FOREWORD

This report is the fourth of five companion documents to the Trusted Database Management System 
Interpretation of the Trusted Computer System Evaluation Criteria. The companion documents 
address topics that are important to the design and development of secure database management 
systems, and are written for database vendors, system designers, evaluators, and researchers. This 
report addresses auditing issues in secure database management systems.





_______________________________  May 1996  

Keith F. Brewster

Acting Chief, Partnerships and Processes

ACKNOWLEDGMENTS

The National Computer Security Center extends special recognition to the authors of this document. 
The initial version was written by Richard Graubart of the MITRE Corporation. The final version 
was written by Stan Wisseman, Bill Wilson, and David Wichers of Arca Systems, Inc.

The documents in this series were produced under the guidance of Shawn P. O'Brien of the National 
Security Agency, LouAnna Notargiacomo and Barbara Blaustein of the MITRE Corporation, and 
David Wichers of Arca Systems, Inc.

We wish to thank the members of the information security community who enthusiastically gave 
of their time and technical expertise in reviewing these documents and in providing valuable 
comments and suggestions.

TABLE OF CONTENTS

SECTION  PAGE

1.0 INTRODUCTION  

1.1 BACKGROUND AND PURPOSE  

1.2 SCOPE  

1.3 INTRODUCTION TO AUDITING  

1.4 AUDIENCES OF THIS DOCUMENT  

1.5 ORGANIZATION OF THIS DOCUMENT  

2.0 BACKGROUND  

2.1 AUDIT DEFINITION  

2.2 PURPOSE OF AUDIT  

2.3 SECURE DBMS VS. SECURE OS AUDITING  

2.3.1 Object Differences  

2.3.2 Queries and Transactions  

2.3.3 DBMS Integrity  

2.4 PROBLEMS AND ISSUES  

3.0 AUDITABLE EVENTS  

3.1 AUDIT POLICY  

3.2 SELECTIVE AUDITING  

3.2.1 Audit Event Requirements  

3.2.2 Audit Event Data  

3.3 AUDITlNG ACCESS CONTROL EVENTS  

3.3.1 What is a DBMS Access?  

3.3.2 Content and Context Dependent Access Control  

3.4 AUDITING DBMS INTEGRITY  

4.0 AUDIT STORAGE, PERFORMANCE, AND PROTECTION  

4.1 AUDIT IMPLEMENTATION  

4.1.1 Auditing to Satisfy the Requirements  

4.1.2 Auditing to Capture Intent  

4.1.3 Application Specific Auditing  

4.2 AUDIT SETTINGS  

4.2.1 Audit Setting Precedence for Views and Base Tables  

4.2.2 Establishing New Audit Settings for Objects  

4.2.3 Modifying Audit Settings  

4.3 AUDIT STORAGE  

4.3.1 Audit Storage Location  

4.3.2 Audit Storage Format  

4.3.3 Audit Storage Longevity  

4.4 PERFORMANCE  

4.5 CREDIBILITY AND PROTECTION  

4.5.1 Audit Trail Credibility  

4.5.2 Access Control for the Audit Trail  

4.5.3 System Availability vs. Audit Collection  

5.0 AUDIT TRAIL ANALYSIS  

5.1 REQUIREMENTS  

5.2 AUDIT PROCESSING  

5.2.1 Audit Formatting  

5.2.2 Audit Reduction  

5.2.3 Audit Querying (Database Support)  

5.2.4 Manually Trained Audit Analysis Tools (static profiling)  

5.3 INTRUSION DETECTION  

5.4 CORRELATION OF AUDIT TRAILS  

5.5 DETECTION OF INFERENCE AND AGGREGATION  

5.6 DETECTING EXPLOITATION OF COVERT CHANNELS  

6.0 ARCHITECTURE  

6.1 INTEGRITY-LOCK  

6.1.1 Architectural Summary  

6.1.2 Auditing Issues in the Integrity-Lock Architecture  

6.2 DISTRIBUTED DBMS ARCHITECTURE  

6.2.1 Architectural Summary  

6.2.2 Auditing Issues in the Distributed DBMS Architecture  

6.3 TRUSTED SUBJECT  

6.3.1 Architectural Summary  

6.3.2 Auditing issues in a Trusted Subject Architecture  

6.4 NO MAC PRIVILEGES ARCHITECTURE  

6.4.1 Architectural Summary  

6.4.2 Auditing Issues in a NMP Architecture  

6.5 TCB SUBSETS  

6.6 SUMMARY  

7.0 DATA RECORDING FLEXIBILITY  

8.0 SUMMARY  

APPENDIX  

REFERENCES  

LIST OF FIGURES

FIGURE  PAGE

3.1: EMPLOYEE RELATION  

3.2: DEPT RELATION  

6.1: INTEGRITY LOCK ARCHITECTURE  

6.2: SECURE DISTRIBUTED DBMS ARCHITECTURE  

6.3: EXAMPLE OF UNAUTHORIZED ACCESS REQUEST  

6.4: TRUSTED SUBJECT ARCHITECTURE  

6.5: TRUSTED SUBJECT ARCHITECTURE OPTIMIZED FOR AUDITING  

6.6: TRUSTED SUBJECT ARCHITECTURE OPTIMIZED FOR MODULARITY

& MINIMIZATION  

6.7: NMP ARCHITECTURE  

LIST OF TABLES

TABLE  PAGE

2.1: ROADMAP TO DISCUSSIONS ON DBMS SECURITY DILEMMAS  

3.1: REPRESENTATIVE AUDIT TRAIL EVENT TYPES  

3.2: TCSEC REQUIRED AUDIT EVENTS  

3.3: TDI REQUIRED AUDIT EVENTS  

3.4: AUDIT RECORD CONTENT  

A.l: INFORMIX-ONLINE SECURE AUDIT EVENT TYPES  



SECTION 1

INTRODUCTION

This document is the fourth volume in the series of companion documents to the Trusted Database 
Management System Interpretation of the Trusted Computer System Evaluation Criteria [TDI 91; 
DoD 85]. This document examines auditing issues in secure database management systems and 
summarizes the research to date in this area.

1.1 BACKGROUND AND PURPOSE

In 1991 the National Computer Security Center published the Trusted Database Management 
System Interpretation (TDI) of the Trusted Computer System Evaluation Criteria (TCSEC). The 
TDI, however, does not address many topics that are important to the design and development of 
secure database management systems (DBMSs). These topics (such as inference, aggregation, and 
database integrity) are being addressed by ongoing research and development. Since specific 
techniques in these topic areas had not yet gained broad acceptance, the topics were considered 
inappropriate for inclusion in the TDI.

The TDI is being supplemented by a series of companion documents to address these issues specific 
to secure DBMSs. Each companion document focuses on one topic by describing the problem, 
discussing the issues, and summarizing the research that has been done to date. The intent of the 
series is to make it clear to DBMS vendors, system designers, evaluators, and researchers what the 
issues are, the current approaches, their pros and cons, how they relate to a TCSEC/TDI evaluation, 
and what specific areas require additional research. Although some guidance may be presented, 
nothing contained within these documents should be interpreted as criteria.

These documents assume the reader understands basic DBMS concepts and relational database 
terminology. A security background sufficient to use the TDI and TCSEC is also assumed; however, 
fundamentals are discussed wherever a common understanding is important to the discussion.

1.2 SCOPE

This document addresses audit in secure DBMSs. It is the fourth of five volumes in the series of 
TDI companion documents, which includes the following documents:

 Inference and Aggregation Issues in Secure Database Management Systems [Inference 96]

 Entity and Referential Integrity Issues in Multilevel Secure Database Management Systems 
[Entity 96]

 Polyinstantiation Issues in Multilevel Secure Database Management Systems [Poly 96]

 Auditing Issues in Secure Database Management Systems

 Discretionary Access Control Issues in High Assurance Secure Database Management 
Systems [DAC 96]

This series of documents uses terminology from the relational model to provide a common basis 
for understanding the concepts presented. This does not mean that these concepts do not apply to 
other database models and modeling paradigms.

1.3 INTRODUCTION TO AUDITING

Auditing has long been recognized as being a critical element in secure systems. Schaefer et al., 
examined the historical significance of auditing in [Schaefer 89b]. That discussion is reused here.

The word ``audit" is derived from the Latin auditus (hearing) and is defined by the Oxford English 
Dictionary as an ``official examination of accounts with verification by reference to witnesses and 
vouchers. To make an official systematic examination of (accounts) so as to ascertain their accuracy." 
From the earliest citations until the present epoch there is a close relationship between the concepts 
of audit, accountability, accounting, and accuracy.

The original purposes of audit focused on a quest for establishing the verity of account books and 
ledgers. A primary interest of the auditor was to ascertain whether the reckoning of accounts 
represented on paper accurately depicted what could be tied to reality and, if not, why not. ...

In the operating system context, the original intention of audit appears to have begun with an 
investigation into the accuracy and legitimacy of charges to customers for the use of computing 
resources. The system of   ``witnesses and vouchers" checked by Electronic Data Processing (EDP) 
auditors consisted largely of a system-generated ``accounting log'' whose entries associated a specific 
user account with an identified use of some billable resource (e.g., machine store, magnetic tape, 
CPU time, printer, card punch, etc.) on a specific date and time for some time period....

The accuracy of bills clearly related to the accuracy of the accounting log. If some billable events 
were not recorded, the computer center would lose revenue. If some events were entered into the 
accounting log that either did not occur or were caused by another user's actions, some customer 
would be overbilled. If some customer were capable of altering the accounting log entries, some form 
of fraud would occur.

The TCSEC audit requirements are derived fairly directly from the needs of EDP auditors. A set of 
accountable events is defined, and each such must be associated with an accountable user and 
accurately recorded into a protected security audit log along with the appropriate ``witnesses and 
vouchers" to the event's context.

In an automated information system (AIS), the audit trail is a chronological record of when users 
log in, how long they are engaged in various activities, what they were engaged in, and whether an 
actual or attempted security violation occurred [Stang 93]. The record should be sufficient to enable 
the reconstruction, review, and sequence of environment surrounding or leading to each event in 
the path of a transaction from its inception to output of final results. Such trails may be examined 
by a system security officer (SSO). They may also be examined, depending on the circumstances, 
by an operating system (SO) security specialist, application specialist, or by an information security 
(INFOSEC) specialist.

1.4 AUDIENCES OF THIS DOCUMENT

This document is targeted at four primary audiences: the security research community, database 
application developers/system integrators, trusted product vendors, and product evaluators. In 
general, this document is intended to present a basis for understanding secure DBMS auditing. 
Members of the specific audiences should expect to get the following from this document:

Researcher

This document describes the basic issues associated with secure DBMS auditing. Important research 
contributions are discussed as various topics are covered. This discussion will assist the research 
community in understanding the scope of the auditing issues and highlight areas that require 
additional research.

Database Application Developer/System Integrator

This document highlights the potential hazards and added management complexity resulting from 
secure DBMS auditing. This document discusses the ramifications a secure DBMS audit trail has 
on storage, performance, and analysis tools.

Trusted Product Vendor

This document identifies likely enhancement paths that would add value to existing audit 
mechanisms, yet remain TCSEC compliant. It provides the basis for understanding how audit 
requirements have been interpreted for secure DBMSs in previous NCSC evaluations and how 
various architectures affect auditing.

Evaluator

This document presents an understanding of auditing issues so that evaluators can better evaluate 
secure DBMS audit mechanisms. It accomplishes this by providing TCSEC/TDI references where 
applicable, and examples of Trusted DBMSs where available.

1.5 ORGANIZATION OF THIS DOCUMENT

The organization of the remainder of this document is as follows:

 Section 2 provides the definition and purpose of audit, and compares secure DBMS 
auditing to that of a secure OS.

 Section 3, based on a DBMS audit policy, discusses what actions to audit, objects to audit, 
and the data to be collected about each event.

 Section 4 addresses issues of what DBMS data to collect for each auditable event, how to 
capture that data, where to store the data, and how much to store. Section 4 also discusses 
performance issues and audit trail credibility/protection.

 Section 5 addresses ways to facilitate use of DBMS audit data for misuse detection and 
damage assessment.

 Section 6 describes the impact of variations in secure DBMS architectures on assurance and 
other aspects of auditing.

 Section 7 introduces the concept of recordability, the ability to precisely adjust the amount 
of data that is recorded for particular audit events.

 Section 8 summarizes the contents of this document.

SECTION 2

BACKGROUND

A broad definition of audit is that it is the collection and review of a documented history of the use 
of a system to verify that the system is intact and working effectively [DoD 84]. This section further 
examines the definition and purpose of auditing. It then compares secure DBMSs to secure OSs, 
emphasizing those differences that impact auditing. Finally, some of the audit issues examined in 
this document are enumerated.

2.1 AUDIT DEFINITION

The auditing activity, viewed in its entirety, encompasses the notion of both an internal and external 
audit.

An internal audit is distinguished from an external audit by the fact that internal auditing is designed 
into the system and runs continuously, whereas an external audit is only performed periodically and 
by means external to a system. Internal audit consists of automated collection and analysis of 
documentary evidence of the system's use. An internal audit subsystem must include mechanisms 
for continuously collecting and recording audit data and for periodically reviewing and analyzing 
the collected data. The internal audit collection mechanism records data about system activities that 
have been judged significant to audit; these are referred to as audit events. An audit event may 
originate in the operating environment (e.g., a network connection to a DBMS), in the operating 
system (e.g., as a file open), or in the DBMS (e.g., as a database query). The same thread of activity 
may be audited at three different levels of abstraction with correspondingly different granularity. 
Data collected about the occurrence of audit events is either recorded in the respective audit trails, 
or merged together into a composite audit trail. Multiple audit trails may need to be compared and 
reconciled during the investigation of a suspected or actual security breach. Since it serves as the 
only internal accountability mechanism, the audit trail, the audit settings, and the audit mechanism 
itself must be trusted/protected-comparable to the human external auditor's auditing instructions 
and audit results.

An external audit consists of gathering and analyzing documentary evidence about the system by 
methods that are external to the system. External audit has two facets: (1) operational audit and (2) 
systems audit. Operational audit is a review of computer operations that covers system security 
policy, data integrity controls, system development procedures, and backup recovery procedures. 
Systems audit is an indepth audit of a particular system for accuracy. By tracing the progress of 
special transactions as they flow through the system auditors gain evidence to certify the accuracy 
and accountability of the system. The audit process and the collection of documentary audit evidence 
provide assurance that the system under inspection is functioning properly.

This document discusses internal auditing rather than external, particularly the internal auditing 
collection mechanism, the automated aspects of the internal audit process, and the audit trail of 
documentary evidence, all with regard to secure DBMSs.

2.2 PURPOSE OF AUDIT

The Guide to Understanding Audit in Trusted Systems points out that the purpose of audit is the 
same regardless of the computer component performing the audit [Audit 88]. That is, the audit 
objective does not change just because the component performing the audit is a DBMS rather than 
an operating system. The TCSEC control objective for accountability is:

Systems that are used to process or handle classified or other sensitive information must assure 
individual accountability whenever either a mandatory or discretionary security policy is invoked. 
Furthermore, to assure accountability the capability must exist for an authorized and competent agent 
to access and evaluate accountability information by a secure means, within a reasonable amount of 
time, and without undue difficulty.

The Guide to Understanding Audit in Trusted Systems specifies five auditing goals:

1. Allow for reviewing patterns of access

2. Allow for discovery of attempts to bypass system controls

3. Allow for discovery of use of privilege

4. Act as a deterrent

5. Provide additional assurance

Auditing should provide a database SSO (DBSSO) with a manageable set of data that can be 
analyzed to detect where in the AIS security scheme violations have taken place and by whom 
[Gluck 93]. Auditing is used to detect and deter penetration of an AIS and to reveal instances of 
misuse [Audit 88]. Audit serves as a deterrent because it documents and adds accountability to user 
actions which the user can be forced to explain. With the results of this data, an AIS security 
mechanism can be adjusted to plug ``leaks" that are identified. Auditing allows for the recording 
and review of all security relevant events and provides an additional level of user assurance that 
misuse will not go undetected [Seiden 87]. Audit can also verify that the system is intact and working 
effectively [Filsinger 93].

