The forensic chain-of-evidence model: Improving the process of evidence collection in incident handling procedures

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. Chain-of-Evidence Model The Chain-of-Evidence Model illustrates the discrete sets of actions carried out by an insider attempting to inflict malicious damage in an intranet environment. One group of actions is separated from another, based on the level of authority required to execute them. Each group of actions has a different corresponding source of evidence that must be responsible for documenting activity for forensic purposes. However each such source of evidence must be linked to the logs next to it (see above figure) in order to form a complete chain of evidence. The figure above starts with physical access to computer systems that must precede any malicious activity. It is in this stage that the crucial link between physical recognition and computer recognition take place. Following log-on procedures the user proceeds to invoke the services of a network application that must be used as a vehicle to inflict damage on a remote system. The network application issues the malicious network traffic that reaches a remote computer and executes the intended behavior. As illustrated in the figure above, the link between each log is crucial to the establishment of a complete chain of evidence. Across all of the links the crucial factor upon which the integrity of the entire chain rests is the authenticity of the time-line. If the accuracy of the time in any of the links is questionable then the entire chain is rendered useless. Timing however is not the only pivotal factor. In the case of the link between access logs/CCTV and operating system event logs, the identification of the individual on screen and in the event log along is also important. Establishing the link between the operating system logs and the invocation of a network application can be difficult if the operating system’s event configuration did not require such events be recorded. In addition most network applications do not record user behavior within the boundaries of network application use making it difficult to record precisely how users used the network application. Another weak link is the interaction between network applications and the traffic they generate. In general there is not enough information in operating systems event logs to determine whether network traffic was directly initiated by the user or was generated by some other source like a network application running in the background. The author is in the process of researching the feasibility of a log of events that links a user session to the invocation of a network application, and the network application to the network traffic it produces. This log may improve the accountability of program behavior in a network environment. The final link between the operating system where the damage has been caused to the network traffic that caused it is a matter of identifying the network traffic that caused the damage and tracing it back to the source system where the traffic was thought to have originated. Using the Evidence Model to Improve Collection Most guides to incident handling stress the importance of documenting observations and asking the basic questions of Who, What, When and Where [Hosmer98]. Many experts have suggested that a low-level backup is made to preserve the crime scene and for further causal analysis [Civie98]. Incident handling frequently involves a distinct collection phase in anticipation of prolonged analysis. Administrators follow procedures by which evidence is collected and stored. Following the collection the systems become subject to maintenance after which attempts are made to bring systems back on line. The model in Figure 2 encourages administrators in their collection phase to think in terms of preserving chains of evidence as opposed to links of evidence that may or may not be useful in the analysis phase of the investigation. The model clearly defines a minimum number of areas in which evidence must be collected and in addition, stresses the importance of joining the links by respecting the importance of crucial factors like the accuracy of timing of each link and the quality of CCTV pictures, user identification in operating systems logs and so forth. The administrator is able to direct resources in accordance with the identified areas and links to preserve evidence. For example, in the case of an approach to or intrusion on the systems areas the CCTV picture must be clear enough to identify a face to the requirements of the law. Additional authentication systems can