SUMMARY | Computer Forensics: Computer Crime Scene Investigation (With CD-ROM) (Networking Series)

< Day Day Up >

Once the data has been successfully collected, it must be analyzed to extract the evidence you wish to present and to rebuild what actually happened. As for everything, you must make sure you fully document everything you do—your work will be questioned and you must be able to show that your results are consistently obtainable from the procedures you performed.

This is where logging utilities come in. Logging utilities are vital for forensics when reconstructing the sequence of events leading up to, during, and after an attack, provided the attacker doesn’t delete the log files. Refining the firewall rules, keeping the IDS current, and reviewing the log files will be important to stay one step ahead of the bad guys.

Conclusions Drawn from Reconstructing Past Events

Computer Forensics is the principle of reconstructing the activities leading to an event and determining the answer to “What did they do?” and “How did they do it?”
Stored information can be volatile and persistent at the same time.
As you can see, collecting electronic evidence is no trivial matter. There are many complexities you must consider, and you must always be able to justify your actions.
Gathering electronic evidence is far from impossible though—the right tools and knowledge of how everything works is all you need to gather the evidence required.
Audit trails can also be used to reconstruct events after a problem has occurred.

An Agenda for Action in Reconstructing Past Events

The following is a provisional list of actions for reconstructing past events. The order is not significant; however, these are the activities for which the research would want to provide a detailed description of procedures, review, and assessment for ease of use and admissibility. A number of these reconstructing past events topics have been mentioned in passing already:

To reconstruct the events that led to your system being corrupted, you must be able to create a timeline. This can be particularly difficult when it comes to computers—clock drift, delayed reporting, and differing time zones can create confusion in abundance.
One thing to remember is not to change the clock on an affected system.
Record any clock drift and the time zone in use as you will need this later, but changing the clock just adds in an extra level of complexity that is best avoided.
Log files usually use timestamps to indicate when an entry was added, and these must be synchronized to make sense.
You should also be using timestamps—you’re not just reconstructing events, you yourself are making a chain of events that must be accounted for as well.
It’s best to use the GMT time zone when creating your timestamps because the incident may involve other time zones than your own, so using a common reference point can make things much easier.
When analyzing back-ups, it is best to have a dedicated host for the job. This examination host should be secure, clean (a fresh, hardened install of the operating system is a good idea), and isolated from any network—you don’t want it tampered with while you work, and you don’t want to accidentally send something nasty down the line.
Once the system is available, you can commence analysis of the backups. Making mistakes at this point shouldn’t be a problem—you can simply restore the back-ups again if required.
Remember the mantra—document everything you do.
Ensure that what you do is not only repeatable, but that you always get the same results.
Now that you have collected the data, you can attempt to reconstruct the chain of events leading to and following the attacker’s break-in.
You must correlate all the evidence you have gathered (which is why accurate timestamps are critical), so it’s probably best to use some graphical tools, diagrams, and spreadsheets.
Include all of the evidence you’ve found when reconstructing the attack—no matter how small it is, you may miss something if you leave a piece of evidence out.
The amount of damage that occurred with an incident can be assessed by reviewing audit trails of system activity to pinpoint how, when, and why the incident occurred.

< Day Day Up >