Dependable Intrusion Tolerance

1
Dependable Intrusion Tolerance

• Alfonso Valdes
• Victoria Stavridou
• Yves Deswarte
• Hassen Saïdi

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

3
Ideas Adapted from Fault Tolerance

• Faults (including malicious faults) are
  inevitable, need to provide service in spite of
  these
• Faults are manifest in errors
• Ideally, detected before they lead to failure
• Service is provided in a redundant fashion in
  spite of error
• Distributed server bank
• Diverse platforms/OS

4
Reusable Architecture
Diversified Server Bank
Distributed Tolerance Proxy (Diverse platform/OS)
HP/UX/Openview Server
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
1 Firewall Filter Insertion 2 Dynamic Proxy
Configuration 3 HTTP Service Management 4 Sensor
Management
Proof-Based Triggers
5
Complementary Architecture Components

• Proof based triggers Formal models used on-line
  to provide continuous checks
• Intrusion detection (EMERALD signature
  components)
• Competitive learning (Symptomatic Anomaly
  Detection) monitors the delivered service for
  unanticipated QOS deviations
• Challenge/response Protocols present a request of
  the service bank for which the reply is known
• Components are on diverse platforms and OS

6
Proof-Based Triggers (Formal Models used On-Line)

• Policy is captured within a formal framework
• High-level policy is decomposed into proof-based
  triggers
• Triggers detect departures from policy
• Policy dynamically changes through the policy
  activator
• Due to triggers, or
• Response to manual selection
• Which triggers are active depends on policy
  variant in effect (e. g. INFOCON level)

7
Challenge/Response

• Periodically submitted by Tolerance Proxy to each
  component
• Frequency of challenge can change according to
  policy
• Challenge is a random number
• Response is computed from this challenge and an
  integrity check on the component

8
Diagnosis

• Alarm/anomaly reports from diverse sources
• Forwarded to distributed tolerance proxy service
• Tolerance proxy components consolidate reports,
  resolving conflict as needed
• The aggregate decision of the tolerance proxy
  components must itself be validated
• Response, if warranted, is jointly determined
• Desired conclusions from inference
• Intrusion or anomaly has been detected
  (confidence of detection?)
• Component has been compromised (confidence in
  component?)
• Server is down

9
Response/Recovery

• Error masking Reliably determine and deliver
  valid response in case of non-agreement, if
  possible.
• Client is unaware of error
• Identify and repair suspicious component
• Failed Server Reboot, perform integrity checks
  on content
• If source of intrusion is reliably identified,
  reconfigure firewall dynamically to block this
  (for some time interval)
• Failed tolerance proxy server Restart, rebuild
  its state dynamically from its peers

10
Risks/Mitigation

• Formal representation of adaptive policy
• Sufficiently similar to formal representation of
  requirements
• Inference of root causes
• Remains an unsolved problem in ID domain
• Accurate diagnosis of symptoms may be adequate
  for acceptable recovery
• Attacker has intent
• Makes correlation problematic
• Address by diversity of platforms/software of
  distributed components
• Tolerance proxy represents a major innovation
• Implementation of additional capability in stages

11
Tech Transfer

• Transferable components
• Intrusion-tolerant EMERALD
• Intrusion tolerant architecture
• Tolerance proxy
• Resilient web server configuration
• Transfer mechanisms
• Committed to delivering prototypes to DARPA and
  commercial sites
• Participation in IETF - ID working group

12
Schedule

• Year 1
• Architecture specification
• Adapt ID components (harden, make intrusion
  tolerant)
• Competitive learning component
• Year 2
• Tolerance proxy V. 1
• Resilient web server, static content
• Year 3
• Tolerance Proxy V. 2 Policy activator
• Resilient web server, dynamic content