Intrusion Tolerance by Unpredictable Adaptation William H. Sanders Michel Cukier James Lyons Prashant Pandey HariGovind Ramasamy Partha Pal Ron Watro Franklin Webber Jeanna Gossett Not for public distribution

Intrusion Tolerance by Unpredictable Adaptation Develop middleware-based mechanisms to keep a distributed CORBA-based application running despite intrusions: Adaptation to cope with changes in environment Redundancy to tolerate arbitrary component failures Unpredictability to thwart attack planning and delay the attacker Research Agenda Explore the use of adaptation, redundancy and unpredictability in the context of intrusion tolerance Evaluate the developed capabilities Specific tasks Use unpredictability in adaptive response Mechanism for adaptation control in the middleware Protect application objects from the adverse effects of intrusion Replication and intrusion tolerance within the communication layers Results so far: Middleware extension for unpredictable adaptation Intrusion-tolerant group communication system Prototype architecture to tie in the capabilities and as a basis for further investigation and evaluation ITUA Intrusion Model, analysis of effectiveness of mechanisms in terms of various factors In progress Distributed management of application level replicas and a hierarchical response mechanism

Outline of the talk Nature of attacks ITUA is considering Mechanisms for adaptive tolerance of intrusion effects Unpredictable adaptive response to intrusion effects Techniques under investigation Dynamic and unpredictable response engagement Distributed management of redundant resources/security tools Rapid reaction to intrusion/anomaly Dynamic adjustment of security Protecting application objects from intrusions Application level replication coordinated through middleware Group communication tolerating arbitrary intrusion effects A reference architecture for using/evaluating these components Integration opportunities Schedule and events This talk is different from prior PI presentations. A year into the project, we are past the initial thinking phase and currently deep in an implementation phase. This talk will pay more attentio. Midway through the talk we will switch for Michel to talk about a critical piece and then I will come back to conclude the talk.

Nature of Attacks that ITUA is considering Focuses on attacks that attempt to “corrupt” the application Broader notion of corruption [ITUA intrusion model] Assumes layers of privilege Anonymous legitimate user, domain user, domain administrator : supported by properly configured security domains and cryptographic techniques Application privilege (needed to interact with the application components): supported by object level access control (currently in the form of OODTE) Each layer is a barrier, subversion of different layers have different consequences with domain admin privilege attacker can start or stop processes in a host with application privilege attackers can corrupt processes More layers mean more barriers, and more possibilities for adaptation Attacks typically progress in “stages” Identify target component Gain access to the target security domain sending attack packet may kill the orb, or the process (redundancy) attack packet reaching the process will be rejected (application privilege) Must work its way to obtain application privilege, possibly by gaining domain admin privilege first with domain admin privilege it may kill application processes, start attack processes Death/Corruption in application objects: detected and recovered Death/Corruption in ITUA system objects: detected, and abandoned (relies on redundancy)

Dynamic and Unpredictable Response Engagement Enhanced QuO middleware to support unpredictable adaptation contract: adaptation control policy selection of “transition” action selection of “contract” region A means to increase attacker’s difficulty w/o increasing the programmer’s difficulty Exploit attacker’s decision points Make use of redundancy [including redundant intrusion response mechanisms] At various levels: application’s level, system management level Effectiveness limited number of available options quantifying the added level of difficulty reinforcing the effectiveness of other mechanisms s s s s s c Contract Example application level : which s is next used if the current one is suspected ? Further escalation will hide the real call among multiple arbitrary calls h h h d2 d1 h h d3 h Example management level : need to start a replica, where? An agreed upon decision collectively made, but hard to predict.

Distributed Management I: Rapid Reaction to Intrusion/Anomalous Conditions snort Adopingtaptive middleware iptables A sensor-actuator loop Prototyping a couple of sensor-actuator loops involving COTS tools such as snort, iptables, tripwire etc. Focused, local, knee-jerk reaction coordinated by the QuO adaptive middleware Snort: IPTables Tripwire:FileMgrActuator: CPUMonitor: -> OSMgrActuator: Gains time against attacks that plant an executable, overload CPU or send signature attack packets in some stage of their life sometimes this may effectively block the attack! Lowest level participant in distributed management manages multiple sensors and actuators different resources/tools Next: investigate unpredictability in this level host Network interface File system CPU/Process Multiple sensor-actuator loops in a host

Distributed Management II: Managing Redundant Resources Implementing ITUA Managers and Subordinates Locus of decentralized coordination and decision-making Replication control, control of security elements deployed in the hosts and security domains Decentralization: good survivability practice Responsibilities Information collection and reporting Decide whether host/domain infiltration has occurred Start application objects “securely” when commanded by manager Initiate replication related adaptation proposal and collectively act on them Decide which replica of replication group to start, kill, migrate

