Chapter 4

“Never confuse a single defeat with a final defeat.”

—Scott Fitzgerald

On May 31, 2017, OneLogin, a San Francisco–based software security company that specializes in managing logins to applications and multiple websites, reported a data breach where threat actors allegedly may have attempted unauthorized access to OneLogin data and networks. The full extent of this breach is currently not known. However, OneLogin is sold as software to help increase a person’s overall security. There is no doubt that people started questioning the effectiveness of OneLogin security solutions after the data breach occurred. Evidence of this can be seen on Reddit discussions found on discussion forums at www.reddit.com/r/technology/comments/6emqwz/password_manager_onelogin_admits_data_breach_in/.

Fool.com reported in an article posted on May 27, 2014, how a cyberattack exposed 233 million registered eBay accounts. The article criticizes eBay’s handling of the breach, claiming it took nearly three months to notice the breach and two additional weeks to report it (www.fool.com/investing/general/2014/05/27/ebay-data-breach-response-teaches-everyone-how-not.aspx).

An article in TechCrunch on February 2, 2017, reported that Verizon knocked off $350 million US in its offer to purchase Yahoo!, after Yahoo! suffered two massive data breaches. Many security professionals questioned how well Yahoo! was handling security for its own users after these breaches were disclosed (techcrunch.com/2017/02/21/verizon-knocks-350m-off-yahoo-sale-after-data-breaches-now-valued-at-4-48b/).

These examples show how critical it is to respond to a breach correctly and effectively. Many organizations have completely tarnished their reputation, lost customers, and in some cases, never been able to fully recover after a large-scale data breach. Many of these pitfalls could have been avoided with the proper incident response plans and techniques.

Digital forensic network engineers are involved in part of the process of responding to a data breach. In many cases, their role is much more technical in providing the details around the breach. However, in this chapter, we look at the full scope that is normally required when organizations respond to a breach. This allows a network engineer to fully understand the process and ensure specific tasks meet the needs of the organization during an incident. It is important to point out that incident response is different from digital forensics; however, many incident response plans include using forensics to understand what occurred, proving theories about the incident, or preparing for potential future legal action.

This chapter provides an overview of the incident response process from a managerial point of view rather than a technical one. As a network engineer, you will be engaged in a small portion of the entire incident response process, but we believe it is important for you to understand the challenges that organizations face when building an incident response team (IRT) and engaging in the process. Remember that technical services should always track back to a business goal to be relevant. Understanding this will help maintain funding and support for your forensic practice.

The goal of this chapter is to make sure you understand why organizations fail at the process when responding to a breach and examine the techniques used by organizations that have a successful incident response plan. We have combined several accepted frameworks published on building a successful incident response team to develop the content for this chapter. We have additionally added our own experience as well as an overview on industry-proven components required to build an incident response process within your organization.

In Chapter 5, “Investigations,” we go into the technical details for an investigation that are relevant to network engineers. This includes software used by network engineers when responding to a breach and how to use that software when collecting, preserving, and analyzing evidence. You will use the techniques in Chapter 5 to provide detailed evidence and telemetry data needed by incident response teams at different stages of their investigation, which are outlined in this chapter. Before we do that, let’s step back and examine the basic concepts for proper incident response procedures.

When Hollywood Presbyterian Medical Center paid approximately $17,000 US in early 2016 to remove ransomware, it did so because it could not provide the best patient care services to its customers (www.latimes.com/business/technology/la-me-ln-hollywood-hospital-bitcoin-20160217-story.html). The medical center, its reputation, and the public’s trust for the organization are immediately put at risk after these types of attacks occur. Some organizations believe that hiring a security services company and keeping it on standby as much preparation as they might need for a future incident. Organizations simply cannot rely on having an expert on retainer and buying cyber insurance as their method to respond to a breach. Not having an incident response process could represent a lack of due diligence for enforcing the minimal level of required security and could cause the company to be legally liable regardless of what services are outsourced. Many insurance companies engage a third-party auditor to validate existing controls, which means you need to ensure that you have not only technology in place, but also an acceptable incident response plan.

