2001 July page 1 Applications that Participate in their Own Defense (APOD) BBN Technologies FTN PI Meeting 2001 July 30 Franklin Webber QuO

2001 July 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 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 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 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 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 page 7 Security Domains: Example domain host router domain host router domain host replicas of application component 1 replicas of application component 2

2001 July 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 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 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 page 11 Application Attacker Raw Resources CPU, bandwidth, files... QoS Management CryptoCrypto OSs and NetworkIDSsFirewalls Defense-Enabled Application Competes With Attacker for Control of Resources

2001 July 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 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!

2001 July 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 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 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 page 17 A Classification of Defense Mechanisms Table is open to expansion: more mechanisms more columns Boldface mechanisms already implemented and integrated in APOD defenses

2001 July 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 adaptation NEW!

2001 July 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 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 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 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) QuO

2001 July page 22 QuO adds specification, measurement, and adaptation into the distributed object model Application Developer Mechanism Developer CLIENT Network operation() in args out args + return value IDL STUBS IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF CLIENT Delegate Contract SysCond Contract Network MECHANISM/PROPERTY MANAGER operation() in args out args + return value IDL STUBS Delegate SysCond IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF Application Developer QuO Developer Mechanism Developer CORBA DOC MODEL QUO/CORBA DOC MODEL

2001 July 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

2001 July 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 progress NEW!

2001 July 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 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 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 page 28 Schedule July 1999 Start July 2000July 2001July 2002 Finish Final Survivability Tools Delivery Proof of Concept SW Release Defense-Enabled App SW Releases Validation Experiment Technical Reports Experiment In-house, scheduled