Applications that Participate in their Own Defense (APOD)

1. Applications that Participate in their Own Defense (APOD) Franklin Webber BBN Technologies QuO

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. 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. 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. A Distributed Military Application

6. A Cyber-Attack Hacked!

7. An Abstract View Data User Data Source Data Processing (Fusion, Analysis, Storage, Forwarding, etc.) Attacker

8. Traditional Security Application Attacker Trusted OSs and Network Private Resources Limited Sharing Private Resources

9. Most OSs and Networks In Common Use Are Untrustworthy Application Attacker OSs and Network Private Resources Limited Sharing Private Resources

10. Cryptographic Techniques Can Block (Most) Direct Access to Application C r y p t o Application Attacker OSs and Network OSs and Network Private Resources Limited Sharing Private Resources

11. Firewalls Block Some Attacks; Intrusion Detectors Notice Others C r y p t o Application Attacker OSs and Network IDSs Firewalls Raw Resources CPU, bandwidth, files...

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

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

15. The QuO Toolkit Supports Building Adaptive Apps or Adding Adaptation to Existing Apps QoS Adaptivity Specification QuO Code Generator CORBA IDL QoS Management

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. Security Domains Limit the Damage From A Single Intrusion domain host host host router host router host host domain hacked domain

18. Replication Management Can Replace Killed Processes domain host host host router host router host host domain hacked domain application component replicas QuO replica management

19. Bandwidth Management Can Counter Flooding Between Routers domain host host host router host router host host domain hacked domain QuO bandwidth management RSVP reservation or packet-filtered link

20. Other Defense Mechanisms • Dynamically change communication ports • Dynamically change communication protocols

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. 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. 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. 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. 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. C B B B B B C B B B S S S Experiment Testbed and Test Application Experiment Control,external waypoint Legend C: client S: server B: broker factory router router router router VPN/Internet

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