ITUA Presentation

1
Intrusion Tolerance by Unpredictable Adaptation
William H. Sanders Michel Cukier James
Lyons Prashant Pandey HariGovind Ramasamy
Jeanna Gossett
Partha Pal Ron Watro Franklin Webber
Not for public distribution
2
Intrusion Tolerance by Unpredictable Adaptation

• Develop middleware-based mechanisms to keep a
  distributed CORBA-based application running
  despite intrusions
• Adaptation to cope with changes in environment
• Redundancy to tolerate arbitrary component
  failures
• Unpredictability to thwart attack planning and
  delay the attacker
• Research Agenda
• Explore the use of adaptation, redundancy and
  unpredictability in the context of intrusion
  tolerance
• Evaluate the developed capabilities
• Specific tasks
• Use unpredictability in adaptive response
• Mechanism for adaptation control in the
  middleware
• Protect application objects from the adverse
  effects of intrusion
• Replication and intrusion tolerance within the
  communication layers
• Results so far
• Middleware extension for unpredictable adaptation
  
• Intrusion-tolerant group communication system
• Prototype architecture to tie in the capabilities
  and as a basis for further investigation and
  evaluation
• ITUA Intrusion Model, analysis of effectiveness
  of mechanisms in terms of various factors
• In progress
• Distributed management of application level
  replicas and a hierarchical response mechanism

3
Outline of the talk

• Nature of attacks ITUA is considering
• Mechanisms for adaptive tolerance of intrusion
  effects
• Unpredictable adaptive response to intrusion
  effects
• Techniques under investigation
• Dynamic and unpredictable response engagement
• Distributed management of redundant
  resources/security tools
• Rapid reaction to intrusion/anomaly
• Dynamic adjustment of security
• Protecting application objects from intrusions
• Techniques under investigation
• Application level replication coordinated through
  middleware
• Group communication tolerating arbitrary
  intrusion effects
• A reference architecture for using/evaluating
  these components
• Integration opportunities
• Schedule and events

4
Nature of Attacks that ITUA is considering

• Focuses on attacks that attempt to corrupt the
  application
• Broader notion of corruption ITUA intrusion
  model
• Assumes layers of privilege
• Anonymous legitimate user, domain user, domain
  administrator supported by properly configured
  security domains and cryptographic techniques
• Application privilege (needed to interact with
  the application components) supported by object
  level access control (currently in the form of
  OODTE)
• Each layer is a barrier, subversion of different
  layers have different consequences
• with domain admin privilege attacker can start
  or stop processes in a host
• with application privilege attackers can corrupt
  processes
• More layers mean more barriers, and more
  possibilities for adaptation
• Attacks typically progress in stages
• Identify target component
• Gain access to the target security domain
• sending attack packet may kill the orb, or the
  process (redundancy)
• attack packet reaching the process will be
  rejected (application privilege)
• Must work its way to obtain application
  privilege, possibly by gaining domain admin
  privilege first
• with domain admin privilege it may kill
  application processes, start attack processes
• Death/Corruption in application objects detected
  and recovered
• Death/Corruption in ITUA system objects
  detected, and abandoned (relies on redundancy)

5
Dynamic and Unpredictable Response Engagement

• Enhanced QuO middleware to support unpredictable
  adaptation
• contract adaptation control policy
• selection of transition action
• selection of contract region
• A means to increase attackers difficulty w/o
  increasing the programmers difficulty
• Exploit attackers decision points
• Make use of redundancy including redundant
  intrusion response mechanisms
• At various levels applications level, system
  management level
• Effectiveness
• limited number of available options
• quantifying the added level of difficulty
• reinforcing the effectiveness of other mechanisms

s
s
s
s
s
c
Example application level which s is next used
if the current one is suspected ? Further
escalation will hide the real call among multiple
arbitrary calls
h
h
h
d2
d1
h
h
d3
h
Example management level need to start a
replica, where? An agreed upon decision
collectively made, but hard to predict.
6
Distributed Management I Rapid Reaction to
Intrusion/Anomalous Conditions

• Prototyping a couple of sensor-actuator loops
  involving COTS tools such as snort, iptables,
  tripwire etc.
• Focused, local, knee-jerk reaction coordinated by
  the QuO adaptive middleware
• Snort IPTables
• TripwireFileMgrActuator
• CPUMonitor -gt OSMgrActuator
• Gains time against attacks that
• plant an executable, overload CPU or send
  signature attack packets in some stage of their
  life
• sometimes this may effectively block the attack!
• Lowest level participant in distributed
  management
• manages multiple sensors and actuators
• different resources/tools
• Next investigate unpredictability in this level

host
Network interface
File system
CPU/Process
Multiple sensor-actuator loops in a host
7
Distributed Management II Managing Redundant
Resources

• Implementing ITUA Managers and Subordinates
• Locus of decentralized coordination and
  decision-making
• Replication control, control of security elements
  deployed in the hosts and security domains
• Decentralization good survivability practice

• Responsibilities
• Information collection and reporting
• Decide whether host/domain infiltration has
  occurred
• Start application objects securely when
  commanded by manager
• Initiate replication related adaptation proposal
  and collectively act on them
