< Day Day Up > 


Not all the evidence on a system is going to last very long. Some evidence is residing in storage that requires a consistent power supply; other evidence may be stored in information that is continuously changing.[i] When collecting evidence, you should always try to proceed from the most volatile to the least. Of course, you should still take the individual circumstances into account—you shouldn’t waste time extracting information from an unimportant/unaffected machine’s main memory when an important or affected machine’s secondary memory hasn’t been examined.

To determine what evidence to collect first, you should draw up an Order of Volatility—a list of evidence sources ordered by relative volatility. An example an Order of Volatility would be:

  1. Registers and cache

  2. Routing tables

  3. Arp cache

  4. Process table

  5. Kernel statistics and modules

  6. Main memory

  7. Temporary file systems

  8. Secondary memory

  9. Router configuration

  10. Network topology[ii]


    Once you have collected the raw data from volatile sources you may be able to shutdown the system.

[i]John R. Vacca, The Essential Guide to Storage Area Networks, Prentice Hall, 2002.

[ii]Matthew Braid, “Collecting Electronic Evidence After A System Compromise,” Australian Computer Emergency Response Team (AusCERT (http://www.auscert.org.au), The University of Queensland, Qld 4072 Australia (mdb©auscert.org.au), ([SANS Institute, 5401 Westbard Ave. Suite 1501, Bethesda, MD 20816).], 2001.

 < Day Day Up > 

 < Day Day Up > 


When collecting and analyzing evidence, there is a general four-step procedure you should follow. Note that this is a very general outline—you should customize the details to suit your situation.

Identification of Evidence

You must be able to distinguish between evidence and junk data. For this purpose, you should know what the data is, where it is located, and how it is stored. Once this is done, you will be able to work out the best way to retrieve and store any evidence you find.

Preservation of Evidence

The evidence you find must be preserved as close as possible to its original state. Any changes made during this phase must be documented and justified.

Analysis of Evidence

The stored evidence must then be analyzed to extract the relevant information and recreate the chain of events. Analysis requires in-depth knowledge of what you are looking for and how to get it. Always be sure that the person or people who are analyzing the evidence are fully qualified to do so.

Presentation of Evidence

Communicating the meaning of your evidence is vitally important—otherwise you can’t do anything with it. The manner of presentation is important, and it must be understandable by a layman to be effective. It should remain technically correct and credible. A good presenter can help in this respect.

 < Day Day Up > 

 < Day Day Up > 


Once you’ve developed a plan of attack and identified the evidence that needs to be collected, it’s time to start the actual process of capturing the data. Storage of that data is also important as it can affect how the data is perceived.

Logs and Logging

You should be running some kind of system logging function. It is important to keep these logs secure and to back them up periodically. Because logs are usually automatically timestamped, a simple copy should suffice, although you should digitally sign and encrypt any logs that are important, to protect them from contamination. Remember, if the logs are kept locally on the compromised machine, they are susceptible to either alteration or deletion by an attacker. Having a remote syslog server and storing logs in a sticky directory can reduce this risk, although it is still possible for an attacker to add decoy or junk entries into the logs.

Regular auditing and accounting of your system is useful not only for detecting intruders but also as a form of evidence. Messages and logs from programs such as Tripwire™ can be used to show what damage an attacker did. Of course, you need a clean snapshot for these to work, so there’s no use trying it after the compromise.


Monitoring network traffic can be useful for many reasons—you can gather statistics, watch out for irregular activity (and possibly stop an intrusion before it happens), and trace where an attacker is coming from and what they are doing. Monitoring logs as they are created can often show you important information you might have missed had you seen them separately. This doesn’t mean you should ignore logs later—it may be what’s missing from the logs that are suspicious.

Information gathered while monitoring network traffic can be compiled into statistics to define normal behavior for your system. These statistics can be used as an early warning of an attacker’s actions.

You can also monitor the actions of your users. This can, once again, act as an early warning system—unusual activity or the sudden appearance of unknown users should be considered definite cause for closer inspection.

No matter the type of monitoring done, you should be very careful—there are plenty of laws you could inadvertently break. In general, you should limit your monitoring to traffic or user information and leave the content unmonitored unless the situation necessitates it. You should also display a disclaimer stating what monitoring is done when users log-on. The content of this should be worked out in conjunction with your lawyer.

 < Day Day Up >