±Forensic Focus Partners

Become an advertising partner

±Your Account


Forgotten password/username?

Site Members:

New Today: 2 Overall: 36767
New Yesterday: 4 Visitors: 130

±Latest Articles

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Videos

±Latest Jobs

The Forensic Chain of Evidence Model

The Forensic Chain of Evidence Model

Improving the Process of Evidence Collection in Incident Handling Procedures
Page: 1/2

by Atif Ahmad
Department of Information Systems, University of Melbourne, Parkville, VIC 3010, Australia


This paper suggests that administrators form a new way of conceptualizing evidence collection across an intranet based on a model consisting of linked audit logs. This methodology enables the establishment of a chain of evidence that is especially useful across a corporate intranet environment. Administrators are encouraged to plan event configuration such that audit logs provide complementary information across the intranet. Critical factors that determine the quality of evidence are also discussed and some limitations of the model are highlighted.

Introduction to Computer Forensics

Computer Forensics is a relatively new field in computer science and is still undergoing a process of evolution and definition. In general computer forensics is related to evidence from or about computers that is destined for use in court, although it is also used to describe the use of computers to analyze complex data [Sommer98]. In this paper computer forensics is limited to a post-incident scenario where investigators have been called in to gather evidence for use in legal proceedings.

Forensic investigations typically consist of two phases. The first phase, known as the exploratory phase, is an attempt by the investigator to identify the nature of the problem at hand and to define what s/he thinks transpired at the scene of the incident. For example, in a hacker case the investigator may need to pinpoint the source of the break in. In a corporation with hundreds of computers and thousands of entry points this may well be a daunting task.

Once the investigator has determined what s/he thinks took place the induction ends and the deduction, i.e. the evidence phase, begins. The evidence phase revolves around the accumulation of proof admissible in court that deductively proves the conclusion of the forensic investigator made by way of induction.

The exploratory phase of the investigation tests the investigator's ability to detect patterns in what may appear to be a chaotic scenario. Each scenario consists of recurring patterns that define a commonly occurring "normal" sequence of events, like users following their usual patterns of computer/network usage, backups taking place according to their pre-determined schedule. The patterns that form this "normal" sequence of events when identified, allow the investigator to visualize any disruptions or anomalous events that may have taken place. The solution to many cases lies in these anomalous occurrences that should be marked for careful scrutiny at a later date.

Collecting Evidence in a Corporate Intranet Environment

Traditionally logging has been the primary source for documenting events happening in operating systems. Event logs aim to record significant events in the case where an incident takes place and the administrator wanted some idea of what had transpired [Murray98]. Event logging has been based on the old centralized computing model that is now largely obsolete. Sources of evidence that investigators may have at hand on a computer system include system logs, audit logs, application logs, network management logs, network traffic capture, and data regarding the state of the file system [Sommer98]. Logs are traditionally regarded as the primary record or indication of transpired activity. With the evolution from stand-alone PCs to networked systems, system logs have been complemented with network logs and traffic capture etc. to improve recording of ongoing computer activity.

In an Intranet-type environment where resources are distributed, events on one computer are frequently related to those on another. In these scenarios centralized logging leads to extremely localized (and short) chains of evidence that are difficult to relate to other chains on other computers within the same Intranet. Network traffic logging has assisted in connecting links of evidence that exist on operating systems that are related due to the use of network connectivity. In the case of malicious-use of remote commands if network traffic is recorded then it can be typically traced to a source address thereby connecting it to the computer from which the attack originated. In general there is not enough information in the event logs of the source address to identify which application initiated the network traffic and what initiated the network traffic in the first place. Specifically, intention is extremely difficult to establish in such an environment. If a user account can be linked to the use of privileges that led to the generation of malicious network traffic, the user may still claim that he/she "didn't do it". In such a case it may become necessary to provide a source of evidence that cannot be easily repudiated that identifies the identity of the user. In such a case physical access control logs or CCTV pictures may be required.

Industry standards and expert advice in the area of incident handling have traditionally limited the scope of the 'crime scene' to the computer system itself. In a corporate intranet broadening the scope to include the immediate physical work environment around the computer system will significantly improve the context of computer-based evidence. It has been well documented that the vast majority of malicious incidents that aim at harming corporate interests originate from the work environment. Including the immediate work environment surrounding computer systems will preserve the chain of evidence that has traditionally ended at the user terminal.

Next Page (2/2) Next Page