DARPA BAA0015
Intrusion Tolerance
A Comprehensive Approach for Intrusion Tolerance
Based on Intelligent Compensating Middleware
Amjad Umar
Farooq Anjum
Rabih Zbib
Abhrajit Ghosh
Some Examples (from “Dark”)
 Situation: XML “Trade Languages” in many industry segments
based on a common DTD. DTD is used to validate the information
being exchanged between trading partners.
– Threat: Someone modifies the DTD (or DTD parser) so that every
transaction becomes invalid
 Situation: Pub/subscribe for Integration. Many organizations, such
as JBI (Joint Battlespace Infosphere), are beginning to use
publish/subscribe platforms.
– Threat: someone damages/modifies the P/S channel
 Situation: components (EJBs, CORBA components) are being
positioned to develop many applications. Vendors are providing EJBs
for industry segments (Financial). Components are “dropped in” to
containers that provide security, transaction etc.
– Threat: someone contaminates container disabling industry segments
 Other examples:
– “electronification” of supply chains
– call agent for VOIP
JBI web site: http://www.sab.hg.af.mil/archives/index.html
Doc Name – 2
Background and Scope
Motivated by
– Army Fed Labs (ATIRP) -- Information distribution in battlefields
– Ebusiness “Frontiers” - Extended enterprises, large scale integration
– Telcommunications - OSSs, call agents
 Common problem: getting uniformity out of non-uniformity (same COTS
from same supplier with different capabilities at different sites)
 What threats/attacks is your project considering
– Focus on assault tolerance (“threat model”)
– Vicious attack to damage/disable (attacks may be subtle)
– Explore “dark points” (e.g., attacks on emerging COTS with heavy use)
 What assumptions does your project make
– Very knowledgeable attacker (can infer what you are relying on to conduct
operations)
– Knows your weak points (e.g., middleware stack)
 What policies can your project enforce
– Concentrate on “continue to operate as long as possible” and higher
Doc Name – 3
Applications are increasingly relying on layers of technologies
MS Office
Web App
EPurchasing
Trading Hubs,
Large collaborative
systems
Higher Level
Middleware (“Upperware”)
Software
EC Middleware
Intrusion
Tolerance
Infrastructure
General Purpose Middleware
Operating Systems, DBMS,,
Network Services
(PSTN, IP, NGN,,)
Doc Name – 4
S id e b a r: IT in fra st ru c tu re n e e d e d to su p p o rt M o d e rn A p p s (a C h e c k list)
N G E S p ecific (“A d va n ced ” ) M id d lew a r e
M id d lew a r e to su p p ort m obility
C olla bor a tive com p u tin g softw a r e th at span s m ultip le or g an iza tion s
W or k flo w a n d tran sa ction m an ag em en t a cr oss m u ltip le en ter prises th a t coop er a te in virtua l op er a tion s
C lear in gh ou se/A u ction in g /electr on ic m ar k etpla ces su p p ort
E C m id d lew a r e su ch for a d ver tisin g, br ow s er / n a vig a tion , n eg otia tion an d tra din g , p ur ch a se an d d eliver y,
In voicin g/billin g, pa ym en t an d r econ ciliation , E D I, d ir ectories, ca ta log s,
G a tew a ys a n d in ter fa ces of N G E w ith tra d ition al system s ( E A Is, E R P s)
B a sic E C sp ecific M id dlew a r e :
C a ta log s
EDI
T r an sa ction M an a g em en t
Q u eu ed M essa g in g /T ran sa ction s
T r an sa ction S er vices for W eb C om m er ce
O bject tran sa ction ser vices
In tern et tran sa ction ser vices
A d va n ced G en er al P urp ose M id d lew a r e
D istr ibu ted O bject T ech n olog ies (Ja va , C O R B A , D C O M )
M essa g e or ien ted m id dlew a r e for w r ap p er s
W or k flo w M a n a g em en t (sim p le, sin gle or gan iz ation )
T r an sa ction M an a g em en t (T r an sa ction S er vices for W eb C om m er ce, O bje ct tran sa ction ser vices, In tern et
tr an sa ction ser vices)
E n ter prise A p p lica tion In tegr ator s (E A I)
W ir eless M idd lew a r e
C olla bor a tive ser vices su p p or t
G r ou p w a r e
A d d ition al secu rity an d m an a g em en t su pp or t
R em ote O p er ation In fr a stru ctur e (C O R B A /D C O M /R P C )
B a sic G en era l P ur p ose M id d lew a r e
F ile T ran sfer , T eln et
M essa g in g an d E m ail ser vices
W e b ser vices ( H T M L , X M L , H T T P, Ja va A p p lets, B r ow s er s an d W 3 S er ver s)
R em ote D a ta A ccess In fra str u ctur e (S Q L /O D B C /JD B C ) for a ccessin g d ata
R em ote p r ocessin g a ccess (e.g . S un R P C , S ock ets)
B a sic secu r ity ser vices (e.g . S S L )
S er vice M a n a g em en t S yst em s to su p p ort an d m an ag e th e in fr astr u ctur e
N etw or k ser vices
V P N ser vices
V oice/d a ta in tegr ation
IP r ou ter s an d G atew a ys
N etw or k seg m en ts L A N s, M A N S , W A N S
N etw or k elem en ts (Fram e r ela y, A T M , D S L , S on et,,)
Doc Name – 5
Problem Statement and Approach
Intrusion tolerant systems must, as stated in the
BAA00-15 PIP, be able to
– maintain the integrity of application data and programs
– assure high availability under information attacks
Our Approach: Attempt to address both issues
a) For integrity of application data and programs, we attempt to
provide
 capabilities to make the application programs and data intrusion
