1. 1 21 July 00 Joint PI Meeting FTN Applications 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 QuO

2. 2 21 July 00 Joint PI Meeting FTN Long-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.

3. 3 21 July 00 Joint PI Meeting 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

4. 4 21 July 00 Joint PI Meeting FTN Application and Attacker Compete to Control System Resources Application Attacker Raw Resources CPU, bandwidth, files... QoS Management CryptoCrypto OSs and NetworkIDSsFirewalls

5. 5 21 July 00 Joint PI Meeting FTN Levels of Attacker Privilege no privilege “login shell” privilege “root shell” privilege application privilege Application privilege includes the ability to modify the application or start new application components. We assume attackers do not have application privilege. We use cryptographic techniques to try to enforce this assumption. A related BBNT project (under ITS) will remove this assumption about application privilege. “Intrusion Tolerance by Uncertain Adaptation”

6. 6 21 July 00 Joint PI Meeting FTN Project 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.

7. 7 21 July 00 Joint PI Meeting FTN 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 can support a wide variety of applications.

8. 8 21 July 00 Joint PI Meeting FTN 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

9. 9 21 July 00 Joint PI Meeting FTN 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

10. 10 21 July 00 Joint PI Meeting FTN 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

11. 11 21 July 00 Joint PI Meeting FTN 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)

12. 12 21 July 00 Joint PI Meeting FTN A Classification of Defense Mechanisms Table is open to expansion: more strategies more columns

13. 13 21 July 00 Joint PI Meeting FTN Accomplishments Integrated the following defensive mechanisms within the QuO adaptive infrastructure: redundancy management access control intrusion detection packet filtering Applied all the mechanisms in a simple defensive strategy in the context of a single demonstration example air traffic monitoring application Developed validation plan (partially complete)

14. 14 21 July 00 Joint PI Meeting FTN Control CenterField Deployed admin publish Map server File sharing protocol Map display attacker Tripwire detects intrusion into admin credentials Quo Contract sens1 simulator database sens2 attacker Attempt to insert fake data into the database is thwarted by OO-DTE Quo Contract Admin privileges suspended after intrusion detected tripwire QuO sets critical parameters to preset value QuO restores credentials

15. 15 21 July 00 Joint PI Meeting FTN Redundancy 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

16. 16 21 July 00 Joint PI Meeting FTN QuO Gateway IIOPGlue Control QuO Gateways Support Specialized Communication Protocols Client-Side ORB IIOP Group Replication WAN Bandwidth Reservation IIOP over TCP/IP (default) IIOPGlue Control IIOP Server-Side ORB 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

17. 17 21 July 00 Joint PI Meeting FTN Access 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)

18. 18 21 July 00 Joint PI Meeting FTN Stand-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

19. 19 21 July 00 Joint PI Meeting FTN Work In Progress Augmenting IDS information about possible attacks with 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

20. 20 21 July 00 Joint PI Meeting FTN Plans 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

21. 21 21 July 00 Joint PI Meeting FTN 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 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

22. 22 21 July 00 Joint PI Meeting FTN 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 are trying to put an APOD experiment on the TIC’s agenda. Hypothesis: the application-level defensive adaptation in an APOD application significantly increases the work needed to damage or destroy that application

23. 23 21 July 00 Joint PI Meeting FTN 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

24. 24 21 July 00 Joint PI Meeting FTN Technology Transition Plan: Defense-enabling of more complex applications Candidate applications likely to emerge from QuO user base NSWC ALP (Advanced Logistics Program)

25. 25 21 July 00 Joint PI Meeting FTN Summary A variety of software defense mechanisms, including property management and other support from QuO middleware, is being used to enhance the survivability of applications. Ideally, the effectiveness of these defenses will be tested by experiment at the TIC. A software release, demonstrating the use of redundancy management, cryptography-based access control, multiple IDS triggers, and packet filtering, will be available after July 2000: www.dist-systems.bbn.com/projects/APOD