1. 1 Multilevel Bidirectional Damage Assessment Peng Liu, Penn State University Jason Li, Information Automation Inc. ARO Workshop on Cyber Situational Awareness Nov. 2007 GMU, Fairfax, VA

2. 2 Multilevel Situational Awareness

3. 3 Damage Assessment Aspect Goal: Develop techniques and tools to identify and assess compromised and damaged information assets Damage assessment is an indispensible part of situation awareness A computer handles only two types of information assets: data and code Network packets are data So only two things could be damaged: data or code

4. 4 But why is damage assessment still a hard problem? Observation 1: A piece of damaged data or code has different semantics at different levels Observation 2: Damage can propagate Observation 3: Damage assessment has two dimensions Time dimension Space dimension

5. 5 Observation 1: we cannot ignore semantics A data record is corrupted by SQL injection attack: Instruction level semantics: a memory unit is tainted Process level semantics: the process (code) executing the malicious SQL query is doing bad things Transaction level semantics: there is a malicious interest rate adjusting transaction, and a data record is corrupted Business process level: the interest rate management business process is causing damage Application level semantics: the loan management application is causing $80 million cascading financial loss Mission level semantics: the mission of protecting the national finance infrastructure is in trouble

6. 6 Observation 2: damage can propagate Direct damage is directly caused by intrusion actions e.g., SQL injection  a data record is modified Indirect damage is indirectly caused by damage propagation e.g., a corrupted file X is used by an innocent program to corrupt file Y No “causality”  no damage propagation Damage assessment is about identifying and tracking the relevant “causality” relationships

7. 7 Observation 3: damage assessment has two dimensions Time dimension: Reactive: what damage has already been caused Real-time: what damage is being caused Predictive: what damage would be caused in the future Reflective: why the damage was caused Space dimension: Multilevel damage assessment Bidirectional damage assessment

8. 8 Focus of this talk We focus on the space dimension  Observation 3 A main merit of multilevel, bidirectional damage assessment is that semantics can be well addressed  Observation 1 Another main merit of multilevel, bidirectional damage assessment is that cross-layer damage propagation will be tracked  Observation 2

9. 9 10,000 feet view of info systems Application code

10. 10 Threat Model Threats may come from either inside or outside of the transaction-level scope of applications Inside the scope: both insider and outsider attacks need to either directly corrupt certain data objects or get certain malicious transactions launched Outside the scope: attack actions (e.g., Witty worm) may bypass the transaction interface and corrupt some data or code via low-level (e.g., memory, file, or I/O) operations

11. 11 Mission Decomposition Model Mission Application 1Application 2 Application m … Bus process 1Bus process 2Bus process n… Task 1Task 2Task k… Application actions vs. environmental actions 40% 20% Influence Factor 20% Inter- dependency

12. 12 Multi-Level Model for Situation Awareness Layer 5: the mission layer is the top layer. Layer 4 is the application layer A mission usually involves the execution of multiple applications. Layer 3 is the business process layer A business process is a workflow instance that involves the execution of multiple tasks. Layer 2 is the task layer A task is usually a partial order of pre-specified, planned actions, e.g., transactions Layer 1 is the action layer: either application actions or environmental actions. An environmental action can be associated with the OS, the network environment, the Physical World, or other peer applications.

13. 13 Multi-Level Damage Assessment Task 1: tracking the causality relationships within each layer This capability is well addressed in the literature Task 2: tracking the causality relationships cross layers This capability is still largely missing in the literature

14. 14 Bidirectional damage assessment Bottom-up direction: Start at a lower level Then track how the damage propagates to a higher level Top-down direction: Purpose 1: forensics Purpose 2: what-if analysis e.g., to satisfy new application requirements, the admin needs to open ports, add services & registry keys, etc., how will this affect lower level damage propagation? U-shape assessment: When new lower level damage propagation channels are caused, other existing applications may be reversely affected State-of-the-art: top-down damage assessment is still largely missing in the literature

