Applications that Participate in their Own Defense (APOD)

OPX PI Meeting 2002 February 21 -- page 1

Applications that Participate in their Own Defense (APOD)

QuOQuO

Franklin Webber

BBN Technologies

OPX PI Meeting 2002 February 21 -- page 2

Project

• Sponsor: DARPA/ATO• Program: Fault-Tolerant Networks• Program manager: Doug Maughan• Project monitor: Pat Hurley (AFRL)• Period of performance: July 1999 - July 2002

OPX PI Meeting 2002 February 21 -- page 3

Technical Objective

Give any critical distributed software application an increased resistance to malicious attack:

• even though the environment in which it runs is untrustworthy;• without major modifications to its code.

Any such application is “defense-enabled”.

OPX PI Meeting 2002 February 21 -- page 4

Existing Practice/Technical Approach

• Infrastructure (operating systems, networks) on which many military applications are run is less than trustworthy– applications are vulnerable to attacks that exploit security flaws in

infrastructure

• An application that can adapt to work around the effect of attacks will offer more dependable service– a defense-enabled application is aware of its quality-of-service (QoS)

requirements and monitors its environment for QoS changes

• Metric: length of correct computation while under attack– measured in Red Team experiments and other validation

OPX PI Meeting 2002 February 21 -- page 5

A Distributed Military Application

OPX PI Meeting 2002 February 21 -- page 6

A Cyber-Attack

OPX PI Meeting 2002 February 21 -- page 7

An Abstract View

Attacker

Data Processing(Fusion,Analysis,Storage,

Forwarding,etc.)

DataUser

DataSource

OPX PI Meeting 2002 February 21 -- page 8

Traditional Security

AttackerApplication

PrivateResources

PrivateResources

LimitedSharing

Trusted OSs and Network

OPX PI Meeting 2002 February 21 -- page 9

Most OSs and Networks In Common Use Are Untrustworthy

AttackerApplication

PrivateResources

PrivateResources

LimitedSharing

OSs and Network

OPX PI Meeting 2002 February 21 -- page 10

Cryptographic Techniques Can Block (Most) Direct Access to Application

AttackerApplication

PrivateResources

PrivateResources

LimitedSharing

OSs and Network

Crypto

OSs and Network

OPX PI Meeting 2002 February 21 -- page 11

Attacker

Raw ResourcesCPU, bandwidth, files...

OSs and Network IDSs Firewalls

Firewalls Block Some Attacks;Intrusion Detectors Notice Others

Application

Crypto

OPX PI Meeting 2002 February 21 -- page 12

ApplicationAttacker

Raw ResourcesCPU, bandwidth, files...

QoS Management

Crypto

OSs and Network IDSs Firewalls

Defense-Enabled Application CompetesWith Attacker for Control of Resources

OPX PI Meeting 2002 February 21 -- page 13

QuO Adaptive Middleware Technology

QuO is DARPA Quorum developed middleware that provides:•interfaces to property managers, each of which monitors

and controls an aspect of the Quality of Service (QoS)offered by an application;

•specifications of the application’s normal and alternateoperating conditions and how QoS should dependon these conditions.

QuO has integrated managers for several properties:•dependability (DARPA’s Quorum AQuA project)•communication bandwidth

(DARPA’s Quorum DIRM project)•real-time processing

(using TAO from UC Irvine/WUStL)•security (using OODTE access control from NAI)

QuOQuO

OPX PI Meeting 2002 February 21 -- page 14

QuO adds specification, measurement, and adaptation into the distributed object model

ApplicationDeveloper

MechanismDeveloper

CLIENT

Network

operation()

in args

out args + return value

IDLSTUBS

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network

MECHANISM/PROPERTYMANAGER

operation()

in args

out args + return value

IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

ApplicationDeveloper

QuODeveloper

MechanismDeveloper

CO

RB

A D

OC

MO

DE

LQ

UO

/CO

RB

A D

OC

MO

DE

L

OPX PI Meeting 2002 February 21 -- page 15

The QuO Toolkit Supports Building Adaptive Apps or Adding Adaptation to Existing Apps

QuO Code Generator

QoS AdaptivitySpecification

QoS Management

CORBAIDL

OPX PI Meeting 2002 February 21 -- page 16

Implementing Defenses in Middleware

•for simplicity:•QoS concerns separated from functionality of application.•Better software engineering.

•for practicality:•Requiring secure, reliable OS and network support is not currently cost-effective. •Middleware defenses will augment, not replace, defense mechanisms available in lower system layers.

•for uniformity:•Advanced middleware such as QuO provides a systematic way to integrate defense mechanisms.•Middleware can hide peculiarities of different platforms.

•for reuseability•Middleware can support a wide variety of applications.

OPX PI Meeting 2002 February 21 -- page 17

Security Domains Limit the Damage From A Single Intrusion