Distributed Management III: Rapid Reaction and Managing Redundant Resources Each host has a subordinate ; one subordinate in a domain is a manager A Sub/Mgr controls the dynamic reorganization of “local” resources and tools Subordinates on a security domain report to a manager A manager sets domain-wide policies that govern subordinates Loops on a host report to an ITUA management component (manager or subordinate) on that host Rapid response buys time for coordinated responses by the managers Distributed control and local decisions  attacker faces different and possibly unpredictable responses on different hosts and domains host Security domain ITUAMgr ITUASub

Distributed Management IV: Distribution and Consistency Security Posture of a domain Dynamically computed by domain manager “Security state” of the domain high, medium, low Operating levels of Sensors and Actuators depend on the domain’s posture Controls sensitivity (sensors) and aggressiveness (actuator) Cost vs. Protection: middleware is the right place for the trade off and coordination policies QuO Managers and Subordinates Gateways and handlers sensor actuator QuO Contract Host level decisions are made at each host Security Domains make decision about the domain in collaboration with the member hosts System Wide Decisions are made by collaboration among domains host Contract domain Other hosts in the same security domain A Sensor-Actuator loop makes its own decision Situational awareness flows up and directives flow down

Protecting Application Objects I: ITUA Group Communication System Bottom Reliable Pt2pt Pt2ptw Local Total Top_appl Stable Vsync Sync ITUA_Group Elect Intra Inter Leave Suspect Heal Top Expanded an existing GCS which tolerates crash failures to tolerate the faulty communication behavior of corrupt objects Based on C-Ensemble and Maestro (C++ interface) Need total ordering and virtual synchrony properties C-Ensemble stack needed to be radically changed: No total ordering was provided (“Total” and “Reliable” provide total ordering) Group membership was not suited to the ITUA environment (Ensemble trusts all members: “ITUA_Group” has been created) Most Ensemble microprotocols needed to be modified to fit the ITUA environment New Modified Unchanged

ITUA GCS Contd: Total Ordering and Group Membership Protocols Total ordering protocol: Global total ordering provided by a globally unique sequence number Each process can check if the sequence number corresponds to the process that has generated the message Very efficient for replicas (processes generating a similar number of messages) Processes that do not need to generate a message will send a NULL message Group membership protocol: A process will be removed if its crash has been detected, if it is slowing down the protocol, or if it is exhibiting “provably bad behavior” Processes can join a group (new process) or rejoin a group (accidental faulty process) Approval of majority of the non-faulty members is necessary for effecting any change to group membership Two types of messages are exchanged: GMP-Messages, which are related to the group membership protocol and contain changes to the membership Normal Messages, which are related to the application execution

Protecting Application Objects II: Replication using Intrusion Tolerant GCS Replicas use the ITUA gateways to interact with each other over the ITUA GCS The gateways: provide reliable remote invocations to replicated objects contain some intrusion tolerance mechanisms Several handlers are needed: In terms of the function of the component (e.g., ITUA object, manager, subordinate) Depending on the intrusions to be tolerated Handler and Gateway implementation is in progress r1 ORB Gateway IIOP TAO ORB ITUA GCS Naming Service Handler Factory DII Processor Create handlers Top Heal Handler for ITUA object -1 Handler for ITUA object -2 Handler for ITUA object -n Suspect Gateway handlers ... Leave Inter ITUA GCS Intra Elect ITUA_Group Sync Vsync Stable Top_appl Total Local Pt2ptw Pt2pt Reliable Bottom

The ITUA Architecture 4 5 3 2 1 A s 1 Sensor-actuator loop 2 Rapid response 3 Subordinate group 4 Manager group 5 Replication group host C M 4 Security Domain host M host S r1 Security Domain 5 host M 3 host S host r1 S s A 1 2 Security Domain

Integration Opportunities What we can use from others: ITUA’s application level protection complements any technology that makes the infrastructure intrusion tolerant, for instance: Can use an Intrusion Tolerant ORB as the basis of our QuO adaptive middleware Can use an Intrusion Tolerant Storage System to store critical data Can use sensors (for instance a better IDS) and actuators (for instance an intrusion tolerant packet filter) that are relevant Can use AO’s elusive interfaces to create more options to support unpredictable adaptation What others can use from ITUA: The ITUA architecture and mechanisms can be used to make distributed CORBA-based applications intrusion tolerant The ITUA unpredictable engagement technique can be used to enhance dynamic reconfiguration mechanisms The ITUA Gateway and intrusion-tolerant GCS can be used in the context of replicated objects and groups Understanding the packaging and boundaries is TBD

Schedule/External Activities 2000 2001 2002 2003 ID Task Name Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 1 ITUA 3 Initial Concept Dev & Proof of concept demo 4 Design & Devlp of Prototype v1 5 Final Prototype & Evaluation results Proof of concept for some components demonstrated External activities: Metrics Workshop DSN Fast abstract NSPW paper