Database Security Essay Example

advanced techniques such as badge readers, biometric recognition, and signature analysis devices are also available.
- Authorization and Access Controls: Authorization involves defining rules that determine which individuals have access to specific information. The disclosure and modification of information are governed by authorization policies. Access controls are procedures designed to manage authorizations.

They have the responsibility to restrict access to stored data to authorized users exclusively. · Integrity and consistency are ensured through an integrity policy, which consists of a set of rules (i.e. semantic integrity constraints) that establish the correct states of the database during database operation. Consequently, this policy can prevent malicious or accidental alteration of information. Concurrency control and recovery are closely linked issues to integrity and consistency.

Concurrency control policies protect the integrity of the database in the presence of concurrent transactions. If these transactions do not terminate normally due to system crashes or security violations, recovery techniques are used to reconstruct correct or valid database states. Auditing, on the other hand, refers to the requirement to keep records of all security-relevant actions issued by a user. These audit records serve as the basis for further reviews and examinations to test the adequacy of system controls and recommend any changes in the security policy. However, this chapter does not take such a broad perspective of database security.

The main focus is on authorization and access controls, rather than identification, authentication, and auditing. This is because those aspects typically fall under the operating system's scope, and integrity and consistency policies are related to semantic data modeling or dependent on the DBMS software's physical design (such as the transaction and recovery manager). While relational databases are primarily

discussed in this chapter, the results can generally apply to other database models. For a comprehensive discussion on basic database security concepts, refer to surveys by Jajodia and Sandhu (1990a), Lunt and Fernandez (1990), or Denning (1988). Additionally, consult the annotated bibliography by Pernul and Luef (1992) for further readings. The chapter outline is as follows: a brief review of the relational data model, introduction of a recurring example, explanation of computer security terminology, and description of successful methods used to breach databases. Given the diversity of application domains, different security models and techniques exist.

However, there have been four proposals for storing and examining audit records using DBMS software. In Section 2, we review, evaluate, and compare the most prominent representatives among them. Section 3 investigates secure (trusted) database management systems (DBMSs). These systems are designed for supporting a level-based security policy and prioritize enforcing high security requirements. Section 4 focuses on one of the major problems of level-based security in database research. In this section, we address the problem of properly classifying the data stored in the database with security classifications that accurately reflect the security requirements of the application domain.

To effectively address this issue, it is essential to possess a comprehensive comprehension of the security semantics associated with the database application and devise a clever database design. We propose a semantic data/security model that enables the conceptualization and clear understanding of the database application's security semantics. Multiple national and international standardization efforts are being undertaken to enhance database security (and computer security in general). These efforts aim to establish metrics for assessing the level of trustworthiness of computer products utilized for processing sensitive

information. In Section 5, we will provide a brief overview of these proposals, while Section 6 will identify research challenges within the domain of database security and present our perspective on the anticipated trajectory of the entire field in the coming years.

Finally, Section 7 will conclude this Chapter. The Relational Data Model Revisited. The relational data model was invented by Codd (1970) and is described in most database textbooks. A relational database supports the relational data model and must have three basic principles: a set of relations, integrity rules, and a set of relational operators. Each relation consists of a state-invariant relation schema RS(A1,... ,An), where each Ai is called attribute and defined over a domain dom(Ai). A relation R is a state-dependent instance of RS and consists of a set of distinct tuples of the form (a1,...

,an), where each element ai must satisfy dom(Ai) (I. e. aiIdom(Ai)). Integrity constraints restrict the set of theoretically possible tuples (i. e.

The set of practically meaningful attributes, denoted as dom(A1) ? dom(A2) ? ... ? dom(An)), is used in relation to X and Y, which represent sets of one or more attributes Ai in a schema. If X®Y, it means that it is impossible to have two tuples with the same value for X but different values for Y.

Functional dependencies are essential for ensuring data integrity in the relational data model. They determine which integrity constraints are applicable to a given relation. Out of the many proposed integrity constraints, two have particular significance for security: the key property and referential integrity.

The key property requires that each tuple in a relation is uniquely identified by a key, and that

the key attribute cannot have a null value. This ensures that each event in reality is represented in the database only once.

Referential integrity, on the other hand, states that tuples referenced in one relation must exist in others. This constraint is expressed using foreign keys.

