Multilevel Bidirectional Damage Assessment

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. Multilevel Situational Awareness

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. 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. 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 millioncascading financial loss • Mission level semantics: the mission of protecting the national finance infrastructure is in trouble

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. 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. 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. Application code 10,000 feet view of info systems

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. Mission Decomposition Model Mission 40% Influence Factor 20% 20% Application m Application 1 Application 2 … … 20% Bus process 1 Bus process 2 … … Bus process n Inter- dependency Task 1 Task 2 … … Task k Application actions vs. environmental actions

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. 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. 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. 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. Bottom-up DA: instruction level assessment Memory cell X tainted Instruction level dependency graphs are already in the literature: -- Dynamic taint analysis (e.g., TaintCheck) -- Info flow analysis Instruction U Memory cell Y Register ebx Instruction V I/O address Z

17. Bottom-up DA: process level assessment Process X Process Y • 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 From King & Chen 2003

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. 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. Bottom-up DA: Transaction-level Assessment Data Dependency Only

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

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. 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. 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. 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. Questions? Thank you!

27. Requirements • Real-time, automated damage assessment • Assist analysts in finding root cause of a cyber attack • Accurately find damaged network and system components • 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 • What extent the damage is, and what corrective actions to take (to keep the overall enterprise operable

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