multilevel bidirectional damage assessment

Download Multilevel Bidirectional Damage Assessment

If you can't read please download the document

Upload: chanel

Post on 22-Mar-2016

52 views

Category:

Documents


2 download

DESCRIPTION

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 . Multilevel Situational Awareness . Damage Assessment Aspect. - PowerPoint PPT Presentation

TRANSCRIPT

  • Multilevel Bidirectional Damage AssessmentPeng Liu, Penn State UniversityJason Li, Information Automation Inc. ARO Workshop on Cyber Situational Awareness Nov. 2007GMU, Fairfax, VA

  • Multilevel Situational Awareness

  • 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

  • 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

  • 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

  • Observation 2: damage can propagateDirect damage is directly caused by intrusion actionse.g., SQL injection a data record is modified Indirect damage is indirectly caused by damage propagatione.g., a corrupted file X is used by an innocent program to corrupt file YNo causality no damage propagation Damage assessment is about identifying and tracking the relevant causality relationships

  • Observation 3: damage assessment has two dimensionsTime dimension: Reactive: what damage has already been causedReal-time: what damage is being causedPredictive: what damage would be caused in the futureReflective: why the damage was caused Space dimension: Multilevel damage assessment Bidirectional damage assessment

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

  • 10,000 feet view of info systems

  • Threat ModelThreats may come from either inside or outside of the transaction-level scope of applicationsInside the scope: both insider and outsider attacks need to either directly corrupt certain data objects or get certain malicious transactions launchedOutside 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

  • Mission Decomposition ModelMissionApplication 1Application 2Application m Bus process 1Bus process 2Bus process n Task 1Task 2Task k Application actions vs. environmental actions 40%20%20%Influence Factor20%Inter-dependency

  • Multi-Level Model for Situation Awareness Layer 5: the mission layer is the top layer. Layer 4 is the application layerA mission usually involves the execution of multiple applications. Layer 3 is the business process layerA business process is a workflow instance that involves the execution of multiple tasks. Layer 2 is the task layerA task is usually a partial order of pre-specified, planned actions, e.g., transactionsLayer 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.

  • Multi-Level Damage AssessmentTask 1: tracking the causality relationships within each layerThis capability is well addressed in the literature Task 2: tracking the causality relationships cross layersThis capability is still largely missing in the literature

  • Bidirectional damage assessmentBottom-up direction: Start at a lower level Then track how the damage propagates to a higher level Top-down direction: Purpose 1: forensicsPurpose 2: what-if analysise.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

  • Bottom-up Damage Assessment: one methodologyBottom level: instruction levelLevel 2: process/thread levelLevel 3: transaction levelLevel 4: business process levelLevel 5: application level Level 6: mission level

  • Bottom-up DA: instruction level assessmentMemory cell XtaintedInstruction UMemory cell YRegister ebxInstruction VI/O address ZInstruction level dependency graphs are already in the literature:

    -- Dynamic taint analysis (e.g., TaintCheck) -- Info flow analysis

  • Bottom-up DA: process level assessmentProcess 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 XProcess YFrom King & Chen 2003

  • A quick noteProcess dependency graphs can be derived from instruction level dependency graphsIf we know which instruction belongs to which process

  • Relation to Attack GraphsProcess 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 processAn edge in an attack graph is an exploit, while an edge in a process dependency graph is a dependency relationshipHowever, process dependency graphs and attack graphs can be integrated together

  • Bottom-up DA: Transaction-level AssessmentData DependencyOnly

  • Bottom-up DA: Business process level assessmentAdd Control Dependencyon top oftransactionlevel graphs

  • Bridges between attack graphs and dependency graphsAnnotate 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 graphWhen a poisoned data object X is read by a transaction Y, we add a data bridge from X Y in the dependency graph

  • Bottom-up DA: Application level assessmentOne application runs multiple business processes; these business processes may have inter-dependencies Differences-based application-level DACreate a VEE: virtual execution environmentLet 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

  • Mission level: Quantify the impact of attacks on a missionBased on the concrete attack effects captured by attack graphs and dependency graphs:Step 1: quantify the impact of business process level effects on applicationsStep 2: quantify the impact of application level effects on missionsBoth steps rely onMission decomposition graphsInter-dependency among components

  • Top-down Damage AssessmentPurpose 1: forensicsTravel through the bridges in the reverse directionOne-to-many uncertainty: one consequence could be independently caused by multiple lower level eventsHow to minimize such uncertainty is a primary challengePurpose 2: answer what-if questionsLeverage Bayesian networks

  • Questions?

    Thank you!

  • 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

  • Multi-Level Damage AssessmentCapture 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 graphsCapture 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