Database Security

Database
An organized collection of data Data is typically organized using a data model
ER model Relational model

DBMS
A software designed to allow definition, creation, querying, update and administration of databases

 Functions of a DBMS
Query Processing Transaction Management Storage Management Metadata Management Database Integrity Fault Tolerance Security

Security Policies for Database Systems

A set of rules that enforce security Divided into two classes
Mandatory Security policies
Have to be followed strictly irrespective of the applications

Discretionary Security policies

Policies specified by the administrator Variable in nature

Discretionary Security Policies

Access Control Policies
Control access to data Authorization Policies
Users are granted access based on authorization rules Various types of authorization policies
Positive authorization Negative authorization Conflict resolution Strong and weak authorization Propagation of authorization rules Content and context based rules

 Role based access control

Grant access to users depending on their roles and functions Users need access to data depending on their roles Data accessible to one class of users may or may not be available to another class of users Eg. In an organization, the president can have access to all the information about the organization, the financial head can access all the finance related information, a team leader can access data pertaining to only the employees in his/her team etc.

 Administration Policies
Specify who is to administer the database Administration duties usually performed by the Database Administrator (DBA) include keeping the data current, making sure that the metadata is updated etc. Security related tasks may be performed by a System Security Officer (SSO)

 Identification and authentication

Users must identify themselves using user ID and password Authentication involves the verification of the user credentials to ensure the identity of the user Password based schemes are susceptible to attacks Many modern systems use biometric techniques like face and voice recognition

 Database views for security

Database views can be used to restrict the data exposed to the user Eg. A relation Employee stores details relating to the employees in a company. Some personal information like healthcare records, salary etc. should not be viewed by other employees. This can be done by defining a view on the Employee relation that excludes these attributes.

 Policy Enforcement
Mechanism to enforce security policies Three aspects to policy enforcement
Policy specification Policy implementation Policy visualization

 SQL extensions for security

SQL is designed to access and manipulate data in a database Security features embedded in SQL include the GRANT and REVOKE functions which control access to the data for users
Eg:- GRANT JOHN EMPLOYEE READ, REVOKE JOHN DEPT WRITE etc.

 Extensions can be made to SQL to enforce certain security policies

Eg:- User John has read access to the name and salary attributes in a relation EMP separately, but never together. This can be specified in SQL as

 Query modification
Database queries can be modified based on constraints to enforce security Eg: Consider a query by the user John to retrieve all tuples from EMP. If John only has read access to all the tuples in EMP where salary is less than 30K, and the employee is not in Security department, then the query

 Database functions affected by discretionary security measures

Query optimization Transaction management Storage management

 Visualization of policies
Visualization tools are used by users to better understand the data in the databases Visualization tools are useful when integrating security policies of different databases Visualizing the effects of dynamically varying security policies are helpful in designing secure databases

Mandatory Security Policies

Specify the access that users have to various database objects Uses Multi Level Security (MLS) Based on Bell and LaPadula model of security
The various database objects are assigned security levels which include Unclassified, Confidential, Secret and TopSecret The hierarchy of the security levels is Unclassified < Confidential < Secret < TopSecret Subjects are assigned clearance levels for accessing data Subjects can access data on levels upto and including their clearance level

 The rules of the Bell and LaPadula model are

Simple security policy: A subject has read access to an object if its level dominates the level of the object * - Property: A subject has write access to an object if the subjects security level is dominated by that of the object For database systems, the *-property is modified such that a subject has write access to an object if the subjects level is that of the object A subject can modify relations at its own level

Security Architectures for MLS Databases

Integrity Lock
Contains an untrusted back end DBMS, an untrusted front end that communicates with the user and a trusted filter component that performs encryption The untrusted components are isolated from each other and can communicate only through the trusted component Multiple instantiations are maintained for the front end, corresponding to each user level Every tuple that is inserted into the database has associated with it a security label (also called a sensitivity label) and a cryptographic checksum. Checksums are computed by the trusted filter on insertion and recomputed during retrieval. For insertions, the trusted filter computes the checksum and the untrusted back-end DBMS takes the data (i.e., the tuple) and associated label and checksum and stores them in the database On retrieval, the back end retrieves the data tuples and passes them to the trusted filter which recomputes the checksum based on the tuple and label retrieved.

 Operating System Providing Access Control

