IS 3957 Doctoral Seminar in Systems

and TechnologyInformation Assurance

Introduction

James Joshi

September 8, 2005

Access Control

Access control Restrict access to system entities to authorized personnel

Security Domain A bounded group of subjects and objects under a single

security policy

Multidomain Secure Environment Ensuring a secure interaction among participating domains

Current Systems

Single domain systems

Multidomain systems Open Interconnected Heterogeneous Systems

Web applications, E-Government, Global enterprises

DoD Business Operations Environment (Ref: JECPO)

Introduction

Example

Business Protection Environment

Operational ViewOperational View OV-1OV-1

Construction Mgmt

EngineeringAnalysis & Approval Payment/

Disbursement

Budget Planning

Personnel Admin

Auditing Transportation

Health, Safety,Environment

ProgramSch, Dir, Cont

Procurement

Oversight

Training

Adjudication

DisposalMgmt

Funds MgmtInventory Flow

Mgmt

Log Planning

MaintenancePlanning

Maintenance

TrainingDevelopment

Movement

Requirements Analysis

T&E

Facilities Mgmt

DoD Business OperationsDoD Business Operations

Warfighter Operations

Industry(various ops)

DoDBusiness Operations Environment

• Initiate a transaction• Manage a transaction• Manage reference data• Provide performance support• Control access to and protect transaction and reference data• Transmit and translate transactions and reference data

Business Protection Environment

Contract Admin

Accounting

Receiving

TechnologyProjection

Discretionary Access Control (DAC)

Subjects have ownership over objects A subject can pass access rights to other subjects

at his discretion Highly flexible and most widely used Not appropriate for

high assurance systems, e.g., a military system Many complex commercial security requirements

“Trojan horse” problem

Mandatory Access Control (MAC)

Subjects/objects have security levels forming a lattice

Flow of information is restricted. Example: (no-readup), (no-writedown)

Well-know MAC model is the Bell-LaPadula model

Some Existing Models

Abstract models HRU’s Access Control Matrix Schematic Protection Model and variation

Mandatory Confidentiality model - Bell-LaPadula Integrity model

Biba, Lipner’s, Clark-Wilson

Hybrid Chinese wall

Confidentiality Policy

Also known as information flow policy Integrity is secondary objective Eg. Military mission “date”

Bell-LaPadula Model Formally models military requirements

Information has sensitivity levels or classification Subjects have clearance Subjects with clearance are allowed access

Multi-level access control or mandatory access control

Bell-LaPadula: Basics

Mandatory access control Entities are assigned security levels Subject has security clearance L(s) = ls Object has security classification L(o) = lo Simplest case: Security levels are arranged in a

linear order li < li+1

ExampleTop secret > Secret > Confidential >Unclassified

“No Read Up”

Information is allowed to flow up, not down Simple security property:

s can read o if and only if lo ≤ ls and s has read access to o

- Combines mandatory (security levels) and discretionary (permission required)

- Prevents subjects from reading objects at higher levels (No Read Up rule)

“No Write Down”

Information is allowed to flow up, not down *property

s can write o if and only if ls ≤ lo and s has write access to o

- Combines mandatory (security levels) and discretionary (permission required)

- Prevents subjects from writing to objects at lower levels (No Write Down rule)

Categories Total order of classifications not flexible enough

Alice cleared for missiles; Bob cleared for warheads; Both cleared for targets

Solution: Categories Use set of compartments (from power set of compartments) Enforce “need to know” principle Security levels (security level, category set)

(Top Secret, {Nuc, Eur, Asi}) (Top Secret, {Nuc, Asi})

Combining with clearance: (L,C) dominates (L’,C’) L’ ≤ L and C’ C Induces lattice of security levels

Lattice of categories

{Nuc} {Eur} {Us}

{Nuc, Eur} {Nuc, Us} {Eur, Us}

{Nuc, Eur, Us}

{}

