Databases Reference
In-Depth Information
Audit Scenario.
Suppose patient Adam complains to his primary care
provider that his diabetes condition has been disclosed without his consent.
A hospital auditor then initiates an audit by formulating an
audit expression
that declaratively specifies the information to be tracked, i.e. Adam's diag-
nosis. An audit expression is syntactically identical to an SQL query except
that the SELECT clause is replaced by an audit clause of the form “
audit
audit-list
from
audited-tables
where
conditions
” where
audit-list
is a list of
column names,
audited-tables
are the tables containing the data which is the
source of the audit and
conditions
identify the subset of the data that is the
target of the audit. The auditor specifies the following audit expression to
determine whether Adam's diagnosis information was improperly accessed.
audit
y.diagnosis
from
Patient x, Treatment y
where
x.pid=y.pcid
and
x.name = 'Adam'
After receiving the audit expression, the HDB auditing system performs
a static analysis of the query log to isolate a set of
candidate queries
,which
consists of all queries that accessed all columns specified in the audit-list. The
system then combines the candidate queries with the audit expression to de-
termine the
suspicious queries
that may have accessed Adam's information.
A suspicious query is defined as a logged query that shares an
indispensable
tuple
with the audit expression. A tuple t in T is
indispensable
in the com-
putation of a SELECT-PROJECT-JOIN query Q over a database D if the
result of the execution of Q over D is not identical to the result obtained from
executing Q over D after deleting t from T.
The audit system then combines the suspicious queries into a single audit
query and runs this query against the backlog tables to determine the exact
information accessed by the query at the time it was issued. Finally, the results
of the audit reveal those queries that accessed Adam's diagnosis information,
including the identity of each query issuer, the date and time of the query,
the purpose of the query (if available), and the state of the database at the
time of the query.
Figure 5 illustrates audit query generation for the example audit given
above. The figure shows the audit expression on the right and the logged query
number 11 on the left. Query number 11 is a sample query that ran at time
T15. After identifying query 11 as a candidate query, the audit component
builds a QGM graph for this query and also builds a query model for the audit
expression. The tables referenced by the query are substituted by their backlog
tables. A temporal predicate is added over each backlog table to recover the
snapshots of the source table at time T15, the time that query 11 ran. The
audit expression is added over the logged query, thus creating a conjunction
of its predicates with those of the logged query to determine if they share an
indispensable tuple. If so, the resulting audit query produces an output tuple
identifying query 11 as suspicious.