hackeddomain

host

router

domain

host

router

domain

host

host

host

host

OPX PI Meeting 2002 February 21 -- page 18

Replication Management Can Replace Killed Processes

hackeddomain

host

router

domain

host

router

domain

host

host

host

host

application component replicas

QuO replica management

OPX PI Meeting 2002 February 21 -- page 19

Bandwidth Management Can Counter Flooding Between Routers

hackeddomain

host

router

domain

host

router

domain

host

host

host

host

QuO bandwidth management

RSVP reservation or packet-filtered link

OPX PI Meeting 2002 February 21 -- page 20

Other Defense Mechanisms

• Dynamically change communication ports• Dynamically change communication protocols

OPX PI Meeting 2002 February 21 -- page 21

Defense Strategy

• Use QuO middleware to coordinate all available defense mechanisms in a coherent strategy.

• Best current strategy has two parts:– “outrun”: move application component replicas off bad

hosts and on to good ones

– “contain”: quarantine bad hosts by limiting or blocking network traffic from them and, within limits, shutting them down

OPX PI Meeting 2002 February 21 -- page 22

Validation

• Experimentation: a defense-enabled application is attacked by professional hackers, i.e., a “Red Team”, and its performance is measured

• Modeling: properties of a defense-enabled application are measured in the lab and plugged into an abstract model of attack and defense

OPX PI Meeting 2002 February 21 -- page 23

Experimentation

• Blue Team: the technology developers– Franklin Webber, et al., BBN/Distributed Systems

• Red Team: the attackers– Steve Kaufman, et al., Sandia

• White Team: the moderators– Ken Theriault, et al., BBN/Security

– testbed preparation; experiment planning and analysis

OPX PI Meeting 2002 February 21 -- page 24

Experimentation Milestones

• October: begin weekly planning meetings• November: experiment plan outlined• December: ‘whiteboard’ experiment analysis

– all teams met at BBN

– plan for first experiment complete

• January: testbed preparation• February: conducted first experiment

– approximately one week long

OPX PI Meeting 2002 February 21 -- page 25

Multiple APOD Experiments

• ‘whiteboard’ experiment: discuss likely approaches to attack and defense without actually carrying them out

• first experiment (February)– use replication management, dynamic packet filtering,

and intrusion detection for defense; flooding is off-limits

• second experiment (TBD)– add bandwidth management; allow flooding

OPX PI Meeting 2002 February 21 -- page 26

C

BC BB

BBBB

B

SS

S

VPN/Interne

t

Experiment Control,external waypoint

router

router

router

router

LegendC: clientS: serverB: broker factory

Experiment Testbed and Test Application

OPX PI Meeting 2002 February 21 -- page 27

Whiteboard Analysis of APOD

• Red Team starts with ‘root’ privilege on one host• Intended Red Team attacks:

– ARP cache poisoning to partition network– spoofing to trigger APOD ‘containment’ strategy, leading to

self-denial-of-service– reverse engineering application components to cause

malicious application behavior

• Lessons learned for Blue Team:– network partitioning a bigger problem than expected– some changes to mechanisms and strategy

• Formulating an experiment to test the limits of the APOD ‘outrun’ strategy is difficult

OPX PI Meeting 2002 February 21 -- page 28

Results from First Experiment

• A defense-enabled application forced a highly-skilled and prepared attacker to work very hard and with no stealth against a purely automated defense to deny service

• Red Team eventually defeated APOD defenses with a combination of spoofing, ARP cache poisoning, and TCP connection flood– roughly a week of trial-and-error

– final scripted attack takes 5 minutes and sets off numerous alarms (the undefended app, in comparison, could be killed immediately in the same situation)

OPX PI Meeting 2002 February 21 -- page 29

More Results

• APOD defenses add roughly 5% to application request latency on average

• Unpredictable adaptation is good– nondeterministic placement of replicas helped

– dynamic choice of communication ports would be better

• Corrupting running application processes to cause malicious behavior was not attempted, but may be harder than it seemed at first

OPX PI Meeting 2002 February 21 -- page 30

Plans for Second Experiment

• Improve APOD strategy– TCP connection flood can be detected and responded to

– other

• Add bandwidth management mechanism– detect and respond to (data) flooding

– may use security-enhanced RSVP from NCSU to reserve bandwidth; will use dynamic packet-filtering to block floods

– use strategically-placed Linux routers

• Consider augmenting purely automatic defense with tools for operator intervention

OPX PI Meeting 2002 February 21 -- page 31

Technology Transition/Summary

• APOD defenses measurably “raise the bar” against cyber-attack, even against well-prepared attackers.

• APOD middleware encapsulates adaptive defense strategies for reuse in many applications.

• A distributed military application is sought– for testing the APOD technology against a real-world set of

requirements

– for testing how easily an existing application can be defense-enabled

– for further research to improve APOD defenses