Course 10 7.

DATABASE SECURITY
Database systems affect every persons daily life. They are used in billing systems, subscription services, reservations systems and numerous other aspects of daily life. For these systems, to properly carry out their respective tasks, the database operations must function properly and the information contained within the database must be correct. While the data cannot be guaranteed from accidental changes, it can be protected from malicious system and data attacks. This protection is the subject of this chapter. 7.1 Database Management System Primer To understand the security problems that can plague a database management system (DBMS), a basic knowledge of database systems is required. Two key parts of a database management system are (1) the user defined data (data tables) and (2) the operations defined to manipulate the data. The data tables, often called entities or touples, contain the database information. The tables are composed of constituent characteristics, or attributes. For example, the employee data table in Figure 7.1 has four attributes: employee name, address, phone number, and department. In a similar manner, the department data table in Figure 7.1 consists of three attributes: department name, manager name, and location. EMPLOYEE TABLE
Name Fred Barney Wilma Betty Home address 34 Main Street 628 Stone Avenue 26 Quary Court 157 Lime Road Home phone 555-2548 555-1837 555-2548 555-8643 Departament Testing Sales Testing Design

DEPARTAMENT TABLE Departament Design Payrol Sales Testing Location BLDG. 210 BLDG. 209 BLDG. 236 BLDG. 229 Manager Donald Dasy Micky Minnie

Figure 7.1. Example database tables.

The data contained in tables such as these are manipulated with operations provided by the database management system (DBMS). Manipulation of the data tables is accomplished with operations that add new data, update existing data, delete existing data, and list data with certain attributes. The specific functions that perform these operations depend upon the requirements of the system. For example, a query could request a list of all employees in a given department. Depending on the design and scope of the DBMS, a query such as this may not be possible. In some database environments the actions available to the users are limited. The limitations can either be the result of the environment or a restriction in a user's capabilities. Environmental limitations prevent users from performing actions on data not related to the relevant environment. For example, environmental limitations would prevent a user from modifying his bank records from within an airline reservation system. Unlike environmental limitations, capability limitations restrict the actions a user can perform on relevant data. An example of a capability based limitation would be an airline reservation system that allows the travel agent to change a traveler's reservation but not alter an airplane's flight schedule. Capability based limitations such as these are often implemented with the use of multi-leveled security. Multi-leveled DBMSs attempt to control access to the system with the use of relative security classifications. Commonly used security labels are top-secret, secret, confidential, restricted, and unrestricted. Security classifications such as these are used to determine whether a user can both access data and perform a given database operation. This is accomplished by applying the security classification labels to the system data, operations and users. Users with a security label lower than that of an operation are prevented from performing the operation. Users with a security label lower than that of the data are not permitted to read the data. The ability to write information to the database will depend on the access rules enforced by the system. For a user to manipulate data, the user must have a security label that allows the operation to complete on the requested data and access to the data. For example, a user wishing to read a name from an on-line phone book must have the security classification that allows the user to read information from the phone book. The permission to access information in a given manner, such as reading from, or writing to, a phone book is called a role. Roles are discussed in detail below. 7.2 DBMS Vulnerabilities and Responses DBMSs may suffer from any of four different types of vulnerabilities. These vulnerabilities are: (1) inference, (2) aggregation, (3) data integrity, and (4) Trojan horses. The presence of inference or aggregation vulnerabilities leads to the undesired release of normally secure, or hidden, information contained in the database. Data integrity vulnerabilities undermine the correctness of the information within the database. Trojan horse vulnerabilities allow hidden operations to perform unauthorized actions in, and to, the DBMS. Removing

