Transcript BBN Technologies

Applications that Participate in their Own
Defense (APOD)
BBN Technologies
QuO
FTN PI Meeting
16-19 January 2001
18 January 2001
page 1
BBN Technologies
Contract Overview
•
•
•
•
Start: July 1999
Finish: July 2002
Agent: Patrick Hurley, AFRL
Participants (BBN Technologies):
–
–
–
–
–
–
18 January 2001
Franklin Webber, PI (formerly cleared to SECRET)
Partha Pal
Chris Jones
Tom Mitchell
Michael Atighetchi
Paul Rubel
page 2
BBN Technologies
Long-Term Vision
Systems with more survivability, built with less effort.
• 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.
18 January 2001
page 3
BBN Technologies
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.
18 January 2001
page 4
BBN Technologies
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
18 January 2001
page 5
BBN Technologies
Security Domains: Example
domain
host
host
host
router
host
router
host
host
domain
domain
replicas of application component 1
18 January 2001
page 6
replicas of applicationBBN
component
Technologies2
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
18 January 2001
page 7
BBN Technologies
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)
18 January 2001
page 8
BBN Technologies
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
18 January 2001
page 9
BBN Technologies
A Classification of Defense Mechanisms
Overcome
Workaround
Guard
Use application Retry, use
level adaptivity local calls
Choose
Increase selfalternate server, checking
degrade service
Use QoS
Reserve
Migrate replicas Tighten
Management
bandwidth,
access
CPU
controls
Use Gateways
Block IP
Change
Strengthen
sources
protocols, ports encryption,
change keys
Table is open to expansion:
•more strategies
•more columns
18 January 2001
page 10
BBN Technologies
Defense-Enabled Application Competes
With Attacker for Control of Resources
Attacker
C
r
y
p
t
o
Application
QoS Management
OSs and Network
IDSs
Firewalls
Raw Resources
CPU, bandwidth, files...
18 January 2001
page 11
BBN Technologies
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.
18 January 2001
page 12
BBN Technologies
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 alternate
operating conditions and how QoS should depend
on 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)
18 January 2001
page 13
QuO
BBN Technologies
Simplified DOC Model (CORBA)
Client
Logical Method Call
ORB Proxy
Object
Application
Developer
ORB Proxy
Mechanism
Developer
Obj Req Broker
Obj Req Broker
Network
Client
18 January 2001
Network
page 14
Server
BBN Technologies
QuO adds specification, measurement, and
adaptation into the object model
Logical Method Call
Client
SysCond
Delegate
Contract
SysCond
Contract
ORB Proxy
Application
Developer
SysCond
SysCond
SysCond
SysCond
Object
Delegate
QuO
Developer
SysCond
Mechanism/Property
Manager
Specialized ORB
ORB Proxy
Mechanism
Developer
Specialized ORB
Network
Client
18 January 2001
Network
page 15
Server
BBN Technologies
The QuO Toolkit provides tools for building
QuO applications
Connector Setup
Language (CSL)
Contract Description
Language (CDL)
Structure Description
Language (SDL)
• Quality Description Languages
(QDL)
CORBA IDL
Delegates Contracts
Connectors
Code
Generators
QuO Runtime
– 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
18 January 2001
page 16
BBN Technologies
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 NEW!
• use OO-DTE (NAI) for adaptive access control
policy and policy management
• use RSVP for bandwidth management
18 January 2001
page 17
BBN Technologies
Accomplishments II
• integrate intrusion detection systems (IDSs) to
trigger adaptation
– Tripwire
– Snort
• use IPchains (Linux) for configurable packet
filtering
NEW!
• implement TCP, UDP port hopping to evade attacks
on communication
– dynamic configuration of IPchains
• enhance QuO middleware to allow time-driven
adaptation
18 January 2001
page 18
NEW!
BBN Technologies
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
–
–
–
–
18 January 2001
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
page 19
BBN Technologies
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
18 January 2001
page 20
BBN Technologies
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
18 January 2001
page 21
BBN Technologies
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
18 January 2001
page 22
BBN Technologies
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
18 January 2001
page 23
BBN Technologies
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 staff
that could be used for running attacks against APOD defenses.
We proposed a TIC experiment for APOD validation.
•Hypothesis: the application-level defensive adaptation
in an APOD application significantly increases the work
needed to damage or destroy that application
18 January 2001
page 24
BBN Technologies
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
18 January 2001
page 25
BBN Technologies
Schedule
Proof of
Concept
SW Release
0.0
July 1999
Start
Defense-Enabled App
SW Releases
1.0
1.1
Final
Survivability
Tools
Delivery
2.0
July 2000
3.0
July 2001
In-house,
planned
July 2002
Finish
TIC
Validation Experiment
Technical Reports
18 January 2001
page 26
BBN Technologies