ITDB: Intrusion Tolerant Database Systems
Survivability Validation Framework
Peng Liu
University of Maryland, BC
Sept. 4, 2001
1
Technology Description & IAS Addressed
Our project aims to develop an intrusion tolerant or survivable database system, called
ITDB.
Databases, a widely used means to store and manage data, are a critical component of a
variety of (mission critical) information systems. Although current commercial off-the-shelf
(COTS) database management systems (DBMSs) are equipped with pretty good preventive
mechanisms such as authentication and access control, COTS DBMSs have very limited
ability to survive successful (data) attacks. As a result, information assurance of existing
database applications is seriously threatened by the lack of (good) survivability, which can
cause data to be damaged (without being detected), (wrong) decisions to be made based on
damaged data, the data integrity level to be seriously decreased, and the availability of the
database to be (indirectly) jeopardized.
Existing database survivability techniques can be broken down into two categories:
trusted database systems and OS-level survivability. Trusted database systems aim to develop
a (much more) secure database system from scratch where the low level vulnerabilities and
threats (of COTS DBMSs) can be avoided or removed (by using tamper-resistant processing
environments, exploiting cryptography, and avoiding bug-prone OS services), thus the
survivability to these (low-level) threats is achieved [MVS00]. However, the requirement that
the DBMS should be redeveloped from scratch prevents the technique from being widely
used. OS-level survivability aims to enhance the survivability of COTS database systems to
Page 1
OS-level attacks such as modifying data files without interfering with the DBMS [MG96,
BGI00]. However, this technique cannot handle hardware level attacks.
Although the above two database survivability techniques can achieve pretty good
resilience to OS (and other lower) level attacks, none of them can handle application level or
transaction level attacks, namely malicious transactions, which represent most of the (known)
database attacks. Our intrusion tolerant database systems framework solves this problem.
An ITDB system, with the architecture shown in Fig 1., can detect malicious
transactions, isolate attacks, contain, assess, and repair the damage caused by malicious
transactions in a timely manner such that a self-stabilized level of data integrity can be
provided to applications [LJLI01].
Fig 1. - ITDB Architecture
Page 2
2
Assumptions
A1
No ITDB component is malicious or has bugs.
A2
The implementation of each ITDB component meets its specification.
A3
The logs and audit trails used by ITDB components are not corrupted.
A4
The COTS DBMS executes transactions correctly.
2.a Residual Risks, Limitations, and Caveats
RLC-1
RLC-2
3
OS and lower lever attacks can comprise the effectiveness of ITDB; lowlevel database survivability techniques (as mentioned in Section 1) are
needed to help ITDB survive these attacks.
DBMS bugs can be exploited by the attacker to gain the control of
transaction processing, and to access the metadata used by ITDB
components. These controls and accesses can seriously comprise the
effectiveness of ITDB.
RLC-3
Tons of malicious transactions (with different user identities) can compose a
flooding attack to the database.
RLC-4
The malicious transaction can read and disclose sensitive information.
Vulnerabilities and Attacks
ITDB focuses on the attacks through malicious transactions, which represent most of the
(known) database attacks. The assumptions (particularly A1-A4) and the residual risks
(particularly RLC-1 to RLC-4) indirectly summarize the other types of attacks that a database
system or an ITDB system may suffer (Note that these attacks are already addressed by
existing research). Malicious transactions can be generated in several ways:

Attacker uses a legitimate user’s password and privileges to execute malicious
transactions.

An insider misuses or abuses his or her privileges to execute malicious transactions.

Attacker uses a legitimate user’s unlocked GUI to takeover an active database session, so
no passwords are needed.
Page 3

