Transcript PowerPoint

Applications that Participate in their Own Defense
(APOD)
Review Meeting
23 March 00
Presentation by:
Franklin Webber, Ron Scott, Partha Pal, and Ron Watro
{fwebber, rscott, ppal, rwatro}@bbn.com
BBN Technologies
Presentation to:
Doug Maughan, DARPA/ITO
1
23 March 00 APOD Review
Agenda
Project Status (Franklin, 70 mins)
– Overview, Application-Level Defensive Adaptation, Goals
– QuO Middleware Support
– Accomplishments, Work In Progress, Plans
Software Demonstrations (Partha, 30 mins)
– Redundancy Management Demo
– Bandwidth Reservation Demo
Discussion of Technical and Contractual Issues (20 mins)
– Deliverables, Budget
– Priorities (TIC Experimentation, NT, etc.)
2
23 March 00 APOD Review
Long-term Vision
More survivable systems, 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;
– Detect and classify a wide variety of attacks;
– Adapt to these attacks in various ways, reasoning about
which response mechanisms will best retain the system’s
effectiveness.
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.
3
23 March 00 APOD Review
Adaptable, Defense-Enabled, Survivable Applications
• Can proceed in the face of intrusions or denial of service and
participate in their own defense
• Provide means to specify various aspects of Quality of Service
(QoS)
• Have means to recognize when QoS is degraded, indicating a
potential failure, intrusion, or attack
• Provide alternate implementation and adaptation strategies:
– Switch among different operating modes according to the
severity of the attack;
– Dynamically reconfigure to counter or avoid attacks;
– Interact with QoS management subsystems and intrusion
detection systems (IDSs) operating on their behalf.
4
23 March 00 APOD Review
Application and Attacker Compete to Control
Information, Resources, and QoS
Application
Attacker
IDS
5
23 March 00 APOD Review
CPU
bandwidth
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.
BBNT successfully proposed work under DARPA 00-15
that will remove this assumption about application privilege.
•“Intrusion Tolerance by Uncertain Adaptation”
6
23 March 00 APOD Review
Project Goals
• Formulate strategies for responding to attacks that threaten
survival of applications.
• Implement many response mechanisms in 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
mechanisms, enhance survivability.
7
23 March 00 APOD Review
Why Put Defenses In Middleware?
•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 should be application-independent.
8
23 March 00 APOD Review
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)
9
23 March 00 APOD Review
QuO
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
10
23 March 00 APOD Review
Network
Server
QuO adds specification, measurement, and adaptation
into the distributed object model
Logical Method Call
Client
SysCond
Delegate
Contract
SysCond
Contract
ORB Proxy
Delegate
Mechanism/Property
Manager
ORB Proxy
Mechanism
Developer
Specialized ORB
Network
11
23 March 00 APOD Review
QuO
Developer
SysCond
Specialized ORB
Client
Application
Developer
SysCond
SysCond
SysCond
SysCond
Object
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
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
12
23 March 00 APOD Review
New APOD Requirements on QuO
•Survivability-related constructs in QDLs
•e.g., encryption strength
•Coordination of different QoS aspects to support
survivability
•e.g., RT+FT+security
•Security-related restrictions on use of QuO
•e.g., different address spaces for different levels of trust
13
23 March 00 APOD Review
A Classification of Defense Strategies
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
23 March 00 APOD Review
Tighten
access
controls
Strengthen
encryption
Choose
Increase selfalternate server, checking
degrade service
Table is open to expansion:
•more strategies
•more columns
14
Guard
APOD Implementation Path
A series of software releases over the course of the project,
showing increasingly strong defenses.
•implement critical strategies first
•implement easy strategies first
Defenses incorporated into example applications.
Supporting technology, e.g., languages, motivated by
need to integrate defenses into applications easily.
15
23 March 00 APOD Review
APOD Accomplishments to Date
Software Release 0
•delivery December 99
•initial “proof of concept”; simple defensive strategies
•air traffic monitoring application
•bandwidth reservation defense strategy
•redundancy management defense strategy
Improved Redundancy Management
•supporting technology developed under Quorum program
•defense for much wider class of applications
16
23 March 00 APOD Review
Example Application
Air Traffic Monitoring:
•tracking a single aircraft
•sensor data fusion from multiple radars
•user interfaces for display and administration
A potentially mission-critical application
•motivated by Air Force’s ATD
with multiple QoS aspects
•security
•availability
•performance
previously used in Quorum Integration project
•integration of OODTE access control with QuO
17
23 March 00 APOD Review
Control Center
Field Deployed
attacker
Map
display
Tripwire detects
intrusion into admin
credentials
tripwire
QuO restores
credentials
admin
Admin
privileges
suspended
after intrusion
detected
simulator
sens1
sens2
Quo Contract
QuO sets critical
parameters to preset
value
Quo Contract
attacker
Map
server
18
File sharing
protocol
23 March 00 APOD Review
publish
database
Attempt to insert fake
data into the database is
thwarted by OO-DTE
Bandwidth Reservation Defense Strategy
Threat: denial of service by network flooding
Strategy: reserve bandwidth for application
•use QuO technology developed under Quorum
•depends on RSVP-enabled routers and ORBs
Weakness: malicious attacker can also reserve bandwidth
•need trusted RSVP?
19
23 March 00 APOD Review
Redundancy Management Defense Strategy
Threat: denial of service by crashing hosts or application processes
Strategy: replicate processes; move replicas off of damaged hosts
•redundancy management integrated with QuO delegates
•all delegates linked in a logical ring
•status information is circulated; a “software bus”
•self-stabilizing: converges to agreement about status
•self-repairing: crashed replicas are replaced
•protected by OO-DTE (Quorum technology from NAI)
•delegates use ring status for multicast
Pro: easy to integrate OO-DTE access control; portable
Con: only weak guarantees for communication in replica groups
20
23 March 00 APOD Review
First Attempt at Integrating Replication
with Access Control
Client
Client
Client
Logical Method Call
Delegate
Delegate
Delegate
Object
Object
Object
Delegate
Delegate
Delegate
Self-Stabilizing
Software Bus
ORBProxy
Proxy
ORB
ORB
Proxy
ORBProxy
Proxy
ORB
ORB
Proxy
ORB+OODTE
ORB+OODTE
ORB+OODTE
ORB+OODTE
ORB+OODTE
ORB+OODTE
Network
Client
21
23 March 00 APOD Review
Network
Server
Application
Developer
QuO
Developer
Mechanism
Developer
Using Quorum Technology for Dependability
QuO technology developed for Quorum offers better
redundancy management than that used in Software
Release 0:
•group communication using Ensemble (Cornell U)
•membership services
•synchronization
•encapsulation in QuO Gateway
•alternate transport-layer protocol
•replica management using Proteus (U of Illinois)
•several alternate failure models supported
This architecture separates the programming
of the application’s functionality from concerns about
dependability (reliability and availability).
22
23 March 00 APOD Review
QuO Gateways Support Specialized Communication
Protocols and Below the ORB Mechanisms
Client-Side ORB
QuO Gateway
QuO Gateway
Control
IIOP
IIOP
Glue
Control
Group Replication
Bandwidth Reservation
IIOP over TCP/IP (default)
WAN
23
23 March 00 APOD Review
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
Quorum Dependability vs. Software Bus
Technologies: Summary
Software Release 0 included redundancy management
based on the self-stabilizing software bus. This implementation
offers some advantages but it lacks facilities for replica
coordination needed in many applications.
Future releases will use the Quorum dependability management
technology, as it is more advanced and its replica coordination
facilities will support a wider range of applications.
24
23 March 00 APOD Review
Work In Progress
Integrating security with Quorum dependability management
•needed to protect against attacks that gain application
privilege
•OODTE won’t work in the current architecture
•uses SSL, which is point-to-point, not multicast
•Ensemble has own multicast security mechanisms
•uses PGP
•option: combine OODTE policies, Ensemble mechanisms
•Blocking unauthorized TCP requests using Linux ip_chains
•needed to counter some denial of service attacks
•a readily available defense on a single platform
25
23 March 00 APOD Review
Plans for Current Year
•Integrate redundancy management with other QuO property
managers (security, bandwidth mgmt) in a single application
•Integrate multiple IDSs for complementary detection
•currently only using Tripwire
•considering Snort
•Augment IDS information about possible attacks
with application-level self-checking
•Use adaptation other than property management:
•graceful degradation of application functionality
•change protocols dynamically
•Create or adopt a language for specifying defense strategies
•Run experiments at IA’s Technology Integration Center
26
23 March 00 APOD Review
Integration Issues
Integrating complementary defenses is necessary,
but difficult.
Different Platforms: Solaris, Linux, NT
•SSL support for OODTE not available on Linux
•RSVP only available on Linux
•Dependability management not yet ported to NT
•...
Different ORBs: Visibroker, TAO
•offer different program language bindings
•nonstandard extensions
Different QoS Aspects: security, RT, FT
•inadequate theory for composition
•technology immature or unavailable, e.g, FT+RT
27
23 March 00 APOD Review
A Strategy Specification Language
Short-Term Goal: describe defensive strategies abstractly
•avoid hardwiring in property managers
•allow non-APOD users to create own strategies easily
•considering using Adage/Pledge to augment QuO’s
existing 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
28
23 March 00 APOD Review
Validating Defenses by Experiment
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.
•Proposal submitted Nov 99; favorably reviewed
•Hypothesis: the application-level defensive adaptation
in an APOD application significantly increases the work
needed to damage or destroy that application
•TIC staff has requested more information
•detailed proposal plan needed
•stand-alone or piggybacked on other IA work?
•“countermeasure characterizations” likely needed
•Experiment may be run during 2000
29
23 March 00 APOD Review
Adaptive software raises several interesting issues for
IA and security
• Tradeoff between critical application survivability and system
security
– System security policy manager has ultimate authority over security issues
– Critical applications that are adapting to survive must take priority over
other applications
• What security holes will adaptable frameworks, applications, and
systems introduce
– Can adaptation be exploited?
– Will adaptation, measurement, and control APIs be exploitable?
• If good guys can adapt, then so can bad guys
– If our applications are adapting to make it more difficult to compromise
them and to increase their chances for survival;
– Can attackers adapt making it more difficult to detect them, defend against
them, and recover from their attacks?
30
23 March 00 APOD Review
Technical Summary
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.
31
23 March 00 APOD Review
Schedule Highlights
• 7/99: Contract Start
• 12/99: Software release 0
– Simple defense-enabled adaptive applications.
• 7/00: Software release 1
– Initial integration with existing (COTS or from other
DARPA researchers) infrastructure components.
• 11/00: Initial validation experiments
• 7/01: Software release 2
– Expanded defense strategies; potential feedback (CIDFbased) to intrusion detection systems.
• 11/01: Validation experiments
• 11/01 - 7/02: Technology transfer software deliveries and
integration as needed
32
23 March 00 APOD Review