Security in Computing-Module 5

Download

Module 5

1. Types of Security

Database security is a very broad area that addresses many issues like:

1. Legal and ethical issues regarding the right to access information.
2. Policy issues at the governmental, institutional or corporate level as to what kinds of information should not be made publicly available.
3. System related issues such as the system levels at which various security functions should be enforced.
4. The need in some organizations to identify multiple security levels and to categorize the data and users based on these classifications.

II. Threats to Databases

Important security goals are integrity, availability and confidentiality. Threats to databases result in the loss of degradation of some or all of the security goals.

1. Loss of integrity – Database security refers to the requirement that information be protected from improper modification. Modification of data includes insertion, deletion, updation etc. Integrity is lost if unauthorized changes are made to data by either intentional or accidental acts.
2. Loss of availability – Database availability refers to making objects available to a human user or a program to which they have a legitimate right. Loss of availability is a serious threat to database security.
3. Loss of confidentiality – Database confidentiality refers to the protection of data from unauthorized disclosure. Unauthorized access to data can lead to loss of database security.

To protect databases against these types of threats four kinds of countermeasures can be implemented:

1. Access control – The security mechanism of a DBMS must include provisions for restricting access to the database system as a whole. This function is called access control and is handled by creating user accounts and passwords to control the login process by the DBMS.
2. Inference control – Statistical database is used to provide statistical information or summaries of values based on various criteria. For e.g. a database for population statistics based on age groups, income level and other criteria. It is sometimes possible to deduce or infer certain facts concerning individuals from queries that involve only summary statistics on groups; this must not be permitted. This problem is called statistical database security. The corresponding counter measures are called inference control measures.
3. Flow control – It prevents information from flowing in such a way that it reaches unauthorized users. Channels that are pathways for information to flow implicitly in ways that violate security policy of an organization are called covert channels.
4. Data Encryption – It is used to protect sensitive data that is being transmitted via some type of communications network. Encryption is also used for providing additional protection for sensitive portions of a database. The data is encoded using some coding algorithm.

In a multiuser database system, the DBMS must provide techniques to enable certain user or user groups to access selected portions of a database without gaining access to the rest of the database. A DBMS includes a database security and authorization subsystem that is responsible for ensuring the security portions of a database against unauthorized access. There are two types of database security mechanisms:

1. Discretionary security mechanisms – These are used to grant privileges to users, including the capability to access specific data files, records or fields in specified mode.
2. Mandatory security mechanisms – These are used to enforce multilevel security by classifying the data and users into various security classes (or levels) and then implementing the appropriate security policy of the organization.

III. Database Administrator (DBA)

DBA is the central authority for managing a database system. The DBA has a DBA account which is also called a system or superuser account, which provides powerful capabilities that are not made available to regular database accounts and users. DBA has privileged commands for performing actions like:

1. Account creation – This action creates a new account and password for a user or a group of users to enable access to the DBMS.
2. Privilege granting – This action permits the DBA to grant certain privileges to certain accounts.
3. Privilege revocation – This action permits the DBA to revoke (cancel) certain privileges that were preciously given to certain accounts.
4. Security level assignment – This action consists of assigning user accounts to the appropriate security classification level.

IV. Access Protection, User accounts & database Audits

Whenever a person or group of persons needs to access a DBMS, the individual or group must apply for a user account. The DBA will then create a new account number and password for the user if there is a legitimate need to access the database. The user must log into the DBMS by entering the account number and password whenever database access is needed. The DBMS checks that the account number and password are valid; if they are, the user is permitted to use the DBMS.

                        To keep track of database users and their accounts and passwords there is an encrypted table or file with two fields – account number and password. Whenever a new account is created, a new record is inserted into the table. When an account is canceled, the corresponding record is deleted from the table.

                        The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session, which consists of the sequence of database interactions that a user performs from the time of logging in to the time of logging off. When a user logs in, the DBMS can record the user’s account number and associate it with the terminal from which the user logged in. All operations applied from that terminal are attributed to the user’s account until the user logs off.

                        To keep track of all updates applied to the database, a system log is maintained. It includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash.

                        If any tampering with the database is suspected, a database audit is performed, which consists of reviewing the log to examine all accesses and operations applied to the database during a certain time period. When an illegal or unauthorized operation is found, the DBA can determine the account number used to perform this operation. A database log that is used mainly for security purpose is called an audit trail.

V. Types of Discretionary Privileges

There are two levels of assigning privileges to use the database system:

1.      The account level – At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database.

The privileges at the account level are

a)      Create schema or Create table - To create a schema or base relation.

b)      Create view – To create virtual relations.

c)      Alter - To apply schema changes such as adding or removing attributes from relations.

