1. DART: Dynamic Assessment and Repair of
Tampered data in Commercial Database
Applications
Anand TM Rishab Govind
tmanand@gmail.com rishab.govind@gmail.com
Dr. DVLN Somayajulu
soma@nitw.ac.in
Department Of Computer Science & Engineering,
National Institute of Technology (NIT), Warangal
(Formerly, REC Warangal)
Warangal – 506004
India
Abstract
In a database, the results of one transaction can affect the execution of other
future transactions. A single malicious transaction can damage data and in turn
make the transactions that use this dirty data, malicious and so on. The
complexity of attack recovery is mainly caused by a phenomenon called
damage spreading. We have developed the damage assessor and damage
repairer modules of an intrusion tolerant database system for accessing the
extent of damage and then taking the system closer to the state in which it was
expected to be if none of the transactions would have been malicious. Given a
set of malicious transactions reported by an intrusion detector, the Dynamic
Assessment and Repair of Tampered data (DART) system locates and repairs
the damage caused by each malicious transaction on the database, along with
the damage caused by any benign transaction that is affected, directly or
indirectly, by a malicious transaction. While traditional secure database systems
rely on preventive controls and are very limited in surviving malicious attacks by
trying to just take the system in the state it was in before the attacks occurred,
our system can isolate attacks, contain, assess, and actually repair the damage
caused by intrusions, on the fly, in a timely manner such that sustained, self-
stabilized levels of data integrity and availability can be provided to applications
in the face of attacks. Experimental results of different models of DART
demonstrate the performance benefits of our proposed techniques.
Keywords: intrusion tolerant database; database intrusion; database security; damage repair;
damage assessment; malicious transaction; database recovery; information security;
1. Introduction
Data corruption is a serious security problem since it could lead to wrong
decisions and disastrous actions. Data corruption is not only a data integrity
issue, but also a data availability issue. Many critical real world data
applications shut down the whole database when they realize that the database
could have been seriously corrupted. The execution of new transactions can be
resumed only after the database is recovered for sure. In some cases, the real
purpose of a data corruption attacker could be denial-of-service to good users.
With cyber attacks on data-intensive Internet applications, i.e. e-commerce
systems, becoming an ever more serious threat to our economy, society, and

2. 2
everyday lives, attack resilient database systems that can survive malicious
attacks are a significant concern. The factors that lead to motivation for the work
on data recovery from intrusions are:
• Security limitations of preventive database systems
• Need for advanced trusted databases and computing
• Intensifying computer-generated assaults
• Opportunities provided by latest intrusion recognition technologies
A database attack can be enforced at four possible levels: processor (or
instruction) level, OS level, DBMS level, and transaction (or application) level.
And in general, malicious insiders tend to attack at the transaction level and
outsiders tend to attack at the other three levels.
The first step towards recovering from any intrusion is to detect it. This is
taken care of by the module named Intrusion Detector. However, intrusion
detection makes the system attack-aware but not attack-resilient, that is,
intrusion detection itself cannot maintain the integrity and availability of the
database in face of attacks. To overcome the inherent limitation of intrusion
detection, a broader perspective is introduced, saying that in addition to
detecting attacks, countermeasures to these successful attacks should be
planned and deployed in advance. This is known as survivability of the system.
Figure 1: The Data Damage Scenario
Figure 1 shows the various types of possible attacks and the
corresponding spread of damage due to malicious transactions. The area
marked in red is the damaged portion of the database, which has to be first
detected and then assessed and ultimately repaired.