A legitimate user can mistakenly execute a transaction harming the database. Executing a
harmful transaction by mistakes or executing purposely have no difference from the
perspective of the database.
As the standard interface to access a database, a malicious transaction can attack a database in
several ways.
Design
VA1
Malicious transactions are difficult to detect.
Operation
4
VA2
Malicious transactions can corrupt the data. Corrupted data can lead to wrong
(real world) decisions and actions, which can be dangerous, harmful,
misleading, and disaster-prone.
VA3
Data corruption caused by malicious transactions can force the database server
to halt periodically to assess and repair the damage, which hurts the availability.
VA4
Long detection latency (in identifying malicious transactions) can cause
ineffective damage containment.
VA5
Inaccurate intrusion detection, or high false alarm rates, can cause many
innocent transactions to be mistakenly rejected or rolled back.
Information Assurance and Survivability Attributes
The ITDB architecture assures integrity (I) by dynamically maintaining a self-stabilized
level of data integrity. The damage caused by malicious transaction will be detected and
identified through intrusion detection and damage assessment. A substantial amount of
damage will be isolated (and masked) without causing any harm to the (main) database.
Located damage will be repaired on-the-fly. A cost-based self-tuner is used to stabilize the
data integrity level through agile adaptive reconfiguration. The ITDB architecture assures
availability (AV) by WarmStart damage assessment and repair (without halting the database),
damage containment (without denying the access to undamaged part of the database), and
attack isolation and masking (without rejecting suspicious transactions). The availability (AV)
loss caused by flooding attacks to databases is not addressed by ITDB. Our project has not
addressed confidentiality (C), authentication (AU) and nonrepudiation (NR).
Page 4
5
Comparison with Other Systems
The ITDB architecture can be compared with three types of database systems: (1) COTS
DBMSs such as Oracle, SQL Server, Sybase, and Informix; (2) trusted database systems such
as ITB [MVS00]; (3) COTS DBMSs enhanced with OS-level survivability tools such as data
jamming [MG96] and data corruption detection [BGJ00]. In terms of integrity (I), type (1)
systems use integrity constraints to protect the database from inconsistent data. However, they
cannot prevent the attacker from corrupting data without violating data consistency. Type (2)
and Type (3) systems can effectively detect (and recover from) OS-level data corruption.
However, none of the three types of systems can handle transaction-level data corruption. This
kind of integrity threats can only be addressed by ITDB. In terms of availability (AV), these
three types of systems may need to halt the database during the repair. However, ITDB
systems inherently support WarmStart repair. Finally, it should be noticed that ITDB builds on
top of existing database security and survivability techniques. An ITDB system can be built on
top of either a COTS DBMS, or a trusted database system. Therefore, the confidentiality (C),
authentication (AU), and nonrepudiation (NR) of an ITDB system rely on the corresponding
IAS attributes of the underlying system.
6
Information Assurance and Survivability Mechanisms
M1
Policy Enforcement Manager: proxy transactions, monitor transaction behavior,
and enforce the system wide IAS policy [LJLI01]
M2
Intrusion detector: application aware transaction level database intrusion
detection [IL01]
M3
Isolation Manager: immunize the database from the damage caused by
suspicious transactions without losing the availability [Liu01]
M4
Masking Manager: mask the damage caused by less suspicious transactions
M5
Damage Containment Manager: one-phase and multi-phase damage
containment; contain the damaged part of the database until being repaired
[LJ01]
M6
Damage Assessor: read-write dependency based damage assessment [LJB01,
LL01, LX01]
M7
Damage Repairer: on-the-fly data corruption repair with WarmStart semantics
[LJB01, LL01, LX01]
M8
Self-Tuner: agile, adaptive, cost-based reconfiguration to deliver a self-
Page 5
stabilized level of data integrity
7
Rationale
7.1 Rational Matrix
Threats
VA1
VA2
VA3
VA4
VA5
AV
M21
N/A
(M6, M7)4
N/A
(M2, M3, M4)6
I
M22
(M1 – M8)3
N/A
M55
(M3, M4)7
C
AU
NR
N/A
Notes:
1
Inaccurate intrusion detection (ID) can cause availability loss because innocent
transactions can be mistaken as malicious and be rejected or rolled back. M2 (application
aware ID) exploits application (and transaction) semantics to improve the accuracy of ID
[IL01].
2
Inaccurate ID can cause integrity loss, since (a) undetected malicious transactions will not
be repaired, (b) the effects of the innocent transactions that are mistaken as malicious ones
will be rolled back. M2 exploits application (and transaction) semantics to improve the
accuracy of ID [IL01].
3
One of the key goals of ITDB is to detect/immunize from/mask/recover from data
corruption. M2 detects the malicious transactions that corrupt the data. M3 (isolation)
immunizes the database from a substantial amount of damage (caused by malicious
transactions) by isolating suspicious transactions before some of them turn out to be
malicious later on. M4 (masking) masks the damage caused by (a set of less) suspicious
transactions by propagating their effects onto only a subset of the masking database
servers. As a result, in many cases even if a suspicious transaction is found malicious later
on, its effects are not visible to many database servers. M5 (damage containment)
effectively contains the part of the database that is damaged. Since contained damage will
not spread, M5 can effectively stabilize the data integrity level. M6 (damage assessment)
and M7 (repair) improve data integrity by recovering the database from the damaged part.
Page 6
M8 (self-tuning) helps to achieve a self-stabilized level data integrity through adaptation.
Finally, the interactions among M2-M8 are facilitated by M1 (policy enforcement).
4
M6 (damage assessment) and M7 (repair) are two closely coupled, on-the-fly mechanisms,
which means that damage assessment and repair are processed as the execution of new
transactions continues. Hence in an ITDB system, much more availability can be given to
users. Note that ITDB do cause some availability loss, for example, the proxy delay can
reduce the throughput of the database system.
5
Long detection latency can generate a long damaged history for the Damage Assessor to
locate the damage. Hence the assessment latency will also be long. Traditional damage
containment is one phase where a data item is contained only after the Assessor finds that
it is damaged. The main limitation of one-phase containment is that long detection and
assessment latency can cause ineffective containment, that is, when an item is contained,
its damage may have already spread to many other items during the latency. M5 (multiphase damage containment) solves this problem by quick but approximate initial
containment, followed by a set of un-containing phases where the data items that are
mistakenly contained in the containment phase will be un-contained as quick as possible.
As a result, during the detection and assessment latency, M5 can guarantee that no damage
spread.
6
M2 can improve the detection accuracy to some extent; however, in many cases the false
alarm rate could still be pretty high. M3 (isolation) and M4 (masking) can significantly
reduce the number of innocent transactions that are mistaken as malicious and got rejected
or rolled back, because since many suspicious transactions will be isolated or masked, we
can setup a pretty high anomaly threshold for reporting malicious transactions. In this way,
the alarms raised by the detector will be much more accurate. At the same time, note that
isolated or masked transactions are given almost full availability.
7
We face a dilemma when using an inaccurate detector to protect data integrity: setting up a
high anomaly threshold (for ID) will allow many gradual attacks to succeed; setting up a
low anomaly threshold captures more attacks, but at the same time makes more mistakes.
In both cases, the data integrity can be seriously jeopardized. M3 (isolation) and M4
(masking) can significantly enhance a database system’s ability to live with inaccurate
intrusion detectors. In particular, by isolating and masking a set of suspicious transactions,
it is not necessary to detect the set of suspicious transaction accurately within a short
Page 7
period of time (note that we want the detection latency to be as short as possible). During
the isolation or masking period, the detector can spend more time to focus on these
suspicious transactions, which would improve the accuracy significantly. At the same
time, note that the isolated or masked transactions cause almost no damage to the main
database.
7.2 Verification Techniques
The verification should focus on the following aspects:
8

