Databases Reference
In-Depth Information
Upon the completion of an audit window for a relation
R
, the relation's
access profile is analyzed to evaluate access patterns of interest. This can easily
be done using standard SQL statements that involve
group by
and sorting.
For example, for insert statements, one can determine typical values or value
ranges of inserted attributes. Similarly, for delete statements, one can compute
characteristic properties of the deleted tuples. For update statements, it is
furthermore possible to analyze the modifications at a much more fine-grained
level. For example, one can determine the average, maximum, and minimum
change of an updated attribute. Here again, knowing the security policies and
typical behavior of data in the relation is of much help in designing constraint
mechanisms that prevent accidental or intentional anomalous updates. As an
illustrative example, assume an employee relation with an attribute
Salary
.If
it is known that salaries can only be increased by no more than 20% and not
decreased by more than 10%, and these properties are also reflected in the
access profile for the relation, then suitable triggers enforcing this property
can be implemented.
In summary, the data profiling approach provides data administrators with
both static (one-time) and temporal properties of relations and accesses to re-
lations. The information obtained during the profiling not only helps in under-
standing the behavior of mission-critical and sensitive data, but it can also be
used to derive semantic integrity constraints, which, if suitably implemented,
further help preventing potentially anomalous data modifications.
3.3 User Profiling
Following the data profiling tasks presented in the previous sections, the next
step is to associate users with the behavior of the data and eventually de-
termine models describing the normal behavior of users. Profiling of users
or, more precisely, their behavior over time, has been the focus of several re-
lated work in the context of relational databases, e.g., [13, 15, 29, 56], fraud
detection, e.g., [21, 22], and intrusion detection, e.g., [33, 36, 53, 60].
In order to suitably approach the user profiling task, it is important to un-
derstand the notion of a user in a database system. Underlying access control
models in databases is the notion of
authorization identifier (AuthID)
,which
is either the identifier of a database user or a database role name. According
to the SQL:1999 standard [39], when an SQL session is initiated (e.g., an ap-
plication connects to the database using a valid database user account), the
authorization identifier is then determined by the DBMS. In the following,
whenever we refer to a user, we mean a valid database user account used by
either a person or an application. There are typically different types of users:
•
Database Administrators (DBAs)
. These types of users possess various
system privileges to manage physical database objects (e.g., the creation
of database files), logical objects (e.g., the creation and deletion of rela-
tions, views, triggers etc.), user accounts, database roles and privileges,
and system parameters and settings.
