Exercise using payload to test wireshark and other tests

EXERCISES

1. The tool ss is a Linux tool comparable to netstat. Test out the tool, and the effect of the options -l (listening ports) -a (all ports) -p (process listing) -e (extended information) -i (internal information) -t (TCP) and -u (UDP).
2. Run one or more of the Sysinternals tools from the network via live.sysinternals.com\tools.
3. Use the Sysinternals tool pslist from the command line to list the running processes, and use pskill to kill a process.
4. Compare and contrast TCPLogView http://www.nirsoft.net/utils/tcp_log_view.html with Sysinternals TCPView.
5. Wireshark is vulnerable to direct attack. Install Wireshark 1.4.4 on a Windows system, and use the Metasploit module exploit/windows/misc/wireshark_packet_dect to gain a shell on the target.
6. Install the Microsoft Network Monitor, available from http://www.microsoft.com/en-us/download/details.aspx?id=4865. Use it to capture packets during a Metasploit attack against a browser using the reverse HTTPS Meterpreter payload. Can you identify the Meterpreter traffic in the packet capture?
7. (Advanced) The command

   msfpayload windows/shell_bind_tcp LPORT=4444 R | msfencode -t dll -o test.dll

   is used to create raw (R) shellcode for a Windows shell that binds to port 4444 on a system. This is piped to an encoder that converts the result to a .dll and stores the result in the output file test.dll.
   Copy test.dll to a Windows system, and run it using rundll32.exe

   C:\> rundll32.exe test.dll,1

   Connect to the listening shell by configuring /exploit/multi/handler.
   Despite the fact that test.dll is purely shellcode, notice that Process Explorer reports the application as signed, and Virus Total does not see it as suspicious.

From Cyber Operations: Building, Defending, and Attacking Modern Computer Networks

MAC+PHY (MAC and Physical Layer)

Which of the following can be used to map who is able to communicate with whom, the measured strength of signals, and what frequencies are used, as well as be used for jamming certain frequencies and for determining which devices were likely used to set off remote bombs and Improvised Explosive Devices (IEDs)?


Selected Answer:


MAC+PHY (MAC and Physical Layer)
IEEE Layer
Flags fields
Quality of Service information

Dica sobre criptografia e compressão

O tráfego criptografado não se comprime. A compressão reduz o tamanho de um conjunto de dados, removendo redundâncias ou seções repetidas dentro do conjunto de dados. Os dados corretamente criptografados produzem texto cifrado que não contém redundâncias ou padrões reconhecidos. Se o texto cifrado tivesse essas características, não seria tão seguro. Assim, sem essas redundâncias, não é possível comprimir dados criptografados.


(Stewart 87-88)
Stewart, J. Security Security Network, Firewalls e VPNs, 2ª edição. Jones & Bartlett Learning, 07/2013. Arquivo do VitalBook.

technical TIP

Encrypted traffic does not compress. Compression reduces the size of a data set, removing redundancies or repeated sections within the data set. Properly encrypted data produces ciphertext that does not contain redundancies or recognizable patterns. If ciphertext did have these characteristics, it would not be as secure. Thus, without these redundancies, it’s not possible to compress encrypted data.

(Stewart 87-88)

Stewart, J. M. Network Security, Firewalls and VPNs, 2nd Edition. Jones & Bartlett Learning, 07/2013. VitalBook file.

POOR SOURCE CODE QUALITY

Lack of identification is inevitable during functionality testing, even if there has been thorough unit testing during the development phase. Usually, in test management, the test manager comes out with the test approach, scenarios, conditions, cases and scripts, to complete the functional testing of your project. Their test plan should cover all of the requirements that are agreed to be delivered. The test manager will plan several cycles of testing. Starting with a full suite of functional testing, followed by successive cycles of testing defects from previous cycles, along with regression testing of the existing functionality, to make sure the fix made by the team did not impact already tested and proven modules.

There is a huge risk to timely delivery if a high volume of defects inflow is identified by the testing team of a project. There is no industry standard for acceptable defect volumes, but, if you see a large volume of critical or high priority defects, then as a project manager, you have to revisit your development team’s quality assurance procedures/processes.

Root cause analysis
Any defect identified by the test team has to undergo root cause analysis that undermines the basic cause of the defect. A defect could be at the code, design, environment or even a requirement gap; you will have to focus on the prime factor for the defects and take appropriate measures, such as revisiting your process, tightening the review process, or adding more unit testing.

Re-opened defects
Re-opened defects are a bigger challenge. They are the defects that are fixed, or claimed to be fixed, by the team, but tests prove it to still be open, and the test team has to reopen it. This could be due to lack of testing on the developer’s side, or delivery of a wrong version of the code.

Defect fixes create more defects
There are situations where a defect fix opens up newer defects during the testing. This proves that the development team has not performed proper impact analysis and has failed to perform end-to-end testing.

Add penalty clauses for such scenarios (such as re-open defects, defect fixes create more defects) in the development team’s contract, so they will be more careful with their delivery.

One bright side of the problem is that we identify defects and issues earlier with the test team’s help, rather than facing them after go-live.

one person cannot identify all risks alone since different perspectives are needed

