Transcript PowerPoint

Applications that Participate in their
Own Defense (APOD)
BBN Technologies
Franklin Webber, Ron Scott, Partha Pal, Michael Atighetchi,
Chris Jones, Tom Mitchell, and Ron Watro
{fwebber, rscott, ppal, matighet, ccjones, tmitchel, rwatro}@bbn.com
QuO
1
21 July 00 Joint PI Meeting
FTN
Long-term Vision
FTN
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 will be
distributed, and will:
– Assume that OS and network infrastructure is vulnerable
to intrusion and cyber-attack;
– Adapt their own behavior, resource usage, and service
levels to remain as effective as possible in spite of attacks.
Such systems are defense-enabled, and need to be designed,
implemented, operated, and maintained with less (or at least
no more) effort than today’s non-defense-enabled systems.
2
21 July 00 Joint PI Meeting
Adaptable, Defense-Enabled,
Survivable Applications
FTN
• Have multiple operating modes and a strategy for changing
modes to survive the effects of intrusion and denial of service
– some adaptations will lead to a degraded mode of operation
– most will involve interacting with management subsystems in
the application’s environment to collect information and
request changes
– most will be automatic
• Are aware of various aspects of Quality of Service (QoS) and
can recognize and react when QoS is degraded, indicating a
potential failure, intrusion, or attack
• Integrate security mechanisms, including intrusion detection
systems (IDSs), with the application and with QoS management
subsystems
3
21 July 00 Joint PI Meeting
Application and Attacker Compete
to Control System Resources
Attacker
C
r
y
p
t
o
Application
QoS Management
OSs and Network
Raw Resources
CPU, bandwidth, files...
4
21 July 00 Joint PI Meeting
FTN
IDSs
Firewalls
Levels of Attacker Privilege
•no privilege
•“login shell” privilege
•“root shell” privilege
•application privilege
Application privilege includes the ability to modify the
application or start new application components.
We assume attackers do not have application privilege.
We use cryptographic techniques to try to enforce
this assumption.
A related BBNT project (under ITS) will remove this
assumption about application privilege.
•“Intrusion Tolerance by Uncertain Adaptation”
5
21 July 00 Joint PI Meeting
FTN
Project Goals
FTN
• Formulate strategies for responding to attacks that threaten
survival of applications.
• Organize response mechanisms around a middleware
infrastructure (i.e., a software layer between the application
and the resources).
– Start with existing QuO (Quality of Service for Objects)
framework and the QoS aspects it supports;
– Extend QuO as necessary with application-centered
strategies.
• Test whether response strategies, implemented at both the
application and middleware layers and using QuO-integrated
mechanisms, enhance survivability.
6
21 July 00 Joint PI Meeting
Why Put Defenses In Middleware?
FTN
•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.
•simplicity:
•QoS concerns separated from functionality of application.
•Better software engineering.
•uniformity:
•Advanced middleware such as QuO provides a systematic
way to integrate defense mechanisms.
•Middleware can hide peculiarities of different platforms.
•reuseability
•Middleware can support a wide variety of applications.
7
21 July 00 Joint PI Meeting
QuO Technology
FTN
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)
8
21 July 00 Joint PI Meeting
QuO
Simplified DOC Model (CORBA)
Client
Logical Method Call
ORB Proxy
Object
FTN
Application
Developer
ORB Proxy
Mechanism
Developer
Obj Req Broker
Obj Req Broker
Network
Client
9
21 July 00 Joint PI Meeting
Network
Server
QuO adds specification, measurement,
and adaptation into the object model
Logical Method Call
Client
SysCond
Delegate
Contract
SysCond
Contract
ORB Proxy
Delegate
Mechanism/Property
Manager
ORB Proxy
Mechanism
Developer
Specialized ORB
Network
10
21 July 00 Joint PI Meeting
QuO
Developer
SysCond
Specialized ORB
Client
Application
Developer
SysCond
SysCond
SysCond
SysCond
Object
FTN
Network
Server
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
FTN
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
11
21 July 00 Joint PI Meeting
A Classification of Defense Mechanisms
Overcome
Use QoS
Management
Use Gateways
Use application
level adaptivity
Avoid
Reserve
Migrate replicas
bandwidth,
CPU
Block IP
Change
sources
protocols, ports
Retry, use
local calls
21 July 00 Joint PI Meeting
Guard
Tighten
access
controls
Strengthen
encryption
Choose
Increase selfalternate server, checking
degrade service
Table is open to expansion:
•more strategies
•more columns
12
FTN
Accomplishments
Integrated the following defensive mechanisms within
the QuO adaptive infrastructure:
•redundancy management
•access control
•intrusion detection
•packet filtering
Applied all the mechanisms in a simple defensive
strategy in the context of a single demonstration example
•air traffic monitoring application
Developed validation plan (partially complete)
13
21 July 00 Joint PI Meeting
FTN
Control Center
attacker
Map
display
Tripwire detects
intrusion into admin
credentials
tripwire
QuO restores
credentials
admin
FTN
Field Deployed
Admin
privileges
suspended
after intrusion
detected
simulator
sens1
sens2
Quo Contract
QuO sets critical
parameters to preset
value
Quo Contract
attacker
Map
server
14
File sharing
protocol
21 July 00 Joint PI Meeting
publish
database
Attempt to insert fake
data into the database is
thwarted by OO-DTE
Redundancy Management
FTN
Threat: denial of service by killing application components
Defense: maintain component replicas
•group communication using Ensemble (Cornell U)
•membership services
•reliable atomic multicast
•encapsulation in QuO Gateway
•alternate transport-layer protocol
•replica management using Proteus (U of Illinois)
•several alternate failure models supported
TBD:
•use “secure Ensemble”
•replicate Proteus, QuO Kernel
15
21 July 00 Joint PI Meeting
QuO Gateways Support Specialized
Communication Protocols
FTN
Client-Side ORB
QuO Gateway
QuO Gateway
Control
IIOP
IIOP
Glue
Control
Group Replication
Bandwidth Reservation
IIOP over TCP/IP (default)
WAN
16
21 July 00 Joint PI Meeting
IIOP
Glue
IIOP
Server-Side ORB
• The QuO gateway enables insertion of
below-the-ORB mechanisms and
specialized network controls
• The gateway translates IIOP messages
into specialized communication
protocols or network level controls
• To the client-side, the QuO gateway
looks like the remote ORB
• To the object-side, the QuO
gateway looks like the
client’s ORB
• The two ends of the gateway are on the same LAN
as the client/object
• Currently, we have gateways that support Ensemble
group communication,
RSVP resource reservation,
and IIOP over TCP/IP
Access Control
Threat: corruption of the application’s components
or its communication
Defense: cryptography-based access control
•security policy maintenance using OODTE (NAI)
•digital signatures using PGP or JCE
•access control enforcement in CORBA interceptors
•Proteus and QuO Kernel protected
•executables, keys, protected by Tripwire
TBD: use enhancements to OODTE enforcement as they
become available from NAI (e.g., SSL enforcement
in conjuction with Ensemble)
17
21 July 00 Joint PI Meeting
FTN
Stand-Alone Mechanisms
Integrated Using QuO
FTN
Using off-the-shelf IDSs
•Tripwire to notice attacks on critical files
•Snort to recognize known attack signatures in network traffic
Using Linux ipchains to block packets suspected to be a threat
•needed to counter some denial of service attacks
•a readily available defense on a single platform
•These mechanisms are off-the-shelf
•QuO is a control system in which IDSs are one kind of sensor
and ipchains is one kind of actuator
18
21 July 00 Joint PI Meeting
Work In Progress
•Augmenting IDS information about possible attacks
with application-level anomaly detection:
•violation of application invariants
•timeouts
•Developing more complex defense strategies, e.g.,
•anomalous behavior from one host triggers
further scrutiny
•Porting QuO Gateway to TAO (The ACE ORB)
(UC Irvine, Wash U StL)
•will facilitate future control of real-time behavior
19
21 July 00 Joint PI Meeting
FTN
Plans
FTN
Integrate management of additional QoS aspects:
•scheduling CPU
•expect to rely on TAO real-time
•reserving communication bandwidth
•candidate mechanism is ARQOS (NC State)
Implement additional defensive strategies:
•port hopping
•protocol replacement
Tighten current defenses (e.g. replicate Proteus, QuO)
Develop toolkit for configuring application defenses
•specification language for defensive strategies
Evaluate defensive strategies both by analysis and by experiment
20
21 July 00 Joint PI Meeting
A Strategy Specification Language
FTN
Short-Term Goal: describe defensive strategies abstractly
•avoid hardwiring in property managers
•allow non-APOD users to create own strategies easily
•encapsulate QuO QDLs
Long-Term Goal: map high-level strategies to lower-level ones
•generate some QDL automatically
•generate instructions for non-QuO components, e.g.
•configure IDSs dynamically using CIDF
21
21 July 00 Joint PI Meeting
Validating Defenses by Experiment
FTN
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 are trying to put an APOD experiment on the TIC’s agenda.
•Hypothesis: the application-level defensive adaptation
in an APOD application significantly increases the work
needed to damage or destroy that application
22
21 July 00 Joint PI Meeting
Schedule
Proof of
Concept
SW Release
July 1999
Start
FTN
Defense-Enabled App
SW Releases
July 2000
July 2001
Validation Experiment
Technical Reports
23
21 July 00 Joint PI Meeting
Final
Survivability
Tools
Delivery
July 2002
Finish
Technology Transition
Plan: Defense-enabling of more complex applications
Candidate applications likely to emerge from
QuO user base
•NSWC
•ALP (Advanced Logistics Program)
24
21 July 00 Joint PI Meeting
FTN
Summary
FTN
A variety of software defense mechanisms,
including property management and other support from QuO
middleware, is being used to enhance the survivability
of applications.
Ideally, the effectiveness of these defenses will be tested
by experiment at the TIC.
A software release, demonstrating the use of redundancy
management, cryptography-based access control, multiple
IDS triggers, and packet filtering, will be available
after July 2000:
www.dist-systems.bbn.com/projects/APOD
25
21 July 00 Joint PI Meeting