Intrusion Tolerance by Unpredictability and Adaptation Presented by: Partha Pal Ron Watro Franklin Webber Chris Jones William H. Sanders Michel Cukier James Lyons Prashant Pandey Hari Ramasamy David Corman Jeanna Gossett

ITUA: Intrusion Tolerance by Unpredictability and Adaptation Goal –Develop middleware based mechanisms that significantly increase the likelihood a distributed object-oriented application survives the attacks we consider Approach –Use a variety of techniques to keep the application going despite intrusion: Adaptation to cope with changes in environment Redundancy to tolerate different kinds of component failures Unpredictability to thwart attack planning and inflict delays to the attacker Research Agenda –Explore the complementary concepts of unpredictable adaptation and adaptive use of hybrid-mode (crash and Byzantine) fault-tolerance in the context of IT –Build prototype to illustrate the developed concepts and to provide a basis for further design investigation –Evaluate effectiveness of concepts and implementation by modeling and/or experimental techniques

Unpredictable Adaptation for Intrusion Tolerance Introduce uncertainty in adaptations resulting from intrusion response: –Application’s adaptive behavior (e.g. change from one server type to another) –Response of middleware services that manage QoS (e.g. change the type and/or level of replication / communication) –Reconfiguration of system infrastructure itself (e.g. killing processes, changing configuration of a firewall) Expected Benefit: –Attacks that exploit static behavior will be delayed, providing time for other mechanisms to take effect. Ankle-biters will be deterred (anecdotal evidence), but attack prevention is not a goal Dimensions of unpredictable adaptation: –How they are triggered (e.g. reactive or pro-active) –Whether they are a part of the application (in-band) or the system (out of band) –Whether they are aimed at tolerating a specific attack or used to create diversity and stealth in general

Adaptive Hybrid-Fault Tolerant Replication for Intrusion Tolerance Approach –Develop dynamic replication algorithms supporting multiple failure assumptions and dynamic switching among them –Dynamically changeable crash/Byzantine replication and communication algorithms can aid in providing practical IT Malicious attacks may vary in number and type of failures they cause Exclusive use of Byzantine fault-tolerance schemes is expensive Function 1: Management –Receive information from: replication/communication mechanisms themselves, IDSs, resource managers –Make (possibly unpredictable) configuration decisions: type and level of replication, placement of replicas Function 2: Mechanisms –Provide replication and group communication algorithms that can dynamically change between tolerance to crash and Byzantine failures –Allow dynamic entry/exit of replicas

Example Application: Insertion of Embedded Infosphere Support Technologies (IEIST) C2 Node 1 LAN UCAV UCAV # 1 Host UCAV # 1 Host Navigation & Discovery for F15 # 1 Auto Router for F15 # 1 Threat Analysis for F15 # 1 UCAV # 1 Guardian UCAV # 1 Guardian Attack Aircraft F15 # 1 Host F15 # 1 Host Tactical Data Link C2 Node 2 C2 Node 3 Tactical Data Link Tactical Data Link Host Platforms Potential GA Components Potential GA Domains Resource Assignment F15 # 1 Guardian Auto Router for F15 # 1 Navigation & Discovery for F15 # 1 Threat Analysis for F15 # 1 Threat Analysis for F15 # 1 Threat Analysis for UCAV # 1 Threat Analysis for UCAV # 1 Navigation & Discovery for UCAV # 1 Navigation & Discovery for UCAV # 1 Auto Router for UCAV # 1 Auto Router for UCAV # 1

Technical Details 3 views of the ITUA technology Context, scope and assumptions Structure of application and system objects, and organization of groups in the ITUA system Features – Hybrid-fault replication Support and example –Unpredictable adaptation Support and example

ITUA Intrusion Model The ITUA intrusion model consists of –Items: terms and objects, usually abstract, that the model describes –Actions: what can happen to the items –Assumptions: constraints on the actions, expressing limits on the attacker’s capability and properties of the environment –Specifications: desired properties to follow from the assumptions, given a system design Items –Security domains Non-overlapping; boundaries are hard for attacker to cross Are either okay or infiltrated –Processes Two types –Application processes –System processes Are either okay or corrupt

Application Objects and ITUA System Objects in Security Domains Security Domain I Security Domain III Security Domain II ITUA Manager ITUA Subordinate Replicated object o1 Replicated object o2 Replicated object o3 Non-replicated object o4 Non-replicated object o5 Host C Host B Host E Host A Host D Host F

