applications that participate in their own defense (apod)
DESCRIPTION
Applications that Participate in their Own Defense (APOD). Franklin Webber BBN Technologies. QuO. Project. Sponsor: DARPA/ATO Program: Fault-Tolerant Networks Program manager: Doug Maughan Project monitor: Pat Hurley (AFRL) Period of performance: July 1999 - July 2002. - PowerPoint PPT PresentationTRANSCRIPT
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