Examples of levels (Top Secret, {Nuc,Asi}) dom

(Secret, {Nuc}) (Secret, {Nuc, Eur}) dom

(Confidential, {Nuc,Eur}) (Top Secret, {Nuc}) dom

(Confidential, {Eur}) Bounds

Greatest lower, Lowest upper glb of {X, Nuc, Us} & {X, Eur,

Us}? lub of {X, Nuc, Us} & {X, Eur,

Us}?

Integrity policy

Requirements different than confidentiality policies Biba’s models

Low-Water-Mark policy Ring policy Strict Integrity policy

Lipner’s model Combines Bell-LaPadula, Biba for a more practical

software development and deployment process Clark-Wilson model

Transaction integrity Separation of duty

Biba’s Integrity Policy Model

Based on Bell-LaPadula Subject, Objects Integrity Levels with dominance relation

Higher levels more reliable/trustworthy More accurate

Information transfer path:Sequence of subjects, objects where si r oi

si w oi+1

Policies Low-Water-Mark Policy

s w o i(o) ≤ i(s) prevents writing to higher level s r o i’(s) = min(i(s), i(o)) drops subject’s level s1 x s2 i(s2) ≤ i(s1) prevents executing higher level objects

Ring Policy s r o allows any subject to read any object s w o i(o) ≤ i(s) (same as above) s1 x s2 i(s2) ≤ i(s1)

Biba’s Model: Strict Integrity Policy (dual of Bell-LaPadula) s r o i(s) ≤ i(o) (no read-down) s w o i(o) ≤ i(s) (no write-up) s1 x s2 i(s2) ≤ i(s1)

Theorem for each: If there is an information transfer path from object o1 to object on+1, then the

enforcement of the policy requires that i(on+1) ≤ i(o1) for all n>1

Requirements of Commercial Integrity Policies (Lipner)

1. Users will not write their own programs, but will use existing production programs and databases.

2. Programmers will develop and test programs on a nonproduction system; if they need access to actual data, they will be given production data via a special process, but will use it on their development system.

3. A special process must be followed to install a program from the development system onto the production system.

4. The special process in requirement 3 must be controlled and audited.

5. The managers and auditors must have access to both the system state and the system logs that are generated.

Integrity Policy: Principles of operation

Requirements induce principles of operation: Separation of Duty: Single person should not be allowed to

carry out all steps of a critical function Moving a program from Dev. to Prod. system Developer and Certifier (installer) of a program Authorizing checks and cashing it

Separation of function Do not process production data on development system

Auditing Emphasis on recovery and accountability Controlled/audited process for updating code on

production system

Permissions

RBAC (NIST Standard)

Users Roles Operations Objects

Sessions

UA

user_sessions(one-to-many)

role_sessions(many-to-many)

PA

An important difference from classical models is thatSubject in other models corresponds to a Session in RBAC

Advantages of RBAC Allows Efficient Security Management

Administrative roles to manage other roles Role hierarchy allows inheritance of permissions

Principle of least privilege Minimizes damage

Separation of Duties constraints Prevents fraud

Grouping Objects Permissions can be grouped according to a class of

objects Policy-neutrality

Provides generality

Core RBAC (relations) Permissions = 2Operations x Objects UA ⊆ Users x Roles PA ⊆ Permissions x Roles assigned_users: Roles 2Users assigned_permissions: Roles 2Permissions

Op(p): set of operations associated with permission p Ob(p): set of objects associated with permission p user_sessions: Users 2Sessions

session_user: Sessions Users session_roles: Sessions 2Roles

session_roles(s) = {r | (session_user(s), r) UA)} avail_session_perms: Sessions 2Permissions

Permissions

RBAC with General Role Hierarchy

Users Roles Operations Objects

Sessions

UA

user_sessions(one-to-many)

role_sessions(many-to-many)

PA

RH(role hierarchy)

RBAC with General Role Hierarchy

