DARPA
Intrusion Tolerance by Unpredictability and Adaptation
Presented by:Partha Pal
Partha PalRon WatroFranklin WebberChris Jones
William H. SandersMichel CukierJames LyonsPrashant PandeyHari Ramasamy
David CormanJeanna Gossett
DARPA ITUA: Intrusion Tolerance byUnpredictability and Adaptation
• Goal– Develop middleware based mechanisms that significantly increase the
likelihood a distributed object-oriented application survives the attacks we consider
• Approach– Use a variety of techniques to keep the application going despite intrusion:
• Adaptation to cope with changes in environment• Redundancy to tolerate different kinds of component failures• Unpredictability to thwart attack planning and inflict delays to the attacker
• Research Agenda– Explore the complementary concepts of unpredictable adaptation and
adaptive use of hybrid-mode (crash and Byzantine) fault-tolerance in the context of IT
– Build prototype to illustrate the developed concepts and to provide a basis for further design investigation
– Evaluate effectiveness of concepts and implementation by modeling and/or experimental techniques
DARPAUnpredictable Adaptation for Intrusion
Tolerance
• Introduce uncertainty in adaptations resulting from intrusion response:– Application’s adaptive behavior (e.g. change from one server type to another)– Response of middleware services that manage QoS (e.g. change the type
and/or level of replication / communication) – Reconfiguration of system infrastructure itself (e.g. killing processes, changing
configuration of a firewall)• Expected Benefit:
– Attacks that exploit static behavior will be delayed, providing time for other mechanisms to take effect.
• Ankle-biters will be deterred (anecdotal evidence), but attack prevention is not a goal
• Dimensions of unpredictable adaptation:– How they are triggered (e.g. reactive or pro-active)– Whether they are a part of the application (in-band) or the system (out of band)– Whether they are aimed at tolerating a specific attack or used to create diversity
and stealth in general
DARPA Adaptive Hybrid-Fault Tolerant Replication for Intrusion Tolerance
• Approach– Develop dynamic replication algorithms supporting multiple failure assumptions
and dynamic switching among them – Dynamically changeable crash/Byzantine replication and communication
algorithms can aid in providing practical IT • Malicious attacks may vary in number and type of failures they cause• Exclusive use of Byzantine fault-tolerance schemes is expensive
• Function 1: Management– Receive information from: replication/communication mechanisms themselves,
IDSs, resource managers– Make (possibly unpredictable) configuration decisions: type and level of
replication, placement of replicas • Function 2: Mechanisms
– Provide replication and group communication algorithms that can dynamically change between tolerance to crash and Byzantine failures
– Allow dynamic entry/exit of replicas
DARPAExample Application: Insertion of
Embedded Infosphere Support Technologies (IEIST)
C2 Node 1
LAN LAN
UCAV
UCAV # 1Host
UCAV # 1Host
Navigation &Discovery for
F15 # 1Auto
Router for F15 # 1
ThreatAnalysis for
F15 # 1
UCAV # 1Guardian
UCAV # 1Guardian
AttackAircraft
F15 # 1Host
F15 # 1Host
TacticalData Link C2 Node 2 C2 Node 3
TacticalData LinkTactical
Data Link
UCAV
UCAV # 1Host
Attack Aircraft
F15 # 1Host
F15 # 1Host
Host Platforms
ThreatAnalysis
AutoRouter
Navigation&
Discovery
Controller
Potential GA Components
C2 Node 3
C2 Node 1
C2 Node 2 C2 Node 4
Potential GA Domains
Resource Assignment
F15 # 1Guardian
AutoRouter for F15 # 1
Navigation &Discovery for
F15 # 1Threat
Analysis forF15 # 1
ThreatAnalysis for
F15 # 1
ThreatAnalysis forUCAV # 1
ThreatAnalysis forUCAV # 1
Navigation &Discovery for
UCAV # 1Navigation &Discovery for
UCAV # 1
AutoRouter for UCAV # 1
AutoRouter for UCAV # 1
DARPA Technical Details
3 views of the ITUA technology
• Context, scope and assumptions
• Structure of application and system objects, and organization of groups in the ITUA system
• Features – Hybrid-fault replication
• Support and example– Unpredictable adaptation
• Support and example
DARPA ITUA Intrusion Model
• The ITUA intrusion model consists of– Items: terms and objects, usually abstract, that the model describes– Actions: what can happen to the items– Assumptions: constraints on the actions, expressing limits on the attacker’s
capability and properties of the environment– Specifications: desired properties to follow from the assumptions, given a
system design• Items
– Security domains• Non-overlapping; boundaries are hard for attacker to cross• Are either okay or infiltrated
– Processes• Two types
– Application processes – System processes
• Are either okay or corrupt
DARPA Application Objects and ITUA System Objects in Security Domains
Security Domain I
Security Domain III
Security Domain II
ITUA Manager
ITUA Subordinate
Replicated object o1
Replicated object o2
Replicated object o3
Non-replicated object o4
Non-replicated object o5
Host C
Host BHost E
Host AHost D Host F
DARPA Intrusion Model (Cont.)
• Actions– Start or stop a process, infiltrate a domain, corrupt a process– Processes compute, communicate
• Assumptions– A minimum time to infiltrate each domain and to find a domain containing a given kind
of process– A limit on number of concurrent attacks (i.e., only “staged attacks” are possible)– Infiltration and corruption may cause arbitrary failures and may be detected by corrupt
process behavior or by IDSs– Communication is timed asynchronous
• Example Specifications– Replication improves an application’s time to failure– Unpredictable adaptation improves time to failure under certain conditions
Further details: http://www.dist-systems.bbn.com/projects/ITUA
DARPASummary: Short Answers to the 3
Questions
• Which attacks?– Attacks that (in multiple stages)
• Infiltrate hosts and security domains • Kill or corrupt processes • Observe and adapt to defensive responses
– Attacks implemented at compile time and manifest at run time are not considered
• What assumptions?– See previous slide, assumptions involve security domains,attack stages,
detection and communication• What policies?
– High level: try to maintain integrity and service availability as long as possible • Subject to our assumptions and in the context of the attacks we consider
– Auxiliary policies: use QoS specification, constraints on adaptation based on data unlikely to be available to the attacker
• QoS managers have their own policies: e.g. governing type and number of replication, access control policy etc.
DARPA Structure of an ITUA Application Object
CORBA Object
Group Communication System
Gateway
Passive H
and
ler -S
tate Cast
Passive H
and
ler -S
table S
torage
Active H
and
ler -P
ass First
Active H
and
ler -L
eader O
nly
Active H
and
ler -M
ajority Votin
g
Protocols for
Toleratin
g only
Crash
Failu
res
Protocols for
Toleratin
g only
Arb
itrary Failu
res
Protocols for
Toleratin
g x Crash
Failu
res and
yA
rbitrary F
ailures
Application-level Control of Adaptive Middleware
Handlers for tolerating crash failuresand value failures Handler choice based on comparisonbetween computation and communication cost For passive handlers, tunable parameter of frequency of state multicast/storage
Protocols for tolerating crash and/orarbitrary failures Tunable parameter of number of crashand arbitrary failures to tolerate Dynamic switching between protocols
Middleware intercepts all object requests and responses to introduce application-level adaptive behavior If such adaptation is in response to intrusion, unpredictability can make attacker’s task harder
Interface on
Stand
ard
Netw
ork T
ransp
ort
DARPA Structure of ITUA Manager and Subordinate
Managers and subordinates are collectively responsible for • Gathering security related information• Controlling local resources and configurations for security• Replication management
Security Advising (SecAdv) and Replication Management (RepMan) are two major functional aspects
• Responsibilities are different for Managers and Subordinates
ITUA Manager
Group Communication System
Gateway
Handler forITUA Manager
SecAdv RepMan
Interfaceto standardnetwork transport
ITUA Subordinate
Group Communication System
Gateway
Handler forITUA Subordinate
SecAdv RepMan
Interface to standardnetwork transport
DARPA Organization of Managers and subordinats within a Security Domain
Manager
Subordinate
sensors
actuators
sensors actuators
Subordinate
sensors actuators
Subordinate
sensors actuators
• Sensors provide information to determine security posture– CPU monitors, network monitors, IDSs, replication mechanisms
• Actuators control external resources– Firewall, IDSs, OS controls
• Interpretation of sensed data and reaction to events depend on current security posture
DARPA Groups in the ITUA System
SecurityDomain I
Host C
Host B
Host A
SecurityDomain II
Host E
Host D
SecurityDomain III
Host F
SecurityDomain IV
Host G
SecurityDomain V
Host I
Host H
SecurityDomain VI
Host L
Host K
Host J
ITUA manager
group
ITU
Asu
bord
ina t
e gr
oup
ITU
Asu
bord
ina t
e gr
oup
ITU
A s
ubor
d ina
te g
rou p
ITU
A s
ubor
d ina
te g
rou p
ITUA
subordinate
group
ITUA
subordinate
group
a replic
ation group
DARPASupporting Adaptive Hybrid-Fault
Replication
• Part of the job of the Security Advisor and Replication Manger components of the ITUA Managers and Subordinates– Using the hybrid-fault tolerant “plumbing”
• Important Replication Manager functions – In a subordinate
• Start application objects securely when commanded by manager– In a manager
• Decide which replica of replication group to start, kill, migrate• Decide when to switch between different failure modes
• Important Security Advisor functions – In a subordinate
• Collect information from local IDS, monitors • Report to manager
– In a manager• Collect domain wide security info, decide security posture• Decide whether host/domain infiltration has occurred
DARPAExample Use of Hybrid-Fault Replication/Communication
r1
h1
r2
h2
More replicas, Byzantine-tolerance
mode
r1 r2
h1 h2Replicated object r tolerates 1 crash
Senses network anomaly
Informs manager
r1 r2
h1 h2
Three replicas, r3 placed hx picked unpredictably
r3
hx
r2
h2
Depending on domain-wide information, change security posture, increase replication level or switch to Byzantine mode
Anomaly persists, reports potential infiltration on H1 to manager
Under the new posture, decides to switch r (and other replicated object with replicas on H1) to Byzantine tolerance
r2
h2r5
hn
Subordinate on h1 Manager of h1s domain
Ready for a potential loss, attacker will first need to find where a new replica is placed
Even though the attacker corrupts r1 in an arbitrary way on the infiltrated host, the replicated object r continues: r1 is evicted from the group
On demand, adaptive use of expensive Byzantine tolerance => Practical intrusion tolerance!
DARPA Supporting Out-of-Band Unpredictable Adaptation
• Out-of-Band Adaptation– Intrusion response that involves reconfiguration of system resources
• Requires system privilege– Carried out by the hierarchy of managers and subordinates
• Via the sensors and actuators– Reconfiguration may take place proactively, subject to cost and interference
constraints
• Inserting uncertainty: use the inherent non-determinism of distributed systems– Likely that different domains will have different postures – Even within a domain different hosts may have different postures
• Recall interpretation of sensed data and reaction to observed event can depend on the current posture
DARPAExample Out-of-Band Unpredictable
Adaptation
• Attacker trying to corrupt an application object (i.e. the replication group). Uses an attack process in host H1.
• Symptom(s) observed – Anomalies in replication group of the targeted application object or its consumers– Sensors on H1 may pick up CPU or network anomalies
• Depending on current posture, H1’s subordinate may– Use firewall to control what goes out and comes into H1– Use access control mechanism to change access control policy of objects in
H1– Kill rogue process in H1
• Advantage – Attackers experience in one domain may not work in another
• May proactively reorganize resource configuration– Subject to performance and interference constraints move files around, use different
ports, change scanning interval etc in an unpredictable manner.– Limit attacker knowledge (see US Extra-net for Security Professionals)
DARPASupporting Unpredictability in Application-Level Adaptation
• Contracts: QuO’s adaptation control mechanism– Region: basis for structuring adaptation
• inter-object interaction is “adapted” in band (intercepted and modified) depending on the current region
– Transition: action on region change• Inserting uncertainty:
– Unpredictable selection of contract region
– Unpredictable selection of transition action
• Other possibilities to explore: – parameterization, switching the
evaluation engine, generating contracts on-the-fly etc.
QuO is an adaptive middleware supporting application-level (in-band) adaptation
Client Network Server
Logical Method Call Client
Delegate
ORB Proxy
Specialized ORB
ContractSysCond
SysCond
SysCond SysCond
Object
Delegate
ORB Proxy
Specialized ORB
Contract
Network
Mechanism/PropertyManager
SysCond
SysCond
SysCond
DARPA Example Application-Level Unpredictable Adaptation
Unpredictable selection of transition actions:one_of {
T1: kill all non-application/ non-essential objects on local host T2: talk to a different object T3: start a security scan T4: use cached value (I.e.don’t remote)T5: slow down (I.e. insert sleep before remote)
}
C1C3
C2Unpredictable selection of contract regions: Conceptual operating regions of an adaptive application may overlap:
C1 (Host H infiltrated), C2 (Network N infiltrated), C3 (Object O corrupt)
Under certain condition any one of the regions may be true. Advantage: If the attacker has partial knowledge about the system and wants to push the application into a desired operating region, he may be surprised to find the application behave in an unexpected way
Advantage: If the attacker observed the reaction (that muffled his stage 1) and attempts to re-attack aiming to counter or bypass that reaction, he may see a different reaction this time
There may be cases where even with limited, known alternatives, unpredictable selection is a better strategy (game theory results).
Current stage
Next stage?
T1
T2T3
T4
T5
Corrupt replica is of O, on H and H is in N
DARPA Current Status / Next Steps
• Unpredictable Adaptation– Developed examples and a conceptual framework– Working on extending the framework and a detailed use case for evaluation
• Adaptive, Hybrid-Fault Tolerant Replication / Communication Algorithms
– Developed a strategy of applying adaptive fault-tolerance– Working on algorithms that implement the strategy
• ITUA Prototype Design– Integrated security domain, replication control, and uncertainty concepts in a unified
architecture– Created high-level architecture for evaluating adaptive techniques and unpredictable
policies– Detailed designs for adaptive control and unpredictable policy mechanisms– Planning the stages in the implementation
• Modeling and Validation– Formalized the project scope and assumptions relating to attacks– Investigating ways to validate the effectiveness (via modeling and/or experimental
techniques) of ITUA techniques
DARPA Schedule/External Activities
ID Task Name1 ITUA
3 Initial Concept Dev & Proof of concept demo
4 Design & Devlp of Prototype v1
5 Final Prototype & Evaluation results
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q12000 2001 2002 2003
Proof of concept for some components expected at the end of summer
External activities:
• 19th IEEE SRDS: Panel on integrating FT and Security in Distributed Information Systems: Franklin Webber
• ISW 2000: Position paper: Partha Pal
• EU-US Joint workshop on intrusion and attack tolerance: Bill Sanders
DARPA Back up:Proposed Gateway Architecture
ApplicationObject
ApplicationObject
Application
CORBAORB
HandlerFactoryHandlerFactory
Active handlers• pass first• leader only• majority voting
Passive handlers• state cast• stable storage
Active handlers• pass first• leader only• majority voting
Passive handlers• state cast• stable storage
Handler forreplicated obj -1
Handler forreplicated obj -1
Hybrid-Fault Group Communication
Hybrid-Fault Group Communication
Gateway
Gateway handlers
Local Area Network
IIOP create handlers
Handler forreplicated obj -2
Handler forreplicated obj -2
Handler forReplicated obj -n
Handler forReplicated obj -n
CORBAORB
NamingService
Top Related