1

Engineering a Distributed Intrusion Tolerant Database System Using COTS Components

Peng Liu University of Maryland Baltimore County

Feb 2001

2

The problem: Database Intrusion Tolerance

• Attacks can succeed -> Intrusions •Intrusions can seriously impair data integrity and availability

DBMS

Authentication

SQLCommands

connect

Access control

Integrity control

Database

3

Technical Objectives

Engineering using COTS components a database system that can tolerate intrusions

•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

4

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?–The system will continuously execute transactions even in face of attacks

–Damage caused by attacks will be automatically located and repaired

–Located damage will be confined to not further spread

–Suspicious users will be isolated or masked transparently

–The degree of data integrity will be automatically stabilized

–etc.

5

Existing Practice: Database Assurance

•Authentication and access control cannot 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

6

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

7

Our Approach

8

Transaction-Level vs. OS-Level Intrusion Tolerance

Transaction-Level OS-Level

•Good when attacks are via transactions

•Cannot handle OS-level attacks

•Good when attacks are via direct OS operations

•Inefficient in handling malicious transactions

Although both transaction-level and OS-level intrusion tolerance are necessary, we focus on transaction-level intrusion tolerance:

–Most database attacks are (by insiders) through transactions

–OS-level techniques can be easily integrated into our framework

9

Scheme 1: preliminary intrusion tolerance

COTS DBMS

Proof collector

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Repair SQL Commands

Proofs

Damage Confinement

10

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

SSN Start Date Salary

900000001 01/01/97 $58,000

900000001 01/01/98 $60,000

900000001 01/01/99 $62,000

900000001 01/01/00 $82,000

11

Application-Aware Intrusion Detection

•Features:

–application aware

–portable

–real time

–protect the database from active bad transactions

–integrate OS-level, table-level, session-level, and transaction-level semantics or statistics

12

Damage Assessment and Repair (Liu& Ammann &

Jajodia 98,00)

A history time

B1 G2 G3

B1: read(x,z); write(x)G2: read(z); write(z)G3: read(x,y); write(y) y

x

z

B1

G2 G3

A dependency graph

Read-from

A repair

Undo B1 & G3Our goal: implementation and evaluation

The database

13

Current Status of Scheme 1

•A prototype of Scheme 1 is implemented except that –damage confinement is not implemented

–a simulated intrusion detector is used, the real one is under coding

•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 SQL command, maintains the status of every session and every transaction, collects the proofs for every transaction, raises warnings, rolls back active bad transactions, locates the damage as a bad transaction is identified, and repairs the damage, all on-the-fly

•Now the prototype is under testing and evaluation

•We plan to demo this prototype on DISCEX II in June

14

A Limitation of Scheme 1

Proof collector

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Repair SQL Commands

Proofs

Damage Confinement

The database

B1 B1

G2

G4

•The purpose of confinement is to prevent damage from spreading

•The delay of damage assessment can cause ineffective confinement!

B1’s write setsG2’s write sets

15

Scheme 2: multi-phase confinement

COTS DBMS

Proof collector

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Repair SQL Commands

Proofs

Damage Confinement

Laterphases

Phase 1

16

Multi-Phase Confinement: An example

Proof collector

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Repair SQL Commands

Proofs

Damage Confinement

The database

B1 B1[5]

G2[7]

G4[15]

G3’s write setis clean

G3[9]

B1

all data objects updated after time 5

To be confined:

except the data objects updated by G3

17

Current Status of Scheme 2

18

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

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

The database

An user’s history

Attack enforced Attack detected

t1 t2

19

Scheme 3: Isolation

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Damage Confinement

Maindatabase

Suspicious trans.

Isolatingengine 1

Isolatingengine n

...

merge

read

20

Current Status of Scheme 3

•Our preparation

•Our current focus: design and implementation (is challenging!)

21

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

22

Scheme 4: Masking

Intrusion detector

Mediator(Policy Enforcement)

User SQL Commands

Damage Assessor

Damage Repairer

Damage Confinement

MainDB

Less suspicious trans.

Isolatingengine 1

Isolatingengine n

...

merge

read

Maskingengine 1

Maskingengine n

Very suspicious trans.

...

23

Intrusion Masking: An Example

Three less suspicious users:

Main history

•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

1

1

1

:

:

:

kk

jj

ii

TU

TU

TU

Masking history 1 Masking history 2

T[i1]

T[j1]

T[k1]clean

Advantages:•Quicker recovery•Less cost

24

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

25

Scheme 5: Self-Stabilization

Mediator(Policy Enforcement)

User SQL Commands

DamageAssessor

Damage Repairer

Maindatabase

Isolationengines

Maskingengines

The database

Intrusion detector

Damage Confinement

The controller

State variable feedback

Tolerablerange

•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

26

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

27

Metrics to measure success (better cost-effectiveness)

•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

28

Task Schedule

Schedule

Intrusion Detection

Assessment & Repair

Confinement

Isolation and Masking

Self-Stabilization

FY01 FY02

DesignSeparate DemonstrationsIntegrated Demonstrations

29

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 to arm customers' database systems with necessary intrusion tolerance facilities

30

Questions?

Thank you!

31

Multi-layer representation of our approach