Intrusion Tolerant Software Architectures

1
Intrusion Tolerant Software Architectures

• Victoria Stavridou
• System Design Laboratory
• SRI International
• victoria_at_sdl.sri.com
• [phone]

2
The team

• Victoria Stavridou, Bruno Dutertre, Hassen Saidi,
  Bob Riemenschneider
• Dependable System Architecture Group,
• System Design Lab
• SRI International
• Jan Filsinger
• NAI Labs

3
Topics

• Intrusion tolerance
• Software architectures
• Intrusion tolerant software architectures
• Noninterference and intrusion tolerance
• Summary

4
Design for Security Assurance

• Dependability impairments (IFIP WG 10.4)
• fault error
  failure

5
Design for Security Assurance
Removal
Prevention
Tolerance
Avoidance
Avoid introducing vulnerabilities (good system
and s/w engineering, security engineering, SEI/CMM
, SSE-CMM, formal methods)
Numerous potential vulnerabilities
Tolerate unknown/too expensive to
fix vulnerabilities
Remove known vulnerabilities (Test, analysis,
VV)
6
Intrusion Prevention/Detection/Tolerance

• Intrusion prevention is reactive
• Statically deploys firewalls and anti-virus
  software to stop the exploitation of known
  vulnerabilities
• Intrusion detection is reactive
• Builds mechanisms to detect and alert
• Intrusion tolerance is proactive
• Design/engineering focus
• Borrows concepts from the software and safety
  engineering communities
• Helps with those unforseen little difficulties

7
Intrusion Tolerance Objectives

• After an intrusion detection mechanism has
  located an intrusion, maintain an acceptable (but
  possibly degraded) level of service
• Contain and expel intruder
• Minimize impact of penetration on system
  integrity
• Determine and report the vulnerability exploited,
  so that it can be removed or blocked
• Collaborate with IDS to produce more
  sensitive/intelligent detection
• Provide measured response

8
Intrusion/fault tolerance mechanisms

• Intrusion detection /location (IDS sensor
  correlation, byzantine agreement with
  authentication algorithms, trigger deployment)
• Intrusion containment (secure compartments,
  reconfigure architecture to isolate bad guy, eg
  IDIP/Schnackenberg)
• Intrusion mitigation (reconfigure architecture to
  minimize stolen resources and disable
  inappropriate information flows)
• Intrusion recovery (extended/distributed recovery
  regions, reconfigure architecture with backwards
  or forwards roll to eliminate the impact of the
  bad guy)

But redundancy management, tradeoffs and
independence are open issues On the other hand
its much easier to deal with consequences of
faults!
9
Topics

• Intrusion tolerance
• Software architectures
• Intrusion tolerant software architectures
• Noninterference and intrusion tolerance
• Summary

10
Security in theory and practice

• Research community has emphasized mathematical
  modeling of security properties which can be
  hard to relate to actual systems
• Commercially available systems not formally
  linked to security theory so its hard to
  determine whether they actually have the desired
  properties
• We replace the abstract mathematical models by
  structured architectural models that still
  emphasize formal analysis but are easier to
  relate to actual systems.
• We advocate lightweight formal methods Design a
  lot, specify some and prove a little

11
Software architectures

• Bridge the gap between requirements and
  implementation
• Support composition and evolution at the design
  level
• Characterize families of applications with shared
  characteristics
• Provide design-level abstractions, patterns and
  styles
• Provide generic, reusable solutions with
  guaranteed benefits

12
Architectural description concepts

• Languages Specification languages for
  architectures
• Components Loci of computation and storage
• Connectors Communication mechanisms
• Constraints Configuration, other properties
• Styles Collections of constraints (ontologies)
• Dataflow, client-server, blackboard
• Patterns
• Hierarchies

13
Software architecture hierarchies

• Manage complexity
• Explore design options
• Support incremental rearchitecting
• Exploit and support modularity

Hierarchies bridge the gap between abstract
architecture and concrete code
14
Security assurance by construction
Abstract architecture
Architecture Hierarchy
Security Preserving Transformations
Implementations
Example X/Open Secure Distributed Transaction
Processing A provably secure implementation
15
Security assurance by construction

• Means that
• A security vulnerability that does not exist in
  the abstract
• architecture cannot be introduced into any
  intermediate
• concrete architecture in the hierarchy
• Benefits
• Eliminate whole classes of concerns
• Focus security analysis at the highest level
• Higher quality, higher security assurance result

16
Structural Architecture Description LanguageSADL

• Specific and generic architectures
• Architectural styles, mappings,implementation
  patterns
• Architecture alternatives thru hierarchies
• Interoperability with other ADLs (ACME)
• Interfaces with PVS for theorem proving

17
SADL Toolkit
PVS
ACME Studio
AST to SADL object
ADL parsers
SADL object base

SADL object to AST
ADL printers
TOOL n
18
Topics

• Intrusion tolerance
• Designing for security assurance
• Software architectures
• Intrusion tolerant software architectures
• Noninterference and intrusion tolerance
• Summary

19
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
20
Intrusion Tolerant Software Architectures
The project goal To enable the creation and
evolution of intrusion tolerant, software
architecture hierarchies
21
Example X/Open Secure Distributed Transaction
Processing

A provably secure implementation
Validated refinement step replace secure
channels by ordinary ones security filter
Level 0
Additional validated refinement steps leading to
implementation level architecture
Level 2
Level 1
Validated refinement step decompose security
filter
22
Intrusion Tolerant Software Architectures

