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
1
Motivation
reject
Unauthorized
transactions
Authorized but
malicious transactions
database
damage
Reference Monitor
Authorized but malicious transactions can damage a database to
useless !
2
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
3
The Context
From scratch
Application or
Transaction Level
Our focus
DBMS Level
Trusted DBMS which
protects data on un-trusted
storage using signatures
OS Level
Trusted OS or trusted
DBMS loader
Hardware
Using COTS components
Our focus
1. Storage jamming
2. Signed hashes
Tamper resistant
processing environment
Multi-layer Database Survivability
4
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
5
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.
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
Installation
9
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
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
Intrusion
Detector
Rule
Registration
rule base
trails
Rule
Definition
Function
DLL
Application
Semantics
Every existing ID algorithm can be specified by a rule
Rules capture application semantics
Active malicious transaction will be rolled back
12
Damage Assessment and Repair
A history
B1
G2
time
The database
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
13
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
14
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.
15
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)
B1’s write sets
G2’s write sets
Repair SQL Commands
Intrusion detector
B1
Proofs
Proof collector
B1
G4
Damage Repairer
G2
Damage Assessor
The database
16
Scheme 2: multi-phase confinement
User SQL Commands
Damage Confinement
Phase 1
Later
phases
Mediator
(Policy Enforcement)
Repair SQL Commands
Intrusion detector
Proofs
COTS DBMS
Damage Repairer
Proof collector
Damage Assessor
17
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
G3’s write set
is clean
Mediator
(Policy Enforcement)
B1
Repair SQL Commands
Intrusion detector
B1
Proofs
Proof collector
Damage Assessor
B1[5]
G4[15]
Damage Repairer
G2[7]
G3[9]
The database
18
Damage Confinement: A Spectrum
Maximum damage leakage
Zero damage leakage
Minimum computing resources
Maximum computing resources
Minimum integrity
Maximum integrity
Maximum availability
One-phase
Minimum availability
Approximate
multi-phase
Multi-phase
19
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 1113, 2001, Nova Scotia, Canada
20
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
An user’s history
Attack enforced
t1
t2
Attack detected
The database
•Our goal: decreasing the amount of damage without losing detection
accuracy and denial-of-service
21
Scheme 3: Isolation
User SQL Commands
Damage Confinement
Suspicious trans.
Mediator
(Policy Enforcement)
Intrusion detector
Main
database
Isolating ... Isolating
engine 1
engine n
Damage
Repairer
read
Damage Assessor
merge
22
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.
23
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
24
Scheme 4: Masking
User SQL Commands
Damage Confinement
Mediator
(Policy Enforcement)
Less suspicious trans.
Very suspicious trans.
Intrusion detector
Damage Assessor
Damage
Repairer
Masking
engine 1
Main
DB
Isolating
engine 1
...
Isolating
engine n
...
Masking
engine n
read
merge
25
Intrusion Masking: An Example
Ui : Ti1
Three less suspicious users:
Main history
Uj : T j 1
Uk : T k 1
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, reexecuting T[j1] on the main history can produce the valid database
26
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
27
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)
Intrusion
detector
Damage
Assessor
Damage
Repairer
Tolerable
range
State variable feedback
The controller
Main
database
Isolation
engines
Masking
engines
28
The database
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
29
New Progress of Scheme 5
• Since Feb 2001
• We have investigated rule-based (adaptive) selfstabilization techniques
• Some example self-tuning rules are produced
• Overall
30
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
31
Task Schedule
Repair
Mediator Detection
Confine
Isolation
Masking Self-Tuning
Design
Implementation
100
90
80
70
60
50
40
30
20
10
0
Evaluation
32
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
33
Questions?
Thank you!
34
Multi-layer representation of our approach
35