IS 3957 Doctoral Seminar in Systems and Technology Information Assurance
description
Transcript of IS 3957 Doctoral Seminar in Systems and Technology Information Assurance
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