SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Service

1
SITAR A Scalable Intrusion Tolerant Architecture
for Distributed Service

• Fengmin Gong, MCNC
• Kishor Trivedi, Duke University
• July 20, 2000

2
Outline

• Existing Practice
• Objectives
• Ideas Architecture
• Challenges Capabilities
• Expected Impact
• Evaluation/Metrics
• Current Status
• Schedule
• Observations

3
Limitations of Existing Approaches

• Focused on the Means of Attacks
• Lead to IDS that is poor at dealing with variants
  or new attacks unpredictability or
  sophistication of attackers
• Focused on the Statistical Norm of Systems
• Still a big challenge to identify the right
  measures to learn the normal behavior
  unacceptably high false-alarm rates
• Time to focus more on the Ends
• What systems need to be protected
• What are the service objectives for the systems

4
Project Objectives

• Develop an architecture for building
  intrusion-tolerant systems
• Useful for building all-new systems
• Useful for creating intrusion-tolerant systems
  out of existing COTS
• Useful for i-hardening existing systems
• Develop methods for applying existing
  fault-tolerant approaches to intrusion tolerance,
  e.g. how to perform acceptance test on a generic
  information server

5
Objectives Contd

• Develop solutions to deal with the problem of
  dynamic faults caused by compromised components
  and external attacks
• A compromised component may exhibit behavior
  that is totally unpredictable
• External attacks (e.g. denial-of-service) may
  come in many forms and at arbitrary times

6
Innovative Ideas

• Focus on one generic class of service
  (network-distributed services built from COTS
  components) as the target for protection
• Focus on three challenges
• How some of the very basic techniques of
  fault-tolerance (e.g., redundancy and diversity)
  apply to our target
• How do we deal with the external attacks (dynamic
  malicious faults) and compromised components,
  which exhibit very unpredictable behavior
  compared to accidental or (static) malicious
  faults
• Metrics and evaluation

7
Innovative Ideas Contd

• Apply dynamic reconfiguration strategies based on
  an intrusion-tolerance model
• Use model-based (analysis and simulation) and
  measurement-based approaches to evaluate the
  security of the architecture and to carry out
  cost-benefit tradeoff studies

8
ITS Architecture
Protected
Users/Clients
9
Low-Overhead Configuration
10
High-Tolerance Configuration
11
Study, Design Prototype

• Study accidental vs. malicious faults
• Develop a model of intrusion-tolerance
• Threat model
• ITS architecture
• Analytical/simulation-based tradeoff studies for
  different strategies
• Create a prototype intrusion-tolerant Web server
  system (USC Emergency Management System)
• Evaluate the prototype through experimental
  measurements/simulation/analytical models

12
Specific Challenges

• Proxy servers
• Maintain up to date consistent state for
  on-going requests
• Efficient migration of the service context
• IDS request load control
• Multicast, shared memory, JavaSpaces
• Acceptance Monitors
• Check the reasonableness of results
• Trust-state monitoring of the COTS servers

13
Specific Challenges contd

• Ballot Monitors
• Transformations of complex results required
  before voting/adjudication
• Choice of checksum, secure hash, etc.
• Voting/adjudication algorithm must work correctly
  with all monitor configurations e.g., all
  monitors on one processor, one monitor per
  processor
• Trusted announcer of result e.g., fixed
  designated, dynamic election, parallel
  independent reports

14
Specific Challenges contd

• Audit control
• Verify the audit records to detect abnormal
  behavior in the components by conducting periodic
  diagnostic tests
• Maintain audit logs of all system components
• Conduct diagnostic tests of all components
• Initiated by system administrator
• Configured periodic/on-trigger

15
Specific Challenges contd

• Adaptive Reconfiguration
• Automatically enforces security policies by
  reconfiguring the system in the presence of
  accidental malicious faults
• Current states of servers
• Current workload on the servers
• Service security requirements IT Policies
• Available intrusion tolerant strategies
• Resource availability - COTS servers other
  modules