authorized_users: Roles 2Users

authorized_users(r) = {u | r’ ≥ r &(r’, u) UA) authorized_permissions: Roles 2Permissions

authorized_users(r) = {p | r’ ≥ r &(p, r’) PA)

RH Roles x Roles⊆ is a partial order called the inheritance relation written as ≥. (r1 ≥ r2) authorized_users(r1) ⊆ authorized_users(r2) &

authorized_permisssions(r2) ⊆ authorized_permisssions(r1)

Example

authorized_users(Employee)?authorized_users(Administrator)?

authorized_permissions(Employee)? authorized_permissions(Administrator)?

Administrator

Employee

Engineer

SeniorEngineer

SeniorAdministrator

Manager

px, py

p1, p2

pa, pb px, pye1, e2

px, pye3, e4

px, pye5

px, pye6, e7

px, pye8, e9

px, pye10

pm, pn

po

pp

Constrained RBAC

Permissions

Users Roles Operations Objects

Sessions

UA

user_sessions(one-to-many)

PA

RH(role hierarchy)Static

Separation of Duty

DynamicSeparation

of Duty

Static Separation of Duty

SSD 2⊆ Roles x N In absence of hierarchy

Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n) SSD, for all t ⊆RS:

|t| ≥ n ∩rt assigned_users(r)=

In presence of hierarchy Collection of pairs (RS, n) where RS is a role set, n ≥ 2;

for all (RS, n) SSD, for all t ⊆RS: |t| ≥ n ∩rt authorized_uers(r)=

Dynamic Separation of Duty

DSD 2⊆ Roles x N Collection of pairs (RS, n) where RS is a role

set, n ≥ 2; A user cannot activate n or more roles from RS What if both SSD and DSD contains (RS, n)?

Consider (RS, n) = ({r1, r2, r3}, 2)?

If SSD – can r1, r2 and r3 be assigned to u?

If DSD – can r1, r2 and r3 be assigned to u?

MAC using RBAC

L

M1

H

M2

LR

M1R

HR

M2R

H

M1W

LW

M2WRead Roles

(same lattice)Write Roles

(inverse lattice)

Transformation rules• R = {L1R, L2R,…, LnR, L1W, L2W,…, LnW}• Two separate hierarchies for {L1R, L2R,…, LnR} and { L1W, L2W,…, LnW}• Each user is assigned to exactly two roles: xR and LW• Each session has exactly two roles yR and yW• Permission (o, r) is assigned to xR iff (o, w) is assigned to xW)

Transformation rules• R = {L1R, L2R,…, LnR, L1W, L2W,…, LnW}• Two separate hierarchies for {L1R, L2R,…, LnR} and { L1W, L2W,…, LnW}• Each user is assigned to exactly two roles: xR and LW• Each session has exactly two roles yR and yW• Permission (o, r) is assigned to xR iff (o, w) is assigned to xW)

BLP

Security for Grid-based Computing Systems

Issues and Challenges

What is a Grid?

Enabling the coordinated use of geographically distributed resources — in the absence of central control, omniscience, strong trust relationships connect distributed heterogeneous high performance computer, computer cluster, large-scale database server and large-scale file server with high-speed interconnection network and integrate them into a transparent virtual high-performance computing environment.

— Ian Foster

What is a Grid?

Systems & applications that integrate and manage resources and services distributed across multiple security domains Large and dynamic pool of users and resources Sharing is highly controlled & coordinated Dynamic creation of services Form virtual organizations (VO) Collaboration is dynamic, ad-hoc Resource providers belong to different real organizations

employing different policies and mechanisms

What is a Grid?

Domain 1

VirtualOrganization

Policy

Domain 3

Domain 4Domain 2

Essentially a Dynamic Multidomain Environment

Grid Security

Globus Toolkit (GT) includes Grid Security Infrastructure (GSI) PKI to support identity mapping, single sign-on, delegation