The Real World
Jane has extensive experience in IT, particularly in application development and operations; however, she is relatively new to the information security field. She received a battlefield promotion to the role of information security officer at the financial organization she worked for (ACME Financials) after a data breach occurred. Focusing on information security she obtained her CISSP designation and built up the security program at her company by aligning with well-known information security frameworks.
Jane excelled in her position, and came to the attention of a large healthcare organization after one of the auditors of ACME Financials mentioned her to the CIO at the healthcare organization. After some aggressive recruiting the CIO convinced Jane to join the hospital system as their information security officer. Although she had limited exposure to the Healthcare Insurance Portability and Accountability Act (HIPAA) she is comfortable with working in a regulated environment as her previous organization was subject to Gram-Leach-Bliley Act (GLBA) requirements. The position is new to the hospital system and was created in response to an audit comment noted in a HIPAA audit performed by an external party.
One of the primary tasks that the CIO has for Jane is to build up the information security program. Jane is actually a little hesitant since the organization is significantly larger than her prior company; however, she is up to the challenge. Throughout this book we will keep coming back to Jane’s situation and see how risk assessments play a role in her journey to keep her new company, and frankly her new job, safe!
Let’s talk about Jane’s first day on the job. She wasn’t expecting much. Just show up at HR, get her keys, badges, and attend the new employee orientation. Basically, just ease into her new job and allow hereself to adjust and get a feel for the organization. As you well know, that seldom happens in the real world. Instead of sitting in new employee orientation the CIO of the hospital decided at the spur of the moment to ask her to speak to the IT managers, some members of the hospitals risk committee, audit department, and other select department heads of the hospitals about what she believes the organizations primary information security risks are!
Whoa! Definitely not the first day Jane was expecting. But she wasn’t going to let this rattle her. Well, she was rattled a little but she was not completely unprepared. In her prior company she had implemented her program using a risk-based approach so she was familiar with the concept of risk. She also knew that with this diverse group of people, they would probably come to the meeting with their own preset ideas on the definition of risk in the context of their specific department or field. Since it was her first day, she really didnt want to ruffle any feathers by minimizing or highlighting specific risks since she didn’t feel like she knew enough about the organizations operating environment to make that call.
With all of that in mind, instead of going up and enumerating risks from out of the air, Jane decided to start with a conciliatory note:
“Each one of us here would most likely have their own ideas of what the “primary” risks are. For example, for audit, you would probably be concerned about the possibility of a lack of compliance to HIPAA. For the department heads here, this could be the possibility that we’ll be unable to deliver service to our patients. For others, it could be a possible inability to protect our patient’s personal information. All of these are valid risks and all could produce a negative impact to our organization. But in order to answer the question of which ones are the “primary” risks to the organization, we need to start measuring risk through a documented and repeatable process. This is one of the main things that I plan to start with, a formal risk assessment process for information security. Though ultimately risk is always based on perception, a formal process will allow us to look at all the risks in a more objective manner. What I would really like to do now is go around the table and ask each of you to tell me what risks are of primary concern to your department.”
As Jane waits for a response from the group she is met with blank stares! Not one to give up, she decided to just start with the person immediately on her left and then work her way around the room, helping each of the participants to convey their risk in a structured way by utilizing her knowledge of the definitions and components of risk. For example when she was talking to the applications manager:
Jane: “What security event are you worried about?”
Application Manager: “Hmmm. Not much really. But I guess hackers might be able to get into our hospital website?”
Jane: “That’s is worth looking into. What things to do you have in place to protect from hackers?”
Applications Manager: “Hmmm. Nothing on our side. But we do have a firewall. Besides the website is just html and I don’t think they’ll be able to use anything there.”
Jane: “But they can deface the website right?”
Applications Manager: “Right. That’s true, they can deface the website by changing the files.”
CIO: “Hmmm. I think we’ll want to look more into that. That would be really embarrassing to the hospital. If people think we can’t protect our website, then how would they be comfortable that we can protect their sensitive information?”
By going around the table, Jane is beginning to see trends in the risks that the people in the room are most concerned with and equally as important is able to start identifying preconceptions that may be wrong. You’ve also probably noticed that she is doing it in a very structured way; ask for the threat, then the vulnerability, and finally the asset. It’s good to know the basics since if push comes to shove you can fall back onto basics to guide a productive conversation about risk.
By going around the room and letting other people talk, with some gentle guiding, she was able to quickly learn quite a bit about the perception of risk within her new organization. She did run into some snags, one of the attendees was adamant that the risk assessment could be done in a day and was under the impression that the meeting they were having was the risk assessment, not understanding why the process would actually take some time and require meetings with multiple groups. Now the meeting was probably not what Jane’s CIO was expecting but hey, it’s her first day and she knows she is going to educate her new boss as much, or probably even more, than anyone else in the organization. Although done indirectly, Jane was able to convey that one person cannot identify all risks alone since different perspectives are needed and that this would ultimately be an organizational effort. She also demonstrated her knowledge of the concept of risk and used that knowledge to create a structured information gathering approach for questioning the meeting participants.
All in all, not a bad first day for our information security officer!

WebSockets - library

The Solution: WebSockets

No doubt you’ve heard people talking about HTML5 and all its neat new features. Two of these new features directly apply to realtime web technologies and client server communication—a fantastic result demonstrating that the web standards organizations and browser vendors really do listen to our feedback.