The computer security research community has sought to further refine auditing characteristics. 
Jajodia et al., aim for a complete reconstruction of all events in the DBMS, specifically who has 
been accessing what data in what order [Jajodia 89, 90; Kogan 91]. Hosmer proposes flexibility to 
match the threat and the needs for analysis [Hosmer 90]. Williams and LaPadula aim for external 
consistency [Williams 93]. Filsinger aims for both internal and external integrity [Filsinger 93]. 
The developers of intrusion detection and countermeasure tools seek from auditing evidence of 
activity known to represent misuse and the identification of user activity discernibly anomalous 
from historical usage [Halme 95]. Finally, Schaefer et al., go to lengths to examine modes of access 
related to audit [Schaefer 89b].

2.3 SECURE DBMS vs. SECURE OS AUDITING

The TCSEC audit requirements for a secure OS also serves as the basis for secure DBMS audit. 
However, there are some differences in applying auditing requirements to a secure DBMS. In some 
cases, the differences are due to fundamental variations in the roles of a DBMS versus an OS. In 
other cases, the distinction is due to the incorporation of features that, while not fundamental to the 
DBMS paradigm and not required for OSs, have become de facto requirements of DBMSs. This 
section describes the differences between DBMSs and OSs and how they impact auditing.

2.3.1 Object Differences

There is a greater variety of object types in a DBMS than in an OS. The typical object in an OS is 
a file or segment. In a DBMS, there can be a relation (table), a tuple (row), metadata, an index, and 
others. The TCSEC requires the audit of objects introduced into the user's address space. The 
TCSEC defines two classes of objects: named objects, which are generally used for discretionary 
access control (DAC), and storage objects, which are generally used for mandatory access control 
(MAC). For auditing, the TCSEC makes no distinction between these two classes of objects.

For many MLS DBMSs, the object of MAC (the storage object) is a row or tuple. But the named 
object may be a tuple, view, or relation. For example, Trusted Oracle storage objects are tuples and 
pipe messages. Whereas Trusted Oracle named objects are tables, views, sequences, program units, 
and snapshots [Oracle 94]. Thus, while there may be some entities that are both named and storage 
objects, some DBMS objects are only named objects or only storage objects. Since the TCSEC 
makes no distinction regarding the auditing of named and storage objects, the introduction of both 
named and storage objects into a user area must be audited.

One unique aspect of DBMS objects is that in some instances they tend to overlap (e.g., views). 
This overlap can be a problem from an audit perspective if the auditing is done at the wrong level 
of granularity. For example, two overlapping views may share a common set of data tuples, but the 
access permissions on the two views may be different. If the DBMS provides only tuple-level 
auditing, then it is not possible to capture the use of the view or audit whether or not it was a 
legitimate access. The twofold solution to the problem is to have a system flexible enough to provide 
auditing at both the view and tuple level, and to ensure that the type of access employed (via the 
view or via the base tables) impacts the type of auditing provided [Schaefer 89a].

The greater number of DBMS objects means that more data objects will be accessed. If the audit 
mechanism audits each object accessed, this could greatly increase the size of the audit trail. Given 
that the number of DBMS objects can potentially be several orders of magnitude greater than the 
number of OS objects, the impact on the audit trail size could be extremely significant. Such an 
increase could render meaningful interpretation of the audit trail impossible. Potential solutions to 
this problem include the development of highly sophisticated audit reduction tools (see Section 5).

2.3.2 Queries and Transactions

Data accesses are fairly straightforward in an OS since DAC is done only on the object itself. Thus, 
no matter what path you take to get to an OS object you are subject to that object's DAC controls. 
In a DBMS there may be numerous access paths that can access the same data, each of which has 
its own separate DAC controls. This is because of views, and the fact that in most DBMS 
implementations gaining access to a view implies access to all the information included in the view, 
regardless of the DAC controls on the underlying base tables or views. In a DBMS, the determination 
as to whether access is granted or denied is based on the choice of access paths (e.g., through certain 
views or direct access to the base tables). The determination of which access path to employ is at 
least partially under user control. Therefore, the access path that the user intended to employ may 
be reflected in the user's query.

The increased sophistication and power of query processing in a DBMS greatly complicates user 
access and the associated role of auditing. Many operations supported by relational DBMSs can be 
divided into suboperations. In addition, many of the DBMS operations can also can have a 
propagating effect. That is, one macro operation may cause, or force, other macro operations to 
take place. As a result, there are a far greater number of potential audit events. Not only does this 
increase the size of the audit trail, but it also increases the number of configuration options for audit 
collection/reduction.

Another distinction between DBMSs and OSs is the concept of transactions and transaction 
management that applies to DBMSs but not OSs. A transaction is a grouping of statements within 
a database application that form a logical work unit. By definition, a transaction must leave a 
database in a consistent state. If a transaction fails during its execution (e.g., because one of the 
comprising statements cannot obtain a lock of a DBMS resource), the transaction will abort, and 
those actions that were performed by the transaction up to that point must be undone (rolled back). 
In some instances, the transaction will automatically repeat at various subsequent time intervals 
until it finally succeeds. If these subsequent transactions also fail to complete, those transactions 
will also be aborted and rolled back as well. Once again we see potential for a significant increase 
in the number of auditable events, and in the size of the audit trail.

2.3.3 DBMS Integrity

One of the features found in most relational DBMSs is support for integrity policies. The integrity 
policies enforced by DBMSs are more than the label-based concept of integrity reflected in [Biba 
77]. Rather, integrity in the DBMS sense includes concepts of correctness (e.g., value integrity) and 
consistency (e.g., referential integrity). Neither the TCSEC nor the TDI consider incorporating such 
integrity concepts in their definition of security. Enforcement of referential and entity integrity is 
an aspect of DBMSs that makes them unique from OSs. The point that needs to be noted here is 
that auditing of DBMS integrity events, which is not required by the TDI, could greatly increase 
the size and complexity of an audit trail. For additional relevant work, consult the associated TDI 
companion document Entity and Referential Integrity Issues in Multilevel Secure Database 
Management Systems [Entity 96].

Given the additional complexities of a DBMS, including finer object granularity, support for views, 
queries, transactions (including rollback), and integrity policies (and possible auditing thereof), the 
complexity of auditing in a secure DBMS may greatly exceed that of a secure OS.

2.4 PROBLEMS AND ISSUES

As has been observed through the previous discussions, DBMS auditing poses many serious issues. 
Table 2.1 offers pointers to where some of these issues are discussed within this document. Secure 
DBMS vendors have implemented audit mechanisms and have addressed many of the issues raised 
above. Approaches from the two DBMSs that have completed NCSC evaluation (Oracle and 
INFORMIX) are cited throughout the document to provide examples of NCSC acceptable 
implementations.

Topic

Issues

References

Audit Policy

What events should be audited? How 
should an appropriate audit policy for 
the perceived risks be determined and 
adapted when the threat changes?

 Discussion, ¶ 3.1

 Named and stored objects, ¶ 2.3.1

 The TCB boundary, ¶ 3.31

 Use of OS audit trail, ¶ 4.1.3

 Class B2 covert channel

 requirement, ¶ 5.6

Auditable 
Events

What events should the DMBS be 
capable of recording? What data about 
each event should be recorded?

 Discussion, ¶ 3

 Satisfying requirements, ¶ 4.1.1

 Audit settings, ¶ 4.2

 INFORN Online Secure events

 in Appendix

Audit

Storage

If the level of granularity of audit within 
a DBMS is too fine, the resulting 
volume of audit records generated will 
be too high to permit effective 
identification of security-relevant 
events. Will denial of service occur if 
the DBMS shuts down when the audit 
trail overflows or the audit mechanism 
malfunctions?

 Discussions, ¶ 3.2, 4.3.

 Storage of DBMS audit records in 

 OS audit trail, ¶ 4.1.3

 View-based access events, ¶ 4.2.1

 NPM architecture impact, ¶ 6.4.1

 Data recording flexibility, ¶ 7



Audit

Creditabilit
y

& 
Protection

Is the audit mechanism credible? How

is the DBMS audit mechanism/guarded 
against disclosure, alteration, purging 
or disabling?

 Discussion, ¶ 4.5

 DBMS protection, ¶ 4.1.3

 Protecting against intruders, ¶ 4.3.1e

Audit

Analysis

Retrieving an item of interest is quite 
difficult given the sheer volume of audit 
records produced when DBMS 
auditing is enabled. Should the audit 
trail be stored is database itself to 
facilitate analysis?

  Discussion, ¶ 5

 The need for tools, ¶ 4.1.2

 Centralized audit trail, ¶ 4.3.1a&e

 Distributed audit trail, ¶ 4.3.1b

 OS-based analysis, ¶ 4.3.1c

 Tool performance, ¶ 4.3.2

 Summary of analysis issues and 

 current capabilities, ¶ 8.

Table 2.1: Roadmap to Discussions on DBMS Security Dilemmas 

SECTION 3

AUDITABLE EVENTS

Audit can be performed on either a continuous basis, or triggered by a particular events [Albert 92]. 
Audit, in an accounting sense, for fraud is continuous. In contrast, triggered auditing only takes 
place when a security relevant event  is deemed to occur and the need for security auditing is elevated 
(e.g., to gather evidence and log the damage so it can be repaired). This section opens with a 
description of what an audit policy covers and its variables. Following this is a discussion of each 
variable, introducing the actions to audit, objects to audit, and the data to be collected about each 
event. This section should answer the questions, what could you and should you audit.

3.1 AUDIT POLICY

An audit policy is a statement of high-level rules, goals, and practices that describe how the 
organization collects, manages, and protects its audit data [Filsinger 93]. Audit policies impose a 
structure on DBMS auditing encompassing technical, administrative, and procedural aspects of 
DBMS audit. The technical aspects of the audit policy define which objects and events to audit. 
The policy should be sufficiently detailed that it can be implemented with the technical capabilities 
of the target DBMS.

The audit policy can help to delineate which audit options are to be used: part, some, or all of the 
time. Once it has been determined what objects are to be controlled and which events are security 
relevant, then the DBMS audit options can be set to target the objects of interest and optimize the 
audit resources. The audit policy may vary depending on the level of risk and the perceived threats. 
For example, a policy of auditing only modifications to data may be changed to another which audits 
both access and modification [Hosmer 94]. The DBSSO normally establishes these policies using 
risk management principles, so that there is more auditing where there is more risk.

3.2 SELECTIVE AUDITING

Selectable audit events can be provided by the DBMS as a way to balance the trade-off between 
too much audit data against too little or none. Historically, audit options have been relatively 
inflexible, requiring DBSSOs to enable large amounts of auditing even if their audit policy only 
warranted a small amount of audit activity. Extensive auditing can degrade performance in AISs 
not designed to handle such activity and the resulting audit trail space requirements can exceed 
capacity. Selective auditing may be the only viable alternative to manage rapid DBMS audit trail 
growth.

Extreme flexibility should be the hallmark of a good DBMS audit mechanism, allowing the DBMS 
owner to tradeoff performance, storage capacity, security, and mission needs. Audit options enable 
the DBSSO to maintain performance, conserve space, and to focus on the significant audit data. 
DBMS audit mechanisms should provide a highly configurable set of audit capabilities to ensure 
that the data captured is no more or less than necessary. For example, some DBMSs provide the 
ability to audit over 200 separate database events [Oracle 94a].

Different users, groups, and objects in a system may have different audit requirements. For example, 
a DBSSO may want to single out a particular user or group of users and gather extensive data. 
Similarly, a highly sensitive view of a database may require a significantly higher level of audit than 
other views. Audit events can be divided into groups with similar types. Albert et al., divide database 
audit events into several different classes as shown in Table 3.1 [Albert 92].

Event Types

Data Included in Audit Trail

End User

All actions taken by a DBMS on the part of the end-user 
(includes SQL commands)

Database Admin

Actions by operators and database administrators to 
control or configure DBMS operation

Database Security Admin

Granting and revocation of privileges and permissions, 
and setting labels

Database Metadata

Operations relating to the structure of the database

Database System Level

Utility commands, deadlock detection, rollback and 
recovery, etc.

Opening System Interface

Utilities used and configuration changes performed 
between the OS and the DBMS

Application

Application specific security relevant events supplied by 
the application

Table 3.1: Representative Audit Trail Event Types

Enabling and disabling of audit options can be implemented in different ways. Oracle has the AUDIT 
SQL command to turn on/off audit options [Oracle 94b]. INFORMIX uses audit masks to specify 
a set of user events to be audited [INFORMIX 94]. Audit masks are implemented as a sequence of 
bits, one for each predetermined auditable event. The following describes the type of audit masks 
a database security administrator (DBSA) can use:

 Compulsory Mask - Events which are always audited for all users

 Individual User Mask - Events for a particular user that need to be audited

 Default Mask - Events which are audited for those users without an individual audit mask

 Template Mask - A pre-defined set of auditable events that may be used to quickly  
 change another audit mask

 DBSA Mask - Events which are audited for all DBSAs

In the INFORMIX implementation, each individual user always has the compulsory and individual 
(or default) mask applied to their actions. The DBSA uses a trusted interface tool, SAFE, to manage 
the audit masks. The compulsory, default, and DBSA audit masks cannot be deleted. Audit mask 
changes take effect immediately upon changes to a user's individual mask.

3.2.1. Audit Event Requirements

Systems offering higher trust include more auditable events [Hosmer 94]. For example, lower level 
systems provide passive auditing, whereas high level systems can aid in proactively anticipating 
problems. Security relevant events are identified by the vendor and may be audited for success, for 
failure, or for both. According to the Guide to Understanding Audit in Trusted Systems (Audit 88], 
depending on the TCSEC evaluation class of a system, the events in Table 3.2 should be auditable.

TCSE Class

Required Audit Events

C2 and up

 Use of identification and authentication mechanisms

 The introduction to and deletion of objects from a user's address space

 Actions taken by privileged users (e.g., operators and DBSSOs)

 Production of printed output

 All (other) ``security-relevant'' events

B1 and up

 Actions taken to disable or override human readable output labels

 Actions taken to change sensitivity ranges or levels of I/O devices and 
 communication channels

B2 and up

 Events that may exercise covert channel channels

B3 and up

 Events that may indicate an imminent violation of the system's security 
 policy

Table 3.2: TCSEC Required Audit Events

In addition to the ``security-relevant" events identified in Section 5 of the Audit Guideline, the 
TCSEC has been interpreted for the auditing of unadvertised TCB interfaces [Interp 95]. 
Interpretation 1-0286 was effective as of 1994-04-18 and applies to classes C2, B1,  B2, B3, and A1:

The following interprets the requirement that ``The TCB shall be able to record the following types 
of events:...and other security-relevant events".

The TCB shall be capable of auditing all security-relevant events that can occur during the operation 
of the evaluated configuration, including events that may result from the use of TCB interfaces not 
advertised for general use.

The TDI requires that the following events also be auditable [TDI 91]

TDI Class

Required Audit Events

All

 All access control decisions

None

 Tuples not returned because they do not satisfy the query

Table 3.3: TDI Required Audit Events

An appropriate set of security relevant events is not always easy to determine for a DBMS. The 
TDI notes that if each of several subsets (e.g., OS, DBMS) meets the audit requirements locally, 
then the set of audit records generated will meet the requirements for the whole system. If not all 
the TCB subsets meet the audit requirements locally, then it must be demonstrated that the audit 
requirements for the whole system are met by the cooperative action of the set of TCB subsets. For 
the DBMS, auditable events are the individual operations initiated by untrusted subjects (e.g., 
UPDATE, INSERT, DELETE), not just the invocation of the DBMS. Individual operations 
performed by the DBMS TCB subset, if totally transparent to the user, need not be audited by the 
DBMS. As an example, INFORMIX-OnLine/Secure auditable events are provided in the Appendix.