GT2 X.509 certificate, TLS, SSL protocol Proxy certificate for delegation Community Authorization Service

GT3 – Open Grid Services Architecture (OGSA) Align Grid with web services technologies

Limitation of Classic Globus Authorization

Scalability Each personnel or policy change requires changing policy at

each participating site Authorization is done at VO as well as in each site Authorization information needs to be managed by individual

local site Expressivity

Native OS methods may not be expressive enough to support VO policies

Consistency Native OS methods at different sites may not support the same

kinds of policies

Grid Challenges

Individual hosts (resource providers) Each domain must specify highly dynamic set of access

control policies Challenges

Highly flexible access control framework (attribute-based AC)

Multi-domain problem Multiple policies need to be integrated Challenges

Multidomain challenges! Trust issues and Risk management

Secure interoperation

Challenges Expressive multi-domain policy specification

framework Automation of the integration of policies

Algorithms to detect violations and compute maximal secure interoperation

scalability? Policy negotiation Issues(trust)

Policy negotiation Issues(trust)

DelegationDelegationIdentity/Credentialmapping

Identity/Credentialmapping

Security Management Tools and techniques needed to support efficient

administration of Grid security Grid can scale to Internet size Dynamically changing resource pool

Protection objects may include Compute cycle; storage elements Sophisticate instruments Data (files and database elements) Services High level information knowledge/concepts

Dynamic pool of users with diverse credentials Identity/credential management

Policies and mechanisms evolve

Trust and Risk Management

Trust management is essential for dynamic collaboration environment Trust-based authorization

Absolute security is not possible Single point of failure situation Security assurance may vary

Grid resources may be very sensitive Trust and risk issues become very crucial Impact severity of information leaks? How to control propagation of risks?

Grid Challenges

Individual hosts (resource providers) flexible access control framework

Multi-domain problem Semantic heterogeneity & secure interoperability Security management Trust issues and Risk management

Multidomain Security

Local Policy Base

Access Control Module

Local Policy Base

Access Control Module

User’s access requests User’s authorization

Local Policy Base

Access Control Module

Local Policy Base

Access Control Module

Global Policy Base

Access Control Module

Trust-based

Tightly-coupled (Federated system)

Lightly-coupled

Application (e.g., workflow) Application (e.g., workflow)

Application (e.g. workflow)

Application (e.g., workflow) Application (e.g., workflow)

Semantic heterogeneity

Different systems may use different security policies e.g., DAC, MAC, Chinese wall, Integrity policies etc.

Variations of the same policies e.g., BLP model and its several variations

Naming conflict on security attributes Similar roles with different names Similar permission sets with different role names

Structural conflict different multilevel lattices / role hierarchies

Secure Interoperability Principles of secure interoperation

Principle of autonomyIf an access is permitted within an individual system,

it must also be permitted under secure interoperation in a multi-domain environment.

Principle of securityIf an access is not permitted within an individual

system, it must not be permitted under secure interoperation.

Interoperation of secure systems can create new security breaches

a

b

ca

b

Unsecure Interoperability

X

Y

Z

A

B C

D

X

Y

Z

A

B C

D

d

F12 = {a, b} F12 = {a, b, c, d}

1 1 22

(1) F12 = {a, b, d}Direct access

(2) F12 = {c}F12 - permitted access between

systems 1 and 2

Challenges in Secure Interoperability

How to ensure autonomy and security principles? Determining inconsistencies/incompleteness in

security rules. Identifying security holes Selecting optimality criteria for secure

interoperability: maximizing number of domains, direct accesses

Assurance and Risk Propagation & Security Management

Assurance and Risk propagation Breach in one domain can render the whole

environment insecure Cascading problem

Security Management Centralized/Decentralized Managing global metapolicy Managing policy evolution

Secret Secret

Top Secret

Confidential

FirstDowngrading

SecondDowngrading

System X

System Y

Composed System

