An Adaptive Intrusion-Tolerant Architecture Alfonso Valdes, Tomas Uribe, Magnus Almgren, Steven Cheung, Yves Deswarte, Bruno Dutertre, Josh Levy, Hassen Saïdi Acknowledgements Research sponsored under DARPA Contract N C Views presented are those of the authors and do not represent the views of DARPA or the Space and Naval Warfare Systems Center

Outline t Assumptions t Background t System Components t The Single Proxy t Mechanisms t Validation and Future Work

Schedule Adapt Hacked Dependable Intrusion Tolerance Contain Recover New Ideas Impact  Detect cyber system deviation resulting from attacks,  Contain the attacked resource,  Adapt system resources, and  Recover lost functionality over time  Assures integrity and availability of mission critical content provision services such as plan distribution  Critical service providers function even when under attack  Distributed content is accurate, despite hacker’s malicious changes  Automatic recovery lets operators focus on primary mission

Assumptions t Attacker does not have physical access t Flood/overrun attacks are not addressed t Not all replicates are vulnerable to the same attack t No attack can simultaneously compromise more than a critical fraction of the COTS Servers t Correct servers all give the same answer to a given request t Focus is on integrity and availability, but system is compatible with mechanisms for confidentiality

Background t Intrusion Tolerant Server

Background t Intrusion Tolerant Server u Redundancy & Diversity

Background t Intrusion Tolerant Server u Redundancy & Diversity u Hardened Proxy l StackGuard l Online Verification ensures operation conforms to spec l Small Code Base

Background t Intrusion Tolerant Server u Redundancy & Diversity u Hardened Proxy l StackGuard l Online Verifiers l Small Code Base u HIDS/NIDS/app-IDS l EMERALD/Snort

Mechanism Summary t Proxy u Limits access to app servers u Sanitizes some suspicious requests t IDS u Detect attacks, anomalous traffic u Trigger response mechanism t Adaptive agreement policy u Corroborates response to client u Identifies malfunctioning servers t Challenge-response u Integrity and liveness u Triggers response mechanism t On-line verification u Ensures correct proxy functionality u Triggers response mechanism t Periodic reboot

System Components t Application Servers u Solaris, Win2k, RedHat, FreeBSD t IDS t Proxy u RedHat-6.2 u Our own code base MS Win2k IIS Solaris 8 (Sparc5) Apache eXpert-BSM RedHat 7.1 iPlanet FreeBSD 4.2 Apache App-IDS eXpert-Net eBayes-TCP eBayes-Blue Snort RedHat 6.2 Proxy eAggregator C-R

Agreement Policies t Benign - Each request dealt to one app server t Duplex (default regime at system start) - Each request sent to two app servers t Triplex - Each request sent to three app servers t Quad - Each request sent to four app servers t Transition to a more permissive regime after some time of normal activity Policy regime is specified as (N, K), N servers are polled, K must agree. (3,3) is the regime obtained if (4, 3) is in effect and one server is diagnosed faulty. While it is repaired, full agreement is required of the rest. 1,12,23,34,4 4,3 Policy/Regime

Proxy in Detail e-Aggregator Challenge Response Repair Manager Proxy Server Regime Manager Alert Manager 1,12,23,34,4 4,3 Policy/Regime

Response t Temporarily blocking the address from where attack seems to originate t Increasing agreement regime t Increasing frequency and coverage of challenge-response protocol t Disconnecting and rebooting a server t Refusing service and alerting the sys admin

Publications and Presentations t “Dependable Intrusion Tolerance”, Tenth Annual Conference on Security Protocols, Cambridge, UK, April 02 t “An Adaptive Intrusion Tolerant Server Architecture” Workshop on Intrusion Tolerant Systems, DSN02, June 02 t “Combining Monitors for Run-Time System Verification”, Workshop on Runtime Verification (RV'02) International Conference on Computer Aided Verification, Copenhagen, Denmark, July 02 Electronic Notes in Theoretical Computer Science, vol. 70, number 4

Validation t Diversity u Direct detection on external network (IDS sensors) u Symptom detection on the private network (proxy) u Agreement u Challenge response protocols t Performance u Preliminary Results t Resistance to attacks u Compiling a list of existing Web exploits to run them against the implementation u Formal verification of appropriate components u Red teaming

Plans t Address dynamic content t Refine alert, detection, response mechanisms t Validation and experimentation t Transition