Cost-effectiveness of the ITDB architecture. This can be verified using simulated
and real world database attacks.

Correct implementation of ITDB components. This can rely on standard (and
emerging) software assurance and testing techniques.

The impact of low-level attacks (such as OS and DBMS bugs) on the effectiveness
of ITDB architecture. Both qualitative and quantitative verification methods could
be needed for this purpose.

The impact of the effectiveness of the Intrusion Detector on the overall effectiveness
of the ITDB architecture. In particular, it is desired to know how effective is enough
for an intrusion detector to be valuable to an ITDB system. For this purpose, a
quality-of-service model for intrusion detectors and a cost model for ITDB
architecture should be developed.
Cost and Benefit Analysis
8.1 Cost Considerations
Development
Development of the ITDB software (components) is a one-time cost.
Resources
More computing resources are certainly needed to enforce ITDB functionalities. To
illustrate, attack isolation requires some suspicious data versions be temporarily
Page 8
maintained, which makes ITDB systems consume more disk space. Attack masking
requires multiple (slightly different) databases (be maintained) and multiple database
servers (to manage these databases), which makes ITDB systems consume more resources
than that of a functionally equivalent database server.
System administration
In addition to the cost of administering a database server, the system security officer need
also to administer the ITDB facilities. In some applications, the data integrity level may
need to be manually monitored, and some ITDB reconfiguration operations may need to
be manually performed.
Performance
Perhaps the largest concern with survivable database systems is the database performance
penalty caused by the ITDB facilities. The throughput of the database (in transaction
processing) can be significantly decreased in an ITDB system built on top of a COTS
DBMS, compared with the throughput of this COTS DBMS. Our preliminary testing
results have shown that the main reason is that the proxy delay is significant [LL01]. It is
clear that integrating the ITDB functionality into the DBMS kernel can dramatically
decrease the performance penalty.
8.2 Benefits
Database systems conforming to the ITDB architecture can survive data corruption
caused by malicious transactions, as described in the previous sections.
9
References
[BGI00]
D. Barbara, R. Goel, and S. Jajodia. Using Checksums to Detect Data
Corruption. In Proc. of the 2000 International Conference on Extending
Data Base Technology, Mar 2000.
[IL01]
S. Ingsriswang and P. Liu. AAID: An Application Aware Transaction-Level
Database Intrusion Detection System. Technical Report, University of
Baltimore –BC, Mar 2001.
Page 9
[Liu01]
P. Liu. DAIS: A Real-Time Data Attack Isolation System for Commercial
Database Applications. Proc. 2001 Annual Computer Security Applications
Conference, Dec, 2001. To appear.
[LJ01]
P. Liu and S. Jajodia. Multi-Phase Damage Confinement in Database
Systems for Intrusion Tolerance. Proc. 14th IEEE Computer Security
Foundations Workshop, June 2001, pages 191-205.
[LJB01]
P. Liu and S. Jajodia. Trusted Recovery and Defensive Information Warfare.
Kluwer Academic Publishers, 2001. To appear.
[LJLI01]
P. Liu, J. Jing, P. Luenam, and S. Ingsriswang. Intrusion Tolerant Database
Systems. Technical Report, University of Maryland –BC, April 2001.
[LL01]
P. Luenam and P. Liu. ODAM: An On-the-fly Damage Assessment and
Repair System for Commercial Database Applications. Proc. of 15th IFIP
WG11.3 Working Conference on Database Security, July 2001.
[LX01]
P. Liu and H. Xu. Efficient Damage Assessment and Repair in Resilient
Distributed Database Systems. Proc. of 15th IFIP WG11.3 Working
Conference on Database Security, July 2001.
[MG96]
J. McDermott and D. Goldschlag. Towards a Model of Storage Jamming. In
Proc. of the IEEE Computer Security Foundations Workshop, pages 176185, Ireland, June 1996.
[MVS00]
U. Maheshwari, R. Vingralek, and W. Shapiro. How to Build a Trusted
Database System on Untrusted Storage. In Proc. of 4th Symposium on
Operating System Design and Implementation, San Diego, CA, Oct 2000.
Page 10