engineering a distributed intrusion tolerant database system using cots components n.
Download
Skip this Video
Download Presentation
Engineering a Distributed Intrusion Tolerant Database System Using COTS Components

Loading in 2 Seconds...

play fullscreen
1 / 35

Engineering a Distributed Intrusion Tolerant Database System Using COTS Components - PowerPoint PPT Presentation


  • 136 Views
  • Uploaded on

Engineering a Distributed Intrusion Tolerant Database System Using COTS Components. Peng Liu Lab. for Info. and Sys. Security http://www.liss.ifsm.umbc.edu/ University of Maryland Baltimore County. July 2001. Motivation. Authorized but malicious transactions. reject. Unauthorized

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 'Engineering a Distributed Intrusion Tolerant Database System Using COTS Components' - cleo


Download Now 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
engineering a distributed intrusion tolerant database system using cots components

Engineering a Distributed Intrusion Tolerant Database System Using COTS Components

Peng Liu

Lab. for Info. and Sys. Security

http://www.liss.ifsm.umbc.edu/

University of Maryland Baltimore County

July 2001

motivation

Motivation

Authorized but

malicious transactions

reject

Unauthorized

transactions

database

damage

Reference Monitor

Authorized but malicious transactions can damage a database to

useless !

existing practice database assurance

Existing Practice: Database Assurance

Authentication and access controlcannot prevent all attacks

Integrity constraints are weak at prohibiting plausible but incorrect data

Concurrency control and recovery mechanisms cannot distinguish legitimate transactions from malicious ones

Automatic replication facilities and active database triggers can serve to spread the damage

network

the context

The Context

From scratch

Using COTS components

Application or

Transaction Level

Our focus

Our focus

Trusted DBMS which

protects data on un-trusted

storage using signatures

DBMS Level

OS Level

Trusted OS or trusted

DBMS loader

1. Storage jamming

2. Signed hashes

Hardware

Tamper resistant

processing environment

Multi-layer Database Survivability

technical objectives

Technical Objectives

Engineering using COTS components a database system that can survive authorized but malicious transactions

Practical Database Intrusion Tolerance

Our approach: using COTS DBMS as main building blocks

Cost effective Database Intrusion Tolerance

Our approach: multi-layer defense, cost-effectiveness-performance analysis

Comprehensive Database Intrusion Tolerance

Our approach: transaction-level intrusion detection, isolation & masking, damage confinement, assessment, and repair

Adaptive Database Intrusion Tolerance

Our approach: self-stabilization by adaptation

assumptions policies

Assumptions & Policies

What attacks are you considered?

All and only the attacks through malicious transactions

What assumptions are you making?

The proposed ITS facilities are trusted

The COTS DBMS executes transactions correctly

What policies can your project enforce?

New transactions execution control policy, i.e., stop, continue, or reduce speed

Damage confinement policy, i.e., single-phase or multi-phase

Intrusion detection policy, i.e., suspicion levels for malicious and suspicious trans

Attack isolation and masking policy

Self-stabilization control policy, i.e., the minimum integrity level

etc.

expected major achievements

Expected major achievements

A cost-effective intrusion tolerant database system prototype

A family of innovative database intrusion tolerance techniques

Transaction-level intrusion detection

Intrusion isolation and masking

Multi-phase damage confinement

On the fly damage assessment and repair (implementation)

Adaptive database intrusion tolerance

Optimized load balance among ITS facilities

Identification and study of such ITS properties as adaptability, stability, and sensitivity

scheme 1 preliminary intrusion tolerance

Scheme 1: preliminary intrusion tolerance

User Transactions

Damage Confinement

Mediator

(Policy Enforcement)

Repair Transactions

Intrusion detector

Proofs

COTS DBMS

Damage Repairer

Proof collector

Damage Assessor

transaction level intrusion detection

Transaction-Level Intrusion Detection

  • Our goal: applying existing intrusion detection techniques to identifying malicious transactions
  • Key issues:
    • semantics-based intrusion detection
    • proof collection
    • using the detector as a protection tool
    • coupling OS-level and transaction-level intrusion detection
application aware intrusion detection

Application-Aware Intrusion Detection

Intrusion

Detector

Rule

Registration

Rule

Definition

