An Adaptive Intrusion-Tolerant Architecture

Alfonso Valdes, Tomas Uribe, Magnus Almgren, Steven Cheung, Yves Deswarte, Bruno Dutertre, Josh Levy, Hassen Saïdi

AcknowledgementsResearch 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

Outline

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

Schedule

Adapt

Hacked

Dependable Intrusion Tolerance

Contain

Recover

Online VerifiersCR Protocol

20032001

Tolerance Proxy

Architecture Specification2000

Year 4Year 3Year 2Year 12002

Tolerance Proxy Activator

Proto Phase 1

Proto Phase 2

Quantification Methodology

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

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

Background

Intrusion Tolerant Server

Background

Intrusion Tolerant Server Redundancy & Diversity

Background

Intrusion Tolerant Server Redundancy & Diversity Hardened Proxy

StackGuard Online Verification ensures

operation conforms to spec Small Code Base

Background

Intrusion Tolerant Server Redundancy & Diversity Hardened Proxy

StackGuard Online Verifiers Small Code Base

HIDS/NIDS/app-IDS EMERALD/Snort

Mechanism Summary

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

System Components

Application Servers Solaris, Win2k, RedHat,

FreeBSD

IDS Proxy

RedHat-6.2 Our own code base

MS Win2kIIS

Solaris 8(Sparc5)Apache

eXpert-BSM

RedHat 7.1iPlanet

FreeBSD 4.2Apache

App-IDS

eXpert-NeteBayes-TCPeBayes-Blue

Snort

RedHat 6.2Proxy

eAggregatorC-R

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 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,1 2,2 3,3 4,4

4,3Policy/Regime

Proxy in Detail

e-Aggregator

ChallengeResponse

RepairManager

Proxy ServerRegimeManager

AlertManager

1,1 2,2 3,3 4,4

4,3Policy/Regime

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

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

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

Plans

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