3. 3
2. Problem Specification
The complexity of attack recovery is mainly caused by a phenomenon called
damage spreading. In a database, the results of one transaction can affect the
execution of some other transactions. When a transaction Ti reads a data item x
updated by another transaction Tj (We say Ti reads x from Tj), Ti is directly
affected by Tj. If a third transaction Tk is affected by Ti but not directly affected
by Tj, Tk is indirectly affected by Tj. It is easy to see that when a (relatively old)
transaction Bi that updates x is identified malicious, the damage on x can
spread to every data item updated by a transaction that is affected by Bi,
directly or indirectly.
The attacker's goal may be to reduce availability by attacking integrity.
This causes damage to certain data items and leads to uncertainty about which
good transactions can be trusted, and hence brings the system down while
repair efforts are being made. To address the availability threat, on-the-fly
attack recovery without the need to halt normal transaction processing is
needed. The job of attack recovery gets more difficult as use of the database
continues because the damage can spread to new transactions and cleaned
data items can be again damaged by new transactions. The goal of attack
recovery is to locate each affected transaction and recover the database from
the damage caused on the data items updated by every malicious or affected
transaction. In addition, the goal of DART is to identify each malicious
transaction, and to assess and repair the damage caused by these malicious
transactions in a timely manner such that the database will not be damaged to
such a degree that is unacceptable or useless.
3. DART Approach
Database intrusion tolerance can be enforced at two possible levels: operating
system (OS) level and transaction level. OS level intrusion tolerance techniques
can be directly integrated into a transaction-level intrusion tolerance framework
to complement it with the ability to tolerate OS level attacks. Hence we focus on
transaction level intrusion tolerance.
The attack recovery problem has two phases:
• Damage Assessment
• Damage Repair
So far, the other intrusion tolerant system ([5]) has succeeded in
restoring the system to its original safe state after an intrusion is detected. This
is carried out by undoing of the malicious transactions and also the
corresponding affected transactions. However, DART adds to the functionality
of this system since DART assesses the damage that has spread due to a
malicious transaction and repairs that damage and hence we attempt to take
the system nearest to the state that it was expected to be in the absence of any
intrusion. The solution we have provided makes use of redoing the affected
transactions that originally corrupted the data because of their dependency on a
malicious transaction.

4. 4
Given a set of malicious transactions reported by an intrusion detector,
DART locates and repairs the damage caused by each malicious transaction on
the database, along with the damage caused by any benign transaction that is
affected, directly or indirectly, by a malicious transaction. DART uses triggers
and transaction profiles to keep track of the read and write operations of
transactions, locates damage by tracing the affecting relationships among
transactions along the history, and repairs damage by composing and executing
some specific UNDO transactions in reverse chronological order followed by
execution of the REDO transactions in the chronological order. DART is
transparent to on-going user transactions and very general. In addition to
Oracle, it can be easily adapted to support many other database application
platforms such as Microsoft SQL Server, Sybase, and Informix.
We have proposed a set of transaction-level trusted recovery algorithms.
DART has actually implemented the on-the-fly damage assessment and repair
algorithm proposed in section 4 below. DART makes use of an SQL rewriting
approach to implement the algorithm. We present a comprehensive view of
DART and the fundamental design and implementation issues of intrusion-
tolerant database systems, and describe how the set of individual DART
components interact with each other, and why these components can be
integrated into one intrusion-tolerant database system.
Figure 2: The DART Scheme
Figure 2 shows the basic approach taken by DART. First detection of the
damage takes place, which is next assessed and then repaired by the repair
manager. DART builds upon work on database survivability by Pramote
Luenam and Peng Liu, Dept. of Info. Systems, UMBC, Baltimore, MD 21250
([5]).

5. 5
4. The Algorithm
The approach, given a set of malicious transactions (denoted B) and a log that
records every read and write operation on the database, scans the log to
identify every innocent transaction that is affected by B. When a malicious
transaction is scanned, its write set will be marked dirty. When a committed
innocent transaction is scanned, if it reads a dirty item, then its write set will be
marked dirty and a specific UNDO transaction will be composed and executed.
When a data item is cleaned by an UNDO transaction, it will not be marked dirty
anymore. UNDO transactions are composed as follows: For every item that is
updated by a transaction to be undone, if the item is not cleaned by any
previous UNDO transaction, then a write operation that restores the item to the
value before it was damaged will be added to the UNDO transaction. Undoing
of all the affected transactions is carried out in the reverse chronological order
and then the redo operation is carried out in the chronological order for these
transactions to take the system closer to the expected state.
5. Architecture Design
The architecture is built on top of a traditional COTS (Commercial-Off-The-
Shelf) DBMS. Within the framework, the Intrusion Detector identifies malicious
transactions based on the history kept (mainly) in the log. The Damage
Assessor locates the damage caused by the detected transactions. The
Damage Repairer repairs the located damage using specific UNDO and REDO
transactions.
Figure 3: System Architecture