rule base

Function

DLL

Application

Semantics

trails

Every existing ID algorithm can be specified by a rule

Rules capture application semantics

Active malicious transaction will be rolled back

damage assessment and repair

Damage Assessment and Repair

time

The database

A history

B1

G2

G3

B1: read(x,z); write(x)

G2: read(z); write(z)

G3: read(x,y); write(y)

x

y

z

B1

Read-from

G2

G3

A repair

A dependency graph

Undo B1 & G3

Our goal: implementation and evaluation

new progress of scheme 1

New Progress of Scheme 1

Since Feb 2001

The intrusion detector prototype is implemented (using ad-hoc rules)

Scheme 1 was demonstrated on DISCEX II in June

A new testing application is developed

Till now

Scheme 1 is implemented (except the damage confinement part)

The prototype has around 20,000 lines of multi-threaded C++ code, running on top of a NT LAN and an Oracle server

The prototype proxies every user transaction, collects the trails of transactions, detects bad transactions, rolls back active bad transactions, locates and repairs the damage (caused by identified bad transactions), all on-the-fly

The prototype (except the intrusion detector) is tested and evaluated

scheme 1 publications

Scheme 1: Publications

1. Peng Liu, Xu Hao, "Efficient Damage Assessment and Repair in Resilient Distributed Database Systems", Proc. 15th IFIP WG 11.3 Working Conference on Database and Application Security, July 15-18, 2001, Ontario, Canada.

2. P. Luenam, P. Liu, "ODAM: An On-the-fly Damage Assessment and Repair System for Commercial Database Applications", Proc. 15th IFIP WG 11.3 Working Conference on Database and Application Security, July 15-18, 2001, Ontario, Canada.

3. S. Ingsriswang, P. Liu, "AAID: An Application Aware Transaction-Level Database Intrusion Detection System", Technical Report, Dept. of Information Systems, UMBC, 2001.

a limitation of scheme 1

A Limitation of Scheme 1

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

B1’s write sets

G2’s write sets

The purpose of confinement is to prevent damage from spreading

The delay of damage assessment can cause ineffective confinement!

Repair SQL Commands

Intrusion detector

B1

B1

Proofs

Damage Repairer

G4

Proof collector

G2

Damage Assessor

The database

scheme 2 multi phase confinement

Scheme 2: multi-phase confinement

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

Phase 1

Repair SQL Commands

Later

phases

Intrusion detector

Proofs

COTS DBMS

Damage Repairer

Proof collector

Damage Assessor

multi phase confinement an example

Multi-Phase Confinement: An example

To be confined:

all data objects updated after time 5

except the data objects updated by G3

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

G3’s write set

is clean

B1

Repair SQL Commands

Intrusion detector

B1

B1[5]

G4[15]

Proofs

Damage Repairer

Proof collector

G2[7]

G3[9]

Damage Assessor

The database

damage confinement a spectrum
Damage Confinement: A Spectrum

Maximum damage leakage

Zero damage leakage

Maximum computing resources

Minimum computing resources

Minimum integrity

Maximum integrity

Maximum availability

Minimum availability

Approximate

multi-phase

Multi-phase

One-phase

new progress of scheme 2

New Progress of Scheme 2

Since Feb 2001

The damage confinement subsystem is 70% designed and 70% implemented

Till now

The multi-phase damage confinement technique is developed

P. Liu, S. Jajodia, “Multi-Phase Damage Confinement in Database Systems for Intrusion Tolerence”, Proc. 14th IEEE Computer Security Foundations Workshop, June 11-13, 2001, Nova Scotia, Canada

a limitation of scheme 2

A Limitation of Scheme 2

  • For accuracy, intrusions can be detected with a significant delay
  • The delay can cause serious damage when an intrusion is detected
  • Quicker detection can decrease the amount of damage, but could mistake many legitimate transactions for malicious, and cause denial-of-service

t1

t2

An user’s history

Attack enforced

Attack detected

The database

  • Our goal: decreasing the amount of damage without losing detection accuracy and denial-of-service
scheme 3 isolation

Scheme 3: Isolation

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

Suspicious trans.

Intrusion detector

Main

database

Isolating

engine 1

...

Isolating

engine n

Damage

