BBN Technologies a part of
page 118 January 2001
Applications that Participate in their Own Defense (APOD)
BBN Technologies
FTN PI Meeting
16-19 January 2001
QuOQuO
BBN Technologies a part of
page 218 January 2001
Contract Overview
• Start: July 1999• Finish: July 2002• Agent: Patrick Hurley, AFRL• Participants (BBN Technologies):
– Franklin Webber, PI (formerly cleared to SECRET)
– Partha Pal
– Chris Jones
– Tom Mitchell
– Michael Atighetchi
– Paul Rubel
BBN Technologies a part of
page 318 January 2001
Long-Term Vision
• Future military systems need to be more survivable than the components from which they are built.
• These systems need to be designed, implemented, operated, and maintained with less (or at least no more) effort than today’s systems of comparable complexity.
Systems with more survivability, built with less effort.
BBN Technologies a part of
page 418 January 2001
Defense-Enabled Applications
• Focus on defending critical applications, not their environment.
• OS and network environment offers some protection but are flawed:– vulnerable to intrusion and cyber-attack.
• Static protection is augmented with dynamic defense: – Applications adapt their own behavior, resource usage, and
service levels and add application-level protection to remain as effective as possible in spite of attacks.
• Focus on integrity and assured service, not confidentiality.
BBN Technologies a part of
page 518 January 2001
Essential Parts of Defense Enabling
• Slow the acquisition of privileges by the attacker:– multiple security domains with independent privileges– application distributed redundantly over domains– attacks must proceed in stages; privileges cannot be acquired
in many domains at once• typically an assumption, but may be enforced
• Respond to attacker’s use of privilege:– monitor for infiltration of domains and damage to application– use privilege to isolate application from infiltration– reconfigure and adapt automatically
BBN Technologies a part of
page 618 January 2001
Security Domains: Example
domain
host
router
domainhost
hostrouter
domain
hosthost
host
replicas of application component 1
replicas of application component 2
BBN Technologies a part of
page 718 January 2001
Kinds of Privilege
• Some common privileges in application’s environment:– “root” privilege
– “user” privilege
– anonymous privilege
• Manufacture new kind of privilege for application:– authorization for interactions between application
components, and ability to start new components, issue commands to the application, or modify its functionality
BBN Technologies a part of
page 818 January 2001
Application-Level Privilege
• Use crypto to make application-level privilege hard for attacker to get, even with “root” privilege– encrypt executables on disk
– digitally sign all communication between application processes
• Implies attacker is unlikely to damage application processes other than by halting them– no “Byzantine” failures in application– a related BBNT project (under ITS) will relax this
assumption about the attacker• “Intrusion Tolerance by Uncertain Adaptation” (ITUA)
BBN Technologies a part of
page 918 January 2001
Characteristics of Adaptive Defense
• Multiple mechanisms organized into a coherent strategy for adaptation– many adaptations will involve interacting with
management subsystems in the application’s environment to collect information and request changes
– some adaptations will result in a degraded mode of operation most suitable given remaining resources
– various quality-of-service (QoS) aspects can be used to indicate possible attacks and measure the effectiveness of adaptation
BBN Technologies a part of
page 1018 January 2001
A Classification of Defense Mechanisms
Overcome Workaround Guard
Use applicationlevel adaptivity
Retry, uselocal calls
Choosealternate server,degrade service
Increase self-checking
Use QoSManagement
Reservebandwidth,CPU
Migrate replicas Tightenaccesscontrols
Use Gateways Block IPsources
Changeprotocols, ports
Strengthenencryption,change keys
Table is open to expansion:•more strategies•more columns
BBN Technologies a part of
page 1118 January 2001
ApplicationAttacker
Raw ResourcesCPU, bandwidth, files...
QoS Management
Crypto
OSs and Network IDSs Firewalls
Defense-Enabled Application CompetesWith Attacker for Control of Resources
BBN Technologies a part of
page 1218 January 2001
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.
BBN Technologies a part of
page 1318 January 2001
QuO 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
BBN Technologies a part of
page 1418 January 2001
Simplified DOC Model (CORBA)
Client Network Server
ApplicationDeveloper
MechanismDeveloper
Logical Method Call Client
ORB Proxy
Obj Req Broker
Object
ORB Proxy
Obj Req Broker
Network
BBN Technologies a part of
page 1518 January 2001
QuO adds specification, measurement, and adaptation into the object model
Client Network Server
ApplicationDeveloper
QuODeveloper
MechanismDeveloper
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
BBN Technologies a part of
page 1618 January 2001
The QuO Toolkit provides tools for building QuO applications
• Quality Description Languages (QDL)
– Support the specification of QoS contracts (CDL), delegates and their adaptive behaviors (SDL), connection, creation, and initialization of QuO application components (CSL)
– QuO includes code generators that parse QDL descriptions and generates Java and C++ code for contracts, delegates, creation, and initialization
• System Condition Objects, implemented as CORBA objects
• QuO Runtime Kernel– Contract evaluator– Factory object which instantiates
contract and system condition objects
CORBA IDL
CodeGenerators
CodeGenerators
Contract DescriptionLanguage (CDL)
Structure DescriptionLanguage (SDL)
QuO RuntimeQuO Runtime
Delegates ContractsConnectors
Connector SetupLanguage (CSL)
BBN Technologies a part of
page 1718 January 2001
Accomplishments I
• use Java Cryptography Extension (JCE)(Sun) to enforce application-level privilege
• use Proteus Dependability Manager (U of I) and Ensemble group communication (Cornell) to replicate essential application components across security domains and to tolerate crash failures
• integrate JCE enforcement with Proteus• use OO-DTE (NAI) for adaptive access control
policy and policy management• use RSVP for bandwidth management
NEW!
BBN Technologies a part of
page 1818 January 2001
Accomplishments II
• integrate intrusion detection systems (IDSs) to trigger adaptation– Tripwire
– Snort
• use IPchains (Linux) for configurable packet filtering• implement TCP, UDP port hopping to evade attacks
on communication– dynamic configuration of IPchains
• enhance QuO middleware to allow time-driven adaptation
NEW!
NEW!
BBN Technologies a part of
page 1918 January 2001
Work in Progress
• integrating RSVP bandwidth management with Proteus/Ensemble– must configure Ensemble to use TCP, not UDP
• validation– in-house testing of defense mechanisms
• upgrading to latest QuO version– based on TAO (UC Irvine, WUStl)– aspect-oriented integration of multiple QoS dimensions– requires some modification to most defense mechanisms– needed for robustness, latest versions of resource managers
BBN Technologies a part of
page 2018 January 2001
Plans: Strengthening Defense Mechanisms
• incorporate application-specific self-checking– violation of invariants used to trigger adaptation
• incorporate Ensemble security features– prevents addition of malicious group members
• replicate QoS managers, e.g., Proteus– removes single points of failure
• replace RSVP with ARQoS (NC State)– prevents use of bandwidth reservation by attacker
• user test and evaluation– will focus effort on weak points in defense
BBN Technologies a part of
page 2118 January 2001
Plans: Toolkit for Defense Strategies
• strategy specification language– allow non-APOD users to create strategies easily
– specify QoS for each mechanism for each operating mode
• automatic configuration of defense mechanisms– generate QuO-level specifications automatically
– configure non-QuO components automatically, e.g., IPchains
– resolve tradeoffs and conflicts between different QoS aspects
BBN Technologies a part of
page 2218 January 2001
Validating Defense Enabling
• Testing in-house– specific tests of individual defense mechanisms
• Experimentation at TIC– test of complete defense strategy
– attack by adversarial “Red Team”
– no longer a likely option; may be replaced by expanded in-house testing
• Technology transition to a military site– meeting site-specific requirements
BBN Technologies a part of
page 2318 January 2001
Validating Defenses by Testing
• defense enabled two different applications– separate sets of defense mechanisms, some currently
incompatible
• results:– most mechanisms work as expected
– replication management can easily be disrupted with flooding attacks
• test report forthcoming
BBN Technologies a part of
page 2418 January 2001
Validating Defenses by Experiment
Are APOD defense strategies effective?
This question cannot be answered by analysis alone:•depends on skill of attacker•depends on quality of defenses in underlying OS and network
IA’s Technology Integration Center offers facilities and staffthat could be used for running attacks against APOD defenses.We proposed a TIC experiment for APOD validation.
•Hypothesis: the application-level defensive adaptationin an APOD application significantly increases the workneeded to damage or destroy that application
BBN Technologies a part of
page 2518 January 2001
Papers
• “Defense-Enabled Applications”,
submitted to DISCEX II• “Defense-Enabled Applications: An Example”
submitted to MILCOM
• project overview, software distributions:– www.dist-systems.bbn.com/projects/APOD
BBN Technologies a part of
page 2618 January 2001
Schedule
July 1999Start
July 2000 July 2001 July 2002Finish
FinalSurvivabilityToolsDelivery
Proof ofConceptSW Release
Defense-Enabled AppSW Releases
Validation ExperimentTechnical Reports
0.0 1.0 1.1 2.0 3.0
TICIn-house,planned