Intrusion Model (Cont.) Actions –Start or stop a process, infiltrate a domain, corrupt a process –Processes compute, communicate Assumptions –A minimum time to infiltrate each domain and to find a domain containing a given kind of process –A limit on number of concurrent attacks (i.e., only “staged attacks” are possible) –Infiltration and corruption may cause arbitrary failures and may be detected by corrupt process behavior or by IDSs –Communication is timed asynchronous Example Specifications –Replication improves an application’s time to failure –Unpredictable adaptation improves time to failure under certain conditions Further details:

Summary: Short Answers to the 3 Questions Which attacks? –Attacks that (in multiple stages) Infiltrate hosts and security domains Kill or corrupt processes Observe and adapt to defensive responses –Attacks implemented at compile time and manifest at run time are not considered What assumptions? –See previous slide, assumptions involve security domains,attack stages, detection and communication What policies? –High level: try to maintain integrity and service availability as long as possible Subject to our assumptions and in the context of the attacks we consider –Auxiliary policies: use QoS specification, constraints on adaptation based on data unlikely to be available to the attacker QoS managers have their own policies: e.g. governing type and number of replication, access control policy etc.

Structure of an ITUA Application Object CORBA Object Group Communication System Gateway Passive Handler - State Cast Passive Handler - Stable Storage Active Handler - Pass First Active Handler - Leader Only Active Handler - Majority Voting Protocols for Tolerating only Crash Failures Protocols for Tolerating only Arbitrary Failures Protocols for Tolerating x Crash Failures and y Arbitrary Failures Application-level Control of Adaptive Middleware  Handlers for tolerating crash failures and value failures  Handler choice based on comparison between computation and communication cost  For passive handlers, tunable parameter of frequency of state multicast/storage  Protocols for tolerating crash and/or arbitrary failures  Tunable parameter of number of crash and arbitrary failures to tolerate  Dynamic switching between protocols  Middleware intercepts all object requests and responses to introduce application-level adaptive behavior  If such adaptation is in response to intrusion, unpredictability can make attacker’s task harder Interface on Standard Network Transport

Structure of ITUA Manager and Subordinate Managers and subordinates are collectively responsible for Gathering security related information Controlling local resources and configurations for security Replication management Security Advising (SecAdv) and Replication Management (RepMan) are two major functional aspects Responsibilities are different for Managers and Subordinates ITUA Manager Group Communication System Gateway Handler for ITUA Manager SecAdvRepMan Interface to standard network transport ITUA Subordinate Group Communication System Gateway Handler for ITUA Subordinate SecAdvRepMan Interface to standard network transport

Organization of Managers and subordinats within a Security Domain Manager Subordinate sensors actuators sensors actuators Subordinate sensors actuators Subordinate sensors actuators Sensors provide information to determine security posture –CPU monitors, network monitors, IDSs, replication mechanisms Actuators control external resources –Firewall, IDSs, OS controls Interpretation of sensed data and reaction to events depend on current security posture

Groups in the ITUA System Security Domain I Host C Host B Host A Security Domain II Host E Host D Security Domain III Host F Security Domain IV Host G Security Domain V Host I Host H Security Domain VI Host L Host K Host J ITUA manager group ITUA subordinate group ITUA subordinate group ITUA subordinate group a replication group

Supporting Adaptive Hybrid-Fault Replication Part of the job of the Security Advisor and Replication Manger components of the ITUA Managers and Subordinates –Using the hybrid-fault tolerant “plumbing” Important Replication Manager functions –In a subordinate Start application objects securely when commanded by manager –In a manager Decide which replica of replication group to start, kill, migrate Decide when to switch between different failure modes Important Security Advisor functions –In a subordinate Collect information from local IDS, monitors Report to manager –In a manager Collect domain wide security info, decide security posture Decide whether host/domain infiltration has occurred

Example Use of Hybrid-Fault Replication/Communication r1 h1 r2 h2 More replicas, Byzantine-tolerance mode r1 r2 h1 h2 Replicated object r tolerates 1 crash Senses network anomaly Informs manager r1 r2 h1 h2 Three replicas, r3 placed hx picked unpredictably r3 hx r2 h2 Depending on domain-wide information, change security posture, increase replication level or switch to Byzantine mode Anomaly persists, reports potential infiltration on H1 to manager Under the new posture, decides to switch r (and other replicated object with replicas on H1) to Byzantine tolerance r2 h2 r5 hn Subordinate on h1 Manager of h1s domain Ready for a potential loss, attacker will first need to find where a new replica is placed Even though the attacker corrupts r1 in an arbitrary way on the infiltrated host, the replicated object r continues: r1 is evicted from the group On demand, adaptive use of expensive Byzantine tolerance => Practical intrusion tolerance!

