Applications that Participate in their Own Defense (APOD)

1. 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. Long-term Vision 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. Systems with more survivability, built with less effort.

3. Adaptable, Defense-Enabled, Survivable Applications • 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 withQoS management subsystems

4. Application and Attacker Compete to Control System Resources C r y p t o Attacker Application QoS Management OSs and Network IDSs Firewalls Raw Resources CPU, bandwidth, files...

5. 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. 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. 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. 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. Network Simplified DOC Model (CORBA) Logical Method Call Application Developer Client Object ORB Proxy ORB Proxy Mechanism Developer Obj Req Broker Obj Req Broker Client Network Server

10. Contract Contract Network QuO adds specification, measurement, and adaptation into the object model Logical Method Call Application Developer Client Object SysCond SysCond Delegate Delegate SysCond SysCond SysCond QuO Developer SysCond SysCond ORB Proxy ORB Proxy Mechanism/Property Manager Mechanism Developer Specialized ORB Specialized ORB Client Network Server

11. Connector Setup Language (CSL) CORBA IDL Contracts Delegates Contract Description Language (CDL) QuO Runtime Connectors Code Generators Structure Description Language (SDL) 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

12. A Classification of Defense Mechanisms • Table is open to expansion: • more strategies • more columns

13. 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. Map display admin Control Center Field Deployed attacker simulator Tripwire detects intrusion into admin credentials sens1 tripwire sens2 Quo Contract Admin privileges suspended after intrusion detected QuO sets critical parameters to preset value QuO restores credentials Quo Contract Quo Contract attacker Map server database File sharing protocol publish Attempt to insert fake data into the database is thwarted by OO-DTE

15. 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. QuO Gateway Control IIOP IIOP IIOP Glue Client-Side ORB QuO Gateways Support Specialized Communication Protocols • 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 QuO Gateway Control Group Replication IIOP Glue Server-Side ORB Bandwidth Reservation IIOP over TCP/IP (default) WAN

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

24. Technology Transition • Plan: Defense-enabling of more complex applications • Candidate applications likely to emerge from • QuO user base • NSWC • ALP (Advanced Logistics Program)

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