The two rules mentioned in the text are universal and must be upheld in all relational databases. Additionally, there may be specific semantic constraints that vary between different databases. Views, which are the result of relational operations, are different from base relations. Views exist virtually, while base relations actually hold the stored data in the database. Relational operations include set operations, a select operation to choose tuples that meet a specified predicate, a project operation to choose a subset of attributes from a relation, and a join operation to combine attributes and tuples from different relations. The IBM implementation of the relational data model, known as System R, and the INGRES implementation at U.C., were the first to be developed.

Berkeley and the two projects it initiated have significantly advanced the field of database security research. These systems serve as the foundation for many commercially available products. Designing a database is a complex process that consists of multiple phases and activities. It is essential to carry out a thorough requirements analysis and conceptualization of the database before determining the final relation schemas.

Typically, this is accomplished by using a conceptual data model, which must be sufficiently powerful to represent all application-related knowledge. The conceptual model serves as an intermediary representation of the database and is ultimately converted into corresponding relation schemas. It is crucial to employ a conceptual data model at this

stage because only such a high-level model can accurately depict all of the data semantics specific to the application. The Entity Relationship Approach (ER) (Chen, 1976) or one of its variations is widely considered the de facto standard for conceptual design. In its simplest form, the ER views the world as comprising entity types (represented by boxes), attributes (linked to boxes), and relationship types (represented by diamonds). Relationship types are established between entity types and can be either <1:1>, <1:n>, or . The degree indicates the maximum number of participating entities.

Below is a short example of a relational database. This example will be referred to throughout the Chapter. It is a simple yet adequate example for discussing many security-related questions and showcasing the complexity of the field.

Figure 1 shows the conceptualization of the database in the form of an ER diagram, along with the corresponding relation schemas. Key attributes are underlined, and foreign keys are in italics. The database reflects the fact that projects within an enterprise are carried out by employees. In this example, there are three security objects to consider: Employee, which represents a group of employees, each uniquely identified by an SSN (I).

The text discusses two important aspects: employees and projects.
For employees, the important information includes their name, department, salary, and social security number.
Regarding projects, each project has a title, subject, and client.

The Assignment security object covers the allocation of employees to projects. Each assignment includes the Date and Function of an employee's involvement in the project. An employee can be assigned to multiple projects, and a project can involve multiple employees.
Furthermore, before discussing database security research details, it is

crucial to establish security-related vocabulary and comprehend major threats that may jeopardize database security. As mentioned earlier, security requirements are conveyed through a security policy consisting of regulations, principles, and protocols governing how an organization handles, protects, and shares confidential information.

A security policy is typically defined in terms of a collection of security objects and subjects. A security object can be either structured or unstructured, representing a passive entity that contains or receives information. Examples of structured concepts include databases, relations, views, tuples, attributes, attribute values, and factual representations in the database. Unstructured examples include physical memory segments, bytes, bits, printers, and processors. It should be noted that the term "object" may have different definitions in other computer science domains.

Within this framework, the focus of protection is on security objects. A security subject, typically a person (user) or a process acting on behalf of a user, is an active entity. Security subjects are responsible for altering the state of a database and facilitating the movement of information between various objects and subjects. The majority of threats to database security originate from sources external to the computing system.

When focusing on authorization, it is important to implement security controls to oversee the actions of users and the processes they carry out on behalf of the users. Within the system, an active database process can operate from the authority of an authorized user with legitimate access, but it can also operate on behalf of a person who has managed to infiltrate the system. Furthermore, an authorized user of the database can unknowingly or intentionally become a conduit for restricted information to flow to unauthorized users. Database penetration methods

that have proven to be particularly successful include misusing authority, improperly acquiring resources, stealing programs or storage media, and modifying or destroying data. Logical inference and aggregation also concern users who are authorized to use the database.

Logical inference occurs when sensitive information can be deduced from combining less sensitive data, potentially including knowledge external to the database system. This is closely linked to the aggregation problem, where individual data items are not considered sensitive, but a sufficiently large collection of these values is deemed sensitive. · Masquerade: A penetration tester could gain unauthorized access by pretending to be someone else. · Bypassing Controls: This could involve password attacks and the exploitation of system trapdoors that bypass intended access control mechanisms. Trapdoors refer to security vulnerabilities intentionally built into the program's source code by the original programmer.

