Standard Forensic Methodology

Before specific tools, processes, and technological approaches are discussed, it is important to understand the basic methodology present in all digital forensic investigations. Remember, proper digital forensic techniques are important even if the end result isn't criminal or civil action.

The basic process for any digital forensic investigation should contain the following high-level steps:

1. Identify the target(s) and the time of attack, systems affected, data, or type of information to investigate (depending upon the goals of the investigation).

2. Perform preliminary investigation of running processes and very time-sensitive data (nonintrusively).

3. Perform passive network monitoring with a "network tap."

4. Replicate all data onto investigation system or workstation.

5. Analyze replicated data in an investigation environment and determine what exactly was compromised, recover deleted or hidden data, or perform other forensic investigation processes (depending upon goals of the investigation).

6. Document findings and record all operations and steps taken.

7. Restore services after correcting root-cause breach point(s), recover data, or perform other corrective actions (depending upon the goals of the investigation).

These high-level steps will be discussed in greater detail in the remainder of this section. A high-level diagram of this process follows in Figure 16-1.

Figure 16-1: High-level process diagram of investigation and recovery process

Note 

We highly recommend Kevin Mandia, Chris Prosise, and Matt Pepe's Incident Response and Computer Forensics, Second Edition (McGraw-Hill/Osborne, 2003) whose methodology is similar to that of the SANS Incident Response Process. Another great title is Hacking Exposed Computer Forensics , by Chris Davis, Aaron Philipp, and David Cowen (McGraw-Hill/Osborne, 2004). It is impossible to cover the details of the exacting science of digital forensics or the experience transfer of incident handling in one chapter, so we've tried to be as broad as possible, but provide at least some details to move you in the right direction with regard to tools and techniques. For more detail, please read these or other books that hone in on this subject matter.

Identifying Target(s) and Time of Attack, Compromise, or Areas of Interest

This may seem like an obvious step, but it is important to clearly identify the focus of the investigation; otherwise , it is easy to wander into areas that may be outside the focus of the incident. This includes identifying the system or systems that were attacked , infected, compromised, or contain information that needs to be investigated. Important factors include how the incident was reported to you, what made you aware that a compromise occurred, and what time or in what timeframe did it take place; all of these questions serve to develop a scope for the discovery process.

Without these guidelines the tendency may be to start immediately looking at all sorts of systems and data that are outside the scope or timeframe of the incident. A common occurrence in a forensic investigation is to find out that a previous attack may have taken place on a system that is not the primary concernthis might be interesting, but is often outside the scope of the issue at hand and should be addressed separately. These guidelines place a scope on the investigation effort; otherwise, it is possible it may never be completed, or may never proceed through the appropriate phases. It is akin to the software development lifecycle of many applicationsin software development, the application is never actually finished, it just keeps improving! It doesn't matter what you do, there is always something else that can be added or improved. The question is, when is it complete enough? In the case of a typical forensic identification process, the answer is, when you can positively identify all the points and potential points of attack; what was compromised, infected, or changed; and how to correct the problem. Of course, the actual scope depends on the nature of the investigation.

Note 

If there may be legal action, either criminal or civil, as a result of an investigation, the chain of custody of evidence must be preservedthe original data must be preserved intact and in a protected environment, with procedural controls to log who accessed the materials when and how. The defense will at every point be challenging where there were opportunities for tampering with, deleting, or modifying evidence.

Performing Preliminary Nonintrusive Investigation

At this point you have identified a system or systems that need to be investigated. Is there anything that can be done to investigate them nonintrusively? With most systems, there are common, nonintrusive procedures that can be performed. These are advanced techniques that require special care to investigate a system without destroying the data or modifying sensitive information.

What can you do to a system without destroying evidence? In general, it is often possible to investigate current processes that are running, the contents of memory, and the state of the network connections without modifying the file system. As long as the output is not stored on the file system, you are relatively safeat the same time, many programs write data to the file system without your knowledge. The contents of virtual memory, or memory that is swapped out to disk, may also be of interest. Special tools exist for these purposes, but are dependent upon the operating system and platforms you are using. Some examples of these tools and their usage are discussed in the "Advanced Digital Forensic Tools" section of this chapter.

Performing Passive Network Monitoring with a Network Tap

It is often useful to monitor inbound and outbound network activity of the system(s) in question using a network tap, which will allow you to audit every communication of the system passively (without alerting anyone to your investigative presence).

This process is almost always useful as it provides rich reference data during the investigation, even if it doesn't help you find the root cause of the problem. The basic architecture for performing passive network monitoring is a system (referred to as a capture host ) to collect the network traffic destined for or originating from the target's network interface. This is usually accomplished by connecting the capture host to a span or mirror port on the network switch that is duplicating the traffic being sent to (and received from) the port connecting the target host to the network. A packet capture program is then used on the capture host to store the raw network packets. Details of this setup and tools to use to investigate the traffic are discussed later in the section, "Forensic Techniques: An Example Forensic Recovery and Investigation Procedure."