• Tasks
• Develop an IT ontology
• Develop a risk based set of IT levels
• Develop an approach to the creation and evolution
  of IT
• software architectures
• Develop an approach to the creation of IT s/w
  components
• Refine by applying to a realistic architecture
• (GENOA)

23
Approach

• Define abstract architectural intrusion tolerance
  properties (types and levels)
• Non interference, secure composition, node data
  integrity, stability,
• Define mechanisms for ensuring those properties
• IT triggers, integrity marks, bounded
  reconfiguration,
• Prove abstract architectural specification has
  required intrusion tolerance properties
• Prove architecture refinement steps that lead to
  the implementation instrumented with IT
  mechanisms preserve required intrusion tolerance
  properties
• Apply this approach to an IA architecture (GENOA)

24
Topics

• Intrusion tolerance
• Software architectures
• Intrusion tolerant software architectures
• Noninterference and intrusion tolerance
• Summary

25
Noninterference as an IT property

• From security to safety and back
• Can be used in two distinct ways
• as a characterization of secure compartments
• as a characterization of intrusion tolerance
• Hypothesis Can be captured as an emergent system
  property that can be preserved through an
  architecture hierarchy
• Key idea Tolerate deviations from required
  behavior within specified limits

26
Application level IT
Application nodes
Network
External nodes
27
Model

• Labeled transition systems
• Communication network
• Application nodes
• Fault model
• Intrusion tolerance is observational equivalence
  (within predefined tolerances) of healthy vs
  compromised system wrt a set of critical events

28
Topics

• Intrusion tolerance
• Software architectures
• Intrusion tolerant software architectures
• Noninterference and intrusion tolerance
• Summary

29
Summary

• Problem
• Systems will always contain unexpected
  vulnerabilities
• This is exacerbated by complexity and acquisition
  trends (COTS, mobile code)
• Solution
• Tackle the problem at the design level
• Use measured response and software architectures

30
Backup
31
How do we get there?

• Focus on GENOA as the experimentation target
• Rich problem set
• Information assurance investment
• There is still time to influence the design
• Define intrusion tolerance properties
• Focus on integrity and availability requirements
• Work out the tradeoffs
• Use software architecture models

32
Outcomes

• An intrusion tolerance ontology
• A risk-based approach to intrusion tolerance
  level definition
• Technology for developing, evolving, and
  maintaining intrusion tolerant software
  architectures
• Architectural style definitions that make
  specification of intrusion tolerant architectures
  more straightforward
• A library of refinement patterns known to
  preserve key intrusion tolerance properties
• Easy-to-apply lightweight techniques for
  verifying that patterns preserve intrusion
  tolerance
• Technology for developing, evolving, and
  maintaining intrusion tolerant components
• An analysis of intrusion tolerance requirements
  for a demanding IA application

33
Intrusion tolerance is the ability of a system to
continue providing adequate service after a
penetration
Intrusion tolerance by design and construction
Intrusion tolerance design is proactive, not a
passive extra feature after developing the
system
34
Intrusion Tolerance vs Intrusion Detection

• Intrusion tolerance is pro-active
• Design/engineering focus
• Borrows concepts from the software and safety
• engineering communities

• Intrusion detection is re-active
• Build mechanisms to prevent and detect

35
Proof-Carrying ArchitecturesArchitecture and
Proofs Refined in Parallel
m (
a
)
m (m (
a
))
a
1
1
2
m (m (
C
))
m (
C
)
C
1
2
1

• Link abstract architecture descriptions to simple
  proofs of desired properties (e.g., security)
• Apply architecture transformations to proofs as
  well as architecture descriptions
• Check that result is a gappy-but-essentially-corre
  ct proof

36
Objectives
Question Are intrusion tolerance properties the
same for every architecture?

• Define intrusion tolerance levels (ITLs)
• Risk based approach
• Balanced protection

37
Objectives (Cont.)
Question How can we build intrusion tolerant
architectures?

• Create and evolve intrusion tolerant, software
  architecture hierarchies
• Start from architectural IT properties
• Define appropriate architectural styles involving
  IT mechanisms for the target architecture
• Develop refinement patterns
• Develop intrusion tolerance preserving
  transformations

38
Objectives (Cont.)
Question How can we transition these ideas to
real systems?

• Apply to GENOA
• Evaluate impact of intrusion tolerance
  requirements
• Introduce intrusion tolerance dimension to the
  security architecture framework
• Propose intrusion tolerance techniques
• Propose intrusion tolerance design processes

Concepts developed with reference to a specific
system
39
Design for Security Assurance
Numerous potential vulnerabilities
40
Design for Security Assurance
Avoidance
Avoid introducing vulnerabilities (good system
and s/w engineering, security engineering, SEI/CMM
, SSE-CMM, formal methods etc)
Numerous potential vulnerabilities
41
Design for Security Assurance
Avoidance
Avoid introducing vulnerabilities (good system
and s/w engineering, security engineering, SEI/CMM
, SSE-CMM, formal methods)
Numerous potential vulnerabilities
Remove known vulnerabilities (Test, analysis, VV)
42
Design for Security Assurance
Avoidance
Removal
Prevention
Avoid introducing vulnerabilities (good system
and s/w engineering, security engineering, SEI/CMM
, SSE-CMM, formal methods)
Numerous potential vulnerabilities
Remove known vulnerabilities (Test, analysis, VV)