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

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



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



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.



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.



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



Security Domains: Example

domain

host

router

domainhost

hostrouter

domain

hosthost

host

replicas of application component 1

replicas of application component 2



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



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)



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



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



ApplicationAttacker

Raw ResourcesCPU, bandwidth, files...

QoS Management

Crypto

OSs and Network IDSs Firewalls

Defense-Enabled Application CompetesWith Attacker for Control of Resources



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.



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



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



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



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)



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!



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!



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



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



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



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



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



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



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



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

Documents

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