Your SlideShare is downloading. ×
Database security
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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-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- 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-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-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-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-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- 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- 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 -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 - 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 - 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 -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 -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 -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 -{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 - 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 -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 - 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 -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 -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 -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 - 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 -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 -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 - 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 - 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 -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 - 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 -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 - (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 -• 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 -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 -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 -• 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 -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 -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.
  • 38. - 38 - 2.6 A Final Note on Database Security Models In this Section we have discussed different approaches of how to expressdatabase security. In conclusion, although the models differ significantly webelieve all of the approaches discussed have their right to exist. The discretionary security approach may be the first choice if a high degreeof security is not necessary. Keeping the responsibility to enforce security at theusers side is only adequate if potential threats against security will not resultinto considerable damage. Even in the case a central authority is responsible forgranting and revoking authorizations DAC-based protection may still besubject to Trojan Horse attacks and cannot be recommended as a securitytechnique for security critical database applications. Mandatory policies are more effective because they imply that users do nothave control over the creation and alteration of security parameters. A securitypolicy suitable for a particular application may also have both a mandatory anda discretionary component. Furthermore, real systems often offer leaks on strictmandatory controls, for example, for privileged users such as systemadministrators and security officers. Such back-door entry points oftenrepresent a serious source of vulnerability. Multilevel applications may becomevery complex. What may help to counter this complexity is to develop aconceptual representation of the multilevel database application. We will comeback to this issue in Section 4 of this Chapter where we introduce a conceptualmodel for multilevel database security. Although very effective mandatory policies can only be applied inenvironments where labeled information is available. We believe that this is oneof the strongest points in favor of the AMAC security model. AMAC offers adesign environment for databases with main emphasis on the security. Itincludes discretionary as well as mandatory controls. However, the model lacksbecause of its restricted expressiveness. AMAC uses relational algebra toexpress security constraints and for certain applications this may not beexpressive enough to specify sophisticated security constraints. We interpret the personal knowledge approach as a means to implementdiscretionary controls. Letting person-objects decide whether to respond to aquery issued by another object seems to be very effective to control the privacyaspect of stored information. Privacy security may be an interesting alternativein applications where mostly personal information is maintained, for examplein hospital information systems. The Clark and Wilson model has gained wide attention in recent years.However, although it looks promising at a first glance, we believe a detailedand thoroughly investigation is still missing because major questions are not
  • 39. - 39 -solved yet. Many of the security relevant actions are segregated to applicationprograms and the model does not support ad hoc database queries. It is ourinterpretation that most of the requirements on the security of databases can beexpressed; however, this would cause tremendous application developmentcosts. 3. Multilevel Secure Prototypes and Systems Trusted systems are systems for which convincing arguments or proofsmust be given that the security mechanisms are working as advertised andcannot be subverted. A basic property of trusted systems is that these systemstend to be quite large with respect of the amount of code needed for theirimplementation. This is especially true for complex systems, for example, fortrusted database management systems (DBMSs). With today’s technology acomplete formal implementation proof of the system specifications is notpossible yet, although a great deal of research on formal specification andverification is currently in progress. The huge amount of code necessary is thereason that most trusted DBMSs have taken a very conservative approach toachieve a certain level of assurance, namely to reuse and build on previouslybuilt and verified trusted systems. This approach is known as TCB subsetting. A trusted computing base (TCB) is that part of a system which isresponsible for enforcing a security policy and may be any combination ofhardware, firmware, and operating system software. The term trustedcomputing base was defined in the Trusted Computer System EvaluationCriteria (TCSEC, 1985). The criteria defines seven levels of trust which rangefrom systems that have minimal protection features to those that provide thehighest level of security state-of-the-art security technique may produce. TheTCSEC is not the only proposal with the goal of defining objective guidelineson which security evaluations of systems may be based on. We will review theTCSEC and other proposals in Section 5 of this Chapter. TCB subsetting is identified as a strategy for building trusted DBMSs in theTrusted Database Interpretation (TDI, 1990) of the TCSEC. In this Section wewill discuss the most prominent projects with the goal to build systems thatmeet the requirements of the higher levels of trust as specified in the TDIevaluation criteria. For systems trying to get evaluated at higher levels of trustthe support of mandatory access controls is necessary. There have been threemain efforts to design and implement trusted relational database systems.SeaView, being implemented at SRI, LDV of Honeywell SCTC, and ASD ofTRW. Besides these (semi-) academic prototypes several vendors, includingIngres, Informix, Oracle, Sybase, Trudata, and others, have announced or
  • 40. - 40 -already released commercial systems supporting mandatory access controls.The systems not only differ in their details. Moreover, it is not even agreedabout what should be the granularity of the security object. For example,SeaView supports labeling at an individual attribute value level, LDV supportstuple-level labeling, in ASD_Views the security object is a materialized view,while some commercial systems do only support security labeling at therelation level or even on the database level. 3.1 SeaView The most ambitious and exciting proposal towards the development of atrusted DBMS has come from the SeaView project (for example see Denning etal. (1987) or Lunt (1990)). This project has began in 1987 and is a joint effortby Stanford Research Institute (SRI) International, Oracle, and GeminiComputers with the goal of designing and prototyping a multilevel securerelational DBMS. The most significant contribution of SeaView is the realization thatmultilevel relations must only exist at a logical level and can be decomposedinto single-level base relations. The advantage of these findings are mostlypractical. In particular, single level base relations can be stored by using aconventional DBMS and commercially available TCBs can be used to enforcemandatory controls with respect to single level fragments. The architectural approach taken by the SeaView project is to implementthe entire DBMS on top of the commercially available Gemsos TCB (Schell etal. 1985). Gemsos provides user identification and authentication, maintenanceof tables containing clearances, as well as a trusted interface for privilegedsecurity administrators. Multilevel relations are implemented as views oversingle-level relations. The single-level relations are transparent to the users andstored by using the storage manager of an Oracle DBMS engine. From theviewpoint of Gemsos every single level relation is a Gemsos security object ofa certain access class. Gemsos enforces the mandatory security policy based onthe Bell-LaPadula security paradigm. A label comparison is performedwhenever a subject attempts to bring a storage object into its address space. Asubject is prevented from accessing storage objects not in the subjects currentaddress space by means of hardware controls included in Gemsos. In addition to mandatory controls the SeaView security policy requires thatno user is given access to information unless that user has been granteddiscretionary authorization to the information. DAC-based protection isperformed outside Gemsos and allows users to specify which users and groupsare authorized for specific modes of access to particular database objects, as
  • 41. - 41 -well as which users and groups are explicitly denied authorization for particulardatabase objects. Since a multilevel relation is stored as a set of single-level fragments, twoalgorithms are necessary: 1. A decomposition algorithm which breaks multilevel relations into single-level fragments. 2. A recovery formula to reconstruct the original multilevel relation from the fragments. It is obvious that the recovery must yield to an identical result, otherwise decomposition and recovery is incorrect. In SeaView, the decomposition of multilevel relations into single-level onesis performed by applying vertical and horizontal fragmentation while recoveryby performing union- and join operations. For the following consider aconceptual multilevel relation R (A1, C1, ..., An, Cn, TC) where each Ai is anattribute defined over a domain Di and each Ci is a security class out of a list<TS, S, Co, U> where TS>S>Co>U. We assume A1 as being the apparentprimary key. The original SeaView decomposition algorithm (Denning et al.,1988) consists of three steps and can be outlined as follows: Step 1: The multilevel relation R is vertically partitioned into n projections R1[A1, C1], R2[A1, C1, A2, C2], ..., Rn[A1, C1, An, Cn]. Step 2: Each Ri is horizontally fragmented into one resulting relation for each security level. Obviously, for <TS, S, Co, U> this results into 4n relations. Step 3: In a further horizontal fragmentation R2, ..., Rn (i.e. 4n - 4 relations) are further decomposed into at most 4 resulting relations. The final decomposition is necessary because of the support of polyinstantiation. For this algorithm a performance study and a worst case analysis has beenperformed by Jajodia and Mukkamala (1991) and the authors have shown that amultilevel relation R (A1, C1, ..., An, Cn, TC) is decomposed in a maximum of(10n - 6) single level relations. The algorithm outlined above has been subject to extensive discussion inthe scientific literature. For example, Jajodia and Sandhu (1990b) pointed outthat the decomposition algorithm leads to unnecessary single-level fragments.Moreover, performing the recovery of multilevel relations requires repeatingjoins that may lead to spurious tuples. As an effect they have proposed tochange the polyinstantiation integrity property defined in the original SeaViewdata model by dropping the portion of the property that enforces a multivalueddependency. Their suggestions have led to a reformulation of the
  • 42. - 42 -polyinstantiation integrity by Lunt et al. (1990). In a further proposal, Jajodiaand Sandhu (1991b) give another algorithm that decomposes a multilevelrelation into single-level fragments and a new recovery algorithm whichreconstructs the original multilevel relation. In this proposal the recoveryalgorithm improves over earlier versions because decomposition uses onlyhorizontal fragmentation. Since no vertical fragmentations are required, it ispossible to reconstruct a multilevel relation without having to perform costlyjoin operations; only unions are required to be processed. Recently, Cuppensand Yazdanian (1992) have proposed a ‘natural’ decomposition of multilevelrelations in which they study functional dependencies and apply normalizationwhenever they try to decompose multilevel relations. As decomposition andrecovery is crucial for the SeaView performance it is expected thatinvestigating efficient decomposition techniques for fragmenting multilevelrelations into single-level fragments will remain a heavily discussed researchtopic in the future. A further contribution of SeaView was the development of a multilevelSQL (MSQL) database language (Lunt et al., 1988). MSQL is an extension ofSQL (Structured Query Language) and includes user commands for operatingon multilevel relations. The design includes a preprocessor that acceptsmultilevel queries and translates them into single-level standard SQL queriesoperating on the decomposed single-level fragments. 3.2 Lock Data Views Lock Data Views (LDV) is a multilevel secure relational DBMS, hosted onthe Lock TCB and currently prototyped at Honeywell Secure ComputingTechnology Center (SCTC) and MITRE. Lock supports a discretionary and amandatory security policy. The mandatory policy enforces the simple securityproperty and the restricted *-property of BLP. The authors of LDV have stated,that because of its operating system orientation the Lock security policy had tobe extended for the use in LDV (Stachour and Thuraisingham, 1990). Oneaspect of Lock, type enforcement, is of special interest for the increasedfunctionality of this TCB in LDV. The general concept of type enforcement in Lock and its use in LDV hasbeen discussed by Haigh et al. (1990). The main idea is that the accesses of asubject to an object are restricted by the role the subject is performing in thesystem. This is done by assigning a domain attribute to each subject and a typeattribute to each object and both are maintained within the TCB. Entries in thedomain definition table correspond to a domain of a subject and to a type listrepresenting the set of access privileges the subject has within the domain.
  • 43. - 43 - Lock’s type enforcement mechanism made it possible to encapsulate LDVin a protected subsystem, by declaring the database objects to be special Locktypes (Lock files) which are only accessible to subjects executing in the DBMSdomain. Since only DBMS programs are allowed to execute in this domain,only DBMS processes can access the Lock types holding portions of thedatabase. The remaining problem which had to be solved was to securelyrelease data from the DBMS domain to the user domain. Fortunately, Locksupports the implementation of assured pipelines that have been used in LDVto transfer the data between DBMS and user domains. Assurance is achievedthrough appropriate trusted import and export filters (hard- and softwaredevices). Two basic extensions to the Lock security policy have been performed inLDV. Both extensions concern the proper classification of data. The firstextension deals with the insert and update of data. During insert and update thedata is assigned to that Lock type classified with the lowest level at which thetuple can be stored securely. The second extension is concerned with queryresults. The result of a query is transferred from Lock types into ordinaryobjects and the appropriate security level of the query result is derived. The twopolicies are enforced in LDV by using three assured pipelines. These threepipelines are the query/response pipeline, the data/input pipeline, and thedatabase definition/metadata pipeline. The query/response pipeline is the query processor of LDV. The pipelineconsists of a set of processes which execute multi-user retrieval requests,integrate data from different Lock types, and output the information at anappropriate security level. First, a user supplied query is mapped from theapplication domain in the DBMS domain, then the query is processed, theresult is labeled and finally exported to the user. In order to prevent from logicalinference over the time the response pipeline includes a history function. Thismechanism can be used to trace the queries already performed for a particularuser and to deny access to relations based on the querying history of the user. The data/input pipeline is responsible for actions that need to be takenwhenever a user issues an insert, modify, or delete operation. First, the requesthas to be mapped from the application domain to the DBMS domain. Then, therequest must be processed. A delete request will only affect data at a singleclassification level (restricted *-property of BLP). For consistency reason, datais not actually removed but marked as deleted. Before the actual removal takesplace certain consistency checks are performed. More complicated is the casewhere the request is an insert operation. Classification rules that may be presentin the data dictionary (see database definition/metadata pipeline) may make itnecessary that the relation tuple is decomposed into different subtuples that are
  • 44. - 44 -stored in separated files, each of which with a different classification. Themodify request operates in a way similar to the insert operation. The database definition/metadata pipeline interacts with the LDV datadictionary and is used to create, delete, and maintain metadata. Metadata mayeither correspond to definitions of the database structure (relations, views,attributes, domains) or be classification constraints. Classification constraintsare rules that are responsible for assigning proper classification levels to thedata. The use of the metadata pipeline is restricted to a database administratoror database security officer (DBSSO). Here, again Lock type enforcementmechanisms are used to isolate the metadata in files that can only be accessedby the DBMS domain and DBSSO domain and not by the application domain. A few final words on the organization of a LDV database are in order. Datais distributed across Lock files and the basic schema is to assign a set of filesper security level. The data/input pipeline determines the appropriateassignment of data to files by examining the classification constraints stored inthe data dictionary. In LDV there is no replication of data across differentsecurity levels. The advantage of this approach is the simplicity of updates.However, it causes the disadvantage of a significant performance penalty forretrieval requests due to the necessity of a recovery algorithm. The recoveryalgorithm used in LDV is outlined by Stachour and Thuraisingham (1990). 3.3 ASD_Views ASD_Views, implemented on top of an existing DBMS called ASD, is aresearch project at TRW. ASD is a multilevel relational system offeringclassification at the tuple level. In 1988 attempts have started at TRW to extendASD and to chose views as the objects of mandatory as well as discretionarysecurity. Wilson (1988) has discussed the advantages and disadvantages of usingviews as the target of protection within ASD_Views. Among the advantages hestates the following:• Views are very flexible and can be used to define access control based on the content of data.• Τhe view definition itself documents the criteria used to determine the classification of data.• Arithmetic and aggregate functions could be used to define views.• Tuple level classification can be achieved by specifying horizontal views while attribute level classification by specifying vertical subsets of relations.
  • 45. - 45 -• Access control lists can be associated with views and can control discretionary access. Thus, the same concept could be used for mandatory protection and discretionary protection as well.However, there are also some major disadvantages when using views formandatory protection. Two of them are given below:• The view definitions may need to be considered within the TCB. View based DBMSs tend bo be very large, because views involve most code of the DBMS. Since a small TCB is required for a successful evaluation of the correctness of the specifications and the code, including the maintenance of views within the TCB would tremendously increase the verification effort.• Not all data are updateable through certain views. To overcome the disadvantages Garvey and Wu (1988) have included in anear-term design of ASD_Views the claim that each view must include acandidate key of the underlying base relation and moreover, the near-termdesign should only support a restricted query language to define secure views.The restrictions include that a view definition may describe a subset of datafrom a single base relation only and that joins, aggregate functions, andarithmetic expressions are not allowed. The authors of ASD_Views argue thatthese restrictions minimized the code of the TCB considerably. In ASD_Viewsthe restricted views are the security objects and base tables can only beaccessed through views. In ASD_Views the creation of a view must be trusted because otherwise aTrojan Horse in untrusted code could switch the names of two columns causingdata at a higher security level to become visible to a user logged in at a lowerlevel. During database initialization a trusted database administrator creates alltables and their associated views and assigns a classification level to each view.When a user logs in to ASD_Views a user process is created at the user’s loginclearance and discretionary and mandatory access checks on the referencedviews can be performed. Because ASD_Views is built on top of ASD the system may operate in thethree different modes of operation of ASD (Hinke et al., 1992). Under the firstmode of operation, the DBMS is a server in a local area network. Under thesecond mode of operation, the system can serve as a back-end DBMS for singlelevel or multilevel host computers. Under the final mode of operation, thesystem can serve as a host resident DBMS within a multilevel host running amultilevel secure operating system. 4. Conceptual Data Model for Multilevel Security
  • 46. - 46 - Designing a database is a complex and time consuming task, even more inthe case when attention must be given to the security of the resulting database,too. Database design, including the design of databases containing sensitivedata, is normally done by performing at least three main design phases (Fugini,1988). The first phase, conceptual design, produces a high-level, abstractrepresentation of the database application. The second phase, called logicaldesign, translates this representation into specifications that can beimplemented by using a DBMS. The third phase, called physical design,determines the physical requirements for the efficient processing of thedatabase operations. Conceptual and logical design can be performedindependently of the choice of a particular DBMS whereas physical design isstrongly system dependent. In this Section we will develop a conceptual data model for multilevelsecurity. Such a data model is of particular importance for a securityadministrator to get a clear understanding of the security semantics of thedatabase application. The model proposed combines well accepted technologyfrom the field of semantic data modeling with multilevel security. We will startwith identifying the basic requirements on a conceptual data model. The following characteristics of a conceptual database model are discussedin the literature (for example, see Elmasri and Navathe (1989), or Navathe andPernul (1992)):• Expressiveness: The data model must be powerful enough to point out common distinctions between different types of data, relationships, and constraints. Moreover, the model must offer a toolset to describe all of the application dependent semantics.• Simplicity: The model should be simple enough for a typical user or end user to use and to understand and should therefore have a diagrammatic representation.• Minimality: The model should have only a small number of basic concepts. Concepts must be not overlapping in their meaning.• Formality: The concepts of the model should be formally defined and should be correct. Thus, a conceptual schema can be seen as a formal unambiguous abstraction of reality. Semantic data models address these requirements and provide constructs torepresent the semantics of the application domain properly. In the proposedapproach for a semantic data model for security we use Chen’s Entity-Relationship (ER) model with enhancements needed for multilevel security.The decision to choose ER is motivated by the fact that this model isextensively used in many database design methodologies, has an effective
  • 47. - 47 -graphical representation, and is a de facto standard of most tools supporting thedatabase design. We will not discuss aspects related to data semantics, howeverwe will describe in detail the application dependent security semantics thatneed to be considered in a conceptual data model for multilevel security. Fordetails on the ER approach and questions related to the conceptual databasedesign the book by Batini et al. (1992) is recommended. Compared to the huge amount of published literature on semantic modelingand conceptual design of databases not much work has been done investigatinginto security semantics of multilevel secure database applications. Onlyrecently, several research efforts have started to provide tools and assistance toaid a designer in creating a multilevel database application. The first attempt touse a conceptual model to represent security semantics was made in Smith(1990a) and Smith (1990b). The author develops the semantic data model forsecurity (SDMS) based on a conceptual database model and a constraintlanguage. This was a careful and promising first step which has influenced allfollowing approaches. A more recent approach has been made within theSPEAR project (Wiseman (1991), Sell (1992)). SPEAR is a high-level datamodel and similar to the ER approach. The model consists of an informaldescription of the application domain and of a mathematical specification usinga formal specification language. Two further related projects are known. Bothprojects consider to include dynamics, in addition to modeling the static of theapplication, within the conceptual modeling process. In Burns (1992) the ERmodel has been extended to capture limited behavior by including theoperations ‘create’, ‘find’, and ‘link’ into the conceptual databaserepresentation whereas in Pernul (1992b) ER has been used to model the staticpart of a MLS application and data flow diagramming to model the behavior ofthe system. The discussion in the following Subsection will partly adopt thegraphical notation developed in Pernul (1992b). The proposal made in this Section will considerably extend previous workon security semantics by• carefully defining the major security semantics that need to be expressed during the design of a multilevel application, by• outlining a security constraints language (SCL) for expressing corresponding rules in a conceptual model of the application, by• providing a graphical notion for constraints expressed in the ER model, by• giving general rules to detect conflicting constraints specified, and by• suggesting to implement the constraint system in a rule-based system. This may help to achieve completeness and consistency of security semantics specified.
  • 48. - 48 - 4.1 Concepts of Security Semantics Security semantics are defined as all security relevant knowledge about theapplication domain. They are mainly concerned with the secrecy and privacyaspect of information (maintaining confidentiality against the risk ofdisclosure) and with the integrity aspect of information (assuring that data isnot corrupted). Within the framework of multilevel security, security semanticsbasically consist of rules (security constraints) classifying both data and queryresults. The rules are specified by a database designer and must properlyrepresent the level of sensitivity of the data classified. When consideringsecurity semantics, there are a few concepts that deserve special attention whendeveloping classification constraints:• Identifier A property which allows to identify an object of the real world uniquely is called its key or identifier. Additionally, when considering security semantics there is the notion of a near-key, which is a property that identifies a particular object not uniquely but most of the time. For example, SSN of an employee is a key while the property Name is its near- key.• Content The sensitivity of an object of a certain type is usually dependent on its content, i. e. the actual data values or associations of data with metadata make an object classified.• Hiding the existence In security critical applications it may be necessary to hide the existence of classified data, i. e. it is not sufficient to provide unauthorized users with null values of certain facts.• Attribute - attribute value Most data will make sense only when combined with metadata. As a result, when we refer to a classified property, it means that both the property and its value are classified.• Non-conflicting constraint set For large applications it might be necessary that a large set of security constraints need to be expressed at the conceptual database level. Checking for consistency of the constraints specified is one of the more difficult tasks of the design. In the proposed approach it is distinguished between two kinds of conflicts. Depending on the kind of conflict the conflicts are either resolved automatically or notified to the designer who may decide about a proper resolution strategy.
  • 49. - 49 -• Default security level A set of classification constraints is complete if every piece of data is assigned a classification level via the classification constraints. In our approach we enforce completeness by ensuring that every piece of data has a default classification. The security level public may not be assigned explicitly. It is used as an initial classification in order to ensure completeness. If there is no further classification rule applicable for certain data, public has the semantic meaning that data is not classified at all. In the following we give a taxonomy of security semantics which consistsof the most common application dependent requirements on multilevelsecurity. Each requirement will be formally defined, expressed in a securityconstraint language (SCL), graphically included in the notion of the ER model,and explained by means of an example. We will start with defining the basicconcepts. An object type O is a semantic concept of reality that is described by certainproperties. Using ER terminology, O might be an entity type, a specializationtype, a generic object, or a relationship type. In a security terminology, O is thetarget of protection and might be denoted by O (A1, ..., An). Ai (i=1..n) is acharacteristic property and defined over a domain Di. Each security object musthave an identifying property A (A ⊆ {A1, ..., An}) which makes instances(occurrences) o of O (o = {a1, ..., an}, ai ∈Di) distinguishable from others. Moving to a multilevel world the major question involved is in which wayshould the properties and occurrences of O be assigned to proper securityclassifications. The process of assigning data items to security classifications iscalled classifying and results into the transformation of a security object O intoa multilevel security object Om (O ⇒ Om). The transformation is performed bymeans of security constraints. For the following we assume Om being a flat tablefollowing the definition of a MLS relation of the Jajodia-Sandhu modelintroduced in Subsection 2.2.2 of this Chapter.
  • 50. - 50 - Secrecy Levels (U) (Co) (S) (TS) Ranges of Secrecy Levels [U..S] [Co..TS] Association leading to S (NK .. near-key attribute) NK Aggregation leading to TS (N .. constant) N Inference leading to Co × Security dependency Evaluation of predicate P P FIG. 6. Graphical Extensions to the ER Figure 6 contains the graphical extensions proposed to the Entity-Relationship model. These extensions are very simple but offer a powerful toolto represent very complex application dependent security constraints. They arestated in terms of sensitivity levels, ranges of sensitivity levels, securitydependencies, predicates, association-, aggregation-, and inference constraints.For simplicity we do only distinguish between four different levels ofsensitivity. In the case a finer granularity is required the model can easily beextended to capture additional levels. A sensitivity level may be assigned to anystructural concept of the ER model. In the case occurrences of a security objectare not uniformly labeled a valid range of classifications is indicated by placingcorresponding abbreviations next to the concept. In this case the concept itselfmust show a level that is dominated by all classifications of the instances orproperties of the security object. The concept of a security dependency isintroduced in order to indicate the origin of a classification. Predicates areincluded to express constraints that are dependent on the content of securityobjects. Predicates cannot be specified in the diagrammatic representation butare expressed by means of the security constraint language SCL. The othergraphical extensions will be discussed when introducing the corresponding
  • 51. - 51 -classification constraints. The model proposed distinguishes between two kinds of securityconstraints: application independent and application dependent. Applicationindependent constraints must be valid in every multilevel database whereasapplication dependent constraints are specified by the database designer. Byfollowing the proposed methodology designing a multilevel databaseapplication is a two phase activity. In a first design phase the designer specifiesthe application dependent security requirements by using ER modelingtechniques together with SCL. In a second phase the constraints are analyzedbecause constraints specified may conflict with others or may violateapplication independent rules. In the semantic data model for multilevelsecurity proposed, in a final design step the constraints are checked forconflicts, conflicting constraints are resolved and the non-conflicting constraintset is used to construct the conceptual representation of the multilevelapplication. Consistency and conflict management will be discussed inSubsection 4.3 in more detail. 4.2 Classification Constraints In the following we give a taxonomy of the most relevant securitysemantics that should be expressed in a conceptual data model. Theseconstraints have been initially defined by Pernul et al. (1993). Among theapplication dependent classification constraints it is distinguished between twokinds: a) constraints that classify characteristic properties of security objects(simple, content-based, complex, and level-based constraints) and b)constraints that classify retrieval results (association-based, inference, andaggregation constraints). The examples considered will focus on the Project-Employee database as given in the Introduction. We assume the existence of asingle category only and a list SL of four sensitivity levels, denoted by SL =<TS, S, Co, U>. Please note, the default level public is not in SL and thereforemay not be assigned except for initializing.4.2.1 Simple Constraints Simple constraints classify certain characteristic properties of securityobjects. For example classifying the characteristic property that employeeshave a salary (i. e. classifying property Salary) or classifying the fact thatemployees are assigned to projects are examples of simple security constraints.• Definition: Let X be a set of characteristic properties of security object
  • 52. - 52 - O (X ⊆ {A1, ..., An}). A simple security property SiC is a classification of the form SiC (O (X)) = C, (C ∈ SL) and results into a multilevel object Om (A1, C1, ..., An, Cn, TC) whereby Ci = C for all Ai ∈ X, Ci left unchanged for the remaining Ai ∉ X.• SCL predicate: SiC (O, X, C), where O is the security object under consideration, X is the set of characteristic properties to be classified and C is the desired security level.• Example and graphical representation: Property Function of Assignment is regarded as confidential information. SiC (Assignment, {Function}, S) SSN Date Function Title Name Employee N M Project Subject Dep Salary Assignment Client SSN Title FIG. 7. Graphical Representation of Simple Constraint4.2.2 Content-based Constraints Content-based constraints classify characteristic properties of securityobjects based on the evaluation of a predicate defined on specific properties ofthis object.• Definition: Let Ai be a characteristic property of security object O with domain Di, let P be a predicate defined on Ai and let X ⊆ {A1, ..., An}. A content-based constraint CbC is a security classification of the form CbC (O (X), P: Ai θ a) = C or CbC (O (X), P: Ai θ Aj) = C (θ ∈ {=, ≠, <, >, ≤, ≥}, a ∈ Di, i ≠ j, C ∈ SL). A predicate may be combined with other predicates by means of logical operators. For any instance o of security object O(A1, ..., An) for which a predicate evaluates into true the transformation into o(a1,c1,...,an,cn,tc) is performed. Classifications are assigned in a way that ci = C in the case Ai ∈ X, ci left unchanged otherwise.• SCL predicate: CbC (O, X, A, Theta, V, C), where O is the security object under consideration, X is the set of characteristic properties to be classified, A is the evaluated characteristic property Ai, Theta is the
  • 53. - 53 - comparison operator, V is the comparison value a or characteristic property Aj, and C is the security level desired.• Example and graphical representation: Properties SSN and Name of employees with a salary ≥ 100 are treated as confidential information. CbC (Employee, {SSN, Name}, Salary, ‘≥’, ‘100’, Co) SSN Date Function Title Name P Employee N M Project Subject Dep Salary Assignment Client SSN Title FIG. 8. Graphical Representation of Content-based Constraint4.2.3 Complex Constraints Complex security constraints involve two different security objectsparticipating in a dependency relationship. They are treated similar to thecontent-based constraints with the only difference, that the predicate isevaluated on a specific property of the independent security object yielding to aclassification of properties of the associated dependent security object.• Definition: Let O, O’ be two security objects and the existence of an instance o of O is dependent on the existence of a corresponding occurrence o’ of O’ whereby the k values of the identifying property K’ for o’ are identical to k values of characteristic properties of o (foreign key). Let P(O’) be a valid predicate (in the sense of content-based constraints) defined on O’ and let X ⊆ {A1, ..., An} be an attribute set of O. A complex security constraint CoC is a security classification of the form CoC (O (X), P(O’)) = C (C ∈ SL). For every instance o of security object O(A1, ..., An) for which the predicate evaluates into true in the related object o’ of O’ the transformation into o(a1, c1, ..., an, cn, tc) is performed. Classifications are assigned in a way that ci = C in the case Ai ∈ X, ci left unchanged otherwise.• SCL predicate: CoC (OD, X, O, A, Theta, V, C), where OD is the dependent security object under consideration, X is the set of characteristic properties of OD to be classified, A is the evaluated
  • 54. - 54 - characteristic property Ai of O’, Theta is the comparison operator, V is the comparison value a or characteristic property Aj of O’, and C is the security level desired.• Example and graphical representation: Individual assignment data (SSN) is regarded as secret information in the case the assignment refers to a project with Subject = ‘Research’. CoC (Assignment, {SSN}, Project, Subject, ‘=’, ‘Research’, S) SSN Date Function Title Name Employee N M Project Subject Dep Salary Assignment Client SSN Title P FIG. 9. Graphical Representation of Complex Constraint4.2.4 Level-based Constraints Level-based security constraints are constraints classifying characteristicproperties based on the classification of some other properties of the samesecurity object. This signifies that for all instances of the security object theconcerned characteristic properties are always enforced to be at the samesecurity level.• Definition: Let level (Ai) be a function that returns the classification ci of the value of characteristic property Ai in object o(a1, c1, ..., an, cn, tc) of a multilevel security object Om. Let X be a set of characteristic properties of Om such that X ⊆ {A1, ..., An}. A level-based security constraint LbC is a classification of the form LbC(O (X)) = level (Ai) and results for every object o(a1, c1, ..., an, cn, tc) to the assignment cj = ci in the case Aj ∈ X.• SCL predicate: LbC (O, X, A), where O is the security object under consideration, X is the set of characteristic properties to be classified, and A is the determining characteristic property.• Example and graphical representation: Property Client of security object Project must always have the same classification as the property
  • 55. - 55 - Subject of the Project. LbC (Project, {Client}, Subject) SSN Date Function Title Name Employee N M Project Subject Dep Salary Assignment Client SSN Title FIG. 10. Graphical Representation of Level-based Constraint While the constraints considered above classify characteristic properties ofsecurity objects, the following additional constraints classify the retrievalresults. This is necessary, because security may require that the sensitivity ofthe result of a query is different from the classifications of the constituentsecurity objects. In that way we cover the logical association, the aggregation,and the logical inference problem.4.2.5 Association-based Constraints Association-based security constraints restrict from combining the value ofcertain characteristic properties with the identifying property of the securityobject in the retrieval result. This permits the access to collective data butprohibits the user from relating the properties to the individual instances of thesecurity object.• Definition: Let O (A1, ..., An) be a security object with identifying property K. Let X ⊆ {A1, ..., An} (K ∩ X = {}) be a set of characteristic properties of O. An association-based security constraint AbC is a classification of the form AbC(O (K,X)) = C (C ∈ SL) and results in the assignment of security level C to the retrieval result of each query that takes X together with identifying property K.• SCL predicate: AbC (O, X, C), where O is the security object under consideration, X is the set of characteristic properties to be classified when retrieved together with the identifying property, and C is the security level.• Example and graphical representation: The example considers the
  • 56. - 56 - salary of an individual person as confidential while the value of salaries without the information which employee gets what salary as unclassified. AbC (Employee, {Salary}, Co) SSN Date Function Title Name Employee N M Project Subject Dep Salary [Co] Assignment Client SSN Title FIG. 11. Graphical Representation of Association-based Constraint4.2.6 Aggregation Constraints Under certain circumstances the combination of several instances of asecurity object may be regarded as more sensitive than a query result consistingof a single instance only. This phenomenon is known as the aggregationproblem. It occurs in cases where the number of instances of a query result isexceeding a constant value specified.• Definition: Let count(O) be a function that returns the number of instances referenced by a particular query and belonging to security object O (A1, ..., An). Let X (X ⊆ {A1, ..., An}) be sensitive characteristic properties of O. An aggregation security constraint AgC is a statement of the form AgC (O, (X, count(O) > n)) = C (C ∈ SL, n ∈ Ν) and results into the classification C for the retrieval result of a query in the case count(O) > n, i. e. the number of instances of O referenced by a query accessing properties X exceeds the value n.• SCL predicate: AgC (O, X, N, C), where O is the security object under consideration, X is the set of characteristic properties, N is the specified value n, and C is the security level of corresponding queries.• Example and graphical representation: The information which employee is assigned to what projects is regarded as unclassified. However, aggregating all assignments for a certain project and thereby inferring which team (aggregate of assigned employees) is responsible for what project is considered secret. To master this situation a maximum value of n = 3 should be specified.
  • 57. - 57 - AgC (Assignment, {Title}, ‘3’, S) SSN Date Function Title Name Employee N M Project Subject Dep Assignment Client Salary SSN Title 3 FIG. 12. Graphical Representation of Aggregation Constraint4.2.6 Inference Constraints Inference constraints restrict from using unclassified data to infer datawhich is classified. Inferences can occur because of hidden paths that are notexplicitly represented in the conceptual data model of the multilevelapplication. The hidden paths may also involve knowledge from outside thedatabase application domain.• Definition: Let PO be the set of multilevel objects involved in a potential logical inference. Let O, O’ be two particular objects from PO with corresponding multilevel representation O (A1, C1, ..., An, Cn, TC) and O’ (A’1, C’1, ..., A’m, C’m, TC’). Let X ⊆ {A1, ..., An} and Y ⊆ {A’1, ..., A’m}. A logical inference constraint IfC is a statement IfC (O(X), O’(Y)) = C and results into the assignment of security level C to the retrieval result of each query that takes Y together with the properties in X.• SCL predicate: IfC (O1, X1, O2, X2, C), where O1 is the first security object involved, X1 is a set of characteristic properties of O1 that might be used for logical inference, O2 is the second security object, X2 attribute set of O2, and C is the security level of corresponding queries.• Example and graphical representation: As an example consider the situation where the information which employee is assigned to what projects is considered as confidential. Consider further, that from having access to the department an employee works for and to the subject of a project, users (having certain knowledge from outside the system) may infer which department may be responsible for the project and thus may conclude which employees are involved. The situation is modeled below.
  • 58. - 58 - IfC (Employee, {Dep}, Project, {Subject}, Co) SSN Date Function Title Name Employee N M Project Subject Dep Assignment Client Salary SSN Title × FIG. 13. Graphical Representation of Inference Constraint 4.3 Consistency and Conflict Management The classification constraints as specified by the designer have to be storedin a rule-base. For complex applications it might be necessary that a large set ofsecurity constraints need to be expressed at the conceptual database level.Checking for consistency of the constraints is one of the more difficult tasks ofthe design. For this purpose an automated tool is proposed which dynamicallyassists a designer in specification and refinement of the security constraints.The tool has to ensure that the consistency of the rule-base is satisfied whenevera classification constraint is updated or a new constraint is inserted in the rule-base. In the proposed conceptual model for multilevel security two types ofconflicts are distinguished. The first type is concerned with conflicts amongapplication dependent and application independent constraints. By expressingthe security semantics on the conceptual schema, application independentmultilevel constraints might be violated. In the proposed system, these conflictsare detected automatically, the conflicts are resolved and finally notified to thedesigner. However, in the case an application dependent security constraint is inconflict with an application independent constraint the designer is not given apossibility to override the changes performed by the tool. The second kind ofconflict deals with conflicting application dependent security constraints. Suchconflicts are notified to the designer who may decide about a properclassification. As a default strategy the tool suggests the maximum of theconflicting security levels to guarantee the highest degree of security possible.The following is the set of integrity constraints which are considered and thatthe set of classification constraints must satisfy:
  • 59. - 59 -• [I1]: Multilevel Integrity. Each property must have a security level. This is satisfied because during initial classifying all properties are assigned to the default security level.• [I2]: Entity Integrity. All properties forming an identifying property must be uniformly classified and must be dominated by all the other classifications of the object. The tuple-class must dominate all classifications. A multilevel security object Om with identifying property K (apparent key) satisfies entity integrity property if for all occurrences o (a1, c1, ..., an, cn, tc) of Om 1. Ai, Aj ∈ K ⇒ ci = cj 2. Ai ∈ K, Aj ∉ K ⇒ ci ≤ cj 3. tc ≥ ci (i=1..n).• [I3]: Foreign key property. The level assigned to a foreign key must dominate the level of the corresponding identifying property. The foreign key property guarantees that no dangling references between depending objects will occur. Let K be identifying property in multilevel security object Om (A1, C1, ..., An, Cn, TC) and let it be a foreign key K’ in a dependent object O’m (A’1, C’1, ..., A’k, C’k, TC’). Foreign key property is satisfied if for any two dependent occurrences o(a1, c1, ..., an, cn, tc) of Om and o’(a’1, c’1, ..., a’k, c’k, tc’) of O’m Ai ∈ K, A’j ∈ K’ ⇒ ci ≤ c’j• [I4]: Near-key property. Near key property is important in the case an association-based constraint AbC (O, X, C) is specified. In this case C is also propagated to each query that takes a near-key instead of the identifying property of O together with attribute set X.• [I5]: Level-based property. In order to avoid a transitive propagation of security levels between level-based constraints specified, for any two LbC(O, X, A) and LbC(O, X’, A’) A ∉ X’ and A’ ∉ X must hold. Additionally, because of the entity integrity a LbC may not be defined on an attribute set including the identifying property.• [I6]: Multiple-Classification property. Each value of a characteristic property may only have a single classification. In the case different security constraints assign more than one level to a particular property value the conflict must be notified to the designer who may decide whether to apply the default resolution strategy or not.
  • 60. - 60 - 4.4 Modeling the Example Application Classifying is performed by stepwise insertion of security constraints intothe rule-base. Declaring a new constraint is an interactive process between tooland designer whereby each constraint is validated against the integrityconstraints specified above. In the case a conflict is detected which violates anapplication independent integrity constraint the constraint is enforced bypropagating the required classification to the characteristic properties involved.In the case a conflict is due to multiple-classification the conflict is notified andthe designer may decide whether to accept the default resolution strategy ornot. Let us now apply the classification requirements to the example design. Forconvenience, the corresponding rules specified in SCL are given below oncemore. 1) SiC (Assignment, {Function}, S) 2) CbC (Employee, {SSN, Name}, Salary, ‘≥’, ‘100’, Co) 3) CoC (Assignment, {SSN}, Project, Subject, ‘=’, ‘Research’, S) 4) LbC (Project, {Client}, Subject) 5) AbC (Employee, {Salary}, Co) 6) AgC (Assignment, {Title}, ‘3’, S) 7a) SiC (Assignment, {SSN, Title}, Co) 7b) IfC (Employee, {Dep}, Project, {Subject}, Co) Classifying starts with the assignment of the default classification level toevery characteristic property. Insertion of rule 1) results into the assignment ofS to property Function. No conflicts result. Insertion of rule 2) leads to the assignment of the range [∅..Co] toproperties SSN and Name of Employee. This is, in the case the predicateevaluates into true Co is assigned to the properties otherwise the classificationremains public (denoted by ∅). Because of the application independentintegrity constraint specifying that the classification of the identifying propertymust be dominated by all other classifications of an object the insertion of thisCbC causes a violation of entity integrity. As a consequence the classificationrange [∅..Co] is automatically propagated to the other properties of object typeEmployee as well. The identifying property of Employee (i. e. SSN) is alsoforeign key in Assignment. Because of foreign key property [∅..Co] must alsobe propagated to SSN of Assignment. There, classifying SSN with [∅..Co]violates the entity integrity causing in a first consequence the propagation of[∅..Co] to property Title (the key must be uniformly classified) and as a secondconsequence [∅..Co] to property Date and Function as well (all otherclassifications must dominate the key). As property Function is alreadyassigned to S, the first conflict arises and is notified to the designer. Let us
  • 61. - 61 -assume the designer confirms the suggested classification and Function remainsclassified at S. No further conflicts arise. The complex security constraint specified as rule 3) states that SSN ofAssignment is considered at S in the case an assignment refers to a project withSubject = ‘Research’. Inserting the constraint in the rule-base causes amultiple-classification conflict because [∅..Co] is already assigned to SSN ofAssignment. Let us assume the designer accepts the suggested defaultresolution strategy and [∅..S] is assigned to SSN. As the key must be uniformlyclassified this causes a conflict with entity integrity and [∅..S] is propagated toproperty Title as well. Because of the demand that the classification of theidentifying property must dominate all other classifications of the object, [∅..S]is also propagated to Date and Function. Propagating [∅..S] to attributeFunction causes a multiple-classification conflict. This is because of rule 1) thatalready has assigned a classification S. The conflict is notified to the designerand let us assume that the designer confirms the suggested default resolutionstrategy and S remains assigned. Figure 14 shows the state of design afterconflict resolution and before inserting constraint 4). SSN Date Function [∅..Co] [∅..S] Title Name Employee N M Project Subject [∅..Co] Dep Assignment Client [∅..Co] SSN Title Salary [∅..S] [∅..S] [∅..Co] FIG. 14. State of Design after constraint 3) Introducing the level-based constraint specified as rule 4) does not causeany conflicts. Inserting the association-based constraint specified as rule 5)causes a violation of the near-key integrity property. The conflict is resolved byincluding the near-key in the constraint. Inserting rule 6) does not cause any conflicts. Rule 7a) leads to multipleclassification because SSN and Title of Assignment are already classified at[∅..S]. Let us assume the designer accepts the default conflict resolutionstrategy [Co..S]. Because of enforcing entity integrity this causes thepropagation of [Co..S] to all other properties of Assignment as well. For
  • 62. - 62 -property Function a conflict arises because Function is already assigned to S.Let us again assume the designer accepts the suggested resolution strategy.Finally, the inference constraint (rule 7b) classifying certain query results isincluded in the conceptual model. Figure 15 contains the graphicalrepresentation of the conceptual data model of the example multilevelapplication after classifying and conflict resolution. A possible implementationof the graphical browser should provide a tracing facility giving the designer apossibility to trace back all classification steps that have led to certainclassifications. SSN Date Function [∅..Co] [Co..S] Title Name Employee N M Project Subject [∅..Co] Dep Assignment Client [∅..Co] Title 3 SSN Salary [Co..S] [Co..S] [∅..Co] × FIG. 15. Conceptual Model of the Example Database The contribution of this Section was the development of a semantic datamodel for multilevel security. The model provides an integrated approach formodeling both data and security semantics of a database application. Theproposal made in this Section extends previous work on semantic modeling ofsensitive information by carefully defining the security semantics considered,by providing a constraint language and a graphical notion to express them in aconceptual model, and by developing consistency criteria that the set ofclassification constraints specified must satisfy. The technique can be extendedin several directions: Firstly, for certain database applications it may also benecessary to model the dynamic aspects of information. A first step into thisdirection has already been made by Burns (1992) and Pernul (1992b).Secondly, the model needs to be completely implemented. So far, theimplementation has only a prototype status covering only the constraintslanguage SCL and conflict management. The implementation of the graphicalbrowser is left for further work. Another important issue to the databasecommunity is when to enforce the security constraints represented in the
  • 63. - 63 -conceptual representation of the database. In general, security constraints maybe enforced during database update, during query processing, as well as duringdatabase design. In the case the constraints are handled during database updatethey are treated by the DMBS similar to integrity constraints. In the case theconstraints are enforced during query processing they may be treated similar toderivation rules. That is, they are used to assign classifications before data isreleased from the DBMS domain into the user domain. In the case theconstraints are treated during the database design phase they must be properlyrepresented in the database structure and in the metadata. When to enforce theconstraints may be dependent on the kind of constraint considered. However, itis important to note that enforcing the constraints during query processing andduring database update will strongly influence the performance of the database.From this point of view it is necessary to include as many constraints aspossible during the design of the database. The technique proposed in thisSection serves as a valuable starting point for logical design, during which theconceptual representation of the database is transferred into a target data model,for example, into the multilevel relational data model. 5. Standardization and Evaluation Efforts Database security (and computer security in general) is currently subject tointensive national and international standardization and evaluation efforts. Theefforts have the goal to develop metrics to evaluate the degree of trust that canbe placed in computer products used for the processing of sensitiveinformation. Degree of trust means the level of assurance that the securityenforcing functions of a system are working as advertised. The basis of all the efforts has been the ‘Orange Book’ criteria (TCSEC,1985) issued by the U.S. National Computer Security Center (NCSC). Sincethen, the criteria have been used for evaluation of products in the U.S. and inmany other countries as well. Shortly after its release, the Orange Book hasbeen criticized because of its orientation towards confidentiality and secrecyissues and because of its main focus on centralized computer systems andoperating systems. As a consequence, the NCSC has issued two interpretationsof the Orange Book, the ‘Red Book’ an interpretation for networks and the‘Purple Book’ (TDI, 1990) an interpretation for databases. Together with otherdocuments issued by NCSC the standards are known as the ‘rainbow series’because of the color of their front pages. Within Europe there have been a number of national initiatives in thedevelopment of security evaluation criteria. Recognizing the common interest
  • 64. - 64 -and similar principles behind their work, four European countries (France,Germany, the Netherlands, and the United Kingdom) have cooperated in thedevelopment of a single set of harmonized criteria issued by the Commission ofthe European Communities (ITSEC, 1991). Besides these efforts, criteria setshave also been published from Canada and Sweden. Because of the ongoing internationalization of the computer product marketthere is a strong demand from industry for a harmonization between TCSEC,ITSEC, and the other proposals. The first step in this direction is the workperformed under the US Federal Criteria Project, currently as draft underpublic review. In the following we will briefly review the basic concepts of theOrange Book and show how they relate to corresponding concepts in theITSEC. The TCSEC defines four hierarchical ordered divisions (D,C,B,A) ofevaluation classes. Within each of the divisions there are one or morehierarchical classes. Figure 16, borrowed from the Orange Book, contains adetailed representation of this packaging. D-level criteria relate to all systems and products that cannot be evaluatedat the higher levels of trust. D-level requires no security features. Systems rated at a C-level support DAC which includes the support ofidentification, authentication, and auditing functions. At C1 DAC-basedprotection must only be provided at a user-group level while for C2 protectionat the individual user-level is required. Most commercially available generalpurpose DBMS products are evaluated at C2. At the B-level of the criteria security labels and mandatory access controlsare introduced. Enhancing existing DBMSs with ad-on security packages mayresult into the evaluation at B1 whereby for B2 and above the system must havebeen designed with security already in mind. At B2 emphasis is on assurance.For this purpose a formal security policy model must be developed, the role ofa system administrator and an operator is introduced, and security relevant codemust be separated into a TCB. B3 requires an increased level of assurancewhich is achieved by more testing and giving more attention to auditing.Emphasis at B3 is also directed toward minimizing and simplifying the code ofthe TCB. The A1 evaluation class is in its functionality identical to B3 but requiresformal and informal techniques to show and to proof consistency betweenspecification and formal security policy. It is not required to proof the sourcecode against the specification and against the formal security policy. Thesystems discussed in Section 3 of this Chapter were developed with the goal toget evaluated at the A1 level whereas most commercial DBMS systems that
  • 65. - 65 -support a mandatory security policy have been evaluated at the B1 or B2 level. C1 C2 B1 B2 B3 A 1 Discretionary access control Object reuse Labels Label integrity Exportation of labelled information Exportation of multilevel devices Security policy Exportation of single-level devices Labelling human-readable output Mandatory access controls Subject sensitivity labels Device labels Identification and authentication Accountability Audit Trusted paths System architecture System integrity Security testing Assurance Design specification and verification Covert channel analysis Trusted facility management Configuration management Trusted recovery Trusted distribution Security features user’s guide Documentation Trusted facility manual Test documentation Design documentation No additional requirements for this class New or enhanced requirements for this class No requirements for this class FIG. 16. Trusted Computer Security Evaluation Criteria Summary Chart NCSC-TCSEC (1985), Fig. 1, p. 109 It has been pointed out by several researchers (for example, Neumann,1992) that the TCSEC has deficiencies. Besides the fact that distributedsystems are not adequately covered (although the Red Book provides someguidelines) it is criticized that TCSEC• has its primary focus on confidentiality. Integrity and availability are not treated adequately.• Authentication considers only passwords. More advanced techniques are not included.• TCSEC provides inadequate defence against pest programs (Neumann, 1990).• Auditing data (and its real-time analysis) can provide an important aid in
  • 66. - 66 - protecting against vulnerabilities. This is not considered in the criteria. The ITSEC has been developed with some of the deficiencies of theTCSEC in mind and is intended to be a superset of the TCSEC. It definessecurity as being a combination of confidentiality, integrity, and availability anddistinguishes between two kinds of criteria: a functional criteria of tenhierarchical ordered divisions and a correctness criteria of seven divisions.Both criteria are evaluated separately. The functional criteria are used to evaluate the security enforcing functionsof a system. The functional criteria has been developed within the Germannational criteria project. The first five functionality divisions correspondclosely to the functionality classes of the TCSEC. The remaining fivefunctionality classes are intended as examples to demonstrate commonrequirements for particular types of systems. The correctness criteriarepresents seven levels of assurance in the correctness of the security features.The correctness criteria correspond roughly to the levels of assurance of theTCSEC and cumulatively require testing, configuration control, access todesign specification and source code, vulnerability analysis, formal andinformal verification of correspondence between specification, security model,and source code. Figure 17 relates the functional and correctness criteria of theITSEC to the corresponding evaluation classes of the TCSEC. ITSEC TCSEC functional correctness evaluation - E0 ⇒ D F-C1 E1 ⇒ C1 F-C2 E2 ⇒ C2 F-B1 E3 ⇒ B1 F-B2 E4 ⇒ B2 F-B3 E5 ⇒ B3 F-B3 E6 ⇒ A1 F-IN Data integrity - F-AV System availability - F-DI Communication integrity - F-DC Communication confidentiality - FIG. 17. Correspondence between ITSEC and TCSEC. Although it is commonly agreed that the evaluation criteria are a first step in
  • 67. - 67 -the right direction the market for commercial evaluation is not fully developedyet. The existence of at least seven sets of evaluation criteria from differentcountries has led to an unwillingness of the developers to let their productsundergo an evaluation process. However, it is commonly agreed thatharmonization efforts of the different criteria and a growing number ofevaluated products together with an increasing number of customers showing apreference for evaluated products may generate further interest of public andsociety in the field of database security (or computer security in general) andsecurity evaluation. 6. Future Directions in Database Security Research The field of database security has been active for almost twenty years.During the early stages of research focus was mainly directed towards thediscretionary aspect of database security, namely to different forms of accesscontrol lists and to view-based protection issues. Later, the focus has shifted tomandatory controls, integrity issues, and security mechanisms fine-tuned toprovide privacy. The major current trends are to provide tools supporting adesigner during the different phases in the design of databases with securitycritical contents, developing security semantics and classification constraints,to investigate the use of rules and triggers for various problems related todatabase security, extending security issues to other data models, extendingsecurity issues to distributed and heterogeneous databases, and to investigate inphysical design questions, like transaction- and recovery management as wellas in storage structures developed with main focus on the support of security.The following contains our interpretation of some directions in which weexpect the entire field to move within the next few years.System Architecture of Mandatory Systems Most DBMSs supporting MAC are based on the principles of balancedassurance and TCB-subsetting. As a result, the DBMS is hosted on a TCBwhich is responsible for identification, user authentication, and mandatoryaccess controls. Multilevel relations are only supported at an external level andthe whole database is decomposed into single-level fragments which are storedusing the storage manager of a general purpose DBMS product. In our opinionthis approach may have several practical advantages but represents only a near-term solution to database security. What is necessary in the near future is todevelop data models, storage structures, transaction and recovery managementprocedures specially suited for the use in DBMSs with a high degree of trust intheir security features. A first step into this direction has already beenperformed for secure transaction management (for example, see Kogan and
  • 68. - 68 -Jajodia (1990), or Kang and Keefe, 1992a) and recovery management (forexample, see Kang and Keefe, 1992b).Formal Specification and Verification of MLS DBMSs Assurance that the security features of a DBMS are working as advertisedis required for DBMSs holding databases with security critical content. Thisinvolves a formal specification and verification of the DBMS specifications, ofthe DBMS architecture, of the DBMS implementation, as well as of the designand implementation of a particular database application. So far, not much workhas been done on this topic and there is only very little experience usingexisting systems and techniques to formally specify and verify databases. Anatural next step should be to adopt existing techniques and to use them fordesigning and implementing secure databases. A very good discussion on prosand cons of formal methods within the framework of safety-critical systems hasbeen made by McDermid (1993).Evaluation Criteria It is commonly agreed that the evaluation criteria are a first step into theright direction. However, since the international field of information technologyproviders will not be able to evaluate their products against different criteria indifferent countries the criteria proposed will have to be merged. This alsoincludes the need for mutual recognition of security certifications andevaluations between different countries. Moreover, as technology evolves, theconcept of security will need to be extended to an open, heterogeneous, multi-vendor environment. In the future, also different kinds of systems will have tobe considered for evaluation than what we have today, for example, object-oriented systems, knowledge-based systems, active systems, multi-mediasystems, or hypertext may become candidates for evaluation. To cover futuredevelopment, criteria must be open ended and thereby addressing the needs ofnew, yet to be explored, information technology environments.Extending Security to Non-relational Data Models It is only recently that security is discussed in the context of non-relationaldata models. Preliminary work has begun to develop security models forobject-oriented databases (for example, for multilevel approaches see Keefe etal. (1989), Jajodia and Kogan (1990), Thuraisingham (1992), or Millen andLunt (1992), or for discretionary models, for example, Fernandez et al. (1989),Rabitti et al. (1989), or Fernandez et al., 1993), for knowledge-based systems(for example, see Morgenstern (1987), and Thuraisingham, 1990), formultimedia databases (Thuraisingham, 1991) and for hypertext (Merkl andPernul, 1994). So far, the Personal Knowledge Approach is the only data modelthat was initially developed with the main goal to meet security requirements.
  • 69. - 69 -All other approaches have adopted existing data models for the use in securitycritical environments. It is expected that further research will lead to new datamodels in which security has been one of the major design decisions.Research Issues in Discretionary Security The presence of more advanced data models, for example, the object-oriented data model, has renewed interest in discretionary access controls.Further research issues include explicit negative authorization, groupauthorization, propagation of authorization, propagation of revocations,authorizations on methods and functions, and the support of roles.Design Aids and Tools Future research is necessary to develop aids and tools supporting a designerduring the different phases involved in the design of a database with securitycritical content. Research is needed in an integrated fashion and must spanrequirements analysis, conceptual- and logical design, security semantics,integrity rules, and also prototyping, testing, and benchmarking. Aids,guidelines and tools are needed for both discretionary and mandatory protecteddatabases.Extending Security to Distributed and Heterogeneous Databases Distribution adds a further dimension to security because distributedsystems are vulnerable to a number of additional security attacks, for example,to data communication attacks. Even more complicated is the case whereinheterogeneous DBMSs are chosen to form a federation. Since the participatingcomponent databases remain operating autonomously and the securitymechanisms may be different across the sites, additional security gateways andcontrols may be necessary. The steps involved in building a secure distributedheterogeneous DBMS are by no means straightforward and some researchersbelieve that given the current state-of-the-art of both database security andfederated database technology, they are not even possible.Security and Privacy Addressing security and privacy themes must remain a future topic ofdatabase research. Security and privacy is one of the most important topics inmedical informatics, for example, in integrated hospital information systems.In numerous medical venues computerized information systems have beenintroduced with little regard to security and privacy controls so far. It is a futurechallenge to database security to cope with the availability, confidentiality, andprivacy of computer-based patient records in the near future.
  • 70. - 70 - 7. Conclusions The Chapter has proposed models and techniques which provide aconceptual framework to counter the possible threats to database security.Emphasis has been given to the discussion of techniques with the main goal toassure a certain amount of confidentiality, integrity, and availability of the data.Discussed to a lesser degree was the privacy and related legal issue of databasesecurity. Although we have directed the main focus towards the technologicalissues involved in protecting a database, it should be recognized that databasesecurity includes organizational, personnel, and administrative security issuesas well. Database security is not an isolated problem - in its broadest sense it is atotal system problem. Database security depends not only on the choice of aparticular DBMS product or on the support of a certain security model, but alsoon the operating environment, and the people involved. Although not discussedin this Chapter, further database security issues include requirements on theoperating system, network security, add-on security packages, data encryption,security in statistical databases, hardware protection, software verification, andothers. There is a growing interest in database security and the approaches reportedin this Chapter show that there has been considerable success in developingsolutions to the problems involved. Public interest has increased dramaticallybut it is only recently that the issue of security outside the research communityreceives a priority properly reflecting its importance. Database security hasbeen a subject of intensive research for almost two decades but still remainsone of the major and fascinating research areas of the day. It is expected thatchanging technology will introduce new vulnerabilities to database security.Together with problems not yet adequately solved database security promisesto remain an important area of future research. AcknowledgementsI wish to acknowledge the many discussions that I have had on the AMACsecurity technique and on conceptual modeling of sensitive information withKamal Karlapalem, Stefan Vieweg, and Werner Winiwarter. In particular, Ithank A Min Tjoa and Dieter Merkl for their many fruitful comments on thisChapter.
  • 71. - 71 - REFERENCESBatini, C., Ceri, S., and Navathe, S. B. (1992). ‘Conceptual Database Design: An Entity- Relationship Approach’. The Benjamin/Cummings Company, Inc.Bell, D. E., and LaPadula, L. J. (1976). Secure Computer System: Unified Exposition and Multics Interpretation. Technical Report MTR-2997. MITRE Corp. Bedford, Mass.Biba, K. J. (1977). Integrity Considerations for Secure Computer Systems. ESD-TR-76-372, USAF Electronic Systems Division.Biskup, J. (1990). A General Framework for Database Security. Proc. European Symp. on Research in Computer Security (ESORICS’90), Toulouse, France.Biskup, J., and Brüggemann, H. H. (1988). The Personal Model of Data: Towards a Privacy- Oriented Information System. Computers & Security, Vol. 7, North Holland (Elsevier).Biskup, J., and Brüggemann, H. H. (1989). The Personal Model of Data: Towards a Privacy Oriented Information System (extended abstract). Proc. 5th Int’l Conf. on Data Engineering (ICDE’89), IEEE Computer Society Press.Biskup, J., and Brüggemann, H. H. (1991). Das datenschutzorientierte Informationssystem DORIS: Stand der Entwicklung und Ausblick. Proc. 2. GI-Fachtagung “Verläßliche Informationssysteme (VIS’91). IFB 271, Springer Verlag.Burns, R. K. (1992). A Conceptual Model for Multilevel Database Design. Proc. 5th Rome Laboratory Database Workshop, Oct. 1992.Chen, P. P. (1976). The Entity Relationship Model: Towards a Unified View of Data. ACM Trans. on Database Systems (TODS), Vol. 1(1).Clark, D. D., and Wilson, D. R. (1987). A Comparison of Commercial and Military Computer Security Policies. Proc. 1987 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Codd, E. F. (1970). A relational model for large shared data banks. Comm. of the ACM, Vol. 13(6).Cuppens, F., and Yazdanian, K. (1992). A ‘Natural’ Decomposition of Multi-level Relations. Proc. 1992 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Denning, D. E. (1988). Database Security. Annual Reviews Comput. Sci. 1988.3.Denning, D. E., Lunt, T. F., Schell, R. R., Heckman, M., and Shockley, W. R. (1987). A multilevel relational data model. Proc. 1987 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Denning, D. E., Lunt, T. F., Schell, R. R., Shockley, W. R., and Heckman, M. (1988). The SeaView Security Model. Proc. 1988 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Elmasri, R., and Navathe, S. B. (1989). ‘Fundamentals of Database Systems’. The Benjamin/ Cummings Company, Inc.Fernandez, E. B., Summers, R. C., and Wood, C. (1981). ‘Database Security and Integrity’. Addison-Wesley, Reading, MA, System Programing Series.Fernandez, E. B., Gudes, E., and Song, H. (1989). A Security Model for Object-Oriented Databases. Proc. 1989 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Fernandez, E. B., Gudes, E., and Song, H. (1993). A Model for Evaluation and Administration of Security in Object-Oriented Databases. To appear: IEEE Trans. on Knowledge and Data Engineering.Fugini, M. G. (1988). Secure Database Development Methodologies. In: ‘Database Security: Status and Prospects’. C. Landwehr (Ed). North Holland (Elsevier).
  • 72. - 72 -Garvey, C., and Wu A. (1988). ASD_Views. Proc. 1988 Symp. on Research in Security and Privacy. IEEE Computer Society Press.Graham, G. S., and Denning, P. J. (1972). Protection Principles and Practices. Proc. AFIPS Spring Joint Computer Conference.Griffiths, P. P., and Wade, B. W. (1976). An authorization mechanism for a relational database system. ACM Trans. on Database Systems (TODS), Vol. 1(3).Haigh, J. T., O’Brien, R. C., Stachour, P. D., and Toups, D. L. (1990). The LDV Approach to Database Security. ‘Database Security III: Status and Prospects’. D. L. Spooner and C. Landwehr (Eds). North Holland (Elsevier).Harrison, M. A., Ruzo, W. L., and Ullman, J. D. (1976). Protection in operating systems. Comm. of the ACM, Vol. 19(8).Hinke, T. H., Garvey, C., and Wu A. (1992). A1 Secure DBMS Architecture. In: ‘Research Directions in Database Security’. T. F. Lund (Ed.). Springer Verlag.ITSEC (1991). Information Technology Security Evaluation Criteria (ITSEC). Provisional Harmonized Criteria, COM(90) 314. Commission of the European Communities.Jajodia, S., and Kogan, B. (1990). Integrating an Object-Oriented Data Model with Multilevel Security. Proc. 1990 Symp. on Research in Security and Privacy. IEEE Computer Society Press.Jajodia, S., and Sandhu, R. (1990a). Database Security: Current Status and Key Issues. ACM SIGMOD Record, Vol. 19(4).Jajodia, S., and Sandhu, R. (1990b). Polyinstantiation Integrity in Multilevel Relations. Proc. 1990 Symp. on Research in Security and Privacy. IEEE Computer Society Press.Jajodia, S., Sandhu, R., and Sibley, E. (1990). Update Semantics of Multilevel Secure Relations. Proc. 6th Ann. Comp. Security Application Conf. (ACSAC’90), IEEE Computer Society Press.Jajodia, S., and Sandhu, R. (1991a). Toward a multilevel secure relational data model. Proc. ACM SIGMOD Conf., Denver, Colorado.Jajodia, S., and Sandhu, R. (1991b). A Novel Decomposition of Multilevel Relations into Single-Level Relations. Proc. 1991 Symp. on Research in Security and Privacy. IEEE Computer Society Press.Jajodia, S., and Mukkamala, R. (1991). Effects of the SeaView decomposition of multilevel relations on database performance. Proc. 5th IFIP WG 11.3 Conf. on Database Security. Stepherdstown, WV.Kang, I. E., and Keefe, T. F. (1992a). On Transaction Processing for Multilevel Secure Replicated Databases. Proc. European Symp. on Research in Computer Security (ESORICS’92). LNCS 648, Springer Verlag.Kang, I. E., and Keefe, T. F. (1992b). Recovery Management for Multilevel Secure Database Systems. Proc. 6th IFIP WG 11.3 Conf. on Database Security. Vancouver, BC.Keefe, T. F., Tsai, W. T., and Thuraisingham, M. B. (1989). Soda - A secure Object-Oriented Database System. Computers & Security, Vol. 8(5). North-Holland (Elsevier).Kogan, B., and Jajodia, S. (1990). Concurrency Control in Multilevel Secure Databases using the Replicated Architecture. Proc. ACM SIGMOD Conf., Portland, Oregon.Lampson, B. W. (1971). Protection. Proc. 5th Princton Conf. on Information and Systems Sciences.Lampson, B. W. (1973). A Note on the Confinement Problem. Comm. of the ACM, Vol. 16(10).Landwehr, C. E. (1981). Formal Models of Computer Security. ACM Computing Surveys, Vol. 13(3).Lunt, T. F., Schell, R. R., Shockley, W. R., and Warren, D. (1988). Toward a multilevel relational data language. Proc. 4th Ann. Comp. Security Application Conf. (ACSAC’88), IEEE Computer Society Press.Lunt, T. F., Denning, D. E., Schell, R. R., Heckman, M., and Shockley, W. R. (1990) The
  • 73. - 73 - SeaView Security Model. IEEE Trans. on Software Engineering (ToSE), Vol. 16(6).Lunt, T. F., and Fernandez, E. B. (1990). Database Security. ACM SIGMOD Record, Vol. 19(4).McDermid, J. A. (1993). Formal Methods: Use and Relevance for the Development of Safety- critical Systems. In: ‘Safety Aspects of Computer Control’, (P. Bennett, Ed.). Butterworth- Heinemann.Merkl, D. and Pernul G. (1994). Security for Next Generation of Hypertext Systems. To appear: Hypermedia, Vol. 6(1). Taylor Graham.Millen, J. K. (1989). Models of Multilevel Computer Security. Advances in Computers, Vol. 29, (M. C. Yovits, Ed.). Academic Press.Millen, J. K., and Lunt T. F., (1992). Security for Object-Oriented Database Systems. Proc. 1992 Symp. on Research in Security and Privacy. IEEE Computer Society Press.Morgenstern, M. (1987). Security and inference in multilevel database and knowledge-based systems. Proc. ACM SIGMOD Conf., San Francisco, CA.Navathe, S. B., and Pernul, G. (1992). Conceptual and Logical Design of Relational Databases. Advances in Computers, Vol. 35, (M. C. Yovits, Ed.). Academic Press.Neumann, P. G. (1990). Rainbow and Arrows: How the Security Criteria Address Computer Misuse. Proc. 13th National Computer Security Conference. IEEE Computer Society Press.Neumann, P. G. (1992). Trusted Systems. In: ‘Computer Security Reference Book’. (K. M. Jackson, J. Hruska, Eds.). Butterworth-Heinemann.Pernul, G., and Tjoa, A M. (1991). A View Integration Approach for the Design of Multilevel Secure Databases. Proc. 10th Intl Conf. on the Entity-Relationship Approach (ER’91), San Mateo, CA.Pernul, G., and Luef, G. (1991). A Multilevel Secure Relational Data Model Based on Views. Proc. 7th Ann. Comp. Security Applications Conf. (ACSAC’91). IEEE Computer Society Press.Pernul, G. (1992a). Security Constraint Processing in Multilevel Secure AMAC Schemata. Proc. European Symp. on Research in Computer Security (ESORICS’92). LNCS 648, Springer Verlag.Pernul, G. (1992b). Security Constraint Processing During MLS Database Design. Proc. 8th Ann. Comp. Security Applications Conf. (ACSAC’92). IEEE Computer Society Press.Pernul, G., and Luef, G. (1992). A Bibliography on Database Security. ACM SIGMOD Record, Vol. 21(1).Pernul, G., and Tjoa, A M. (1992). Security Policies for Databases. Proc. IFAC Symp. on Safety and Security of Computer Systems (SAFECOMP’92). Pergamon Press.Pernul, G., Winiwarter, W., and Tjoa, A M. (1993). The Entity-Relationship Model for Multilevel Security. Institut für Angewandte Informatik und Informationssysteme. Universität Wien.Rabitti, F., Bertino, E. Kim W., and Woelk D. (1991). A Model of Authorization for next- generation Database Systems. ACM Trans. on Database Systems (TODS), Vol. 16(1).Rochlis, J. A., and Eichin, M. W. (1989). With Microscope and Tweezers: The Worm from MIT’s Perspective. Comm. of the ACM, Vol. 32(6).Schell R. R., Tao, T. F., and Heckman M. (1985). Designing the Gemsos Security Kernel for Security and Performance. Proc. of the 8th Nat. Computer Security Conference. IEEE Computer Society Press.Sell, P. J. (1992). The SPEAR Data Design Method. Proc. 6th IFIP WG 11.3 Conf. on Database Security. Burnaby, BC.Smith, G. W. (1990a). The Sematic Data Model for Security: Representing the Security Semantics of an Application. Proc. 6th Int’l Conf. on Data Engineering (ICDE’90), IEEE Computer Society Press.Smith, G. W. (1990b). Modeling Security Relevant Data Semantics. Proc. 1990 Symp. on Research in Security and Privacy. IEEE Computer Society Press.
  • 74. - 74 -Smith, K., and Winslett, M. (1992). Entity Modeling in the MLS Relational Model. Proc. 18th Conf. on Very Large Databases (VLDB’92).Stachour, P. D. and Thuraisingham, B. (1990). Design of LDV: A Multilevel Secure Relational Database Management System. IEEE Trans. KDE, Vol. 2(2).Stoll, C. (1988). Stalking the Wily Hacker. Comm. of the ACM, Vol. 31(5).Stonebraker, M. and Rubinstein, P. (1976). The Ingres Protection System. Proc. 1976 ACM Annual Conference.TCSEC (1985). Trusted Computer System Evaluation Criteria. (Orange Book). National Computer Security Center, DOD 5200.28-STD.TDI (1990). Trusted Database Interpretation of the Trusted Computer System Evaluation Criteria, NCSC-TG-021. Version 1.Thompson, K. (1984). Reflections on Trusting Trust. Comm. of the ACM, Vol. 27(8). Also in: ACM Turing Award Lectures: The First Twenty Years 1965-1985. ACM Press.Thomsen, D. J., and Haigh, J. T. (1990) A Comparison of Type Enforcement and Unix Setuid Implementation of Well-Formed Transactions. Proc. 6th Ann. Comp. Security Applications Conf. (ACSAC’90). IEEE Computer Society Press.Thuraisingham, M. B. (1990). Towards the design of a secure data / knowledge base management system. Data & Knowledge Engineering, Vol. 5(1), North Holland (Elsevier).Thuraisingham, M. B. (1991). Multilevel Security for Multimedia Database Systems. In: ‘Database Security: Status and Prospects IV’. (S. Jajodia, C. E. Landwehr, Eds). North Holland (Elsevier).Thuraisingham, M. B. (1992). Multilevel Secure Object-Oriented Data Model - Issues on non- composite objects, composite objects, and versioning. JOOP, SIGS Publications.Wilson, J. (1988). A Security Policy for an A1 DBMS (a Trusted Subject). Proc. 1988 Symp. on Research in Security and Privacy, IEEE Computer Society Press.Wiseman, S. (1991). Abstract and Concrete Models for Secure Database Applications. Proc. 5th IFIP WG 11.3 Conf. on Database Security. Stepherdstown, WV.