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