6. 6
6. Component level Design
Figure 4: Component Level Design
The design of this project has been implemented using java as the primary
programming language. The database related operations are carried out using
SQL and PL/SQL. The application is designed making use of java swing and
Abstract Window Toolkit (AWT). The query provided by the user as input is
trimmed of any trailing spaces and is processed in the proxy of the Policy
Enforcement Manager (PEM). We define a vector, which stores the ids of
malicious transactions within it. In an intrusion tolerant system, it is the function
of the intrusion detector to provide the ids of transactions that are malicious.
User Transactions
Policy Enforcement Manager
Proxy Triggers
ReadSet WriteSet
Intrusion Detector
Repair Manager
Undo Redo
Damage
Assessor
Dependency
Set of
affected
transactions
Transaction
Table
LogMiner
Database

7. 7
Based on these malicious transactions, we generate a list of transactions, which
might have been affected due to them. Next, the repair manager is invoked,
which repairs the damage by affected transactions and then attempts to bring
the system to the state it was expected to be in. As and when a transaction
occurs in the system, the corresponding write and read sets are generated
simultaneously.
DART is broadly divided into following modules:
1. The Policy Enforcement Manager (PEM)
2. Write Set Generator
3. Read Set Generator
4. The Damage Assessor
5. The Damage Repairer
These modules are all coupled together closely to form the entire DART
system.
6.1 Policy Enforcement Manager (PEM)
The Policy Enforcement Manager (PEM) (a) functions as a proxy for normal
user transactions and the internal system transactions, and (b) is responsible
for enforcing system-wide intrusion tolerant policies. For example, a policy may
require the PEM to reject every new transaction submitted by a user as soon as
the Intrusion Detector finds that the user is malicious.
The PEM first creates a connection to the database. The queries of the
transaction are intercepted by this module. First of all the query is parsed
making use of the ZQL parser ([11]). This is necessary to get the identifier of the
particular data area being modified by the query as well as the list of conditions
since this will be useful in generating the read set of the transaction by making a
list of rowids of the tuples being read by the transaction. The PEM makes use of
triggers to generate the write set of each transaction. Finally, the PEM executes
the query.
The ZQL Parser
Zql is an SQL parser written in Java. Zql parses SQL and fills in java structures
representing SQL statements and expressions. SQL statements are parsed into
java classes, that you can use to SQL-enable the application.
6.2 Write Set Generator
The write set generator’s function is to determine the write set of each
transaction. Write set of a transaction consists of the rowids of all the rows that
were modified or written by that transaction.
This module is implemented as a trigger in DART. As and when a
transaction is executed by the PEM, this trigger is fired for the particular table
and it first gets the id of the transaction that caused the invocation of the trigger.

8. 8
Making use of the :new operator as :new.rowid, rowids of all the rows that were
last modified by the current transaction are recorded into a structure
corresponding to that transaction. This structure forms the write set of the
transaction. Write sets of all the transactions are stored similarly.
6.3 Read Set Generator
The read set generator’s function is to determine the read set of each
transaction. Read set of a transaction consists of the rowids of all the rows that
were read by that transaction before performing the operation.
The conditions obtained from the query are used to determine the rows,
which were read by the transaction. These rowids are then stored in the
structure named readset along with the corresponding transaction id.
6.4 The Damage Assessor
A thread of damage assessor runs for each malicious transaction to
simultaneously determine the affected transactions for all malicious
transactions. Once the transactions that were affected by the malicious
transactions are found, the transactions that were in turn affected by the
affected transactions have to be determined. Hence, this module needs to
iterate over the list of affected transaction while adding transactions, that have
been found to be further affected, into this list.
A transaction T is said to be affected by a malicious transaction M if there
is at least one common rowid between the write set of M and the read set of T
where T occurs after the occurrence of M. This would mean that transaction T
reads data from a location in the database that was updated by the malicious
transaction M. Thus, there are chances that the data read by T was corrupt and
hence T also might have become malicious. So, in apprehension of this
possibility, we label T as an affected transaction.
This module selects the rowids of the transactions that have occurred
after a malicious transaction has occurred. This is determined on the basis of
the time stamp stored along with the transaction in the transactions table.
6.5 The Damage Repairer
For this module to function, it is necessary to start the LogMiner ([12]) utility of
Oracle database server. The Repair Manager has a responsibility to perform
on-the-fly damage repair. First, the Repair Manager retrieves the appropriate
SQL undo statement from the LogMiner based on the Transaction ID of the
affected transaction. After that, the Repair Manager rollbacks all changes made
by the bad or suspect transaction by preparing undo commands and sending
them to the Oracle Scheduler via the Mediator. After a ‘success’ return code is
sent back from the Mediator, the Repair Manager records the information of all
undo transactions. At this stage, the system is in a safe state which prevailed
before the execution of the malicious transaction. It then accesses the