Many organizations see information technology (IT) investments and, by extension, IT security as costs they can reduce. With the intention of creating better efficiencies, some organizations implement defensive solutions that consolidate or eliminate security programs. This includes sacrificing a complete IT data security program responsible for security awareness, incident response, and breach reaction components because they do not think they will need it or are under the impression that their existing solutions and polices already address these problems. Many enterprise corporations have been guilty of failing to budget a plan because they believe the massive amounts of investments they have made in regulatory and compliance practices, such as HIPAA and PCI DSS, have given them adequate protection and responsive capabilities to deal with a breach. If you recall from our previous chapters, compliance should be your minimum level of security, which means it should not be where you stop your investment, because many of these programs use dated material and just are not good enough to prepare you for real-world threats. The truth is that many compliance programs are not risk based but are written as a one-size-fits-all approach. Every organization is different and so are the vulnerabilities, so you need a tailored program based on your business requirements to be successful.

It is common for organizations to simply overestimate how capable they are in responding to a breach. Many branches of the US government run “tabletop” exercises to practice their incident response capabilities. According to Ready.gov, “Tabletop exercises are discussion-based sessions where team members meet in an informal, classroom setting to discuss their roles during an emergency and their responses to a particular emergency situation. A facilitator guides participants through the discussion of one or more ‘scenarios’ ” (www.ready.gov/business/testing/exercises). These simulation exercises can include situations such as a major power outage, outbreak of diseases, and even cyberattacks. The idea behind tabletop exercises is well intentioned, meaning it is designed to prepare for a real event, but it is not close to a true penetration test or what a red-team-blue-team (attack and defend) training program would offer. In some cases, using tabletop conversations as the only training could provide a false sense of how prepared an organization is for a real cyber incident.

Organizations fail at adequately preparing their programs by not havening continuous, ongoing training. Training exercises should not be treated as special events. Organizations should build continuous training and response procedures that are embedded into an organization’s standard operating procedure. Training should combine the practical, technical, and business aspects of responding to a breach by all team members involved. When should organizations train their incident response teams to respond to a breach? All the time.

It is absolutely critical that organizations have support from the executive (C-Suite) level for cybersecurity measures. If corporations do not have an executive sponsor for cybersecurity, they need to implement a structure that supports executive ownership of cybersecurity issues. Some organizations have their Chief Security Officers (CSOs) reporting directly to the board of directors while other smaller organizations have given traditional responsibilities of the CSO to the Chief Financial Officer (CFO) or Chief Technology Officer (CTO). Although it is not always realistic or possible, moving the CSO position outside the chain of the C-Suite executives can make quite a bit of sense. The CTO and Chief Information Officer (CIO) have roles to implement technology solutions to enable a business (hopefully in a secure manner). The CSO, however, should ultimately be responsible for enabling security while at the same time understanding the requirements set by the CTO or CIO for business operations. Having the CSO sit outside the traditional hierarchical organization chart not only allows for separation of duties but also reduces conflict of interest. Regardless of politics or personal beliefs, one only needs to look at the relationship between former director of the FBI, James Comey, and US President Donald Trump to see why it might be a bad idea to be put in a position where you need to enforce policies for your own boss. This is the same reason many organizations remove the CSO position from the standard management structure, which is simply to remove potential conflicts of interest.

An incident response team, often referred to as an IRT, is a team of individuals who are available, are ready, and have the expertise to investigate a data breach. In most cases, these teams have expertise in both the technical and nontechnical aspects of an organization’s business and technology. This enables them to make quick decisions, understand and interpret results from their investigations, and quickly take any necessary action as needed.

An incident response team must have and follow a well-defined incident response methodology. The basic incident handling methodology described here follows a variation of several public methods and techniques we have modified and feel work best in most environments. Our incident response process consists of the following areas:

1. Create and practice a breach preparedness plan.

2. Secure your data and investigation site.

3. Assemble your incident response team.

4. Contain the data breach.

5. Access the severity and extent of the breach.

6. Follow all legal and organization notification procedures.

7. Perform follow-up actions and procedures.

