±Forensic Focus Partners
New Today: 2
New Yesterday: 4
±Forensic Focus Partner Links
· SQLite Database Forensics – ‘Sleep Cycle’ Case Study
· Data Recovery As A Medium For Email Forensics
· Carving out the Difference between Computer Forensics and E-Discovery
· Forensic Analysis of SQLite Databases: Free Lists, Write Ahead Log, Unallocated Space and Carving
· How Secure Is Your Password? A Friendly Advice from a Company That Breaks Passwords
· Using SQL as a date/time conversion tool
· Forensics and Bitcoin
· Investigation and Intelligence Framework (IIF) – an evidence extraction model for investigation
· Extracting data from dump of mobile devices running Android operating system
The Forensic Chain of Evidence ModelBack to top Back to main Skip to menu
The Forensic Chain of Evidence Model
Improving the Process of Evidence Collection in Incident Handling Procedures
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.
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.