· Browsing A penetrator bypasses the security measures and searches for directory or dictionary information in an attempt to find privileged data. If strict need-to-know access controls are not put in place, browsing poses a significant vulnerability to database security.

· Trojan Horses A Trojan horse refers to concealed software that deceives a legitimate user, unbeknownst to them, into performing certain actions. For instance, a Trojan Horse might be disguised as a sorting routine and programmed to disclose specific data to unauthorized individuals. Whenever a user activates the sorting routine, such as when sorting the results of a database query, the Trojan horse will operate under the user's identity, granting it all of the user's privileges.

Covert Channels are typically used to retrieve information stored in a database. Unlike legitimate channels, covert channels are hidden paths that are not

intended for information transfer. These paths can be storage channels such as shared memory or temporary files, which can be used for communication, or timing channels that result in a degradation of the system's overall performance.

Hardware and Media Attacks involve physical attacks on equipment and storage media. The attack scenario mentioned above is not limited to databases; it can occur in other systems as well.

The German Chaos Computer Club successfully attacked a NASA system by bypassing access controls and using Trojan horses to capture passwords (Stoll, 1988). Some of these techniques were also employed by the Wily Hacker. In 1988, the Internet worm exploited trapdoors in electronic mail handling systems and infected over 5000 machines on the Internet network (Rochlis and Eichin, 1989). In his Turing Award Lecture, Thompson (1984) demonstrated a Trojan horse placed in the executable form of a compiler, allowing the insertion of a trapdoor in every program compiled with that compiler.

It is generally accepted that the number of reported cases of computer abuse is much lower than the actual number of occurrences due to a large number of unreported incidents in this area. Additionally, different security models and techniques have been proposed to address the various threats to database security, given the diverse application domains for databases. In this section, we will focus on the most prominent models. In summary, Discretionary Security establishes rules that allow subjects to create and delete objects, as well as grant and revoke access authorizations, at their own discretion.

In addition to access control, Mandatory Security also regulates the information flow between objects and subjects. Although effective, mandatory security controls have drawbacks. To address these limitations, the

Adapted Mandatory Access Control (AMAC) model focuses on secure database design. The Personal Knowledge Approach emphasizes the informational self-determination of humans, in accordance with the laws of many countries. Meanwhile, the Clark and Wilson Model aims to represent computerized security models based on common commercial business practices.

First attempts to compare some of these techniques have been made by Biskup (1990) and Pernul and Tjoa (1992). Landwehr (1981) is a very good survey of formal policies for computer security in general and Millen (1989) focuses on various aspects of mandatory computer security. 2. 1 Discretionary Security Models Discretionary security models are fundamental to operating systems and DBMSs and have now been studied for a long time. From 1970 through 1975, there was a significant interest in the theoretical aspects of these models. Then, most of the relational database security research has turned to other security techniques.

However, the emergence of more sophisticated data models has sparked a renewed fascination with discretionary policies. Discretionary access controls (DAC) are founded on the notions of security objects O, security subjects S, access privileges T, which determine the specific kind of access a subject has to an object, and predicates P to represent content-based access rules.

When applied to relational databases, the letter O represents a finite set of values {o1,... ,on} that represents relation schemas. The letter S is also a finite set, but represents potential subjects {s1,... sm} which could be users, groups of users, or transactions operating on behalf of users. The access types, or privileges, are the set of database operations such as select, insert, delete, update, execute, grant, or revoke. The predicate pIP defines the access window

of subject sIS on object oIO.

The access rule tuple <o,s,t,p> is used to determine if an authorization f(o,s,t,p) is valid or not: O ? S ? T ? P ® {True, False}. If f(o,s,t,p) evaluates to True, subject s is authorized to access object o within the range defined by predicate p. Discretionary security models support delegation of rights, where a subject si can delegate the right (o,t,p) to another subject sj (i? j). DAC systems store access rules in an access control matrix, where the rows represent subjects, the columns represent objects, and the intersection of a row and column contains the access type that subject has authorization for with respect to the object.

