Digital Forensics

Digital Forensics Dr. Bhavani Thuraisingham The University of Texas at Dallas Lecture #31 Forensics Process Modeling November 12, 2007

Outline • Review of Lecture 30 • Some Optional Papers • Discussion of the papers on Process Modeling

Review of Lecture 30 • File Hound: A Forensics Tool for First Responders • http://dfrws.org/2005/proceedings/gillam_filehound.pdf • Monitoring Access to Shared Memory-Mapped File • http://dfrws.org/2005/proceedings/sarmoria_memorymap.pdf • Network Forensics Analysis with Evidence Graphs • http://dfrws.org/2005/proceedings/wang_evidencegraphs.pdf

Optional Papers (DFRWS 2007) • Analyzing multiple logs for forensic evidence (OPTIONAL) • http://dfrws.org/2007/proceedings/p82-arasteh.pdf • Massive threading: Using GPUs to increase the performance of digital forensics tools (OPTIOONAL) • http://dfrws.org/2007/proceedings/p73-marziale.pdf • Carving contiguous and fragmented files with fast object validation (OPTIONAL) • http://dfrws.org/2007/proceedings/p2-garfinkel.pdf

Abstract of “Analyzing multiple logs for forensic evidence” • Information stored in logs of a computer system is of crucial importance to gather forensic evidence of investigated actions or attacks. • Analysis of this information should be rigorous and credible, hence it lends itself to formal methods. • Authors propose a model checking approach to the formalization of the forensic analysis of logs. A set of logs is modeled as a tree whose labels are events extracted from the logs. • In order to provide a structure to these events, Authors express each event as a term of algebra. The signature of the algebra is carefully chosen to include all relevant information necessary to conduct the analysis. Properties of the model, attack scenarios, and event sequences are expressed as formulas of a logic having dynamic, linear, temporal, and modal characteristics. • Authors provide a tableau-based proof system for this logic upon which a model checking algorithm can be developed. Authors use our model in a case study to demonstrate how events leading to an SYN attack can be reconstructed from a number of system logs.

