Applications that Participate in their Own Defense (APOD)

1. Applications that Participate in their Own Defense(APOD) Review Meeting 23 March 00 Presentation by: Franklin Webber, Ron Scott, Partha Pal, and Ron Watro {fwebber, rscott, ppal, rwatro}@bbn.com BBN Technologies Presentation to: Doug Maughan, DARPA/ITO

2. Agenda Project Status (Franklin, 70 mins) • Overview, Application-Level Defensive Adaptation, Goals • QuO Middleware Support • Accomplishments, Work In Progress, Plans Software Demonstrations (Partha, 30 mins) • Redundancy Management Demo • Bandwidth Reservation Demo Discussion of Technical and Contractual Issues (20 mins) • Deliverables, Budget • Priorities (TIC Experimentation, NT, etc.)

3. Long-term Vision More survivable systems, 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; • Detect and classify a wide variety of attacks; • Adapt to these attacks in various ways, reasoning about which response mechanisms will best retain the system’s effectiveness. 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.

4. Adaptable, Defense-Enabled, Survivable Applications • Can proceed in the face of intrusions or denial of service and participate in their own defense • Provide means to specify various aspects of Quality of Service (QoS) • Have means to recognize when QoS is degraded, indicating a potential failure, intrusion, or attack • Provide alternate implementation and adaptation strategies: • Switch among different operating modes according to the severity of the attack; • Dynamically reconfigure to counter or avoid attacks; • Interact with QoS management subsystems and intrusion detection systems (IDSs) operating on their behalf.

5. Application and Attacker Compete to Control Information, Resources, and QoS Application Attacker IDS CPU bandwidth

6. 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. • BBNT successfully proposed work under DARPA 00-15 • that will remove this assumption about application privilege. • “Intrusion Tolerance by Uncertain Adaptation”

7. Project Goals • Formulate strategies for responding to attacks that threaten survival of applications. • Implement many response mechanisms in 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 mechanisms, enhance survivability.

8. 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 should be application-independent.

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

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

11. Contract Contract Network QuO adds specification, measurement, and adaptation into the distributed 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

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

13. New APOD Requirements on QuO • Survivability-related constructs in QDLs • e.g., encryption strength • Coordination of different QoS aspects to support • survivability • e.g., RT+FT+security • Security-related restrictions on use of QuO • e.g., different address spaces for different levels of trust

14. A Classification of Defense Strategies • Table is open to expansion: • more strategies • more columns

15. APOD Implementation Path • A series of software releases over the course of the project, • showing increasingly strong defenses. • implement critical strategies first • implement easy strategies first • Defenses incorporated into example applications. • Supporting technology, e.g., languages, motivated by • need to integrate defenses into applications easily.

16. APOD Accomplishments to Date • Software Release 0 • delivery December 99 • initial “proof of concept”; simple defensive strategies • air traffic monitoring application • bandwidth reservation defense strategy • redundancy management defense strategy • Improved Redundancy Management • supporting technology developed under Quorum program • defense for much wider class of applications

17. Example Application • Air Traffic Monitoring: • tracking a single aircraft • sensor data fusion from multiple radars • user interfaces for display and administration • A potentially mission-critical application • motivated by Air Force’s ATD • with multiple QoS aspects • security • availability • performance • previously used in Quorum Integration project • integration of OODTE access control with QuO

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

19. Bandwidth Reservation Defense Strategy • Threat: denial of service by network flooding • Strategy: reserve bandwidth for application • use QuO technology developed under Quorum • depends on RSVP-enabled routers and ORBs • Weakness: malicious attacker can also reserve bandwidth • need trusted RSVP?

20. Redundancy Management Defense Strategy • Threat: denial of service by crashing hosts or application processes • Strategy: replicate processes; move replicas off of damaged hosts • redundancy management integrated with QuO delegates • all delegates linked in a logical ring • status information is circulated; a “software bus” • self-stabilizing: converges to agreement about status • self-repairing: crashed replicas are replaced • protected by OO-DTE (Quorum technology from NAI) • delegates use ring status for multicast • Pro: easy to integrate OO-DTE access control; portable • Con: only weak guarantees for communication in replica groups

