1. OPX PI Meeting 2002 February 21 -- page 1 Applications that Participate in their Own Defense (APOD) QuO Franklin Webber BBN Technologies

2. OPX PI Meeting 2002 February 21 -- page 2 Project Sponsor: DARPA/ATO Program: Fault-Tolerant Networks Program manager: Doug Maughan Project monitor: Pat Hurley (AFRL) Period of performance: July 1999 - July 2002

3. OPX PI Meeting 2002 February 21 -- page 3 Technical Objective Give any critical distributed software application an increased resistance to malicious attack: even though the environment in which it runs is untrustworthy; without major modifications to its code. Any such application is “defense-enabled”.

4. OPX PI Meeting 2002 February 21 -- page 4 Existing Practice/Technical Approach Infrastructure (operating systems, networks) on which many military applications are run is less than trustworthy –applications are vulnerable to attacks that exploit security flaws in infrastructure An application that can adapt to work around the effect of attacks will offer more dependable service –a defense-enabled application is aware of its quality-of-service (QoS) requirements and monitors its environment for QoS changes Metric: length of correct computation while under attack –measured in Red Team experiments and other validation

5. OPX PI Meeting 2002 February 21 -- page 5 A Distributed Military Application

6. OPX PI Meeting 2002 February 21 -- page 6 A Cyber-Attack

7. OPX PI Meeting 2002 February 21 -- page 7 An Abstract View Attacker Data Processing (Fusion, Analysis, Storage, Forwarding, etc.) Data User Data Source

8. OPX PI Meeting 2002 February 21 -- page 8 Traditional Security Attacker Application Private Resources Private Resources Limited Sharing Trusted OSs and Network

9. OPX PI Meeting 2002 February 21 -- page 9 Most OSs and Networks In Common Use Are Untrustworthy Attacker Application Private Resources Private Resources Limited Sharing OSs and Network

10. OPX PI Meeting 2002 February 21 -- page 10 Cryptographic Techniques Can Block (Most) Direct Access to Application Attacker Application Private Resources Private Resources Limited Sharing OSs and Network CryptoCrypto

11. OPX PI Meeting 2002 February 21 -- page 11 Attacker Raw Resources CPU, bandwidth, files... OSs and NetworkIDSsFirewalls Firewalls Block Some Attacks; Intrusion Detectors Notice Others Application CryptoCrypto

12. OPX PI Meeting 2002 February 21 -- page 12 Application Attacker Raw Resources CPU, bandwidth, files... QoS Management CryptoCrypto OSs and NetworkIDSsFirewalls Defense-Enabled Application Competes With Attacker for Control of Resources

13. OPX PI Meeting 2002 February 21 -- page 13 QuO Adaptive Middleware 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. OPX PI Meeting 2002 February 21 -- page 14 QuO adds specification, measurement, and adaptation into the distributed object model Application Developer Mechanism Developer CLIENT Network operation() in args out args + return value IDL STUBS IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF CLIENT Delegate Contract SysCond Contract Network MECHANISM/PROPERTY MANAGER operation() in args out args + return value IDL STUBS Delegate SysCond IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF Application Developer QuO Developer Mechanism Developer CORBA DOC MODEL QUO/CORBA DOC MODEL

15. OPX PI Meeting 2002 February 21 -- page 15 The QuO Toolkit Supports Building Adaptive Apps or Adding Adaptation to Existing Apps QuO Code Generator QoS Adaptivity Specification QoS Management CORBA IDL

16. OPX PI Meeting 2002 February 21 -- page 16 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.

17. OPX PI Meeting 2002 February 21 -- page 17 Security Domains Limit the Damage From A Single Intrusion hacked domain host router domain host router domain host

18. OPX PI Meeting 2002 February 21 -- page 18 Replication Management Can Replace Killed Processes hacked domain host router domain host router domain host application component replicas QuO replica management

19. OPX PI Meeting 2002 February 21 -- page 19 Bandwidth Management Can Counter Flooding Between Routers hacked domain host router domain host router domain host QuO bandwidth management RSVP reservation or packet-filtered link

