1

Multilevel Bidirectional Damage Assessment

Peng Liu, Penn State UniversityJason Li, Information Automation Inc.

ARO Workshop on Cyber Situational Awareness Nov. 2007

GMU, Fairfax, VA

2

Multilevel Situational Awareness

Application Dependency Graph

MissionDependency Graph

Construction

AttackDatabase

Attack Graph

IDS

Attack Analysis- Alert correlation- Filtering

Attack Prediction- Reasoning- Suggested Actions

Protection Domain

Visualization

SituationalAwareness

Static Analysis

DamageAssessment

What-ifAnalysis

ActionPlanning

Root-causeAnalysis

ContainmentSuggestions

Networks and Systems Level

Network-Application IF

Application-Mission IF

Missions and Applications Level

Application Dependency Graph

MissionDependency Graph

Construction

AttackDatabase

Attack Graph

IDS

Attack Analysis- Alert correlation- Filtering

Attack Prediction- Reasoning- Suggested Actions

Protection Domain

Visualization

SituationalAwareness

Static Analysis

DamageAssessment

What-ifAnalysis

ActionPlanning

Root-causeAnalysis

ContainmentSuggestions

Networks and Systems Level

Network-Application IF

Application-Mission IF

Missions and Applications Level

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 million cascading 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

10,000 feet view of info systems

Application code

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

Application 1 Application 2 Application m… …

Bus process 1 Bus process 2 Bus process n… …

Task 1 Task 2 Task k… …

Application actions vs. environmental actions

40%20% 20% Influence Factor

20%

Inter-dependency

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 assessmentMemory cell X tainted

Instruction U

Memory cell Y Register 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

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 XProcess 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 DependencyOnly

21

Bottom-up DA: Business process level assessment

Add Control Dependencyon top oftransactionlevel 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

• ContainContain the spread of the malicious code; QuarantineQuarantine 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 extentextent 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