3.2.2 Audit Event Data

As observed previously, ``DBMS vendors have recognized that auditing requirements vary a great 
deal from site to site based on application and environment" [Schaefer 89b]. Table 3.4 presents the 
minimum TCSEC requirements for what data should be captured for each auditable event [DoD 85].

TCSE Class

Required Data

C2 and up

 Date and time of event.

 User who caused the event to occur.

 Type of event.

 Success or failure of the event.

 For I&A events, the origin of the request shall be included.

 For events that introduce an object into the user's address space and for 
object  deletion events, the name of the object shall be included.

B1 and up

 The object's security level.

Table 3.4: Audit Record Content

The TCSEC has been interpreted with regard to the data collected following an unsuccessful login 
attempt [Interp 95]. Interpretation 1-0006 was effective as of 1993-10-20 and applies to classes C2, 
BI, B2, B3, and Al:

The following interprets the requirement the ``The TCB shall be able to record the following types 
of events: use of identification and authentication mechanisms,... For each recorded event, the audit 
record shall identify: data and time of the event, user, type of event, and success or failure of the event."

While the audit mechanism is requirement to be capable of producing a record of each login 
attempt, on failed login attempts  it is not required to record in the audit record the character 
string supplied as the user identity.

Over and above the TCSEC requirements, the specific data that should be collected for each event 
depends both on the nature of the event and the needs of the auditor. This includes not only what 
to audit, but specifically what data should be collected for those events which are audited. Not only 
does a DBMS need to provide flexibility as to which events are to be audited, but what data is to 
be collected for each event.

3.3 AUDITING ACCESS CONTROL EVENTS

The TCSEC has been interpreted for audit of access control events [Interp 95]. Interpretation 1-
0073 was effective as of 1993-10-20 and applies to classes C2, B1, B2, B3, and Al:

The following interprets the requirement that "The TCB shall be able to record the following types 
of events:..introduction of object's into a user's address space (e.g., file open, program initiation). . .``

Auditing the attempted introduction of an object at the point of passing the security access 
control checks satisfies the above requirement, even though the object may not actually be 
introduced into the subject's address space because of failing later checks not related to 
security.

This section considers how best to determine what should be considered an auditable DBMS access, 
including ramifications for context and content dependent accesses.

3.3.1 What is a DBMS Access?

Consider the situation in which the audit requirement is that all accesses must be audited. Let us 
use as our example a query issued against a non-indexed relation (such as the relation in Figure 
3.1). Because the relation is non-indexed, the DBMS will retrieve each tuple in the relation to see 
if it satisfies the logical conditions of the query. Now the question is, do each of these retrievals 
constitute an access that needs to be audited? If so, then the entire relation (one tuple at a time) will 
be accessed and the relevant data placed in the audit trail. The consequence of such an action is a 
huge, and to a large extent meaningless, audit trail.

Name

Job Title

Age

DEPT

Security Level

John Smith

Engineer

21

2

U

Mary Jones

Manager

29

4

U

Jeff Johnson

Spy

32

13

TS

Figure 3.1  EMPLOYEE Relation

What then should constitute an auditable DBMS access? The answer most consistent with the TDI 
and TCSEC is that an auditable access is the data that is passed beyond the TCB boundary. A 
consequence of this interpretation is that if the TCB encompasses the entire DBMS, which is true 
for some Class C2-B1 DBMSs, then only the data that is returned to the user is considered an access. 
The major problem with this approach is that data not returned but used as a basis of the selection 
and qualification process is not represented. This would adversely impact detection of unauthorized 
access attempts including potentially the detection of the exploitation of covert channels at B2 and 
higher.

The most logical answer to this dilemma would be to consider only that data which is returned after 
the DBMS performs a logical qualification on the fetched tuples as an auditable access. But if the 
logical qualification function is part of the DBMS TCB, and it in turn passes the data to still another 
part of the TCB, then one is in effect auditing the internal functions of the TCB. Such an action is 
not required by the TDI and the TCSEC.

The truth is that there is no single best answer to the question of what constitutes a DBMS access. 
What is apparent is that the answer is dependent upon the nature and structure of a given DBMS 
TCB and hence is architecturally specific. This question of auditing DBMS accesses is explored 
further in Section 6.3.1. However a DBMS access is identified, DBMS vendors need to define it in 
their assurance documentation.

3.3.2 Content and Context Dependent Access Control

DBMSs can enforce content-dependent or context-dependent access control policies. The most 
common implementation of these policies involves views and triggers. For example, a view might 
be constructed against the EMPLOYEES relation (Figure 3.1) and would constrain some users to 
access only those tuples in which the Employees were in Departments 2 and 4. Thus, any changes 
to the contents of these fields through the new view would have impact on subsequent user access 
requests. At the very least, this construction would increase the size of the audit trail because one 
more auditable event would be included.

More sophisticated DBMSs can also support context-dependent access control. For example, a 
trigger could be set on relation X that would prohibit a user from accessing the relation if he has 
reviewed specified tuples in relation Y or Z in the last 24 hours. Such a technique might be used to 
address inference threats. To determine whether the access control condition is satisfied, a history 
log would be required. A separate history log could be developed for this purpose. In fact, a system 
such as this is employed in the LOCK DBMS [Haigh 90]. In order for the audit mechanism to detect 
potential security violations of such a policy, it would need to collect all accesses to relations Y and 
Z by all users. This action would likely significantly increase the size of the audit trail.

3.4 AUDITING DBMS INTEGRITY

Most DBMSs and MLS DBMSs support referential integrity. That is, the DBMSs support 
mechanisms for placing bindings or constraints on multiple relations. As noted in Section 2.3.3, 
the TDI does not require auditing of DBMS integrity events. However, since integrity enforcement 
is such a key feature of a DBMS, Jajodia believes that integrity related audit events should be a 
consideration [Jajodia 90].

A simple example of this is the definition of a foreign key in one relation that refers to another 
relation. Consider a new multilevel relation, DEPT, which has three attributes: DEPTNO, NAME, 
EMP_COUNT and a Row_Label for each tuple. The EMPLOYEES relation, defined earlier, also 
has a DEPTNO field, and this field could be identified as a foreign key for DEPT..

DEPTNO

NAME

EMP_COUNT

ROW_Label

2

John Smith

21

U

4

Mary Jones

29

U

13

Jeff Johnson

32

TS

  Figure 3.2: DEPT Relation

Now, a database designer might wish to use referential integrity to ensure that each employee must 
have a valid department number in the EMPLOYEE relation. During the completion of a tuple 
insertion into the EMPLOYEE relation, the DBMS checks the DEPT relation for the existence of 
a DEPT record that has the same value for DEPTNO as the one being inserted. Not only does this 
extra operation increase the potential for the generation of an audited event, but the nature of these 
new audit events could take many forms. For instance, if a No Valid Department error is returned, 
then the New Employee record does not satisfy the integrity constraint, the insertion operation fails, 
and it should probably be audited. On the other hand, if a valid department record exists but is 
classified at a level higher than the user's operating level, then the successful completion of the 
insertion may be considered a write-down of the fact of the existence of the department. Likewise, 
the failure of the insertion due to classification would probably also be an event that should be 
audited.

Another more complex example of referential integrity occurs when an operational constraint is 
placed on a pair of relations. For instance, a database designer may wish to impose a constraint 
where employee records cannot exist without a Valid Department. One way of doing this is to define 
a delete cascade on the DEPTNO foreign key. A cascading delete operation will force a DBMS to 
delete all EMPLOYEE records with the corresponding value of DEPTNO when a given DEPT 
record is deleted, and such an operation can potentially generate many auditable events.

SECTION 4

AUDIT STORAGE, PERFORMANCE, AND PROTECTION

The previous section described what events could be audited and how to decide which events should 
be audited. This section presents an implementation oriented view of auditing. Specifically, it 
addresses for specific data that can be collected (Section 4.1), when to collect it (Section 4.2), where 
to store it (Section 4.3), how much to store (Section 4.4), and how to protect it (Section 4.5).

4.1 AUDIT IMPLEMENTATION

There are many goals for audit implementations. The most basic is to simply meet the TCSEC 
requirements. However, researchers have also proposed audit mechanisms that capture the intent 
of users. Other audit mechanisms allow applications to insert audit entries. Issues related to these 
approaches are discussed in the following sections.

4.1.1 Auditing to Satisfy the Requirements

Section 3 discussed the audit requirements from the TCSEC. Given these requirements, they should 
be relatively straightforward to satisfy. Auditing of I&A events is normally done at a single point 
within the TCB. Auditing for access control events depends on how objects are stored and the 
granularity of the access control mechanism.

For DAC, controls are typically provided down to the table or view level. Thus, each access to any 
or all tuples within a table or view will require a single audit record to be generated to satisfy the 
auditing requirement for DAC. However, for MAC, it can be a very different story. MAC is typically 
provided down to the tuple level, and can even be provided down to the element level. The number 
of MAC decisions that are made depends on how tuples are stored internally, not necessarily how 
they are represented to the users. For example, a DBMS can provide tuple level labeling by storing 
all tuples of like sensitivity levels in a single object (e.g., INFORMIX OnLine Secure [INFORMIX 
94]). If this is done, then a single MAC check is done for each level, rather than one per tuple. This 
may significantly reduce the amount of audit data that must be recorded to satisfy the requirements.

If tuples are individually stored and labeled, then each time a MAC check is made on an individual 
tuple, that data must be recorded in the audit trail (for enabled events). This can cause a significant 
amount of data to be recorded in the audit trail, depending on the query, contents of the database, 
and its organization. For example, a query by an Unclassified user which asks to return all tuples 
from a table will require the access decisions to each and every tuple in the table to be recorded in 
the audit trail, since a MAC check will have to be done on each tuple to determine whether it can 
be returned to the user. Now, according to the TDI, if the user includes a WHERE clause in the 
query, then all tuples that are excluded because they do not satisfy the selection criteria do not have 
to be audited.

4.1.2 Auditing to Capture Intent

If only the security relevant data explicitly required by the TCSEC is recorded, it may be difficult 
for a DBSSO to grasp the intent of a user's query from this data. This difficulty may be compounded 
based on where during query processing the auditing is actually performed. These two issues are 
discussed in the following paragraphs.

To help grasp the user's intent, it is desirable to record the entire text of each SQL statement in the 
audit trail. This allows the DBSSO to better understand what a user was trying to do, rather than 
trying to infer this based on the audit record generated during the processing of the query. Recording 
transaction starts and ends will also help the DBSSO understand what queries or changes are being 
attempted and which changes are actually committed to the database.

In high assurance DBMSs, the parser, compiler, and optimizer may have to be excluded from the 
DBMS TCB to reduce the size and complexity of the TCB. If this is the case, then the TCB may 
receive only correctly formed and optimized queries rather than the raw original queries from the 
user. When trying to determine the intent, it may be much more helpful to see the original query, 
rather than the parsed and optimized query. As such, it would be helpful if the original query 
submitted by the user was recorded, rather than the optimized one. To do this with assurance, there 
must be an extension of the TCB which captures user input at the user interface, audits this data, 
and then passes this data on to the parser/optimizer/compiler before it is eventually submitted back 
to the TCB.

Thus, for all operations:

 The entire text of the SQL statement should be recorded.

In addition, for certain operations, it is sometimes desirable to collect additional data beyond what 
is minimally required. Therefore:

 For UPDATES, the old and/or new data values should be recorded.

 For INSERTS, the value of the inserted data should be recorded.

 For DELETES, the value of the deleted data should be recorded.

Other data that might be useful to record for failed events is the reason why the event failed. Related 
to this is recording the security levels or authorizations associated with the user at the time of the 
event or a means for obtaining this data. This data can be helpful when trying to identify why an 
access attempt failed.

Regardless of when a query is recorded in the audit trail, the audit trail must ensure that the DBSSO 
can trace each piece of audit data back to the query which caused that data to be included in the 
audit trail. This is crucial because a single query can cause a huge amount of data to be recorded 
in the audit trail. This can be done in a number of ways, including storing all related data for a query 
in a single audit record, or including some type of reference number with each audit record that 
allows it to be traced back to the query which caused the record to be generated.

Similar to associating data with queries, it would also be helpful to be able to easily associate queries 
with transactions. Each transaction is composed of a series of queries. From the auditing perspective, 
all of the accesses generated as a result of a transaction constitute a legitimate read and write. If all 
audit records are written out, whether a transaction is rolled back or not, not only are additional 
audit events generated by the rolling back and repeating of transactions, but many of these audit 
events provide an essentially false picture of the state of the system. In addition, the repetitive 
attempts at access may be logged by the audit mechanism and potentially misinterpreted by the 
DBSSO as user-attempted security violations.

To address these problems, the audit mechanism must have some way to identify those events that 
are part of a completed transaction and those that are not. This identification may require the 
transaction manager to notify the DBMS when it begins, completes, or fails a transaction. The 
appropriate data could then be appended to the records in the audit log corresponding to the data 
that was accessed. The difficulty with this approach is that the data about accesses will likely be 
recorded prior to the data regarding transaction completion or failure. To make the audit data useful 
to the DBSSO some form of audit analysis tool is needed to correlate the data [Schaefer 89a]. To 
help a DBSSO trace the progress of a transaction, it would be helpful if the audit analysis tool could 
thread the associated queries together.

Therefore, the following data is recommended for capture in the audit trail:

 Reason why an event failed, including the user's security levels or authorizations, or 
  a pointer to this data.

 The original query, prior to parsing or optimization.

 Each audit event record should be traceable back to the query which caused it.

 Each query that is part of a transaction should be traceable to the transaction.

 Whether a transaction eventually was committed or was rolled back.

4.1.3 Application Specific Auditing

Just as most trusted OSs enable their applications to insert audit records into the OS audit trail, it 
is recommended that DBMSs also provide their applications with a similar interface. The goal is 
to collect audit data that is meaningful to the DBSSO. For example, Compartmented Mode 
Workstation (CMW) requirements include the ability to accept data from processes which have 
been given the privilege (e.g., writeaudit) of writing their own audit records [Picciotto 87]. Another 
privilege (e.g., suspendaudit) can then be used by these processes to suspend and resume OS auditing 
of their actions. If the relevant application is collecting event data, then the underlying OS can have 
its lower level auditing disabled for activities related to that application. Thus, the OS can avoid 
cluttering the audit trail with low level events and retain the focus on activities of the subjects at 
the proper level.

This capability can be provided for DBMS applications in a couple of ways. If the DBMS inserts 
its records into the OS audit trail, then applications can use this same capability to insert records 
into the OS audit trail. This is what INFORMIX [INFORMIX 94] and Oracle do when the database 
is set to write all audit records to the OS audit trail, rather than storing it in a DBMS audit trail 
[Oracle 94b]. If the DBMS keeps its own audit trail, it should also have a mechanism for privileged 
database applications to insert their own audit records into the database audit trail and provide 
appropriate protection of the audit trail.

Another capability for generating ad hoc records that can provide additional audit flexibility is the 
ability to use triggers to generate customized audit records [Oracle 94a]. This allows the DBSSO 
to capture specific data based on whatever data the trigger can test on. For example, a trigger could 
be used during an UPDATE to capture both the old and new values of any tuple modified by the 
UPDATE. Triggers could also capture different data based on tuple accessed, user performing the 
operation, time of day, object sensitivity, old or new element values, etc. Such a capability could 
be used to provide much of the desired collection flexibility described in Section 7. This capability 
also has the additional advantage that it places the trust of performing the audit into the DBMS 
audit mechanism, rather than having it done in an outside application. This helps minimize the 
amount of trusted code that must be developed to support an application specific audit policy 
[Hosmer 94].

4.2 AUDIT SETTINGS

Section 3 talked about various types of auditing that could be performed, including statement, 
privilege, and object auditing. What is to be audited, and hence what is recorded when an event 
occurs, is typically defined by the DBA, DBSSO, or object owner. For statements and privileges, 
audit parameters are defined for each statement or privilege. Whenever a statement or privilege is 
used, the appropriate data is collected, regardless of the audit settings of other statements or 
privileges, or the objects accessed.

