Databases Reference
In-Depth Information
association between tank-name and its value at the Secret level could be ZZZ
instead of XXX. The security policy of UFOS is essentially read-at-or-
below-your-level and write-at-your-level. There does not appear to be any
discussion of TCB with this effort.
11.5
Design Issues
DB security can no longer be considered a secondary requirement to be
added to existing DB systems. Rather, it must be considered a primary need
to be taken into account from the initial phases of the DB design. Various
authors thus suggest the use of a methodological approach to the design of a
secure DB system, along the lines of the methodologies used for DB design.
Here, we briefly report some guidelines that can be used in designing a secure
DB (some of the ideas presented here are taken from [6]). Secure DB design
can be seen as an incremental process, consisting of the following steps:
(1) preliminary analysis; (2) requirement analysis; (3) security policy specifi-
cation; (4) design of the access control mechanism; and (5) implementation
of the access control mechanism.
The aim of the preliminary analysis phase is to perform a feasibility
study for the secure system to be developed, including an evaluation of
the costs, risks, priorities, and human, hardware, and system resources to
be employed. The protection requirements are fully specified during the
requirement analysis phase. This second phase must start with a precise study
of all the possible security threats to which the system could be exposed and
an accurate analysis of the kind of protection you would like to ensure for the
data stored in the system. The result of this phase is a specification of the type
of accesses a subject can exercise on the DB objects. Such specification is usu-
ally expressed in an informal way, usually as a set of sentences expressed in
natural language.
In the third phase, the security policies that best match the require-
ments specified in the preceding phase are selected. During the security poli-
cies specification phase, it must be defined in details which kinds of privileges
the subjects can exercise on the objects in the system (e.g., update, read, exe-
cute). During this phase, it must also be defined which are the roles and/or
groups (if any) in the systems and whether they are flat or hierarchically
organized. It must also be defined at which granularity the access control
should be enforced, that is, whether it is possible to require access to groups
of objects, single objects, or portions of them.
