Intrusion Tolerance by Unpredictable Adaptation

1. DARPA Sponsored by QuO Monitored by Air Force Research Lab Intrusion Tolerance by Unpredictable Adaptation Presented by Partha Pal ppal@bbn.com BBN Technologies University of Illinois and Boeing Corporation

2. People and Contact Info • BBN • Partha Pal [ppal@bbn.com] • Ron Watro [rwatro@bbn.com] • Franklin Webber [fwebber@bbn.com] • University of Illinois • Bill Sanders [whs@crhc.uiuc.edu] • Michel Cukier [cukier@crhc.uiuc.edu] • Boeing • Bryan Doerr [Bryan.Doerr@boeing.com] • Project Web Page: • http://www.dist-systems.bbn.com/projects/itua

3. Contents • Part I • Background and Context • Part II • Project Description • Technical Objective • Expected Accomplishments • Technical Approach • Risks Involved • Evaluation and Qualitative Metrics • Policy and Enforcement • Tech Transfer • Schedule and Milestones

4. Observations • Attacks on distributed systems will occur • issues involved are well known and well studied • attacks attempt to take control over “resources” which applications need and security mechanisms aim to protect • Imperfection in security mechanisms: “defense in depth” • many traditional underlying assumptions are inapplicable for distributed systems in the days of globalization and the internet • There is little interaction between the applications and traditional security mechanisms • Applications need to adapt to environmental changes when attacked • Recent technical developments in middleware technology make it easier for an application to integrate various desired properties and to incorporate adaptive behavior

5. Background • Under Quorum/ QuOIN • the QuO Middleware • preliminary work towards integrating individual mechanisms such as Bandwidth management, Fault Tolerance, Real-time and Security in adaptive distributed applications • Individual mechanisms provide some degree of inherent survivability against naturally occurring problems • Under Information Survivability • a toolkit for developing applications that can adapt in response to various triggers, including signals from IDSs • Can we tolerate intrusion attacks? • can we stop the errors caused by intrusion attacks before a failure? • can we survive the failures caused by intrusion attacks? • all? some? which ones? caused by what kinds of attacks?

6. Synthesis of Survivability Ideas • Think as if the application has a survivability requirement, distinct from its functional requirements • separation of survivability from functional aspects in line with Quorum/QuOIN {philosophy, methodology,framework} • Survivability requirements are addressed by incorporating survivability strategies • some survivability strategies are proactive (in anticipation or in preparation) and some are reactive (in reaction) • from another perspective, some are defensive strategies and some are tolerance strategies • The two perspectives are not mutually exclusive • a defensive/tolerance strategy may have both proactive and reactive measures • a practical strategy is likely to have multiple strategies of various flavors

7. Long Term Vision: Future Critical Systems • Will be built upon vulnerable OS and network infrastructure • Will need to employ survivability strategies to adapt their own behavior, resource usage and service levels to remain as effective as possible in spite of intrusion attacks • require new capabilities like awareness of the environment, use of new kinds of resource management mechanisms and interaction with security mechanisms • it is advantageous to put the support for the strategies in the middle • This is a big problem space that we are just starting to explore: • ongoing FTN project: Applications that participate in their own defense (APOD) • new ITS start: Intrusion tolerance by unpredictable adaptation(ITUA)

8. Overview: Applications that participate in their own defense • Facilitates construction of distributed applications using adaptive middleware that: • are security /intrusion aware and • display survivalist adaptive behavior • Scope: Simple strategies aimed at simple, non-coordinated attacks • assumes attacker does not have application privilege • Tasks: implement and incorporate strategies and validate • Focuses on application’s awareness of security mechanisms • can be integrated with IDSs (does not focus on intrusion detection) • can be integrated with access-control mechanisms, firewalls • Paving the way towards integration of multiple mechanisms: • security and bandwidth management ; security and replication management

9. A typical APOD scenario Adaptive middleware IDS Replica migrated Host infected Host infected client replicated server Replication Manager restrict access to host Infocon alert Non replicated back up

10. Part II • ITUA Introduction • Technical Objective • Expected Accomplishments • Technical Approach • Risks Involved • Evaluation and Quantitative Metrics • Policy and Enforcement • Tech Transfer • Schedule and Milestone