Isolating the Systems from Production Use

Depending upon the goals of the investigationfor example, if recovery or investigation of a compromised filesystem is warrantedtaking the system offline may be warranted to facilitate investigation in a pristine environment. This isn't always the right approach. In some cases it may be better to set a trap (enabling additional logging, for example), or passively monitor the system to watch what services have been affected or are actively being misused. For this example we will assume that we have a break-in of some kind (which occurred sometime in the past by an internal or external user), and we need to determine how the user got in and what files or parts of the system have been accessed and if any files were modified, additional programs left behind, or other changes made. We are dealing only with this one system in this example. When dealing with multiple systems, obviously you must multiply your effort to include these systems as well. In this case, the next step, although as tough a decision as it may be sometimes, is to bring the production systems that need further investigation offlineout of production and away from typical access by users and production services.

In many situations, the best tactic for removing systems from production may be to shut down the critical applications and then disallow remote logins or disable web services, deferring these services to other backup systems (if they exist). In some cases where backup services or servers do not exist, it may include notifying your customers of maintenance. At this point, it usually is not appropriate to let your customers know you are performing an investigation on the system(s) for security reasons, as this may inform the attacker of your presence, and cause you unnecessary harm in terms of reputation or customer service issues.

Note 

This does not mean you should never inform your customers, and in fact, according to legislation in the State of California (SB-1386), you may be required to report the breach to your customers. With regard to the legal ramifications and requirements that are specific to you and your organization, however, we will defer to your legal counsel.

For UNIX systems, the best bet is to place the system in single-user mode. This is often implemented via the halt or shutdown command. Please check with your operating system documentation to confirm the correct command before proceeding.

Note 

Shutting down does result in changes to what processes are running and what is in memory, and so is probably not the best initial course of action for a live attack or where you otherwise want to preserve that kind of evidence. Again, this depends on the overall goals of your investigation.

Where possible, we recommend disconnecting the system from the network, either physically or through software controls. Generally speaking, this thwarts further aggression on the system unless the attacker is on its console. This restricts access to the system and ensures that our investigation will take place from the console only, conceivably free of external modification. Where servers or workstations don't have console connections, shut down any network interfaces that are unnecessary (disconnecting the system from the Internet), stop any processes that are normally running that are providing network services (except the ones you will be using for administration), and again prevent network logins or remote access to regular users.

From this point, you are ready to replicate all the data from the system so it may be analyzed on an investigation system or workstation.

Replicating All Data from the Target System

In this step, the goal is to make an exact copy of all data from the target system(s) so it may be analyzed in a pristine environment, which will not affect the actual production system storage. The process of performing this replication is operating system and hardware-specific. Detailed procedures will be discussed later in this chapter.

Analyzing Replicated Data and Determining Points of Compromise

This is the process of analyzing the data that was replicated, as discussed in general in the previous step. Special software applications are often required to investigate the data from the system, and in some cases, depending upon the goals of the recovery effort, tools that can read files directly from the hard drive images below the operating system level may be required. The details of performing this level of investigation using one popular open -source application are discussed later in this chapter.

Documenting Findings and Recording All Operations and Steps Taken

This is more a general process and high-level recommendation for all steps during the investigation process. Document! Document! Document! Without proper documentation, you might as well not do the investigation at all. This process includes capturing commands, steps, and results of the work performed. A trusty old-fashioned notebook is an excellent way to record the high-level steps and the process of what you are doing at each point, what you are looking for, and whyagain, critical.

In UNIX environments, all commands executed at a prompt should be recorded to a text file. Many shells automatically log commands that are executed to a text file (for example, .history files); however, they do not associate the commands with the output generated. Our favorite application for this process that records all commands and all output generated is called "script." Once the script command is executed, any commands and all the output generated are recorded to a file of your choosing. If graphical applications are used, screen captures of critical screens as well as details of output and input should be recorded as well. These screen captures can simply be stored in a common directory with numbers . These screen capture files should be referenced by name /number in the handwritten notes and logs as a record of findings.

Restoring Services After Correcting Root Cause Breach Point

Once the investigation is complete and the root cause of the security breach or the entry point is found, it is time to correct the problem(s), either by patching the system, repairing the damage, or restoring the system from a known good backup, and then finally bringing the production system back into service. It is often critical to know that you are not restoring an infected or compromised system back into service. To do this, you may need to validate all of the data and files on the filesystem and ensure they are proper and unmodifiedsometimes easier said than done. It is quite easy to back up infected or compromised files and then end up restoring them again. In almost all cases, it is easier to restore the system completely from backup tape or from a known good backup, even if that means rebuilding the operating system from vendor media, then restoring applications and data.