For views and base tables, the data to be recorded is not necessarily straightforward due to the 
explicitly defined relationships between them. Typically, audit setting data is recorded for each:

 Base table definition,

 View definition.

Based on this, audit is typically performed each time a view or underlying base table is accessed. 
The exact details of what is audited depends on the defined precedence between view and base table 
audit settings and how these settings are established. These two issues are discussed in the following 
subsections.

4.2.1 Audit Setting Precedence for Views and Base Tables

The DBMS designer must decide what the relationship is between audit settings associated with a 
view and the settings of any base tables or views accessed by the view. A number of options are 
available:

1. The highest level (most abstract) view settings take precedence.

2. The base table settings take precedence.

3. A union of the settings of all views and base tables accessed is used.

4. The intersection of the settings of all views and base tables accessed is used. 

These options each have certain benefits and drawbacks as follows:

Using the highest level view settings is a simple mechanism and allows the creator of the view to 
specifically identify what is audited and when. However, this may override the desires of the owners 
of the underlying views or base tables. In fact, with this mechanism, changes to the audit settings 
of underlying views or base tables will have no effect on higher level views, unless changes are 
somehow propagated to other views.

Using base table settings ensures that the owner of the base table has complete control over what 
is audited when that table is accessed no matter how it is accessed. This has the benefit that auditing 
will be consistent across all views to the underlying base table but has the disadvantage that auditing 
cannot be tailored for specific views. In this approach, changes to the audit settings of a base table 
would automatically be used by all views which access the table, and view level settings would be 
unnecessary.

Using the union of the settings would be a more complicated mechanism. Given that a view can 
build upon other views which in turn can be built on other views, etc., the number of settings that 
must be UNIONed together could be difficult to compute. This type of mechanism could cause the 
amount of audit data generated to be much larger than what is desired if the audit settings are not 
managed properly, but it ensures that the auditing desires of the owner of each view or base table 
are met because the union of these settings is what is audited. This mechanism would have the 
advantage that changes to the audit settings of more primitive views or underlying base tables would 
automatically be invoked when higher level views are accessed. Trusted Oracle functions this way 
by generating a separate audit record for each view accessed by a particular function [Oracle 94b]. 
In this way, Oracle does not need to compute the UNION of the settings, rather it automatically 
generates a separate audit record for each view accessed by a function, regardless of how the user 
got to that view (i.e., directly or through another view). It generates each record based on the settings 
of that particular view and if these settings indicate that no record should be generated, then no 
record is created. This has the disadvantage that multiple redundant audit records may be generated 
but it ensures that all uses of a particular view are recorded.

Using the intersection of the audit settings (i.e., only audit when all audit settings indicate that it 
should be done) may be difficult or impossible to compute. Intersection may also cause the amount 
of audit data captured to be insufficient for reconstruction of the event which caused the audit record 
to be generated. Without proper management, the amount of data audited could be null. It is not 
clear how intersection would be computed when multiple views are used to construct a higher level 
view. It is not expected that this would be a reasonable choice for an audit precedence mechanism.

INFORMIX avoids this issue by supplying audit masks that are associated with individual users, 
independent of the objects they might access [INFORMIX 94]. These masks are used to indicate 
which events are to be audited for that individual (e.g., object creation, deletion, access; database 
or table privilege granting or revoking). Using this mechanism avoids the necessity to determine 
precedence of audit setting among views and base tables but does not provide the flexibility of 
adjusting audit settings on a per view or base table basis.

4.2.2 Establishing New Audit Settings for Objects

Once the audit settings precedence among views and base tables has been established, a specific 
procedure for establishing and maintaining audit settings needs to be defined by the DBMS vendor 
and implemented in the DBMS to promote a consistent and easy to manage audit capability. Since 
a base table is the most primitive view of that data in the database, the settings on a new base table 
are initially not related to any other view or base table. As such, the owner of the base table (or 
those with the appropriate privilege/role) should simply enable the audit settings as desired and that 
should complete the operation.

When a view is created which is based on the underlying base table, the settings can be defined in 
a number of ways, and should be affected by the audit setting's precedence defined between the 
view and the base table as discussed previously. If audit settings are only recorded for base tables 
(e.g., choice 2 from above options in Section 4.2.1) then no audit setting data needs to be recorded 
when a new view is created. If the union of the settings is used (choice 3) then the creator of the 
view simply adds any additional data that should be audited to this view definition. When the settings 
are UNIONed together, all the desired data is audited and, if the base table settings were subsequently 
changed, any new data would be captured. Data removed from the base table settings would not be 
recorded, unless it was also specified in the view definition that this data should be recorded as well.

If the highest level view settings take precedence (choice 1) then the underlying base table settings 
have no affect on what is audited. In this case, the user could create new audit settings from scratch, 
or for consistency or ease of use, the default settings of the new view could be set to the union of 
the underlying views or base tables accessed by the view (Schaefer 89b]. This would make the 
default settings equivalent to the settings on the underlying views. These default settings could then 
be modified as desired by the owner of the new view.

4.2.3 Modifying Audit Settings

Established audit settings typically evolve over time. The difficulty here is trying to make the audit 
settings as consistent and easy to manage as possible while providing the desired flexibility. The 
TCSEC has been interpreted to ensure that the enforcement of audit settings is consistent with the 
AIS's protection goals [Interp 95]. Interpretation 1-0004 was effective as of 1993-10-20 and applies 
to classes C2, B1, B2, B3, and Al:

The following interprets the requirement the ``The ADP system administrator shall be able to 
selectively audit..."

If the TCB supports the selection of events to be audited, it shall provide a method for 
immediate enforcement of a change in audit settings (e.g., to audit a specified user, to audit 
objects at a particular sensitivity level); however, the immediate method (e.g., shutting the 
system down) need not be the usual method for enforcement. The TFM shall describe both 
the usual enforcement of audit settings and, if the immediate enforcement method is different 
from the usual one, how an administrator can cause immediate enforcement.

The TFM shall describe the consequences of changing an audit state dynamically if such 
changes could result in incomplete or misleading audit data.

If audit settings are only recorded for base tables (choice 2), then changes to the base table audit 
settings are automatically used whenever they are accessed by a view. If audit settings are the union 
of all views and base tables accessed by the view (choice 3), then any changes to the audit settings 
of the underlying views or base tables are also automatically reflected in the auditing performed by 
any higher level views.

Only when the audit settings of the highest level view take precedence (choice l) do changes to the 
audit settings of more primitive views or base tables not affect the audit records generated by higher 
level views. Mechanisms could be created which aid the user in propagating changes to views which 
reference a more primitive view. This is a research issue. Difficulties could arise in finding these 
view definitions and the user may not possess the appropriate permissions to change higher level 
views which the user may not own.

4.3 AUDIT STORAGE

Previous sections discussed what events should be auditable and what data should be recordable 
for each event. This section discusses storing the audit data that is ultimately captured by the DBMS.

4.3.1 Audit Storage Location

A DBMS (particularly the server portion) typically runs on top of a trusted OS which is performing 
its own auditing. The relationship between the OS and DBMS is one factor in the equation of how 
to store audit data most effectively. There are many other factors that affect the decision as to which 
storage option should be selected for storing DBMS audit data. Some of the possible storage options 
are as follows:

a) Store all DBMS audit data in a single audit trail that is independent of the OS audit 
  trail (for MLS DBMSs, this would be a database-high object).

b) For MLS DBMSs, create a separate audit trail for each sensitivity level and 
  compartment combination.

c) For DBMSs running on top of an OS, insert the DBMS audit records into the OS audit 
  trail.

d) Merge the DBMS audit trail with or use the DBMS transaction/recovery log as the 
  audit repository.

e) Forward the audit trail to a specified location.

These options each have certain benefits and drawbacks, some of which are described as follows:

a) Using a Single DBMS Audit Trail

The most common audit storage method is to store all the DBMS audit data in a single audit trail. 
This can either be within an audit database or a raw file managed by the OS. This method is fairly 
simple to implement as the DBMS owns and controls all the necessary resources. A single audit 
trail also aids the audit analysis task since all the audit data is chronologically stored in a single 
location, which makes it easier for an analysis tool to search for and correlate related events. The 
ease of analysis depends on the sophistication of the supplied audit analysis tools, which can range 
from the primitive (e.g., UNIX grep) to the sophisticated. For MLS DBMSs, all records in this audit 
trail can either be treated at system-high, or, if stored in a database, each audit record can be 
individually labeled to help track the session level of the user associated with each event. Labeling 
each individual audit record is beneficial because it provides another factor to distinguish audit 
records from one another. Labels also provide the ability to allow certain users to access portions 
of the audit trail without requiring a clearance for all levels of data stored in the audit trail.

b) One Audit Trail Per Sensitivity Level

Recording a separate audit trail at each sensitivity level is not commonly done, however, for certain 
MLS DBMS architectures, it is required unless the underlying OS permits blind write-ups. This 
approach is specifically required for DBMSs that are not trusted with respect to the underlying MLS 
OS's MAC policy. As described in Section 6.4, in the No MAC Privileges architecture, each DBMS 
instance logs audit records at its corresponding sensitivity level. Performing audit analysis can be 
more difficult in this configuration because the data is distributed across a number of different files. 
If the underlying OS permitted blind write ups, then a single audit trail could be created at the 
highest level of the database by allowing each component of the DBMS to append audit data to the 
audit trail. If this approach was taken, the lower level DBMSs would not be able to view the audit 
data that they contribute to the audit trail. Only a DBMS or a DBSSO with access to the highest 
level of data in the database would be permitted to view the audit data. No current DBMSs use the 
blind write up approach.

c) Merging the DBMS Audit Trail with the OS Audit Trail

Another option for recording audit trail data is to insert the DBMS audit trail data into the OS audit 
trail. This option depends on OS support for this capability. This has the advantage that the audit 
trails are merged into a single location. However, there may be difficulties in correlating related 
events between the OS and DBMS while ensuring that the chronology between events is maintained. 
Synchronized clocks will help alleviate the latter problem but the former depends on the granularity 
of data that is known and dealt with by the respective systems. For example, when a user who is 
accessing the OS then logs in to the DBMS, a record must be stored in the audit trail which associates 
the OS userid with the DBMS userid, or they must be identical on the two systems. This allows the 
actions of a single user to be correlated together regardless of whether the action occurred at the 
OS level or in the DBMS. However, even this simple approach can become complicated when in a 
client-server environment. Another difficulty factor is that an OS level audit analysis tool may not 
be able to access data stored in the database which is helpful to the analysis, whereas a DBMS 
specific audit tool may have that capability.

d) Merging the DBMS Audit Trail with the Transaction Log

Some discussion has been made in the literature (e.g., Schaefer 89b] about merging the DBMS 
audit trail with the DBMS transaction/recovery log since that data has to be recorded anyway. The 
idea is that it may be more efficient to record this data together since some of the data may be 
redundant between the two logs. However, the difficulties that arise have tended to outweigh the 
benefits of this approach. For example, dealing with roll backs and the subsequent loss of audit 
records caused by the rollback may be a problem, as well as trust issues surrounding the use of the 
transaction log and possible interference with the usability of the transaction log for its original 
purpose. Since the integrity of the audit trail must be guaranteed, merging it with the transaction/
recovery log requires that all software that creates, modifies, or purges the transaction/recovery log 
be trusted to protect the contents of the log and as well as ensure its accuracy.

However, using the transaction log as a supplement to a separate audit trail may not be a bad idea. 
The audit log can be used to record all the data required by the TCSEC and TDI, e.g., all access 
control decisions, I&A actions, etc., while the transaction log can then be used to provide additional 
data that might be helpful to a DBSSO when reconstructing events. The transaction log already 
provides data such as field values before and after changes, which changes are related to specific 
transactions, etc., and may be easily modified to include other additional data. In fact, the transaction 
log may be a more suitable place to collect some of the additional data that is recommended in 
Section 4.1.2. If the assurance of the transaction log is an issue, it may be fairly straightforward to 
provide a reasonable level of assurance as to its accuracy and integrity. The point within a DBMS 
where transaction entries are typically recorded is at a fairly low level within the DBMS. Thus, the 
mechanism should be fairly small and it should be feasible to provide reasonable assurance 
arguments as to its correctness. Some additional controls might be required to limit the ability to 
modify the transaction log to only a few select users and applications to ensure the integrity of the 
log after it is created.

e) Forwarding Audit Data

The ability to forward the audit trail to another location can be useful for a number of reasons 
[Schaen 91]. For example, if the DBMS is in a networked environment where an audit server is 
present, storing all the audit data on the server has the advantage that all the audit data is collected 
into a single location, making audit analysis and correlation easier. Obviously, a sophisticated audit 
server and audit analysis tool must exist which can store and manage this data. It must be able to 
correlate events across platforms and applications. From the DBMS point of view, all it needs to 
provide is the capability to forward audit data to an alternate location rather than storing it locally. 
Another reason might be to provide the ability to forward the audit data near real time to a separate 
location which is performing intrusion detection.

It is also desirable to be able to forward audit trail records to specific locations for protection reasons, 
such as write once devices, removable media, or duplicate locations [Hosmer 94]. These techniques 
are used to help protect audit trail data from intruders who might gain access to the system and wish 
to damage or destroy the audit trail to cover their tracks.

4.3.2 Audit Storage Format

