Home > Articles > Responding to a Breach

Responding to a Breach

Chapter Description

In this sample chapter from Investigating the Cyber Breach: The Digital Forensics Guide for the Network Engineer, you will explore the basic concepts for proper incident response procedure to understand why organizations commonly fail at the process when responding to a breach. The authors also share techniques used by organizations that have a successful incident response plan and provide an overview of industry-proven components required to build an incident response process within your organization.

Identifying Software Used to Assist in Responding to a Breach

This section discusses software your organization may want to invest in to assist in gathering evidence when responding to a breach. This section is not meant to encompass software you will use during your investigation. This chapter does not mention disk imaging software, registry analysis tools, password crackers, and other forensic investigation tools, for example. Don’t worry: we cover all those tools, plus many more throughout this book, and describe them in detail in Chapter 13, “Forensic Tools.” This section specifically discusses the types of software used by network engineers to assist an IRT responding to a breach.

Trend Analysis Software

Software tools like NetFlow can help an incident response team identify trends in information flow, and provide threat intelligence with visualization and discovery techniques like advanced search, threat mappings, tree maps, charts, links to blogs, and word clouds. This helps filter out inherent noise present in log data and identify important security events. Most trending software allows the administrator to save these searches for later use and even export them as reports in PDF or CSV file format. Many common SIEM products such as Splunk and others can provide this type of trend analysis. Figure 4-5 shows a Solar Winds Trend Analysis Module in its Log and Analysis toolkit.

Figure 4-5

Figure 4-5 Solar Winds Trend Analysis Module Example

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.”

Security Analytics Reference Architectures

A few words of advice: Any type of analytical software takes time to learn and usually requires a notable bit of investment. These technologies may not be the best fit for some environments. However, we have seen many global organizations that have invested in time and people run an extremely successful incident response program using this technology.

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.

Figure 4-6

Figure 4-6 RSA Security Analytics

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

Figure 4-7 RSA Security Analytics Data Leakage Example

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.

Other Software Categories

Other tool categories that incident response team members tell us come in handy fall into the range of group calibration and calendar software. Our teams mostly take advantage of open source tools or applications from Google or Microsoft. However, you may want to consider more advanced types of calibration software such as software suites from the Cisco WebEx product lines.

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.

There are currently no related articles. Please check back later.