Since 1990, transaction processing in multilevel secure database management systems (DBMSs) has been receiving a great deal of attention from the security community. Transaction processing in these systems requires modification of conventional scheduling algorithms and commit protocols. These modifications are necessary because preserving the usual transaction properties when transactions are executing at different security levels often conflicts with the enforcement of the security policy. Considerable effort has been devoted to the development of efficient, secure algorithms for the major types of secure DBMS architectures: kernelized, replicated, and distributed. An additional problem that arises uniquely in multilevel secure DBMSs is that of secure, correct execution when data at multiple security levels must be written within one transaction. Significant progress has been made in a number of these areas, and a few of the techniques have been incorporated into commercial trusted DBMS products. However, there are many open problems remain to be explored. This paper reviews the achievements to date in transaction processing for multilevel secure DBMSs. The paper provides an overview of transaction processing needs and solutions in conventional DBMSs as background, explains the constraints introduced by multilevel security, and then describes the results of research in multilevel secure transaction processing. Research results and limitations in concurrency control, multilevel transaction management, and secure commit protocols are summarized. Finally, important new areas are identified for secure transaction processing research.

System protection mechanisms such as access controls can be fooled by authorized but malicious users, masqueraders, and misfeasors. Intrusion detection techniques are therefore used to supplement them. However, damage could have occurred before an in

Recently, application-level isolation was introduced as an effective means of containing the damage that a suspicious user could inflict on data. In most cases, only a subset of the data items needs to be protected from damage due to the criticality level or integrity requirements of the data items. In such a case, complete isolation of a suspicious user can consume more resources than necessary. The paper proposes partitioning the data items into categories based on their criticality levels and integrity requirements; these categories determine the allowable data flows between trustworthy and suspicious users. An algorithm that achieves good performance when the number of data items is small, is also provided to detect inconsistencies between suspicious versions of the data and the main version.

System protection mechanisms such as access controls can be fooled by authorized but malicious users, masqueraders, and misfeasors. Intrusion detection techniques are therefore used to supplement them. The capacity of these techniques, however is limited: innocent users may be mistaken for malicious ones while malicious users stay at large. Isolation is a method that has been applied to protect systems from damage while investigating further. This paper proposes the use of isolation at an application level to gain its benefits while minimizing loss of resources and productive work in the case of incidents later deemed innocent. We describe our scheme in the database context. It isolates the database transparently from further damage by users suspected to be malicious, while still maintaining continued availability for their transactions. Isolation is complicated by the inconsistencies that may develop between isolated database versions. We present both static and dynamic approaches to identify and resolve conflicts. Finally, we give several examples of applications in which the isolation scheme should be worthwhile and be able to achieve good performance.

We consider the problem of surviving information warfare attacks on databases. We adopt a fault tolerance approach to the different phases of an attack. To maintain precise information about the attack, we mark data to reflect the severity of detected damage as well as the degree to which the damaged data has been repaired. In the case of partially repaired data, integrity constraints might be violated, but data is nonetheless available to support mission objectives. We define a notion of consistency suitable for databases in which some information is known to be damaged, and other information is known to be only partially repaired. We present a protocol for normal transactions with respect to the damage markings and show that consistency preserving normal transactions maintain database consistency in the presence of damage. We present an algorithm for taking consistent snapshots of databases under attack. The snapshot algorithm has the virtue of not interfering with countermeasure transactions.

One of the most important responsibilities of a database management system (DBMS) is maintaining the integrity of data. Traditional database integrity mechanisms have evolved in DBMSs to fulfill this need, including transaction management to maintain

Multilevel secure (MLS) DBMSs are subject to a number of security-related architectural and functional factors that affect performance. These factors include, among others, the distribution of data among security levels, the session levels at which queries are run, and how the database is physically partitioned into files. In this paper, we present a benchmark methodology, a test database design, and a query suite designed to quantify this impact upon query processing. We introduce three metrics (uniformity, scale-up and speed-up) that characterize DBMS performance with varying data distributions. Finally, we provide comparisons and analysis of the results of a number of actual benchmarking experiments using DBMSs representative of the two major MLS DBMS architectures (trusted-subject and TCB-subset).>

Data management applications that use multilevel database management system (DBMS) capabilities have the requirement to read and write objects at multiple levels within the bounds of a multilevel transaction. The authors define a new notion of atomicity that is meaningful within the constraints of the multilevel environment. They offer a model of multilevel atomicity that defines varying degrees of atomicity and recognizes that lower security level operations within a transaction must be able to commit or abort independently of higher security level operations. Execution graphs are provided as a tool for analyzing atomicity requirements in conjunction with internal semantic interdependencies among the operations of a transaction and rules for determining the greatest degree of atomicity are proved that can be attained for a given multilevel transaction. Several alternative transaction management algorithms that can be used to preserve multilevel atomicity are presented.>

Examples of DoD/intelligence data protection requirements are described that cannot be handled through traditional mandatory (MAC) or discretionary (DAC) access controls, and two new forms of access controls to respond to these problems are proposed. First, a user attribute-based access control for enforcement of dissemination controls is introduced. Second, a type of access control known as owner-retained access control is described, to provide a privilege-based form of access control that, unlike DAC, prevents access to data being extended to others without the owner's concurrence. For both types of controls, the access control rules to be enforced and the implications of providing automated enforcement of these controls are discussed. The two forms of control are compared, and an informal model is presented that provides a common framework for representing both. In conclusion, the benefits and drawbacks of this approach are discussed, and some areas for future work are identified.>