BBN Technologies a part of page 118 January 2001 Applications that Participate in their Own Defense (APOD) BBN Technologies FTN PI Meeting January 2001 QuO

BBN Technologies a part of page 218 January 2001 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

BBN Technologies a part of page 318 January 2001 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.

BBN Technologies a part of page 418 January 2001 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.

BBN Technologies a part of page 518 January 2001 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

BBN Technologies a part of page 618 January 2001 Security Domains: Example domain host router domain host router domain host replicas of application component 1 replicas of application component 2

BBN Technologies a part of page 718 January 2001 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

BBN Technologies a part of page 818 January 2001 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)

BBN Technologies a part of page 918 January 2001 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

BBN Technologies a part of page 1018 January 2001 A Classification of Defense Mechanisms Table is open to expansion: more strategies more columns

BBN Technologies a part of page 1118 January 2001 Application Attacker Raw Resources CPU, bandwidth, files... QoS Management CryptoCrypto OSs and NetworkIDSsFirewalls Defense-Enabled Application Competes With Attacker for Control of Resources

BBN Technologies a part of page 1218 January 2001 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.

BBN Technologies a part of page 1318 January 2001 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

BBN Technologies a part of page 1418 January 2001 Simplified DOC Model (CORBA) ClientNetworkServer Application Developer Mechanism Developer Logical Method Call Client ORB Proxy Obj Req Broker Object ORB Proxy Obj Req Broker Network

BBN Technologies a part of page 1518 January 2001 QuO adds specification, measurement, and adaptation into the object model ClientNetworkServer Application Developer QuO Developer Mechanism Developer Logical Method Call Client Delegate ORB Proxy Specialized ORB Contract SysCond Object Delegate ORB Proxy Specialized ORB Contract Network Mechanism/Property Manager SysCond

BBN Technologies a part of page 1618 January 2001 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 Code Generators Code Generators Contract Description Language (CDL) Structure Description Language (SDL) QuO Runtime Delegates Contracts Connectors Connector Setup Language (CSL)

BBN Technologies a part of page 1718 January 2001 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!

BBN Technologies a part of page 1818 January 2001 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!

BBN Technologies a part of page 1918 January 2001 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

BBN Technologies a part of page 2018 January 2001 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

BBN Technologies a part of page 2118 January 2001 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

BBN Technologies a part of page 2218 January 2001 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

BBN Technologies a part of page 2318 January 2001 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

BBN Technologies a part of page 2418 January 2001 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 staff that could be used for running attacks against APOD defenses. We proposed a TIC experiment for APOD validation. Hypothesis: the application-level defensive adaptation in an APOD application significantly increases the work needed to damage or destroy that application

BBN Technologies a part of page 2518 January 2001 Papers “Defense-Enabled Applications”, submitted to DISCEX II “Defense-Enabled Applications: An Example” submitted to MILCOM project overview, software distributions: –

BBN Technologies a part of page 2618 January 2001 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 TIC In-house, planned