1. Slide 1 ITUA: Approach to Project Validation and Characterization Not for public distribution. Intrusion Tolerance by Unpredictable Adaptation (ITUA) Approach to Project Characterization and Validation Partha Pal Ron Watro Franklin Webber William H. Sanders Michel Cukier James Lyons Prashant Pandey HariGovind Ramasamy Jeanna Gossett OASIS PI Meeting, July 26, 2001

2. Slide 2 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Goals 1)To develop intrusion-tolerant communication/agreement protocols that tolerate a range of intrusions and permit the number and type of intrusions tolerated to be dynamically updated as the protocols operate 2)To define and develop mechanisms that respond to attacks effectively in an unpredictable manner 3)To develop a intrusion-tolerant architecture, based on replication and adaptation and coordinated through middleware in which the techniques developed in 1) and 2) can be effectively deployed

3. Slide 3 ITUA: Approach to Project Validation and Characterization Not for public distribution. OASIS Framework Design Implementation Operation TAVs Goals Availability Integrity Confidentiality Nonrepudiation Authentication

4. Slide 4 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Primary Focus Design Implementation Operation TAVs Goals Availability Integrity Confidentiality Nonrepudiation Authentication

5. Slide 5 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Secondary Focuses Design Implementation Operation TAVs Goals Availability Integrity Confidentiality Nonrepudiation Authentication

6. Slide 6 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Secondary Focuses Design Implementation Operation TAVs Goals Availability Integrity Confidentiality Nonrepudiation Authentication

7. Slide 7 ITUA: Approach to Project Validation and Characterization Not for public distribution. Overlapping Activities Validation Characterization Say what it does! Use a common context Compare to others Find synergies Locate IA&S gaps Provide assurance that it works! Focus on individual project Need specification/implementation Various approaches Analytic Experimental

8. Slide 8 ITUA: Approach to Project Validation and Characterization Not for public distribution. Assumptions vs.Working Hypotheses Assumptions –Technical statements that express widely accepted positions or technical boundaries Working Hypotheses –Simplifying assumptions made for the project that are potentially less precise, less widely accepted, and more subject to future change –May serve as the basis for defining a starting point in the exploration of a complex problem space –During work on a project, one may reinforce (i.e., find justification, validate, or develop support for) a hypothesis, or find a hypothesis untenable, in which case it must be revised or removed

9. Slide 9 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Project Assumptions A-1: Effectiveness of cryptography: Keys are adequately sized and mathematical assumptions are made to ensure that common symmetric and asymmetric encryption techniques cannot be efficiently broken. A-2: Protection from Network Denial-of-Service (DoS): ITUA will be designed to tolerate selective failures of communications links, but not to tolerate a systematic flooding of a wide portion of the communications network. Protection against that type of denial-of-service attack is an active research area that is outside the scope of ITUA. Our technology will require adequate network service levels between a changeable set of sites, and is expected to be compatible with any effective DoS protection scheme (e.g., ingress filtering, traceback, etc.). In addition, there are experimental mechanisms available to help ensure selective, continuous communication; for our purposes, we assume them to be effective.

10. Slide 10 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Project Working Hypotheses WH-1 Adequate situational awareness tools (e.g., tools that detect attempted intrusions) exist to provide the information needed as the basis for determining defensive postures and reactions. WH-2 An adequate variety of effective defensive postures and attack responses exists to support the creation of unpredictable responses to attacks. WH-3 Attacks that corrupt an application will proceed through a series of stages (e.g., gaining user access, root access, and application access) and thus will require more time and more intelligent direction than single-stage attacks. Attacks of this type require considerable planning, and their goal is something more than simple momentary disruption. ITUA specifically targets this kind of sophisticated attack. WH-4 The ITUA infrastructure can create and deploy replicas at performance levels that compare favorably with the time required to complete application- level attacks against these replicas. WH-5 Adequate diversity exists in operating systems, applications, firewalls, and other aspects of the computing environment to make it possible to create replicas that provide identical services but present different security vulnerabilities.

11. Slide 11 ITUA: Approach to Project Validation and Characterization Not for public distribution. TAV Specification Recall that TAVs can occur during design, implementation, and operation Some OASIS technologies avoid the effect of an attack due to design or implementation modifications Other OASIS technologies tolerate the effect of a attack during operation ITUA tolerates effects during operation Therefore: –TAVs that originate during design or implementation may be tolerated during operation, so it makes sense to specify TAVs during all lifecycle phases, even if a project tolerates effects during operation –Understanding effects and their relationship to TAVs is important when developing validation technologies (Distinction between TAV and effect is analogous to the distinction between fault and error)

12. Slide 12 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Design TAVs TAV-1-1 Incomplete or incorrect high-level security requirements For example, the analysis of the problem was incomplete and did not identify all the security requirements. TAV-1-2 Incorrect refinement of the security requirements For example, a high-level security requirement is mapped to specific component security requirements that are inadequate to ensure the high-level requirement. TAV-1-3 Incorrect design The design of a component fails to meet the component security requirements. TAV-1-4 Design environment attack The information system that contains the design information is attacked and the design information is maliciously manipulated.

13. Slide 13 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Implementation TAVs TAV-2-1 Implementation flaws or bugs The software as written does not match the design. TAV-2-2 “Easter eggs” and back doors Developers hide code in the application to perform hidden functionality or to allow developers full access to the subsequently deployed system. TAV-2-3 Buffer overflows Implementation writes data without checking whether the data is too large for the buffer, potentially leading to the execution of data in an unintended fashion. TAV-2-4 Implementation environment attack The information system that contains the design information is attacked and the software is maliciously manipulated.

