Databases Reference
In-Depth Information
database audit trail (typically a table in the data dictionary) or (2) in an op-
erating system audit trail, where audit information is written to a file outside
the database, unaccessible to database users. Typical information recorded in
an audit trail includes the database user name, role and object privileges used,
name of the database object accessed, session and transaction id, SQL text of
the statement that triggered the auditing, and type of operation performed.
It should be noted that enabling any type of audit mechanism has an impact
on the performance of the database, no matter whether these are triggers or
audit mechanisms enabled through the SQL
audit
command. Thus, any au-
dit strategy targeting the security evaluation of a database has to carefully
analyze the various security requirements imposed on the database and the
specific objectives of the strategy. In the following two sections, we first discuss
some basic building blocks for such a strategy: the profiling of data and users.
In Section 4, we then present a methodology that embeds these techniques in
a more comprehensive and strategy-driven framework.
3.2 Data Profiling
Most approaches to misuse detection are
user-centric
. Their objective is to
determine how users typically behave in terms of operations on the database
and how their current behavior deviates from previous behavior. We con-
jecture that for the security re-engineering of databases, the evaluation and
strengthening of security has to take a
data-centric
view. That is, first the
behavior of the data being managed in the database needs to be evaluated
before techniques are employed to detect and evaluate the (potentially anoma-
lous) behavior of users. There are several reasons for such an approach. First,
accidental or malicious tampering with the security and integrity of data is
often only detected at the data level, that is, when erroneous, missing, extra,
or anomalous data are discovered. This aspect leads to the second argument,
where one would like to back-trace anomalous data to users who operate on
the data, something that is not trivial in particular in the case of shared
database user accounts, which is common in many application settings and
will be discussed in Section 4. Finally, and most importantly, approaches to
establishing some normal user behavior typically assume that the data users
operate on are normal, i.e., the data are correct and of good quality, some-
thing that is often not the case for production databases where evaluating and
maintaining the quality of data is a major concern [9, 18].
Snapshot Profiles
The first step in security re-engineering for databases is to determine and
evaluate the properties of data that is to be protected from misuse. Given
a database schema consisting of a set of relations
, those relations are in-
vestigated that manage mission-critical or sensitive data. Similar to the ap-
proaches suggested in [25] and [56], for a given relation
R
R
∈R
with attributes