21. Network First Attempt at Integrating Replication with Access Control Logical Method Call Application Developer Client Object Client Object Client Object Delegate Delegate Delegate Delegate Delegate Delegate QuO Developer Self-Stabilizing Software Bus ORB Proxy ORB Proxy ORB Proxy ORB Proxy ORB Proxy ORB Proxy Mechanism Developer ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE ORB+OODTE Client Network Server

22. Using Quorum Technology for Dependability • QuO technology developed for Quorum offers better • redundancy management than that used in Software • Release 0: • group communication using Ensemble (Cornell U) • membership services • synchronization • encapsulation in QuO Gateway • alternate transport-layer protocol • replica management using Proteus (U of Illinois) • several alternate failure models supported • This architecture separates the programming • of the application’s functionality from concerns about • dependability (reliability and availability).

23. QuO Gateway Control IIOP IIOP IIOP Glue Client-Side ORB QuO Gateways Support Specialized Communication Protocols and Below the ORB Mechanisms • 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

24. Quorum Dependability vs. Software Bus Technologies: Summary Software Release 0 included redundancy management based on the self-stabilizing software bus. This implementation offers some advantages but it lacks facilities for replica coordination needed in many applications. Future releases will use the Quorum dependability management technology, as it is more advanced and its replica coordination facilities will support a wider range of applications.

25. Work In Progress • Integrating security with Quorum dependability management • needed to protect against attacks that gain application • privilege • OODTE won’t work in the current architecture • uses SSL, which is point-to-point, not multicast • Ensemble has own multicast security mechanisms • uses PGP • option: combine OODTE policies, Ensemble mechanisms • Blocking unauthorized TCP requests using Linux ip_chains • needed to counter some denial of service attacks • a readily available defense on a single platform

26. Plans for Current Year • Integrate redundancy management with other QuO property • managers (security, bandwidth mgmt) in a single application • Integrate multiple IDSs for complementary detection • currently only using Tripwire • considering Snort • Augment IDS information about possible attacks • with application-level self-checking • Use adaptation other than property management: • graceful degradation of application functionality • change protocols dynamically • Create or adopt a language for specifying defense strategies • Run experiments at IA’s Technology Integration Center

27. Integration Issues • Integrating complementary defenses is necessary, • but difficult. • Different Platforms: Solaris, Linux, NT • SSL support for OODTE not available on Linux • RSVP only available on Linux • Dependability management not yet ported to NT • ... • Different ORBs: Visibroker, TAO • offer different program language bindings • nonstandard extensions • Different QoS Aspects: security, RT, FT • inadequate theory for composition • technology immature or unavailable, e.g, FT+RT

28. 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 • considering using Adage/Pledge to augment QuO’s • existing 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

29. Validating Defenses by Experiment • 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. • Proposal submitted Nov 99; favorably reviewed • Hypothesis: the application-level defensive adaptation • in an APOD application significantly increases the work • needed to damage or destroy that application • TIC staff has requested more information • detailed proposal plan needed • stand-alone or piggybacked on other IA work? • “countermeasure characterizations” likely needed • Experiment may be run during 2000

30. Adaptive software raises several interesting issues for IA and security • Tradeoff between critical application survivability and system security • System security policy manager has ultimate authority over security issues • Critical applications that are adapting to survive must take priority over other applications • What security holes will adaptable frameworks, applications, and systems introduce • Can adaptation be exploited? • Will adaptation, measurement, and control APIs be exploitable? • If good guys can adapt, then so can bad guys • If our applications are adapting to make it more difficult to compromise them and to increase their chances for survival; • Can attackers adapt making it more difficult to detect them, defend against them, and recover from their attacks?

31. Technical 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.

32. Schedule Highlights • 7/99: Contract Start • 12/99: Software release 0 • Simple defense-enabled adaptive applications. • 7/00: Software release 1 • Initial integration with existing (COTS or from other DARPA researchers) infrastructure components. • 11/00: Initial validation experiments • 7/01: Software release 2 • Expanded defense strategies; potential feedback (CIDF-based) to intrusion detection systems. • 11/01: Validation experiments • 11/01 - 7/02: Technology transfer software deliveries and integration as needed