tolerant.
 integrity of “behaviour of application” by assuring intrusion
tolerance of middleware itself.
b) For high availability, our focus is also on middleware since
availability of network, hardware, and system software is
discussed heavily elsewhere.
.
Doc Name – 6
Reality Check: How To Introduce Intrusion
Tolerance in Middleware (any COTS)
Given:
- a set of requirements R (e.g., intrusion/assault tolerance)
- M middleware components are available (M > 200)
- m middleware components (where m < M) that do not satisfy R
 Find the most practical approach to satisfy R
Possible approaches:
• Extend the non-conforming m middleware components to
satisfy R (not doable).
• Imbed the functionality in the applications (not advisable).
• Build completely new middleware M’ (not advisable).
• * Build intelligent compensating middleware (ICM) that provides
the missing functionality and interworks with m through an
open API
Doc Name – 7
Intelligent Compensating Middleware for
Intrusion/Assault Tolerance (Detailed View)
FRS
(Fragmentation,
Replication,
scattering)
Applications
Operational
Knowledgebase
B1
ICM
A1
Scheduler
C
Intrusion
Triggers
IT Components
. R, F, S, A
. Encryption
C
H-API
B2
C
L-API
COTS
Middleware
A2
B3
A3, C
Network Services
•Arrows A1, A2, A3 indicate Path A (ICM as a lower level service)
•Arrows B1, B2, B3 indicate Path B (ICM as a higher level service)
•Arrow C indicates Path C (ICM invoked by intrusion triggers in random order)
Doc Name – 8
Policies (Specified in Operational
Knowledgebase)
Protection Policy (secrecy, IT)
N o IT
No
E n c r y p t io n
E n c r y p t io n
P -P o lic y 0
P -P o lic y 1
R
P -P o lic y 2
P -P o lic y 3
F RS
F RSA
P -P o lic y 4
P -P o lic y 5
P -P o lic y 6
P -P o lic y 7
Compensation
Protection policies can be described for
•applications (by users or system administrators)
•middleware also (by system administrators)
Recovery Policies to specify level of recovery from intrusions
R -P o lic y 0
Sto p , s e n d
m e s s a ge
R -P o lic y 1
Sto p ,
r e lo a d ,
c o n t in u e
R -P o lic y 2
R -P o lic y 3
R -P o lic y 4
C o n t in u e
t o a llo w
shutdow n
C o n t in u e
a s lo n g a s
p o s s ib le
C o n t in u e
u n d e r a ll
c o n d it io n s
Recovery policies can be
inferred from Protection Policies
and vice versa
Compensation
Doc Name – 9
An XML-CORBA Example
Oracle
Applications
Server
Client
IDL (XML)
Middleware
Customer
Information
IDL (XML)
CORBA Services
•Basic services (finding and invoking objects)
•Thread services (create and manage threads)
•Object life cycle services (create, destroy objects)
•Naming services (facilitate portable names)
•Others: Event, Trading, transactions, Persistence,,
P -P o lic y
R -P o lic y
Ap p
6 ( F R S A)
4 ( a lw a y s )
CORBA
4 (F RS)
4 ( a lw a y s )
XM L
1(E )
2 ( g r a c e fu l
shut dow n)
XML
Support
Doc Name – 10
ICM higher layer services
Purpose:
 Make application itself intrusion tolerant
 Level of intrusion tolerance is specified by protection policies
