1. Middleware Policies for Intrusion Tolerance
Franklin Webber, Partha Pal, Chris Jones, Michael Atighetchi, and Paul Rubel
BBN Technologies
QuO

2. Outline Using middleware for defense against intrusions
Defense mechanisms
Parameterizing defense policies

3. A Distributed Military Application

4. A Cyber-Attack
Hacked!

5. An Abstract View Data User Data Source Data Processing (Fusion,
Analysis,
Storage,
Forwarding,
etc.)
Attacker

6. Traditional Security Application Attacker Trusted OSs and Network
Private
Resources
Limited
Sharing
Private
Resources

7. Most OSs and Networks In Common Use Are Untrustworthy
Application
Attacker
OSs and Network
Private
Resources
Limited
Sharing
Private
Resources

8. Cryptographic Techniques Can Block (Most) Direct Access to Application
Attacker
OSs and Network
OSs and Network
Private
Resources
Limited
Sharing
Private
Resources

9. Firewalls Block Some Attacks; Intrusion Detectors Notice Othersy p t o
Application
Attacker
OSs and Network
IDSs
Firewalls
Raw Resources
CPU, bandwidth, files...

10. Defense-Enabled Application Competes
With Attacker for Control of Resources C r y p t o
Attacker
Application
Middleware for QoS and
Resource Management
OSs and Network
IDSs
Firewalls
Raw Resources
CPU, bandwidth, files...

11. QuO QuO Adaptive Middleware Technology
QuO is BBN-developed middleware that provides:
interfaces to property managers, each of which monitors
and controls an aspect of the Quality of Service (QoS)
offered by an application;
specifications of the application’s normal and alternate
operating conditions and how QoS should depend
on these conditions.
QuO has integrated managers for several properties:
dependability
communication bandwidth
real-time processing
(using TAO from UC Irvine/WUStL)
security (using OODTE access control from NAI)
QuO

12. QuO adds specification, measurement, and adaptation into the distributed object model
CLIENT
Network
operation()
in args
out args + return value
IDL
STUBS
SKELETON
OBJECT
ADAPTER
ORB
IIOP
(SERVANT)
OBJ
REF
Application
Developer
CORBA DOC MODEL
Mechanism
Developer
CLIENT
Delegate
Contract
SysCond
Network
MECHANISM/PROPERTY
MANAGER
operation()
in args
out args + return value
IDL
STUBS
SKELETON
OBJECT
ADAPTER
ORB
IIOP
(SERVANT)
OBJ
REF
Application
Developer
QuO
Developer
QUO/CORBA DOC MODEL
Mechanism
Developer 7

13. The QuO Toolkit Supports Building Adaptive Apps or Adding Adaptation to Existing Apps
QoS Adaptivity
Specification
QuO Code Generator
CORBA
IDL
Middleware for QoS and
Resource Management

14. Implementing Defenses in Middleware
for simplicity:
QoS concerns separated from functionality of application.
Better software engineering.
for practicality:
Requiring secure, reliable OS and network support is not currently cost-effective.
Middleware defenses will augment, not replace, defense mechanisms available in lower system layers.
for uniformity:
Advanced middleware such as QuO provides a systematic way to integrate defense mechanisms.
Middleware can hide peculiarities of different platforms.
for reuseability
Middleware can support a wide variety of applications.

15. Security Domains Limit the Damage From A Single Intrusion
host
host
host
router
host
router
host
host
domain
hacked
domain

16. Replication Management Can Replace Killed Processes
domain
host
host
host
router
host
router
host
host
domain
hacked
domain
application component replicas
QuO replica management

17. Bandwidth Management Can Counter Flooding Between Routers
domain
host
host
host
router
host
router
host
host
domain
hacked
domain
QuO bandwidth management
RSVP reservation or
packet-filtered link

18. Other Defensive Adaptations
Dynamically configure firewalls to block traffic
Dynamically configure routers to limit traffic
Dynamically change communication ports
Dynamically change communication protocols

19. Defense Strategy
Use QuO middleware to coordinate all available defense mechanisms in a coherent strategy.
Our best current strategy has two parts:
“outrun”: move application component replicas off bad hosts and on to good ones
“contain”: quarantine bad hosts and bad LANs by limiting or blocking network traffic from them and, within limits, shutting them down

20. Policy Issues for ‘Outrunning’
Where should new replicas be placed?
Always in new security domain?
Always on a new host?
Unpredictably?
Should number of replicas change under attack?
Increase for protection against stealth?
Decrease for more rapid response?

21. Policy Issues for ‘Containment’
Should quarantine be used?
Or rely only on self-shutdown based on local sensors?
When is a domain, LAN, or host judged bad?
Depends on source of warning?
Depends on repeated warnings?
Depends on combination of warnings?
Is agreement necessary before quarantine?
Yes: local decisions are easier to spoof
No: global decisions are impeded by flooding

22. Avoiding Self-Denial-of-Service
How to prevent attacker from spoofing defense into quarantining all security domains?
Limit number or fraction of quarantined domains?
Limit rate of quarantining?
Allow later reintegration of quarantined domains?

23. Conclusion
The feasibility of adaptive cyber-defense is being explored.
Adaptive cyber-defense is naturally implemented in middleware.
A strategy for cyber-defense can be parameterized in several ways.