DATA SECURITY
Data security is about protecting the database against unauthorised users. This is to maintain privacy, to ensure that data is not seen by those who are not entitled to see it, and also to ensure that data is not wilfully corrupted.
There should be an enterprise-wide data security policy in place. This policy should specify the degree of security protection to be applied to the different categories of data in the enterprise and who should have access to what data. The policy should be clear and concise so that all involved in the management of data can easily understand their role in the maintenance of the security of that data.
The policy is then enforced through the use of the security mechanisms provided both by the operating systems and the database management systems in use in the enterprise’s information systems. The data security mechanisms available include access controls and encryption. Additionally, audit trails may be put in place to track who did what in the event of a breach of security.
Access controls
Most users only need access to a subset of the available data to carry out their duties. They should, therefore, have authorised access to that data and be prevented from accessing the rest of the data. This is where access controls come in.
Access controls rely on authentication procedures such as logins and associated passwords. Groups of data access rights are then granted to individuals, or to groups of individuals with the same or similar roles, based on their logins.
The aim of access control is to ensure that database users can only create, read, update or delete data relevant to their role. One of the functions of the database management system is to provide the facilities to enable this to be achieved. For example, SQL has a subset of the language that is the data control language (DCL) in addition to the data definition language (DDL), the part of SQL that allows for the creation of tables and the various constraints, and the data manipulation language (DML), which allows data to read, inserted, updated or deleted. Access to data or any database object (table, procedure, etc.) is restricted to the creator of the object, usually the database administrator. The creator of an object becomes its owner. No other users can access an object, say to read or update the data, unless privileges associated with that object have been given to that user. The data control statements in SQL allow for the granting and of revoking these privileges, which fall into three groups:
table privileges;
function and procedure privileges;
database object privileges.
Table privileges allow the user to access specific base tables and views (the SQL name for virtual tables) and, maybe, specific columns within those tables. The privileges may be to SELECT (i.e. read) data, to INSERT (i.e. create) data, to UPDATE data or to DELETE data. There is an additional ‘privilege’, ALL PRIVILEGES, that allows the user to create, read, update and delete data. The SELECT, INSERT and UPDATE privileges can apply either to whole tables or to specific columns; the DELETE privilege can only apply to whole tables, that is only whole rows can be deleted. Typical table privilege statements are shown in Figure 8.1.
FIGURE 8.1 Table privilege statements
Function and procedure privileges allow users to execute stored SQL-invoked routines. These are routines that may be written in SQL (using the syntax for functions and procedures) and with the program code stored as part of the logical schema. Alternatively they may be written in some other programming language, such as C, with their definition stored as part of the logical schema. The privilege statement in Figure 8.2 allows the human resources department to execute a function that calculates the current age of an employee.
FIGURE 8.2 A function privilege statement
Database object privileges control which users can create or alter database structures. These privileges are not part of the SQL standard but are provided by some vendors of database management systems. These privileges are normally reserved for database administrators. In fact, if these privileges are not restricted to database administrators it will be almost impossible to have enterprise-wide management of data. The privilege statement in Figure 8.3 allows the human resources department to create tables within their database.
FIGURE 8.3 A database object privilege statement
All of these privileges may also be granted to all users by using the pseudo authorisation identifier PUBLIC.
Another way that access to data can be controlled is through the use of virtual tables or views. This becomes extremely powerful when combined with access controls. For example, instead of providing department heads with SELECT access to the payroll_number, surname and salary columns of the employee table it is possible to create an appropriate view for that data and grant access to that view, as shown in Figure 8.4.
FIGURE 8.4 A view statement and an associated table privilege statement
Another example of the use of views is to restrict access to data for a particular user, for example, so that an employee can see their own employee record but no others. This can be achieved as shown in Figure 8.5 (assuming that a user’s authorisation identifier is their payroll number).
FIGURE 8.5 A user-specific view statement and an associated table privilege statement
Discretionary and mandatory access controls
There are two levels of access control:
Discretionary Access Control(DAC) is where the users who are granted access rights are allowed to propagate those rights to other users.
Mandatory Access Control (MAC) is where access rights cannot be changed by the users.
The access control mechanisms described above, including their use with views, provide Discretionary Access Control. The privileges may be granted and revoked, and once given privileges and the authority to grant them onwards, there is no limit to their propagation amongst users. Under Discretionary Access Control, a user could accidentally or maliciously provide access to create, read, update or delete data to unauthorised users. Consequently, Discretionary Access Control provides a very low-level of data security, yet the use of views and the granting and revoking of privileges are the most common data security mechanisms in use.
Mandatory Access Control needs to be applied where an environment with trusted security is needed. In Discretionary Access Control, the user (which may be the database administrator) who created an object can grant access rights to other users. In Mandatory Access Control, the access rights are set by the security administrator and are not under the control of the users.
A popular model used in Mandatory Access Control is the Bell–LaPadula Model, developed by David Bell and Len LaPadula for the US Department of Defense. Consider a situation where the organisation holds data at three security levels, secret, confidential and public, so that secret is the most sensitive and public is the least sensitive; that is, secret is more sensitive than confidential and confidential is more sensitive than public. Objects in the database are given a security label – one of the specified security levels, secret, confidential, public. That is the level at which the object is classified. Each user or role (known as a subject in the Bell–LaPadula Model) is given a security clearance – again, one of the specified security levels, secret, confidential, public. This is the highest level of classification that the subject can access. The model then imposes two restrictions on access to data, as follows:
A subject with a clearance at a given level of classification may not read a database object or data labelled at a higher classification level; that is, there is ‘no read up’.
A subject with a clearance at a given level of classification must not write to any database object labelled at a lower classification level; that is, there is ‘no write-down’.
With this model, therefore, users can only view data at or below their own security level; confidential users can view confidential or public data, but may not view secret data. On the other hand, users can only create data at or above their own security level; confidential users can create confidential or secret data but may not create public data. This second restriction prevents a user from accidentally or maliciously writing highly classified data, say secret data, to a table that is of a lower, say public, classification, which would then be available to subjects with a lower clearance.
Multilevel security
Using a model such as the Bell–LaPadula Model, Mandatory Access Control could be applied to a complete database. For example, all data within the database can be considered as being secret (even though some, probably most, of it should realistically be of a lower classification) and the control is then applied via the operating system. Only subjects with appropriate clearance are allowed access to the database. Applying multilevel security to the whole database in this way is often known as ‘ system high’. A far greater degree of security can be achieved through the use of multilevel security within the database. This is achieved by applying security labels to database objects, tables, columns, etc, and to the data itself. In the case of the data, a security label is applied to each row, so all data in that row is at the same classification level.
One of the implications of the application of multilevel security to database objects and data is that two users (or one user with two different roles, each having a different clearance) may get different answers to the same query applied to the same set of data. Consider a table with 1000 rows of data, where 50 rows are labelled as having a secret classification, 100 rows are labelled as having a confidential classification and the remaining rows are labelled as having a public classification. A general query on that table returns 850 rows of data for a subject with a public clearance, 950 rows of data for a subject with a confidential clearance and all 1000 rows for a subject with a secret clearance. The subject with only public clearance is not told that they are denied access to 150 rows; the database management system responds as if there are only 850 rows in the table. Problems can arise when only some of the data in a secret or confidential row should be labelled at that higher level, and most of the data in the row should really be labelled as public. The user with public clearance is then denied access to data that only warrants a public label and should, therefore, be available to them. In the worst case, if they believe that some data about ‘x’ should be available to them but they do not see that data they may infer that there is some other data about ‘x’ that is of a higher classification and this may, of itself, be a breach of security. For this reason, the design of a database where multilevel security is to be implemented requires considerably more care than for a ‘system high’ or unclassified database. At one time, a major database management system vendor was publicly saying that the design of a multilevel secure database would cost 14 times the cost of a standard database. I am not aware that these figures were ever verified through surveys or controlled studies, but they do provide an indication of the extra care that needs to be taken when designing a database with internal multilevel security.
Encryption
The access controls discussed above are applied by the database management system, but it is possible to use the operating and file-management systems to directly access the data files, thus bypassing the database management system and its security controls. Generally, the average user cannot make sense of these files – the information held within them is of a proprietary format designed by the database management system vendor. However, there are two ways that the data in these files could be compromised. A copy could be taken of the files and then used with another instance of the database management system software to access the files. Under these circumstances, the only danger is that the data is read by someone unauthorised to do so. Alternatively, a determined ‘hacker’ with the right knowledge could access these files in situ without going through the database management system. In this case, the ‘hacker’ could corrupt the data as well as reading it.
To prevent either of these situations, the database could be encrypted. Either the whole database could be encrypted or the encryption could be applied to just some of the data. The encryption of the whole database is the simplest option, but it affects the overall database performance; the database needs to be unencrypted every time some data needs to be read and re-encrypted every time some data is updated. The alternative is to only encrypt data in columns that need encrypting, such as columns holding credit card details. Some database management systems come with a built in ability to encrypt some or all of the data; others provide encryption as an extra module. There are also stand-alone database encryption software products available from third-party vendors.
Audit trails
Most database management systems include facilities to maintain audit trails of database operations, recording what database objects were accessed by whom and when. Some even allow the audit trail to record what data was changed. Audit trails do not prevent unauthorised access, but they do provide information that allows security breaches to be detected. As such they help to promote data security.