2/21/2012

ICSE 6203:
Database Management Systems

Lecture 6
Database Security Design

2/21/2012 Dr. E. A. Kalinga, CSE, CoICT, UDSM 1

Database Security Design

• Secure DBMS design:
The basis for any secure database is a secure
DBMS.
There are different architectures depending on
different parts in the whole system that cannot
be trusted.
• Design of secure databases:
A security policy must be selected, implemented
and verified.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 1
 2/21/2012

Differences between DBMS and OS

• Object granularity: DBMS uses a finer granularity
(relations, rows, columns, fields) than the OS (files,
devices).
• Semantic correlation among data: relations
between data pose a threat of security violations
through inference.
• Meta-data: A DBMS provides metadata describing
relations, attributes, domains, constraints, etc. An
OS provides limited or no meta-data.

Differences between DBMS and OS

• Logical and physical objects: An OS only deals
with physical objects (files, devices). A DBMS
deals with logical objects, independent of OS
objects (relations, views).
• Multiple data types: An OS only knows files and
read, write and execute permissions. A DBMS has
many data types and operations, with separate
access modes e.g. for individual access, grouped
access, statistical operations, administrative
operations, etc.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 2
 2/21/2012

Differences between DBMS and OS

• Static and dynamic objects: Virtual objects in a
database, like views and query results can be used
in the same way as physical objects.
• Multilevel transactions: In an OS an object can
only have data of one security level. There is no
need for polyinstantiation, unlike in databases.
• Data life cycle: Data in a database must be stored
securely and permanently right after the completion
of the transaction that creates the data. In an OS
data is often not immediately stored securely.

Security mechanisms in DBMSs

• Different degrees of granularity of
access: The DBMS must offer access controls
at various degrees of granularity, such as
relations, columns, rows or individual data
items.
• Different access modes: Typical database
access modes are select, insert, update,
delete. (select means “read”)

Dr. E. A. Kalinga|UDSM|CoICT|CSE 3
 2/21/2012

Security mechanisms in DBMSs

• Different types of access controls:
– name-dependent: depends on name of
object.
– data-dependent: depends on value of
object. (can be value in query or value in
object.)
– context-dependent: depends on other
objects being accessed, on time, location
of user, etc.
• Dynamic authorization: a user’s
authorizations can be modified while the
database is operational.

Security mechanisms in DBMSs

• Multilevel protection: The DBMS should support
multilevel protection through a mandatory policy.
• Covert channels: The DBMS should be covert
channel-free.
• Inference controls: The DBMS should provide a
way to assign classifications to aggregate
information.
• Polyinstantiation: This mechanism allows the
database to have multiple instances of objects, each
having their own classification level.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 4
 2/21/2012

Security mechanisms in DBMSs

• Auditing: Security-related events should be
reported in a structured format such as system
journals, audit trails and system logs.
• Flow controls: Check the destination of output
obtained through authorized access.
• No back doors: Access to data should occur only
via the DBMS.
• Reasonable performance: Security controls
should not increase execution times significantly.

Integrity mechanisms in DBMSs

• Well-formed transactions: Updates may only occur
via transactions. (Correct execution is guaranteed via
locking.)
• Authenticated users: Updates may only be performed
by authorized and authenticated users. Authenticating
users is typically performed by the OS and need not be
duplicated in the DBMS.
• Least privilege: It should be possible to give users the
minimum update rights for their task.
• Separation of duties: No single user should be able to
corrupt data on his own.
• Continuity of operation: The DBMS should continue
to function, without data loss, in case of disasters.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 5
 2/21/2012

Integrity mechanisms in DBMSs

• Reconstruction of events: Improper behavior
should be detected (through audit trails).
• Reality checks: This goes beyond the duty of
the DBMS. But through some constraints some
“impossible” data can be avoided.
• Ease of safe use: Security procedures should be
user-friendly, known and fault-free.
• Delegation of authority: The DBMS should
support ways to assign privileges according to
mandatory or discretionary policies.
Typically the SQL grant/revoke statements are
used to delegate authority.

The System R authorization model

• System R was the first relational database system
from IBM. Protection is done at the level of tables.
There are five access modes:
—Read: to read tuples from a table. A user with read
access may also define views on the table.
—Insert: to add tuples to a table.
—Delete: to delete tuples from a table.
—Update: to modify existing tuples in a table. This privilege
may be restricted to certain columns of a table.
—Drop: to delete an entire table.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 6
 2/21/2012

The System R authorization model

• System R supports decentralized
administration of authority: the creator of
a table has all privileges on the table and can
grant rights to others and revoke rights:
<s, p, t, ts, g, go>
– s: subject or grantee.
– p: the privilege to be granted.
– t: the table on which access is to be granted.
– ts: timestamp for the grant operation.
– g: user who grants the privilege (the grantor).
– go {yes,no}: the grant option.