Server-Sent Events and the EventSource API¹³ are a formalization of the HTTP streaming solution but there is one more solution that’s even more exciting.

You may have heard the term WebSockets a time or two. If you’ve never really looked into realtime before, WebSockets may not have shown up on your radar except as a buzzword in articles talking about all the great new features of HTML5. The reason why WebSockets are so exciting is that they offer a standardized way of achieving what we’ve been trying to do through Comet hacks for years. It means we can now achieve client server bidirectional realtime communication over a single connection. It also comes with built-in support for communication to be made cross-domain.

Figure 1-5.  Websockets open a full-duplex connection, allowing bidirectional client server communication

The WebSocket specification is part of HTML5, which means that web developers can use the WebSocket protocol in modern browsers.¹⁴

According to the WHATWG,¹⁵ the WebSocket protocol defines a standardized way to add realtime communication in web applications:

The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling).¹⁶

One of the most beneficial implications of widespread WebSocket support is in scalability: because WebSockets use a single TCP connection for communication between the server and client instead of multiple, separate HTTP requests, the overhead is dramatically reduced.

The WebSocket Protocol

Because full-duplex communication cannot be achieved using HTTP, WebSocket actually defines a whole new protocol, or method of connecting to a server from a client.

This is accomplished by opening an HTTP request and then asking the server to “upgrade” the connection to the WebSocketprotocol by sending the following headers:¹⁷

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin:http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

If the request is successful, the server will return headers that look like these:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

This exchange is called a handshake, and it’s required to establish a WebSocket connection. Once a successful handshake occurs between the server and the client, a two-way communication channel is established, and both the client and server can send data to each other independently.

Data sent after the handshake is enclosed in frames, which are essentially chunks of information. Each frame starts with a 0x00byte and ends with a 0xFF byte, meaning that every message sent has only two bytes of overhead in addition to the message’s size.

So we’ve made it very clear that this is great news for web developers. But it’s not all unicorns and ice cream cones, unfortunately: as ever, we’ll be waiting for a minority of users and companies to upgrade to modern browsers. We’re also going to be waiting for some parts of the Internet infrastructure to catch up. For instance, some proxies and firewalls block legitimate WebSocketconnections. This doesn’t mean we can’t start using them in our applications, however.

HTML5 WebSocket Technology and Pusher

We already talked a bit about WebSocket and realtime, but let’s recap: HTML5 WebSocket allows applications to push data to the client rather than requiring the client to constantly ask for new data.

EXERCISE 2-6: TRYING OUT THE WEBSOCKET API

Let’s have a look at the native WebSocket API to get an idea of how it can be used. Create an HTML file with the following content. This file contains JavaScript that connects to a WebSocket echo test service. This means that you can test connecting, sending, and receiving messages.

<!doctype html>
<html lang="en">

    <head>
        <meta charset="utf-8" />
        <title>Trying out the WebSocket API 02-06</title>
    </head>

    <body>

        <script>
            var ws = new WebSocket( 'ws://echo.websocket.org' );

            ws.onopen = function() {
              console.log( 'connected' );
              console.log( '> hello' );
              ws.send( 'hello' );
            };
            ws.onmessage = function( ev ) { console.log( '< ' + ev.data ); };
            ws.onclose = function() { console.log( 'closed' ); };
            ws.onerror = function() { console.log( 'error' ); };
        </script>

    </body>

</html>

If you open up this page in a browser that supports WebSocket and open up the browser’s JavaScript console, you’ll see the following:

connected
> hello
< hello

The connected message is displayed when WebSocket has connected to the server, and the onopen function handler has been called. The code then logs > hello to indicate it’s going to send hello over the WebSocket connection to the server using the WebSocket send function. Finally, when the server echoes back the message, the onmessage function handler is called, and < hellois logged to the console.

This demonstrates how to use the WebSocket API and gives you a glimpse of how useful it could be. But, as we covered in Chapter 1, the WebSocket API is not fully supported in all browsers just yet, and we need a fallback mechanism. As a result, implementing realtime apps can be cumbersome, tricky, and extremely time-consuming if we have to handle browser compatibility issues ourselves.

Fortunately for the rest of us, there are a number of services out there that have overcome these hurdles and created APIs that start by checking for WebSocket support; then regressively check for the next-best solution until they find one that works. The result is powerful realtime functionality without any of the headache of making it backward-compatible.

Among these companies offering realtime services, Pusher stands out for its extreme ease of implementation, free accounts for services that don’t have large user bases, great documentation, and helpful support staff.

Pusher provides a JavaScript library¹¹ that not only handles fallbacks for older browsers but also offers functionality such as auto-reconnection and a Publish/Subscribe¹² messaging abstraction through its API, which can make it much easier to use than simply dealing with generic messages, as would be the case if we used the native WebSocket API.

Finally, because Pusher is a hosted service, it will handle maintaining the persistent connections over which data will be delivered and can deal with scaling to meet demand for us. Although this latter point might not be a big deal for our sample application, it’s a valid consideration when you are building a production application.

For those reasons, we’ll be using Pusher in this book to build our realtime.

Why Do We Need It?

Pusher will allow you to add realtime notifications and updates to the application, including the following:

• Updating all users when a new question is added: This means that when a user adds a new question, all users currently using the app in that room will receive the new question immediately.
• Updating attendees when the presenter marks a question “answered”: When the presenter answers a question, marking it “answered” will instantly update all attendees’ devices to prevent confusion.
• Updating the presenter when more than one attendee wants the same question answered: If more than one user is interested in having a question answered, they can upvote that question. The presenter will receive a visual indication to let them know that the question is pressing.
• Updating all attendees when a room is closed: When the presenter closes the room, attendees need to be updated so they know not to ask any questions that won’t be answered.

What Role Does It Play?

Pusher will play the role of the app’s nervous system: it will be informed when changes are made and relay that information to the brains of the app so that they can process the information.

How Does It Work?

In the simplest terms, Pusher provides a mechanism that lets the client “listen” for changes to the app. When something happens, Pusher sends a notification to all the clients who are listening so that they can react appropriately. This is the Publish Subscribe paradigm we mentioned earlier.

Chapter 3 is dedicated to the finer details, so we will skip the exercise in this section.

OAuth

Unlike the technologies discussed so far, OAuth is a protocol, not an actual programming language. It’s a concept that was drafted in 2007 to address the issue presented by websites that provided services that overlap; think about how social networks can access your address book to look for friends or how a photo sharing site can tie into Twitter to let your followers know when you’ve posted a new photo.

The problem was this: when these services first started to work together, they required that users provided a username and password to access the service, which was potentially a huge risk. What was to stop a shady service from using that password for its own purposes, up to and including the possibility of changing your password and locking you out?

This was a big concern. OAuth devised a solution based on its study of a number of other attempts to solve the problem, using what it considered to be the best parts of each.

To paraphrase an excellent analogy from the OAuth website:¹³

OAuth is like giving someone the valet keys to a luxury car. A valet key will only allow the car to drive a few miles; it doesn’t allow access to the trunk; it prevents the use of any stored data in the cars onboard computers, such as address books. OAuth is similar to a valet key for your online services: you don’t provide your password, and you’re able to allow only certain privileges with the account without exposing all of your information.

For instance, Facebook uses OAuth for user authentication on third-party services. If you’re already logged in to Facebook, you’re presented with a dialog (on Facebook’s domain), telling you which permissions are required and allowing you to accept or deny the request. Privileges are compartmentalized—reading someone’s timeline is different from viewing their friends list, for example—to ensure that third-party services receive only the privileges they need to function.

This keeps users safe and reduces liability for web apps. It also provides a wonderful benefit for developers: we can allow a user to log in to our app with their Facebook, Twitter, or other credentials using a simple API.

Why Do We Need It?

We don’t need it in the app that we’re building, but it would be a neat feature so we’ve included it in Appendix A if you want to see how it could be included. In a nutshell, we would use OAuth to eliminate the need to build a user management system. This would also hugely reduce the time needed to sign up for an account without reducing the app’s access to the information it needs to function.

Let’s face it: most people have more accounts than they can remember on the Internet. The difference between someone using our app and not using our app could be something as simple as how many buttons he has to click to get started.

OAuth provides a great way to get everything we need:

• Verify that the person is indeed real: We can reasonably assume that anyone who is signed into a valid Facebook or Twitter account is a real person.
• Collect necessary data about the user: For this app, we would really only need a name and e-mail.
• Reduce the barrier to entry: By eliminating all the usual steps of creating an account, we could get the user into our app in seconds with just two clicks.

What Role Does It Play?

OAuth would be the gatekeeper for our app. It would use third-party services to verify the authenticity of a user and gather the necessary information for the app to function.

How Does It Work?

You’ll find more details on the specifics of OAuth in Appendix A, but at its core, OAuth contacts the service through which we want to authenticate our user and sends a token identifying our app. The user is prompted to log in to the third party service if they’re not already and then allow or deny the requested privileges from our app. If the user allows our app to access the requested data, the service sends back a token we can use to retrieve the necessary data and consider a user “logged in” to our app.

Summary

At this point, we have successfully defined a rough list of functionality and requirements for our app. We also used that information to flesh out a list of tools we will use to bring the app to life.

In the next chapter, you’ll get familiar with Pusher and its underlying technologies, and you’ll build your first realtime application.

¹ This is 100% the opinion of the authors.

² http://www.apress.com/9781430228745

³ http://www.apress.com/9781430228479

⁴ http://socket.io

⁶ http://signalr.net/

⁵ http://faye.jcoglan.com

⁷ http://www.tornadoweb.org/

⁸ http://www.apress.com/9781430224730

⁹ http://www.sequelpro.com/

¹⁰ http://www.navicat.com/en/

¹¹ http://pusher.com/docs/client_libraries/javascript

¹² http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

¹³ http://oauth.net/about/

risk management

1. What is the goal or objective of an IT risk management plan?
* The purpose of the Risk Management Plan is to define how risks will be managed, monitored and controlled throughout the project.


2. What are the five fundamental components of an IT risk management plan?

* The components of a Risk Management Plan are Risk Identification, Risk Analysis, Risk Evaluation, Risk Monitoring, and Review.

3. Define what risk planning is.
* Risk planning is developing and documenting organized, comprehensive, and interactive strategies and methods for identifying risks.

