Databases Reference
In-Depth Information
(who performed what operations on what objects at what points in time) and
the reconstruction of events [41].
NIST has established six components of security audit criteria [3], which
can directly be adopted to database systems. The activities are the (1) selec-
tion of security audit events, (2) security audit data generation, (3) security
audit event storage, (4) audit review, (5) security audit analysis, and (6) au-
tomatic response. Figure 1 illustrates the sequence of these criteria as an ap-
proach to using auditing techniques for evaluation activities, which is preceded
by an extra step, the analysis of application specific security requirements.
Analysis of
application-specific
security requirements
Selection of
audit events
Generation of
audit data
Audit event
storage
Review of
audit trail
Audit analysis
Response
Fig. 1.
Activities according to the NIST security audit criteria.
Most of today's commercial and open-source DBMS provide audit mecha-
nisms and architectures that support such activities and which mostly vary in
terms of the granularity of access information that can be recorded in audit
trails. For example, database triggers provide a convenient means to record in-
formation about SQL insert, update, and delete statements against database
relations, including the recording of old and new values of updated tuples.
Activities related to the creation, modification, and deletion of database ob-
jects resulting from SQL data definition language (DDL) statements can be
audited as well, often referred to as the auditing of accesses with respect to
system privileges
. Some database systems even offer mechanisms that go be-
yond simple SQL statement level auditing by monitoring data accesses based
on content, such as Fine-Grained Auditing (FGA) introduced with Oracle 9i.
This is in particular useful when access information about SQL select state-
ments needs to be recorded (see, e.g., [30]).
In addition to database triggers and the SQL
audit
command supported
by many DBMS, another useful technique are stored procedures. Instead of
individual SQL insert, update and delete statements issued from an applica-
tion, stored procedures are called. A stored procedure then executes the data
modification statements and also records (in auxiliary relations) some extra
context information about the modifications such the current user role, other
users currently running database sessions, or the number of records that have
been modified through these statements.
In general, audit mechanisms for the monitoring of SQL statements, access
privileges used, database schema objects and fine-grained access information
can manage audit information in two ways: (1) within the database as a
