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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.