4. What is the first step in performing risk management?
* One of the most important first steps for a risk management plan is to establish the objectives.

5. What is the exercise called when you are trying to identify an organization’s risk health?

* Health Risk Assessment

6. What practice helps reduce or eliminate risk?
* Risk Management.

7. What on-going practice helps track risk in real-time?.
* Risk Mitigation.

8. Given that an IT risk management plan can be large in scope, why is it a good idea to develop a risk management plan team?
  * Scope identifies boundaries. So, if the plan is that large in scope, a team would work obviously together and not against to maintain its structure in nature and have consensus.


9. Within the seven domains of a typical IT infrastructure, which domain is the most difficult to plan, identify, assess, remediate, and monitor?
* LAN-WAN

10. From your scenario perspective, with which compliance law or standard does your organization have to comply? How did this impact the scope and boundary of your IT risk management plan? 
* Honoring that the law requires a student to receives grades from instructors physically. Compliance


11. How did the risk identification and risk assessment of the identified risks, threats, and vulnerabilities contribute to your IT risk management plan table of contents?
* It was detailed properly to locate provided information needed.

12. What risks, threats, and vulnerabilities did you identify and assess that require immediate risk mitigation given the criticality of the threat or vulnerability?

* Among other things, faculty and/or students weak or being subject to falling short of financial, pleasure or any other immoral selfish gain.

13. For risk monitoring, what techniques or tools can you implement within each of the seven domains of a typical IT infrastructure to help mitigate risk?

* Anything possible, man or man-made to properly assess, identify and deal with possible risks.

14. For risk mitigation, what processes and procedures are needed to help streamline and implement risk mitigation solutions to the production IT infrastructure?

* Control, remediation, assess and reporting are key.

15. How does risk mitigation impact change control management and vulnerability management?
 * Change control is a systematic way to approaching change, within an organization; it can prevent the possibility of services becoming interrupted and if so, provide a plan to bring them back up as soon as possible

A polícia entrega USBs infectados como prêmios no questionário de segurança cibernética

12 de janeiro de 2018

Segurança do governo, Malware


Tão irônico. Você trabalha duro para ganhar um prêmio de segurança cibernética, e o que você obtém? Uma unidade USB recheada com um sabor assustador e desagradável, é isso mesmo.

O governo de Taiwan no mês passado celebrou sua repressão ao crime cibernético. A polícia nacional - o Bureau de Investigação Criminal (CBI) - pegou 250 unidades USB em branco, cada uma com uma capacidade de 8 G, para distribuir como prêmios na expo de segurança de dados, hospedada pelo escritório presidencial de 11 a 15 de dezembro.

De acordo com o Tapei Times, um empregado em um empreiteiro New Taipei City, Shawo Hwa Industries Co., primeiro testou as unidades, criando um sistema operacional sobre elas e testando a capacidade de armazenamento

Opa! O CBI disse depois de investigar a infecção, que terminou em 54 das unidades que foram entregues aos vencedores de um questionário sobre conhecimento de segurança cibernética. "Vencedores de um questionário sobre conhecimento de segurança cibernética", como "pessoas" que espero saber o suficiente para não conectar unidades USB aleatórias convenientemente espalhadas por todo o estacionamento, mas não necessariamente aquelas entregues em um prato de prata em uma expo de segurança ".

De acordo com a CBI, as 54 unidades capturaram um arquivo de malware executável que passa pelo nome de XtbSeDuA.exe. A CBI disse que o malware foi projetado, anos atrás, para sugar dados pessoais e transmiti-lo para um endereço IP baseado na Polônia que, em seguida, transmitir a informação para servidores não identificados.

Em 2015, o malware estava sendo usado para fraudes eletrônicas descobertas pela Europol, de acordo com a CBI, embora não conseguisse encontrar o registro de qualquer malware com esse nome.

De qualquer forma, o CBI teria dito que apenas os computadores antigos de 32 bits são suscetíveis ao malware e que o software anti-vírus comum pode detectá-lo e colocá-lo em quarentena. Embora algumas das unidades de polegar - elas fossem originárias de vários fornecedores - foram feitas na China, a CBI descartou a espionagem chinesa.

O CBI disse que o servidor configurado para receber dados do malware foi encerrado.

Uma fonte anônima disse ao Taipei Times que o escritório presidencial não ficou particularmente satisfeito pelo fato de que um de seus eventos - um evento para celebrar seu trabalho de cibersegurança, foi comprometido desta maneira.

Na verdade, apesar da investigação da CBI mostrar que o malware veio de um empreiteiro do governo trabalhando no computador de um contratado do governo, o escritório exigiu que a agência pesquissasse mais sobre o incidente.

CSI Computer Crime and Security Survey 2010/2011

The Computer Security Institute (CSI) completes regular surveys that identify many of the trends related to IT security. The 2010/2011 report includes responses from 5,412 security practitioners.

Some of the notable findings in this report were:

•  Malware infections are the most commonly seen attack. Over 67 percent of respondents reported malware infections. This is an increase of 3 percent from the previous year. The lowest was 50 percent in 2007.

•  About 29 percent said zombies within their network. A zombie is a computer joined to a botnet. This is an increase of 5 percent from the previous year.

•  Most respondents attribute losses to outsiders. Almost 60 percent indicated they did not believe any of their losses were due to malicious insiders.