How will it work (example: FRSA specified) :
– Startup: FRSA the application - data and DTD (one copy in
highly secure site)
– Normal runtime: keep updating FRSs (based on policy)
– Under attack - indicated by triggers (recovery policy is
“Continue under all conditions”):
 No damage to application ; no action required (pass to monitor)
 partly damaged - isolated (database destroyed, or DTD
overwritten): use replicated database or DTD
 partly damaged but unpredictable or severely damaged - attempt
to rebuild/reconstruct. Give up with messages to roll back, restart
Doc Name – 11
ICM lower layer services
Purpose:
 Make COTS middleware intrusion tolerant
 Level of intrusion tolerance is specified by protection policies
How will it work (example: CORBA =FRS, XML =E specified) :
– Startup: FRS the CORBA middleware, encrypt XML middleware
– Normal runtime: keep updating FRSs of CORBA and verifying XML
– Under attack - indicated by triggers (recovery policy is
“Continue as long as possible” and “graceful shutdown”):
 No damage to middleware; no action required
 partly damaged - identified (directory destroyed): restore
replicated directory
 partly damaged but unpredictable or severely damaged
– for XML, send message, reload
– for CORBA.
Switch to another middleware (e.g., MOM) to continue operation
ICM itself takes over completely in case of disasters (can
send/receive info through an open API invoked through
interceptors)
Doc Name – 12
Operational Knowledgebase - Rules for operation
P r o t e c t io n
P o lic y
P o lic y 0
Sta rtu p
P o lic y 1
E n c r y p t io n
P o lic y 2
R e p lic a te
P o lic y 3
E n c r y p t , r e p lic a te
P o lic y 4
F r a g m e n t , r e p lic a te ,
sca tte r
E n c ryp t, F RS
P o lic y 5
N o t h in g
P o lic y 6
F r a g m e n t , r e p lic a te ,
sca tte r, a da p t
P o lic y 7
E n c ryp t, F ra gm e n t,
r e p lic a t e , s c a t t e r ,
adapt
N o r m a l R u n t im e
N o t h in g
Ve r ify fo r a u t h o r ize d
access
U p d a t e r e p lic a te d
c o p ie s
Ve r ify ,
U p d a t e r e p lic a te d
c o p ie s
M a in t a in o p e r a t io n a l
v ie w o f F R S
Ve r ify , Ma in ta in
o p e r a tio n a l v ie w o f
FRS
M a in t a in o p e r a t io n a l
v ie w o f F R S A
M a in t a in o p e r a t io n a l
v ie w o f F R S A
S a m p le In t r u s io n
R e c o v e r y r u le s
S t o p , s e n d a m e s s a ge
S t o p , r e lo a d
S w it c h t o r e p lic a te d
copy
S w it c h t o r e p lic a te d
copy
R e c o n s t r u c t fr o m
F R Sd
R e c o n s t r u c t fr o m
F R Sd
S w it c h t o a n o t h e r
m id d le w a r e , if
p o s s ib le
S w it c h t o IC M a s a
fa ll-b a c k m id d le w a r e
Also contains what needs to be compensated where
Doc Name – 13
Scheduler and Triggers
 Scheduler:
– Invoked by the triggers (subscriber)
– consults the knowledgebase to determine what to do
– invokes high level for app
– invokes low level for middleware
Publisher
Intrusion Triggers
detect intrusions
•publish intrusions as events
Subscribers
Intrusion
Scheduler
H-API
Channel
• No damage
•Modified (isolated)
•Modified (not isolated)
•Disaster
Operational
Knowledgebase
IT Components
. R, F, S, A
. Encryption
L-API
No
damage
Admnistrator
Doc Name – 14
Intrusion Tolerant Components
Redundancy
Scattering
Fragmentation
Agents
Others
Encryption
Core-ICM
Middleware
Use the EJB (CORBA Component) type model
“Intrusion Tolerant Container”
Components dropped in the container
Doc Name – 15
Work Done So Far (since June 22)
 Task 1: Impact Analysis
– Several cases gathered about various newer COTS and possible threats
 Task 2: Architecture Specification
– Rough outline prepared
 Task 3: Software prototyping
– A simple prototype working (inherited from Army)
– Compensates/adjusts for wireless/wired networks and network congestions
– Examining how to extend it
 Task 4: FRSA Evaluation
– Quantify the level of intrusion tolerance achieved based on
 Degree of Fragmentation
 Degree of Redundancy
 Degree of Scattering
– Collaboration between Agents to achieve the given level of intrusion tolerance
– The combined effect of FRS schemes and cryptographic schemes
– Analytical models to evaluate tradeoffs (
 Task 5: Operational Management (optional)
– Some initial thoughts (from OSSs)
Doc Name – 16
D . S c h e d u le o f M ile s to n e s
G F Y 2000
T ASK S
3Q
4Q
G F Y 2001
1Q
2Q
3Q
G F Y 2002
4Q
1Q
2Q
3Q
G F Y 2003
4Q
1Q
2Q
3Q
4Q
T a sk 1
Im p act
A n alysis
T a sk 2
A rch itectu re
T a sk 3
S oftw are
T ask 3 -O p t
T a sk 4
E valu ation
O f FR S A
T a sk 5
(o p t.)
M an agem en
t
Doc Name – 17
Technology Transfer
 Publicize the results of the work in academic/industrial conferences
 Investigate the possibility of initiating an Intrusion Tolerance Task Force
in OMG (we are already active members of the OMG Fault Tolerance
Task Force)
 Work with DARPA to identify potential transition to military customers.
In particular, Army Research Lab, JBI, National Security Agency and
CECOM
 Leverage Telcordia’s industrial position to pursue the following
avenues:
 Work with some vendors to introduce the results of our research directly
into the future COTS middleware.
 Utilize the concepts and software produced by this research in building
the future intrusion tolerant telecommunications operation support
systems (OSSs).
 Build intrusion tolerance as a consulting offer that will promote the
practice of intrusion tolerance.
Doc Name – 18
Risks and Issues
 Difficult to keep up with emerging COTS (will have to be
selective)
 May have to change direction of research somewhat due to
industry evolution (not sure about DARPA process)
 Some spaces may be too dark for DARPA
Doc Name – 19
Conclusions
 Focus on :
– Dependability from undependable COTS
– Assault tolerance (“threat model”)
– Explore “dark points” (e.g., attacks on emerging COTS with heavy
use)
 Approach: intelligent compensation to introduce IT on
– applications
– middleware
 Main interest in building flexible architectures that can
automatically adjust/compensate for missing functionalities in
available COTS
Doc Name – 20
 Backup stuff
Doc Name – 21
Middleware
Application
Application
Middleware
Middleware
Network
Network
Definition: MIDDLEWARE is a set of common business/industry-unaware services
enabling applications and end users to interact with each other across a network.
It resides above the network and below the business-aware application software.
Examples: email, Web, CORBA, distributed transaction processors, data replicators,
workflow systems, collaborating systems
More than 200 middleware packages (Gartner)
USWeb Professional Certification
Legacy Systems and the Web
Doc Name – 22
Intelligent Compensating Middleware for
Intrusion/Assault Tolerance (High Level View)
Applications
Operational
Knowledgebase
B1
ICM
Intrusion
Triggers
Publish
intrusion
events
C
A1
•Runs on trusted
machines
• Compensation at
startup, normal runtime,
intrusion recovery
B2
COTS
Middleware
A3
B3
A2
Network Services
Intended for large scale systems
Different levels of compensation needed at different sites
Doc Name – 23
Descargar

No Slide Title