11. Intrusion Tolerance by Unpredictable Adaptation • Considers coordinated attacks that manifest themselves as Byzantine application behavior • some of these attacks will (at least partially) subvert traditional security measures and affect the application • some may even gain application privilege • some may be sustained and phased, and may lead to common mode failures • Goal is to make applications tolerate the faults, as opposed trying to prevent (or detect) the attacks that cause them • middleware tolerance of resource attacks is a worthwhile addition to the defense-in-depth approach • Adaptation is still your friend, but predictability is your enemy in this context!

12. replica replica replica replica replica OO-DTE OO-DTE OO-DTE OO-DTE OO-DTE firewall firewall firewall firewall firewall Spawn on an unpredictable host (note the required redundant resources) Spawn on an unpredictable host (note the required redundant resources) Select the set in an unpredictable manner Back up OO-DTE Byzantine agreement firewall ITUA Scenario client Tolerance triggers Adaptive middleware and multi-mode redundancy mechanisms present intrusion-tolerant view of system resources to application

13. Technical Objective • Develop algorithms and infrastructure support to enable distributed systems to survive coordinated attacks on systems resources • Combine fault tolerance and security techniques to provide a variety of survivability mechanisms to the application • Manage the redundancy of various system resources in a decentralized and secured manner • Develop and integrate survivability strategies that provide layers of defense using fast reacting, adaptive responses that are unpredictable to the attacker

14. Expected Accomplishments • Development of distributed infrastructure for integrating survivability strategies • Creation of survivability mechanisms required for implementing these strategies building on known fault-tolerance and security approaches • development of a decentralized resource manager that manages the redundancy of various system resources • enhancement of adaptive middleware • example strategies • Experimental validation (or refutation) of the developed technologies • Transfer developed technologies to industrial partners

15. Technical Approach: Primary Focus • Management of resource redundancy and security • decentralized mechanisms supporting the implementation of our survivability strategies • redundancy of resources at various levels of abstractions • integration of security and fault tolerance techniques dictated by the nature of faults • self protection of the mechanism • Engineering of distributed systems and trade offs • enhance the adaptive middleware framework as required • use hints (anomalies visible to the application, signals from IDS, Signals from the resource manager and other mechanisms) • use the capabilities of the resource redundancy management • cope with adaptivity and unpredicability that are part of the strategies • Validation of developed technologies (base and optional parts) • analytical? experimental? how rigorous and how formal?

16. Risks Mitigation • Different security and fault tolerance techniques may have conflicting assumptions • reduce scope, refine assumption • Developed technology may lead to an impractical solution • thrashing: refine strategies • introduction of new vulnerabilities: self protection is a task item • developed technology too costly, too complex to be used: early evaluation and tech transition plan • Strategy may be refuted • early validation/experimentation • Tolerance triggers we hope to use may not be available • rely on hints that we gather from the middleware and the mechanisms as opposed to tolerance triggers

17. Quantitative Metrics • Goal: Quantitative evaluation of • Effectiveness: Does it work? How well does it work? • Applicability: Is it applicable in a real military context? • Potential effectiveness metric • Does the developed technology provide additional protection relative to an unprotected system? • Additional protection (measured in effort or time) the developed technology provides relative to an unprotected system • Potential applicability metric • Cost vs. benefit ratio of applying our technology in Boeing’s application • Other potential quantities to measure: coverage

18. Policy enforcement is done by the adaptive middleware and the resource management mechanism that mediates between the application and the infrastructure Policy Enforcement in ITUA context • Policy: Directive/Guidance for handling unwanted events • Survivability strategies can be thought about as application level micro-policies, for example: • pick a replication host in a non-deterministic manner when a host is infected • Someone’s policy is someone else’s specification • QuO contracts and associated adaptive behavior descriptions are incarnations of the micro-policies • They can work with/take inputs from an over-arching policy mechanism (INFOCON) via QuO System Conditions application Middleware and resource managers Infrastructure resources

19. Technology Transfer Plans • Boeing provides the technology transfer context and target • Technology development with an eye on transition • Boeing’s participation in the technology development, early evaluation and validation will ensure that the developed technology • is set in a realistic context • provides usable and practical solution to a real problem • is readily transitioned into Boeing’s applications that need survivability

20. Schedule and Milestones theoretical basis of MRM ready survivability strategies/ mw enhancement ready protection of infrastructure added software development activity evaluation/tech transfer activity software demonstration Technical Paper PI meetings and reviews Final Report 0 3 6 9 12 15 18 21 24 28 32 36 40 44 Months after contract 7/1/00 10/1/01 12/31/02 9/30/03