Supporting Out-of-Band Unpredictable Adaptation Out-of-Band Adaptation –Intrusion response that involves reconfiguration of system resources Requires system privilege –Carried out by the hierarchy of managers and subordinates Via the sensors and actuators –Reconfiguration may take place proactively, subject to cost and interference constraints Inserting uncertainty: use the inherent non-determinism of distributed systems –Likely that different domains will have different postures –Even within a domain different hosts may have different postures Recall interpretation of sensed data and reaction to observed event can depend on the current posture

Example Out-of-Band Unpredictable Adaptation Attacker trying to corrupt an application object (i.e. the replication group). Uses an attack process in host H1. Symptom(s) observed –Anomalies in replication group of the targeted application object or its consumers –Sensors on H1 may pick up CPU or network anomalies Depending on current posture, H1’s subordinate may –Use firewall to control what goes out and comes into H1 –Use access control mechanism to change access control policy of objects in H1 –Kill rogue process in H1 Advantage –Attackers experience in one domain may not work in another May proactively reorganize resource configuration –Subject to performance and interference constraints move files around, use different ports, change scanning interval etc in an unpredictable manner. –Limit attacker knowledge (see US Extra-net for Security Professionals)

Supporting Unpredictability in Application-Level Adaptation Contracts: QuO’s adaptation control mechanism –Region: basis for structuring adaptation inter-object interaction is “adapted” in band (intercepted and modified) depending on the current region –Transition: action on region change Inserting uncertainty: –Unpredictable selection of contract region –Unpredictable selection of transition action Other possibilities to explore: –parameterization, switching the evaluation engine, generating contracts on-the-fly etc. QuO is an adaptive middleware supporting application-level (in-band) adaptation ClientNetworkServer Logical Method Call Client Delegate ORB Proxy Specialized ORB Contract SysCond Object Delegate ORB Proxy Specialized ORB Contract Network Mechanism/Property Manager SysCond

Example Application-Level Unpredictable Adaptation Unpredictable selection of transition actions: one_of { T1: kill all non-application/ non-essential objects on local host T2: talk to a different object T3: start a security scan T4: use cached value (I.e.don’t remote) T5: slow down (I.e. insert sleep before remote) } C1 C3 C2 Unpredictable selection of contract regions: Conceptual operating regions of an adaptive application may overlap: C1 (Host H infiltrated), C2 (Network N infiltrated), C3 (Object O corrupt) Under certain condition any one of the regions may be true. Advantage: If the attacker has partial knowledge about the system and wants to push the application into a desired operating region, he may be surprised to find the application behave in an unexpected way Advantage: If the attacker observed the reaction (that muffled his stage 1) and attempts to re-attack aiming to counter or bypass that reaction, he may see a different reaction this time There may be cases where even with limited, known alternatives, unpredictable selection is a better strategy (game theory results). Current stage Next stage? T1 T2 T3 T4 T5 Corrupt replica is of O, on H and H is in N

Current Status / Next Steps Unpredictable Adaptation –Developed examples and a conceptual framework –Working on extending the framework and a detailed use case for evaluation Adaptive, Hybrid-Fault Tolerant Replication / Communication Algorithms –Developed a strategy of applying adaptive fault-tolerance –Working on algorithms that implement the strategy ITUA Prototype Design –Integrated security domain, replication control, and uncertainty concepts in a unified architecture –Created high-level architecture for evaluating adaptive techniques and unpredictable policies –Detailed designs for adaptive control and unpredictable policy mechanisms –Planning the stages in the implementation Modeling and Validation –Formalized the project scope and assumptions relating to attacks –Investigating ways to validate the effectiveness (via modeling and/or experimental techniques) of ITUA techniques

Schedule/External Activities IDTask Name 1ITUA 3Initial Concept Dev & Proof of concept demo 4Design & Devlp of Prototype v1 5Final Prototype & Evaluation results Q1Q2Q3Q4Q1Q2Q3Q4Q1Q2Q3Q4Q1Q2Q3Q4Q Proof of concept for some components expected at the end of summer External activities: 19th IEEE SRDS: Panel on integrating FT and Security in Distributed Information Systems: Franklin Webber ISW 2000: Position paper: Partha Pal EU-US Joint workshop on intrusion and attack tolerance: Bill Sanders

Back up:Proposed Gateway Architecture Application Object Application CORBA ORB Handler Factory Active handlers pass first leader only majority voting Passive handlers state cast stable storage Handler for replicated obj -1 Hybrid-Fault Group Communication Gateway Gateway handlers Local Area Network IIOP create handlers Handler for replicated obj -2 Handler for Replicated obj -n CORBA ORB Naming Service