14. Slide 14 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Operational TAVs TAV-3-1 Hardware failure A network host or infrastructure node or a communication link fails, either halting operation entirely or performing erroneous or malicious functions. TAV-3-2 User-level attack A system or range of systems is corrupted by attacks run by an untrusted user. Subsequent stages may allow the user to reach application- level privileges. TAV-3-3 System-level attack A system or range of systems is corrupted by a trusted user operating with system administrator privileges. TAV-3-4 Application-level attack A system or range of systems is corrupted by a trusted user operating with application-level privileges. TAV-3-5 Virus or worm attack An autonomic attack infects hosts silently and subsequently is simultaneously activated against a large number of infected hosts. TAV-3-6 Reactive attack The attack launches probes against the system, evaluates any defensive response, and then prepares and launches custom attacks based on the probe results. TAV-3-7 Credential attack Secret authentication credentials are compromised through inadvertent disclosure, brute-force dictionary attack, crypto-analysis, or some other method. TAV-3-8 ITUA infrastructure attack The ITUA management component of a system is subverted.

15. Slide 15 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Mechanisms Mapped to Goals 1)To develop intrusion-tolerant communication/agreement protocols that tolerate a range of intrusions and permit the number and type of intrusions tolerated to be dynamically updated as the protocols operate (M-3, M-4, M-7) 2)To define and develop mechanisms that respond to attacks effectively and in a manner not easily predictable by the attackers (M-1, M-5, M-6, M-7, M-8) 3)To develop a security architecture, based on replication and adaptation, and coordinated through middleware in which the techniques developed in (1) and (2) can be effectively deployed (M-2)

16. Slide 16 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Survivability and Security Mechanisms M-1 Autonomic reaction to intrusion detection In the ITUA prototype, ID tools such as Snort and QoS probes will be used as “sensors,” in conjunction with another set of tools called “actuators,” to produce a range of immediate autonomic responses. Multiple sensor-actuator loops will be deployed on each host in each security domain. M-2 Hierarchical (sensor-actuator-specific, host-specific, domain-wide, system-wide) response to suspicious events (intrusion or anomaly) based on local, decentralized decision-making This is the next level of response after M-1. Each host in a security domain has an ITUA subordinate to which the sensor-actuator loops on that host report. Each domain has a subordinate designated a manager, to which the subordinates in that domain report. M-3 Application-level replication provided through middleware Replicas are typically maintained in separate security domains to prevent a single attack from damaging all the copies. The ITUA managers and subordinates are responsible for this kind of replication management. M-4 Voting and agreement protocols between replicas Provides correct and consistent results plus identification of malicious errors. These protocols will be located in the ITUA gateway, which will contain the ITUA intrusion-tolerant group communication system.

17. Slide 17 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Survivability and Security Mechanisms, cont. M-5 Random selection among functionally equivalent options (application-level and system-level) This is the first aspect of unpredictability. It includes, for example, randomization of network addresses to prevent easy location of protected resources. The QuO middleware is responsible for this mechanism. M-6 Selection from non-equivalent options based on situational awareness and the goal of maintaining unpredictability This is the second aspect of unpredictability and part of the overall approach to dynamic adaptation. The QuO middleware driven by the managers and subordinates is responsible for this mechanism. M-7 Dynamic adjustment of security based on situational awareness and the cost of protection technology Adaptation is based on deployment of expensive protection only when required. The ITUA intrusion-tolerant gateway and the ITUA managers and subordinates are responsible for this mechanism. M-8 Protection of application functionality using layers of privilege in the application environment Deployment of OO-DTE (Object-Oriented Domain and Type Enforcement) is a key aspect of this mechanism.

18. Slide 18 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Validation Approach Different validation approaches should be used at different phases of the lifecycle of the project Validation effort is ongoing, since project mechanisms are currently under development Design Phase –Use logical argument and stochastic models –Simple stochastic model presented in ITUA Intrusion Model document, available at http://www.distsystems.bbn.com/projects/ITUA Implementation and Operational Phase –Compile list of effects to be tolerated. –Inject implementation with effects (example given in demo of IT GCS Tuesday night; many of the effects to be presented were injected) –Modify mechanism (to make it tolerate the effect) or assess goodness of mechanism via statistical analysis of experimental results

19. Slide 19 ITUA: Approach to Project Validation and Characterization Not for public distribution. Example ITUA Group Communication TAV effects

20. Slide 20 ITUA: Approach to Project Validation and Characterization Not for public distribution. ITUA Rationale Matrix

21. Slide 21 ITUA: Approach to Project Validation and Characterization Not for public distribution. Lessons Learned “Outline of a characterization” handout provides a good structure for performing a characterization/validation of OASIS technologies Outline does not specify what validation technique to use; individual projects must decide which existing validation techniques are useful, or whether a new one needs to be invented It is useful to separate assumptions the project relied on into “Assumptions” and “Working Hypotheses,” to express ones confidence in the reasonableness of the assumptions, and suggest assumptions that may be refined during the project period TAVs are most useful for explaining validation results to end users of particular systems, but effects are most useful when validating a system in the implementation and operational phases Work is needed to map TAVs to effects in order to characterize, at a high level, the intrusion-tolerance of an approach