•  Only about 25 percent reported insider abuse of network access or e-mail usage. This is a significant reduction from a high of 59 percent in 2007.

•  Of respondents indicating incidents, 45.6 percent reported they were the subject of at least one targeted attack. The trend is more attacks from advanced persistent threats (APTs).

•  Losses due to financial fraud declined from almost 19 percent to about 8 percent during the period.

•  Respondents indicated that regulatory compliance efforts had a positive effect on their security programs.

•  Nearly half of the organizations reported they were using cloud computing, but only 10 percent indicated they were using cloud-specific security tools.

(Gibson 35)

Gibson, Darril. Managing Risk in Information Systems, 2nd Edition. Jones & Bartlett Learning, 07/2014. VitalBook file.

The citation provided is a guideline. Please check each quote for accuracy before use.

Attacker’s Cost < Attacker’s Gain

Often the goal is not to eliminate the risk but, instead, to make it too expensive for the attacker. Consider the following two formulas:

•  Attacker’s Cost < Attacker’s Gain—When this is true, it is appealing to the attacker.

•  Attacker’s Cost > Attacker’s Gain—When this is true, the attacker is less likely to pursue the attack.

Cryptography is one of the ways to increase the attacker’s cost. If your company sends data across the network in cleartext, it can be captured and analyzed. If the company encrypts the data, an attacker must decrypt it before analyzing it. The goal of the encryption isn’t to make it impossible to decrypt the data. Instead, the goal is to make it too expensive or too time-consuming for the attacker to crack it.

(Gibson 24)

Gibson, Darril. Managing Risk in Information Systems, 2nd Edition. Jones & Bartlett Learning, 07/2014. VitalBook file.

The citation provided is a guideline. Please check each citation for accuracy before use.

Básico teste de Penetração em uma Máquina Virtual (Boot2Root Challenge)

https://www.linkedin.com/pulse/b%C3%A1sico-teste-de-penetra%C3%A7%C3%A3o-em-uma-m%C3%A1quina-virtual-rodrigues-alves/

Validate the problem

A remarkable number of products turn out to be solutions in search of a problem. The Segway and Google Wave are two famous examples, but a more subtle one comes from a startup called Patient Communicator, which created an online portal where patients could get in touch with doctors and doctors could manage patient information. If you’ve ever waited in line for a long time to see a doctor, especially if all you had was a trivial question, this feels like a real problem. We might phrase the problem as “doctors don’t have an efficient way to manage patient communication and information.” However, the founder of Patient Communicator, Jeff Novich, learned the hard way that this wasn’t a real problem:

The sum total of our efforts—which included hundreds of cold calls, tens of thousands of emails (I was invited to a “top 20 customers” dinner with TK from Tout), seminars, an appearance on FOX News Live, ads, reaching out to our personal networks as well as the Blueprint Health mentor network—was one paying doctor (who later went out of business) and a handshake deal to partner with a small 20-year-old EMR.

[Novich 2013], Jeff Novich, Founder of Patient Communicator

Novich lists several reasons the company failed, including one I found particularly revealing: “doctors want more patients, not an efficient office” [Novich 2013]. This seems like a subtle difference, as a more efficient office could lead to more patients, but focusing on the wrong problem leads the entire company astray.

For example, consider the dental industry. For years, it focused on products and marketing about “fighting gum disease” and “preventing tooth decay,” until some marketing genius realized that the problem customers actually cared about was how to get white teeth and fresh breath. Sure, fighting off gum disease and tooth decay could lead to white teeth and fresh breath, but focusing on the wrong problem means all the products, marketing strategies, and sales materials are wrong. If you focus on tooth decay, you probably don’t come up with profitable product ideas like tooth whitening strips, breath mints, mouthwash, and 3D whitening toothpaste (whatever that is). This is why you need to validate that you’ve identified the right problem before running off and solving it. As Harvard Business School marketing professor Theodore Levitt put it, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” [Christensen, Cook, and Hall 2006].

It’s also important to validate that the problem you’ve identified is big enough to warrant building a startup around it. There are three aspects to consider when thinking about the size of a problem: frequency, density, and pain.

Frequency: Does the problem you’re solving occur often?
Density: Do a lot of people face this problem?
Pain: Is the problem just an annoyance, or something you absolutely must resolve?

[Kumar 2015], Manu Kumar, K9 Ventures

For example, consider Facebook and LinkedIn. Facebook scores very high for frequency (you might use it multiple times per day to communicate with friends and family) and density (just about everyone with an Internet connection uses it), but a lot lower on pain (there are many other ways to communicate with friends and family, such as in person, via a phone call, text message, IM, blog post, Skype, Twitter, Snapchat, etc.). On the other hand, LinkedIn scores low for frequency (you don’t need to update your profile, look for a job, or network that often), medium for density (all professionals can use it), and high for pain (there aren’t too many better ways to find a job, find a candidate, or get in touch with a colleague).

Not all products are as obvious as Facebook and LinkedIn, and to be fair, the potential size of these social networks was not obvious in their early days either, so you’ll have to do some market sizing to estimate the size of a problem.

Market sizing

