Security Careers: A Closer Look At Digital Investigations

[This article appears as a special to Dark Reading courtesy of the(ISC)2 Advisory Board of the Americasas Executive Writers Bureau.]

No matter how good their defenses, every security team eventually finds itself facing a data compromise. Increasingly, enterprises are approaching these compromises by combining two disciplines that previously were thought of separately: incident response and digital forensics.

This combined process, called digital investigations, helps to streamline both incident response and forensics. Most organization have multiple processes that outline how an incident should be handled as well as the processes for supporting forensic methodologies. The concept of merging them together may at first seem frightening, but it shouldn’t be a re-invention of existing processes.

The National Institute of Standards and Technology (NIST) have published several documents that speak to security incident handling (SP800-61) and integrating forensics with incident response (SP800-86). These documents are publicly available on the NIST website, offering a framework and guidance to building internal digital investigation processes.

As you'll see in the NIST documentation, there are key elements that are translatable between incident handling and digital forensics. One example is event categorization: the initial assessment that must be performed when the investigator arrives on the scene.

This assessment provides the basis to determine the "fruits of crime" -- what was the target -- and the "tools of crime" -- what was used. The distinction between fruit and tool forms the starting point for analysis and conducting root cause analysis. Even after you've drawn the line around your "crime scene," however, you'll likely discover new information that expands the scope of the investigation.

The best strategy for dealing with this "scope creep" is to set a large perimeter around your crime scene and work to narrow it down by ruling out possible avenues. One approach is to utilize a spider-web technique: the concept that everything has a relationship, and a small change in one area results in a large difference elsewhere.

This technique positions the actual event at the center of the web, providing several ways to move out toward the root causes. These several inter-connected, outward data paths have all contributed to the incident as either a tool or fruit of the event, and may have direct association to another data path.

As more data is identified -- and as we move further away from the event -- we will find related data paths and associated root causes. As we move outward, some paths may reach a clear conclusion, which reduces the scope of the investigation.

As the investigation progresses and the scope of data changes, there may be multiple branches of information that requires synchronized analysis. There is no means by which an investigative team can simultaneously analyze everything. The best way to produce results quickly is to divide and conquer by creating dedicated "tiger teams" that have the appropriate skill sets to work through data quickly but thoroughly.

These "tiger teams" should be assembled on demand and must have access to critical resources in order to complete their part of the investigation. Depending on the specialization of the team, there will be a different focus on data sources and where to collect evidence.

The digital investigation process does not need to be a re-invention of forensic or incident response processes and procedures. There are several documents published by reputable organizations that can be used as a basis for integrating processes and handling different types of incidents. It is important to incorporate industry best practices into your investigative process and to draw upon industry knowledge when applying investigative techniques. Keep in mind that digital investigations are conducted when there is a breach -- the race to determine root cause(s) must be quick. The race to preserve evidence also necessitates speed. But acting fast is not always easy.

With any digital investigation, it is not uncommon to have an enormous amount of data to cull before a root cause can be found. And while the incident may have occurred on an end-user system, the scope of relevant data may often include network appliances, software, or even mobile devices.

While retrieving data from assets belonging to your own organization might be straightforward, the growing use of cloud services may complicate the picture. Your ability to retrieve data from cloud service provider (CSP) systems may prove challenging. In the cloud, there is no access to or ownership of the physical assets; numerous other organizations use the same platforms.

To help mitigate these problems work with your CPS before an incident occurs to establish service-level objectives that make the CPS an extension of your incident response team and ensure that you can collect data from the cloud provider environment using sound investigative processes.

As the investigation grows and the volume of data becomes overwhelming, it is important to cull and reduce the scope of evidentiary sources and narrow the question of what is relevant. It’s not uncommon to have a broad forensic toolset where one tool is for log analysis, another for system analysis, and so on. As investigative software continues to evolve into single-point solutions, investigators will gain access to platforms that offer even better intelligence and response tools.

Security information and event management (SIEM) platforms, for example, are an excellent technology to consolidate, store, and correlate data from multiple sources -- they can quickly reduce the amount of data related to security events. Stand-alone SIEM platforms provide a simplified view of data within the organization -- they may offer automated detection, but they often rely on manually reactive processes.

By integrating SIEM systems with automated incident response capabilities, you can reduce the manually reactive processes performed by security analysts. Based on the category of incident that has occurred, there is an immediate need to collect and preserve volatile evidence that can be lost over time, such as running processes, remote system connections, and active users. SIEM tools enable the preservation of live system data at the time an incident occurs -- a capability that can be can useful when subsequently analyzing entire systems.

Now that we have extracted relevant data from SIEM and collected volatile data through automated response capabilities, it may be time to use digital forensics as a means of recovering additional evidence. For any category of incident, there are always digital artifacts that exist in some state on end-user systems; relevant information can be extracted from sources such as event logs, registry hives, or the recycle bin.

Digital forensics generally requires some level of specialized training; however, many forensic toolkits offer a great deal of automation to identify and preserve evidence. Tightly integrated and streamlined forensic toolkits allow the security analyst to complete the initial triage while preserving the forensic evidence, leaving it to the forensic practitioner to do the heavy lifting.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.