Applications that Participate in their Own Defense (APOD)

1. Applications that Participate in their Own Defense (APOD) BBN Technologies FTN PI Meeting 16-19 January 2001 QuO

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

3. 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 need to be designed, implemented, operated, and maintained with less (or at least no more) effort than today’s systems of comparable complexity.

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

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

6. Security Domains: Example domain host host host router host router host host domain domain replicas of application component 1 replicas of application component 2

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

8. 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)

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

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

11. Defense-Enabled Application Competes With Attacker for Control of Resources C r y p t o Attacker Application QoS Management OSs and Network IDSs Firewalls Raw Resources CPU, bandwidth, files...

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

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

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

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

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

17. 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!

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

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

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

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

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

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

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

25. Papers • “Defense-Enabled Applications”, submitted to DISCEX II • “Defense-Enabled Applications: An Example” submitted to MILCOM • project overview, software distributions: • www.dist-systems.bbn.com/projects/APOD

26. Schedule Proof of Concept SW Release Defense-Enabled App SW Releases Final Survivability Tools Delivery 0.0 1.0 1.1 2.0 3.0 July 1999 Start July 2000 July 2001 July 2002 Finish In-house, planned TIC Validation Experiment Technical Reports