The size of the market determines how much money you can make—and therefore how much money you can raise, how big your company can get, what kind of products you can build, what kind of strategies you can use for sales and marketing, and a number of other factors. A good way to think about market size is to consider the different ways you could build a company that makes $1 billion in revenue:

• Sell product at $1 to 1 billion: Coca-Cola (cans of soda)
• $10 to 100 million: Johnson & Johnson (household products)
• $100 to 10 million: Blizzard (World of Warcraft)
• $1,000 to 1 million: Lenovo (laptops)
• $10,000 to 100,000: Toyota (cars)
• $100,000 to 10,000: Oracle (enterprise software)
• $1,000,000 to 1,000: Countrywide (high-end mortgages)

[Srinivasan 2013], Balaji S. Srinivasan, Stanford Startup Engineering Class

For example, if you have an idea for a product that costs around $10, then to build a startup around it that can scale to $1 billion in revenue, you need a market that has at least 100 million people in it (or more, as you’ll probably share the market with competitors), and a lot of capital up front (because you make relatively little money per sale and it takes a long time for a product to reach an audience of millions); in addition, you need to devise a marketing strategy that can reach this huge audience, such as advertising. On the other hand, if you have an idea for a product that costs $100,000, then you’re looking for a market of at least 10,000 customers; you might be able to bootstrap the business off of a small number of early customers, and instead of advertising, you might need to focus much more on building a massive sales team.

