Engineering a Distributed Intrusion Tolerant Database System Using COTS Components

1
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
2
Motivation
Authorized but malicious transactions
reject
Unauthorized transactions
database
damage
Reference Monitor
Authorized but malicious transactions can damage
a database to useless !
3
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
4
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
5
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

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

7
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

8
Our Approach
9
Installation
10
Scheme 1 preliminary intrusion tolerance
User Transactions
Damage Confinement
Mediator (Policy Enforcement)
Repair Transactions
Intrusion detector
COTS DBMS
Proofs
Damage Repairer
Proof collector
Damage Assessor
11
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

12
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
13
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
14
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

15
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.
16
A Limitation of Scheme 1

• The purpose of confinement is to prevent damage
  from spreading
• The delay of damage assessment can cause
  ineffective confinement!

User SQL Commands
Damage Confinement
Mediator (Policy Enforcement)
B1s write sets
G2s write sets
Repair SQL Commands
Intrusion detector
B1
B1
Proofs
Damage Repairer
G4
Proof collector
G2
Damage Assessor
The database
17
Scheme 2 multi-phase confinement
User SQL Commands
Damage Confinement
Mediator (Policy Enforcement)
Phase 1
Repair SQL Commands
Later phases
Intrusion detector
COTS DBMS
Proofs
Damage Repairer
Proof collector
Damage Assessor
18
Multi-Phase Confinement An example
all data objects updated after time 5
To be confined
except the data objects updated by G3
User SQL Commands
Damage Confinement
Mediator (Policy Enforcement)
G3s write set is clean
B1
Repair SQL Commands
Intrusion detector
B1
B15
G415
Proofs
Damage Repairer
Proof collector
G27
G39
Damage Assessor
The database
19
Damage Confinement A Spectrum
Maximum damage leakage
Zero damage leakage
Minimum computing resources
Maximum computing resources
Maximum integrity
Minimum integrity
Minimum availability
Maximum availability
Multi-phase
Approximate multi-phase
One-phase
20
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
21
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 users history
Attack enforced
Attack detected
The database

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

22
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
23
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.
24
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

25
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
26
Intrusion Masking An Example
Three less suspicious users
Main history
Masking history 1
Masking history 2

• Advantages
• Quicker recovery
• Less cost

clean
Ti1
Tk1
Tj1

• If Ti1, Tj1, and Tk1 are all malicious, the
  main database is valid
• If Ti1 and Tj1 are malicious, but Tk1 is
  not, then masking engine 2 is valid
• If Ti1 and Tk1 are malicious, but Tj1 is
  not, then though none is valid, re-executing
  Tj1 on the main history can produce the valid
  database

27
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

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

30
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

31
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

32
Task Schedule
33
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

34
Questions?
Thank you!
35
Multi-layer representation of our approach