1. 1 23 March 00 APOD Review 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. 2 23 March 00 APOD Review 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. 3 23 March 00 APOD Review 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. 4 23 March 00 APOD Review 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. Adaptable, Defense-Enabled, Survivable Applications

5. 5 23 March 00 APOD Review Application and Attacker Compete to Control Information, Resources, and QoS Application Attacker IDSCPUbandwidth

6. 6 23 March 00 APOD Review 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. 7 23 March 00 APOD Review 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. 8 23 March 00 APOD Review 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. 9 23 March 00 APOD Review 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. 10 23 March 00 APOD Review 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

11. 11 23 March 00 APOD Review QuO adds specification, measurement, and adaptation into the distributed 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

12. 12 23 March 00 APOD Review 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)

13. 13 23 March 00 APOD Review 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. 14 23 March 00 APOD Review A Classification of Defense Strategies Table is open to expansion: more strategies more columns

15. 15 23 March 00 APOD Review 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. 16 23 March 00 APOD Review 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. 17 23 March 00 APOD Review 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. 18 23 March 00 APOD Review 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

19. 19 23 March 00 APOD Review 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. 20 23 March 00 APOD Review 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. 21 23 March 00 APOD Review First Attempt at Integrating Replication with Access Control ClientNetworkServer Application Developer QuO Developer Mechanism Developer Logical Method Call Client Delegate ORB Proxy ORB+OODTE Object Delegate ORB Proxy ORB+OODTE Network Self-Stabilizing Software Bus Object Client Delegate Client Delegate ORB Proxy ORB+OODTE

22. 22 23 March 00 APOD Review 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. 23 23 March 00 APOD Review QuO Gateway IIOPGlue Control QuO Gateways Support Specialized Communication Protocols and Below the ORB Mechanisms 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

24. 24 23 March 00 APOD Review 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. 25 23 March 00 APOD Review 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. 26 23 March 00 APOD Review 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. 27 23 March 00 APOD Review 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. 28 23 March 00 APOD Review 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. 29 23 March 00 APOD Review 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. 30 23 March 00 APOD Review 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. 31 23 March 00 APOD Review 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. 32 23 March 00 APOD Review 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