Download Database Security Design

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.
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.
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”)
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.
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.
Integrity mechanisms in DBMSs
• 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.
• 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.
Integrity mechanisms in DBMSs
• 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.
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
all but privileges



 on table


to user - list with grant option 
 all rights
revoke 
 privileges
on table from



user - list
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.
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
front end
Untrusted
front end
Trusted DBMS
Trusted OS
Database
Woods Hole Architectures
High user
Low user
Untrusted
front end
Untrusted
front end
Trusted front end
Untrusted DBMS
Database
The Integrity Lock Architecture
High user
Low user
Untrusted
front end
Untrusted
front end
Trusted filter
Cryptographic unit
Append stamp
Query
Check stamp
Store
Untrusted DBMS
Database
Response
The Kernelized Architecture
High user
Low user
Trusted
front end
Trusted
front end
High DBMS
Low DBMS
Trusted OS
Database
The Replicated Architecture
High user
Low user
Trusted
front end
Trusted
front end
High DBMS
Database
high & low data
Low DBMS
Database
low data
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.
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.
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.
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?
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.
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.)
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.
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 tamperresistant.
– 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.
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.