1. 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 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. Outline t Assumptions t Background t System Components t The Single Proxy t Mechanisms t Validation and Future Work

3. 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

4. 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

5. Background t Intrusion Tolerant Server

6. Background t Intrusion Tolerant Server u Redundancy & Diversity

7. 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

8. 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

9. 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

10. 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

11. 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

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

13. 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

14. 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

15. 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

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