The System R authorization model

• Grant and revoke commands in SQL
 all rights 
 
grant  privileges  on table
all but privileges 
 
to user - list with grant option
 all rights 
revoke  
 privileges 
on table from user - list

Dr. E. A. Kalinga|UDSM|CoICT|CSE 7
 2/21/2012

The System R authorization model

• Views:
– The owner of a view has the same rights as on
the base tables, plus the drop right.
– The owner of a view (on tables for which he has
rights with the grant option) can grant others
access rights on the view, even if they do not
have access rights on the base tables.
– Access rights on base tables, given to the owner
of a view after the creation of the view are not
added to the view.
– Access rights on base tables, revoked from the
owner of a view, are also removed from the view.

The System R authorization model

• Extensions:
– Groups: Reduces the effort of distributing access
rights. Groups may overlap.
– Non-recursive revoke: This alleviates the need
to re-grant access rights after a highly authorized
user is deleted and replaced.
– Negative authorizations: One can forbid a
user to access a table, in such a way that when
other users grant access the user is still denied
the access.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 8
 2/21/2012

Secure DBMS architectures

• Two major approaches:
—Trusted Subject Architecture: assumes a
trusted DBMS and a trusted OS.
Used in many commercial DBMSs
(Sybase, Informix, Ingres, Oracle, DEC, Rubix).
—Woods Hole architectures: assume the OS is
trusted but the DBMS is untrusted. Three variants:
Integrity Lock, Kernelized, and Replicated
architecture. Supported by research prototypes
(Mitre, SeaView) and commercial DBMS (TRUDATA,
Oracle).

The Trusted Subject Architecture

High user Low user

Untrusted Untrusted
front end front end

Trusted DBMS

Trusted OS

Database

Dr. E. A. Kalinga|UDSM|CoICT|CSE 9
 2/21/2012

Woods Hole Architectures

High user Low user

Untrusted Untrusted
front end front end

Trusted front end

Untrusted DBMS

Database

The Integrity Lock Architecture

High user Low user

Untrusted Untrusted
front end front end

Trusted filter
Cryptographic unit
Append stamp Check stamp

Query Store Response

Untrusted DBMS

Database

Dr. E. A. Kalinga|UDSM|CoICT|CSE 10
 2/21/2012

The Kernelized Architecture

High user Low user

Trusted Trusted
front end front end

High DBMS Low DBMS

Trusted OS

Database

The Replicated Architecture

High user Low user

Trusted Trusted
front end front end

High DBMS Low DBMS

Database Database
high & low low data
data

Dr. E. A. Kalinga|UDSM|CoICT|CSE 11
 2/21/2012

Sybase Secure Server

• B1 or B2 classified (running on B1 secure

Unix or on B2 “bare hardware”).
• separates a TCB domain from the untrusted
User Domain.
• Primary objects: table rows, the smallest
objects that can have a security label.
• Secondary objects: tables, databases, which
have lists of discretionary access (ACLs) in
which authorized users or groups are allowed
operations.

Sybase Secure Server

• Subjects are users and user groups, using the
Transact-SQL language.
• Subjects can be assigned roles: security officer,
database administrator, database owner,
generic user.
• A Logon procedure is used to create a
connection between user-interface and DBMS. A
user has a clearance level, and can connect at a
security level not exceeding that clearance.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 12
 2/21/2012

Sybase Secure Server

• User operations are Transact-SQL requests
(Select, Update, Insert, Delete). The SQL
parser and compiler run as untrusted user
processes. They translate operations into a
reduced set of binary format instructions
(forming a procedure).
• A procedure is executed by the TCB. The TCB
also verifies the user’s access rights based on
his security level, and on discretionary rights.
• Auditing can be configured.

Ingres
• Subjects are users and groups.
• All users in a group are given a set of
authorizations, giving them the right to execute
certain applications.
• When executing an application a user must
enter the role and password for that role.
• Objects are databases, catalogues, tables,
views, procedures. Ingres uses Grant and Grant
Option for rights Select, Insert, Delete, Update
and Execute.
• Auditdb command for inspecting audits.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 13
 2/21/2012

Oracle
• B1 version for Unix, A1 for GEMSOS.
• Subjects can be created, altered and dropped.
• The administrator defines a role, grants
privileges to the role and then grants the role
to subjects.
• Granting roles to roles creates hierarchy.
• Connect privilege to connect to database.
• Resource privilege to create base tables.
• DBA privilege to also create users.

Oracle (cont.)
• Objects are databases, tables, views, etc.
Objects have security labels, defines at the
relation level.
• Operations Select, Insert, Update, Delete,
Alter, Index and Reference on tables. Only
Select, Insert, Update and Delete on views.
Execute privilege on procedures.
• Grant option is available.
• Column privileges for Update, Insert,
Reference.
• Audit command to inspect audit trails.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 14
 2/21/2012