The access matrix model, which is the foundation for discretionary access controls, was initially developed by Lampson (1971) and later improved by Graham and Denning (1972), as well as by Harrison et al. (1976). For a more extensive examination of discretionary controls in databases, Fernandez et al. (1981) provide a comprehensive discussion in their book. Discretionary security, which relies on the notion of database views, is implemented in the majority of commercial DBMS products.

Instead of granting a user access to all the base relations of a system, the access control matrix is used to limit their access to specific subsets of the available data. There are two main system architectures for view-based protection: query modification and view relations. Query modification is used in DBMSs like Ingres (Stonebraker and Rubinstein 1976), and involves adding additional security qualifiers to a user's query. View relations, on the other hand, are virtual queries based on physical base relations. Instead of accessing the base relations directly,

users are only given access to these virtual view relations. Security restrictions can be implemented by specifying qualifiers in the view definition.

The protection mechanism of System R-based DBMSs, known as view relations, was introduced by Griffiths and Wade in 1976. However, discretionary models, which are widely used, have limitations when applied to databases with security critical content. One major drawback is the enforcement of the security policy. Discretionary Access Control (DAC) is based on the concept of ownership of information. Unlike enterprise models where the entire enterprise is responsible for granting access to stored data, DAC systems assign ownership to the creator of the data items in the database, allowing them to grant access to other users. This means that enforcing security requirements falls on the users themselves and cannot be controlled by the enterprise without incurring high costs. Another limitation is cascading authorization, where multiple subjects have the privilege to grant or revoke access rules for other subjects. This can result in cascading revocation chains.

Consider the example where there are subjects s1, s2, s3, and an access rule (s1,o,t,p). Subject s2 receives privilege (o,t,p) from s1 and grants this access rule to s3. Later, s1 grants (o,t,p) again to s3, but s2 revokes (o,t,p) from s3 for some reason. The result of these operations is that s3 still has authorization (from s1) to access object o by satisfying predicate p and using privilege t, even if s2 has revoked it. This means that s2 is unaware that authorization (s3,o,t,p) is still in effect. In systems supporting DAC, the identity of the subjects is important. If actions can be performed using another subject's identity, then

DAC can be undermined. A Trojan Horse can be used to grant a certain right (o,t,p) of subject si onto sj (i?j) without the knowledge of subject si. Any program running on behalf of a subject acts with the identity of that subject and therefore has all the DAC access rights of the subject's processes.

Discretionary access control methods cannot restrict a program's Trojan Horse from granting access rules to other users. However, view-based protection in an update problem can handle unmaterialized queries that have no explicit physical representation in the database. This flexibility supports different views for subjects and automatically filters unauthorized data. Yet, certain views may not be able to update all data due to integrity reasons. Mandatory policies have a higher level of threat control compared to discretionary policies, as they not only control data access but also data flow. Additionally, mandatory security techniques overcome the limitations of DAC-based protection described earlier.

While discretionary models focus on defining, modeling, and enforcing access to information, mandatory security models also address the flow of information within a system. Mandatory security necessitates assigning security objects and subjects to specific security levels denoted by labels. An object o's label is known as its classification (class(o)), while a subject s's label is referred to as its clearance (clear(s)). The classification denotes the sensitivity of the labeled data, while the clearance of a subject represents their trustworthiness in keeping sensitive information confidential. A security label comprises two components: a level from a hierarchical list of sensitivity levels or access classes (e.g., top_secret > secret > confidential > unclassified) and a member of a non-hierarchical set of categories representing classes of

object types in the universe of discourse. Clearance and classification levels possess a total order, resulting in partially ordered security labels. Consequently, the set of classifications forms a lattice. In this lattice, security class c1 is comparable to and dominates c2 if the sensitivity level of c1 is greater than or equal to that of c2, and the categories in c1 contain those in c2.

The concept of mandatory security originated in the military, where information labeling is common practice. However, this practice is also prevalent in many companies and organizations, utilizing labels such as 'confidential' or 'company confidential'. It is important to clarify the role of MAC policies in mandatory systems. While there has been confusion surrounding the need for strong controls over data access in these systems, it is essential to have comparable controls over who can modify the data. This is necessary because high-security systems must defend against unauthorized access and potential threats from both authorized and unauthorized users. Authorized users have the potential to disclose sensitive information through various means.