these vulnerabilities often involves reorganizing the data tables, reclassifying the data, or improving the access controls and general security of the system. 7.2.1 Inference Inference vulnerabilities in a DBMS allow a user to deduce the contents of inaccessible parts of a database. For example, a database system indicates that a certain jet fighter with a maximum payload of 400 Kg will be flying a mission where it will carry a certain type of bomb. The database system, however, does not state how many of the bombs will be carried. Since it is general knowledge that each of the bombs weighs 50 Kg, it can be inferred that the fighter will carry 8 bombs. This example shows how common sense knowledge may be used to deduce the contents of the database. Inference vulnerabilities, however, may be made with the assistance of not just common sense, but other data within the database or external information. The fact that information used to make inferences comes from uncontrollable sources hinders (mpiedic) the protection required to prevent inference attacks. Properly protecting a DBMS from inference attacks is a difficult task. This is because attackers do not need to perform any overtly (fi) malicious actions to determine the contents of the database and an attacker's presence and activities may go unnoticed. To determine what can be inferred from the system and create an optimal defense, a knowledge of an attackers source of information is required. Since this knowledge is often unattainable, the DBMS must be maintained such that external knowledge provides little assistance to the attacker. Modifying a database so that little can be inferred first requires identifying the information that must be protected and then adjusting the security classification of the data, the appropriate data relations, and operations. Naturally, this is an application specific solution and modifications such as these must be made on a case by case basis. 7.2.2 Aggregation Like inference, the damages that results from aggregation are only information dissemination, not database modification. Aggregation is the process of combining multiple database objects into one object with a higher security label than the constituent parts. Combining two objects of similar types, such as two addresses, is called inference aggregation. When the combined objects are of different types, such as a name and salary, the process is called cardinal aggregation. While the two types of aggregation are similar in nature, they each require different means of prevention. 7.2.2.1 Inference Aggregation As previously mentioned, inference aggregation is the result of combining the knowledge gained from multiple database objects. For example, knowing the information contained in any one of the tables in Figure 7.2 provides little information by itself. Knowing the contents of all three tables, however, results in

the dissemination of what would otherwise be considered hidden, or private, information. Inference aggregation can be prevented, by raising the security labels associated with any one or more of the tables involved in the aggregation. For example, raising the security label of any single table in Figure 7.2 prevents an authorized user from aggregating the data. This results in requiring a DBMS user to have a higher security label to make the aggregation inference. Raising the security labels of the DBMS tables, however, may result in reducing the operations available to users with lower security labels. The information in a newly labeled data table will no longer be available to lower labeled users who require access. These side effects can be reduce by relabeling only the less frequently used data tables. PHONE BOOK TABLE
Name Fred Barney Wilma Betty Mail 229-234 236-652 229-176 210-235 Phone 3-1234 6-8733 3-2938 5-9054 Departament Testing Sales Testing Design

EMPLOYEE TABLE
Name Fred Barney Wilma Betty Employee number 143324 135631 114356 113542 Home address 34 Main Street 628 Stone Avenue 26 Quary Court 157 Lime Road Home phone 555-2548 555-1837 555-2548 555-8643

SALARY TABLE
Employee number Salary 143324 135631 114356 113542 82,200 45,400 66,100 52,100 Retirement fund 44,000 22,100 33,870 10,790

Figure 7.2. Example of Inference Aggregation 7.2.2.2 Cardinal Aggregation Cardinal aggregation is the combining of like information in a manner that yields information not readily available or apparent to a user. Commonly used

example of cardinal aggregation is a phone book. One phone number provides little information besides a name and phone number. A complete phone book, however, can provide information no single phone number can. It is unusual for dissimilar businesses to share a phone number. If a phone book were examined, and a list created of all businesses that share a single phone number, it could be inferred that the listed businesses may be either store-fronts or involved in unusual business practices. Another common example concerns military troop placement information. It may be of little value to know the location of one army troop. Knowing the location of every troop in the army, however, will be of significantly more value. This type of aggregation, unlike inference aggregation, is difficult to prevent. Two generally accepted solutions are to: (1) lower the security label assigned to the data and restrict access and (2) raise the security label assigned to the individual data so that it equals that which can be aggregated. Unfortunately, neither of these solutions provides a complete solution to the problem. The first means of preventing aggregation is the downgrading of information labels and restriction of access. This solution requires knowledge of both how the data can be exploited and the amount of data necessary to perform an accurate aggregation. It may be difficult, however, to determine, the minimal number of touples needed to provide additional information by aggregation. Furthermore, attempting to limit the amount of data any user may access at any one time does not resolve the problem as a user may make multiple, smaller database accesses and build a complete database. For example, if a user is limited to requesting only 10 entries from a phone book at one time, the user need only make numerous 10 entry requests until the desired aggregation effect is possible. Clearly this solution does not completely prevent cardinal aggregation, rather it slows down the process by requiring a user to apply more effort to obtain the necessary data for aggregation. The second cardinal aggregation solution is to raise the security label of each individual data record. Again using the phone book example, each name and phone number would be given a security label equal to that of the aggregated information. Thus, the information gained through aggregation is readily available to a user without aggregation. This solution, however, has two complications. First, it artificially inflates the security labels of the DBMS information. This is evident by the higher security label a user would need to access a phone number in the example above. Second, the highest security level of all possible aggregations must be determined so that the appropriate label can be applied to the data. This requires the ability to determine every possible aggregation from the data so that the proper label can be determined and applied. Determining every possible aggregation is often impossible, making it difficult to guarantee that the appropriate security label is applied. Unlike inference aggregation, there is no perfect solution to cardinal aggregation.