Also known as the HinkeSchaefer approach Utilizes the underlying trusted operating system to perform the access-control mediation No access-control mediation is performed by the DBMS The DBMS objects (e.g., tuples) are aligned with the underlying operating system objects (e.g., files) Thus, Secret tuples are stored in Secret files and Top Secret tuples are stored in Top Secret files

 Kernel Extensions Architecture

The underlying operating system is utilized to provide the basic MAC and DAC mediation However, the MLS/DBMS will supplement this access mediation by providing some additional accesscontrol mediation For example, the MLS/DBMS might provide contextdependent DAC on views

Trusted Subject Architecture

Does not depend on the underlying operating system to perform access control the DBMS is considered to be a trusted subject hosted on top of the operating system access to DBMS records is mediated by the trusted DBMS

 Distributed Architecture
Multiple untrusted back-end DBMSs and a single trusted front-end DBMS Communication between the back-end DBMSs occurs through the front-end DBMS Two approaches
Partitioned approach - Each back-end DBMS has data at a particular level and operates at that level Replicated approach - Lower-level data is replicated at the higher levels

With the partitioned approach the trusted front end is responsible for ensuring that the query is directed to the correct back-end DBMS For the replicated approach the trusted front end ensures that the query is directed to a single DBMS, which is has the same security level as the user

Multilevel Relational Data Models

Developed to support MLS/DBMS The data in a relational database may be classified on several levels Granularity of classification in a DBMS Database level

 Classifying relations

Classifying attributes

 Classification of tuples

Element level classification

 Classification of Views

 Classification of Metadata

 Polyinstantiation
A technique used in relational databases to represent the fact that users at different levels have different views of the same entity For example, at the TopSecret level Marys salary would be 40K but at the Secret level it would be 30K, at the Confidential level it would be 20K, and at the Unclassified level it would be 10K

 Polyinstantiation violates the properties of the relational model Every entity should have a unique representation in the relational model; in polyinstantiated model an entity has multiple representations Polyinstantiation is required to eliminate covert channels
Eg. John has a salary of 70K, which is the real value and therefore maintained as Top Secret. There is no other value for the salary of John maintained at Secret, Confidential or Unclassified levels. A user at these levels when querying for Johns salary will not get an answer since no value is provided. The lack of answer, therefore, signals to the user about the existence of a salary value for John maintained at a higher security level. This information can be exploited by malicious users or processes to gain access and perform unauthorized modification of higher level data. The absence of data values at the different security level, therefore creates a covert channel for accessing and modifying higher level data

Impact of security on database functions

Impact on query processing
The trust placed on the query processor depends on the architecture of the entire system like integrity locking, extended kernel etc. Query modification is a means of enforcing security; Irrespective of the security architecture followed, the part of the DBMS that performs this function should be a trusted component Query optimization is also impacted by security measures

 Impact on transaction processing

Traditional transaction concurrency control algorithms like locking can cause covert channels A covert channel is created when a process operating at a higher level of security interferes with a low security level process As an example, Consider the case where there are two transactions operating at the Secret and Unclassified levels Suppose the Secret transaction reads an Unclassified object while the Unclassified transaction attempts to update the object. Then the Unclassified transaction will not be able to update the object. This provides information to the Unclassified transaction about the existence of the Secret transaction. A malicious process can exploit this information and gain unauthorized access to the data in the database

 Solution for this problem proposed by the author

For every Unclassified database object O, there is a Secret object which is a duplicate of O, say, O and a Secret object, say, O that is only updated by the Secret process or transaction. Therefore, when an Unclassified transaction updates O, the duplicate O gets updated. The Secret transaction reads from O and writes into O. This way the actions of the Secret transaction do not interfere with those of the Unclassified transaction

 Impact on Storage Management