9. 9
transactions table to retrieve the non-malicious affected queries and redoing
them restores the system close to the expected state.
The LogMiner
LogMiner is a utility provided by Oracle to read and interpret online or archived
redo log files. It is a redo log query engine that is provided with the Oracle
database server.
Every change made to an Oracle database by default generates undo
and redo information which is accumulated in Oracle redo log files. Log Miner
keeps the contents of the redo log file in the fixed view, v$logmnr_contents.
Each transaction has an SQL UNDO statement, which can be used to rollback
the change, and SQL REDO statement, which details the original operation.
Use of LogMiner in repair
Appropriate redo log files are added to the data dictionary for the log miner to
access the contents and populate the v$logmnr_contents table. We will then
select the SQL_UNDO column for all those transactions which are in the list of
affected transactions and whose timestamp is greater than that of the malicious
transaction. Then, we execute the corresponding undo statements and bring the
system back to the previous safe state. In order to bring the system to the
expected state, we then execute the queries belonging to the affected
transactions but not the one marked as malicious.
7. Data Structures
Affected_Set Vector
This vector stores the list of all transactions that have been affected by
either a malicious transaction or another affected transaction. This vector is
the output of the Damage Assessor and is passed to the Damage Repairer.
Transactions Table
This table records following information for each transaction executed on the
database: (i) Transaction_ID, (ii) SQL_Statements – SQL statements
forming the transaction, (iii) Time_Stamp – Time of execution of the
transaction. This information is captured in the PEM module.
Read_Set Table
This table records the following information about the data that was read by
a transaction: (i) Transaction_ID, (ii) Row_IDs – rowids of the rows that were
read by the transaction. (A rowid of a row of a table is unique throughout the
database).
Write_Set Table
This table records the following information about the data that was written
by a transaction: (i) Transaction_ID, (ii) Row_IDs – rowids of the rows that
were inserted or modified by the transaction.

10. 10
v$logmnr_contents Table
This table belongs to the LogMiner. The following information from this table
is of particular interest to us: (i) Commit_Timestamp – Time of execution of
the transaction, (ii) SQL_Undo – SQL undo statements for a transaction
(statements that counteract the transaction), (iii) SQL_Redo – SQL redo
statements for a transaction (statements that would redo the transaction),
(iv) xidusn, xidslt, xidsqn which together form the Transaction_ID.
8. Module Integration and Performance Testing
An intensive research on possible integration models was carried out. Various
prototypes of the system consisting of the above discussed modules were built
and experiments were carried out to determine the model that satisfied the
following:
(1) The speed of damage spread should not be faster than the speed of
repair.
(2) The efficiency of repair should be significantly high.
Here, we are focusing on the efficiency of the Damage Repairer module
in particular since we found that this module can be modeled in multiple ways;
whereas the Damage Assessor module runs in a standard fashion wherein it
will compare the read set of each transaction that has occurred with the write
set of a malicious transaction passed by the Intrusion Detector, and hence
determine the transactions affected by that particular malicious transaction. As
of now, we are not concerned with the efficiency of the Intrusion Detector since
it is out of the scope of DART.
There are certain aspects which are common across all the models. The
Intrusion Detector is assumed to be running continuously, generating the
transaction IDs of the transactions that were detected to be malicious. The
Damage Assessor module is designed as a thread and for each malicious
transaction, a new Damage Assessor thread is spawned which generates the
list of transactions that were affected by this malicious transaction. The PEM,
the Write set generator and the Read set generator modules will perform the
same functions in all models.
We now discuss the models we designed.
The Stop and Go Model
In this model, the Transaction IDs of malicious transactions are stored in a
vector as soon as the Intrusion Detector generates them. While the vector is
being populated by the Intrusion Detector, the Damage Assessor takes up IDs
from this vector in batches and spawns as many threads of itself as the number
of malicious transactions in a batch. Each thread generates a list of transactions
that were affected due to the malicious transaction. At the end of the run of all
threads of a batch, these lists are consolidated into a single list without any
duplicates. The malicious transaction IDs are also included in this list which is
then passed to the Damage Repairer.