Papers to discuss (from DFRWS 2004) • How to Reuse Knowledge about Forensic Investigations Danilo Bruschi, Mattia Monga, Universit`a degli Studi di Milano http://dfrws.org/2004/day3/D3-Martignoni_Knowledge_reuse.pdf • John Lowry, BBN Systems: Adversary Modeling to Develop Forensic Observables http://dfrws.org/2004/day2/Adversary_Modeling_to_Develop_Forensic_Observables.pdf • Dr. Golden G. Richard III, University of New Orleans, New Orleans, LA: Breaking the Performance Wall: The Case for Distributed Digital Forensics http://dfrws.org/2004/day2/Golden-Perfromance.pdf

Abstract of Paper 1 • When detectives perform investigations they manage a huge amount of information, they make use of specialized skills and analyze a wide knowledge base of evidence. Most of the work is not explicitly recorded and this hurdles external reviews and training. In this paper we propose a model able to organize forensic knowledge in a reusable way. Thus, past experience may be used to train new personnel, to foster knowledge sharing among detective communities and to expose collected information to quality assessment by third parties.

Outline • Introduction • Framework • Model and Reasoning • Example • Directions

Introduction • Problems • evidence might be easily and voluntarily erased; • evidence might be easily and voluntarily forged (i.e., false evidence might be created); • evidence might be altered accidentally by daily activities (i.e., the everyday use of a system might damage evidence); • • evidence at different abstraction layers, has different meanings and properties (e.g., an html document may be considered formatted text, or a sequence of ASCII characters, or a set of blocks in the file system structure) • Solutions • produce reusable forensic knowledge to be used as support during investigations; • • organize past experience to foster knowledge sharing among forensic experts; • • record collected information in a way that ease quality assessment.

Framework • Investigative process • formulate hypotheses on the state of the world that caused the case; collect evidence on the basis of these hypotheses; correlate actual evidence with hypotheses; adjust hypotheses, and repeat the process until the consistency state of the knowledge about the case is high. • Framework • Evidence: nothing that is not clear and evident can be accepted. • Analysis: a problem that cannot be faced all at once should be decomposed in easier parts. • Synthesis: a decomposed problem has to be recomposed, but only after every part has been verified through detailed observations and considerations. • Enumeration: the whole process has to be reviewed to evaluate the soundness and completeness of the generalizations involved. Moreover, a careful revision is needed to ascertain the absence of errors and misinterpretations.

Model and Reasoning • Graph is used to represent all the knowledge acquired over the time. • Hypotheses and evidence are expressed in natural language. • To better illustrate the inductive reasoning used to prove or disprove a hypotheses a graphical formalism is used • Example: Hypotheses are represented by square, evidence collecting tests by circle and the weight of evidence by a label on the edge linking evidence to hypotheses.

Example • During a chat session a user has been caught spreading an offensive picture. After a preliminary investigation Mr. Black felt under suspicion. He has been accused of guilty because the address used by the sender to transmit the images, was, at that moment, assigned to him. • In the preliminary phase the detective, starting from the file received and the address of the sender, comes to identify Mr. Black as the criminal. Mr. Black’s computer has been seized for further analysis. • The paper formulates the root hypothesis and applies the reasoning method described.

Directions • Producing reusable knowledge, since forensic (sub-)graphs can be exploited to generate completely unrelated case graphs; • Structuring argumentation from evidence to prosecution hypotheses, since a graphical representation of the structure of the hypothesis space and the evidence support that was collected may convey, even at a glimpse, the global soundness and completeness of the information gathering; • Guiding less skilled detectives during evidence collection, since the highly specialized knowledge of experts in a field can be shared, thanks to its recording in a structured fashion.

Abstract of Paper 2 • Observables of malicious behavior in the cyber realm are derived from intuition or analysis of previous (a-posteriori) events. This creates an untenable situation where cyber defenders are unprepared for novel attacks or malicious behaviors – particularly those expected to be used by sophisticated adversaries. Development of a complete theory of observables with a particular focus on development of a-priori observables is critical to defend against computer network attack and computer network exploitation. Monitoring of a-priori observables will greatly assist in the areas of indications and warnings and attack sensing and warning. Forensic development and analysis of a-priori observables is critical to determine the type of adversary, adversary mission, and ultimately attribution.

Outline • Introduction • Threat Model • Types of Adversaries • Process Model • Adversaries and Forensics • Directions

Introduction • The current sets of cyber observables are developed after an attack or event takes place. These are termed a-posteriori observables because they follow the pattern of event—analysis—observables. • Properly specified, these observables will catch most or all repeat events or new events that use the same techniques. • These observables have no value in identifying new types of events or novel variations of known events. Since the vulnerability space is huge, defenders are forced into a responsive mode of operation. • What is needed is an additional set of observables that will permit the detection and analysis of novel events and attacks. These must be developed a-priori and follow the pattern of threat—analysis—observables.

Threat Model • Any threat model must start with analysis of adversary behavior and incorporate sufficient knowledge of the defended system. • For development of a-posteriori observables, real behaviors and real systems are used. For development of a-priori observables, hypothetical or potential adversarial behavior is modeled. • Cyber-adversaries have goals and objectives. There is a reason why the defender’s system is under attack. • Cyber-adversaries have resource limitations. • Cyber-adversaries engage in mission planning, practice, development and testing • Cyber-adversaries translate their behavior into the world of computers and networks.

Types of Adversaries: Example • Class IV First-world and certain second-world countries, including military and intelligence agencies. Future terrorist organizations. Future organized criminal groups. Some types of insider. • Class III Almost every country not in the Class IV category. Some terrorist organizations. Some organized criminal groups. Some types of insider. Some types of radical organizations. • Class II A very few countries. Many terrorist organizations. Many organized criminal groups. Many types of insider. Many types of radical groups. Very expert hackers and hacker coalitions. • Class I Some terrorist organizations. Some organized criminal groups. Many types of insider. Many types of radical groups. Beginner to journeyman hackers.

Process Model • The process model shows a high-level process model of adversary behavior. However, it can be expected that a Class IV adversary will engage in a much more detailed set of behaviors. • There is a strategic set of goals followed by assignment of missions and mission objectives. • The adversary’s strategic planning can be represented in a Warnier/Orr diagram. The goal is to identify effects that can be achieved, i.e., to identify the top-level opportunities and resources available to carry out the strategic mission. • Behavior: The adversary will study their enemy to determine what they have in place and how they operate. The adversary will develop a list of desired effects that the adversary wishes to have on their enemy. The adversary also takes an initial, high-level cut at the targets of interest.

Adversaries and Forensics • The discipline of computer forensics has been largely focused on the development of a set of tools and procedures. • However, the majority of efforts have remained at this level and not progressed to meet the challenge of Class III and Class IV adversaries. • With the resources available to these adversaries, it is not apparent that analysis of single exploits or events will help to identify and analyze the presence of these adversaries. • For example, it is understood that an adversary will not use his most valuable or sophisticated techniques or methods unless there is sufficient payoff. • Consequently, identification of Class IV adversaries must look for supporting evidence. Fortunately, the kinds of process and control exercised by this type of adversary is likely to leave such evidence.

Directions • While the development of new models and characterizations of cyber-adversaries has been informally pursued for several years and within multiple government-supported programs, the full development and presentation is made under an effort called Theory of Observables within the Proactive and Predictive Cyber Indications and Warnings contract from the Advanced Research and Development Activity (ARDA). • ARDA’s web site is located at www.ic-arda.org.

Abstract of Paper 3 • Authors make the case for distributed digital forensic (DDF) tools and provide several real-world examples where traditional investigative tools executing on a single workstation have clearly reached their limits, severely hampering timely processing of digital evidence. Based on their observations about the typical tasks carried out in the investigative process, they outline a set of system requirements for DDF software. Next, authors propose a lightweight distributed framework designed to meet these requirements and describe an early prototype implementation of it. Finally, we present some performance comparisons of single- versus multiple-machine implementations of several typical tasks and describe some more sophisticated forensics analysis techniques, which will be enabled by a transition to DDF tools.

Outline • Introduction • Requirements • Approach • Directions

Introduction • Having all of the analysis to be carried out in one location may have a performance impact • If the site is down, then the work has to be postponed • Therefore distributed digital forensics analysis may be an option

Requirements • Scalability • Platform Independence • Extensibility • Robustness

Approach • System Architecture • Based on architectures for distributed data management and/or distribted data mining • Distrubuted workload • Each node carries out a specific task, or all of the nodes carry out the same task and then the results have to be combined • Analysis • Each node carries ourt analysis and the results have to be combined

Directions • Develop a framework for DDF • Middleware for forensics analysis • Tools are integrated in a middleware environment. Appropriate tools are involved

Digital Forensics