The following list summarizes different ways to estimate the size of the market (the full list of market-sizing resources can be found at http://www.hello-startup.net/resources/idea-validation/):

Advertising

Many advertising companies offer ad-targeting tools that you can use to research the market without actually paying for any ads (although buying ads can be a good way to test your MVP, which we discuss in “The MVP”). For example, you can use the Google AdWords Keyword Planner to research how many searches there are per month for specific terms. When doing research for hello-startup.net, I looked up about 50 relevant keyword groups (e.g., “startup ideas,” “code review tools,” “equity calculator”) and found that they averaged more than 12 million searches per month. This gave me confidence that “how do I build a startup?” is a real problem. It also helped me hone the language on the resource pages. For instance, I found that “business ideas” was a common synonym people used for “startup ideas.” I also used the ad tools from several other companies and found that there are roughly 16 million people interested in startups on Facebook, 2 million people interested in startups on Twitter, and 13 million people who list entrepreneurship as their industry on LinkedIn.

Competition

If there are already companies solving this problem, it’s not necessarily a bad thing. If anything, the fact that your idea isn’t unique is validation that you’ve found a real problem. To find a list of competitors, use the advertising tools just described to find the right keywords and try to search Google and the mobile app stores to track them down (it shouldn’t be too hard, or their customers won’t be able to find them either, in which case, you don’t have to worry about them). To see how a specific competitor is doing, you can try website analytics tools (e.g., comScore, Quantcast) and mobile analytics tools (e.g., App Annie, Xyo) to estimate their traffic. You can also see how much funding the competitors have and what investors are backing them using websites like CrunchBase and AngelList.

For example, when I was considering turning hello-startup.net into a mobile app, I did some research on competitors. Through Google, I found several other apps that contained startup resources, such as Elevatr, Tech Startup Genius, and Crazy About Startups. From Xyo, it looked like none of these apps had much traction, with Elevatr in the lead at around 17,000 installs. I also searched for other companion apps for books and found several with more traction, such as an app for George R.R. Martin’s A World of Ice and Fire (free; 420,000 installs) and an app for Mark Bittman’s How to Cook Everything ($5; 230,000 installs). This information gave me a ballpark range for how many installs this sort of app could get (from the low thousands up to several hundred thousand) and even different pricing models (free or $5).

Community

Another good way to validate problems is to see if there is already a community of people talking about them. You can search for meetups, conferences, user groups, and online forums to estimate how many people this problem affects. For example, while researching hello-startup.net, I looked on Meetup.com and found 15,000 entrepreneurship groups (4 million members), 3,000 tech startup groups (1 million members), and 2,200 Lean startup groups (650,000 members). On Lanyrd, I found 119 startup conferences and submitted proposals to a few so I could actually talk with the people in these communities. I also found the startups subreddit (roughly 74,000 members), startup and entrepreneurship groups on LinkedIn (roughly 150,000 members), startup topics on Quora (roughly 800,000 followers), and, of course, there’s Hacker News (at least 120,000 unique users per day reading about startups).

Market research and reports

Some good old-fashioned research is always worth the effort. Search online for newspapers, books, journals, classes, podcasts, and blogs that discuss your topic. When relevant, you can also look up SEC filings and government reports (e.g., from the US Small Business Administration). During my hello-startup.net research, I found hundreds of blogs that focus on startups (e.g., Paul Graham’s Essays, TechCrunch, OnStartups), dozens of books (e.g., Founders at Work, The Lean Startup, The Startup Owner’s Manual), and several courses (e.g., Stanford’s How to Start a Startup and Coursera’s Startup Engineering).

There are also a number of companies that specialize in gathering data and publishing reports on specific industry topics. Some of the data is free, such as the World Bank Data. For the rest, you can pay a company such as Nielsen Media Research to do market research for you or a company like AYTM to send out surveys to targeted audiences on your behalf.

Product data

If your product is already live, there are many metrics you can gather and analyze to estimate the impact of a new feature. See Chapter 4 for more info.

This list is not comprehensive, but it should be enough to get you started so that you can do some back-of-the-envelope calculations to estimate the size of the market. Once you’ve identified a problem of a reasonable size, the next step in the validation process is to identify a small number of customers who have that problem and talk to them in person.

Talking to real customers

When you talk to customers, your goal is to learn everything you can about their day-to-day lives and determine the following:

• Is this a real problem for the customer?
• What possible solutions are there to the problem?
• How much is the customer willing to pay to solve the problem?

To answer these questions, you have to “get out of the building” and talk to real customers. However, there’s a catch: it’s not always effective to directly ask customers what they want. Some customers have no idea what they want. Some customers know what they want, but they tell you they want X even though they actually want Y. Sometimes this is because customers don’t want to hurt your feelings, so they tell you they like your product even though they know they’d never actually buy it. Sometimes it’s because the customers have an incentive not to tell you the truth, such as not telling you how much money they are willing to pay for a product. Sometimes it’s because customers aren’t even aware of their own preferences.

If I asked all of you, for example, in this room, what you want in a coffee, you know what you’d say? Every one of you would say, “I want a dark, rich, hearty roast.” It’s what people always say when you ask them what they want in a coffee. What do you like? Dark, rich, hearty roast! What percentage of you actually like a dark, rich, hearty roast? According to [Howard Moskowitz’s research], somewhere between 25 and 27 percent of you. Most of you like milky, weak coffee. But you will never, ever say to someone who asks you what you want that “I want a milky, weak coffee.”

[Gladwell 2004], Malcom Gladwell, Choice, Happiness and Spaghetti Sauce

Even if the customer is fully aware of their own needs and even if they are willing to be honest with you, most of the time they still won’t be able to help you find a good solution, as customers usually only think in terms of 10% better, faster, and cheaper [Kawasaki 2011]. Many customers will ask you for specific features, but your goal is not to walk away with a long feature list. Small incremental improvements and slightly better features rarely make for good startup ideas, as we’ll discuss in “Focus on the differentiators”, so your real goal is to get a deep understanding of the underlying problem.

If I had asked people what they wanted, they would have said faster horses.

Henry Ford

To get to the underlying problem, you’ll have to do a lot more listening and observing instead of talking. Don’t push your ideas on the customer or try to convince them. Instead, try to get them to do as much of the talking as possible. A classic technique you can use, pioneered by Toyota founder Sakichi Toyoda, is the five whys. This technique is best illustrated with an example. Imagine you’re the owner of a trucking company and one of your employees, Bob, tells you that his truck won’t start. Instead of jumping straight to a solution, you repeatedly ask “why” to get to the root cause:

Bob: The truck won’t start.

You: Why?

Bob: The battery died.

You: Why?

Bob: (Investigates) Looks like the alternator isn’t working.

You: Why?

Bob: (Investigates) The alternator belt broke.

You: Why?

Bob: (Investigates) The alternator belt is really old and should have been replaced a long time ago.

You: Why?

Bob: I guess we haven’t been maintaining the vehicle according to the proper maintenance schedule.

If you solved the first problem you heard, that the truck won’t start, your solution would’ve probably been to replace the truck or the battery, which would only be treating a symptom. By asking the five whys, you’re able to uncover the underlying problem: lack of a proper maintenance schedule for the trucks in your fleet. It doesn’t always take exactly five whys to get to the root cause, but you should almost always ask why at least once to make sure you’re identifying the real problem.

After a number of customer conversations, you should have a better understanding of what the real problems are. Before jumping in and building a solution, there is one final quality you must check for: feasibility.

Feasibility

There are two facets to whether a problem is feasible:

• The problem can be solved.
• The problem can be solved by you.

The first question is about market realities. It combines the market sizing and problem validation from earlier in this chapter with a reality check of whether the technologies you need to solve this problem exist and if the economics of the solution work to create a profitable business. The partners at Sequoia Capital, one of the most successful venture capital firms in the world, ask founders the following question: “Why now?” [Calacanis 2013]. What has changed in the world that now is the perfect time to build this company? What do you know that other people don’t? Why didn’t somebody build this company two years ago and why will building it two years from now be too late?

For example, Webvan was an online grocery store that became one of the most famous dot-com flops when it went bankrupt in 2001, after having burned through more than $800 million by building warehouses and buying its own fleet of delivery trucks. Today, many new grocery delivery startups are appearing, such as Instacart and Postmates, and they seem to be doing better than Webvan. Their “why now?” story includes the fact that consumers are far more accustomed to ordering things online today than 15 years ago, and the recent advent of smartphones, wireless data, and GPS connectivity makes it possible to build a delivery fleet on top of drivers using their personal vehicles and to build an inventory on top of existing grocery suppliers.

If the problem can be solved, the next feasibility check is if you are the right person to solve it. Part of this has to do with your personal assets, including not only financial resources (e.g., cash and property), but also your skills, knowledge, and connections. This is yet another reason why domain expertise is so essential. Another important aspect is whether this is an idea you really care about. As I mentioned in Chapter 1, building a successful startup will take on the order of 10 years, and requires an enormous amount of hard work and sacrifice, so you not only need to find a problem you can solve but also one you’re willing to spend the next decade of your life solving.