11. 11
The Damage Repairer undoes each transaction in the list passed to it in
reverse chronological order by making use of the LogMiner. Thereafter it redoes
only the affected transactions and brings the system closer to the expected
state.
Analysis
We found that the Damage Repairer module in this model was functioning at its
optimum efficiency based on our analysis of the other models. However, it was
the batch approach of processing that was making it possible for the Damage
Repairer to execute on a fixed set of transactions at a time and hence
increasing its efficiency. And due to the batch processing, we could see that
eventually, the spread of damage would be more than recovery as malicious
transactions pile up while the Damage Assessor waits for a batch to finish.
Hence, although this model might satisfy our second requirement regarding the
efficiency of the Damage Repairer, it fails to satisfy the first requirement.
The Multi Threaded Model
In this model, the Intrusion Detector passes the ID of a malicious transaction, as
soon as it is detected, to the Damage Assessor module. A new thread is
spawned which generates the list of affected transactions and then spawns a
thread of Damage Repairer. For each malicious transaction and its list of
affected transactions, there runs a thread of Damage Repairer that undoes
each affected transaction in reverse chronological order and then undoes the
malicious transaction. Thereafter it redoes the affected transactions to take the
system closer to the expected state. A row level locking mechanism is
implemented within the Damage Repairer to avoid conflicts in data manipulation
during the undo and redo phases while its threads are running concurrently.
Analysis
Experiments on this model revealed that the efficiency of the Damage Repairer
had come down as compared to the previous model as the average repair time
increased. Two probable reasons for this degradation are: (i) There is a
possibility of a transaction being affected by more than one malicious
transaction. Such an affected transaction will be undone and redone as many
times as the number of malicious transactions that affected it. Clearly, this has
an adverse effect on the efficiency. However, this issue could be rectified by
using a flag that would suggest if the transaction has been cleaned already or
not. (ii) The locking mechanism imposes a significant overhead as other threads
need to wait to clean transactions that modified same data objects.
In this model, we achieve our first requirement, as everytime, the
damage assessment occurred as soon as the damage was detected. However,
we could not achieve the desired repair efficiency.

12. 12
The Fusion Model
Study of the above models suggested the need to arrive at a compromise
between the two. We designed a model that could effectively satisfy both our
requirements with considerable efficiency. The solution that we have arrived at
makes use of batch processing between the Damage Assessor and Damage
Repairer modules. Just as in the Multi Threaded model, the Intrusion Detector
passes the malicious transaction IDs to the Damage Assessor as soon as it
detects them. A new thread is spawned which generates the list of affected
transactions but then a thread of Damage Repairer is not spawned for each
Damage Assessor thread. Instead, we consolidate the list of affected
transactions into a single list along with the malicious transaction IDs and pass
it on to a thread of Damage Repairer just as we did in the Stop and Go model.
However, the important fact that would govern the efficiency of the repair as
well as the rate of damage spread is the number of Damage Assessor threads
that are collected in one batch to be passed to the Damage Repairer. Several
prototypes of this model were formed each with different number of Damage
Assessor threads combined to form one list of affected transactions.
Analysis
We tested each prototype of the Fusion model by differing the number of
Damage Assessors forming a batch, referred to as the thread count. An almost
regular trend was observed in the repair efficiency as well as the damage
spread. With an increase in the thread count in a single batch, the average
repair time reduced, whereas the rate of damage spread amplified as depicted
by the below graphs in Figure 5. We came up with a suitable number of
Damage Assessor threads that should form a batch to have both our
requirements satisfied with considerable efficiency.
Figure 5: Determining the Point of Optimum Overall Efficiency

