Transcript PowerPoint - Applications that Participate in their Own Defense

Applications that Participate in their Own
Defense (APOD)
BBN Technologies
QuO
FTN PI Meeting
2001 July 30
Franklin Webber
2001 July 30 -- page 1
Contract Overview
•
•
•
•
Start: July 1999
Finish: July 2002
Agent: Patrick Hurley, AFRL
Participants (BBN Technologies):
–
–
–
–
–
–
Franklin Webber, PI
Partha Pal
Chris Jones
Michael Atighetchi
Paul Rubel
Nathan Mesh
2001 July 30 -- page 2
Outline
•
•
•
•
•
•
Review of project goals and high-level approach
Accomplishments to date
Dead ends
Adaptive middleware for coordinating defense
Tasks in progress and yet to be done
Schedule
2001 July 30 -- page 3
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.
2001 July 30 -- page 4
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.
2001 July 30 -- page 5
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 at the application layer but
may be enforced at lower layers
• 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
2001 July 30 -- page 6
Security Domains: Example
domain
host
host
host
router
host
router
host
host
domain
domain
replicas of application component 1
replicas of application component 2
2001 July 30 -- page 7
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
2001 July 30 -- page 8
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 OASIS) is relaxing this
assumption about the attacker
• “Intrusion Tolerance by Uncertain Adaptation” (ITUA)
2001 July 30 -- page 9
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
2001 July 30 -- page 10
Defense-Enabled Application Competes
With Attacker for Control of Resources
Attacker
C
r
y
p
t
o
Application
QoS Management
OSs and Network
Raw Resources
CPU, bandwidth, files...
2001 July 30 -- page 11
IDSs
Firewalls
Accomplishments I
• use Java Cryptography Extension (JCE)(Sun) to
enforce application-level privilege
– current defense-enabled applications are written in Java
• 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
– upgrade to new Proteus version in progress
• will allow replication of Proteus to eliminate single
NEW!
point of attack
• will allow easier integration with other defense
mechanisms
2001 July 30 -- page 12
Accomplishments II
• use OO-DTE (NAI) for adaptive access control
policy and policy management
– built new policy enforcement to integrate OO-DTE
policies with Proteus dependability management
– began using NAI’s policy language, DTEL++, to specify
application policies
NEW!
• required some modification to policy compiler
– at our request, NAI is upgrading its policy distribution
machinery to allow integration with other defense
NEW!
mechanisms
2001 July 30 -- page 13
Accomplishments III
• use intrusion detection systems (IDSs) to trigger
defensive adaptation
– Tripwire
– Snort
• use IPtables (Linux) for configurable packet
filtering
• implement TCP, UDP port hopping to evade attacks
on communication
– dynamic configuration of IPtables
2001 July 30 -- page 14
Accomplishments IV
• use RSVP bandwidth management to counter some
flooding attacks
– investigated security-enhanced RSVP (NCSU/UC Davis)
• requires authentication during resource reservation
NEW!
and setup
• was ported, at our request, to Linux from FreeBSD
• implements RSVP signalling but does not make
reservations
– modifications to make reservations are being considered
– investigated, but have not implemented, the integration
of RSVP with other defense mechanisms
2001 July 30 -- page 15
Defense-Enabled Examples
• An air-traffic monitoring system
– uses dependability management, access control,
Tripwire, and packet filtering
• A video data service
NEW!
– uses bandwidth management and dependability
management (not yet Proteus, but a simpler placeholder
mechanism we wrote)
– being shown at this PI meeting
• Test examples for individual mechanisms
2001 July 30 -- page 16
A Classification of Defense Mechanisms
Overcome
Use application
level adaptivity
Use QoS
Management
Use Gateways
Guard
Retry, use
local calls
Choose alternate Increase selfserver, degrade checking
service
Reserve
Migrate replicas Strengthen access
bandwidth,
controls, IDSs
CPU
Change
Strengthen
Block IP
protocols, change encryption,
sources
change keys
ports
Table is open to expansion:
•more mechanisms
•more columns
2001 July 30 -- page 17
Workaround
Boldface mechanisms
already implemented and
integrated in APOD defenses
Security-Enhanced Platform
• more-secure platform should enhance survivability
offered by APOD
• planning to port APOD technology to SecurityEnhanced Linux (NAI/NSA)
– goal: middleware control over OS security policies to
complement defensive adaptation
NEW!
2001 July 30 -- page 18
Dead Ends
• Not really “failures”
– no examples yet of approaches that did not work, only
examples of technology we could not use
• Defense mechanisms and ideas that were too
difficult to use given the project’s budget
– Emerald IDS (SRI): no API; Solaris only; needs
superuser privilege to configure
– Jam IDS (NYU): no API; offline analysis, needs time
and training
– Quench flooding using IP multicast (AT Corp idea):
expected conflicts between IP multicast and protocols
used in APOD defense mechanisms
2001 July 30 -- page 19
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.
2001 July 30 -- page 20
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)
2001 July 30 -- page 21
QuO
CORBA DOC MODEL
QuO adds specification, measurement, and
adaptation into the distributed object model
in args
CLIENT
OBJECT
operation()
OBJ
REF
(SERVANT)
out args + return value
IDL
SKELETON
IDL
STUBS
ORB
Network
IIOP
IIOP
in args
QUO/CORBA DOC MODEL
Application
Developer
CLIENT
Mechanism
Developer
ORB
OBJECT
operation()
OBJ
REF
OBJECT
ADAPTER
(SERVANT)
out args + return value
Contract
Contract
Delegate
Delegate
SysCond
SysCond
IDL
MECHANISM/PROPERTY
MANAGER
SKELETON
STUBS
ORB
2001 July 30 -- page 22
IIOP
Network
QuO
Developer
SysCond
SysCond
IDL
Application
Developer
IIOP
ORB
OBJECT
ADAPTER
Mechanism
Developer
The QuO Toolkit supports building adaptive
applications or adding adaptation to existing ones
• Quality Description Languages (QDL)
CORBA IDL
Contract Description
Language (CDL)
Structure Description
Language (SDL)
Delegates Contracts
Code
Code
Generators
Generators
QuO
QuORuntime
Runtime
– Contract description language, adaptive
behavior description language,
connector setup language
– Code generators that generate Java and
C++ code for contracts, delegates,
creation, and initialization
• System Condition Objects
in args
(SERVANT)
out args + return value
Contract
Contract
Delegate
Delegate
SysCond
SysCond
IDL
MECHANISM/PROPERTY
MANAGER
IDL
SKELETON
STUBS
Client-Side ORB
IIOP
Network
QuO Gateway
IIOP IIOP
IIOP
ORB
Control
Group Replication (AQuA)
IIOP IIOP
Glue Bandwidth Reservation (DIRM) Glue
IIOP over TCP/IP (default)
WAN
2001 July 30 -- page 23
– Contract evaluator
– Factory object which instantiates
contract and system condition objects
OBJECT
ADAPTER
QuO Gateway
Control
• QuO Runtime Kernel
SysCond
SysCond
ORB
– Provide interfaces to resources,
managers, and mechanisms
OBJECT
operation()
OBJ
REF
Server-Side ORB
CLIENT
• Instrumentation library
• QuO gateway
– Insertion of special purpose transport
layers and adaptation below the ORB
Using QuO to integrate defense
mechanisms
• QuO’s quality description languages allow
programming of a defense strategy:
– how should QuO change state when an anomaly,
possibly indicating an attack, is observed?
– How should QuO state changes affect resource
management?
• Recent QuO upgrade allows encapsulation of
simple adaptive behaviors as “qoskets”, which can
be combined
– some APOD defense mechanisms have been
“qosketized”, others in progress
2001 July 30 -- page 24
NEW!
Goal: Toolkit for Defense Strategies
• apply all available mechanisms to defense of
critical applications
– many integration problems between mechanisms remain
• offer a strategy specification language
– allow developers to create a defense strategy easily
without need to master QuO
• do automatic configuration of defense mechanisms
– generate QuO-level specifications automatically
– configure non-QuO components automatically, e.g.,
IPtables
– resolve tradeoffs and conflicts between different QoS
aspects
2001 July 30 -- page 25
Validating Defense Enabling
• Testing in-house
– specific tests of individual defense mechanisms
• Red-team experimentation
– test of complete defense strategy
• Technology transition to a military site
– meeting site-specific requirements
2001 July 30 -- page 26
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
Red-Team experiments may resolve the question
Experimental hypothesis: the application-level defensive
adaptation in an APOD application significantly increases the
work needed to damage or destroy that application
2001 July 30 -- page 27
Schedule
Proof of
Concept
SW Release
0.0
July 1999
Start
Defense-Enabled App
SW Releases
1.0
1.1
July 2000
In-house,
scheduled
2.0
July 2001
Experiment
Validation Experiment
Technical Reports
2001 July 30 -- page 28
Final
Survivability
Tools
Delivery
3.0
July 2002
Finish