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