Many different incident response models are publicly available and widely used. The US Federal Trade Commission has an excellent guide, Data Breach Response: A Guide for Businesses, that can be found at www.ftc.gov/system/files/documents/plain-language/pdf-0154_data-breach-response-guide-for-business.pdf. Additionally, compliance and standards organizations may have their own guide. For example, the Payment Card Industry (PCI) publishes its own guide for data breach response at www.pcisecuritystandards.org/documents/PCI_SSC_PFI_Guidance.pdf. In many cases, these guides do not provide a complete policy that you can implement in your organization as they currently stand. Our recommendation is to take parts of these guides and customize them to meet your specific organization’s business and legal requirements. The same goes for the concepts in this book.

One last point to keep in mind is that there generally aren’t laws or requirements for individuals to become incident responders or incident handlers. In other words, normally, no certifications or government registration is required as there is for lawyers and doctors. However, each geographic region, state, and country may be different. You need to check the local laws in your area to be sure of those requirements.

Do not confuse an incident responder with a forensics specialist. Many places require a forensic specialist, or anyone in the field of collecting any type of evidence, to have a private investigator’s or other type of license. In the United States, laws differ not only by state but also by industry (such as medical, industrial, manufacturing, education, and financial) on the requirements by individuals for conducting incident response and digital forensic investigations. Even though a certification may not be required for you to be an incident handler, you may be required to follow extremely strict state, federal, and other national reporting requirements during your investigations.

In some complicated cases, you are required to report your findings to law enforcement and other government officials. Those reporting requirements may directly contradict nondisclosure and privacy policies you have agreed to within the organization. Failure to comply with all policies and laws may result in personal legal liability for you as the incident handler. If this sounds complicated, do not worry; you are not alone! This is the conundrum many incident and forensic investigators face every day. We suggest you speak with a legal professional if you have any concerns for incidents you are being considered to investigate. Many independent consultants typically purchase business liability insurance or work closely with expert legal professionals. It is likely that if you work for a corporation, your legal liability may be limited because you are acting on behalf of your corporation. Once again, remember laws differ greatly from country to country and sometimes even within the same country.

Before we continue, let’s look at the types of situations you might need to respond to. For a foundation behind developing a response plan, we loosely follow the guidelines defined in NIST Publication 800-61 Revision 2, which you can find at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf. According to the document, a cyber incident is composed of one or more major cyber events. Cyber events can include but are not limited to the following:

Stolen laptops or other sensitive computer equipment that contains data

Attackers compromising internal networks and using those systems to fuel a botnet

Ransomware outbreaks that make systems unusable

Users exposing sensitive information in a public manner intentionally or unintentionally

As you can imagine, there can be hundreds of different use cases. The important point to remember is that an event is an observable artifact that could introduce risk into an organization. It is also important to know that responding to an incident may be required by law or regulation and have specific required tasks, such as what information is released to the public about the incident. During initial incident response cases, the first few minutes can determine the difference between a conviction on a sensitive legal matter to not accomplishing anything. The preparedness plan should include a process around evidence preservation. It is imperative that you treat all cases as if they will lead to legal action even if it is likely not to happen. You may not entirely realize the full impact of what you are investigating until much later. This is why we cover proper data preservation and continually remind you to follow those steps every time you investigate evidence. Be prepared to hear this advice over and over again as you read this book.

A general incident response preparedness plan should include a section on how to handle and preserve evidence. We recommend the following guidelines:

1. Do not access, log in, or change compromised systems.

2. Do not turn off compromised systems.

3. Isolate compromised systems from the network. Unplug wired connections. If a system is wireless, enclose it in a Faraday cage or other enclosure.

4. Collect and clone all data in a forensically sound manner.

5. Document everything and take photographs if possible.

Before you begin creating a response plan, it is critical to understand the environment. At this stage, mature organizations should have most of the documentation available for review. The reality for most organizations is that a review process is required to accurately represent and understand the current environment. This is the stage when you are going to spending time interviewing staff with the goal of understanding details around their jobs, what they support, and the risks associated with the data. At a minimum, we recommend you start with the following:

1. Review all network, application, and workflow documents that are available.

2. Identify and map critical data and assets to network, application, and workflow documents.

3. Request any recent network assessment and security audits.

4. Interview members of each department to gain an understanding of the environment.

5. Review security operations center (SOC), help desk, and general IT support departments.