13. 13
With an increase in the thread count, just as in the Stop and Go model
where the set of affected transactions were consolidated into one list and then
processed by the Damage Repairer, the efficiency of repair increases as the
average time for repair decreases. However, as the other Damage Assessor
threads wait for being processed while the previous batch is being repaired, the
damage continues to spread. So, we need to have a model where the average
number of affected transactions should not be significantly high since higher the
number of affected transactions, higher is the rate of damage spread. Hence,
we came up with a suitable compromise between the two situations as shown in
the above graphs. The point of intersection of the two graphs gives the optimal
value of thread count for an optimum overall efficiency. In our model, we take
thread count as 8.
9. Present State of DART
Presently, DART is implemented as the Fusion model described above with a
thread count of 8 for an optimum efficiency for our system. However, as of now,
this is system dependent and we need to come up with a metrics for
determining a suitable thread count value for different types of systems such as
large, medium or small sized and busy or not busy databases. Since DART is
implemented over the database layer, each transaction passes through the
PEM module of DART before its execution and hence DART is aware of all the
information transmission that occurs.
The system needs no human interaction as it runs as a background
process. Intrusion Detector runs continuously, detecting the malicious
transactions and passing them to the Damage Assessor, which on receiving an
ID from the detector, spawns a new thread of itself and generates a list of
affected transactions which are consolidated in a single list and fed to the
Damage Repairer which cleans the transactions and takes the system closer to
the state it was expected to be in. All this while, the PEM receives each
transaction made by the application, logs them in transactions table, generates
the read set and write set for each transaction and passes the transaction to the
database server for execution.
Since we are making use of the LogMiner, even if the transaction has
been committed, it can be undone and then redone as it is not an SQL rollback
operation that we are performing. The Fusion model makes an appropriate
industrial strength architecture. We do not overburden the system to use
LogMiner, for redoing the affected transactions, since it could be a time
intensive operation. Instead, we make use of the queries stored in the
transactions table to redo these transactions.
The Damage Assessor threads can be consolidated on the first come
first serve basis or on some heuristic approach such as combining those
threads that have transactions acting on mostly same data objects of the
database. In our model we combine the threads on the first come first serve
basis since the overhead of determining the almost same data objects could be
significant.

14. 14
10. Salient Features of DART
a) Robust damage assessment: The damage assessor module
determines the spread of damage over the database caused due to
the malicious transactions and detection latency.
b) Efficient damage repair: By undoing the malicious and affected
transactions and then redoing the non-mailicious affected
transactions, we attempt to bring the system closest to its expected
state.
c) Database availability: Since the repair process is carried out on-the-
fly, the database availability is not affected and the losses due to
downtime between repairs can be avoided.
d) System transparency: DART ensures complete transparency to the
users of the application.
11. Security and Survivability
DART components should certainly be secure and attack resilient by
themselves, else the attacker can attack the database through attacking these
components. For example, a faked cleaning transaction (message) can instruct
the PEM to roll back the work of a benign, unaffected transaction. To secure
DART, first, a firewall is used to prevent outsiders from accessing DART
components. Second, software protection techniques can be used to protect
DART code. Third, cryptography can be applied to protect DART data
structures and messages.
Making DART attack (and failure) resilient is more challenging. For this
purpose, first, we distribute DART components to multiple nodes and try to
minimize the dependency of one DART component upon another. Distributing
the database to multiple sites could help. For example, with respect to trusted
recovery, when one site is disabled, the rest of the database may still be able to
be continuously repaired. Third, some kinds of replication of modules can help.
12. Experimental Results
This section presents a set of preliminary testing results for DART. In particular,
we test the functionality of DART using the database application we have
implemented, and the results show that DART meets its design requirements.
We focus on the damage assessment and repair aspect of DART and
assume that (a) one-phase containment is enforced, (b) no user is isolated.
However, thorough future investigation will be needed to evaluate the merits of
the DART components and their impact on the proxying delay, which is an
overhead of DART.

