a comprehensive approach for intrusion tolerance based on intelligent compensating middleware n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware PowerPoint Presentation
Download Presentation
A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware

Loading in 2 Seconds...

play fullscreen
1 / 23

A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware - PowerPoint PPT Presentation


  • 146 Views
  • Uploaded on

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”).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Comprehensive Approach for Intrusion Tolerance Based on Intelligent Compensating Middleware' - elpida


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a comprehensive approach for intrusion tolerance based on intelligent compensating middleware

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
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

background and scope
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
slide4

Applications are increasingly relying on layers of technologies

Intrusion

Tolerance

Trading Hubs,

Large collaborative systems

MS Office

Web App

E-Purchasing

Higher Level

Middleware (“Upperware”)

Software

Infrastructure

EC Middleware

General Purpose Middleware

Operating Systems, DBMS,,

Network Services

(PSTN, IP, NGN,,)

problem statement and approach
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.

.

reality check how to introduce intrusion tolerance in middleware any cots
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
intelligent compensating middleware for intrusion assault tolerance detailed view
Intelligent Compensating Middleware for Intrusion/Assault Tolerance (Detailed View)

FRS

(Fragmentation,

Replication,

scattering)

Applications

Operational

Knowledgebase

ICM

B1

A1

Scheduler

C

H-API

Intrusion

Triggers

B2

COTS

Middleware

C

IT Components

. R, F, S, A

. Encryption

L-API

A2

B3

C

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)
policies specified in operational knowledgebase
Policies (Specified in Operational Knowledgebase)

Protection Policy (secrecy, IT)

  • 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

Compensation

Compensation

Recovery policies can be

inferred from Protection Policies

and vice versa

an xml corba example
An XML-CORBA Example

Oracle

Server

Client

Customer

Information

Applications

IDL (XML)

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,,

XML

Support

Middleware

icm higher layer services
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
icm lower layer services
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)
operational knowledgebase rules for operation
Operational Knowledgebase - Rules for operation

Also contains what needs to be compensated where

scheduler and triggers
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

Operational

Knowledgebase

Intrusion

Channel

Publisher

Subscribers

Intrusion Triggers

Scheduler

H-API

  • detect intrusions
  • publish intrusions as events
    • No damage
    • Modified (isolated)
    • Modified (not isolated)
    • Disaster

IT Components

. R, F, S, A

. Encryption

L-API

No

damage

Admnistrator

intrusion tolerant components
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

work done so far since june 22
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)
technology transfer
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.
risks and issues
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
conclusions
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
middleware
Middleware

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)

Application

Middleware

Network

Application

Middleware

Network

USWeb Professional Certification

Legacy Systems and the Web

intelligent compensating middleware for intrusion assault tolerance high level view
Intelligent Compensating Middleware for Intrusion/Assault Tolerance (High Level View)

Applications

Operational

Knowledgebase

B1

ICM

  • Runs on trusted machines
  • Compensation at startup, normal runtime, intrusion recovery

A1

C

Intrusion

Triggers

B2

COTS

Middleware

A3

Publish

intrusion

events

B3

A2

Network Services

Intended for large scale systems

Different levels of compensation needed at different sites