±Partners and Sponsors

±Your Account


Nickname
Password


Forgotten password/username?


Membership:
New Today: 0
New Yesterday: 8
Overall: 26918
Visitors: 75

±Follow Forensic Focus

Join our LinkedIn group

Subscribe to news

Subscribe to forums

Subscribe to blog

Subscribe to tweets

The Forensic Chain of Evidence Model

The Forensic Chain of Evidence Model



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

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 be installed in the systems area to strengthen the user authentication procedures and supporting logs.

The main limitation of the Model is the lack of support from the event logging system underlying the operating system/network application/network. It may be necessary for administrators to implement their own monitoring and logging to supplement the standard facilities.

In addition, logs that preserve the action of a user with respect to a target file may depend on the contents of that file. If the malicious action was a modification attack then evidence of that cannot be established without the preservation of the contents before and after the attack.

The logs themselves, along with all of the sources of critical information like the timing, the security subsystem and so forth must be protected from an integrity attack.


Conclusion

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 localized (and short) chains of evidence that are difficult to relate to other chains on other computers within the same Intranet.

Administrators must be aware of the Chain-of-Evidence model in order to plan for a complete trail of evidence across information domains that exist within an intranet. This model allows administrators in their collection phase to think in terms of preserving chains of evidence as opposed to individual links that may or may not be useful in the analysis phase of the investigation. The model 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.

In practice, the main limitation of the model will be the lack of support from the event logging system underlying the operating system/network application/network. It may be necessary for administrators to implement their own monitoring and logging to supplement the standard facilities.


References

[Civie98] Civie, V. and R. Civie (1998). "Future Technologies from Trends in Computer Forensic Science." IEEE: 105-108.
[Hosmer98] Hosmer, C. (1998). Time-Lining Computer Evidence. Information Technology Conference, IEEE.
[Murray98] Murray,J. D. (1998). Windows NT Event Logging, O'Reilly & Associates.
[SANS98] (1998). Incident Handling: Step by Step, The Sans Institute.
[Sommer92] Sommer, Peter (1992), Computer Forensics: an Introduction, Compsec '92, Elsevier.
[Sommer98] Sommer, P. (1998). Intrusion Detection Systems as Evidence. RAID 98, Louvain-la-Neuve, Belgum.




--





Previous Page Previous Page (1/2)