Intrusion Tolerant Software Architectures

1
Intrusion Tolerant Software Architectures

• Bruno Dutertre and Victoria Stavridou
• System Design Laboratory, SRI International
• Lee Benzinger
• NAI Labs.

2
The Team

• System Design Lab, SRI International
• Victoria Stavridou (PI)
• Bruno Dutertre
• Hassen Saidi
• Bob Riemenschneider
• NAI Labs
• Lee Benzinger
• Jan Filsinger

3
Goal

• An Architecture-Based Methodology for Building
  Intrusion Tolerant Systems
• Key Issues
• Characterization of IT Architectures
• Methodology for Deriving Component IT
  Requirements from System Architecture and
  Security Policy
• Methodology for developing IT Architectures and
  Components

4
Approach

• Hierarchical Architectural Modeling using an
  Architecture Description Language
• Identification of Architectural IT Properties
• System Development via Architectural
  Transformations that are Proven to Preserve IT
  Properties

5
Designed-In Intrusion Tolerance
Abstract architectural specification that
guarantees required intrusion tolerance
properties
Refinement step that preserves required intrusion
tolerance properties
Further intrusion tolerance property-preserving
refinement steps
Result Concrete implementation of architectural
specification has required intrusion tolerance
properties
6
Policies and Enforcement Mechanisms

• Our approach is policy independent in terms of
  architectural level intrusion tolerance
• Policies are specified at the highest levels of
  abstraction
• Enforcement mechanisms are obtained along the
  way, during the transformation process

7
Tasks

• Intrusion Tolerance Ontology
• Definition of Intrusion-Tolerance Levels
• Methodology for Developing IT Architectures
• Methodology for Developing IT Components

8
Tasks (continued)

• Two Case Studies
• IT at System Level GENOA
• IT at Component Level SEAS
• Characterize Intrusion Tolerance Architectural
  Dimensions of GENOA and SEAS

9
Schedule
April 00
Aug. 00
Ontology
IT levels
Dec. 00
Arch. Dev. Methodology
March. 01
Comp. Dev. Methodology
Oct. 01
Nov. 00
GENOA IT Characterization
May 01
SEAS IT Characterization
Oct. 01
10
Risks and Risk Mitigation

• We are dependent on obtaining information about
  GENOA and SEAS
• Mitigation
• SEAS is developed at SRI (AI Center)
• There is interest in Intrusion Tolerance within
  the GENOA program
• Support from GENOA managers

11
Technology Transfer

• Transferable Technology
• Architecture-based development methodology
• Transfer Path
• Intrusion tolerance in GENOA and SEAS
• Transfer to SRIs Emerald system (cf. Al Valdess
  project)

12
Accomplishments and Work in Progress

• Enclaves Example
• Characterization of IT based on Noninterference,
  Formal Verification
• GENOA and SEAS
• Ontology
• Characterization of Architecture-Level IT
  Properties

13
Enclave Example

• Enclaves (Li Gong, 1996)
• Lightweight framework for groupware applications
• Provides secure communication and group
  management services
• Not intrusion tolerant all group members must be
  trustworthy

14
Enclaves Architecture
Member
Member
Member
Session Leader
Member
Member
15
Intrusion-Tolerant Enclaves

• New group-management protocol ensures proper
  service to a user A as long as the Leader is not
  compromised, even if members other than A are
  compromised
• The protocol has been formalized and verified
  using PVS
• Enclaves re-implementation is under way

16
GENOA

• A System for Collaborative Crisis Understanding
  and Management for
• National Security Community
• Includes Commanders of the Unified Commands
• A Set of Tools Supporting
• Knowledge Discovery of Critical Information
• Structured Argumentation (SEAS)
• Detailed Corporate Memory

17
Genoa Layers View
Application Layer
Application
Application
Database
Application
Database
SEAS
Application
Database
Server
Application
Database
Server
Application
Database
Server
Server
Information Layer
Manager
Infrastructure Layer
Manager
Manager
Server
Server
18
SEAS

• Purpose capture and present reasoning from
  evidence to conclusion
• Supports collaboration
• Has different collaboration modes

19
System-Level GENOA IT

• Candidate Policies
• Integrity
• Availability
• Work in Progress
• characterization of architectural IT requirements
  for GENOA

20
IT Ontology

• System modeling based on
• Architecture
• State-transition system to model component
  behavior and system behavior
• Policy/Failure Specification
• Integrity properties dont reach a bad state
• Availability properties dont stay forever in a
  set of bad states

21
Ontology (continued)

• Attacks vs. accidental failures
• Accidental random behavior that leads to a bad
  state (for integrity requirements)
• Attack strategy that ensures that the system
  reaches a bad state
• Component failure
• Deviation from component specification

22
Ontology (continued)

• Critical component
• If component failure immediately leads to system
  failure
• If component can be used to launch an attack on
  the rest of the system (fault propagates)
• What next?
• Determine mitigation/protection mechanisms
• Identify limits on what a failed component can do
  (which attacks are )