15. 15 Bottom-up Damage Assessment: one methodology Bottom level: instruction level Level 2: process/thread level Level 3: transaction level Level 4: business process level Level 5: application level Level 6: mission level

16. 16 Bottom-up DA: instruction level assessment Memory cell X tainted Instruction U Memory cell YRegister ebx Instruction V I/O address Z Instruction level dependency graphs are already in the literature: -- Dynamic taint analysis (e.g., TaintCheck) -- Info flow analysis

17. 17 Bottom-up DA: process level assessment Process dependency graphs: damage assessment (forward tracking) intrusion detection (backtracking) (a) X reads from a file (including directories, file attributes, and file names) after Y writes the file; (b) X reads from a piece of memory shared with Y; (c) Y is the parent of X (i.e., X is forked by Y); (d) X receives a message from Y through a pipe or a queue; (e) X receives a message from Y through a networking socket; (f) X receives a “signal” from Y; (g) X receives a semaphore from Y Process X Process Y From King & Chen 2003

18. 18 A quick note Process dependency graphs can be derived from instruction level dependency graphs If we know which instruction belongs to which process

19. 19 Relation to Attack Graphs Process dependency graphs and attack graphs are very different A node in an attack graph is a system attribute, while a node in a process dependency graph is a process An edge in an attack graph is an exploit, while an edge in a process dependency graph is a dependency relationship However, process dependency graphs and attack graphs can be integrated together

20. 20 Bottom-up DA: Transaction-level Assessment Data Dependency Only

21. 21 Bottom-up DA: Business process level assessment Add Control Dependency on top of transaction level graphs

22. 22 Bridges between attack graphs and dependency graphs Annotate attack graphs with the set of poisoned data (e.g., files, records) and code (e.g., threads) When a poisoned code object X involves the execution of transaction Y, add a code bridge from X  Y: Due to this bridge, Y will be marked “poisoned” in the dependency graph When a poisoned data object X is read by a transaction Y, we add a data bridge from X  Y in the dependency graph

23. 23 Bottom-up DA: Application level assessment One application runs multiple business processes; these business processes may have inter-dependencies Differences-based application-level DA Create a VEE: virtual execution environment Let the application run within a clean VEE Identify the application-level differences between the execution results within a clean VEE vs. within a contaminated execution environment

24. 24 Mission level: Quantify the impact of attacks on a mission Based on the concrete attack effects captured by attack graphs and dependency graphs: Step 1: quantify the impact of business process level effects on applications Step 2: quantify the impact of application level effects on missions Both steps rely on Mission decomposition graphs Inter-dependency among components

25. 25 Top-down Damage Assessment Purpose 1: forensics Travel through the bridges in the reverse direction One-to-many uncertainty: one consequence could be independently caused by multiple lower level events How to minimize such uncertainty is a primary challenge Purpose 2: answer what-if questions Leverage Bayesian networks

26. 26 Questions? Thank you!

27. 27 Requirements Real-time, automated damage assessment Assist analysts in finding root cause of a cyber attack Accurately find damaged network and system components ContainQuarantine Contain the spread of the malicious code; Quarantine damage Produce courses-of-action that provide continuity-of-operations for critical network and information enterprise functions. Accurate network map, visualization of where problems are from performance and security standpoints Overall view of what components/applications are down/damaged extent What extent the damage is, and what corrective actions to take (to keep the overall enterprise operable

28. 28 Multi-Level Damage Assessment Capture the direct effects of malicious non- transactional actions using instruction-level,attack graphs Capture the effects of malicious transactions using transaction-level dependency graphs and business process level dependency graphs Capture the indirect effects of malicious non- transactional actions on applications by “bridges” between level-wise dependency graphs Capture the impact of attacks on a mission using mission decomposition graphs and conditional probabilities that quantify inter-dependency