1 / 16

An Adaptive Intrusion-Tolerant Architecture

An Adaptive Intrusion-Tolerant Architecture. Alfonso Valdes, Tomas Uribe, Magnus Almgren, Steven Cheung, Yves Deswarte, Bruno Dutertre, Josh Levy, Hassen Saïdi. Acknowledgements

mackensie-short
Télécharger la présentation

An Adaptive Intrusion-Tolerant Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  3. Dependable Intrusion Tolerance New Ideas Contain • Detect cyber system deviation resulting from attacks, • Contain the attacked resource, • Adapt system resources, and • Recover lost functionality over time Adapt Recover Hacked Schedule Impact • 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 • Attacker does not have physical access • Flood/overrun attacks are not addressed • Not all replicates are vulnerable to the same attack • No attack can simultaneously compromise more than a critical fraction of the COTS Servers • Correct servers all give the same answer to a given request • Focus is on integrity and availability, but system is compatible with mechanisms for confidentiality

  5. Background • Intrusion Tolerant Server

  6. Background • Intrusion Tolerant Server • Redundancy & Diversity

  7. Background • Intrusion Tolerant Server • Redundancy & Diversity • Hardened Proxy • StackGuard • Online Verification ensures operation conforms to spec • Small Code Base

  8. Background • Intrusion Tolerant Server • Redundancy & Diversity • Hardened Proxy • StackGuard • Online Verifiers • Small Code Base • HIDS/NIDS/app-IDS • EMERALD/Snort

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

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

  11. 1,1 2,2 3,3 4,4 Agreement Policies • Benign - Each request dealt to one app server • Duplex (default regime at system start) - Each request sent to two app servers • Triplex - Each request sent to three app servers • Quad - Each request sent to four app servers • Transition to a more permissive regime after some time of normal activity Policy/Regime 4,3 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.

  12. e-Aggregator RegimeManager AlertManager ChallengeResponse Proxy Server RepairManager Policy/Regime 1,1 2,2 3,3 4,4 4,3 Proxy in Detail

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

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

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

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

More Related