Repairer

read

Damage Assessor

merge

new progress of scheme 3

New Progress of Scheme 3

  • Since Feb 2001
    • We have developed a SQL statement rewriting technique to enforce isolation in COTS DBMS
    • The isolation subsystem is 100% designed
    • The implementation of the isolation subsystem has started

P. Liu, “DAIS: A Real-Time Data Attack Isolation System for Commercial Database Applications”, submitted to ACSAC 2001.

a limitation of scheme 3

A Limitation of Scheme 3

  • To reduce cost, very few users (i.e., one) can be isolated within a single engine
  • However, to avoid causing damage on the main database, the number of suspicious transactions can be large
  • Hence, isolating every suspicious transaction can be too expensive!
  • Our solution
    • Treating very suspicious and less suspicious users differently
    • Isolating very suspicious users
    • Masking less suspicious users
  • Advantage: better cost-effectiveness
scheme 4 masking

Scheme 4: Masking

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

Less suspicious trans.

Very suspicious trans.

Intrusion detector

Masking

engine 1

...

Isolating

engine 1

Isolating

engine n

...

Main

DB

Damage Assessor

Masking

engine n

Damage

Repairer

read

merge

intrusion masking an example

Intrusion Masking: An Example

Three less suspicious users:

Main history

Masking history 1

Masking history 2

  • Advantages:
  • Quicker recovery
  • Less cost

clean

T[i1]

T[k1]

T[j1]

  • If T[i1], T[j1], and T[k1] are all malicious, the main database is valid
  • If T[i1] and T[j1] are malicious, but T[k1] is not, then masking engine 2 is valid
  • If T[i1] and T[k1] are malicious, but T[j1] is not, then though none is valid, re-executing T[j1] on the main history can produce the valid database
a limitation of scheme 4

A Limitation of Scheme 4

  • Scheme 4 is not adaptive by nature
  • Adaptation can give better resilience and cost-effectiveness
  • There is no automatic way for the system to adaptively adjust its defense behavior according to:
    • the characteristics of recent and ongoing attacks
    • its current performance against these attacks
  • Although the SSO can dynamically reconfigure some of its components, manual reconfiguration operations are ad-hoc, not scalable, and prone to errors
  • Our goal: adaptive database intrusion tolerance
scheme 5 self stabilization

Scheme 5: Self-Stabilization

  • Self-Stabilization: the degree of data integrity should be able to be automatically stabilized within a tolerable range no matter how the system is attacked

User SQL Commands

Damage Confinement

Mediator

(Policy Enforcement)

Tolerable

range

Intrusion

detector

The controller

State variable feedback

Damage

Assessor

Isolation

engines

Masking

engines

Main

database

Damage

Repairer

The database

optimized load balance

Optimized Load Balance

  • Observation:
    • Different load configurations usually cause different cost-effectiveness
    • A load configuration can cause very different cost-effectiveness in different situations
  • An example of load configuration:
    • the percentage of isolated users
    • the percentage of masked users
    • the percentage of malicious users
    • the number of masking engines used
    • the average interval of state variable feedback
    • ...
  • Our goal: adaptive load configuration optimization
  • Mechanism:the controller can be responsible for this job
new progress of scheme 5

New Progress of Scheme 5

  • Since Feb 2001
    • We have investigated rule-based (adaptive) self-stabilization techniques
    • Some example self-tuning rules are produced
  • Overall
metrics to measure success

Metrics to measure success

Cost

time, space needed for tolerating intrusions

Effectiveness

how many intrusions are detected, isolated, or masked

how many mistakes are made

how effectively can the damage be confined

how quick can the damage be assessed and repaired

how well can the system be adapted

availability: how often is a legitimate request rejected

integrity: how well can data integrity be preserved under attacks

Performance

system throughput

response time

technology transfer

Technology Transfer

Technical papers published in leading technical meetings and technical reports

Release and dissemination of the prototype in source and binary forms

Pursuing technology transition through major commercial DBMS vendors. The technologies can either be absorbed into their DBMS kernels, or be commercialized as intrusion tolerance wrappers

Starting a company to commercialize the technologies and provide flexible services toarm customers' database systems with necessary intrusion tolerance facilities

questions

Questions?

Thank you!