Applications that Participate in their Own Defense (APOD)

1. Applications that Participate in their Own Defense (APOD) BBN Technologies FTN PI Meeting 2001 July 30 Franklin Webber QuO

2. Contract Overview • Start: July 1999 • Finish: July 2002 • Agent: Patrick Hurley, AFRL • Participants (BBN Technologies): • Franklin Webber, PI • Partha Pal • Chris Jones • Michael Atighetchi • Paul Rubel • Nathan Mesh

3. Outline • Review of project goals and high-level approach • Accomplishments to date • Dead ends • Adaptive middleware for coordinating defense • Tasks in progress and yet to be done • Schedule

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

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

6. 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 at the application layer but may be enforced at lower layers • 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

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

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

9. 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 OASIS) is relaxing this assumption about the attacker • “Intrusion Tolerance by Uncertain Adaptation” (ITUA)

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

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. Accomplishments I • use Java Cryptography Extension (JCE)(Sun) to enforce application-level privilege • current defense-enabled applications are written in Java • 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 • upgrade to new Proteus version in progress • will allow replication of Proteus to eliminate single point of attack • will allow easier integration with other defense mechanisms NEW!

13. Accomplishments II • use OO-DTE (NAI) for adaptive access control policy and policy management • built new policy enforcement to integrate OO-DTE policies with Proteus dependability management • began using NAI’s policy language, DTEL++, to specify application policies • required some modification to policy compiler • at our request, NAI is upgrading its policy distribution machinery to allow integration with other defense mechanisms NEW! NEW!

14. Accomplishments III • use intrusion detection systems (IDSs) to trigger defensive adaptation • Tripwire • Snort • use IPtables (Linux) for configurable packet filtering • implement TCP, UDP port hopping to evade attacks on communication • dynamic configuration of IPtables

15. Accomplishments IV • use RSVP bandwidth management to counter some flooding attacks • investigated security-enhanced RSVP (NCSU/UC Davis) • requires authentication during resource reservation and setup • was ported, at our request, to Linux from FreeBSD • implements RSVP signalling but does not make reservations • modifications to make reservations are being considered • investigated, but have not implemented, the integration of RSVP with other defense mechanisms NEW!

16. Defense-Enabled Examples • An air-traffic monitoring system • uses dependability management, access control, Tripwire, and packet filtering • A video data service • uses bandwidth management and dependability management (not yet Proteus, but a simpler placeholder mechanism we wrote) • being shown at this PI meeting • Test examples for individual mechanisms NEW!

17. A Classification of Defense Mechanisms • Table is open to expansion: • more mechanisms • more columns Boldface mechanisms already implemented and integrated in APOD defenses

18. Security-Enhanced Platform • more-secure platform should enhance survivability offered by APOD • planning to port APOD technology to Security-Enhanced Linux (NAI/NSA) • goal: middleware control over OS security policies to complement defensive adaptation NEW!

19. Dead Ends • Not really “failures” • no examples yet of approaches that did not work, only examples of technology we could not use • Defense mechanisms and ideas that were too difficult to use given the project’s budget • Emerald IDS (SRI): no API; Solaris only; needs superuser privilege to configure • Jam IDS (NYU): no API; offline analysis, needs time and training • Quench flooding using IP multicast (AT Corp idea): expected conflicts between IP multicast and protocols used in APOD defense mechanisms

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

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

22. in args CLIENT CLIENT OBJECT (SERVANT) OBJECT (SERVANT) operation() OBJ REF out args + return value Delegate Delegate in args Contract Contract CLIENT CLIENT OBJECT (SERVANT) OBJECT (SERVANT) operation() SysCond SysCond OBJ REF SysCond out args + return value SysCond IDL SKELETON IDL SKELETON MECHANISM/PROPERTY MANAGER IDL STUBS IDL STUBS OBJECT ADAPTER OBJECT ADAPTER Network ORB ORB ORB ORB IIOP IIOP IIOP IIOP Network QuO adds specification, measurement, and adaptation into the distributed object model Application Developer CORBA DOC MODEL Mechanism Developer Application Developer QuO Developer QUO/CORBA DOC MODEL Mechanism Developer

23. The QuO Toolkit supports building adaptive applications or adding adaptation to existing ones • Quality Description Languages (QDL) • Contract description language, adaptive behavior description language, connector setup language • Code generators that generate Java and C++ code for contracts, delegates, creation, and initialization • System Condition Objects • Provide interfaces to resources, managers, and mechanisms • QuO Runtime Kernel • Contract evaluator • Factory object which instantiates contract and system condition objects • Instrumentation library • QuO gateway • Insertion of special purpose transport layers and adaptation below the ORB

24. Using QuO to integrate defense mechanisms • QuO’s quality description languages allow programming of a defense strategy: • how should QuO change state when an anomaly, possibly indicating an attack, is observed? • How should QuO state changes affect resource management? • Recent QuO upgrade allows encapsulation of simple adaptive behaviors as “qoskets”, which can be combined • some APOD defense mechanisms have been “qosketized”, others in progress NEW!

25. Goal: Toolkit for Defense Strategies • apply all available mechanisms to defense of critical applications • many integration problems between mechanisms remain • offer a strategy specification language • allow developers to create a defense strategy easily without need to master QuO • do automatic configuration of defense mechanisms • generate QuO-level specifications automatically • configure non-QuO components automatically, e.g., IPtables • resolve tradeoffs and conflicts between different QoS aspects

26. Validating Defense Enabling • Testing in-house • specific tests of individual defense mechanisms • Red-team experimentation • test of complete defense strategy • Technology transition to a military site • meeting site-specific requirements

27. 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 • Red-Team experiments may resolve the question • Experimental hypothesis: the application-level defensive adaptation in an APOD application significantly increases the work needed to damage or destroy that application

28. 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, scheduled Experiment Validation Experiment Technical Reports