BBN Technologies

1
Intrusion Tolerance by Unpredictable Adaptation

• BBN Technologies
• University of Illinois and Boeing Corporation

Presented by Partha Pal ppal_at_bbn.com
2
People and Contact Info

• BBN
• Partha Pal ppal_at_bbn.com
• Ron Watro rwatro_at_bbn.com
• Franklin Webber fwebber_at_bbn.com
• University of Illinois
• Bill Sanders whs_at_crhc.uiuc.edu
• Michel Cukier cukier_at_crhc.uiuc.edu
• Boeing
• Bryan Doerr Bryan.Doerr_at_boeing.com
• Project Web Page
  
  
• http//www.dist-systems.bbn.com/projects/itua

3
Contents

• Part I
• Background and Context
• Part II
• Project Description
• Technical Objective
• Expected Accomplishments
• Technical Approach
• Risks Involved
• Evaluation and Qualitative Metrics
• Policy and Enforcement
• Tech Transfer
• Schedule and Milestones

4
Observations

• Attacks on distributed systems will occur
• issues involved are well known and well studied
• attacks attempt to take control over resources
  which applications need and security mechanisms
  aim to protect
• Imperfection in security mechanisms defense in
  depth
• many traditional underlying assumptions are
  inapplicable for distributed systems in the days
  of globalization and the internet
• There is little interaction between the
  applications and traditional security mechanisms
• Applications need to adapt to environmental
  changes when attacked
• Recent technical developments in middleware
  technology make it easier for an application to
  integrate various desired properties and to
  incorporate adaptive behavior

5
Background

• Under Quorum/ QuOIN
• the QuO Middleware
• preliminary work towards integrating individual
  mechanisms such as Bandwidth management, Fault
  Tolerance, Real-time and Security in adaptive
  distributed applications
• Individual mechanisms provide some degree of
  inherent survivability against naturally
  occurring problems
• Under Information Survivability
• a toolkit for developing applications that can
  adapt in response to various triggers, including
  signals from IDSs
• Can we tolerate intrusion attacks?
• can we stop the errors caused by intrusion
  attacks before a failure?
• can we survive the failures caused by intrusion
  attacks?
• all? some? which ones? caused by what kinds of
  attacks?

6
Synthesis of Survivability Ideas

• Think as if the application has a survivability
  requirement, distinct from its functional
  requirements
• separation of survivability from functional
  aspects in line with Quorum/QuOIN philosophy,
  methodology,framework
• Survivability requirements are addressed by
  incorporating survivability strategies
• some survivability strategies are proactive (in
  anticipation or in preparation) and some are
  reactive (in reaction)
• from another perspective, some are defensive
  strategies and some are tolerance strategies
• The two perspectives are not mutually exclusive
• a defensive/tolerance strategy may have both
  proactive and reactive measures
• a practical strategy is likely to have multiple
  strategies of various flavors

7
Long Term Vision Future Critical Systems

• Will be built upon vulnerable OS and network
  infrastructure
• Will need to employ survivability strategies to
  adapt their own behavior, resource usage and
  service levels to remain as effective as possible
  in spite of intrusion attacks
• require new capabilities like awareness of the
  environment, use of new kinds of resource
  management mechanisms and interaction with
  security mechanisms
• it is advantageous to put the support for the
  strategies in the middle
• This is a big problem space that we are just
  starting to explore
• ongoing FTN project Applications that
  participate in their own defense (APOD)
• new ITS start Intrusion tolerance by
  unpredictable adaptation(ITUA)

8
Overview Applications that participate in their
own defense

• Facilitates construction of distributed
  applications using adaptive middleware that
• are security /intrusion aware and
• display survivalist adaptive behavior
• Scope Simple strategies aimed at simple,
  non-coordinated attacks
• assumes attacker does not have application
  privilege
• Tasks implement and incorporate strategies and
  validate
• Focuses on applications awareness of security
  mechanisms
• can be integrated with IDSs (does not focus on
  intrusion detection)
• can be integrated with access-control
  mechanisms, firewalls
• Paving the way towards integration of multiple
  mechanisms
• security and bandwidth management security and
  replication management

9
A typical APOD scenario
Adaptive middleware
IDS
Replica migrated
Host infected
Host infected
client
replicated server
Replication Manager
restrict access to host
Infocon alert
Non replicated back up
10
Part II

• ITUA Introduction
• Technical Objective
• Expected Accomplishments
• Technical Approach
• Risks Involved
• Evaluation and Quantitative Metrics
• Policy and Enforcement
• Tech Transfer
• Schedule and Milestone

