Dependable Intrusion Tolerance

1. Dependable Intrusion Tolerance Alfonso Valdes (valdes@sdl.sri.com) Magnus Almgren, Dan Andersson, Steve Cheung, Bruno Dutertre, Yves Deswarte, Hassen Saïdi,Tomas Uribe July 2001 Acknowledgements Research sponsored under DARPA Contract N66001-00-C-8058. Views presented are those of the authors and do not represent the views of DARPA or the Space and Naval Warfare Systems Center

2. Intrusion Detection to Date Seeks to detect possibly infinite number of attacks in progress Relies on signature analysis and probabilistic (including Bayes) techniques Response components immature No concept of intrusion tolerance New Emphasis Detection, diagnosis, and recovery Finite number of attacks or deviations from expected system behavior Seek a synthesis of intrusion detection, unsupervised learning, and proof-based methods for the detection aspect Concepts from fault tolerance are adapted to ensure delivery of service (possibly degraded) Dependable Intrusion Tolerance

3. Outline • Architecture overview • Initial implementation experience • Simulation analysis of response tradeoffs (5 minute talk at Oakland Conference) • On-line verifiers (Tomas Uribe/Hassen Saïdi)

4. EMERALD Network Appliance Sensor Subnet Proxy-AS Subnet External traffic e Architecture App Server App Server Proxy App Server e e2 App Server

5. Archtecture (2) Proxy App Server Proxy App Server Proxy App Server e e2 App Server Proxy EMERALD Network Appliance Sensor Subnet Proxy-AS Subnet External traffic e

6. Application Server Application Server Application Server Critical APP Critical APP Critical APP Application Server Proof Based Trigger Proof Based Trigger Proof Based Trigger Critical APP EMERALD APP Monitor EMERALD APP Monitor EMERALD APP Monitor EMERALD APP Monitor EMERALD Host Monitor EMERALD Host Monitor EMERALD Host Monitor EMERALD Host Monitor The Sensor Picture Note: The Net appliance has a passive interface for the network traffic. Net appliance and app servers have write-only access to sensor subnet (for alert reporting). Proxies use sensor subnet for alert reporting and management. Tolerance Proxy Proxy function On-Line Verifier EMERALD Host Monitor EMERALD AMI IDS Network Appliance eBayes-TCP Blue Sensor e Net Experts Correlation

7. Proxy Implementation • Built as module in Squid proxy • Squid functionality: • Accept HTTP connection • Read client HTTP request • Check ACLs • Load balancing • Send reply to client • New functionality • Interface to sensor subsystem to change policy if needed • Check content agreement (depends on dynamic policy) • Alert the sensor subsystem if content disagrees

8. Ensuring Correct Content • In agreement modes, we compare content from more than one APP server • For efficiency and bandwidth, we actually check MD5 checksums for all polled servers • If these agree, we obtain content from one of the servers and actually verify the MD5 at the proxy • If this agrees with the previous MD5 check, the content is forwarded to the client • For efficiency, we get MD5 only from all but one and MD5 plus the full body of the request from the remaining server. Then if the tests succeed, the proxy already has the content and we save one request

9. Four policy levels • Benign - 1 GET request • Duplex (default regime at system start) • 1 HEAD (get MD5 only) and 1 GET (MD5 plus content). • If MD5 agree, send content to client • Otherwise, go to Triplex • Triplex - • 2 HEAD- and 1 GET-request. • If MD5 all agree, send content to client. If majority obtained, consider minority AS COMPROMISED. Send content to client, rebuild AS, continue Triplex • Full Agreement - Not implemented yet • Transition to a more permissive regime after some time of normal activity

10. Simulation Analysis • System is modeled as 14 Poisson processes • Processes include client requests, server replies, challenge/response requests (from proxy, to assess content validity), random failures, attacks (which make transitions between attack states), IDS false alarms, IDS detections,... • Process rates are state dependent • Requests, attacks, failures always ON. Response process is ON if there are active requests. False alarms are always ON, detections are ON if there are active attacks in a detectable state. • System performance is based on true state. Tolerance response is based on sensor reports • Responses include various levels of content agreement as well as server reboot • Objective: Minimize dropped requests and requests with invalid replies (the latter come from a root-compromised app server) • All tolerance responses have a cost with respect to these objectives, but not responding can also cost

11. Initial Results • Requests arrive at 1000/unit time. Total reply capacity is 4000/unit time. Attack rate is 50/unit time. • Redundancy is beneficial, but diminishing returns beyond 2 App Servers (Total server capacity is 4000/unit time) • Frequent challenge/response requests improve system objectives

12. Status and Plans • Status (end of year 1) • Architecture definition • Continually refining specification • Clarification of the sensor landscape • Initial implementation of Single proxy system (static content) • Specification of on-line verifiers • Plans - • Multi-proxy system • Additional protocols such as challenge/response • Dynamic Content • Implement on-line verifiers

13. Summary • Exploring response tradeoffs as part of a larger dependable intrusion tolerant system study • Explicitly model shortcomings of foreseeable IDS technology with respect to false alarms, missed detections, inaccuracy, and delay • Considering emerging correlation and asset distress monitoring technologies • Recognize that actions have a cost, but no response has a cost as well • Gives some idea of value of redundancy, enforcing agreement, rebooting servers, etc. with respect to some figure of merit

14. (Backup) Poisson Processes • Poisson process: Event stream where inter-event times have an exponential distribution. Parameter is referred to as the process rate, typically denoted l • Mathematical properties of multiple simultaneous Poisson processes lead to tractable implementation: • Overall process is Poisson, with overall rate equal to the sum of the rates of the individual processes • Next event is of a given class with the following probability:

15. Proxy Capabilities Simulated • IDS detect probes and root compromises, but occasionally fail to detect or are too slow, or generate false alerts • Asset distress monitor (blue sensor) can detect a “down” server by rate of failed requests • Proxy detects AHBL when request queue overflows • Challenge/Response: Periodically issues a request to all servers, for which the reply is known • Can detect compromised server if reply is invalid • Can detect a “down” server • These detections are typically much later than from an IDS • Available responses are: • Invoke a content agreement regime for client requests with 2..n servers • Reboot a server

16. Processes and Rates Note: Time units not specified. These rates should be viewed as relative.