Approaches to Multidomain Problem

Policy-Metapolicy specification framework Ad-hoc, Formal models: lattice merging, RBAC

Agent based approach (Policy agents)

Architectural approaches (CORBA, DCE)

A Multi-Domain Access Control Framework

A Multi-Phase Framework Based on RBAC model

Pre-integrationPolicy

ComparisonPolicy

ConformanceMerging/

Restructuring

Consistent, complete and optimal specification

Need external mediation policyto handle conflicts/incompleteness

Pre-integration Phase

Requires RBAC representation of arbitrary policies. A policy mapping technique is needed for non-RBAC systems.

Uses an information base Semantic information about domains including

policies, roles and attributes Integration/merging strategies to generate the

overall configuration of the multi-domain environment.

Policy Comparison and Conformance

Tools & techniques for detecting Semantic conflicts

Naming conflicts Structural conflicts

Rule conflicts Mediation policies are needed for resolution

Predefined meta-policies Domain cooperation by administrators

Tradeoffs Determine optimal/heuristic solutions secure

interoperability

[De] Merging/Restructuring

Merging/integrating policies Restructure domain policies according to the

selected optimal criteria Generate integrated global policy

Repeat policy conformance step Re-evaluation and restructuring of meta-policy

Multidomain Security

Loosely coupled environment More appropriate for open environments Mobile environments Trust-based framework

Trust managementTrust negotiationTrust models

Service oriented architecturesOO -> Component based -> Web Services

Trust

Trust Establishment

Trust establishment between strangers in open system. The client and server are not in the same security

domain. Access control decision is attribute based instead

of identity based. Examples: citizenship, clearance, job classification,

group memberships, licenses, etc. The client’s role within his home organization.

Trust Management – coined by Matt Blaze

Trust negotiation

Trust Negotiation

Goals Establish trust Maintain privacy of attributes

Process Iteratively exchange digital credentials between

two negotiating participants. Begin by exchanging less sensitive credentials Build trust gradually in order to exchange more

sensitive credentials

Digital Credentials

Digital Credentials Are the vehicle for carrying attribute information reliably Contain attributes of the credential owner asserted by the

issuer Issuer is a certification authority

Must be unforgeable Must be verifiable Digitally signed using PKI

X.509 V3 standard for public-key certificate

Credential disclosure

Credential disclosure policy (CDP) Conditions under which a party release resources Credentials it contains may be sensitive

information and should be treated as protected resources

The CDP itself could be a protected object

Requirements

Language requirements Well-defined semantics Monotonicity Credential combination (and, or) Authentication

E.g., a subject may have multiple identities/credentials Constraints on property values Intercredential constraints

e.g., compare values of different credentials of a subject Sensitive policy protection – no inference should be

allowed Unified formalism and use of interoperable language (XML)

Requirements

System requirement Credential ownership (challenge response) Credential validity Credential chain discovery Privacy protection mechanisms Support for alternative negotiation strategies

E.g., maximizing protection or considering first the computation efforts

Fast negotiation strategies

Some existing systems

Keynote trust management system Trust Establishment at Haifa Research lab

Trust Policy Language TrustBuilder Unipro Role-based trust management framework Trust-X

Comparison

Intrusion/SurvivabilityManagement

Survivability

Absolute security is not possible Hence everything bad cannot be prevented

Infrastructure for survivability needed Detection Response Recovery

Survivability Represent capability to gracefully manage system

functionality in presence of attacks and faults

Intrusion Detection/Response

Characteristics of systems not under attack: Denning: Systems under attack fail to meet one or

more of the following characteristics1. Actions of users/processes conform to statistically

predictable patterns2. Actions of users/processes do not include sequences of

commands to subvert security policy3. Actions of processes conform to specifications

describing allowable actions– Denning: Systems under attack fail to meet one or

more of these characteristics

Intrusion Detection

Idea: Attack can be discovered by one of the above being violated Automated attack tools