In later chapters, we also discuss specific network configurations you should ensure are enabled and configured correctly. This includes appropriate logging and retention management configuration of devices. Part of your incident response plan should be to make sure the following security policies are configured on your network devices:

1. Logging in to a central syslog server is enabled.

2. Appropriate log retention is configured.

3. Configuration of logs from the IoT, PCs and workstations, security devices, and network devices is enabled.

4. Correlation of logs to threat intelligence feeds is occurring through a SIEM or similar centralized security type of product.

When you are choosing members of the incident response team, they should include individuals who have experience in how technical systems can be breached and those that understand how to configure and manage such systems. Breach experience could be associated with a job title like penetration tester while managing a system could be a job title like network engineer. Additionally, the incident response team needs managerial, leadership, marketing, and legal representatives to accurately gauge the situation and make appropriate calls that may be financially or politically sensitive. If you are wondering why marketing personnel would be involved, the short answer is that they are probably better able to spin a situation in the most favorable manner for a negative situation like a cyberbreach. What you don’t want is an upset analyst complaining about the situation to the local news.

Here is a list of roles that should be included in a incident response program:

C-level sponsor

Technical members who have knowledge of virtual, physical, and cloud technology

Managers who are authorized to make decisions that impact changes to technology and services

Legal representatives who can advise on the impact of a manager’s decisions

Marketing personnel representing a public-facing message

This story unfortunately highlights how many organizations cannot accurately determine whether attackers have infiltrated their networks. Organizations need to understand when and why they should engage their incident response team. Engaging the team too soon can be costly for the organization and burn out team members. Engaging a team too late could mean attackers may have a chance to fully compromise a network and hide their tracks. There should be rules or triggers that require your organization to engage in incident response as well as a simple method for people to report an incident. Our recommendation is to centralize the method of contact to one email or phone number because people involved in an incident will likely be panicking and need to quickly find the IR resource. This is why the United States makes its emergency number simple to remember: just dial 911. We talk more about contact lists shortly.