11
Intrusion Tolerance by Unpredictable Adaptation

• Considers coordinated attacks that manifest
  themselves as Byzantine application behavior
• some of these attacks will (at least partially)
  subvert traditional security measures and affect
  the application
• some may even gain application privilege
• some may be sustained and phased, and may lead to
  common mode failures
• Goal is to make applications tolerate the faults,
  as opposed trying to prevent (or detect) the
  attacks that cause them
• middleware tolerance of resource attacks is a
  worthwhile addition to the defense-in-depth
  approach
• Adaptation is still your friend, but
  predictability is your enemy in this context!

12
ITUA Scenario
client
Tolerance triggers
Adaptive middleware and multi-mode redundancy
mechanisms present intrusion-tolerant view of
system resources to application
13
Technical Objective

• Develop algorithms and infrastructure support to
  enable distributed systems to survive coordinated
  attacks on systems resources
• Combine fault tolerance and security techniques
  to provide a variety of survivability mechanisms
  to the application
• Manage the redundancy of various system
  resources in a decentralized and secured manner
• Develop and integrate survivability strategies
  that provide layers of defense using fast
  reacting, adaptive responses that are
  unpredictable to the attacker

14
Expected Accomplishments

• Development of distributed infrastructure for
  integrating survivability strategies
• Creation of survivability mechanisms required for
  implementing these strategies building on known
  fault-tolerance and security approaches
• development of a decentralized resource manager
  that manages the redundancy of various system
  resources
• enhancement of adaptive middleware
• example strategies
• Experimental validation (or refutation) of the
  developed technologies
• Transfer developed technologies to industrial
  partners

15
Technical Approach Primary Focus

• Management of resource redundancy and security
• decentralized mechanisms supporting the
  implementation of our survivability strategies
• redundancy of resources at various levels of
  abstractions
• integration of security and fault tolerance
  techniques dictated by the nature of faults
• self protection of the mechanism
• Engineering of distributed systems and trade offs
• enhance the adaptive middleware framework as
  required
• use hints (anomalies visible to the application,
  signals from IDS, Signals from the resource
  manager and other mechanisms)
• use the capabilities of the resource redundancy
  management
• cope with adaptivity and unpredicability that are
  part of the strategies
• Validation of developed technologies (base and
  optional parts)
• analytical? experimental? how rigorous and how
  formal?

16
Risks Mitigation

• Different security and fault tolerance techniques
  may have conflicting assumptions
• reduce scope, refine assumption
• Developed technology may lead to an impractical
  solution
• thrashing refine strategies
• introduction of new vulnerabilities self
  protection is a task item
• developed technology too costly, too complex to
  be used early evaluation and tech transition
  plan
• Strategy may be refuted
• early validation/experimentation
• Tolerance triggers we hope to use may not be
  available
• rely on hints that we gather from the middleware
  and the mechanisms as opposed to tolerance
  triggers

17
Quantitative Metrics

• Goal Quantitative evaluation of
• Effectiveness Does it work? How well does it
  work?
• Applicability Is it applicable in a real
  military context?
• Potential effectiveness metric
• Does the developed technology provide additional
  protection relative to an unprotected system?
• Additional protection (measured in effort or
  time) the developed technology provides relative
  to an unprotected system
• Potential applicability metric
• Cost vs. benefit ratio of applying our technology
  in Boeings application
• Other potential quantities to measure coverage

18
Policy Enforcement in ITUA context

• Policy Directive/Guidance for handling unwanted
  events
• Survivability strategies can be thought about as
  application level micro-policies, for example
• pick a replication host in a non-deterministic
  manner when a host is infected
• Someones policy is someone elses specification
• QuO contracts and associated adaptive behavior
  descriptions are incarnations of the
  micro-policies
• They can work with/take inputs from an
  over-arching policy mechanism (INFOCON) via QuO
  System Conditions

application
Middleware and resource managers
Infrastructure resources
19
Technology Transfer Plans

• Boeing provides the technology transfer context
  and target
• Technology development with an eye on transition
• Boeings participation in the technology
  development, early evaluation and validation will
  ensure that the developed technology
• is set in a realistic context
• provides usable and practical solution to a real
  problem
• is readily transitioned into Boeings
  applications that need survivability

20
Schedule and Milestones
theoretical basis of MRM ready
survivability strategies/ mw enhancement ready
protection of infrastructure added
software development activity
evaluation/tech transfer activity
software demonstration
Technical Paper
PI meetings and reviews
Final Report
0
3
6
9
12
15
18
21
24
28
32
36
40
44
Months after contract
7/1/00
12/31/02
9/30/03
10/1/01