Notional Architecture for Dependable Intrusion Tolerance

1
Notional Architecture forDependable Intrusion
Tolerance

• Alfonso Valdes
• Bruno Dutertre
• Victoria Stavridou
• Yves Deswarte
• January 2001

2
Outline

• Project Overview
• The sensor picture
• Probabilistic alert management
• DIT Architecture
• Tolerance proxy
• Application servers
• Dynamic policy reconfiguration

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
3
Dependable Intrusion Tolerance

• 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)

4
Distributed Tolerance Proxy (Diverse platform/OS)
Diversified Server Bank
Classic Firewall
5
Ideas Adapted from Fault Tolerance

• Faults are inevitable, need to provide service in
  spite of these
• Service is provided in a redundant fashion, but
  on diverse assets
• When fault (possibly malicious) is detected,
  continue to deliver the service (with acceptable
  degradation) from a trusted copy

6
The Sensor Picture
Local Awareness Model-based

• Proof triggers detect deviations from model
  behavior (on-line model checking)
• Active probing (challenge protocol) regularly
  validates server response
• Existing EMERALD sensors
• Detect attacks for which signatures or
  probabilistic models exist
• Host based Reside on all platforms
• Network based Monitor all traffic to and from AS
• Blue Sensor detects asset distress
• Competitive learning detects anomalous global
  states for which no model exists
• Example unusual connectivity patterns
• Cyber Panel inputs update local picture with
  respect to global situation

Global Awareness Weak model assumptions
7
The Sensor Picture (2)
TP
AS
Critical APP
Critical APP
Proof Based Trigger
Proof Based Trigger
EMERALD APP Monitor
EMERALD APP Monitor
Network Interface
EMERALD Host Monitor
EMERALD AMI
EMERALD Host Monitor
Blue Sensor
EMERALD NIDS
Competitive Learning
8
Probabilistic Alert Management

• Introduced in RAID 2000 extended abstract
• One candidate technology to correlate and
  prioritize alert reports
• Correlation functionality adapts concepts from
  multi-sensor data fusion
• Prioritization functionality comprehends attack
  and asset criticality, potentially dynamic in its
  concern profile

9
Architecture Overview

• Intrusion-tolerant system behind a conventional
  firewall
• Client requests are mediated by a bank of
  tolerance proxy servers (TP)
• Responses are from a bank of application servers
  (AS), again mediated by the TP
• The TP enforce protocols to ensure content
  integrity, and maintain availability in adverse
  conditions
• Adverse conditions may or may not be due to
  malicious acts
• Policy dynamically adapts from a benign state
  through increasingly stringent regimes
• TP and AS provide redundant capability but on
  diverse platforms and OS
• Normal operation permits transition to more
  benign regime

10
Diversified Server Bank
HP/UX/Openview Server
Distributed Tolerance Proxy (Diverse platform/OS)
Solaris/Enterprise Server
WinNT/IIS Server
Classic Firewall
Linux/Apache
Tolerance Proxy Server
Challenge/ Response Protocols
Report Consolidation
2
1
Symptomatic anomaly detector
Hardened EMERALD IDS
Firewall Filter Insertion Dynamic Proxy
Configuration HTTP Service Management Sensor
Management
Proof-Based Triggers
11
AS Management Benign Regime

• One designated TP acts as pass through.
• Any TP can assume this function according to a
  fail over protocol
• Requests are distributed among AS according to a
  load balancing scheme
• Full AS capacity is available for client requests
• Occasionally enforce rotating 2-1-1 where some
  percent of requests require agreement of 2
  servers
• Other TP execute challenge-response protocol
• All TP host alert management interfaces,
  monitoring the AS, the network, themselves, and
  the other TP
• This regime is in effect in the absence of
  adverse reports
• From sensors, challenge/response,pass-through
  monitoring, or cyber panel

12
Policy Response Tradeoff

• Under normal operation, redundancy and agreement
  protocols are NOT in effect
• Small possibility of providing faulty content
  between a successful attack and the policy
  response
• Seems a good tradeoff to provide full AS capacity
  most of the time
• Will explore cost-benefit models for response
  selection
• Assess systems present state, and value of that
  state
• Model transitions from this state to subsequent
  acceptable, undesirable, or catastrophic states,
  each with a value
• Any response has an associated cost. The response
  affects the distribution of subsequent states
  obtained
• Choose response action with most desirable value
  to cost
• Improper response can itself bring about DOS!

13
Tolerant Proxy Server Alert Management

• EMERALD AMI Adapted for Report Aggregation/Policy
  Activation
• Probabilistic and heuristic methods considered
• Some alert reports increase overall suspicion
  level
• Policy response must not overreact
• Maybe the attackers purpose with a nuisance
  probe is to force a more stringent policy
• Step up monitoring (higher overhead protocol
  monitors, finer sampling of event streams)
• Some alert reports (detection of host compromise
  or corrupt content) motivate a more serious
  response

14
Sample Policy Responses

• Probes
• Raise concern level slightly. Utility of probes
  may be limited because of NAT.
• Block source IP for some time interval.
• Compromise of AS (if attack stops short of
  corrupt content or full compromise)
• Enforce increasingly stringent content agreement.
  
• Rebuild suspect AS from read-only media.
• Repair vulnerability
• Policy also changed in response to external cyber
  panel input
• A period of normal operation causes a return to
  the next less stringent regime

15
TP/AS ConnectivityBenign Policy

• TP 2 is pass through
• Other TP issue challenge protocols, support
  monitoring
• A client request goes to one AS according to load
  balancing
• Any AS can handle a request (here, 2 responds)

Application Server Bank (AS)
Tolerance Proxy Bank (TP)
Firewall
Client request/reply Monitoring and
challenge/response
16
TP/AS Connectivity Duplex

• A client request goes to two AS (here, 1 and 3)
• Response goes to two TP
• Agreement protocol is invoked
• Validated message is returned to client

Application Server Bank (AS)
Tolerance Proxy Bank (TP)
Firewall
Client request/reply Monitoring and
challenge/response Content agreement protocol
17
TP/AS Connectivity Full Agreement

• A client request goes to all AS
• Agreement protocol is invoked
• Validated message is returned to client
• If one AS disagrees, AS recovery for it
• If no majority, AS recovery for all

Application Server Bank (AS)
Tolerance Proxy Bank (TP)
Firewall
Client request/reply Monitoring and
challenge/response Content agreement protocol
18
Summary

• Exploring synthesis of intrusion detection,
  formal methods, and fault tolerance to develop an
  intrusion-tolerant architecture
• Detection/diagnosis provided by distributed
  components from conventional IDS
• Tolerance based on redundant capability on
  diverse platforms and OS
• Policy steps through increasingly stringent
  agreement protocols as well as reconstruction of
  assets
• Response to adverse conditions ensures integrity
  and availability, as well as to rebuild affected
  assets