13.5 Investigation


13.5 Investigation

With the evidence in hand and the rest of the network secured from the affected systems, the process of investigation can begin. Because investigation relies on information, the first rule in investigation is to get your hands on everything you legally can as soon after the incident as you can. This means requesting logs from any remote servers as well. Due to the amount of information they collect, service providers generally do not retain information for extended periods of time. While they may not hand over the information without the involvement of law enforcement, they can at least be notified to keep a copy of a particular log until the proper permissions can be obtained. Again, training will improve the response time in this case.

The incident response team must act quickly to preserve the contents of volatile memory in affected systems, secure any logs that they are able to, including those from any network service providers they believe are relevant, image all hard drives to backup drives for analysis, and capture any relevant network traffic they can.

There are five [2] primary places that information can be stored on a computer, and each one should be considered for collection during the investigation phase. The first and most volatile piece of information is the actual memory contents of the system. Depending on the operating system, the method of capturing the state of the RAM information in a system varies, but is possible through the use of common administrative utilities such as dd in UNIX or through specialized forensic applications. The most important thing to remember while copying the RAM is that the process of copying the RAM utilizes the RAM and therefore changes the contents of this evidence. This should not discourage anyone from copying volatile information, but it should serve as a reminder that documenting all steps in the incident response process is important. If asked in court, it is a small matter to explain that the evidence presented as RAM is an accurate reflection of the state of the device during capture, with the exception of resources allocated to the copy program itself.

After RAM, there is other important information that can be lost if the computer were to be powered down. The most important of this information is both the state of running processes on the system and the state of any network connections. Both can be captured by running standard system utilities. The information here can often be the most useful in determining the cause of an incident. It is, however, not fool-proof because hacked versions of the applications can hide information about their own processes. This situation is rare enough that it is always a good idea to collect this information before powering down the system.

It should be noted that performing a live system review is not always absolutely necessary. If, for example, there is suspicion that an employee is harassing someone via e-mail, then examining the running system and network processes will not necessarily provide any useful evidence. When the cause of the incident is unknown or is network based, then this information is critical.

With the volatile information secured, the system can then be powered down and the more permanent information from the hard drives and any removable media can be obtained. The cardinal rule of collecting evidence from storage media is to always obtain and perform your analysis on a copy of the original. At all costs, modifications to the original should be avoided.

Imaging information from a production hard drive to a backup hard drive can be accomplished using either system utilities or forensic software created specifically for this task. Most of the time, a direct copy can be performed; but if it is desirable to be able to boot from the imaged drive on a remote host, then the drive geometry must be maintained.

Even when examining a copy of the original data, no changes should be made to the storage medium. Depending on the operating system, it is possible to mount or use a drive in read-only mode. This allows investigators to examine data on the drive without changing the content. Another option is to use forensic software that allows data drives to be mounted in a read-only state for examination.

Examining a large hard drive can be a very tedious process. While forensic software allows pattern searches and may even index the contents of the drive for the benefit of the forensic investigator, this functionality still requires quite a bit of time to perform an extensive analysis on a hard drive of many gigabytes. This is especially true when the investigator does not know what he or she is looking for. If inappropriate pictures or e-mails are the only target of the search, then this can be performed in short order.

If the evidence is going to be used for a criminal or civil trial — and all evidence should be collected in this manner — then steps need to be taken to show that the contents of the imaged drive are identical to the information found on the original drive. This is most often performed using hash algorithms. As we learned about cryptography, hash algorithms are often used to verify the integrity of data. The hash algorithm, commonly MD5 or SHA-1, is run against the content of the original drive and the content of the imaged drive. If the imaged drive is indeed an exact replica of the original, then the hash values should match as well. Considering that hundreds of gigabytes of data can be reduced to a single expression of 160 bits is fairly remarkable and much easier at proving integrity than manually examining the two drives.

Once all the data has been secured, it is ready for investigation. There are numerous software applications favored by forensic examiners that allow the examiner to catalog, sort, and search through the stored evidence. What the software does not provide is an inquisitive mind and an understanding of the protocols, applications, and the experience that forensics investigators acquire over time.

While what to collect may be rather straightforward, the manner in which the information is collected may make or break an investigation. Digital data suffers from the particular disadvantage that it is possible to easily change. This creates the requirement that data be collected and preserved in a particular manner.

The first such requirement is the presence of witnesses. The more people present during the acquisition of data, the better.

The second such requirement is documentation. The entire process of collecting data must be clearly documented. The easiest way for this to occur is for one person to narrate the steps they take and a second person to record those steps. Documentation includes providing the initial state of the system prior to any evidence gathering. This means recording serial numbers, all cables and hook-ups, and any screen display that is present. Providing documentary evidence such as photographs is helpful in this regard. Recording the time that each step has taken will be important in a legal case as well.

One issue that is sure to come up in any criminal investigation is the chain of custody. Because digital data can be easily modified, a defense attorney will attempt to cast doubt on the truth of the data. To avoid having your evidence thrown out, be sure to document in your incident response plan the proper rules regarding chain of custody — who had access to the data, when they had access to it, and for what reason. At a minimum, be sure that the following is recorded for all evidence collected:

  • Who collected the evidence

  • How and where the evidence was collected

  • Who took possession of the evidence

  • How the evidence was stored and protected from tampering in storage

  • Who removed evidence from storage, and why

  • Anything that can be stored in a sealable container should be stored in such

The use of evidence tags, as previously described, will help ensure that these important steps are followed.

Securing evidence is usually where most mistakes are made during the incident response process. The most common mistake is to underestimate the importance of the incident or the scope of the investigation. This causes investigators to treat collected information in a haphazard manner — behavior that cannot be reversed when it is suddenly discovered that the information is indeed important. While it has been mentioned before, the importance of documentation cannot be understated. Every command entered, and every person with access to the media must be documented. Remember that a court of law has different standards than most network administrators are used to operating with.

Other common mistakes involve failure to observe the proper chain of custody rules. This means that the evidence must be stored in a secure location, not in or on your desk, and that all access to the evidence must be recorded. Another mistake is either failing to report an incident altogether or failing to report the incident in a timely manner to either management or law enforcement. When an investigation begins, time is of the essence, especially when persons are to be interviewed or temporary information secured.

The above mistakes might be procedural in nature, but there are also a number of common technical errors. The first and most important is altering the evidence before recording the state of the evidence to a backup drive. This may mean that the file system was altered, the date and time information on programs changed, or even new programs installed during the course of the installation!

[2]Some might argue that the actual registers and cache of the CPU itself contain information. This is true, but it is not common practice to collect this information during an investigation. The crux of the problem is that the very process of trying to capture the information will change the information contained therein.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net