Design of secure databases

• Preliminary analysis: feasibility study
• Security requirements and policies: define
security requirements for all threats.
• Conceptual design: describe policies and
methods to be used.
• Logical design: translate design to the chosen
DBMS.
• Physical design: design physical structures.
• Implementation
• Verification and testing

Design of secure databases (cont.)

• Preliminary analysis:
—System risks: investigate risks, like modification of
information by bypassing DBMS.
—Features of the database environment: e.g.,
multilevel protection or not?
—Applicability of existing security products:
existing products vs. development from scratch.
—Integrability of the security products: can it be
realized on the selected hardware and software?
—Performance of the resulting security system:
how does performance compare to insecure system?

Dr. E. A. Kalinga|UDSM|CoICT|CSE 15
 2/21/2012

Design of secure databases (cont.)

• Requirement analysis: precise and
accurate study of all possible threats, and
selection of appropriate policy.
– Value analysis: determine level of
sensitiveness of data.
– Threat identification / Vulnerability
analysis: how could this system be broken?
– Risk analysis / Risk evaluation: probability of
undesired events and seriousness of the effect..
– Requirement definition: requirements defined
based on threats, undesired events and
probability.

Design of secure databases (cont.)

• Security policy selection:
– Secrecy versus integrity versus reliability.
– Maximum sharing vs. minimum privilege.
– Granularity of control.
– Attributes used for access control.
– Priorities.
– Privileges.
– Authority.
– Inheritance.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 16
 2/21/2012

Design of secure databases (cont.)

• Conceptual design:
– Identification of the subjects and objects relevant
from a security viewpoint.
– Identification of access modes granted to
different subjects on different objects; constraints
on access.
– Analysis of propagation of authorizations in the
system through grant/revoke privileges.
• Model must be
– complete: model must meet requirements.
– consistent: avoid indirect access to objects.

Design of secure databases (cont.)

• Logical design: Translate the conceptual model

to a specific DBMS. e.g. in relational DBMS view-
based and query-based security techniques are
common for access control.
• Physical design: Storage organization and
implementation/integration modes for security
mechanisms. (e.g. auditing using database tables
or OS features, etc.)

Dr. E. A. Kalinga|UDSM|CoICT|CSE 17
 2/21/2012

Design of secure databases (cont.)

• Implementation of security
mechanisms: There are many guidelines,
most of which are common-sense:
– Economy of mechanisms: mechanisms should
be as simple as possible.
– Efficiency: mechanisms, invoked at run time,
should be efficient.
– Linearity of cost: the operation costs should be
proportional to the actual use of the mechanism.
– Privilege separation (responsibilities):
layered mechanisms, maybe with multiple
passwords.

Design of secure databases (cont.)

• Implementation of security
mechanisms:
– Minimum privilege: when acceptable as a
policy this reduces maintenance and risks, and is
easier to be proven correct.
– Complete mediation: each access must be
checked.
– Known design: better than experimental.
– Security by default: if user gives no options
there should be a sensible default.
– Minimum common mechanisms: correct
working of one mechanism independent of others.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 18
 2/21/2012

Design of secure databases (cont.)

• Implementation of security
mechanisms:
– Psychological acceptability: easy to use and
employ correctly.
– Flexibility: mechanisms should be effective
under various circumstances, including worst-
case.
– Isolation: security mechanisms should be
isolated from other system components and be
tamper-resistant.
– Verifiability: security mechanisms must be
provably correct.

Design of secure databases (cont.)

• Implementation of security
mechanisms:
– Completeness and consistency: the
mechanism must comply fully with design
specifications; protection should be specified as
positive and negative specifications.
– Observability: the mechanism and possible
attacks against it must be controllable (visible).
– Problem of residuals: residual data in memory
should be erased before memory is reused.
– Invisibility of data: users should not be able to
deduce data from being denied access to it.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 19
 2/21/2012

Design of secure databases (cont.)

• Implementation of security
mechanisms:
– Work factor: circumventing a security
mechanism should be a lot of work.
– Intentional traps: helps detect attempts to
break the system.
– Emergency measures: special “disable”
modalities, available to trusted persons.
– Secure hardware: reliable, physically protected.
– Programming language: choice of
programming language and employing skilled
programmers can greatly reduce the error rate.

Design of secure databases (cont.)

• Verification and testing:
– Proofs of correctness of mechanisms:
code in some programming languages can be
proven to be correct.
– Tests: analysis of the program behaviour,
through testing, hiring experts to try to break
the system, etc.

Dr. E. A. Kalinga|UDSM|CoICT|CSE 20