Designed to violate security policy Example: rootkits: sniff passwords and stay hidden

Practical goals of intrusion detection systems: Detect a wide variety of intrusions (known + unknown) Detect in a timely fashion Present analysis in a useful manner

Need to monitor many components; proper interfaces needed Be (sufficiently) accurate

Minimize false positives and false negatives

IDS Types:Anomaly Detection

Compare characteristics of system with expected values report when statistics do not match

Threshold metric: when statistics deviate from normal by threshold, sound alarm E.g., Number of failed logins

Statistical moments: based on mean/standard deviation of observations Number of user events in a system Time periods of user activity Resource usages profiles

Markov model: based on state, expected likelihood of transition to new states If a low probability event occurs then it is considered suspicious

Anomaly Detection:How do we determine normal?

Capture average over time But system behavior isn’t always average

Correlated events Events may have dependencies

Machine learning approaches Training data obtained experimentally Data should relate to as accurate normal

operation as possible

IDS Types:Misuse Modeling

Does sequence of instructions violate security policy? Problem: How do we know all violating sequences?

Solution: capture known violating sequences Generate a rule set for an intrusion signature

But won’t the attacker just do something different? Often, no: kiddie scripts, Rootkit, …

Alternate solution: State-transition approach Known “bad” state transition from attack (e.g. use

petri-nets) Capture when transition has occurred (user root)

Specification Modeling

Does sequence of instructions violate system specification? What is the system specification?

Need to formally specify operations of potentially critical code trusted code

Verify post-conditions met

IDS Systems Anomaly Detection

Intrusion Detection Expert System (IDES) – successor is NIDES Network Security MonitorNSM

Misuse Detection Intrusion Detection In Our Time- IDIOT (colored Petri-nets) USTAT? ASAX (Rule-based)

Hybrid NADIR (Los Alamos) Haystack (Air force, adaptive) Hyperview (uses neural network) Distributed IDS (Haystack + NSM)

IDS Architecture

Similar to Audit system Log events Analyze log

Difference: happens real-time - timely fashion

(Distributed) IDS idea: Agent generates log Director analyzes logs

May be adaptive Notifier decides how to handle result

GrIDS displays attacks in progress

Host 1

Agent

Host 1

Agent

Host 1

AgentNotifierNotifier

DirectorDirector

Where is the Agent?

Host based IDS watches events on the host Often uses existing audit logs

Network-based IDS Packet sniffing Firewall logs

IDS Problem

IDS useless unless accurate Significant fraction of intrusions detected Significant number of alarms correspond to

intrusions Goal is

Reduce false positivesReports an attack, but no attack underway

Reduce false negativesAn attack occurs but IDS fails to report

Intrusion Response Incident Prevention

Stop attack before it succeeds Measures to detect attacker Example: Jailing (also Honepots)

Make attacker think they are succeeding and confine to an area Intrusion handling

Preparation for detecting attacks Identification of an attack Contain attack Eradicate attack Recover to secure state Follow-up to the attack - Punish attacker

Containment

Passive monitoring Track intruder actions Eases recovery and punishment

Constraining access Downgrade attacker privileges Protect sensitive information Why not just pull the plug? Example: Honepots

Eradication

Terminate network connection Terminate processes Block future attacks

Close ports Disallow specific IP addresses Wrappers around attacked applications

Follow-Up

Legal action Trace through network

Cut off resources Notify ISP of action

Counterattack Is this a good idea?

Survivability Challenge

Piecemeal solutions exists for different components Intrusion detection [including real-time detection]

[at different architectural layer] Anomaly detection Misuse detection

Response and recovery Vulnerability analysis

Challenge is to synthesize an integrated, cost-based adoptive framework

Internet

Response data

system info/alerts

System Support/BackendSystem Support/Backend

Hubs, Switches Routers

DBMS Systems Operating Systems/System Utilities

