Transcript A Comprehensive Approach for Intrusion

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
Sidebar: IT infrastructure needed to support Modern Apps (a Checklist)
NGE Specific (“Advanced”) Middleware
Middleware to support mobility
Collaborative computing software that spans multiple organizations
Workflow and transaction management across multiple enterprises that cooperate in virtual operations
Clearinghouse/Auctioning /electronic marketplaces support
EC middleware such for advertising, browser / navigation, negotiation and trading, purchase and delivery,
Invoicing/billing, payment and reconciliation, EDI, directories, catalogs,
Gateways and interfaces of NGE with traditional systems (EAIs, ERPs)
Basic EC specific Middleware :
Catalogs
EDI
Transaction Management
Queued Messaging/Transactions
Transaction Services for Web Commerce
Object transaction services
Internet transaction services
Advanced General Purpose Middleware
Distributed Object Technologies (Java, CORBA, DCOM)
Message oriented middleware for wrappers
Workflow Management (simple, single organization)
Transaction Management (Transaction Services for Web Commerce, Object transaction services, Internet
transaction services)
Enterprise Application Integrators (EAI)
Wireless Middleware
Collaborative services support
Groupware
Additional security and management support
Remote Operation Infrastructure (CORBA/DCOM/RPC)
Basic General Purpose Middleware
File Transfer, Telnet
Messaging and Email services
Web services (HTML, XML, HTTP, Java Applets, Browsers and W3 Servers)
Remote Data Access Infrastructure (SQL/ODBC/JDBC) for accessing data
Remote processing access (e.g. Sun RPC, Sockets)
Basic security services (e.g. SSL)
Service Management Systems to support and manage the infrastructure
Network services
VPN services
Voice/data integration
IP routers and Gateways
Network segments LANs, MANS, WANS
Network elements (Frame relay, ATM, DSL, Sonet,,)
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)
No IT
R
FRS
FRSA
No
Encryption P-Policy 0 P-Policy 2 P-Policy 4 P-Policy 6
Encryption P-Policy 1 P-Policy 3 P-Policy 5 P-Policy 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-Policy 0
Stop, send
message
R-Policy 1
Stop,
reload,
continue
R-Policy 2
Continue
to allow
shutdown
Recovery policies can be
inferred from Protection Policies
and vice versa
R-Policy 3
Continue
as long as
possible
R-Policy 4
Continue
under all
conditions
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-Policy
R-Policy
App
6 (FRSA)
4(always)
CORBA
4 (FRS)
4(always)
XML
1(E)
2 (graceful
shut down)
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
Protection Startup
Policy
Nothing
Policy 0
Policy 1
Encryption
Policy 2
Replicate
Policy 3
Encrypt, replicate
Policy 4
Fragment, replicate,
scatter
Encrypt, FRS
Policy 5
Policy 6
Fragment, replicate,
scatter, adapt
Policy 7
Encrypt, Fragment,
replicate, scatter,
adapt
Normal Runtime
Sample Intrusion
Recovery rules
Nothing
Stop, send a message
Verify for authorized
access
Update replicated
copies
Verify,
Update replicated
copies
Maintain operational
view of FRS
Verify, Maintain
operational view of
FRS
Maintain operational
view of FRSA
Stop, reload
Maintain operational
view of FRSA
Switch to replicated
copy
Switch to replicated
copy
Reconstruct from
FRSd
Reconstruct from
FRSd
Switch to another
middleware, if
possible
Switch to ICM as a
fall-back middleware
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. Schedule of Milestones
GFY 2000
TASKS
3Q
4Q
GFY 2001
1Q
2Q
3Q
GFY2002
4Q
1Q
2Q
3Q
GFY 2003
4Q
1Q
2Q
3Q
4Q
Task 1
Impact
Analysis
Task 2
Architecture
Task 3
Software
Task 3-Opt
Task 4
Evaluation
Of FRSA
Task 5
(opt.)
Managemen
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