16
Capabilities of MCNC Team

• MCNC
• Successfully developed ID prototypes for
  detecting coordinated attacks based on
  comprehensive approaches, for tracing intrusion
  sources JiNao, GIANT Deciduous, funded by
  DARPA/ITO/ISO
• Completing security management prototype for
  survivable end-to-end network security services
  Celestial, DARPA/ITO

17
Expected Impact

• To end users
• An architecture for building scalable
  intrusion-tolerant services out of COTS systems
• A prototype Web server system for providing
  intrusion tolerant services
• Research benefits
• Study of architecture for building general
  intrusion-tolerance services in a networked
  environment
• Tools (analytical and simulation) and algorithms
  for applying general fault-tolerant techniques to
  intrusion tolerance

18
Current Status

• Contract signed at the end of 6/00! ?
• Duke subcontract signed last week
• SITAR-team bi-weekly meetings will start before
  the end of July

19
Schedule Milestones (7/00)
20
All Comments Welcome!

• Thank you for your attention!
• Contact SITAR team
• Dr. Fengmin Gong, Fmg_at_anr.mcnc.org
• Dr. Prof. Kishor Trivedi, Kst_at_ee.duke.edu
• www.anr.mcnc.org/projects/SITAR

21
Observations

• Similarities to SCC, Draper Lab, Teknowledge
  projects
• Use redundancy, masking, diversity principles
• Use new trusted components to provide tolerance
  capability
• Use intrusion detection triggers

22
Observations contd

• Main differences from SITAR perspective
• Acceptance Monitor modules used for
• acceptance testing as the first step detection
• Stateful detection as a second step detection
• Proxy Server modules used to facilitate
• Dynamic policy-based intrusion-tolerant services
  with user (client) transparency
• Future integration of new server components
  protocols (e.g., new Proxy-Server protocol to
  enable finer-grain service migration)

23
Observations contd

• Full range of configurable strategies for
  intrusion tolerance
• Degree of physical-server redundancy with
  diversity
• Simple voting to more sophisticated adjudication
  (e.g., with respect to server behavior history)
  by Ballot Monitors
• Multiple strategies for trusted-announcer
  selection
• Simulation analytic approaches to evaluate the
  ITS architecture and the prototype

24
Capabilities of Duke Team

• Development of fast algorithms for the solution
  of fault-trees, Markov chains, stochastic Petri
  nets
• Tools (SHARPE, SPNP) development dissemination
• Applications of the above to computer systems
  networks
• Software reliability growth modeling tool SREPT
• Software rejuvenation (analytic and experimental
  approaches plus implementation in IBM Netfinity)

25
FTS Evaluation (Metrics)

• Fault model
• Types of faults
• Treatment (handling procedure) for each
• Occurrence rate (1/mean time to failure)
• Fault injection simulations to estimate
• Probability (coverage) delay of detection
• Probability (coverage) delay of reconfiguration
• Analytic model to combine the data from the fault
  model and fault injection simulations to
  determine
• Mean time to system failure (reliability)
• Mean downtime (availability)
• Degraded time (performability)
• Using fault trees, Markov chains, stochastic
  Petri nets
• Performance overhead due to FTS
• Software reliability growth modeling during
  testing

26
ITS Evaluation (Metrics)

• Threat model
• Types of attacks
• Treatment (handling procedure) for each
• Probability of occurrence
• Occurrence rate (1/mean time to failure)
• Intrusion injection simulations to estimate
• Probability (coverage) delay of detection
• Probability (coverage) delay of reconfiguration
• Overall coverages and delays using ftrees or
  dtmcs
• Analytic model to combine the data from the
  threat model and intrusion injection simulations
  to determine
• Mean time to undesirable event (reliability type
  analysis)
• Mean downtime (availability type analysis)
• Degraded time (performability type analysis)
• Using fault trees, Markov chains, stochastic
  Petri nets
• Performance overhead due to ITS
• Software reliability growth modeling during
  testing of ITS