1 21 July 00 Joint PI Meeting FTN Applications that Participate in their Own Defense (APOD) BBN...

1 21 July 00 Joint PI Meeting

FTNApplications that Participate in their Own Defense (APOD)

BBN Technologies

Franklin Webber, Ron Scott, Partha Pal, Michael Atighetchi, Chris Jones, Tom Mitchell, and Ron Watro

{fwebber, rscott, ppal, matighet, ccjones, tmitchel, rwatro}@bbn.com

QuOQuO


FTNLong-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 will be distributed, and will:

– Assume that OS and network infrastructure is vulnerable to intrusion and cyber-attack;

– Adapt their own behavior, resource usage, and service levels to remain as effective as possible in spite of attacks.

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.


FTN

• Have multiple operating modes and a strategy for changing modes to survive the effects of intrusion and denial of service

– some adaptations will lead to a degraded mode of operation– most will involve interacting with management subsystems in

the application’s environment to collect information and request changes

– most will be automatic• Are aware of various aspects of Quality of Service (QoS) and

can recognize and react when QoS is degraded, indicating a potential failure, intrusion, or attack

• Integrate security mechanisms, including intrusion detection systems (IDSs), with the application and with QoS management subsystems

Adaptable, Defense-Enabled, Survivable Applications


FTNApplication and Attacker Competeto Control System Resources

ApplicationAttacker

Raw ResourcesCPU, bandwidth, files...

QoS Management

Crypto

OSs and Network IDSs Firewalls


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

A related BBNT project (under ITS) will remove thisassumption about application privilege.

•“Intrusion Tolerance by Uncertain Adaptation”


FTNProject Goals

• Formulate strategies for responding to attacks that threaten survival of applications.

• Organize response mechanisms around 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-integrated mechanisms, enhance survivability.


FTNWhy 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 can support a wide variety of applications.


FTNQuO 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


FTNSimplified DOC Model (CORBA)

Client Network Server

ApplicationDeveloper

MechanismDeveloper

Logical Method Call Client

ORB Proxy

Obj Req Broker

Object

ORB Proxy

Obj Req Broker

Network


FTNQuO 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


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


FTNA Classification of Defense Mechanisms

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


FTNAccomplishments

Integrated the following defensive mechanisms withinthe QuO adaptive infrastructure:

•redundancy management•access control•intrusion detection•packet filtering

Applied all the mechanisms in a simple defensivestrategy in the context of a single demonstration example

•air traffic monitoring application

Developed validation plan (partially complete)


FTNControl 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


FTNRedundancy Management

Threat: denial of service by killing application components

Defense: maintain component replicas•group communication using Ensemble (Cornell U)

•membership services•reliable atomic multicast

•encapsulation in QuO Gateway•alternate transport-layer protocol

•replica management using Proteus (U of Illinois)•several alternate failure models supported

TBD:•use “secure Ensemble”•replicate Proteus, QuO Kernel


FTN

QuO GatewayQuO Gateway

IIOPGlue

Control

QuO Gateways Support Specialized Communication Protocols

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


FTNAccess Control

Threat: corruption of the application’s components or its communication

Defense: cryptography-based access control•security policy maintenance using OODTE (NAI)•digital signatures using PGP or JCE•access control enforcement in CORBA interceptors

•Proteus and QuO Kernel protected•executables, keys, protected by Tripwire

TBD: use enhancements to OODTE enforcement as they become available from NAI (e.g., SSL enforcement in conjuction with Ensemble)


FTNStand-Alone Mechanisms

Integrated Using QuO

Using off-the-shelf IDSs•Tripwire to notice attacks on critical files•Snort to recognize known attack signatures in network traffic

Using Linux ipchains to block packets suspected to be a threat•needed to counter some denial of service attacks•a readily available defense on a single platform

•These mechanisms are off-the-shelf•QuO is a control system in which IDSs are one kind of sensor and ipchains is one kind of actuator


FTNWork In Progress

•Augmenting IDS information about possible attackswith application-level anomaly detection:•violation of application invariants•timeouts

•Developing more complex defense strategies, e.g.,•anomalous behavior from one host triggers further scrutiny

•Porting QuO Gateway to TAO (The ACE ORB) (UC Irvine, Wash U StL)

•will facilitate future control of real-time behavior


FTNPlans

Integrate management of additional QoS aspects:•scheduling CPU

•expect to rely on TAO real-time•reserving communication bandwidth

•candidate mechanism is ARQOS (NC State)

Implement additional defensive strategies:•port hopping•protocol replacement

Tighten current defenses (e.g. replicate Proteus, QuO)

Develop toolkit for configuring application defenses•specification language for defensive strategies

Evaluate defensive strategies both by analysis and by experiment


FTNA Strategy Specification Language

Short-Term Goal: describe defensive strategies abstractly•avoid hardwiring in property managers•allow non-APOD users to create own strategies easily•encapsulate QuO 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


FTNValidating 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 are trying to put an APOD experiment on the TIC’s agenda.

•Hypothesis: the application-level defensive adaptationin an APOD application significantly increases the workneeded to damage or destroy that application


FTNSchedule

July 1999Start

July 2000 July 2001 July 2002Finish

FinalSurvivabilityToolsDelivery

Proof ofConceptSW Release

Defense-Enabled AppSW Releases

Validation ExperimentTechnical Reports


FTNTechnology Transition

Plan: Defense-enabling of more complex applications

Candidate applications likely to emerge fromQuO user base

•NSWC•ALP (Advanced Logistics Program)


FTNSummary

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.

A software release, demonstrating the use of redundancymanagement, cryptography-based access control, multipleIDS triggers, and packet filtering, will be availableafter July 2000: www.dist-systems.bbn.com/projects/APOD

1 21 July 00 Joint PI Meeting FTN Applications that Participate in their Own Defense (APOD) BBN...

Documents

Transcript of 1 21 July 00 Joint PI Meeting FTN Applications that Participate in their Own Defense (APOD) BBN...