Storage management in a DBMS includes two major aspects and they are designing efficient access methods and indexing strategies In a MLS/DBMS storage management involves the storing of multilevel data The trust placed on the DBMS for the secure storage of data is directed by the security architecture followed If the operating system provides access control, then the DBMS is untrusted and therefore the access methods and indexing algorithms are also untrusted If the system is based on trusted subject architecture, then we need to determine the trust placed on the accesscontrol and indexing algorithms Developing secure storage, indexing and access methods for databases is an active area of research

 Impact on metadata management

Like data, metadata also has to be managed securely It must be ensured that metadata is queried securely If database transactions update metadata, it must be ensured that higher level transactions do not interfere with lower level transactions Metadata has to be stored and accessed securely If the operating system is to provide access control to metadata, then metadata management functions may be untrusted. If the DBMS controls access then metadata management may be trusted.

Distributed Database Systems

The developments in computer networking technology and database systems technology resulted in the development of distributed databases A distributed database is a database that is distributed across multiple sites A distributed database system includes a Distributed Database Management System (DDBMS), a distributed database, and a network for interconnection. Distributed database system functions include distributed query management, distributed transaction processing, distributed metadata management, and enforcing security and integrity across the multiple nodes

Discretionary Security for Distributed Database Systems

Discretionary Security measures for distributed databases are similar to those followed for non distributed databases Access Control Policies
The access-control rules enforced in a distributed environment may be distributed, centralized, or replicated. If the rules are centralized, then the central server needs to check all accesses to the database. If the rules are distributed, then appropriate rules need to be located and enforced for a particular access. If the rules are replicated, meaning copies of the rules are stored at every site, any change in the rules made at one location should be reflected at all other locations where a copy of these rules are stored As an example, suppose there is a rule that states that John has access only to the employee salaries if the employees are in the math department. Suppose the database has two relations EMP and DEPT where EMP is stored in site A and has attributes E#, Ename, Salary, and D#. DEPT is stored in site B and has attributes D#, Dname, and Mgr. Now to access the salary values in EMP, one needs to do a join between EMP and DEPT at different sites and make the connection between Salary and Dname. If the Dname is MATH, then John has access to the salary values of the employees in the math department.

 Role based access control

In a distributed database environment users may have different roles at different nodes and may try to access the distributed database to carry out their functions. The ideas developed for a centralized system can be extended for a distributed environment. In the simple case, the users role is verified in a distributed environment by contacting the local authority, and access is then granted. In a multiorganizational environment, there may be some additional concerns. A user may have one role in one organization and another role in another organization. For example, in department A he may be a manager and in department B he may be a project leader. Therefore, he may have access to certain data in department A and certain other data in department B. His roles in different departments will have to be verified before granting his access

 Identification and authentication

Identification and authentication in distributed databases may be performed either by a centralized authority or a distributed authority Having a single site to authenticate the user means that if that site fails then the user cannot be authenticated If every site is given the capability to authenticate the users, as users can log in from anywhere, then it is required to ensure that the password information is protected at all sites

 Security Policy Integration

The schema of individual databases constituting a distributed database system can be merged to obtain a global schema When performing such database schema integration, the security policies defined on the individual databases has to be merged to define a global security policy For example, in one database one could enforce a policy where the salary values of the relation EMP cannot be accessed by John. In another database, one could enforce a policy where the healthcare record of the relation MEDICAL cannot be accessed by John. Therefore, at the global level one enforces a policy where John does not have access to salaries in EMP or healthcare records in MEDICAL.

 Query modification
With query modification, the query is modified based on the access-control rules The query is modified according to the accesscontrol rules enforced by a distributed database system If the access-control rules are replicated, the query modification can be performed at the site where the query is posed If the access-control rules are distributed, then the query is modified at each site according to the rules enforced at that site and then the pieces are combined to form the final modified query

 View mechanism
Views are essentially virtual relations and are computed from the base relations In a distributed database environment, views may be computed from relations and fragments stored at multiple sites Users are then granted access to the resulting views For example, EMP could be stored at site A and DEPT at site B and a view may be formed consisting of employee names and their managers. Access may be granted on this view and access denied on the base relations