• Decide which replica of replication group to
  start, kill, migrate

8
Distributed Management III Rapid Reaction and
Managing Redundant Resources

• Each host has a subordinate one subordinate in
  a domain is a manager
• A Sub/Mgr controls the dynamic reorganization
  of local resources and tools
• Subordinates on a security domain report to a
  manager
• A manager sets domain-wide policies that govern
  subordinates
• Loops on a host report to an ITUA management
  component (manager or subordinate) on that host
• Rapid response buys time for coordinated
  responses by the managers
• Distributed control and local decisions ?
  attacker faces different and possibly
  unpredictable responses on different hosts and
  domains

9
Distributed Management IV Distribution and
Consistency

• Security Posture of a domain
• Dynamically computed by domain manager
• Security state of the domain
• high, medium, low
• Operating levels of Sensors and Actuators depend
  on the domains posture
• Controls sensitivity (sensors) and aggressiveness
  (actuator)
• Cost vs. Protection middleware is the right
  place for the trade off and coordination policies
• QuO
• Managers and Subordinates
• Gateways and handlers

A Sensor-Actuator loop makes its own decision
Situational awareness flows up and directives
flow down
10
Protecting Application Objects IITUA Group
Communication System

• Expanded an existing GCS which tolerates crash
  failures to tolerate the faulty communication
  behavior of corrupt objects
• Based on C-Ensemble and Maestro (C interface)
• Need total ordering and virtual synchrony
  properties
• C-Ensemble stack needed to be radically changed
• No total ordering was provided(Total and
  Reliable provide total ordering)
• Group membership was not suited to the ITUA
  environment (Ensemble trusts all members
  ITUA_Grouphas been created)
• Most Ensemble microprotocols needed to
  bemodified to fit the ITUA environment

11
ITUA GCS ContdTotal Ordering and Group
Membership Protocols

• Total ordering protocol
• Global total ordering provided by a globally
  unique sequence number
• Each process can check if the sequence number
  corresponds to the process that has generated the
  message
• Very efficient for replicas (processes generating
  a similar number of messages)
• Processes that do not need to generate a message
  will send a NULL message
• Group membership protocol
• A process will be removed if its crash has been
  detected, if it is slowing down the protocol, or
  if it is exhibiting provably bad behavior
• Processes can join a group (new process) or
  rejoin a group (accidental faulty process)
• Approval of majority of the non-faulty members is
  necessary for effecting any change to group
  membership
• Two types of messages are exchanged
• GMP-Messages, which are related to the group
  membership protocol and contain changes to the
  membership
• Normal Messages, which are related to the
  application execution

12
Protecting Application Objects II Replication
using Intrusion Tolerant GCS

• Replicas use the ITUA gateways to interact with
  each other over the ITUA GCS
• The gateways
• provide reliable remote invocations to replicated
  objects
• contain some intrusion tolerancemechanisms
• Several handlers areneeded
• In terms of the function of the component (e.g.,
  ITUA object, manager, subordinate)
• Depending on the intrusionsto be tolerated
• Handler and Gateway implementation is in progress

r1
ORB
Gateway
IIOP
TAO ORB
ITUA GCS
Naming Service
DII Processor
Handler Factory
Top
Create handlers
Heal
Handler for ITUA object -1
Handler for ITUA object -2
Handler for ITUA object -n
Suspect
Gateway handlers
...
Leave
Inter
ITUA GCS
Intra
Elect
ITUA_Group
Sync
Vsync
Stable
Top_appl
Total
Local
Pt2ptw
Pt2pt
Reliable
Bottom
13
The ITUA Architecture
1 Sensor-actuator loop 2 Rapid response 3
Subordinate group 4 Manager group 5 Replication
group
host
C
M
4
Security Domain
host
host
M
S
r1
Security Domain
5
host
M
host
3
host
S
r1
S
A
2
s
1
Security Domain
14
Integration Opportunities

• What we can use from others
• ITUAs application level protection complements
  any technology that makes the infrastructure
  intrusion tolerant, for instance
• Can use an Intrusion Tolerant ORB as the basis of
  our QuO adaptive middleware
• Can use an Intrusion Tolerant Storage System to
  store critical data
• Can use sensors (for instance a better IDS) and
  actuators (for instance an intrusion tolerant
  packet filter) that are relevant
• Can use AOs elusive interfaces to create more
  options to support unpredictable adaptation
• What others can use from ITUA
• The ITUA architecture and mechanisms can be used
  to make distributed CORBA-based applications
  intrusion tolerant
• The ITUA unpredictable engagement technique can
  be used to enhance dynamic reconfiguration
  mechanisms
• The ITUA Gateway and intrusion-tolerant GCS can
  be used in the context of replicated objects and
  groups
• Understanding the packaging and boundaries is TBD

15
Schedule/External Activities
2000
2001
2002
2003
ID
Task Name
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
Q2
Q3
Q4
Q1
1
ITUA

3
Initial Concept Dev Proof of concept demo
4
Design Devlp of Prototype v1
5
Final Prototype Evaluation results
Proof of concept for some components demonstrated

• External activities
• Metrics Workshop
• DSN Fast abstract
• NSPW paper