d)     Drop - To delete relations or views.

e)      Modify - To insert, delete, or update tuples

f)       Select - To retrieve information from the database by using a SELECT query.

2.      The relation (or table) level – At this level, the DBA can control the privilege to access each individual relation or view in the database. The relation level privileges are applied to base relations or virtual relations (views). Privileges at the relation level specify for each user the individual relations on which each type of command can be applied.

Access Matrix Model

            The granting and revoking of privileges generally follow an authorization model for discretionary privileges known as access matrix model. In this model the rows of a matrix M represent subjects (users, accounts and programs) and the columns represent objects (relations, records, columns, views, operations). Each position M (i, j) in the matrix represents the types of privileges (read, write, update) that subject i holds on object j.

            To control the granting and revoking of privileges, each relation R in a database is assigned an owner account. The owner is given all privileges. The owner account holder can pass privileges to other users by granting privileges to their accounts. In SQL, the following types of privileges can be granted:

1.      SELECT – This gives the account the privilege to use select statement.

2.      MODIFY – This gives the account the privilege to use insert, update and delete statements.

3.      REFERENCES – This gives the account the capability to reference relation R when specifying integrity constraints.

Specifying Privileges using views

If the owner A of a relation R wants another account B to be able to retrieve only some fields of R, then A can create a view V of R that includes only those attributes and then grant SELECT on V to B.

Revoking Privileges

The owner of a relation may want to grant certain privileges to a user for a specific task and then revoke those privileges, once the task is completed. In SQL, REVOKE command is used for canceling privileges.

Propagation of privileges using the GRANT option

Whenever the owner A of a relation grants a privilege on R to another account B, the privilege can be given to B with or without the ‘GRANT OPTION’. If the GRANT OPTION is given, this means that B can also grant the privilege on R to other accounts.

            Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C, also with GRANT OPTION. In this way, privileges on R can propagate to other accounts without the knowledge of the owner of R. If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privileges should automatically be revoked by the system. It is possible for a user to receive a certain privilege from two or more resources. For e.g. A4 may receive a certain ‘update R’ privilege from both A2 and A3. In such a case, if A2 revokes this privilege from A4, A4 will still continue to have the privilege by virtue of having been granted it from A3. If A3 later revokes the privilege from A4, A4 totally loses the privilege.

E.g.  1.  GRANT createtab to A1 ---- Gives A1 the privilege to create tables.

        2. GRANT INSERT, DELETE ON EMPLOYEE, DEPT to A2 ------ gives the   privilege to perform insert and delete operations on Employee and Dept tables.

        3.  GRANT SELECT ON EMPLOYEE to A3 with GRANT OPTIION ---- gives A3 the privilege to perform select operation.

         4. REVOKE SELECT ON EMPLOYEE FROM A3 ---- revokes the privilege to perform SELECT operation on EMPLOYEE from A3.

Specifying limits on propagation of Privileges

1.      Horizontal propagation – Limiting horizontal propagation to an integer number i means that an account B given the GRANT OPTION can grant the privilege to at most i other accounts.

2.      Vertical propagation – Granting a privilege with a vertical propagation of zero is equivalent to granting the privilege with no GRANT OPTION. If account A grants a privilege to account B with the vertical propagation set to an integer number j>0, this means that the account B has the GRANT OPTION on that privilege, but B can grant privilege to other accounts only with a vertical propagation less than j.

VI. Mandatory Access Control for Multilevel Security

MAC require the classifications of users and data values into security classes and enforce the rules that prohibit flow of information from higher to lower security levels. Typical security classes are top secret (TS), secret (S), confidential (C) and unclassified (U), where TS is the highest level and U is the lowest.

                             TS > S > C > U

The commonly used model for multilevel security known as Bell – LaPadula model classifies each subject (user, account and program) and object (relation, tuple, column, view, operation) into one of the security classifications TS, S, C or U. The clearance (classification) of a subject S is referred as class (S) and the classification of an object O as class (O). Two restrictions are enforced on data access based on the subject/object classifications.

1. A subject S is not allowed to read access to an object O unless class (S) > class (O). This is known as the simple security property.

2.      A subject S is not allowed to write an object O unless class (S) < class (O). This is known as the star property.

The first rule enforces that no subject can read an object whose security classification is higher than the subject’s security clearance. The second rule prohibits a subject from writing an object at a lower security classification than the subject’s security clearance. Violation of this rule would allow information to flow from higher to lower classifications. For e.g. a user (subject) with TS clearance may make a copy of an object with classification TS and then write it back as a new object with classification U, thus making it visible throughout the system.

                        To incorporate multilevel security notions into the relational database model, it is common to consider attribute values and tuples as data objects. Hence each attribute A is associated with a classification attribute C in the schema and each attribute value in a tuple is associated with a corresponding security classification. In addition, in some models, a tuple classification attribute TC is added to the relation attributes to provide a classification for each tuple as a whole. Hence, a multilevel relation schema R with n attributes can be represented as

                                               R (A₁, C₁, A₂, C₂……….A_n, C_n, TC)

