1 23 march 00 apod review applications that participate in their own defense (apod) review meeting...

1 23 March 00 APOD Review

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


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.)


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.


• 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.

Adaptable, Defense-Enabled, Survivable Applications


Application and Attacker Compete to Control Information, Resources, and QoS

Application

Attacker

IDS CPU bandwidth


Levels of Attacker Privilege

•no privilege•“login shell” privilege•“root shell” privilege•application privilege

Application privilege includes the ability to modify theapplication or start new application components.

We assume attackers do not have application privilege.We use cryptographic techniques to try to enforcethis assumption.

BBNT successfully proposed work under DARPA 00-15that will remove this assumption about application privilege.

•“Intrusion Tolerance by Uncertain Adaptation”


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.


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.


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 distributed object model



QuODeveloper

MechanismDeveloper


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)


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


A Classification of Defense Strategies

Overcome Avoid Guard

Use QoSManagement

Reservebandwidth,CPU

Migrate replicas Tightenaccesscontrols

Use Gateways Block IPsources

Changeprotocols, ports

Strengthenencryption

Use applicationlevel adaptivity

Retry, uselocal calls

Choosealternate server,degrade service

Increase self-checking

Table is open to expansion:•more strategies•more columns


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 byneed to integrate defenses into applications easily.


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


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


Control Center Field Deployed

admin

publishMap

server

File sharing protocol

Mapdisplay

attackerTripwire detects intrusion into admin credentials

Quo C

ontract

sens1

simulator

database

sens2

attacker

Attempt to insert fake data into the database is thwarted by OO-DTE

Quo Contract

Quo Contract

Admin privileges suspended after intrusion detected

tripwire

QuO sets critical parameters to preset

value

QuO restores credentials


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?


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; portableCon: only weak guarantees for communication in replica groups


First Attempt at Integrating Replication with Access Control



QuODeveloper

MechanismDeveloper


Delegate

ORB Proxy

ORB+OODTE

Object

Delegate

ORB Proxy

ORB+OODTE

Network

Self-Stabilizing Software Bus

ObjectObjectClient

DelegateDelegate

Client

DelegateDelegate

ORB ProxyORB ProxyORB ProxyORB Proxy

ORB+OODTEORB+OODTEORB+OODTEORB+OODTE


Using Quorum Technology for Dependability

QuO technology developed for Quorum offers betterredundancy management than that used in SoftwareRelease 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 programmingof the application’s functionality from concerns aboutdependability (reliability and availability).


QuO GatewayQuO Gateway

IIOPGlue

Control

QuO Gateways Support Specialized Communication Protocols and Below the ORB Mechanisms

Cli

ent-

Side

OR

B

IIOP Group Replication

WAN

Bandwidth Reservation

IIOP over TCP/IP (default)

IIOPGlue

Control

IIOP

Serv

er-S

ide

OR

B

• 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 gate-way are on the same LAN as the client/object

• Currently, we have gate-ways 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 managementbased on the self-stabilizing software bus. This implementationoffers some advantages but it lacks facilities for replicacoordination needed in many applications.

Future releases will use the Quorum dependability managementtechnology, as it is more advanced and its replica coordinationfacilities will support a wider range of applications.


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


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 attackswith 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


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


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


Validating Defenses by Experiment

IA’s Technology Integration Center offers facilities and staffthat 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 workneeded 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


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?


Technical Summary

A variety of software defense mechanisms,including property management and other support from QuOmiddleware, is being used to enhance the survivabilityof applications.

Ideally, the effectiveness of these defenses will be testedby experiment at the TIC.


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 (CIDF-based) to intrusion detection systems.

• 11/01: Validation experiments• 11/01 - 7/02: Technology transfer software deliveries and integration as

needed

1 23 march 00 apod review applications that participate in their own defense (apod) review meeting...

Documents

apod review applications

defense apod review

new application components

apod review project

apod review levels of

survivable systems

apod review longterm

service qos