Another issue that must be dealt with is how to store the audit data. Since audit trails typically tend 
to be quite large, efficiency of storage is a key issue. However, there are significant trade-offs between 
efficiency of storage and efficiency of analysis, since techniques to improve each capability tend to 
adversely affect the other. For example, minimizing the data recorded in each audit record by 
including references to other audit records or data available in the database (e.g., the identification 
database) rather than copies of the referenced data makes the audit trail smaller, but makes analysis 
slower because the references need to be looked up to find the data. Another problem with this is 
that sometimes the referenced data may not be available when the analysis is performed (e.g., due 
to audit trail truncation or if the analysis is performed on another system which does not have access 
to the auditing system's identification database). These audit problems are not specific to just 
DBMSs, they are the same as those faced by trusted OSs as well.

Another desire is to store DBMS audit data in a format that is compatible with the audit trails of 
other trusted components that will be used with the DBMS, such as the host OS or network. One 
could expect the DBMS to have a portable audit record format so that correlation of audit events 
between the DBMS and OS would be easier. Audit trail format standards efforts do exist [Sibert 
88]. Some of these efforts, such as those by IEEE POSIX 1003.6, have considered including security 
extensions which would include a standard format for audit data as well as a standard Applications 
Programming Interface (API) for submitting audit data to the host OS.

4.3.3 Audit Storage Longevity

Another issue that can become very important when managing DBMS audit data is how long to 
keep the data [Audit 88]. The critical factors are how fast audit data is generated and how much 
storage is available to keep the data. There are a number of techniques for long term management 
of audit data. A single technique can be used, or multiple techniques can be combined in various 
ways to best optimize audit storage based on amount of storage available, retrieval time desired, 
data to be retained, etc. The primary techniques are described as follows:

Archival is the process of taking audit data from primary audit storage and moving it to some other 
storage location. This is typically to tape or some other secondary mass storage device. The oldest 
audit data currently stored on the system is what is normally archived while the more recent data 
is left on the system in case immediate access is needed. Archival has the advantage that no audit 
data is lost but has the disadvantage that is it not immediately accessible if needed.

Truncation is basically discarding some portion of the audit trail, typically the oldest. Discarding 
can be directly from primary audit storage or from an archive. Truncation is typically inevitable 
because primary audit storage or secondary storage eventually becomes full. The decision to truncate 
is based on available storage, the criticality of the audit data, and its age, which obviously can vary 
widely from system to system.

Trimming is a technique whereby certain records in the audit trail are removed rather than 
chronologically truncating the audit trail. The records deleted should be selectable by the DBSSO. 
This allows the DBSSO to delete those records that provide more detail than desired or are deemed 
not important while retaining those records that are important to them. This has the advantage that 
the audit trail size is reduced while the important records are retained for future examination.

Compression can be used to reduce the physical size of the audit trail to a significant degree, 
sometimes as much as 50% or more [Sibert 88]. This has the advantage that less storage is required 
and no audit data is lost. The disadvantage is that a small amount of extra time is required to store 
or access the data (this is usually more than offset by the speed gain due to less disk/tape access).

Abstraction is used to retain statistical data about a series of audit records rather than the records 
themselves. This technique can be used to summarize data into a more compact form through use 
of counts, averages, etc. This format is sometimes more useful to systems such as intrusion detection 
systems who detect violations based on changes to `normal' behavior, in addition to the reduction 
in audit trail size.

All of these techniques should be made available to the DBSSO in order for him to be able to select 
the combination of techniques that are most effective for the site's particular needs.

4.4 PERFORMANCE

Performance has always been a significant issue for trusted OSs which perform auditing. 
Performance is even more critical to trusted databases because of the granularity of the objects 
involved and the potential volume of transactions to be audited. However, the techniques and issues 
surrounding audit's affect on performance are basically the same as for trusted OSs and are not 
further elaborated here.

Due to the potential impact that audit can have on the performance of a high performance DBMS, 
it is much more critical for the DBMS developer to make the audit mechanism as efficient as possible. 
Regardless of what steps are taken to improve performance during auditing, one of the most effective 
mechanisms that can be supplied is to provide a highly configurable audit mechanism which permits 
selective auditing of particular events and selective recording of particular data for each event (See 
Section 7 for more detail on this capability). This allows site specific audit policies to be enforced 
in a manner that closely matches the site's needs without recording unnecessary data and paying 
the performance penalty this might cause.

4.5 CREDIBILITY AND PROTECTION

For the audit trail to reflect a trustworthy record of the events which are supposed to be collected 
by the audit mechanism, it is necessary that the events which are recorded accurately and completely 
reflect events that occurred and that the audit trail is protected from modification. In addition to 
protecting the audit trail from modification, it is also important to control observation of the audit 
trail because it will typically contain sensitive data. Finally, it will be necessary to make decisions 
on what actions to take when the audit trail storage space reaches capacity. These decisions will 
typically involve tradeoffs between completeness of the audit record and availability of the system. 
Each of these issues is discussed below.

4.5.1 Audit Trail Credibility

The credibility of the audit log determines the degree to which the audit log can be used to reconstruct 
the history of the usage of the DBMS. This in turn affects the usefulness of the audit trail to identify 
attempted misuse, successful or not, of the DBMS, as well as the usefulness of the audit trail for 
investigation of misuse or intrusion detected by other means. Schaefer et al., note that the issue of 
the ability of a TCB to accurately record auditable events can be posed in two forms [Schaefer 89b]. 
A weaker form is to ask whether:

When the TCB detects an event, is that event (and its association with a user and its time 
of occurrence) accurately recorded in the audit trail?

This question can be addressed by looking specifically at the audit mechanism and the protection 
afforded the audit trail. A stronger question is whether the event that is recorded represents what 
actually occurred. To answer this question one must do more than just examine the audit mechanism. 
The question can be divided into two parts. The first part is the question above. The second question 
is:

When the TCB detects an event, (and its association with a user and its time of occurrence), 
did precisely that event occur during system execution?

This second question goes directly to the TCB's ability to control the actions of subjects on objects. 
If the TCB has no way to determine accurately that an event has occurred, it cannot mediate that 
event. The ramifications of this observation for different architectures is considered further in 
Section 6.

Access to the database through views is a particularly important case with respect to how much one 
can trust the relationship between what is recorded and what was executed. In particular, if the TCB 
detects a request to access the database through a view, then whether or not that event is the event 
executed may depend on the trustworthiness of the query language parsers or compilers. Recently, 
Schaefer et al., have taken a new look at what types of view based controls can be enforced with 
high assurance [Schaefer 94]. Their findings can be used to understand what can be trusted about 
the actual events executed when a given event is recorded in the audit trail.

Regardless of the degree to which the harder question of accurately reflecting actual event execution 
can be answered, it is essential that the audit trail at least accurately reflect detected events. Potential 
loss of audit data is one of the focuses of an evaluator's audit mechanism review. This means that 
assurance techniques appropriate for the target system assurance level must be employed to show 
that the audit mechanism accurately and completely records events given to it within the context of 
the current audit configuration as established by privileged users. When audit information is kept 
in database audit tables in the form of database rows, this information can only be lost or recovered 
as other database information is lost or recovered.

For example, Oracle table data can be lost if there is a media failure involving the Redo Log or the 
Control file (if the affected file is uniplexed) [Oracle 94b]. Otherwise, no relevant records can be 
lost because the audit trail entry is written before results are returned to the user. The user transaction 
does not have to commit before the audit record is written; writing the audit record is a sub-
transaction that completes before the main transaction does. Therefore, the system could have audit 
records for events that rolled back and therefore never occurred, but would have records for all 
committed transactions and completed queries.

4.5.2 Access Control for the Audit Trail

Unauthorized modification or deletion of the audit trail can clearly subvert its usefulness for 
supporting any audit objectives. The TCSEC requires that [DoD 85]:

The TCB shall be able to ... protect from modification or unauthorized access or destruction an 
audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so 
that read access to it is limited to those who are authorized for audit data.

Well publicized attacks on standard OSs have involved modification of the audit trail by the intruders 
in order to cover their attacks. In one important instance the attack was first noticed because the 
modification was done somewhat clumsily and actually caused the size of the audit trail to decrease 
[CMADIII 95]. Many studies have found that it would be desirable to do auditing at the level of 
applications which understand the meaning of a user's requests [Schaefer 89b]. Hence, it may be 
useful to allow applications to append data to an audit trail as described in Section 4.1.3. 
Nevertheless, it is essential that the ability to delete or modify records be closely controlled within 
the TCB.

While it is obvious that the ability to alter the audit trail must be tightly controlled, it is also the 
case that observation of the audit trail must be controlled. In general, audit records will directly or 
indirectly contain a significant amount of data about what is in the database. Hence, observation of 
the audit trail is a path for observing data from the database. In a system which supports MAC, 
audit trail data must be protected at a level which is an upper bound of the data recorded and the 
transaction causing the event. If the entire audit trail is protected as a single object, the audit trail 
must be protected at the highest level of any data in the database. In any system, observation of the 
audit trail should be limited to those with a legitimate need-to-know. Beyond the fact that 
unauthorized observation of the audit trail could compromise data which the DBMS is supposed 
to protect, observation of the audit trail directly reveals the setting of current audit parameters. This 
gives an intruder data which could be used to minimize the chance of detection of malicious actions.

There are several methods for providing the required protection for the audit trail. If the DBMS 
audit records are entered into the OS audit trail, the OS TCB will provide the required protections. 
However, the tools for correlating OS audit records with DBMS audit records and the procedures 
for granting privilege to the users who can review the audit trail must be carefully designed to make 
sure that they do not result in a loss or compromise of data in the audit trail. If the DBMS stores its 
own audit records (perhaps in the form of database tables to ease subsequent analysis), the DBMS 
TCB will have to directly provide the required access controls to the audit trail. This can be done 
using protection mechanisms already built into the TCB for MAC or DAC control. For example, 
in an MLS DBMS, the audit trail could be given a special compartment not included in the clearance 
of any regular user. Then no regular user could access the audit trail through standard untrusted 
applications. Only trusted applications with the required privilege could read or write the audit trail. 
In general, it is dangerous to use standard DAC controls to protect the audit trail from modification. 
Any user or application which can run with the identity or privilege of the ``owner" of the audit 
trail could then modify the audit trail.

4.5.3 System Availability vs. Audit Collection

Audit data can be indirectly deleted if the AIS is allowed to run while the storage media available 
for the audit trail is full. Either ``old" audit records will be overwritten and lost or additional audit 
records cannot be written. The AIS will need to provide mechanisms to support the DBSSO in 
balancing the requirements for audit and system availability. This should include early warnings 
when space limitations are in danger of being reached, and the ability to archive older audit records 
while the system continues to capture new records. In fact, the TCSEC has been interpreted to 
ensure that audit data is not inadvertently lost due to the lack of available storage media [Interp 95]. 
Interpretation I-0005 was effective as of 1993-10-20 and applies to classes C2, B1, B2, B3, and A1:

The following interprets the requirement that ``The TCB shall be able to create, maintain and protect 
from modification or unauthorized access or destruction an audit trail of accesses to the objects it 
protects."

When the TCB becomes unable to collect audit data, it shall give a clear indication of this condition 
and take a pre-specified action. Tide system implementation may allow an administrator to choose 
from a range of actions. One of the actions that may be chosen by the administrator (or, if no 
choice is possible, the only action) shall be that the system cease performing auditable events 
when the TCB is unable to collect audit data. Choosing an audit overflow action shall be considered 
a security-relevant administrator event for the purpose of auditing. The TFM shall fully describe 
the administrator's options.

To the extent the OS audit trail is used to hold DBMS audit records, the OS will provide the required 
mechanisms. It should be noted however, that the space limitations are likely to be reached more 
frequently with DBMS auditing because of the large quantity of data which will be captured when 
strong auditing is enabled. When audit data is captured in DBMS tables, the audit trail may be 
competing for space with user data. In this case, the DBSSO will need to set space limitations and 
keep track of space utilization to guarantee that there is sufficient space available for the audit data.

SECTION 5

AUDIT TRAIL ANALYSIS

The goal of an audit mechanism is to provide authorized system personnel with a means to regularly 
review a documented history of selected descriptions of activity on the system. If a system violation 
should occur, this documented history will log and permit reconstruction of the events leading up 
to and including this violation. The documented history also permits surveillance of users' activity. 
This may provide notice of successful or unsuccessful attempts to violate system security so that 
the unauthorized activity may be acted upon in advance of a potential later successful violation. 
The data must be easy to understand, easily retrievable, and easily analyzed. In addition, the tools 
for analysis should be both simple to use and integrated into the ordinary capabilities of the AIS.

5.1 REQUIREMENTS

In addition to the actual recording of all events that take place in the database, an audit trail should 
also provide high-level support for querying the audit data [Kogan 91]. The TCSEC accountability 
control objective states that an audit trail must have the capability ``for an authorized and competent 
agent to access and evaluate accountability information by a secure means, within a reasonable 
amount of time and without undue difficulty" [DoD 85]. However, the TCSEC and TDI leave open 
the amount of audit trail processing required of an AIS (selective auditing is sufficient).

The increased sophistication of a DBMS is intended, in part, to provide the user with a greater 
degree of flexibility in posing a query. But this increased flexibility may open the system to additional 
security threats that can only be handled by auditing. This situation is particularly true for those 
DBMSs targeted at Class B3 or A1 which require audit mechanisms to be able to monitor the audit 
trail for imminent violations [DoD 85]. Aspects of this requirement have been interpreted.

Interpretation I-0084 was effective as of 1994-07-12 and applies to classes B3 and A1:

The following interprets the requirement that ``...and if the occurrence or accumulation of these 
security relevant events continues, the system shall take the least disruptive action to terminate the 
event."

The action taken to terminate an imminent violation shall eliminate the capability to repeat 
the event, at least until a recurrence of the event would not indicate an imminent violation. 
The product developer shall provide a convincing argument for why the proposed action is 
the ``least disruptive" of possible actions.

Interpretation I-0172 was effective as of 1994-04-19 and applies to classes B3 and A1:

The following interprets the requirement that ``The TCB shall contain a mechanism that is able to 
monitor the occurrence or accumulation of security auditable events that may indicate an imminent 
violation of security policy. This mechanism shall be able to immediately notify the security 
administrator when thresholds are exceeded..."

Audit of imminent violations is required only for actions that may lead to an actual violation 
(i.e., multiple failed login attempts, excessive use of identified auditable covert channels). The 
threshold for notification of the security administrator may be either settable by an 
administrator or fixed by the vendor. There shall be an immediate notification mechanism 
included with the product (e.g., a message to an identified terminal, a red light as part of the 
hardware), and the TFM shall describe how the security administrator can monitor this 
mechanism.

Ideally, a DBMS audit mechanism would have the ability to detect, deter, and alert the DBSSO of 
misuse patterns. However, automated misuse monitoring requires greater sophistication than is 
traditionally provided by a DBMS audit mechanism. The TDI adds that ``if the total audit 
requirement is met by the use of more than one audit log, a method of correlation must be available" 
[TDI 91].

5.2 AUDIT PROCESSING

Audit review may be categorized by the timeliness in which it is completed. In the standard 
mainframe environment, manual audit review was said to have occurred after the DBSSO ensured 
that the audit mechanism appeared to still be working producing a stack of printout. Audit trails 
would be stored for a designated time and kept available for more detailed review subsequent to 
the identification of a compromise by some other means. The audit trails were thus used as a 
reference for damage assessment if needed and perhaps as evidence for pursuing a conviction. With 
the advent of simple audit analysis tools, audit reduction/formatting could be batched at the end of 
the week for after-the-fact weekend review or at night for morning review. The next advance in 
terms of timeliness permitted near real-time querying against a processed audit log. True real-time 
audit review increases the chances of catching an inappropriate activity in progress. Finally, support 
of early warning suspicion quotients and logging of DBSSO comments present the increased 
possibility of identifying likely future intrusion attempts [Halme 94].

Audit processing can range in order of sophistication [Arca 94]:

1. Audit Formatting,

2. Audit Reduction,

3. Audit Querying, 

4. Static Profiling.

These audit analysis approaches are described in order of increasing sophistication.

5.2.1 Audit Formatting

Audit formatting is the straightforward formatting of logged data for manual review. The TCSEC 
has been interpreted to ensure the details of the audit record are documented [Interp 95]. 
Interpretation I-0046 was effective as of 1994-07-12 and applies to classes C2, B1, B2, B3, and A1:

The following interprets the requirement that ``The procedures for examining and maintaining the 
audit files as well as the detailed audit record structure for each type of event shall be given."

The documentation of the detailed audit record structure may describe either the raw records 
produced by the audit mechanism or the output of an audit post-processing tool as long as the 
records described contain the information specified in the audit requirement. If the output of 
the audit post-processing tool is described, the tool is considered part of the TCB.

5.2.2 Audit Reduction

Audit reduction is the simplest and most straightforward approach to developing an audit analysis 
facility which allows a DBSSO to better digest audit data. Innocuous audit data is eliminated and 
only the remaining filtered and formatted data is displayed for manual review. The innocuousness 
of audit data is determined based on a crude definition such as ignoring commands that do not 
modify certain secured data. Analysis of the remaining data is largely performed as before by manual 
review.

Lichtman and Kimmons developed an audit reduction paradigm to reduce the amount of data to be 
analyzed without degradation in the quality of the analysis [Lichtman 90]. They conclude that if 
redundant lower level events are removed in a consistent manner, the quality of the anomaly analysis 
might even improve while reducing the load on the analysis process/machine.

5.2.3 Audit Querying (Database Support)

A more flexible distillation of raw audit data, this approach supports the use of canned or on-the-
fly querying of audit data after it has been populated into a database facility. With audit querying, 
a DBSSO can quickly determine irregular subject behavior. This approach does not maintain user 
or system profiles based on historical data, but may be manually configured to check activity against 
hard limit figures set by the DBSSO. Examples of audit querying include the models developed by 
Jajodia and Oracle which are described as follows.

Jajodia et al., have developed a model for databases that imposes a uniform logical structure upon 
the past, present, and future data, resulting in zero-information loss [Jajodia 89, 90; Kogan 91]. It 
provides facilities for both recording the history of updates and queries as well as querying this 
history. The goal of the model is to provide a convenient mechanism for both recording and querying 
accesses to a database in order to fully reconstruct the entire database activity.

The Oracle audit trail can optionally be stored in DBMS tables [Oracle 94a]. To read audit trail 
data, suitably privileged users can select from predefined database views of the audit trail stored in 
the database. Similarly, users can employ standard SQL or ordinary end user query tools to 
manipulate views of the audit trail, perform a variety of analysis queries, and produce reports which 
may be stored for later use.

5.2.4 Manually Trained Audit Analysis Tools (static profiling)

A more useful tool performs statistical analyses isolating obvious deviations from earlier learned 
thresholds for normal activity (e.g., flagging a user suddenly issuing a barrage of commands at a 
high rate per second who previously had been described to the tool as having an average command 
rate of one per minute). The DBSSO now needs to look only at a much reduced statistically deviant 
subset of the audit trail. User norms would be reevaluated only on some limited amount of ``training" 
data and only when directed by a human during a learning phase. The evaluated DBMSs have not 
included static profiling tools.

5.3 INTRUSION DETECTION

Intrusion detection is one anti-intrusion method that is very dependent upon the quality and quantity 
of the audit data [Halme 95]. In general, raw audit data currently provides minimal real-time or 
near real-time benefit because the quantity and complexity of the data prohibits meaningful manual 
interpretation. Sophisticated intrusions and insider abuse may not even be discernible by single 
incriminating events and would escape even concentrated manual analysis. Typically, audit trails 
have been used far after the fact when an intrusion is suspected due to other reasons (e.g., a user 
reports a file has been maliciously modified, or a system operator happens to notice unusual modem 
activity). Only then are the audit trails carefully examined to assess damage and accumulate legal 
evidence. While not required by the TCSEC or the TDI, only with the aid of automated analysis 
tools would a DBSSO realistically be able to effectively detect a pattern of evidence identifying 
undesirable activity.

In fact, one of the key problems in using audit data to detect intrusions is that tremendous amounts 
of audit data must be collected and processed. The database audit tables may be flush with data 
which is irrelevant or may simply lack the data which would be useful and/or necessary. Even if 
the necessary data is successfully captured, it may be spread over time and across audit records, 
making it necessary to grasp the meaning of interrelationships between audited events. There must 
be a method of eliminating superfluous or misleading data to prevent excessive record keeping at 
the same time as retaining the essential data necessary as evidence in possible court cases [Hamilton 
92]. This will determine clues such as whether the intruder knew what he was looking for. Intrusion 
countermeasures providing autonomous reaction to audited activity can react without a manual 
reviewer and at machine speeds against automated attacks. However, false alarms could be an 
inconvenience.

5.4 CORRELATION OF AUDIT TRAILS

It is important to collect and correlate audit data from a number of different abstractions to permit 
meaningful audit analysis [Hamilton 92]. This is particularly applicable if access mediation is 
performed by multiple mechanisms at different levels of abstraction [Schaefer 89b]. Since it can 
be difficult to trace transactions from events occurring at different layers [Schaen 91], the TDI 
requires that the audit trail generated by the DBMS include sufficient data to correlate DBMS events 
with OS events [TDI 85]. This includes ensuring that the clock times recorded in the audit trail are 
synchronized as well as ensuring that DBMS events can be associated with the corresponding OS 
user.

Audit analysis in a multiple TCB configuration can potentially be performed by the DBMS or by 
the OS. Since audit records for some database audit events (such as STARTUP and SHUTDOWN) 
must always be directed to the OS, correlation will have to be done between the two audit trails to 
produce a complete picture of a user's activity. The OS audit reduction facilities can be used for 
analysis of database audit records written to the OS audit trail. These facilities may have limited 
utility for examination of database records depending on the interface provided by the OS for audit 
record insertion by applications. However, the evaluation community has determined that manual 
review of the audit trails being correlated meets the intent of the TDI interpretation. Product vendors 
need to consider what data items (such as username and time of event) will be used for correlation 
and document this in the TFM. Alternatively, the DBMS can load the OS audit trail into a table. 
Once in a database, the OS audit records and the database audit records can be joined by use of a 
common identifier (e.g., OS username) using normal SQL processing [Oracle 94b].

At issue is the correlation of audit trails from various sources. An analysis tool may have a very 
hard time if the audit trail content from one system is radically different from another because the 
two systems are so different (e.g., if you compare the type of data audited by UNIX vs. what is 
audited by a relational DBMS vs. a network or object model DBMS).

5.5 DETECTION OF INFERENCE AND AGGREGATION

To detect inference and aggregation attacks (which is not a TCSEC or TDI requirement), it may be 
necessary to perform pattern recognition on a history of queries submitted by multiple users over 
multiple sessions [Schaefer 89b]. To detect such attacks, an audit subsystem capable of addressing 
this objective might need to include in the audit trail the raw text of user queries, compiled parse 
trees/execution plans, mediation decisions, and even retrieved data. The tools required to analyze 
such data would likely include an expert system and deductive inference engine capable of 
supporting complex pattern matching searches and analysis of the audit trail. The time required to 
accomplish this analysis could seriously impact performance if any sort of real time detection was 
desired. Even off-line analysis could be painfully slow [Hosmer 94].

5.6 DETECTING EXPLOITATION OF COVERT CHANNELS

The TCSEC requires that Class B2 and above systems audit all operations that may exercise covert 
storage channels [DoD 85]. Schaefer et al., suggest that to detect exploitation of covert storage 
channels, it may be necessary to audit hidden operations on objects internal to the DBMS [Schaefer 
89b]. For example, in some DBMS architectures, it may be possible to manipulate the resource 
locks used to implement mutual exclusion for covert signaling. It is an inherent property of resource 
locks that their use may introduce covert channels into a system. This is particularly true in a 
distributed database. Two-phase commit protocols or other more complex synchronization and 
recovery protocols used in these configurations may have access delays that can be detected with 
a large number of locking events that can be manipulated. This suggests that an audit subsystem 
may need to record and correlate events from a much lower level of system abstraction than those 
directly available to a user in order to be able to detect exploitation of covert channels.

Covert channels can even be of interest to Class B1 DBMSs given the potential bandwidth of covert 
channels in an integrity enforcing MLS DBMS. Trusted Oracle provides an audit option that can 
be used for monitoring potential signaling channels [Oracle 94b]. This is the EXISTS audit option, 
which audits all SQL statements that return an error because the specified object, or a field in a 
tuple with an entity integrity constraint, or a value in the object limited by an integrity constraint, 
already exists.

SECTION 6

ARCHITECTURE

We have noted previously that many aspects of auditing in a DBMS are closely tied to the architecture 
of the DBMS. In particular, the architecture affects the assurance that one can place in the audit 
trail, and the volume and granularity of the audit data collected. To demonstrate this point, this 
section describes typical MLS DBMS architectures and notes the impact of each architecture on 
auditing. While a brief summary of each architecture is given, readers are assumed to be familiar 
with these architectures. For more details on the various architectures, the readers should refer to 
the appropriate literature.

6.1 INTEGRITY-LOCK

The Integrity-Lock architecture was one of the DBMS architectures considered in the 1982 Air 
Force Summer Study on Multilevel Data Management Security [Air Force 83]. The Integrity-Lock 
architecture was one of the approaches considered appropriate for achieving some form of multilevel 
security in the near term (five years or less). Currently, only one vendor, Atlantic Research 
Corporation, has developed a product based on this architecture [Knode 89]. For more data on the 
Integrity-Lock architecture, see [Graubart 84a, 84b].

6.1.1 Architectural Summary

The basic Integrity-Lock architecture consists of three components as depicted in Figure 6.1: an 
untrusted front-end process, an untrusted back-end process, and a trusted filter. The trusted filter is 
used to mediate data and queries between the untrusted front end and the untrusted back end. Upon 
data insertion, the filter associates a label and a cryptographic checksum with the data. The data, 
label, and checksum are then passed to the untrusted back end, which inserts all of the data into the 
database. Because the data is stored in the database in unencrypted form, the untrusted back end 
can examine the data as it would any other data. When a query is issued by the user, the back end 
performs logical qualification DBMS functions on the data to locate and retrieve those records that 
satisfy the query. The retrieved data is then passed through the filter. The filter performs two checks. 
First, it determines whether the label associated with the retrieved data is dominated by the security 
level of the user. If it is not, then the data is not returned to the user. Next, the filter verifies the 
validity of the checksum, and a correct checksum indicates that neither the data nor the label have 
been altered. If both of these checks are satisfied, then the data is passed to an untrusted front-end 
process that is running at the same level as the user. This process then performs any necessary 
formatting before passing the data to the user.

In some variations of the Integrity-Lock architecture, there is a fourth component-an untrusted 
parser that runs at the same security level as the user [Graubart 84b]. The parser is responsible for 
parsing the user query and generating an appropriate parse stream which it provides to the untrusted 
front and back ends. In those systems where the parser is not explicitly called out, its function is 
handled by the untrusted front end.



Figure 6.1: Integrity Lock Architecture

Schaefer pointed out in the 1979 Air Force Summer Study at Draper Labs that the Integrity-Lock 
architecture possesses a major security flaw; the untrusted DBMS has complete access to all of the 
data in the database [DeWolfe 79]. Therefore, the DBMS could pass back unclassified information 
to a user, but organize it in such a manner that it was actually signaling back classified information 
(for example, the first letter of each tuple returned could spell out some classified information). 
While there are ways to limit this channel, it is not possible to close this channel. This channel can 
be exploited by a Trojan horse in the DBMS process and some means by which a user could signal 
this Trojan horse. In addition, the user may be able to pose a query in which the logical qualification 
will be based in part on classified records in the database and as a result yield a set of releasable 
records which depends on classified data in the database.

Despite the security flaw already mentioned, there is some appeal to the Integrity-Lock architecture. 
In particular, it can be constructed out of existing DBMSs, and little if any change to the DBMS 
code is required. It may be useful in environments with a sufficiently benign threat environment or 
where only a small number of very large records is ever retrieved.

6.1.2 Auditing Issues in the Integrity-Lock Architecture

Because the back end of the Integrity-Lock is not part of the TCB, it cannot be trusted to provide 
correct audit data [Schaefer 89b]. The only component of the architecture that can be trusted is the 
trusted filter. Thus, at a minimum, the filter should be able to audit all of the data it passes to the 
untrusted front-end process.

Given the nature of the threats to which the Integrity-Lock is subject, additional auditing may be 
required. All of the data passed to the filter from the back end should also be auditable. This 
information may help to detect indications of when an attempt to violate security is occurring. It is 
advisable that the query and the parse stream generated as a result of the query should also be 
auditable.  The inclusion of the query and the parse, while not helpful in real time, might be of use 
in retrospective analysis of the audit log. Well-designed audit reduction tools could check the 
consistency between the query and the parse stream. Any inconsistencies might indicate a possible 
Trojan horse in the parser attempting to signal the back end.

Capturing all of this information only provides hints of the actual actions of the back end. Because 
the back end is untrusted, it is not possible to reliably detect malicious activity of the back end. Not 
only is it not possible to audit malicious actions of commission by the back end, but it is not possible 
to audit malicious actions of omission. For example, assume that a tuple needs to be upgraded. The 
actual upgrade occurs at the filter. It is the responsibility of the back end to insert the upgraded data 
into the database replacing the original tuple. Because the back end is not trusted, the action cannot 
be assured to have taken place, nor can any audit of the action be trusted.

Note that if any DAC or database integrity capabilities are provided, this will be done in the back 
end also. Thus, there is no way to audit whether these actions were conducted.

In terms of volume, the amount of audit data generated is less than in other DBMS architectures. 
The back end only passes tuples to the front-end that satisfy the logical qualification clauses. Except 
for queries of the nature ``Select * ..." the number of tuples that are likely to be passed to the filter 
is likely to be reasonable in number, and so will be the volume of audit data generated.

6.2 DISTRIBUTED DBMS ARCHITECTURE

Like the Integrity-Lock architecture, the Distributed DBMS architecture was also discussed at the 
Air Force Summer Study on Multilevel Data Management Security [Air Force 83]. Prototypes based 
on the architecture have been developed [O'Connor 89; Kang 94].

6.2.1 Architectural Summary

In the architecture depicted in Figure 6.2 there is a single trusted front-end node [Kang 95]. This 
node interfaces with multiple back-end nodes, each of which is untrusted. It should be noted that 
the issue discussed here would be the same whether the nodes were actually implemented on 
different machines or on a single machine using an OS TCB to control access to the nodes. The 
back-end nodes each run at a different security level. The data in the lower level nodes is replicated 
in the higher level nodes. Thus, the Unclassified node just has Unclassified data, the Confidential 
node has Confidential and Unclassified data, the Secret node has Secret data, Confidential, and 
Unclassified data, and so on.

When a user issues a query, the trusted front-end node determines the level of the user and issues 
the query to a node at the corresponding level. The back-end node performs all of the necessary 
DBMS functions (e.g., selection, project). The extracted data is then passed back to the front-end 
node, which labels the data (reflecting the level of the node from which it was extracted) and passes 
it to the user. In the case of an update, the front-end node is responsible for ensuring that the update 
is replicated up to the higher level back-end nodes.

 

Figure 6.2: Secure Distributed DBMS Architecture

The advantage of this architecture is that, like the Integrity-Lock architecture, it can be built out of 
untrusted DBMSs. Unlike the Integrity-Lock architecture, it does not suffer from a major security 
flaw. The one significant weakness of this architecture is that it requires one node per security level. 
In an environment with a large number of levels and/or compartments, this can be a major problem 
because of the large number of single level databases required.

6.22 Auditing Issues in the Distributed DBMS Architecture

As with the Integrity-Lock Architecture, in the distributed DBMS (DDBMS) architecture the back 
ends are also untrusted. This means that any auditing provided by the back ends would be suspect 
[Schaefer 89]. Only the front-end node is capable of providing a trustworthy audit trail. produced 
by the front end consist primarily of the data returned by the selected back-end machine. As with 
the Integrity-Lock architecture, this information is only partially. To make the data more useful, 
this audit mechanism in the front end should be capable of capturing the user query.

In the pure sense of this architecture with totally back ends, no attempted DAC or integrity policy 
violations could be audited because these policies, if enforced, would be handled entirely at the 
back end and any auditing of these policies, like any enforcement of the policies, would be 
untrustworthy. Thus, only MAC-related objects (storage) and MAC accesses and policy violations 
can be audited under this architecture. If MAC enforcement is achieved with the DDBMS 
architecture, but the back ends are trusted to enforce DAC or integrity policies, attempted violations 
of these policies could be audited with whatever degree of assurance has been established for the 
back ends. 

The MAC objects audited would essentially be the data returned by the back ends (the label 
associated with this data would be the label of the back-end machine). A MAC access would be 
any access or requested access to the back-end machine. Given the nature of this architecture, the 
attempted MAC violations that could occur are queries targeting a relation that only exists in higher 
level back-end machines (see example in Figure 6.3).

Of course, the attempted violation would be prevented from actually taking place because the front-
end does not permit any data to be returned from a back-end unless the level of the back-end is 
dominated by the level of the subject making the query. However, in order to detect and audit such 
an attempted access, the front-end would need access to the names of relations, attributes, and data 
structures that exist at different levels. Since they are maintained by untrusted DBMSs, the front-
end cannot know this data reliably. Alternatively, the audit mechanism could simply record all 
instances where the queried back-end DBMS indicated the referenced structure did not exist. 
However, the reliability of this data is still suspect since it is generated by an untrusted DBMS.

The nature of this architecture also precludes covert channels if the nodes are in fact separate 
machines. If they are running on a single machine under the control of a TCB, they can potentially 
covert channels permitted by the OS TCB. However, they do not introduce additional covert 
channels. As such, the requirement to audit covert channels is not applicable.

Depending upon the specifics of the MAC policy, there is one aspect of MAC policy that might not 
be auditable under this architecture. If the MAC policy includes the ability to regrade data, then 
this action cannot be audited under this architecture. This is because of the unique way in which 
regrades are handled. For example, to upgrade a tuple under this architecture requires the deletion 
of the tuple from the lower classified machines in which it exists. This action upgrades the data 
since the lower level data is replicated in the higher level machines. Since the back-end machines 
are all untrusted, it is not possible to audit the deletion of the tuples (even worse from a MAC policy 
perspective, one cannot even ensure that the deletion takes place, thus precluding trustworthy 
enforcement of any upgrade policy)

Request from unclassified user: Select * from Weapons

Figure 6.3: Example of Unauthorized Access Request

Thus far, the DDBMS architecture has been discussed with the assumption that the back ends are 
untrusted, since this is the basic architecture. But in recent years, there have been some proposed 
variations to this architecture in which the back ends are trusted, but not to the same degree as the 
front end. For example, in some cases the back ends are C2 nodes with C2 DBMSs, and the front 
end is B1 or higher. This variation in the architecture provides for additional auditing. The actions 
of the back ends with regard to DAC and integrity policies then in force can now be audited by the 
back ends. In theory, these audit trails can now be combined with the audit trail generated by the 
central node to give a more complete audit picture. In effect, the back ends would audit the non-
MAC policies and the front end would audit the MAC policy.

The degree of assurance one can place in the accuracy of the audit records written by the back ends 
is limited by the lower assurance given the back-end DBMSs. There are two perspectives of this 
question. The first is that C2 assurance is sufficient for the mechanism controlling and auditing the 
functionality required in C2 systems. That is, C2 assurance would suffice for audit of DAC. Under 
this perspective, there is no problem with combining the two audit trails. However, a C2 system 
and its associated audit mechanisms are more vulnerable to compromise than a higher assurance 
system. As such, the audit trails generated by the lower assurance back ends cannot be trusted to 
the same degree as the higher level assurance front-end node. Hence, some would not consider 
audit-data gathered by a mechanism of lower assurance to be acceptable as part of a system with 
higher assurance requirements. Essentially, this is the question of balanced versus uniform assurance 
but applied to auditing. There is not a general consensus on this issue.

At first it might appear that the auditing capabilities of the C2 devices might help alleviate some of 
the MAC auditing concerns raised earlier, in particular the problem of auditing regrading of objects. 
But that is not true. While the C2 back ends may be trusted to delete database objects, the level of 
trust in the back ends is less than in the front end. As such, the lower assurance back-end devices 
are being used to support a higher assurance MAC policy and the auditing of that policy. Such an 
arrangement is suspect. In addition, the DAC objects in most DBMSs are relations, views, and 
attributes. While it is not unheard of for a DAC object to include tuples, it is not common either. 
Thus, there is a possibility that what constitutes a MAC object (e.g., tuples) is not an object from 
the perspective of the back end but rather, data within an object. If that is the case, then the back 
end may be unable to audit the insertion or deletion of the tuples.

6.3 TRUSTED SUBJECT

The trusted subject architecture, also sometimes called a dual kernel-based architecture [Graubart 
89], was one of the later MLS DBMS architectures to be developed. It was not part of the Air Force 
Summer Study. Rather, it grew out of the work of various vendor efforts and prototype efforts. For 
detailed descriptions of some of the trusted subject architectures, see [Winkler-Parenty 90].

6.3.1 Architectural Summary

This approach has the DBMS perform labeling and also access mediation for objects under its 
control. MAC controls on DBMS objects are enforced by the MLS DBMS. The architecture is 
referred to as a trusted subject approach because the DBMS has the privilege to override the MAC 
policy enforced by the underlying OS TCB. It must be trusted not to misuse that privilege. Hence, 
it is considered a trusted subject of the underlying OS TCB. Under the trusted subject approach, a 
single DBMS has access to all of the data in the database. The architecture depends upon the 
underlying trusted OS to protect and isolate the DBMS and the associated database(s). This is 
generally handled by having the DBMS and the database maintained at system high, sometimes 
along with a special compartment.

The advantage of this architecture are that it can provide good security, and its performance and 
data storage overhead are relatively independent of the number of security levels involved. Its 
disadvantage is that the DBMS code that performs access mediation must be trusted, and often such 
code is both large and complex. Thus, a significant amount of trusted code may be required under 
this approach [Hinke 89]. Despite this disadvantage, this architecture is the single most popular 
approach. Some variation of this approach is employed by Oracle, INFORMIX, Sybase and Ingres 
(Computer Association) in their MLS DBMS products.

Figure 6.4: Trusted Subject Architecture

6.3.2 Auditing Issues in a Trusted Subject Architecture

As noted above, in this architecture, the MLS DBMS handles all accesses to the database, and so 
it is different than the other architectures discussed so far where untrusted code performed the 
database accesses. It is the first true MLS DBMS that has been discussed. But there are multiple 
variations possible in the trusted subject architecture. One aspect contributing to the variation is 
how much of the DBMS should be included in the TCB, in particular, the non-security-relevant 
functionality. Another aspect pertains to the ordering of certain DBMS and security functionality. 
Both of these issues will be examined as they pertain to auditing.

Let us return to a question raised in Section 3.3: what accesses need to be audited in a DBMS and, 
in particular, in the trusted subject architecture? One possibility is to audit only the data returned 
to the user. If this is done, the ability to audit unauthorized access attempts will be lost. Alternatively, 
the data could be audited as it is accessed by the DBMS. But this action could result in an audit of 
every access that the DBMS performs while sequentially working through a relation, trying to 
determine which tuples satisfy the logical qualification clause of a query.

Ideally, there are three points in a trusted subject MLS DBMS where auditing might be performed. 
The first is where the data is returned from the TCB to the user. This is a logical point to audit 
because it is consistent with the basic definition of auditing in the TCSEC. That is, it is consistent 
with the data that is passed into the user's address space. But auditing at this location does not 
provide insight into any unauthorized access attempts performed by the user.

These attempted access violations can only be detected earlier, as the data is retrieved by the DBMS. 
Therefore, the second point is when the DBMS performs the FETCH operation from the database. 
As noted earlier, the audit of every access that the DBMS performs while sequentially working 
through a relation trying to determine which tuples satisfy the logical qualification clause of a query 
is undesirable. How then should auditing of database accesses be handled? Auditing at this point 
is desirable because any data that passed the logical qualification process would presumably be data 
that the user was attempting to access, and thus data that was rejected for security reasons and may 
be suspect. In some queries, a tremendous amount of data will be rejected for security reasons (an 
example is a query Select * from EMPLOYEES). In such a case, the rejected data may not be 
indicative of an intended security violation, but more indicative of the user's ignorance about the 
existence of the data. However, m general, rejected data can indicate an attempted security violation. 
The only way to determine if the violations were intended is to audit the user's query and correlate 
tuples rejected for security reasons with the query that was issued. This brings us to the third point 
in a trusted subject DBMS where auditing is required - at the beginning to capture the user query. 
The reasoning behind including the query in the audit trail was discussed in previous sections.

Thus, it is desirable to be able to audit data returned to the user, the query itself, and the data that 
passes logical qualification but fails security filtering. It should be noted that if the parser is not 
trusted, there is no assurance that the query which is audited is the one which is actually executed. 
Also, auditing data which passes the logical qualification but fails security filtering only makes 
sense if the logical qualification is performed before the security filtering as depicted in Figure 6.5.

Unfortunately, while this approach may be desirable from a security audit perspective, it is less than 
ideal from a security architecture perspective. Let us first look at the query parser. Making the parser 
trusted increases the size and complexity of the TCB. At lower levels of assurance, this is not an 
issue. But at Class B2 there is a modularity requirement imposed upon the security architecture. At 
Class B3 and higher, there is a minimization requirement imposed upon the TCB that effectively 
mandates the exclusion of non-security-relevant code from the TCB. Traditional or legacy parsers 
are large, complex, and generally ill-structured entities, the bulk of whose functions are not security 
relevant. Thus, the incorporation of such parsers into the TCB for the purpose of addressing the 
auditing security-concern described above would likely result in a system that was unable to satisfy 
the TCSEC architectural requirements.

A similar issue arises in regards to the ordering of the logical qualification processing and security 
filtering. The logical qualification processing is performed by a large and fairly complex set of code. 
In addition, logical qualification processing is generally not considered security relevant. As such, 
the logical qualification function should not be included in the TCB, so that a well-modularized 
and minimized TCB is provided. Providing such a minimum TCB, while still maintaining the basic 
concepts of the trusted subject architecture, requires that the security filtering precede the logical 
qualification processing as depicted in Figure 6.6. This is necessary to ensure that only trusted code 
handles the retrieved data prior to security filtering. By reversing the order of the security filtering 
and logical qualification processing functions, the ability to detect unknown access attempts is 
eliminated.



Figure 6.5: Trusted Subject Architecture Optimized for Auditing

Given current technology, the higher level audit requirements (monitoring the accumulation of 
security auditable events) and the higher level architecture requirements (modularity and 
minimization of the TCB) come into conflict regarding the inclusion of the parser and the 
qualification processing into the TCB. At this point, there does not seem to be a good solution to 
this conflict. The solution probably lies with obtaining a better understanding of what is meant by 
minimization in a DBMS, and with the development of a restructured parser qualification processor 
that would satisfy the B2 and higher architectural requirements, while still providing the necessary 
functionality.

Figure 6.6: Trusted Subject Architecture Optimized for Modularity and Minimization

6.4 NO MAC FRIVILEGES ARCHITECTURE

The No MAC Privileges (NMP) architecture was discussed at the Air Force Summer Study on 
Multilevel Data Management Security [Air Force 83]. The SeaView research program has 
developed a prototype system based on this architecture [Hsieh 93]. Trusted Oracle can be 
configured to run in either this architecture (which they call OS MAC mode) or the trusted subject 
architecture (which they call DBMS MAC mode) [Oracle 94b]

6.4.1 Architectural Summary

The NMP architecture relies on a decomposition of the multilevel database into multiple single 
level relations. The OS TCB provides MAC protection by controlling access to the OS objects in 
which the single level relations are stored. Each interfaces with an instance of the DBMS running 
at the user's working level. The OS MAC enforcement guarantees that the DBMS instance at a 
given level can only read those OS objects at levels dominated by the level of the DBMS instance. 
The DBMS instance can only write to OS objects at the same level as the DBMS instance. The 
DBMS is not given the privilege to override the OS MAC controls. Hence, it is not a trusted subject 
with respect to MAC. Figure 6.7 illustrates the NMP architecture. The description of the DBMS as 
untrusted refers to the fact that it is not relied upon to enforce the MAC policy. DAC enforcement 
is done by the DBMS. Hence, the DBMS is trusted to properly enforce DAC controls.

Figure 6.7: NMP Architecture

The NMP architecture has the advantage that the amount of code which is trusted to do MAC 
enforcement is significantly less than in the trusted subject architecture. The major disadvantages 
are the performance and storage implications of decomposing the multilevel database into multiple 
OS objects. This can represent a heavy penalty if there are many levels and compartments of data.

6.4.2 Auditing Issues in a NMP Architecture

The issues associated with auditing in a NMP architecture are similar to those for the DDBMS 
Architecture. The MAC enforcement is done by the OS TCB at the granularity of OS objects. Since 
there is no additional MAC enforcement done by the DBMS, there is nothing meaningful which it 
can add with respect to auditing for MAC. A DBMS instance at a particular level cannot observe 
database objects at any levels except those lower than or equal to the level of the DBMS instance. 
DBMS objects at higher or incomparable levels are stored in OS objects which cannot be accessed 
by the DBMS instance. Hence, the DBMS instance can neither be the instrument for revealing data 
to the user contrary to the MAC policy nor can it detect any attempts to violate that policy. It is 
inherent in the nature of this architecture that the security filtering is performed (by the OS TCB) 
before logical qualification takes place. Access control decisions are specifically required to be 
audited by the TDI [TDI 91] and bring up some difficult challenges to effective auditing.

On the other hand, the DBMS is trusted to enforce the DAC policy and it can therefore audit actions 
relevant to DAC. Indeed, one approach to implementing a NMP architecture is to use an existing 
C2 DBMS to provide the DAC enforcement and associated auditing. The fact that one only has C2 
level assurance in the correctness of the DAC enforcement and auditing mechanism raises the same 
issues as discussed in the DDBMS section above.

A NMP architecture also introduces several issues with audit trail correlation that were discussed 
in Section 5.4. In this configuration, one database audit trail exists at each level. While having 
multiple audit trails is effective in ensuring that lower level users cannot detect higher level activity, 
it can make tracing a pattern of suspicious behavior across the entire system difficult. In order to 
see a complete picture of the audited activity, the DBSSO can create a view of all lower level database 
audit trails in the highest level database. To determine the label of an audit record within this view, 
the user can select the Row_Label column from that tuple. Because setting the audit options is a 
write operation to the data dictionary, a user can set audit options only in the current database. 
Therefore, the TFM needs to point out the importance of having identical audit options set across 
all levels of the database [Oracle 94b].

6.5 TCB SUBSETS

A TCB consists of one or more sub-elements that together enforce a security policy over an AIS. 
Complex AISs distribute policy enforcement to various sub-elements. While determining the trust 
characteristics of a complex AIS on the basis of a collection of subparts is not well understood, 
there are approaches for arguing about composition of AISs.

The approach used in the TDI is to view the AIS as being composed of hierarchically-ordered 
systems. There is a ``privilege" hierarchy characterized by dependency. The construct developed 
for dealing with layered systems is TCB subsets. If a TCB subset can be shown to be constrained 
and unprivileged relative to the more primitive TCB subset from which it obtains resources, then 
the scope of the assessment can be limited. With this concept, the TDI then defines the conditions 
under which the evaluation of a system can proceed with the maximum degree of independence of 
the evaluation of its individual TCB subsets. This type of evaluation is called evaluation by parts 
and the six required conditions for a system to be suitable for evaluation by parts are:

 The candidate TCB subsets are identified;

 The system policy is allocated to the candidate TCB subsets;

 Each candidate TCB subset includes all the trusted subjects with respect to its policies;

 The TCB subset structure is explicitly described;

 Each TCB subset occupies distinct subset-domains; and

 The more primitive TCB subsets provide support for the Reference Validation 
 Mechanism arguments for less primitive TCB subsets.

The Trusted Subject Architecture cannot be decomposed into TCB subsets meeting these conditions 
because the DBMS is trusted with respect to the OS MAC policy. The NMP architecture on the 
other hand can be decomposed into an OS TCB subset and a DBMS TCB subset suitable for 
evaluation by parts.

For systems suitable for evaluation by parts, the TDI provides interpretation of TCSEC audit 
requirements. The interpretations require that the entire TCB must meet the TCSEC audit 
requirement through the cooperative action of the TCB subsets. TCB subsets may maintain their 
own audit logs or use an audit interface provided by a more primitive TCB subset. If a TCB subset 
uses different user identifications than a more primitive TCB subset, there must be a means to 
associate audit records generated by the actions of a given individual. This association can be done 
either when the records are generated or later. Any TCB subset in which events may occur that 
require notification of the DBSSO shall be able to:

1. Detect the events,

2. Initiate the recording of the audit trail entry, and

3. initiate the notification of the DBSSO.

The ability to terminate the recording and notification described in 2 and 3 above can be provided 
either in the TCB within which they occur, or in the TCB subset(s) where the event was initiated.

The TDI also points out that the monitoring and notification requirements may require cooperation 
among multiple TCB subsets or multiple instantiations of the same TCB subset. For example, 
detection of the accumulation of events for a single user may require collecting events detected in 
different TCB subsets.

6.6 SUMMARY

As can be seen from the above discussion of MLS DBMS architectures, the choice of a security 
architecture has a definite impact on the ability of the system to perform auditing. It is also apparent 
that there is a potential conflict between the requirements of a security architecture and those of 
security auditing. Further thought needs to be given to ways to address the inconsistency between 
these two requirements. Finally, it should be apparent from the discussion of the Integrity-Lock 
architecture that those architectures that are inherently flawed cannot correct or compensate for the 
flaws by auditing.

SECTION 7

DATA RECORDING FLEXIBILITY

This section presents a recommendation that has not been discussed in the literature previously nor 
is it required by the TCSEC or TDI but is a relevant contribution to the DBMS auditing problem. 
No current DBMSs provide this level of flexibility but it could be very helpful to some users if they 
were to do so. This recommendation addresses the ability to precisely adjust the amount of data 
that is recorded for particular audit events as follows:

Just as it is important for audit events to be auditable (meaning you can turn particular events on or 
off) it would also be helpful for the data captured to be recordable (meaning that you can select 
what specific data is recorded for that event, rather than recording all data that is available related 
to a particular event). This would allow a DBSSO to precisely configure the audit mechanism to 
best meet the (typically conflicting) needs of tracking what is happening without overflowing the 
audit logs or adversely impacting system performance. Most current trusted systems record a fixed 
set of data per audit event type rather than providing the flexibility to select or prefilter what data 
is recorded for each audit event. As described in Section 3, what they do provide is the ability to 
decide whether or not an audit record is generated at all (i.e., audit events are `auditable').

For each auditable event, it would be beneficial to be able to select what data is recorded based on 
the same type of factors used to decide whether or not to audit an event in the first place, such as 
[Oracle 94a]:

 Object accessed

 User

 Operation performed

 Privileges used

 The sensitivity of the object accessed (for B1 and higher systems)

 Granularity of object accessed (e.g., table, tuple, element)

This would allow certain critical objects, certain users, certain operations, or use of certain privileges 
to be audited to a finer granularity (i.e., more data is recorded) while other less sensitive or interesting 
events would be audited at a coarser level (i.e., less data is recorded), or not at all. In fact, the ability 
to combine these factors could also be beneficial. For example, it might be useful to be able to record 
more detailed data whenever a particular set of users access a particular object, or whenever an 
access to that object occurs using a particular operation (e.g., update, or delete). The object 
granularity factor is particularly important because it can play a significant factor in the volume of 
audit data collected (e.g., is one record generated whenever a command accesses a table or is one 
record generated for every tuple accessed in the table). As described in Section 3, Trusted Oracle 
allows the DBSSO to turn auditing on or off based on these factors, but is does not allow the DBSSO 
to determine what data is recorded based on these factors. This means that if an audit record is 
generated, the contents of the record are fixed as predetermined by the developers of Oracle.

This flexibility to decide what data to record would enable the DBSSO to reduce the size of the 
audit trail that was generated but may affect the performance of the DBMS. Depending on the 
implementation of the filtering mechanism and the actual settings that are used, the DBMS could 
be faster or slower than a mechanism which does not support recordability or prefiltering. There is 
going to be some overhead involved in checking the filters associated with each event to determine 
what data to record. However, if a significant amount of data is filtered out, this could cause an 
overall speed up in the audit mechanism because it is not recording as much data, in addition to 
reducing the size of the audit trail.

SECTION 8

SUMMARY

As was described, there are a large number of issues involving auditing in secure DBMSs, many 
of which are unresolved, and are also dependent on the specifics of the architecture and 
implementation. This document explores these issues and describes known alternatives along with 
the pros and cons of each. There are, however, some specific recommendations that were presented. 
These are summarized here.

With respect to what information should be recorded, in addition to what is minimally required by 
the TCSEC, we recommended the following information be captured in the audit trail:

 Reason why each event failed, including the user's security levels or authorizations, or 
 a pointer to this data.

 The original query, prior to parsing or optimization.

 Each audit event record should be traceable back to the query which caused it.

 Each query that is part of a transaction should be traceable to the transaction.

 Whether a transaction eventually was committed or was rolled back.

This information is very helpful in understanding a user's intent, and provides a better picture of 
what has actually occurred in the database.

A number of audit storage alternatives were described. Each of these alternatives has certain benefits 
and drawbacks. To provide flexibility, a DBMS should support more than one of these choices. For 
example, providing the ability to record a DBMS specific audit trail, merging the audit data with 
that of the host OS, or forwarding it to a specific location are all reasonable choices which should 
be supported. The actual method used should then be left to the DBSSO.

One of the significant problems with auditing today is poor support for audit analysis. DBMSs have 
an advantage in that by their very nature, they can be used to support audit analysis of their own 
audit trails if the data is stored in a database. Once stored in a database, the full power of the DBMS 
can be brought to bear to search the data for whatever is desired. This capability can be a powerful 
aide to a DBSSO searching for an intrusion and it can also be advantageous to the DBMS vendor 
since they do not have to construct an audit analysis tool from scratch in order to provide an audit 
analysis capability. Both INFORMIX and Oracle have the ability to read the database audit trail 
stored in an OS file into a database and then perform searches on that data using SQL. Oracle can 
also search the audit trail that is recorded directly into an audit database.

APPENDIX

AUDIT EVENT EXAMPLE

As an example, the events audited for INFORMIX-OnLine/Secure are provided in Table A.1 
[INFORMIX 94].

Actions

Event Types

Data Collected

User

Session Startup

None

Object

creation/deletion/access

Object name, object label, object ID,

label at which object was opened

Database privilege granting/

revoking

Database name, grantor, grantee,

privilege, revoke

Table privilege granting/

revoking

Table name, grantor, grantee,

privilege, revokee

Transaction management

None

Administer

Chunk Management

dbspace number, chunk number,

mirror status

dbspace management

dbspace name, mirror status

BLOspace management

BLOspace name, mirror status

Transaction log management

 None

Read/delete audit masks

Audit mask name

Create/Update audit masks

Audit mask name, audit mask

Grant DAC privilege

Object name, object label, grantor,

grantee, privilege

Revoke DAC privilege

Object name, object label, revoker,

revokee, privilege

Access a database

Database name, label

Database label modification

Database name, old label, new label

Table access

Database name, table id, table label

Table label modification

Database name, table name, old

label, new label, owner

Use of transient process

Command line used when process

was executed

Table A1: INFORMIX-OnLine Secure Audit Event Types

                      REFERENCES

[Air Force 83]  Air Force Studies Board, Multilevel Data Management Security, National 
Research Council, National Academy Press, Washington, DC, 1983.

[Albert 92]  Albert, S., Ashby, V. A., Hicks, S. E.,  ``Reference Model for Data 
Management Security and Privacy," ACCM SIGSAC, Vol. 10, No. 2 & 3, 
Spring-Summer 1992.

[Arca 94]  Arca Systems, Inc., Survey of Available Intrusion Detection System (IDS) 
Techniques, ATR 94028, 18 November 1994.

[Audit 88]  A Guide to Understanding Audit in Trusted Systems, NCSC-TG-001, 
Version-2, National Computer Security Center, June 1988.

[Biba 77]  Biba, K. J., Integrity Considerations for Secure Computer Systems, ESD-
TR-76-372, The MITRE Corporation, Bedford, MA, 1977.

[CMADIII 95]   Report on Third Annual Workshop on Computer Misuse and Anomaly 
Detection, UC Davis, 10-12 January 1995. @ http://www.cs.purdue.edu/
homes/swlodin/cmad_report.html

[DAC 96]  National Computer Security Center, Discretionary Access Control Issues in 
High Assurance Secure Database Management Systems, NCSC Technical 
Report-005, Volume 5/5, May 1996.

[DeWolfe 79]  DeWolfe, J. B., Szulewski, P., Final Report of the 1979 Summer Study on 
Air Force Computer Security, R-1326, C. S. Draper Laboratory, Inc., 
Cambridge, MA, October 1979.

[DoD 84]  Department of Defense, Industrial Security Manual for Safeguarding 
Classified Information, DoD 5220.22-M, Washington, DC, March 1984.

[DoD 85]  Department of Defense, Department of Defense Trusted Computer System 
Evaluation Criteria, DoD 5200.28-STD, Washington, DC, December 1985.

[Entity 96]  National Computer Security Center, Entity and Referential Integrity Issues 
in Multilevel Secure Database Management Systems, NCSC Technical 
Report-005, Volume 2/5, May 1996.

[Filsinger 93]  Filsinger, J., ``Integrity and the Audit of Trusted Database Management 
Systems," Database Security, VI: Status and Prospects: Results of the Sixth 
IFIP Working Group Conference on Database Security, Vancouver, Canada 
-21 August, 1992, M. B. Thuraisingham and C. E. Landwehr editors, Elsevier 
Science Publishers, 1993.

[Gluck 93]  Gluck, F. B., ``An Open Security Architecture," Proceedings of the 16th 
National Computer Security Conference, October 1993.

[Graubart 84a]  Graubart, R. D., ``The Integrity Lock Approach to Secure Database 
Management," Proceedings of the 1984 Symposium on Security and Privacy, 
Oakland, CA, April 1984.

[Graubart 84b]  Graubart, R. D., Duffy, K. J., ``Design Overview for Retrofitting Integrity-
Lock Architecture onto a Commercial DBMS," Proceedings of the 1985 
Symposium on Security and Privacy, Oakland, CA, April 1984.

[Halme 95]  Halme, L. R., Bauer, R. K., ``AIN'T Misbehaving -- A Taxonomy of Anti-
Intrusion Techniques," Proceedings of the 19th National Information System 
Security Conference, October 1995

[Hamilton 92]  Hamilton, D., ``Application Layer Security Requirements of a Medical 
Information System," Proceedings of the 15th National Computer Security 
Conference, October 1992.

[Haigh 90]  Haigh, J. T., O'Brien, R. C., Stachour, P. D., Toups, D. L., ``The LDV 
Approach to Security," Database Security, III: Status and Prospects, ed. D. 
L. Spooner and C. Landwehr, North-Holland, Amsterdam, 1990.

[Hinke 89]  Hinke, T., et al., ``A Layered TCB Implementation versus the Hinke-Schaefer 
Approach," Database Security III, IFIP Workshop on Database Security, 
Monterey, CA, 1989.

[Hosmer 90]  Hosmer, H. H., ``Handling Security Violations Within an Integrity Lock 
DBMS," Database Security, III: Status and Prospects:, D. L. Spooner and 
C. E. Landwehr editors, Elsevier Science Publishers, 1990.

[Hosmer 94]  Hosmer, H. H., ``Security Audit Research in Relational MLS DBMS," 
Presented at the Government Workshop on the Status of Multilevel Secure 
RDBMSs, Southwest Harbor, Maine, June 1994.

[Hsieh 93]  Hsieh, D., Lunt, T., Boucher, P., The Sea View Prototype Final Report. 
Technical Report A012, Computer Science Laboratory, SRI International, 
Menlo Park, CA, Aug. 1993.

[Inference 96]  National Computer Security Center, Inference and Aggregation Issues in 
Secure Database Management Systems, NCSC Technical Report-005, 
Volume 1/5, May 1996.

[INFORMIX 94]  INFORMIX OnLine Secure Final Evaluation Report, CSC-EPL-93/004, C-
Evaluation Report No. 32/94, Library No. S-241,835, National Computer 
Security Center, 21 March 1994.

[Interp 95]  The Interpreted TCSEC Requirements, National Computer Security Center, 
Dockmaster Criteria Forum, January 12, 1995.

[Jajodia 89]  Jajodia, S., Gadia, S. K., Bhargava, G., Sibley, E., ``Audit Trail Organization 
in Relational Databases.," Proceedings 3rd IFIP WG 11.3 Working 
Conference on Database Security, September 1989.

[Jajodia 90]  Jajodia, S., ``Tough Issues: Integrity and Auditing in Multilevel Secure 
Databases," Proceedings of the 13th National Computer Security 
Conference, Washington D. C., October 1990.

[Kang 94]  Kang, M.H., Froscher, J.N., McDermott, J.P., Costich, O.L., and Peyton, R. 
``Achieving database security through data replication: the SINTRA 
prototype". Proceedings of the 17th National Computer Security 
Conference, Baltimore, MD, September 1994.

[Knode 89]  Knode, R.B., and Hunt, R.A., ``Making Databases Secure with TRUDATA 
Technology," Proceedings of the Fourth Aerospace Computer Security 
Applications Conference, December, 1989.

[Kogan 91]  Kogan, B., Jajodia, S., ``An Audit Model for Object-Oriented Databases," 
Proceedings of the 7th Annual Computer Security Applications Conference, 
1991.

[Lichtinan 90]  Lichtman, A., Kimmins, J., ``An Audit Trail Reduction Paradigm Based on 
Trusted Processes," Proceedings of the 13th National Computer Security 
Conference, October 1990.

[O'Connor 89]  O'Connor, J. P., et al., Secure Distributed Database Management System 
Architecture. RADC-TR-89-314, Volume I, December 1989.

[Oracle 94a]  Oracle Corporation, Trusted Oracle7 Technical Overview, White Paper, Part 
A14774, January 1994.

[Oracle 94b]  Oracle7 and Trusted Oracle7 Final Evaluation Report, CSC-EPL-94/004, 
C-Evaluation Report No. 07-95, Library No. S242,198, National Computer 
Security Center, 5 April 1994.

[Picciotto 87]  Picciotto, J., ``The Design of an Effective Auditing Subsystem," Proceedings 
of the IEEE Symposium on Security and Privacy, April 1987.

[Poly 96]  National Computer Security Center, Polyinstantiation Issues in Multilevel 
Secure Database Management Systems, NCSC Technical Report-005, 
Volume 3/5, May 1996.

[Schaefer 89a]  Schaefer, M., Hubbard, B., Sterne, D., Haley, T. K., McAuliffe, J. N., Wolcott, 
D., ``Auditing: A Relevant Contribution to Trusted Database Management 
Systems," Proceedings of the Fifth Annual Computer Security Applications 
Conference, Tucson, Az, 1989.

[Schaefer 89b]  Schaefer, M., Hubbard, B., Sterne, D., Haley, T. K., McAuliffe, J. N., Wolcott, 
D., Secure DBMS Auditor: Final Technical Report and Functional 
Specification, TIS Report #278, prepared for RADC by TIS under Contract 
No. F30602-87-D-0093, 28 December 1989.

[Schaefer 94]  Schaefer, M., Smith, G., Halme, L., Landoll, D., Assured DAC for Trusted 
RDBMSs Final Report, ATR-94020, Arca Systems, Columbia, MD, 
September 1994. (Portions to be reprinted in IFIP 1995)

[Schaen 91]  Schaen, S. I., McKenney, B. W., ``Network Auditing: Issues and 
Recommendations," Proceedings of the 7th Annual Computer Security 
Applications Conference, 1991.

[Sibert 88]  Sibert, W. O., ``Auditing in a Distributed System: SunOS MLS Audit Trails," 
Proceedings of the 11th National Computer Security Conference, October 
1988.

[Stang 93]  Stang, D., Moon, S., Network Security Secrets, IDG Books, 1993.

[Schaefer 94]  Schaefer, M., Smith, G., Halme, L., Landoll, D., Assured DAC for Trusted 
RDBMSs Final Report, ATR-94020, Arca Systems, Columbia, MD, 
September 1994. (Portions to be reprinted in IFIP 1995)

[Schaen 91]  Schaen, S. I., McKenney, B. W., ``Network Auditing: Issues and 
Recommendations," Proceedings of the 7th Annual Computer Security 
Applications Conference, 1991.

[Sibert 88]  Sibert, W. O., ``Auditing in a Distributed System: SunOS MLS Audit Trails," 
Proceedings of the 11th National Computer Security Conference, October 
1988.

[Stang 93]  Stang, D., Moon, S., Network Security Secrets, IDG Books, 1993. [TDI 91]  
Trusted Database Management System Interpretation of the Trusted 
Computer System Evaluation Criteria, NCSC-TG-021, National Computer 
Security Center, April 1991.

[TDI 91]  Trusted Database Management System Interpretation of the Trusted 
Computer System Evaluation Criteria, NCSC-TG-021, National Computer 
Security Center, April 1991.

[TNI 87]  Trusted Network Interpretation of the Trusted Computer System Evaluation 
Criteria, NCSC-TG-D05, Version-I, National Computer Security Center, 31 
July 1987.

[Williams 93]  Williams, J. G., LaPadula, L. J., ``Automated Support for External 
Consistency," The Computer Security Foundations Workshop VI Franconia, 
IEEE, June 1993.

[Winkler-Parenty 90]  Winkler-Parenty, H. B., ``Sybase: The Trusted Subject DBMS," Proceedings 
of the 13th National Computer Security Conference, Washington, DC, 1990.