2001 July 30 -- page 1

Applications that Participate in their Own Defense (APOD)

BBN Technologies

FTN PI Meeting

2001 July 30

Franklin Webber

QuOQuO

2001 July 30 -- page 2

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 3

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 4

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.

2001 July 30 -- page 5

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 6

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 7

Security Domains: Example

domain

host

router

domainhost

hostrouter

domain

hosthost

host

replicas of application component 1

replicas of application component 2

2001 July 30 -- page 8

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 9

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 10

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 11

ApplicationAttacker

Raw ResourcesCPU, bandwidth, files...

QoS Management

Crypto

OSs and Network IDSs Firewalls

Defense-Enabled Application CompetesWith Attacker for Control of Resources

2001 July 30 -- page 12

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 point of attack

• will allow easier integration with other defense mechanisms

NEW!

2001 July 30 -- page 13

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

• required some modification to policy compiler

– at our request, NAI is upgrading its policy distribution machinery to allow integration with other defense mechanisms

NEW!

NEW!

2001 July 30 -- page 14

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 15

Accomplishments IV

• use RSVP bandwidth management to counter some flooding attacks– investigated security-enhanced RSVP (NCSU/UC Davis)

• requires authentication during resource reservation 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

NEW!

2001 July 30 -- page 16

Defense-Enabled Examples

• An air-traffic monitoring system– uses dependability management, access control,

Tripwire, and packet filtering

• A video data service– 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

NEW!

2001 July 30 -- page 17

A Classification of Defense Mechanisms

Overcome Workaround Guard

Use applicationlevel adaptivity

Retry, uselocal calls

Choose alternateserver, degradeservice

Increase self-checking

Use QoSManagement

Reservebandwidth,CPU

Migrate replicas Strengthen accesscontrols, IDSs

Use Gateways Block IPsources

Changeprotocols, changeports

Strengthenencryption,change keys

Table is open to expansion:

•more mechanisms•more columns

Boldface mechanismsalready implemented andintegrated in APOD defenses

2001 July 30 -- page 18

Security-Enhanced Platform

• more-secure platform should enhance survivability offered by APOD

• planning to port APOD technology to Security-Enhanced Linux (NAI/NSA)– goal: middleware control over OS security policies to

complement defensive adaptationNEW!

2001 July 30 -- page 19

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 20

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 21

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

2001 July 30 -- page 22

QuO adds specification, measurement, and adaptation into the distributed object model

ApplicationDeveloper

MechanismDeveloper

CLIENT

Network

operation()

in args

out args + return value

IDLSTUBS

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network

MECHANISM/PROPERTYMANAGER

operation()

in args

out args + return value

IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

ApplicationDeveloper

QuODeveloper

MechanismDeveloper

CO

RB

A D

OC

MO

DE

LQ

UO

/CO

RB

A D

OC

MO

DE

L

2001 July 30 -- page 23

The QuO Toolkit supports building adaptive applications or adding adaptation to existing ones

• Quality Description Languages (QDL)– 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– Provide interfaces to resources,

managers, and mechanisms

• QuO Runtime Kernel– Contract evaluator– Factory object which instantiates

contract and system condition objects

• Instrumentation library• QuO gateway

– Insertion of special purpose transport layers and adaptation below the ORB

QuO GatewayQuO Gateway

IIOPGlue

Control

Clie

nt-S

ide

OR

B

IIOP Group Replication (AQuA)

WAN

Bandwidth Reservation (DIRM)

IIOP over TCP/IP (default)

IIOPGlue

Control

IIOP

Serv

er-S

ide

OR

B

CORBA IDL

CodeGenerators

CodeGenerators

Contract DescriptionLanguage (CDL)

QuO RuntimeQuO RuntimeStructure DescriptionLanguage (SDL)

Delegates Contracts

CLIENT

DelegateContract

SysCond

Contract

Network

MECHANISM/PROPERTYMANAGER

operation()

in args

out args + return value

IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON OBJECT

ADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

2001 July 30 -- page 24

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 progressNEW!

2001 July 30 -- page 25

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 26

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 27

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 28

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

ExperimentIn-house,scheduled