Databases Reference
In-Depth Information
•
unused application accounts
for which no person exists who makes use of
that account,
•
unused database accounts
for which no application account exists that uses
the database account, and
•
unused database roles
that have not been assigned to any user or have no
privileges associated with them.
Unused user accounts or default accounts, which often come with appli-
cations and database servers, always pose a security risk. In particular for
default accounts default passwords are used that can easily be guessed by
an intruder (see, e.g., [30, 42]). Even though the information gathering de-
termines that there is a correlation between accounts, say an application can
use two different database accounts, this does not necessarily mean that these
database accounts are actually all used. A similar argument can be made for
database roles. An instantiation of the access path model and representing
the different access paths from the information available at the application
and database layer resembles more like a
static analysis
of admissible access
correlations. The instantiation does not reveal any information about the how
access paths and sub-paths are actually used. This is where the data and user
profiling techniques are employed to further evaluate accesses and to detect
potential vulnerabilities, as discussed next.
4.3 Annotating and Exploring Access Paths
Assume a partially instantiated access path model for some applications and
database where no access correlations between database accounts/roles and
database objects have been made yet. In order to focus on evaluating the
security of mission-critical and sensitive database objects and relations in
particular, only respective relations are considered first in exploring access
correlations. Is is assumed that for a given database schema such relations
can be identified based on existing security policies and regulations. In the
following, let
DB
obj
denote only such critical relations.
Now, for each relation
R
∈DB
obj
, a snapshot profile
DataP rof
(
R, t
i
)
is determined at time
t
i
. This process follows exactly the tasks presented
in Section 3.2. Respective profiles are inspected, evaluated and subsequently
access profiles
AccessP rof
(
R, t
i
,t
j
) are established for a time window [
t
i
,t
j
].
The profiles obtained in this way are now used to
annotate
components of
the access path model instance comprised of vertices (representing accounts,
roles, and objects) and edges (representing access correlations). Each relation
R
∈DB
obj
is annotated with its snapshot profile
DataP rof
(
R, t
i
) and access
profile
AccessP rof
(
R, t
i
,t
j
). It is assumed that a snapshot profile is captured
at the same time
t
i
the collection of access information for
R
during the time
window [
t
i
,t
j
] is initiated. From an access profile
AccessP rof
(
R, t
i
,t
j
)and
its user profiles
UserProf
(
R, u
db
,t
i
,t
j
) then access sub-paths from database
accounts/roles to the relation
R
are established. Each such sub-path ((
u
db
−→
