Database security


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Database security

  1. 1. -1- Database Security *) GÜNTHER PERNUL Institut für Angewandte Informatik und Informationssysteme Abteilung für Information Engineering Universität Wien Vienna, Austria 1. Introduction 1.1 The Relational Data Model Revisited 1.2 The Vocabulary of Security and Major DB Security Threats 2. Database Security Models 2.1 Discretionary Security Models 2.2 Mandatory Security Models 2.3 Adapted Mandatory Access Control Model 2.4 Personal Knowledge Approach 2.5 Clark and Wilson Model 2.6 A Final Note on Database Security Models 3. Multilevel Secure Prototypes and Systems 3.1 SeaView 3.2 Lock Data Views 3.3 ASD_Views 4. Conceptual Data Model for Multilevel Security 4.1 Concepts of Security Semantics 4.2 Classification Constraints 4.3 Consistency and Conflict Management 4.4 Modeling the Example Application 5. Standardization and Evaluation Efforts 6. Future Directions in Database Security Research 7. Conclusions References 1. Introduction Information stored in databases is often considered as a valuable andimportant corporate resource. Many organizations have become so dependenton the proper functioning of their systems that a disruption of service or aleakage of stored information may cause outcomes ranging from inconvenienceto catastrophe. Corporate data may relate to financial records, others may beessential for the successful operation of an organization, may represent trade*)Advances in Computers, Vol. 38. M. C. Yovits (Ed.), Academic Press, 1994,pp. 1 - 74.
  2. 2. -2-secrets, or may describe information about persons whose privacy must beprotected. Thus, the general concept of database security is very broad andentails such things as moral and ethical issues imposed by public and society,legal issues where control is legislated over the collection and disclosure ofstored information, or more technical issues such as how to protect the storedinformation from loss or unauthorized access, destruction, use, modification, ordisclosure. More generally speaking, database security is concerned with ensuring thesecrecy, integrity, and availability of data stored in a database. To define theterms, secrecy denotes the protection of information from unauthorizeddisclosure either by direct retrieval or by indirect logical inference. In addition,secrecy must deal with the possibility that information may also be disclosedby legitimated users acting as an ‘information channel’ by passing secretinformation to unauthorized users. This may be done intentionally or withoutknowledge of the authorized user. Integrity requires data to be protected frommalicious or accidental modification, including the insertion of false data, thecontamination of data, and the destruction of data. Integrity constraints arerules that define the correct states of a database and thus can protect thecorrectness of the database during operation. Availability is the characteristicthat ensures data being available to authorized users when they need them.Availability includes the ‘denial of service’ of a system, i. e. a system is notfunctioning in accordance with its intended purpose. Availability is closelyrelated to integrity because ‘denial of service’ may be caused by unauthorizeddestruction, modification, or delay of service as well. Database security cannot be seen as an isolated problem because it iseffected by other components of a computerized system as well. The securityrequirements of a system are specified by means of a security policy which isthen enforced by various security mechanisms. For databases, requirements onthe security can be classified into the following categories:• Identification, Authentication Usually before getting access to a database each user has to identify himself to the computer system. Authentication is the way to verify the identity of a user at log-on time. Most common authentication methods are passwords but more advanced techniques like badge readers, biometric recognition techniques, or signature analysis devices are also available.• Authorization, Access Controls Authorization is the specification of a set of rules that specify who has which type of access to what information. Authorization policies therefore govern the disclosure and modification of information. Access controls are
  3. 3. -3- procedures that are designed to control authorizations. They are responsible to limit access to stored data to authorized users only.• Integrity, Consistency An integrity policy states a set of rules (i. e. semantic integrity constraints) that define the correct states of the database during database operation and therefore can protect against malicious or accidental modification of information. Closely related issues to integrity and consistency are concurrency control and recovery. 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 The requirement to keep records of all security relevant actions issued by a user is called auditing. Resulting audit records are the basis for further reviews and examinations in order to test the adequacy of system controls and to recommend any changes in the security policy. In this Chapter such a broad perspective of database security is not taken.Instead, main focus is directed towards aspects related to authorization andaccess controls. This is legitimate because identification, authentication, andauditing1 normally fall within the scope of the underlying operating system andintegrity and consistency policies are subject to the closely related topic of‘semantic data modeling’ or are dependent on the physical design of the DBMSsoftware (namely, the transaction and recovery manager). Because most of theresearch in database security has concentrated on the relational data model, thediscussion in this Chapter mostly concerns the framework of relationaldatabases. However, the results described may generally be applicable to otherdatabase models as well. For an overall discussion on basic database securityconcepts consult the surveys by Jajodia and Sandhu (1990a), Lunt andFernandez (1990), or Denning (1988). For references to further readingsconsult the annotated bibliography by Pernul and Luef (1992). The outline of this Chapter is as follows: In the remainder of the openingSection we shortly review the relational data model, we introduce a simpleexample that will be used throughout the Chapter, we present the basicterminology used in computer security, and we describe the most successfulmethods that might be used to penetrate a database. Because of the diversity ofapplication domains for databases different security models and techniques 1. However, audit records are often stored and examined by using the DBMS software.
  4. 4. -4-have been proposed so far. In Section 2 we review, evaluate, and compare themost prominent representatives among them. Section 3 contains aninvestigation of secure (trusted) database management systems (DBMSs).These are special purpose systems that support a level-based security policyand were designed and implemented with main focus on the enforcement ofhigh security requirements. Section 4 focuses on one of the major problemslevel-based security related database research has to deal with. In this Sectionwe address the problem of how to classify the data stored in the database withsecurity classifications reflecting the security requirements of the applicationdomain properly. What is necessary to counter this problem is to have a clearunderstanding of all the security semantics of the database application and aresulting clever database design. A semantic data/security model is proposed toarrive at a conceptualization and a clear understanding of the security semanticsof the database application. Database security (and computer security ingeneral) is subject to many national and international standardization efforts.The efforts have the goal to develop metrics to evaluate the degree of trust thatcan be placed in computer products used for the processing of sensitiveinformation. In Section 5 we will briefly review these proposals. In Section 6we will point out research challenges in database security and we will give ouropinion of the direction in which we expect the entire field to move within thenext few years. Finally, Section 7 will conclude this Chapter. 1.1 The Relational Data Model Revisited The relational data model was invented by Codd (1970) and is described inmost database textbooks. A relational database supports the relational datamodel and must have three basic principles: a set of relations, integrity rules,and a set of relational operators. Each relation consists of a state-invariantrelation schema RS(A1,...,An), where each Ai is called attribute and defined overa domain dom(Ai). A relation R is a state-dependent instance of RS and consistsof a set of distinct tuples of the form (a1,...,an), where each element ai mustsatisfy dom(Ai) (i.e. ai∈dom(Ai)). Integrity constraints restrict the set of theoretically possible tuples (i. e.dom(A1) × dom(A2) × ... × dom(An)) to the set of practically meaningful. Let Xand Y denote sets of one or more of the attributes Ai in a relation schema. Wesay Y is functional dependent on X, written X→Y, if and only if it is not possibleto have two tuples with the same value for X but different values for Y.Functional dependencies represent the basis for most integrity constraints in therelation model of data. As not all possible relations are meaningful in anapplication, only those that satisfy certain integrity constraints are considered.
  5. 5. -5-From the large set of proposed integrity constraints two are of major relevancefor security: the key property and the referential integrity property. The keyproperty states that each tuple must be uniquely identified by a key and a keyattribute must not have the null-value. As a consequence each event of realitymay be represented in the database only once. Referential integrity states thattuples referenced in one relation must exist in others and is expressed by meansof foreign keys. These two rules are application independent and must be validin each relational database. In addition many application dependent semanticconstraints may exist in different databases. Virtual view relations (or shortly views) are distinguished from baserelations. While the former are the result of relational operations and existsonly virtually, the latter are actually present in the database and hold the storeddata. Relational operations consist of the set operations, a select operation forselecting tuples from relations that satisfy a certain predicate, a projectoperation for projecting a relation on a subset of its attributes and a joinoperation for combining attributes and tuples from different relations. The relational data model was first implemented as System R by IBM andas INGRES at U. C. Berkeley. These two projects have mainly started and alsoconsiderably advanced the field of database security research. Both systems arethe basis of most commercially available products. A few words on designing a database are in order. The design of a relationaldatabase is a complicated and difficult task and involves several phases andactivities. Before the final relation schemas can be determined a carefulrequirements analysis and a conceptualization of the database is necessary.Usually this is done by using a conceptual data model which must be powerfulenough to allow the modeling of all application relevant knowledge. Theconceptual model is used as an intermediate representation of the database andfinally transferred into corresponding relation schemas. It is very important touse a conceptual data model at this step because only such a high level datamodel allows to achieve a database that properly represents all of theapplication dependent data semantics. De facto standard for conceptual designis the Entity Relationship Approach (ER) (Chen, 1976) or one of its variants. Inits graphical representation and in its simplest form the ER regards the world asconsisting of a set of entity types (boxes), attributes (connected to boxes) andrelationship types (diamonds). Relationship types are defined between entitytypes and are either of degree <1:1>, <1:n>, or <n:m>. The degree describesthe maximum number of participating entities. Following is a short example of a relational database. This example will beused throughout the Chapter. It is very simple but sufficient to discuss many
  6. 6. -6-security relevant questions and to show the complexity of the field. Figure 1contains the conceptualization of the database in form of an ER diagram andthe corresponding relation schemas (key attributes are underlined, foreign keysare in italics). The database represents the fact that projects within an enterpriseare carried out by employees. In this simple example we have to deal with thefollowing three security objects: First, Employee represents a set of employeeseach of which is uniquely described by a characteristic SSN (i. e. the socialsecurity number). Of further interest are the Name, the Department theemployee is working for, and the Salary of the employee. Second, Project is aset of projects carried out by the enterprise. Each project has an identifyingTitle, a Subject, and a Client. Finally, security object Assignment contains theassignments of employees to projects. Each assignment is characterized by theDate of the assignment and the Function the employee has to perform duringthe participation in the project. A single employee can be assigned to more thanone project and a project may be carried out by more than one employee. SSN Date Function Title Name Employee N M Project Subject Dep Salary Assignment Client SSN Title Employee (SSN, Name, Dep, Salary) Project (Title, Subject, Client) Assignment (Title, SSN, Date, Function) FIG. 1. Representations of the Example DB 1.2 The Vocabulary of Security and Major DB Security Threats Before presenting the details of database security research it is necessary todefine the terminology used and the potential threats to database security. Asalready has been pointed out, security requirements are stated by means of asecurity policy which consists of a set of laws, rules and practices that regulatehow an organization manages, protects, and distributes sensitive information.In general, a security policy is stated in terms of a set of security objects and aset of security subjects. A security object is a passive entity that contains orreceives information. This might be a structured concept like a whole database,
  7. 7. -7-a relation, a view, a tuple, an attribute, an attribute value, or even a fact ofreality which is represented in the database. A security object might also beunstructured like a physical memory segment, a byte, a bit, or even a physicaldevice like a printer or a processor. Please note, the term object is useddifferently in other computer science disciplines. Within the frameworkpresented here, security objects are the target of protection. A security subjectis an active entity, often in the form of a person (user) or process operating onbehalf of a user. Security subjects are responsible for a change of a databasestate and cause information to flow within different objects and subjects. Most sources of threats to database security come from outside thecomputing system. If most emphasis is given to authorization, the users andprocesses operating on behalf of the users must be subject to security control.An active database process may be operating on behalf of an authorized userwho has legitimate access or may be active on behalf of a person whosucceeded in penetrating the system. In addition, an authorized database usermay act as an ‘information channel’ by passing restricted information tounauthorized users. This may be intentionally or without knowledge of theauthorized user. Some of the most successful database penetration methods are:• Misuses of authority Improper acquisition of resources, theft of programs or storage media, modification or destruction of data.• Logical Inference and Aggregation Both deal with users authorized to use the database. Logical inference arises whenever sensitive information can be inferred from combining less sensitive data. This may also involve certain knowledge from outside the database system. Tightly related to logical inference is the aggregation problem, wherein individual data items are not sensitive but a large enough collection of individual values taken together is considered sensitive.• Masquerade A penatrator may gain unauthorized access by masquerading as a different person.• Bypassing Controls This might be password attacks and exploitation of system trapdoors that avoid intended access control mechanisms. Trapdoors are security flaws that were built in the source code of a program by the original programmer.• Browsing A penetrator circumvents the protection and searches directory or
  8. 8. -8- dictionary information, trying to locate privileged information. Unless strict need-to-know access controls are implemented the browsing problem is a major flaw of database security.• Trojan Horses A Trojan horse is hidden software that tricks a legitimate user without his knowledge to perform certain actions he is not aware of. For example, a Trojan Horse may be hidden into a sort routine and be designed to release certain data to unauthorized users. Whenever a user activates the sort routine, for example for sorting the result of a database query, the Trojan horse will act with the users identity and thus will have all privileges of the user.• Covert Channels Usually information stored in a database is retrieved by means of legitimate information channels. In contrast to legitimate channels covert channels are paths that are not normally intended for information transfer. Such hidden paths may either be storage channels like shared memory or temporary files that could be used for communication purposes or timing channels like a degradation of overall system performance.• Hardware, Media Attacks Physical attacks on equipment and storage media. The attack scenario described above is not restricted to occur in databasesonly. For example, the German Chaos Computer Club succeeded in attacking aNASA system masqueraded, by bypassing access controls (by means of anoperating system flaw) and Trojan horses to capture passwords. As reported byStoll (1988) some of these techniques were also used by the Wily Hacker. TheInternet worm in 1988 exploited trapdoors in electronic mail handling systemsand infected more than 5000 machines connected to the Internet network(Rochlis and Eichin, 1989). Thompson (1984), in his Turing Award Lecture,demonstrated a Trojan horse placed in the executable form of a compiler thatpermitted the insertion of a trapdoor in each program compiled with thecompiler. It is generally agreed that the number of the known cases of computerabuse is significantly smaller than the cases actually happened because in thistopic a large number of dark figures exist. 2. Database Security Models
  9. 9. -9- Because of the diversity of the application domains for databases differentsecurity models and techniques have been proposed to counter the variousthreats against the security. In this Section we will discuss the most prominentamong them. In a nutshell, Discretionary Security specifies the rules underwhich subjects can, at their discretion, create and delete objects, and grant andrevoke authorizations for accessing objects to others. In addition to controllingthe access Mandatory Security regulates the flow of information betweenobjects and subjects. Mandatory security controls are very effective but sufferfrom several drawbacks. One attempt to overcome certain limitations ofmandatory protection systems is the Adapted Mandatory Access Control(AMAC) model, a security technique that focuses on the design aspect ofsecure databases. The Personal Knowledge Approach is concentrating onenforcing the basic law of many countries for the informational self-determination of humans and the Clark and Wilson Model tries to representcommon commercial business practice in a computerized security model. Firstattempts to compare some of these techniques have been made by Biskup(1990) and Pernul and Tjoa (1992). Landwehr (1981) is a very good survey offormal policies for computer security in general and Millen (1989) focuses onvarious aspects of mandatory computer security. 2.1 Discretionary Security Models Discretionary security models are fundamental to operating systems andDBMSs and have now been studied for a long time. From 1970 through 1975,there was a good deal of interest in the theoretical aspects of these models.Then most of the relational database security research has turned to othersecurity techniques. However, the appearance of more advanced data modelshas renewed interest in discretionary policies.2.1.1 Discretionary Access Controls Discretionary access controls (DAC) are based on the concepts of a set ofsecurity objects O, a set of security subjects S, a set of access privileges Tdefining what kind of access a subject has to a certain object, and in order torepresent content-based access rules a set of predicates P. Applied to relationaldatabases O is a finite set of values {o1,...,on} representing relation schemas, Sis a finite set of potential subjects {s1,} representing users, groups of them,or transactions operating on behalf of users. Access types (privileges) are the setof database operations such as select, insert, delete, update, execute, grant, or
  10. 10. - 10 -revoke and predicate p∈P defines the access window of subject s∈S on objecto∈O. The tuple <o,s,t,p> is called access rule and a function f is defined todetermine if an authorization f(o,s,t,p) is valid or not: f: O × S × T × P → {True, False}. For any <o,s,t,p>, if f(o,s,t,p) evaluates into True, subject s hasauthorization t to access object o within the range defined by predicate p. An important property of discretionary security models is the support of theprinciple of delegation of rights where a right is the (o,t,p)-portion of the accessrule. A subject si who holds the right (o,t,p) may be allowed to delegate thatright to another subject sj (i≠j). Most systems supporting DAC store access rules in an access controlmatrix. In its simplest form the rows of the matrix represent subjects, thecolumns represent the objects and the intersection of a row and a columncontains the access type that subject has authorization for with respect to theobject. The access matrix model as a basis for discretionary access controls wasformulated by Lampson (1971) and subsequently refined by Graham andDenning (1972), and by Harrison et al. (1976). A more detailed discussion ondiscretionary controls in databases may be found in the book by Fernandez etal. (1981). Discretionary security is enforced in most commercial DBMS products andis based on the concept of database views. Instead of authorizing a user to thebase relations of a system the information of the access control matrix is usedto restrict the user to a particular subset of the data available. Two main systemarchitectures for view-based protection can be identified: query modificationand view relations. Query modification is implemented in Ingres-style DBMSs(Stonebraker and Rubinstein 1976) and consists of appending additionalsecurity relevant qualifiers to a user supplied query. View relations areunmaterialized queries which are based on physical base relations. Instead ofauthorizing the users to base relations they have access to the virtual viewrelations only. By means of qualifiers in the view definition security restrictionscan be implemented. View relations are the underlying protection mechanismof System R-based DBMSs (Griffiths and Wade, 1976).2.1.2 DAC-based Structural Limitations Although very common discretionary models suffer from major drawbackswhen applied to databases with security critical content. In particular we seethe following limitations:• Enforcement of the security policy
  11. 11. - 11 - DAC is based on the concept of ownership of information. In contrast to enterprise models, where the whole enterprise is the ‘owner’ of information and responsible for granting access to stored data, DAC systems assign the ownership of information to the creator of the data items in the database and allow the creator subject to grant access to other users. This has the disadvantage that the burden of enforcing the security requirements of the enterprise is in the responsibility of the users themselves and cannot be controlled by the enterprise without involving high costs.• Cascading authorization If two or more subjects have the privilege of granting or revoking certain access rules to other subjects this may lead to cascading revocation chains. As an example consider subjects s1, s2, s3, and access rule (s1,o,t,p). Subject s2 receives the 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 because of some reason. The effect of these operations is that s3 still has the authorization (from s1) to access object o by satisfying predicate p and using privilege t even if subject s2 has revoked it. This has the consequence that subject s2 is not aware of the fact that authorization (s3,o,t,p) is still in effect.• Trojan Horse attacks In systems supporting DAC the identity of the subjects is crucial, and if actions can be performed using another subject’s identity, then DAC can be subverted. A Trojan Horse can be used to grant a certain right (o,t,p) of subject si on to sj (i≠j) without the knowledge of subject si. Any program which runs on behalf of a subject acts with the identity of the subject and therefore has all of the DAC access rights of the subject’s processes. If a program contains a Trojan Horse with the functionality of granting access rules on to other users this cannot be restricted by discretionary access control methods.• Update problems View-based protection results in unmaterialized queries which have no explicit physical representation in the database. This has the advantage of being very flexible to support the subjects with different views and to automatically filter out data a subject is not authorized to access but has the disadvantage that not all data is updateable through certain views. This is due to integrity reasons that might be violated in data not contained in the view by updating data from the view. 2.2 Mandatory Security Models
  12. 12. - 12 - Mandatory policies address a higher level of threat than discretionarypolicies because in addition to controlling the access to data they control theflow of data as well. Moreover, mandatory security techniques overcome thestructural limitations of DAC-based protection as described above.2.2.1 Mandatory Access Controls While discretionary models are concerned with defining, modeling, andenforcing access to information mandatory security models are in additionconcerned with the flow of information within a system. Mandatory securityrequires that security objects and subjects are assigned to certain security levelsrepresented by a label. The label for an object o is called its classification(class(o)) and a label for a subject s is called its clearance (clear(s)). Theclassification represents the sensitivity of the labeled data while the clearanceof a subject its trustworthiness to not disclose sensitive information to others. Asecurity label consists of two components: a level from a hierarchical list ofsensitivity levels or access classes (for example: top_secret > secret >confidential > unclassified) and a member of a non hierarchical set ofcategories, representing classes of object types of the universe of discourse.Clearance and classification levels are totally ordered resulting security labelsare only partially ordered - thus, the set of classifications forms a lattice. In thislattice security class c1 is comparable to and dominates (≥) c2 if the sensitivitylevel of c1 is greater than or equal to that of c2 and the categories in c1 containthose in c2. Mandatory security grew out of the military environment where it ispractice to label information. However, this custom is also common in manycompanies and organizations where labels termed like ‘confidential’ or‘company confidential’ are used. Mandatory access control (MAC) requirements are often stated based onBell and LaPadula (1976) and formalized by two rules. The first (simpleproperty) protects the information of the database from unauthorizeddisclosure, and the second (*-property) protects data from contamination orunauthorized modification by restricting the information flow from high to low. (1) Subject s is allowed to read data item d if clear(s) ≥ class(d). (2) Subject s is allowed to write data item d if clear(s) ≤ class(d). Few final sentences on MAC policies are in order. In many discussionsconfusion has arisen about the fact that in mandatory systems it is not onlysufficient to have strong controls over who can read which data. Why is itnecessary to include strong controls over who can write which data in systemswith high security requirements? The reason is that a system with high security
  13. 13. - 13 -needs must protect itself against attacks from unauthorized as well as fromauthorized users. There are several ways authorized users may disclosesensitive information to others. This can be done by mistake, as a deliberateillegal action, or the user may be tricked to do so by a Trojan horse attack. Thesimplest technique to disclose information by an authorized user is to retrieve itfrom the database, to copy it into an ‘owned’ object, and to make the copyavailable to others. To prevent from doing so, it is necessary to control theability of the authorized user to make a copy (which implies the writing ofdata). In particular, once a transaction has successfully completed a readattempt, the protection system must ensure that there is no write to a lowersecurity level (write-down) that is caused by a user authorized to execute a readtransaction. As the read and write checks are both mandatory controls, a MACsystem successfully protects against the attempt to copy information and togrant the copy to unauthorized users. By not allowing higher classified subjectsto ‘write-down’ on lower classified data information flow among subjects withdifferent clearances can efficiently be controlled. As covert storage channelsrequire writing to objects the *-property also helps to limit leakage ofinformation by these hidden paths. Mandatory integrity policies have also been studied. Biba (1977) hasformulated an exact mathematical dual of the Bell-LaPadula model, withintegrity labels and two properties: no-write-up in integrity and no-read-downin integrity. That is, low integrity objects (including subjects) are not permittedto contaminate higher integrity objects, or in other words no resource ispermitted to depend upon other resources unless the latter are at least astrustworthy as the former. As an interesting optional feature mandatory security and the Bell-LaPadula (BLP) paradigm may lead to multilevel databases. These aredatabases containing relations which may appear different to users withdifferent clearances. This is due to the following two reasons: Firstly, not allclearances may authorize all subjects to all data and secondly, the support ofMAC may lead to polyinstantiation of attributes or tuples. We will discusspolyinstantiation and the mandatory relational data model in more detail in thenext Subsection.2.2.2 The Multilevel Secure Relational Data Model In this Subsection we will define the basic components of the multilevelsecure (MLS) relational data model. We will consider the most general case inwhich an individual attribute value is subject to security label assignment. Wewill start by using the example database scenario from the Introduction.
  14. 14. - 14 -Throughout the text, whenever we refer to the example we assume theexistence of four sensitivity levels, denoted by TS, S, Co, U (whereTS>S>Co>U) and a single category only. In each relational schema TC is anadditional attribute and contains the tuple classification. Title Subject Client TC Alpha, S Development, S A, S S Beta, U Research, S B, S S Celsius, U Production, U C, U U Title Subject Client TC Alpha, S Development, S A, S S (a) Project S Beta, U Research, S B, S S Celsius, U Production, U C, U U Title Subject Client TC Alpha, U Production, U D, U U Beta, U -, U -, U U Celsius, U Production, U C, U U (c) Polyinstantiation at the tuple level (b) Project U FIG. 2. Instances of MLS Relation ‘Project’ Consider the three different instances of relation Project as given in Figure2. Fig. 2(a) corresponds to the view of a subject s with clear(s) = S. Because ofthe simple property of BLP (read access rule) users cleared at U would see theinstances of Project as shown in Fig. 2(b). In this case the simple property ofBLP would automatically filter out data that dominate U. Consider further asubject s with clear (s) = U and an insert operation where the user wishes toinsert the tuple <Alpha, Production, D> into the relation shown in Fig. 2(b).Because of the key integrity property a standard relational DBMS would notallow this operation (Although not seen by user s Alpha as a key already existsin relation Project.). However, from a security point of view the insert must notbe rejected because otherwise a covert signalling channel occurs from which smay conclude that sensitive information he is not authorized to access mayexist. The outcome of the operation is shown in Fig. 2 (c) and consists of apolyinstantiated tuple in MLS relation Project. A similar situation may occur ifa subject cleared for the U-level would update <Beta, null, null> in Project asshown in Fig. 2(b) by replacing the null-values with certain data items. Again,this would lead to polyinstantiation in relation Project. As another example of
  15. 15. - 15 -polyinstantiation consider that subject s with clear(s)=S wants to update<Celsius, Production, C>. In systems supporting MAC such an update is notallowed because of the *-property of BLP. This is necessary because anundesired information flow might occur between subjects cleared at the S-levelto subjects cleared at the U-level. Thus, if a S-level subject wishes to update thetuple the update again must result into polyinstantiation. The problem of polyinstantiation arises because of the avoidance of acovert channel. Lampson (1973) has defined a covert channel as a means ofdownward information flow. As example let us consider the situation describedabove once more. If an insert operation is rejected to a subject because of thepresence of a tuple at a higher level, the subject might be able to infer theexistence of that tuple, resulting in a downward information flow. With respectto security much more may happen than just inferring the presence of a tuple.The success or failure of the service request, for example, can be usedrepeatedly to communicate one bit of information (0: failure, 1: success) to thelower level. Therefore, the problem is not only the inferring of a classifiedtuple, moreover, any information visible at the higher level can be sent througha covert channel to the lower level. The theory of most data models is built around the concept, that a fact ofreality is represented in the database only once. Because of polyinstantiationthis fundamental property is no longer true for MLS databases thus making thedevelopment of a new theory necessary. The state of development of a MLSrelational theory has been considerably advanced by the researchers involved inthe SeaView project. For example, see Denning et al. (1988) or Lunt et al.(1990). The following discussion of the theoretical concepts behind the MLSrelational data model is mainly based on the model developed by Jajodia andSandhu (1991a). In the Jajodia-Sandhu model each MLS relation consists of a state-invariantmultilevel relation schema RS (A1, C1, ..., An, Cn, TC), where each Ai is anattribute defined over a domain dom(Ai), each Ci is classification for Ai and TCis the tuple-class. The domain of Ci is defined by [Li, Hi] which is a sublatticeof all security labels. The resulting domain of TC is [lub {Li, i=1..n}, lub {Hi,i=1..n}], where lub denotes least upper bound operation in the sublattice ofsecurity labels. In the Jajodia-Sandhu model TC is included but is anunnecessary attribute. A multilevel relation schema corresponds to a collection of state-dependentrelation instances R, one for each access class c. A relation instance is denotedby Rc (A1, C1, ... An, Cn, TC) and consists of a set of distinct tuples of the form(a1, c1, ..., an, cn, tc) where each ai ∈ dom (Ai), c ≥ ci, ci ∈ [Li, Hi], and tc = lub
  16. 16. - 16 -{ci, i=1..n}. We use the notion t[Ai] to refer to the value of attribute Ai in tuple twhile t[Ci] denotes the classification of Ai in tuple t. Because of the simple-property of BLP, t[Ai] is visible for subjects with clear(s) ≥ t[Ci]; otherwiset[Ai] is replaced with the null-value. The standard relational model is based on two core integrity properties: thekey property and the referential integrity property. In order to meet therequirements for MLS databases both have been adapted and two furtherproperties have been introduced. In the standard relational data model a key isderived by using the concept of functional dependencies. In the MLS relationalmodel such a key is called apparent key. Its notion has been defined by Jajodiaet al. (1990). For the following we assume RS (A1, C1, ..., An, Cn, TC) being aMLS relation schema and A (A⊆{A1, ..., An}) the attribute set forming itsapparent key.[MLS Integrity property 1]: Entity Integrity. A MLS relation R satisfies entityintegrity if and only if for all instances Rc and t ∈ Rc 1. Ai ∈ A ⇒ t[Ai] ≠ null 2. Ai, Aj ∈ A ⇒ t[Ci] = t[Cj] 3. Ai ∉ A ⇒ t[Ci] ≥ t[CA] (CA is classification of key A) Entity integrity states that the apparent key may not have the null value,must be uniformly classified and its classification must be dominated by allclassifications of the other attributes.[MLS Integrity property 2]: Null Integrity. R satisfies null integrity if and onlyif for each Rc of R the following conditions hold: 1. For every t∈Rc, t[Ai]=null ⇒ t[Ci] = t[CA] 2. Rc is subsumtion free, i. e. does not contain two distinct tuples such that one subsumes the other. A tuple t subsumes a tuple s, if for every attribute Ai, either t[Ai, Ci] = s[Ai, Ci] or t[Ai] ≠ null and s[Ai] = null. Null integrity states that null values must be classified at the level of the keyand that for subjects cleared for the higher security classes, the null valuesvisible for the lower clearances are replaced by the proper values automatically. The next property deals with consistency between the different instances Rcof R. The inter-instance property was first defined by Denning et al. (1988)within the SeaView framework, later corrected by Jajodia and Sandhu (1990b)and later again included in SeaView by Lunt et al. (1990).[MLS Integrity property 3]: Inter-instance Integrity. R satisfies the inter-instance integrity if for all instances Rc of R and all c’ < c a filter function σproduces Rc’. In this case Rc’ = σ(Rc, c’) must satisfy the following conditions:
  17. 17. - 17 - 1. For every t ∈ Rc such that t[CA] ≤ c’ there must be a tuple t’ ∈ Rc’ with t’[A, CA] = t[A, CA] and for Ai ∉ A t[Ai, Ci], if t[Ci] ≤ c’ t’[Ai, Ci] = { <null, t[CA]>, otherwise. 2. There are no additional tuples in Rc’ other than those derived by the above rule. Rc’ is made subsumtion free. The inter-instance property is concerned with consistency between relationinstances of a multilevel relation R. The filter function σ maps R to differentinstances Rc (one for each c’<c). By using filtering a user may be restricted tothat portion of the multilevel relation for which the user is cleared. If c’ dominates some security levels in a tuple but not others, then duringquery processing the filter function σ replaces all attribute values the user is notcleared to see by null-values. Because of the use of this filter function ashortcoming in the Jajodia-Sandhu model has been pointed out by Smith andWinslett (1992). Smith and Winslett state that σ introduces an additionalsemantics for nulls. In the Jajodia-Sandhu model a null value can now mean‘information available but hidden’ and this null value cannot be distinguishedfrom a null-value representing the semantics ‘value exists but not known’ or anull-value with the meaning ‘this property will never have a value’. In adatabase all kinds of nulls may be present and at a certain security level it maybe hard for the subjects to say what should be believed at that level. Let us now draw our attention to polyinstantiation. As we have seen in theexample given above polyinstantiation may occur on several differentoccasions. For example, because of a user with low clearance trying to insert atuple that already exists with higher classification, because of a user wanting tochange values in a lower classified tuple, but it may also occur because of adeliberate action in form of a cover story, where lower cleared users should notbe supported with the proper values of a certain fact. Some researchers statethat using polyinstantiation for establishing cover stories is a bad idea andshould not be permitted. However, if supported it may not occur within thesame access class.[MLS integrity property 4]: Polyinstantiation Integrity. R satisfiespolyinstantiation integrity if for every Rc and each attribute Ai the functionaldependency A Ci → Ai (i=1..n) holds. Property 4 states that the apparent key A and the classification of anattribute correspond to one and only one value of the attribute, i. e.polyinstantiation may not occur within one access class. In many DBMSs supporting a MLS relational data model multilevelrelations exist only at the logical level. In such systems multilevel relations are
  18. 18. - 18 -decomposed into a collection of single-level base relations which are thenphysically stored in the database. Completely transparent multilevel relationsare constructed from these base-relations on user demand. The reasons behindthis approach are mostly practical. Firstly, fragmentation of data based on itssensitivity is a natural and intuitive solution to security and secondly, availableand well-accepted technology may be used for the implementation of MLSsystems. In particular, the decomposition approach has the advantage that theunderlying trusted computing base (TCB) needs not to be extended to includemandatory controls on multilevel relations and this helps to keep the code ofthe TCB small. Moreover, it allows the DBMS to run mostly as an untrustedapplication on top of the TCB. We will come back to this issue in Section 3when discussing different implementations of Trusted DBMSs.2.2.3 MAC-based Structural Limitations Although being more restrictive than DAC models MAC techniques needsome extensions to be applied to databases efficiently. In particular, we see aslimitations the following drawbacks in multilevel secure databases andmandatory access controls based on BLP:• Granularity of security object It is not yet agreed about what should be the granularity of labeled data. Proposals range from protecting whole databases, to protecting files, protecting relations, attributes, or even certain attribute values. In any case, careful labeling is necessary because otherwise it could lead to inconsistent or incomplete label assignments.• Lack of automated security labeling technique Databases usually contain a large collection of data, serve many users, and labeled data is not available in many civil applications. This is the reason manual security labeling is necessary which may result in an almost endless process for large databases. Therefore, supporting techniques are needed, namely guidelines and design aids for multilevel databases, tools that help in determining the relevant security objects, and tools that suggest clearances and classifications.• N-persons access rules Because of information flow policies higher cleared users are restricted from writing-down on lower classified data items. However, organizational policies may require that certain tasks need to be carried out by two or more
  19. 19. - 19 - persons (four-eyes-principle) having different clearances. As an example consider subjects s1, s2 with clear(s1) > clear(s2), data item d with class(d) = clear(s2) and the business rule that writing of s2 on d needs the approval of s1. Following Bell-LaPadula’s write-access rule would require the same level of clearance for s1 and s2. This may be inadequate for business applications of MLS database technology. 2.3 The Adapted Mandatory Access Control Model Adapting mandatory access controls to better fit into general purpose dataprocessing practice and offering a design framework for databases containingsensitive information are the main goals of the Adapted Mandatory AccessControl (AMAC) model. In order to overcome the MAC-based limitationsstated above AMAC offers several features that assist a database designer inperforming the different activities involved in the design of a databasecontaining sensitive information. For AMAC as a security technique fordatabases we see the following advantages:• The technique supports all phases of the design of a database and can be used for the construction of discretionary protected as well as for the construction of mandatory protected databases.• In the case mandatory protection is required a supporting policy to derive database fragments as the target of protection is provided. This overcomes the discussion about what should be the granularity of the security object in multilevel systems.• In the case mandatory protection is required automated security labeling for security objects and subjects is supported. Automated labeling leads to candidate security labels that can be refined by a human security administrator if necessary. This overcomes the limitation that labeled data often is not available.• In AMAC security is enforced by using database triggers and thus can be fine-tuned to meet application dependent security requirements. For example, the n-eyes-principle may be supported in some applications and may not in others where information flow control is a major concern of the security policy. We will first give a general overview of the AMAC technique which isfollowed by a more formal discussion and an example.
  20. 20. - 20 -2.3.1 AMAC General Overview Adapted mandatory security belongs to the class of role-based securitymodels which assume that each potential user of the system performs a certainrole in the organization. Based on their role users are authorized to executespecific database operations on a predefined set of data. The AMAC modeldoes not only cover access control issues but includes in addition a databasedesign environment with main emphasis on the security of resulting databases.Resulting databases may be implemented in DBMSs supporting DAC only orsupporting DAC and MAC. The technique combines well known and widelyaccepted concepts from the field of data modeling with concepts from the areaof data security research. By using AMAC the following design phases forsecurity critical databases can be identified. (1) Requirements Analysis and Conceptual Design. Based on the role theyperform in the organization the potential users of the database can be classifiedinto different groups. For different roles data and security requirements maydiffer significantly. The Entity-Relationship (ER) model and its variants serveas an almost de facto standard for conceptual database design and have beenextended in AMAC to model and describe security requirements. The securityand data requirements of each role performed in the organization are describedby individual ER-schemas and form the view (perception) of each user groupon the enterprise data. Please note, in this setting the notion of a view denotesall the information a user performing a certain role in the organization is awareof. This information includes data, security requirements, and functions. Thus,the notion of views appears different from that in a DAC environment. In orderto arrive at a conceptualization of the whole information system as seen fromthe viewpoint of the enterprise AMAC uses view integration techniques in afurther design step. The resulting conceptual database model is described by asingle ER-schema extended by security flags indicating security requirementsfor certain user roles. (2) Logical Design. In order to implement the conceptual schema into aDBMS a transformation from the ER-schema into the data model supported bythe DBMS in use is necessary. AMAC contains general rules and guidelines forthe translation of ER-schemas into the relational data model. Output of thetransformation process is a set of relational schemas, global dependenciesdefined between schemas and necessary for database consistency during furtherdesign steps, and a set of views, now describing access requirements on relationschemas. If the DBMS that should hold the resulting database is only capableto support DAC the relational schemas are candidates for implementation andthe view descriptors are used for discretionary access controls. In the case theDBMS under consideration supports MAC further design activities are
  21. 21. - 21 -necessary. The Requirements Analysis, Conceptual and Logical Design phasesin AMAC are described by Pernul and Tjoa (1991). (3) The AMAC security object. In order to enforce mandatory security it isnecessary to determine security objects and security subjects which are bothsubject to security label assignments. In AMAC a security object is a databasefragment and a subject is a view. Fragments are derived by using structureddatabase decomposition and views are derived by combining these fragments.A fragment is the largest area of the database to which two or more views haveaccess in common. Additionally, no view exists that has access to a subset ofthe fragment only. Pernul and Luef (1991) have developed the structureddecomposition approach and the automated labeling policy. Their workincludes techniques for a lossless decomposition into fragments and algorithmsto keep fragmented databases consistent during database update. It should benoted that a database decomposition into disjoint fragments is a natural way toimplement security controls in databases. (4) Support of automated security labeling. As in most IT applicationslabeled data is not available, AMAC offers a supporting policy for theautomated security labeling of security objects and security subjects.Automated labeling is based on the following assumption: The larger thenumber of users cleared to access a particular fragment, the lower is thesensitivity of the contained data and thus, the lower is the level of classificationthat needs to be provided for the fragment. This assumption seems to be validbecause a fragment that is accessed by many users will not contain sensitiveinformation and at the other side, a fragment that is accessible for few usersonly can be classified as being highly sensitive. Views (respectively the usershaving the view as their access window to the data) are ordered based on thenumber of fragments they may access (they are defined over) and additionallybased on the assigned classifications for the fragments. In general, a view needsa clearance that allows the corresponding users to access all fragments the viewis defined over. The suggested classification class(F) applies to the wholefragmental schema F as well as to all attribute names and type definitions forthe schema while the suggested clearance clear(V) to all transactions executingon behalf of a user V. It should be noted that classifications and clearances areonly candidates for security labels and may be refined by a human databasedesigner if necessary. (5) Security Enforcement. In AMAC the fragments are physically storedand access to a fragment may be controlled by a reference monitor. Security isenforced by using trigger mechanisms. Triggers are hidden rules that can befired (activated) if a fragment is effected by certain database operations. Indatabases security critical operations are the select (read access), the insert,
  22. 22. - 22 -delete, and update (write accesses) commands. In AMAC select-triggers areused to route queries to the proper fragments, insert-triggers are responsible todecompose tuples and to insert corresponding sub-tuples into proper fragments,and update- and delete-triggers are responsible for protecting againstunauthorized modification by restricting information flow from high to low incases that could lead to an undesired information transfer. The operationalsemantics of the AMAC database operations and the construction of the select-and insert-triggers are outlined by Pernul (1992a).2.3.2 A More Technical View on AMAC and an Example In AMAC security constraints are handled during database design as wellas during query processing. During database design they are expressed by thedatabase decomposition while during query processing they are enforced by thetrigger mechanisms. In the following we will give the technical details of thedecomposition process, the decomposition itself, the automated securitylabeling process, and certain integrity constraints that need to be considered inorder to arrive at a satisfactorily fragmentation. In AMAC it is assumed that Requirements Analysis is performed on anindividual user group basis and that the view on the database of each user groupis represented by an Entity-Relationship (ER) model. The ER model has beenextended to cover in addition to data semantics the access restrictions of theuser group. The next design activity is view integration. View integrationtechniques are well established in conceptual database design and consist ofintegrating the views of the individual user groups into a single conceptualrepresentation of the database. In AMAC the actual integration is based on atraditional approach and consists of two steps: integration of entity types andintegration of relationship types (Pernul and Tjoa, 1991). During theintegration correspondences between the modeling constructs in differentviews are established and based on the different possibilities ofcorrespondences the integration is performed. After the integration the universeof discourse is represented by a single ER diagram extended by the accessrestrictions for each user group. The next step is the transformation of theconceptual model into a target data model. AMAC offers general rules for thetranslation into the relational data model. The translation is quite simple andresults into three different types of modeling constructs: relation schemas(entity type relations or relationship type relations), interrelationaldependencies defined between relation schemas, and a set of view descriptorsdefined on relation schemas and representing security requirements in the formof access restrictions for the different user groups.
  23. 23. - 23 - In the relational data model user views have no conceptual representation.The decomposition and labeling procedure in AMAC is build around theconcept of a user view and this makes a simple extension of the relational datamodel necessary. Let RS(ATTR,LD) be a relation schema with ATTR a set of attributes{A1,...,An}. Each Ai∈ATTR has a domain dom(Ai). LD is a set of functionaldependencies (FDs) restricting the set of theoretically possible instances of arelation R with schema RS (i.e. ×i dom(Ai)) to the set of semanticallymeaningful. A relation R with schema RS is a set of distinct instances (tuples){t1,...,tm} of the form <a1,...,an> where ai is a value within dom(Ai). Let RS1(ATTR1,LD1) and RS2(ATTR2,LD2) be two relation schemas withcorresponding relations R1 and R2. Let X and Y denote two attribute sets withX⊆ATTR1 and Y⊆ATTR2. The interrelational inclusion dependency (ID)RS1[X]⊆RS2[Y] holds if for each tuple t∈R1 exists at least one tuple t’∈R2 andt[X]=t’[Y]. If Y is key in RS2 the ID is called key-based and Y is a foreign key inRS1. Let V={V1,...,Vp} be a set of views. A view Vi (Vi∈V, i=1..p) consists of a setof descriptors specified in terms of attributes and a set of conditions on theseattributes. The set of attributes spanned by the view can belong to one or morerelation schemas. View conditions represent the access restrictions of aparticular user group on the underlying base relations. For each user groupthere must be at least one view. The concepts defined above serve as the basis of an AMAC conceptual startschema SS. SS may be defined by a triple SS(ℜ,GD,V), where: ℜ = {RS1(ATTR1,LD1),...,RSn(ATTRn,LDn)} is a set of relation schemas, GD = {ID1,...,IDk} is a set of key-based IDs, and V = {V1,...,Vm} is the set of views. In the case discretionary protection is sufficient, the relational schemas arecandidates for implementation in a DBMS, the views may be used toimplement content-based access controls and the set GD of globaldependencies may be associated with an insert-rule, a delete-rule, and amodification-rule in order to ensure referential integrity during databaseoperation. In the case DAC is not sufficient and MAC should be supported it isnecessary to determine the security objects and subjects and to assignappropriate classifications and clearances. In order to express the securityrequirements defined by means of the views a decomposition of SS into singlelevel fragments is necessary. The decomposition is based on the derived viewstructure and results in a set of fragmental schemas in a way, that no view isdefined over a subset of a resulting schema only. A single classification is
  24. 24. - 24 -assigned to each fragmental schema and the decomposition is performed byusing a vertical, horizontal, or derived horizontal fragmentation policy. A vertical fragmentation (vf) results into a set of vertical fragments(F1,...,Fr) and is the projection of a relation schema RS onto a subset of itsattributes. In order to make the decomposition lossless the key of RS must beincluded in each vertical fragment. A vertical fragmentation (vf) R=(F1,...,Fr)of a relation R is correct, if for every tuple t∈R, t is the concatenation of(v1,...,vr) with vi tuple in Fi (i=1..r). The (vf) is used to express ‘simple’ securityconstraints that restrict users from accessing certain attributes. The effects of(vf) on an existing set of FDs have been studied by Pernul and Luef (1991) andthe authors show that if R is not in 3NF (third normal form) some FDs mightget lost during a decomposition. In order to produce a dependency preservingdecomposition in AMAC they have suggested to include virtual attributes (notvisible for any user) and update clusters in vertical fragments in the case aschema is not in 3NF. A horizontal fragmentation (hf) is a subdivision of a relation R with schemaRS(ATTR,LD) into a subset of its tuples based on the evaluation of a predicatedefined on RS. The predicate is expressed as a boolean combination of terms,each term being a simple comparison that can be established as true or false.An attribute on which a (hf) is defined is called selection attribute. A (hf) iscorrect, if every tuple of R is mapped into exactly one resulting fragment.Appending one horizontal fragment to another leads to a further horizontalfragment or to R again. A (hf) is used to express access restrictions based on thecontent of certain tuples. A derived horizontal fragmentation (dhf) of a relation Ri with schemaRSi(ATTRi,LDi) is partitioning RSi by applying a partitioning criterion that isdefined on RSj (i≠j). A (dhf) is correct if there exists a key-based ID of the formRi[X]⊆Rj[Y] and each tuple t∈Ri is mapped into exactly one of the resultinghorizontal fragments. A (dhf) may be used to express access restrictions thatspan several relations. A view Vi (Vi ∈V) defined on ℜ represents the area of the database to whicha corresponding user group has access. Let F (F=Vi∩Vj) be a databasefragment then F represents the area of the database to which two groups ofusers have access in common. If F=Vi Vj, then F is only accessible by usershaving view Vi as their interface to the database. In this case, F represents datawhich is not contained in Vj and must therefore not be accessible for thecorresponding user set. From the point of view of a mandatory security policy acertain level of assurance must be given that users Vj are restricted fromaccessing F. In AMAC this is given by separation. For example, fragment (Vi
  25. 25. - 25 -Vj) is separated from fragment (VjVi) and fragment (Vi ∩Vj) even if allfragments belong to the same relation. The construction of the fragmentsmakes a structured database decomposition necessary and in order to supportmandatory access controls, the access windows for the users is constructed in amultilevel fashion such that only the necessary fragments are combined to forma particular view. Let Attr(V) be the attribute set spanned by view V and let the subdomainSD(V[A]) be the domain of attribute A valid in view V (SD(V[A])⊆Dom(A)).Two particular views Vi and Vj are said to be overlapping, if: ∃A(A∈Attr(Vi∩Vj) and SD(Vi[A])∩SD(Vj[A]) ≠ ∅,otherwise, Vi and Vj are called isolated. The process of decomposing ℜ(ℜ={RS1(ATTR1,LD1),...,RSn(ATTRn,LDn)}) is performed for any twooverlapping views and for each isolated view by using the (vf), (hf), and (dhf)decomposition operations. It results in a fragmentation schemaFS={FS1(attr1,ld1),...,FSm(attrm,ldm)} and a corresponding set of fragments F(F={F1,...,Fm}). If ∪i ATTRi = ∪j attrj (i=1..n, j=1..m) the decomposition iscalled lossless and if ∪i LDi ⊆ ∪j ldj (i=1..n, j=1..m) it is called dependencypreserving. Please note that (hf) or (dhf) may result in additional FDs. Afragmental schema FSj∈FS is not valid if for any view V (∃Fj’⊂Fj) (V⇒Fj’,V⇔Fj). Here, V⇒F denotes that users with view V have access to fragment Fwhile V⇔F means that F is not included in view V. To illustrate the concepts defined above we will apply the fragmentationpolicy to the example given in the Introduction of this Chapter. We assume, thatthe Requirements Analysis has been performed and that the resulted ER modelhas been translated into the following start schema: SS = ( ℜ= { Employee ({SSN, Name, Dep, Salary}, {SSN → Name, Dep, Salary}), Project ({Title, Subject, Client}, {Title → Subject, Client}), Assignment ({Title, SSN, Date, Function}, {Title, SSN → Date, Function})}, GD ={Assignment[Title]⊆Project[Title], Assignment[SSN]⊆Employee[SSN]}, V = {V1, V2, V3, V4, V5}) The security policy of the organization requires to represent the followingconditions on the security:• View V1 represents the access window for the management of the organization under consideration. Users with view V1 should have access to
  26. 26. - 26 - the whole database.• Views V2 and V3 represent users of the pay-office department. Their requirements include access to Employee and Assignment. For V2 access to Employee is not restricted. However, access to attribute Function should only be provided in the case the employees’ Salary ≤ 100. Users V3 should only have access to employees and their assignments in the case the attribute Salary ≤ 80.• View V4 has access to Project. However, access to attribute Client should not be supported in the case the subject of a project is ‘research’.• View V5 represents the view of the users of the quality-control department. For them to perform their work it is necessary to have access to all information related to projects that have a subject ‘development’, i. e. to the project data, to the assignment data, and to the data concerning assigned employees. For security requirements such as the above the construction of afragmentation schema is suggested in AMAC. The security constraints fall intothree different categories. We can identify simple constraints that define avertical subset of a relation schema and content-based or complex constraintsthat both define horizontal fragments of data. A (simplified) graphicalrepresentation of the corresponding view structure is given in Figure 3(a).
  27. 27. - 27 - Employee Assignment Project V1: no restriction V4: V2: V5: V3: (a) Graphical Representation of the View Structure ℜ (vf) (hf) Employee Assignment Project (dhf) IF3 IF4 IF1 IF2 IF5 IF6 IF11 IF12 IF21 IF22 F15 F16 F13 F14 F11 F12 F9 F10 F7 F8 F5 F6 F3 F4 F1 F2 (b) Structured Decomposition FIG 3: AMAC Database Decomposition, Example The view structure forms the basis of the decomposition. Because view V1spans the whole database it does not cause any decomposition. View V2 causesa derived horizontal fragmentation (dhf) of Assignment based on the evaluationof the predicate p:Salary ≤ 100 defined on Employee. The decomposition isvalid because of the existence of the key-based inclusion dependency betweenEmployee and Assignment. For those tuples matching the condition in a secondstep a vertical fragmentation (vf) is performed which splits attribute Functionfrom the other attributes in the derived fragment. In Fig. 3(b) the outcome ofthis operation is shown as IF21 and IF22. Introducing view V3 results into ahorizontal fragmentation (hf) of Employee (into IF3 and IF4) and into a (dhf) ofIF1. IF1 is split into IF11 (representing assignment data of employees with
  28. 28. - 28 -salary below 80) and IF12 (assignment data of employees having a salarybetween 81 and 99). Again, this fragmentation is valid because of the existenceof the key-based ID Assignment[SSN]⊆Employee[SSN]. Introducing view V4results into applying (hf) to Project and in a further (vf)-decomposition attributeClient is split from projects having as Subject the value ‘research’. The result ofthe operations is given in Fig. 3(b) as fragments F1 and F2. Introducing view V5again makes several (hf) and (dhf) operations necessary. Starting with Project a(hf) is performed on IF5 resulting in F3 (holding projects that have subject‘development’) and F4 (holding the other projects). The next step is a (dhf) ofAssignment which is necessary to find all assignment data that relates toprojects having as subject ‘development’. Such data may be found in eachintermediate fragment resulted so far and thus makes four different (dhf)operations necessary. A similar situation occurs with employee data. The finaldecomposition is given in Fig. 3(b) and consists of 16 different fragments. In order to support MAC it is necessary to determine the security objectsand subjects and to assign appropriate classifications and clearances. In AMAC(semi-) automated security label assignment is supported and based on thefollowing assumption: A fragment accessed by many users cannot containsensitive information whereas a fragment that is accessed by few users onlymay have sensitive data. In AMAC such a situation leads to the assignment of a‘low’ classification level to the former fragment and to a ‘high’ classification tothe latter. At the other side, views that are accessing a large number offragments or fragments assigned to ‘high’ classifications need to have ‘high’clearances. In general, a view needs a clearance which allows correspondingusers to access all fragments the view is defined over. Let F={F1,...Fn} be the set of fragments and V ={V1,...Vm} be the set ofviews defined on the database. Let a:F→Ρ(V) be a mapping that assigns to afragment the set of views having access to the fragment. With card_a(Fi→Ρ(V))we denote the cardinality of the set of views accessing the fragement, i.e. |a(Fi)|. Card_a(Fi→Ρ(V)) determines the level of classification that needs to beprovided for fragment Fi. Let d:V→Ρ(F) be a mapping relating to a view the setof fragments spanned by the view. With card_d(Vj→Ρ(F)) we denote thecardinality of the set of fragments to which a user with view Vj has access, i. e.|d(Vj)|. By applying a(Fi) and d(Vj) to the example developed above we derivethe following mappings: Mappings from fragments to views: a(F2)={V1}, a(F6)={V1}, a(F1)={V1,V4}, a(F4)={V1,V4}, a(F5)={V1,V5}, a(F8)={V1,V2}, a(F10)={V1,V2}, a(F14)={V1,V2},
  29. 29. - 29 - a(F3)={V1,V4,V5}, a(F7)={V1,V2,V5}, a(F9)={V1,V2,V5}, a(F12)={V1,V2,V3}, a(F13)={V1,V2,V5}, a(F16)={V1,V2,V3}, a(F11)={V1,V2,V3,V5}, a(F15)={V1,V2,V3,V5}. Mappings from views to fragments: d(V1)={F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14,F15,F16}, d(V2)={F7,F8,F9,F10,F11,F12,F13,F14,F15,F16}, d(V3)={F11,F12,F15,F16}, d(V4)={F1,F3,F4}, d(V5)={F3,F5,F7,F9,F11,F13,F15}. Let us now order the fragments based on the assumption stated above. Theordering defines the level of classification that needs to be assigned to afragment. Based on our assumption we can derive the following dominancerelationship between classifications (For simplicity, we assume a uniformdistribution of users among views.): {class(F2), class(F6)} > {class(F1),class(F4), class(F5), class(F8), class(F10), class(F14)} > {class(F3), class(F7),class(F9), class(F12), class(F13), class(F16)} > {class(F11), class(F15)}.Furthermore, clear(V1) ≥ {class(F1), ..., class(F16)}, clear(V2) ≥ {class(F7), ...,class(F16)}, clear(V3) ≥ {class(F11), class(F12), class(F15), class(F16)},clear(V4) ≥ {class(F1), class(F3), class(F4)}, and clear(V5) ≥ {class(F3),class(F5), class(F7), class(F9), class(F11), class(F13), class(F15)}. The securityclassifications are assigned based on the ordering of the fragments and aregiven in Fig.4. Between the levels the dominance relationship (d > c > b > a)holds. F15 ⇒ a2 F12 ⇒ b4 F14 ⇒ c6 F4 ⇒ c2 F11 ⇒ a1 F9 ⇒ b3 F10 ⇒ c5 F1 ⇒ c1 F16 ⇒ b6 F7 ⇒ b2 F8 ⇒ c4 F6 ⇒ d2 F13 ⇒ b5 F3 ⇒ b1 F5 ⇒ c3 F2 ⇒ d1 FIG. 4: Assigned classifications, Example Structured decomposition results into the assignment of a classificationlabel to each fragmental schema and to a clearance to each user view. Thus, afragmental schema can be denoted as FS(attr, ld, c) which means that datacontained in FS is uniformly classified with classification c. The process ofstructured decomposition and label assignment can be automated. The assignedsecurity labels serve only as a suggestion to a human database designer whocan refine them if necessary. However, it is commonly agreed that in the casethe number of different views is large automated labeling will produce verygood results. The outcome of the decomposition and the assigned
  30. 30. - 30 -classifications and clearances are maintained by three catalog relations: theDominance Schema, the Data Schema, and the Decomposition Schema. Applied to the example label assignment means that based on the AMACassumptions fragments F6 and F2 describe the most sensitive area of thedatabase. This seems to be legitimate because F6 holds attribute Function ofassignments of employees that earn more than 100 in the case the assignmentrefers to a project with attribute Subject ≠ ‘development’ and F2 holding thesensitive information concerning who are the clients of projects having assubject ‘research’. As only one group of users (V1) has access to bothfragments, F2 and F6 will have a classification that dominates all otherclassifications of the database and is only dominated by clear(V1). At the otherside, fragments F11 and F15 are accessed by most views. The AMAC labelingassumption seems to be legitimate here too, because both fragments describenon-sensitive data concerning employees and their assignments in the case theemployee earns less than 80 and the corresponding project has as subject‘development’. In AMAC multilevel relations exist at a conceptual level only. The accesswindow for the users is constructed in a multilevel fashion that only thenecessary fragments are combined to form a particular view. This is donecompletely transparent to the user by first filtering out fragments that dominatethe users clearance and second by performing the inverse decompositionoperation on the remaining fragments. This is for (vf) a concatenation ofvertical fragments (denoted by <c>) and for (hf) and (dhf) an append ofhorizontal fragments (denoted by <a>). With respect to the example the viewsV1 and V2 on Employee and Assignment can be constructed in the followingway (<*> denotes the join-operation):V1 ← (F15 <a> F16) <a> (F13 <a> F14) <*> ((F5 <a> F6) <c> (F7 <a> F8)) <a> (F9 <a> F10) <a> (F11 <a> F12)V2 ← (F15 <a> F16) <a> (F13 <a> F14) <*> (F7 <a> F8) <a> (F9 <a> F10) <a> (F11 <a> F12) Depending on the view the conceptual multilevel relations look differentfor different users. For example, the relation Assignment consists for users V1of {F5, ..., F12}, for users V2 of {F7, ..., F12}, and for users V3 of {F11, F12}only.
  31. 31. - 31 - (a) Dominance Schema (b) Data Schema View Clear Dominates Attribute Integrity Constraint F V1 E A, B, C, D, a1, SSN SSN ⊆ F7[SSN] F5 a2, b1, b2, b3, Title Title ⊆ F3[Title] b4, b5, b6, c1, Function c2, c3, c4, c5, c6, d1, d2 SSN SSN ⊆ F8[SSN] F6 Title Title ⊆ F1[Title] ∪ F4[Title] V2 D B, a1, a2, b2, Function b3, b4, b5, b6, c4, c5, c6 SSN SSN ⊆ F13[SSN] ∪ F14[SSN] F10 Title Title ⊆ F1[Title] ∪ F4[Title] V3 B a1, a2, b4, b6 Date Function V4 A b1,c1, c2 SSN SSN ⊆ F15[SSN] F11 V5 C a1, a2, b1, b2, Title Title ⊆ F3[Title] b3, b5, c3 Date Function ... ... ... (c) Decomposition Schema Fragment Class Parent Operator Brother ... ... ... ... ... F5 c3 IF22 <a> F6 F6 d2 IF22 <a> - F7 b2 IF21 <a> F8 IF21 - IF2 <c> IF22 IF22 - IF2 <c> - IF1 - Assignment <a> IF2 IF2 - Assignment <a> - Assignment - ℜ <*> Project FIG. 5: AMAC Catalog Relations To maintain the database decomposition, to construct the multilevelrelations, and to control the integrity of the database three catalog relations arenecessary in AMAC: the Decomposition Schema, the Data Schema, and theDominance Schema. Figure 5 contains part of the catalog relations that resultedfrom the decomposition of the example database.
  32. 32. - 32 -• Decomposition Schema The schema contains the mapping of the decomposition structure into a flat table. Its contents is necessary in order to reconstruct multilevel relations from single-level fragments.• Dominance Schema The schema is used to model the allocation from fragments to users. Whenever a user supplied query tries to access a multilevel relation, the system has to make sure, that the access request does not violate the security policy of the organization. For example, if we have the rule that the clearance of the user must dominate the classification of the referenced data it can be done by using the information from the Decomposition Schema and the Dominance Schema.• Data Schema The Data Schema contains the schema definitions of the fragments and a set of integrity conditions that must be valid for every tuple in the fragment. Update operations performed on tuples in horizontal fragments may lead to the transfer of tuples to other horizontal fragments. This occurs, if the update changes the value of a selection predicate to a value beyond the domain of this attribute in the fragment. By using the information from the data schema it is always possible to determine the valid domain of selection attributes in fragments and to route tuples to the proper fragments in the case an update- or insert-operation is performed. So far we have shown how security requirements can be expressed inAMAC during database design by means of structured decomposition. InPernul (1992a) it is shown how the requirements can be enforced duringdatabase operation by means of database triggers. Triggers are implemented inmost DBMS-products and can be used to perform hidden actions withoutknowledge of the users. Generally speaking, a trigger consists of two parts. Thefirst part, the trigger definition, specifies when the trigger should be invokedwhile the second part, the trigger action, defines the actions the trigger shouldperform. We see triggers as an alternative way to implement a security policy. In the following we will specify the simple security property (read access)of BLP by means of a select trigger. Similar triggers have been developed byPernul (1992a) for the insert-statement (write access) and have been outlinedfor the update- and delete-statements. For the following assume a user having aclearance of C logged on to the system. Based on the information of theDominance Schema the set of security classifications {c1,...,cn} withC≥{c1,...,cn} can be derived. Any process operating on behalf of the user tryingto access any fragment with schema FS(attr,ld,c’) and c’∉{c1,...,cn} is not
  33. 33. - 33 -properly authorized and thus corresponding fragments may not be effected byoperations performed by the C-level user. Because of security reasons thedatabase fragmentation must be completely transparent to the users and usersmust be supported with the name of base relations even if they are authorized toaccess a subset of a multilevel relation only. Read-access is performed by means of a Select-statement which has thefollowing form: SELECT -attribute list- FROM -base relations- WHERE -p- Every query contains as parameter the identification of the user and the setof referenced base relations. Every multilevel base relation has assignedtriggers which are executed when the base relation is effected by acorresponding operation. As an example consider the definition of a Select-trigger as specified below. Here, %X denotes a parameter, the keywordDOWN_TO the transitive closure of the base relation (i. e. the set of fragmentsresulted from a base relation). The trigger specified implements the simplesecurity property of BLP.CREATE TRIGGER Select_Trigger ON each_base_relation FOR SELECT AS BEGIN declare @dominates, @classification SELECT @dominates = SELECT Dominates FROM Dominance Schema WHERE View = %V SELECT @classification = SELECT Class From Decomposition Schema WHERE Parent = %specified_base_relation DOWN_TO each_resulting_fragment IF @dominates ∩ @classification ≠ ∅ THEN perfom query for each element IN (@dominates ∩ @classification) ELSE Print ‘Base relation not known to the system’ Rollback TransactionEND Select_TriggerAs an example consider a user belonging to class V3 who wants to know thenames of all employees and their function in assigned projects. Please note,users with view V3 should be prevented from accessing data concerningemployees that earn more than 80. The user issues the following query: SELECT Name, Function FROM Employee, Assignment WHERE Employee.SSN = Assignment.SSN Applied to this example and the clearance assigned to users with view V3@dominates = {a1, a2, b4, b6}, @classification = {d2, c3, c4, c5, c6, b2, b3, b4, b5,b6, a1, a2}, and @dominates ∩ @classification = {a1, a2, b4, b6}. Thus, thequery is automatically routed to the corresponding fragments F11, F12, F15, F16
  34. 34. - 34 -and based on the information of the Decomposition Schema V3 can beconstructed by using the inverse decomposition operation, i. e. V3 ← (F15 <a>F16) <*> (F11 <a> F12). The outcome of the Select operation is in accordancewith the simple security property of BLP. 2.4 The Personal Knowledge Approach The personal knowledge approach is focused on protecting the privacy ofindividuals by restricting access to personal information stored in a database orinformation system. The model serves as the underlying security paradigm ofthe prototype DBMS Doris (Biskup and Brüggemann, 1991). The main goal ofthis security technique is to meet the right of humans for informational self-determination as requested in Constitutional Laws of many countries. In thiscontext, privacy can be summarized as the basic right for an individual tochoose which elements of his/her private life may be disclosed. In the model,all individuals, users as well as security objects, are represented by anencapsulated person object (in the sense of object-oriented technology). Thedata part of an object corresponds to the knowledge of the individual abouthimself/herself and his/her relationship to other persons. The operation part ofan object corresponds to the possible actions the individual may perform. The approach is built on the assumption that a person represented in thedatabase knows everything about himself/herself and if he/she wants to knowsomething about someone else represented in the database that person must beasked. Knowledge about different persons cannot be stored permanently andtherefore must be requested from the person whenever the information isneeded. To achieve this high goal, the personal knowledge approach asdeveloped by Biskup and Brüggemann (1988, 1989) combines techniques ofrelational databases, object oriented programming, and capability basedoperating systems. More technically it is based on the following constructs:Persons A person object either represents information concerning an individualabout whom data is stored in the information system or represents the users ofthe system. Each person is an instance of a class, called group. Groups form ahierarchy and in accordance with object-oriented concepts a member of a grouphas the components of the group as well as inherited components from all itssupergroups. More technically an individual person object is represented by aNF2-tuple (non-first-normal-form, i. e. may have non-atomic attribute values)with entries of the form: t (Surrogate, Knows, Acquainted, Alive, Available, Remembers) where
  35. 35. - 35 -• Surrogate is a unique identifier which is secretly created by the system.• Knows is application dependent, organized as a relation with a set of attributes {A1, ..., An}, and represents the personal knowledge of the person object.• Acquainted is a set of surrogates representing other person objects the person is aware of.• Alive is a boolean value.• Available contains the set of rights the person has made available to others.• Remembers may contain a set of records describing messages sent or received. Each person is represented as an instance of a group. All persons in a grouphave the same attributes, operations, roles, and authorities. The operation partof an object consists of system defined operations which are assigned togroups. Examples of common system defined operations are: create (creates anew instance of a group); tell (returns the value of attribute Knows); insert,delete, and modify (transform Knows); acquainted (returns the value forAcquainted), and others.Communication between acquainted objects Persons are acquainted with other persons. A person individually receiveshis/her acquaintances by using the operation ‘grant’. The set of acquaintancesof a person describes the environment of this person and denotes the set ofobjects the person is allowed to communicate with. Communication isperformed by means of messages that may be sent from a person to his/heracquaintances for querying about their personal knowledge or for asking toperform an operation, for example, to update the knowledge.Roles and authorities Depending on the authority of the sender the receiver of a message mayreact in different ways. The authority of a person with respect to anacquaintance is based on the role the person is currently acting in. While the setof acquaintances of a person may change dynamically authorities and roles arestatically declared in the system. When a person is created as an instance of agroup it receives the authorities declared in this group and in all itssupergroups.Auditing Each person remembers the messages the person is sending or receiving.This is established by adding all information about recent queries and updatestogether with the authorities available at that time to the ‘knowledge’ (attributeRemembers) of the sender and receiver person. Based on this informationauditing can be performed and all transactions can be traced by just ‘asking’ the
  36. 36. - 36 -effected person. Security (privacy) enforcement based on the personal knowledge approachis based on two independent features. Firstly, after login each user is assignedas instance of a person object type and thus holds individually receivedacquaintances and statically assigned authorities on roles. Secondly, whenevera user executes a query or an update operation the corresponding transaction isautomatically modified such that resulting messages are only sent to theacquaintances of the person. Summarizing, the personal knowledge approach isfine-tuned to meet the requirements of informational self-determination. Thus,it has main advantage as the underlying security paradigm for databaseapplications in which information about humans not available to the public iskept; for example, hospital information systems or databases containing censusdata. 2.5 The Clark and Wilson Model This model was first summarized and compared to MAC by Clark andWilson (1987). The authors argue that their model is based on concepts that arealready well established in the pencil-and-paper office world. These are thenotion of security subjects, (constraint) security objects, a set of well-formedtransactions and the principle of separation of duty. If we transfer theseprinciples to the database and security world we interpret them as follows: Theusers of the system are restricted to execute only a certain set of transactionspermitted to them and each transaction operates on an assigned set of dataobjects only. More precisely, we interpret the Clark and Wilson approach in thefollowing way: (1) Security subjects are assigned to roles. Based on their role in anorganization users have to perform certain functions. Each business role ismapped into database functions and ideally at a given time a particular user isplaying only one role. A database function corresponds to a set of (well-formed) transactions that are necessary for the users acting in the role. In thismodel it is essential to state which user is acting in what role at what time andfor each role what transactions are necessary to be carried out. To control theunauthorized disclosure and modification of data Clark and Wilson proposeaccess to be permitted only through the execution of certain programs, well-formed transactions, and that the rights of users to execute such code berestricted based on the role of each user. (2) Well-formed transactions. A well-formed transaction operates on anassigned set of data and assurance is needed that all relevant security andintegrity properties are satisfied. In addition it should provide logging and
  37. 37. - 37 -atomicity and serializability of resulting subtransactions in a way thatconcurrency and recovery mechanisms can be established. It is important tonote, that in this model the data items referenced by the transactions are notspecified by the user operating the transaction. Instead, data items are assigneddepending on the role the user is acting in. Thus, the model does not allow ad-hoc database queries. (3) Separation of duty. This principle requires that each set of users beingassigned a specific set of responsibilities based on the role of the user in theorganization. The only way to access the data in the database is through anassigned set of well-formed transactions specific to the role each of the usersplay. In those cases where a user requires additional information, another user(which is cleared at a higher level) acting in a separate role has to use a well-formed transaction from the transaction domain of the role he is acting in togrant the user temporary permission to execute a larger set of well-formedtransactions. Moreover, the roles need to be defined in a way that makes itimpossible for a single user to violate the integrity of the system. For example,the design, implementation, and maintenance of a well-formed transactionmust be assigned to a different role than the execution of the transaction. A first attempt to implement the concept of a well-formed transaction wasmade by Thomsen and Haigh (1990). The authors have compared theeffectiveness of two mechanisms for implementing well-formed transactions,Lock type enforcement (for Lock, see Subsection 3.2) and the Unix setuidmechanisms. With type enforcement, the accesses of the user processes to datacan be restricted based on the domain of the process and the type of data.Setuid and setgid features allow a user who is not the owner of a file toexecute the commands in the file with the permission of the owner. Althoughthe authors conclude that both mechanisms are suitable for implementing theClark and Wilson concept of a well-formed transaction no further studies andimplementation projects are known. The Clark and Wilson model has gained wide attention in recent years.However, although it looks very promising at a first glance, we believe adetailed and thoroughly investigation is still missing. In particular, the authorsonly address as potential threats to the security of a system the penetration ofdata by authorized users, unauthorized actions by authorized users, and abuseof privileges by authorized users. As identified at the beginning of this Chapterthese are only a subset of the necessary functionality of the required securityfeatures of a DBMS.