With each solution comes unwanted side effects that make interaction with the database difficult. While some mechanism should be in place to reduce the possibility of aggregation, the security administrator should be aware that any protection will be incomplete. 7.2.3 Data Integrity Data integrity vulnerabilities allow the unauthorized or inappropriate modification, addition, or deletion of database information. Data integrity vulnerabilities can be prevented with the implementation of an integrity policy. Many policies have been proposed, some of these policies include the BellLaPadula policy, the Biba policy and the Schell-Denning strict integrity policy. The basic concept behind these policies, and others, is the same: reduce the privileges any user has at any given time and group related DBMS privileges. The goal of privilege reduction is to limit the operations that any one user has at any given time. For example, it is unnecessary to give a technician and personnel manager the same DBMS capabilities. A technician need not be able to add new employees or change an employee's personal data. Likewise a personnel manager does not need the ability to modify any technical information. Therefore, DBMSs employ privilege reduction; they only grant each employee access to the data and operations that are required for an employee to perform their job. Privilege reduction is not limited to one dependency. That is, the privileges granted to a user may depend not just upon his department, but upon his current task as well. For example, one personnel employee may only be able to add employees while another personnel employee may only be able to adjust the position and salary of an employee. This is shown in Figure 7.3. It should also be noted that more than one user may be assigned the same privileges; many users often have the same privileges. For this and other security reasons, DBMSs often employ a means of grouping related privileges called roles.

Figure 7.3. An example of user privilege mapping. Grouping related DBMS privileges into a single representation (a role) allows system administrators to better control and represent the activities permissible by a user. By creating roles that represent the activities of the different types of users, the DBMS can more clearly and accurately delineate the

functions available to a user. For example a personnel department worker can be assigned the corresponding role as opposed to listing each privilege individually. Since the reduced amount of authorized privilege combinations are represented by roles, the unauthorized addition of privileges to a user account becomes more noticeable. Furthermore, the use of roles allows a database administrator to adjust multiple user privileges by adjusting a single role. Figure 7.4, below, shows a role based representation of the information in Figure 7.3.

Figure 7.4. An example of role based access control 7.2.4 Trojan Horses A Trojan horse is a program that performs a task that a user does not expect and does not want completed. The name, Trojan horse, stems from the concept that the real functionality of the program is hidden from a user, only rarely making its true purpose apparent after its execution. Trojan horses either modify the database, modify security labels, or modify user roles. For example, a user may execute a DBMS command that creates a backup of a confidential database, that has been altered to make a second copy available for every user to examine. In this example, the backup process functions properly, but the user is unaware of the activity of the Trojan horse. While Trojan horse programs may go unnoticed to the casual DBMS user, they are preventable. The nature of Trojan horse programs lends itself to prevention and possibly detection. Because their presence in a DBMS is an abnormality, they can often be found. This is accomplished by searching for the unusual activity and side effects of a Trojan horse. Searching transaction logs for unusual activity or searching for unexplainable function modifications will often identify the presence of a Trojan horse. This may not be enough, however, as they may have performed their intended task before they are noticed. Nonetheless, a system

should take a few preventative measures. These measures are (1) restrict users from introducing additional functionality to the system and (2) frequent examination of existing system operations. Prohibiting users from adding functionality to the system will prevent the introduction of a Trojan horse. In the event that users cannot or are not prevented from modifying the DBMS, frequent examination of the database operations may locate modified and unauthorized operations.