Where each C_i represents the classification attribute associated with the attribute A_i.

      

Apparent key - The apparent key of a multilevel relation is the set of attributes that would have formed the primary key in a regular (single-level) relation.

Filtering – The process of producing tuples at a lower classification level from a single tuple of a relation stored at a higher classification level.

Polyinstantiation – It is the state at which several tuples can have the same apparent key value but have different attribute values for users at different classification levels.

Consider an e.g.

Employee

Name	Salary	Job Performance	TC
Smith                U    Brown               C	40000                   C 80000                   S	Fair                       S Good                    C	S S

Fig (1)

Assume that the Name attribute is the apparent key. Now consider a select query ‘select * from employee’.

Case 1: A user with security clearance S would see the original relation as it is, i.e.

Name	Salary	Job Performance	TC
Smith                U    Brown               C	40000                   C 80000                   S	Fair                       S Good                    C	S S

Fig (2)

Case 2: A user with security clearance C would see the relation as:

Name	Salary	Job Performance	TC
Smith                U    Brown               C	40000                   C 80000                   C	null                       C Good                    C	C C

                                                                     Fig (3)

Case 3: A user with security clearance U would see the relation as:

Name	Salary	Job Performance	TC
Smith                U	null                      U	null                       U	U

                                                                     Fig (4)

Thus we can see that filtering introduces null values for attribute values whose security classification is higher than the user’s security clearance.

                        The entity integrity rule for multilevel relations state that all attributes that are members of the apparent key must not be null and must have the same security classification within each individual tuple. In addition, all other attribute values in the tuple must have a security classification greater than or equal to the apparent key.

Suppose that a user with security clearance C tries to update the value of ‘JobPerformance’ of Smith to ‘Excellent’; the SQL statement would be

Update employee

Set JobPerformance = ‘Excellent’

Where Name = ‘Smith’

                       Since the view provided to users with security clearance C (Fig. 3) permits such an update, the system should not reject it; otherwise the user could infer that some non null value exists for the ‘JobPerformance’ attribute of Smith rather than the null value that appears. This type of inference should not be permitted in highly secure systems. The solution is to create a polyinstantiation for the Smith tuple at the lower classification level C as shown below:

Name	Salary	Job Performance	TC
Smith                U    Smith                U Brown               C	40000                   C 40000                   C 80000                   S	Fair                       S Excellent              C Good                    C	S C S

This is necessary since the new tuple cannot be filtered from the existing tuple of classification S.

VII. Introduction to Statistical Database Security

Statistical databases are used mainly to produce statistics on various populations. (A population is a set of tuples of a relation that satisfy some selection condition). The database may contain confidential data, which should be protected from user access. However, users are permitted to retrieve statistical information on populations, such as sum, average, maximum, minimum and standard deviation. i.e. statistical database users are not allowed to retrieve individual data but are allowed to access statistical data as a whole. Statistical database security techniques must prohibit the retrieval of individual data. This can be controlled by prohibiting queries that retrieve attribute values and by allowing only queries that involve statistical aggregate functions such as COUNT, SUM, MIN, MAX, AVERAGE and STANDARD DEVIATION. Such queries are called statistical queries.

In some cases it is possible to infer the values of individual tuples from a sequence of statistical queries. As an e.g. consider the two statistical queries:

Q1: select count (*) from person where ;

Q2: select avg (income) from person where ;

Suppose that we are trying to find the salary of ‘Jane Smith’ and we know that she has a PH.D. Degree and she lives in the city of Bellaire, Texas. We issue query Q1 in the following condition: (Last_degree = ‘PH.D.’ and Sex = ‘F’ and City = ‘Bellaire’ and State = ‘Texas’). If we get a result of 1 for this query, we can issue Q2 with the same condition and find the income of ‘Jane Smith’. Even if the result of Q1 on the preceding condition is not 1 but is a small number say 2 or 3, we can issue statistical queries using the functions MAX, MIN and AVERAGE to identify the possible range of values for the income of ‘Jane Smith’.

                  The possibility of inferring individual information from statistical queries is reduced if no statistical queries are permitted whenever the number of tuples in the population specified by the selection condition falls below some threshold. Another technique for prohibiting retrieval of individual information is to prohibit sequences of queries that refer repeatedly to the same population of tuples.

Download