The OODA loop provides a good reference process to understand how to quickly react to rapidly unfolding cybersecurity events. It is often used in cybersecurity in areas of threat intelligence. OODA, which stands for observe, orient, decide, and act, was developed by military strategist and United States Air Force Colonel John Boyd (https://en.wikipedia.org/wiki/OODA_loop). The process can be implemented as a workflow and is still used today by many incident response specialists when dealing with various types of crisis situations, including nontechnical ones. Figure 4-1 shows the OODA loop.

From an incident response standpoint, OODA can be used as starting point for teams when they are investigating a situation. In Figure 4-2, we applied typical actions that an incident response team may take and the relationship of those actions in regard to the OODA loop.

When an IRT team initially responds to an incident, they should observe and understand the security event. We mentioned some of these steps earlier in the chapter in relation to initial assessment and interview guidelines.

As a technical member of the IRT team, a network engineer should pay close attention to the security events that are observable. This includes evaluating logs, SIEMs, and device alerts. Another technique we recommend when you are observing the environment is to note the applications that are being used and research any vulnerabilities or security notices for those applications. Most security logs do not show how attackers exploit them to compromise the network. As a network engineer and forensics specialist, you need to look beyond what the logs tell you and conduct additional, and sometimes manual, research. There are many ways to search for possible exploits. Normally, a Google search with the application and exact version number can reveal them. Additionally, sites such as https://cve.mitre.org/ are good places to look for common vulnerabilities and exposure. We also recommend searching the Exploit Database at www.exploit-db.com/ or even PasteBin at https://pastebin.com/. Figure 4-3 shows the search option within the exploit-db website. When you use these search engines, don’t just limit your searches to applications; try emails, IPs, ASNs, and other information belonging to the organization to see whether there are any data leaks.

Let’s look at the typical actions conducted by attackers and how those actions correspond to the OODA model. In Figure 4-4, some actions of cyber attackers have been added into the OODA loop. These actions are loosely based on the Lockheed Martin Cyber Kill Chain Model and describe actions taken by attackers during a cyberattack. You can see the attacker’s potential techniques correlate nicely with opportunities that IRT members can use to investigate and respond to different aspects of an attack. Not every attack will follow a structured OODA loop, but this is a way to model a generalized attack process with how an IRT should operate.

Often customers roll their eyes at me when I discuss creating a solid phone tree as part of an incident response plan. Hopefully, you will never be in a similar situation to the one I was in. In that situation, our IT team’s simple contact method was the only thing the executive could remember. I was probably not the best person to help the executive on the hijacked plane. Anybody would have been better than the late-night desktop support person. Then again, IT is expected to be able to fix anything. By the way, the executive as well as most of the passengers were fine.

A good incident response and communication plan should have a readily available contact list. This is sometimes done as a phone tree. A phone tree is simply a list of people who need to be notified when a breach occurs. The list may include people outside your organization such as third-party interests and contractors. The list normally specifies who is optional and who is required to contact. It should have multiple contact numbers, emails, or other methods of contacting the individuals because important people tend to be busy and mobile. Because criminals are never mindful of our schedules, most lists should include what to do if a person cannot be reached, how often to retry, and what the backup plan is. It is important to remember that contacting people can take valuable time away from your experts investigating the breach. This is why it is not uncommon for organizations to outsource the call list to a service company.

One final contact concept is feedback as the incident takes place. Leadership and stakeholders will likely want to be updated continuously on the status of an incident as it is being resolved. The incident response preparedness plan should include instructions on how the team can provide feedback and updates to company and data stakeholders. If this step is not defined, it is likely the incident response team will be overrun by update requests. If the plan includes a feedback loop, everyone will understand how updates are received and delivered, thus cutting down on the individual updates the incident response team must do, enabling them to concentrate on investigating the incident.

Another question to ask is when all team members are required to be at the same physical location or if members can work remotely over secure channels such as VPN. If they are working remotely, how will information be shared without exposing results to the risk of contamination? Are the facilities able to accommodate the entire team if called in for an emergency? Some organizations make sure their facilities have beds and showers, along with caterers and food service available 24/7 to ensure their teams have everything in place to investigate complicated incidents. In most cases, you do not have to go to this extreme, but it may be wise to prepare for the worst-case situation or at least have something documented.

Incident response teams must make decisions on where and how to stop attackers. In many mature organizations, systems are often housed in different areas of the network or different offsite locations, or they may utilize multiple cloud providers. This makes containment much easier to implement because of the natural network isolation that occurs, preventing threats from easily spreading over gateways and firewalls. However, it complicates the job for cyber forensics investigators because now they have multiple systems for which they must collect evidence and multiple networks they must understand and assess. Seasoned cyber forensics investigators understand how to collect information on different systems and prepare for different use cases, such as systems being left on, shut down, damaged, virtualized, and so on. This may mean that different strategies need to be deployed among different applications. Be aware that individuals responsible for a forensics investigation may have conflicting actions to the incident responders. For example, it is very common that organizations have a policy in place to reimage any system infected with malicious software. This incident response action directly contradicts what a forensics investigator would do, which is to clone and investigate the system to understand how it was compromised and help the organization avoid future breaches. Best practice is for the incident response plan to define how these complicated situations should be handled, meaning it should identify which party has more authority to make the proper steps occur. We lean toward giving the forensics team higher authority, but the choice depends on the business and situation.

When should an IRT claim it has achieved proper containment? This question can be extremely tricky to answer, and we have seen situations in which the IRT thought an incident was contained but later found more systems showed up as compromised with the same or a new malicious variant after the case was reported closed. Why do these teams fail? In many cases, they don’t understand the true scope of the breach before attempting to contain it, or they have a false sense of containment. This could happen due to a disconnect between what the forensics investigation found or people did not recognize the importance of certain information. An example is misunderstanding which system was initially infected to identify the exploit used to breach the network before the malicious software spread laterally within the network. Incident response teams must understand the full scope of the breach to contain it, which typically includes understanding the full life cycle of the attack. We covered this concept in Chapter 2, “Cybercrime and Defenses,” when we talked about the Cyber Kill Chain Model. Forensic specialists can provide valuable information to the rest of the IRT team by examining logs, traffic, and systems to gain insight on the full scope of a breach. Our recommendation is to have a member or group with forensics expertise be responsible for identifying when an incident is properly contained. This book is designed to help you be part of that team!

To fully understand how to scope an incident, the forensic specialist must identify a few things:

1. What are the device types that may potentially contain evidence?

2. What are the operating system and software running on the devices?

3. What are the network communication capabilities of the device, and what does normal network traffic from those devices look like?

4. How are the devices connected, and what devices can they talk to?

5. What are the available logs on the system, and is it possible to tell if they have been modified?

6. What is the timeline of the incident, and where did it begin?

7. How critical or how sensitive is the data associated with the device?

After these questions have been answered, forensic investigators can normally proceed to preserving evidence and assessing the severity and extent of the breach.

How do you assess the severity of a breach? There a few quantifiable methods that investigators can use:

Number of records stolen

Number of customers affected

Number of geographical regions affected

Difficulty of acquiring stolen data

Difficulty of breach containment

Difficulty of system security

These high-level methods help put a dollar amount on things, which is part of the process to determine how large a breach may have been. However, you must look beyond just the number of records or other basic numbers to determine the extent of the breach. The Sony Pictures attack in 2014 affected a relatively small number of records but at the time had extremely wide implications. It forced Sony to forgo mass release of the movie The Interview, in part because of the attack, which possibly led to millions of dollars’ worth of losses.

As a cyber forensics investigator, you will likely need to understand what type of information may have been accessed during an incident and the potential value of that information accessed. Then you will need to determine whether exfiltration of the data occurred. To do this, you will need to notify one or more different parties of your findings.

Regarding external notification procedures, the first thing to understand is that they may be governed by several laws and compliance regulations. Generally, federal and regulatory laws supersede all other requirements, so you may not want to disclose certain information but may be legally required to do so. Additionally, investigators generally need to take the cumulative and most transparent approach to procedures. Take, for example, California, which passed legislation in 2002 that required more transparency and notifications for breaches affecting California residents. The laws effectively forced organizations to deal with transparency around breaches to all their customers. The interesting aspect of this case is that federal law did not require certain types of disclosures, but state law enforced this practice. Typically, federal law in the United States supersedes state law, but the organizations in California are impacted harder by the state law in this example. It is important to understand and consider how exposure laws are viewed where your organization is located.

To generalize disclosure laws, they typically follow this order of precedence:

1. Federal law supersedes state law.

2. State law supersedes city/county laws.

3. City/county laws supersede organization/company guidelines.

4. Organization/company guidelines govern cyber forensic investigation procedures.

Finally, in some cases immediate disclosure must be made and law enforcement must be engaged, regardless of laws or jurisdiction. These cases normally involve anything that may pertain to endangerment issues or threats or acts that affect national security. You will probably know when these situations occur due to the legal and federal groups that want to get involved. Also, some laws may force you to disclose more data than what was likely lost. In these situations, the forensic investigator highlights areas that were likely exposed to the breach. Sometimes a law states that if breached systems were able to reach other networks, all those systems must also be reported as compromised even though there isn’t evidence suggesting they were compromised. This is why some breaches that go public state large amounts of data being lost. The reality could be a lot less data; however, certain laws force the organization to include any system that could be reached by the identified breached systems.

We have focused heavily on external notification, but internal notification for an incident is just as important. Internal notification keeps stakeholders informed of all procedures and helps employees understand what occurred and what they should and should not disclose about a situation. We recommend a schedule, as described earlier, be set to keep internal teams notified of updates. In many cases, an IRT may have a dedicated communications person assigned to handle updates.

It is important that, as an investigator, you report the findings and do not make conclusions based on assumptions or beliefs you may have. Professional investigators have a level of detachment from their reports and focus on only reporting the facts. If you need to make a conclusion, make sure the evidence supports the claim, rule out alternate theories, and provide solid reasoning for your conclusion.

The basic rules of disclosing forensics findings should include the following:

1. If there is clear fault, even if it is on the company’s side, be open and help the company accept responsibility.

2. Sometimes there is no right answer, and proper evidence cannot be collected or is not available. It is okay to not walk away with the “smoking gun.” If you have the skills and understand the forensic tools, you will have some results to document, even if those results prove or do not prove your case.

3. Educate your clients, management, and other people who may read your work on how to mitigate the problem and avoid future issues.

Typically, forensic results and reports are developed using specific software that is different from incident response applications. Most logging and management software, when configured correctly, are the primary tools used for incident response. This includes SIEMs, log management, trend analysis, and other tools. Most network engineers have some experience using these types of tools. Auditors use other tools, such as Nessus, when testing web applications. To help you understand which tools are right for different aspects of an incident response program, we cover general tool categories next.

Incident response teams can implement threat intelligence management platforms such as Anomaly and Threat Connect, and use those trends and advanced analytics to investigate security events. One popular tool used in these types of investigations is the Cisco Stealthwatch product. We cover this tool in Chapter 11, “Cisco Forensic Capabilities.”

Regardless of the products selected, security analytics reference architectures are designed with some common components that are found across multiple vendors. They typically collect system logs and full-packet captures, which are collected on large storage arrays in searchable Big Data Hadoop–based clusters. These systems—in a very basic, oversimplified explanation—take existing log and packet data and highlight any anomalous-based outliers. They also correlate security logs from multiple devices to give analysts a more complete picture of the situation by ingesting multiple external threat feeds from third parties and locally. Figure 4-6 shows the main dashboard of RSA Security Analytics. Other products that are considered to provide complete security reference architectures include IBM’s QRadar and HawkeyeAP.

Security incident responders can view, analyze, and replay an entire traffic session when investigating an incident. If a corporation is worried that data may have been leaked, the software package can not only confirm a leak did or did not happen but also allow an investigator to view the exact contents of the leak. If threat intelligence feeds learn about a new threat, that intelligence can be applied retroactively to data previously collected. Figure 4-7 is an example showing potential data leakage.

Figure 4-7 shows a threat feed provided new information about malware communication protocols. A security analytics reference architecture is able to retroactively look at past data to determine if the threat was or had existed within the organization. In this example, the threat did exist, and 169 events were detected.

In this example, incident response team members can use this data and turn it into an incident, thus engaging the appropriate response. The solutions should incorporate workflows and integrate with external governance, risk management, and compliance (GRC) software solutions if available.

One of the biggest downsides with Security Reference architectures is the cost required to purchase, install, and maintain the system. There is a very high cost of keeping the tremendous amounts of detailed logs and full-packet captures required to use most data analytics tools. This includes the requirements for additional costs to maintain growing storage needs and training staff to effectively use the program.

Another challenge that impacts the value of these solutions is that the data must be readable. Newer attacks are utilizing encryption, and encrypted traffic cannot be analyzed for threats. (This applies to technology available at the time of this writing. Cisco recently announced some changes to this concept with Cisco Encrypted Traffic Analytics [ETA].) Many security analytics solutions have workarounds to analyze encrypted data, such as SSL Intercept and man-in-the-middle techniques. This concept works when the security devices sit between the internal network and users, and literally break the connection and encryption to examine and analyze it. This can cause quite a bit of complexity in implementing these types of solutions.

We have just begun to touch on the tool categories available. Keep in mind that these are specifically related to tools used by network engineers when providing the IRT with data when responding to breaches. We look at some more technical aspects of using tools and collecting forensic evidence in later chapters. Chapter 13 summarizes all the tools from this book and provides other technology we find useful for forensics and incident response purposes.

As a network and digital forensics specialist, you likely will be involved in this process. You may be involved in only a small portion or a subset of a response process. Your role may be more technical or more managerial, but it is important to understand the full process that organizations go through in responding to a breach to be fully prepared for your own specific function.

This chapter should have given you an understanding from a management point of view how an incident response process is built. Your primary job as a network engineer is using your technical skills to provide support throughout this process. In the next chapter, we look at the details required to accomplish incident response and forensic tasks.

https://thenextweb.com/insider/2012/09/09/why-companies-bad-responding-data-breaches/

https://techcrunch.com/2017/02/21/verizon-knocks-350m-off-yahoo-sale-after-data-breaches-now-valued-at-4-48b/

https://www.reddit.com/r/technology/comments/6emqwz/password_manager_onelogin_admits_data_breach_in/

https://www.fool.com/investing/general/2014/05/27/ebay-data-breach-response-teaches-everyone-how-not.aspx

http://www.latimes.com/business/technology/la-me-ln-hollywood-hospital-bitcoin-20160217-story.html