Database Security Design

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.

2
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.

3
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.

4
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.

5
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)

6
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 users authorizations
  can be modified while the database is operational.

7
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.

8
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.

9
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.

10
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.

11
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.

12
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.

13
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 lts, p, t, ts, g, gogt
• 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.

14
The System R authorization model

• Grant and revoke commands in SQL

15
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.

16
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.

17
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).

18
The Trusted Subject Architecture
Low user
High user
Untrusted front end
Untrusted front end
Trusted DBMS
Trusted OS
Database
19
Woods Hole Architectures
Low user
High user
Untrusted front end
Untrusted front end
Trusted front end
Untrusted DBMS
Database
20
The Integrity Lock Architecture
Low user
High user
Untrusted front end
Untrusted front end
Trusted filter
Cryptographic unit
Append stamp
Check stamp
Query
Store
Response
Untrusted DBMS
Database
21
The Kernelized Architecture
Low user
High user
Trusted front end
Trusted front end
High DBMS
Low DBMS
Trusted OS
Database
22
The Replicated Architecture
Low user
High user
Trusted front end
Trusted front end
High DBMS
Low DBMS
Database low data
Database high low data
23
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.

24
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.

25
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 users access rights based on his
  security level, and on discretionary rights.
• Auditing can be configured.

26
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.

27
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.

28
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.

29
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

30
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?

31
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.

32
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.

33
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.

34
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.)

35
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.

36
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.

37
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.

38
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.

39
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.

40
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.