AuthenticationAccess Control

Audit LogAudit Log

Network Layer

Authentication

Transaction LogTransaction Log

AccessControl

Business Rule BaseWorkflow policy

Business Rule BaseWorkflow policy

Application Servers

Web Servers

Information System Layer

FirewallsTraffic Log

Traffic LogNetwork access

Policy Base

Network accessPolicy Base

Service LogService Log

Application Layer

Hubs, Switches Routers

Network ServicesOffline AnalysisOffline Analysis

Offline AnalysisOffline Analysis

Offline AnalysisOffline Analysis

Access controlPolicy Base

Access controlPolicy Base

Real-timestream mining

(Intrusion Detection)

(across layers)

Real-timestream mining

(Intrusion Detection)

(across layers)

DisruptionDetection ResponseRecovery (DDRR)

(across layers)

DisruptionDetection ResponseRecovery (DDRR)

(across layers)

Survivability Framework

Monitored DataUser profiles/credentials; Transaction/activity Log

OS Audit Log, Network Service/Traffic Log

Policy BaseBusiness Rules, Access Rules

Network Policy Base

Dis

rupt

ion

Dia

gnos

is M

odul

e

Dis

rupt

ion

Con

tain

men

t Mod

ule

Dis

rupt

ion

Rec

over

y M

odul

e

Dis

rupt

ion

Tol

eran

ce M

odul

e

Cost-AdaptivityModule

System StateConfiguration, System loads

(CPU, traffic, service, etc)

Attacker Profiler Module

Parameter (P, T)Computation Module

Disruption ClassifierModule

Temporal Coverage Models

Classification &Disruption Tree

Generation Module

Vulnerability/Incident Database

Disruption Information Base

Coverage Computation

Module

Dis

rupt

ion

Det

ecti

on M

odul

e

Disruption Detection Response and Recovery

System Information

Response

Intrusion DetectionDisruption Detection

Damage AssessmentDamage Assessment

Immediate ResponseImmediate Response

GenerateIntrusion Boundary

GenerateIntrusion Boundary

IntruderIsolationIntruderIsolation

Damage ContainmentDamage Containment

Re-route Transactions

Re-route Transactions

Reduced availability

Better Availability

RecoveryRecovery

RestructureIntrusion Boundary

RestructureIntrusion Boundary

Audit logs, Real-time transaction streamsVersion information

Audit logs, Real-time transaction streamsVersion information

Short termShort term

Damage RepairerDamage Repairer

Update Original From Versions

Update Original From Versions

Long termLong term

Refine PoliciesRefine Policies

Remove Vulnerability

Remove Vulnerability

Policy BasePolicy Base

DisableServicesDisableServices

Optimization(IP)

Optimization(IP)

Disruption (Fault+Attack) Tree Root is the ultimate goal Each node is associated with the following

information Vulnerability exploits needed to achieve the goal Attacker profile indicating different attacker expertise levels Impact profile indicating directly affected objects Environmental pre-conditions and post- conditions Response strategies

Vulnerability/fault databases provide some information Vulnerability exploits objects that are affected

Disruption Tree

X

A

B C

Y

OR

ANDRetrieved from

Assistance from

Response Strategies- Containment- Recovery

VulnerabilityExploits

Attacker Profiles

Impact Profile

Environmental(Pre/Post)Condition

VulnerabilityDatabase

Disruption Tree Two key quantitative parameters

Ps(g|G): probability of the attacker achieving goal g given that the of sub-goals G have been achieved

Tm(g|G): propagation time associated with success of goal g given that set of sub-goals G have been achieved

Key factors that determine Ps and Tm. Attacker expertise level, State of the system

Modeling attacker expertise based on following factors Resources available (funds, tools, personnel, skills, etc.) Types of system access (internet access, insider/outsider) Attacker objective (financial gain, cyber-war, etc.) Risks that attacker is willing to take Time that attacker is willing to spend