15. 15
Also the current prototype implementation suffers from two inefficiencies,
all of which we will tackle in the future. One is that DART is currently
implemented on top of a commercial DBMS. This hurts performance because
the log cannot be exploited and transactions have to be proxyed. To fix this
limitation, we plan to move DART into the DBMS kernel. The other inefficiency
is that we have done little tuning. As a result, the absolute performance is less
than we expect for the in-kernel DART. The in-kernel DART should have a
throughput similar to a prevention-centric DBMS.
From the damage assessment and repair perspective, the effectiveness
of DART is measured by the average repair time of a damaged object. The
repair time of a damaged object is defined by the duration between the time
when the malicious transaction is identified and the time when the object is
cleaned. In this way, the detection latency has no impact on the average repair
time.
13. Conclusion and Future Work
The results show that the impact of DART on the performance of normal
transaction processing is very small, which indicates that DART can be a
practical solution towards providing “data integrity” guarantees to arbitrary
commercial database applications in face of attacks. By implementing DART,
the conceptual soundness, the functional capabilities, and the practicality of the
new on-the-fly damage assessment and repair approach have been validated.
There are some future works for DART.
First, we need to come up with a technique of arriving at the optimum
value of thread count for a batch passed on to a single Damage Repairer thread
for a particular database. As of now, it could be determined only by running
DART on the database on which it is to be implemented by varying the thread
count, generating the graphs as in figure 5 and determining the optimal value of
thread count. However, we plan to design a metrics that would immediately give
a value of thread count by taking into consideration the features of the database
in question.
Second, the security of DART is not addressed in the prototype
implementation. However, successful attacks on DART can cause some
undamaged data items to be mistakenly ‘cleaned’, and can cause some
damaged data items to not be identified. For one example, if the triggers are
disabled then DART is disabled. For another example, if the transaction profiles
are maliciously modified then some unaffected benign transactions can be
backed out. Therefore, the security of DART is a significant concern.

16. 16
14. References
[1] D. E. Denning. An intrusion-detection model. IEEE Trans. on Software
Engineering, SE-13:222-232, February 1987.
[2] P. P. Griffiths and B. W. Wade. An authorization mechanism for a relational
database system. ACM Transaction on Database Systems, 1(3):242-255,
September 1976.
[3] K. Ilgun, R. A. Kemmerer, and P. A. Porras. State transition analysis. A rule-
based information detection approach. IEEE Transactions on Software
Engineering, 21(3):181-199, 1995.
[4] V. Atluri, S. Jajodia, and B. George. Multilevel Secure Transaction
Processing. Kluwer Academic Publishers, 1999.
[5] P. Ammann, S. Jajodia, and P. Liu. Recovery from malicious transactions.
Technical report, George Mason University, Fairfax, VA. Under Review for
Journal publication.
[6] D. Aucsmith. Tamper resistant software: an implementation. In Proc.
International Workshop on Information Hiding, pages 317–333, Cambridge, UK,
1996.
[7] P. Liu, P. Ammann, and S. Jajodia. Rewriting histories: Recovery from
malicious transactions. Distributed and Parallel Databases, 8(1):7–40, 2000.
[8] P. Liu and S. Jajodia. Multi-phase damage confinement in database systems
for intrusion tolerance. In Proc. 14th IEEE Computer Security Foundations
Workshop, Nova Scotia, Canada, June 2001.
[9] P. Liu, S. Jajodia, and C.D. McCollum. Intrusion confinement by isolation in
information systems. Journal of Computer Security, 8(4):243–279, 2000.
[10] P. Liu and Y. Wang. The design and implementation of a multiphase
database damage confinement system. In Proceedings of the 2002 IFIP WG
11.3 Working Conference on Data and Application Security, 2002.
[11] P.-Y. Gibello. Zql: A java sql parser. In http://www.experlog.com/gibello/zql/,
2002
[12] Paul Tsien and Ashish Ray. Logminer, Flashback Query And Online
Redefinition: Power Tools For DBAs. Oracle Corporation Papers.