20. OPX PI Meeting 2002 February 21 -- page 20 Other Defense Mechanisms Dynamically change communication ports Dynamically change communication protocols

21. OPX PI Meeting 2002 February 21 -- page 21 Defense Strategy Use QuO middleware to coordinate all available defense mechanisms in a coherent strategy. Best current strategy has two parts: –“outrun”: move application component replicas off bad hosts and on to good ones –“contain”: quarantine bad hosts by limiting or blocking network traffic from them and, within limits, shutting them down

22. OPX PI Meeting 2002 February 21 -- page 22 Validation Experimentation: a defense-enabled application is attacked by professional hackers, i.e., a “Red Team”, and its performance is measured Modeling: properties of a defense-enabled application are measured in the lab and plugged into an abstract model of attack and defense

23. OPX PI Meeting 2002 February 21 -- page 23 Experimentation Blue Team: the technology developers –Franklin Webber, et al., BBN/Distributed Systems Red Team: the attackers –Steve Kaufman, et al., Sandia White Team: the moderators –Ken Theriault, et al., BBN/Security –testbed preparation; experiment planning and analysis

24. OPX PI Meeting 2002 February 21 -- page 24 Experimentation Milestones October: begin weekly planning meetings November: experiment plan outlined December: ‘whiteboard’ experiment analysis –all teams met at BBN –plan for first experiment complete January: testbed preparation February: conducted first experiment –approximately one week long

25. OPX PI Meeting 2002 February 21 -- page 25 Multiple APOD Experiments ‘whiteboard’ experiment: discuss likely approaches to attack and defense without actually carrying them out first experiment (February) – use replication management, dynamic packet filtering, and intrusion detection for defense; flooding is off-limits second experiment (TBD) –add bandwidth management; allow flooding

26. OPX PI Meeting 2002 February 21 -- page 26 CBCBBBBBBBSSS VPN/ Interne t Experiment Control, external waypoint router Legend C: client S: server B: broker factory Experiment Testbed and Test Application

27. OPX PI Meeting 2002 February 21 -- page 27 Whiteboard Analysis of APOD Red Team starts with ‘root’ privilege on one host Intended Red Team attacks: –ARP cache poisoning to partition network –spoofing to trigger APOD ‘containment’ strategy, leading to self-denial-of-service –reverse engineering application components to cause malicious application behavior Lessons learned for Blue Team: –network partitioning a bigger problem than expected –some changes to mechanisms and strategy Formulating an experiment to test the limits of the APOD ‘outrun’ strategy is difficult

28. OPX PI Meeting 2002 February 21 -- page 28 Results from First Experiment A defense-enabled application forced a highly-skilled and prepared attacker to work very hard and with no stealth against a purely automated defense to deny service Red Team eventually defeated APOD defenses with a combination of spoofing, ARP cache poisoning, and TCP connection flood –roughly a week of trial-and-error –final scripted attack takes 5 minutes and sets off numerous alarms (the undefended app, in comparison, could be killed immediately in the same situation)

29. OPX PI Meeting 2002 February 21 -- page 29 More Results APOD defenses add roughly 5% to application request latency on average Unpredictable adaptation is good –nondeterministic placement of replicas helped –dynamic choice of communication ports would be better Corrupting running application processes to cause malicious behavior was not attempted, but may be harder than it seemed at first

30. OPX PI Meeting 2002 February 21 -- page 30 Plans for Second Experiment Improve APOD strategy –TCP connection flood can be detected and responded to –other Add bandwidth management mechanism –detect and respond to (data) flooding –may use security-enhanced RSVP from NCSU to reserve bandwidth; will use dynamic packet-filtering to block floods –use strategically-placed Linux routers Consider augmenting purely automatic defense with tools for operator intervention

31. OPX PI Meeting 2002 February 21 -- page 31 Technology Transition/Summary APOD defenses measurably “raise the bar” against cyber-attack, even against well-prepared attackers. APOD middleware encapsulates adaptive defense strategies for reuse in many applications. A distributed military application is sought – for testing the APOD technology against a real-world set of requirements – for testing how easily an existing application can be defense-enabled –for further research to improve APOD defenses