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 user’s 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: <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.

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 High user Low user Untrusted front end Untrusted front end Trusted DBMS Trusted OS Database

19. Woods Hole Architectures High user Low user Untrusted front end Untrusted front end Trusted front end Untrusted DBMS Database

20. The Integrity Lock Architecture High user Low 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 High user Low user Trusted front end Trusted front end High DBMS Low DBMS Trusted OS Database

22. The Replicated Architecture High user Low user Trusted front end Trusted front end High DBMS Low DBMS Database high & low data Database 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 user’s 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.