The Entity-Relationship Model for Multilevel Security

The Entity-Relationship Model for Multilevel Security Günther PERNUL, Werner WINIWARTER, A Min TJOAInstitute of Applied Computer Science and Information SystemsUniversity of Vienna, AustriaAbstract. A design environment for security critical database applications thatshould be implemented by using multilevel technology is proposed. For thispurpose, the Entity-Relationship model is extended to capture securitysemantics. Important security semantics are defined and a language to expressthem in an ER model by means of security constraints is developed. The maincontribution consists of the development and implementation of a rule-basedsystem with which security semantics specified may be checked for conflictingconstraints. The check involves application independent as well as applicationdependent integrity constraints and leads to a non conflicting conceptualrepresentation of the security semantics of a multilevel secure databaseapplication.1 IntroductionDesigning a database is a complex and time consuming task, even more in the case attention must be given to the security of the information being considered for representation in the database. In order to simplify the design activity, it is necessary to look at the database application at an abstract level by using a conceptual data model, for example, the Entity-Relationship (ER) Model [1].A conceptual data model must be powerful enough to capture all application dependent knowledge. For applying such a model successfully for the design of a security critical application, the model must in addition to represent the data semantics represent the security properties of data (i. e. the security semantics of the application) as well. The ER model provides a graphical language to describe the information items of the application by means of semantic modeling constructs. Unfortunately, it does only offer restricted possibilities to represent constraints that are imposed on those information items by the application, such as for example security constraints. The goal of this paper is to extend the notion of the standard ER model to also capture security semantics, to provide a language in which application dependent security requirements may be expressed on the concepts of the ER model, and to provide a technique to check constraints resulted from the security requirements for overall consistency. The model proposed includes two levels of representation for security semantics. At the user level we introduce a graphical representation and a constraint language, and at an internal level a knowledge baseto check for conflicting constraints. The constraint language and the knowledge base to check conflicting constraints has already been implemented by using the deductive DBMS LDL, the implementation of the user interface (graphical browser) including the proposed graphical extensions to ER is under development.The outline of the paper is as follows: Section 2 contains relevant related work. In section 3 the security semantics are defined, expressed in the constraint language, and explained by means of an example. Section 4 deals with conflict management in order to achieve a non conflicting representation of a MLS database application. Section 5 concludes the paper.2 Background and Related WorkFor applications in which the secrecy and confidentiality of the information is of major concern DBMSs supporting Mandatory Access Controls (MAC) may be chosen. Mandatory Security requires that data and users are assigned to certain security classifications (security levels, like top-secret, secret, classified, unclassified, or like company-confidential, confidential, private, public, ...). A level represents the sensitivity of the labeled information (classification) or the trustworthiness of a user (clearance) not to disclose information to other users not so trusted. Classifying data is done by means of rules and one of the major questions involved is how the data of a database should be classified without specifying conflicting rules.Mandatory security is often defined in terms of the Bell-LaPadula (BLP) [2] security paradigm which distinguishes between read access and write access by using the two following rules: (1) User u is allowed to read data d if clear(u) ≥class(d) and (2) u is allowed to write data if clear(u) ≤class(d). Because of this two rules, information flow controls are implemented restricting users with high clearances to write data in a lower classified storage area and thereby disclosing sensitive information. Mandatory security leads to multilevel secure (MLS) databases because the content of the database may appear different for users with different clearances. For more information and for a formal treatment of the MLS relational data model consult [3] or [4]. Today, there are several commercially MLS database management systems available, for example Informix, Ingres, Oracle, Rdb, Sybase, and others offer in addition to their general purpose system a multilevel version. However, the first and most prestigious effort towards the design and implementation of a MLS DBMS has come from the SeaView project (e.g. [5], [6]).In this paper we focus on database applications that should be implemented in systems supporting a MLS data model. In this context, the major problems involved are to identify the security semantics (requirements) of the application, to specify the security sementics by means of constraints and rules in a conceptual data model, to check the constraints for completeness and to resolve conflicts between security semantics. The conceptual model developed in the proposed approach may be finally transferred into the MLS data model that is supported by a target DBMS in use.Compared to the huge amount of work published in semantic modeling and conceptual design of databases not much work has been done investigating securitysemantics of MLS database applications. Only recently several research efforts have started to provide tools and assistance to aid a designer in creating a MLS application. The first attempt to use a conceptual model to represent security semantics is given in [7] and [8]. The author develops the semantic model for security (SDMS) based on a conceptual database model and extends the constraint language ALICE (proposed in [9]) to include constructs to describe security constraints. In contrast to the proposed approach their model has not been completely formalized and does not offer sophisticated techniques for the detection of conflicting constraints and if existing, techniques for their resolution. A more recent approach has been made in [10] and [11]. The authors have developed the SPEAR model which is a high-level data model and similar to the ER approach. This model consists of an informal description of the application domain and of a formal mathematical specification using the Z-notation [12]. The model seems to be powerful, however does not offer a graphical notation and only limited support to detect conflicting constraints. Two further related projects are known. Both projects consider, in addition to modeling the static of the application, to include the behavior of the system within the datbase design process. In [13] the ER model has been extended to capure limited dynamics by including the operations 'create', 'find' and 'link' into the conceptual database representation while in [14] ER has been used to model the static part of a MLS application and data flow diagramming to model the behavior of the system. Both approaches do not offer any consistency checks of the security constraints specified.The proposal in this paper extends previous work on security semantics by •carefully defining the major security semantics that need to be represented during the design of a database,•by developing a constraint language for expressing corresponding rules in a conceptual model (ER model) of the appliciation, and•by developing and implementing a rule-based system with which security semantics specified may be tested for conflicts. Conflicting constraints are notified to the designer and may be resolved. The rule-based system is implemented by using the deductive DBMS LDL.3 Concepts of Security SemanticsIn the following we give a taxonomy of security semantics which consists of the most common requirements on multilevel security. Each concept is formally defined, expressed in the security constraints language (SCL), graphically included in the notion of the ER model, and explained by means of an example. We will start with defining the basic concepts.A security object O is a semantic concept of reality that is described by certain properties. Using extended ER terminology, O might be an entity type, a specialization type, a generic object type, or a relationship type. In a security terminology, O is the target of protection and might be denoted by O(A1,...,A n). A i is a characteristic property and defined over a domain D i. Each security object Omust have an identifying property K(K⊆{A1,...,A n}) which is either a single characteristic property or a set of properties that combined together form an identifier and make instances (occurrences) o∈O(o={a1, ..., a n}, a i∈D i) distinguishable from others.Moving to a multilevel world each property of a security object must be assigned to at least one security level. A security level is an entry in a hierarchical list of levels SL. A multilevel security object O m(A1,C1, A2,C2, ..., A n,C n) is a security object where each characteristic property A i is assigned to a security classification C i. The valid domain of C i is specified by an interval consisting of possible security classifications between the lowest classification (L i) and the highest classification (H i) possible for a value of characteristic property A i(L i, H i∈SL). The set of instances of a multilevel security object is a set of distinct tuples of the form (a1,c1, a2,c2, ..., a n,c n,) where each a i∈D i, c i∈[L i,H i].The process of assigning data items to security classifications is called classifying and results into the transformation of a security object O into a corresponding multilevel security object O m (O⇒O m). The transformation is performed by means of security constraints specified in a constraints language.In the following we give a taxonomy of the most relevant security semantics that should be expressed in a conceptual data model. Some of the constraints have been discussed before (e.g. in [7], [15]), however, to the best of our knowledge the following is the first careful formalisation of the constraints. It is distinguished between two kinds of constraints: Constraints that classify characteristic properties of security objects (simple, content-based, complex, and level-based constraints) and constraints that classify retrieval results (association-based, inference, and aggregation constraints).The example design scenario that will be used represents part of a hospital information system containing historical information. Of interest are the security objects:•patient (ssn, pname, karnofski, incompatibility)•treatment (ssn, icd, duration, status, course)•disease (icd, dname, medication)3.1 Simple ConstraintsThese constraints classify certain characteristic properties of security objects. By assigning a security classification to the identifying property even the information about the existence of the security object can be classified.• Definition: Let X be a set of characteristic properties of security object O i.e. X⊆{A1,..,A n}. A simple security constraint SiC is a classification of the form SiC(O(X))=C, C∈SL and results into a multilevel object O m(A1,C1,A2,C2, ..., A n,C n) whereby C i=C for all A i∈X, C i left unchanged for the remaining A i∉X.• SCL predicate:sic(O, X, C)O ... security object, X ... set of classified characteristic properties,C ... security level•Example:The status of a medical treatment should be regarded as private information. ⇒sic(treatment, {status}, private)3.2 Content-Based ConstraintsThey classify characteristic properties of instances of security objects based on the evaluation of a predicate on a specific characteristic property of the same instance.• Definition: Let A i be a characteristic property of security object O with domain D i, let P be a predicate defined on A i and let X⊆{A1,...,A n}. A content-based constraint CbC is a classification of the form CbC(O(X),P:A iθa)=C or CbC(O(X),P:A iθA j)=C (θ∈{=,>,<,≥,≤,≠}, a i∈D i, D i⊆D j,i≠j, C∈SL).For any instance of security object (A1,...,A n) for which a predicate evaluates into true the transformation into (a1,c1, a2,c2, ..., a n,c n) is performed. Classifications are assigned in a way that c i=C in the case A i∈X, c i left unchanged otherwise.• SCL predicate:cbc(O, X, A, Theta, V, C)A ... evaluated characteristic property A i, Theta ... comparison operator θV ... comparison value a or characteristic property A j• Example: Medical treatments have to be classified as confidential, if the duration exceeds 8 months. ⇒cbc(treatment, {ssn, icd}, duration, '>', 8, confidential)3.3 Complex ConstraintsTwo different security objects participating in a dependency relationship are involved in the definition of a complex constraint. As consistent extension of the content-based constraint the predicate is evaluated on a specific characteristic property of the independent security object leading to a classification of properties of the associated dependent object.•Definition: Let O,O' be two security objects and the existence of an instance o of O is depending on the existence of a corresponding instance 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 (as stated above for content-based constraints) defined on O' and let X⊆{A1,...,A n} be an attribute set of O. A complex security constraint CoC is a classification of the form CoC(O(X),P(O'))=C. For any instance o of security object O for which the predicate evaluates into true in the related object o' of O', the transformation into (a1,c1, ..., a n,c n) is performed. Classifications are assigned in that c i=C in the case A i∈X, c i left unchanged otherwise.• SCL predicate:coc(OD, X, O, A, Theta, V, C)OD ... dependent security object O, O ... independent security object O',• Example: The data about treatments of patients suffering from carcinoma has to be processed as most sensitive information.⇒coc(treatment, {ssn}, disease, dname, '=', carcinoma, secret)3.4 Level-Based ConstraintsIf data items are classified on the basis of the classification of some other characteristic property of the same security object, this dependency is expressed by means of a level-based constraint. This signifies that for all instances of the security object the concerned characteristic properties are enforced to be always labeled by the same security level.• Definition: Let level(A i) be a function that returns the classification c i of the value of a characteristic property A i for the instance o m(a1,c1,a2,c2, ..., a n,c n) of a multilevel security object O m. Let X be a set of characteristic properties of the same security object O such that X⊆{A1,...,A n}. A level-based security constraint LbC is a classification of the form LbC(O(X))=level(A i)and results into the classification of the values of all A j∈X (j≠i) with the security levels level(A j)=c i.• SCL predicate:lbc(O, X, A)• Example: The information about the course of a disease in response to the medical treatment has to be protected to the same extent as the status of the patient.⇒lbc(treatment, {course}, status)Fig. 1. Example of constraints on characteristic propertiesFigure 1 contains the summarised graphical representation of the constraints classifying characteristic properties as discussed in the examples given above.3.5 Association-Based ConstraintsThey restrict from combining the values of certain characteristic properties with the identifying property of the security object in the retrieval result. This permits theaccess to collective data but prohibits the user from identifying the properties of the individual instances of the security object.• Definition: Let O(A1,...,A n) be a security object with identifying property K. Let Y ⊆{A1,...,A n}, K∩Y={} be a set of characteristic properties of O. An association-based security constraint AbC(O(K,Y))=C results into the assignment of security level C to the retrieval result of each query that takes Y together with identifying property K.• SCL predicate:abc(O, Y, C)Y ... set of sensitive characteristic properties Y⊆{A1,...A n}, K∩Y={},• Example: The karnofski indices (indicating the state of health of a patient) shall be freely available as anonymous statistical coefficient. However, for an individual patient this private information is sensitized by classifying it as private. ⇒abc(patient, {karnofski}, private)3.6 Inference ConstraintsThese constraints prevent from drawing inferences from seemingly independent data items to higher classified information. Inferences can occur because of hidden relations that are not explicitely represented in the conceptual data model of the MLS database, also involving knowledge beyond the scope of the database system.• 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 representations O(A1,C1, ..., A n,C n) and O'(A'1,C'1, ..., A'm,C'm). Let X⊆{A1,...,A n} and Y⊆{A'1,...,A'm}. A logical inference security 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: if c(O1, X1, O2, X2, C)O1 ... security object O,X1 ... set of sensitive characteristic properties X of O,O2 ... independent security object O',X2 ... set of sensitive characteristic properties Y of O',• Example: The characteristic property incompatibility indicates allergic reactions of a patient against certain drugs that were diagnosed during past medical treatments. Therefore, one could infer recent diseases of a patient from the detected incompatible medicaments combined with the information which medication is applied for a specific disease. To close this forbidden inference channel an appropriate inference constraint is stated that assigns it with a security level of secret. ⇒if c(patient, {pname, incompatibility}, disease, {dname, medication},secret)3.7 Aggregation ConstraintsIn some cases the retrieval of several instances of a security object is regarded as more sensitive than a result consisting only of a single instance. This phenomenon is known as the aggregation problem. It occurs in cases where the query is narrowed on a sensitive characteristic property and information about that property can be concluded from the total retrieval result.•Definition: Let count(O)be a function that returns the number of instances involved in a particular query and belonging to security object O(A1,...,A n). Let A i be a sensitive characteristic property of O that is used for narrowing the query by defining a selection criterion on A i.An aggregation security constraint AgC is a statement of the form AgC(O(A i,count(O)>n))=C(n∈Ν) and results into the classification of C for the retrieval result in the case count(O)>n, i.e. the number of obtained instances of O exceeds the threshold value n.• SCL predicate:agc(O, A, N, C)A ... sensitive characteristic property A i, N ... threshold value n •Example:The report of an individual medical treatment for a specific patient is regarded as less sensitive than the complete medical history obtained from a retrieval of all medical treatments of the patient. Therefore, an aggregation-based constraint is formulated that declares a threshold value of 5 treatments. If this limit is exceeded, a security classification of level confidential is performed. ⇒agc(treatment, ssn, 5, confidential)Figure 2 contains the summarised graphical representation of the constraints classifying retrieval results of the examples given above.F ig. 2. Example of constraints on retrieval results4 Conflict ManagementFor complex and security critical database applications it might be necessary that a large set of security constraints need to be expressed at the conceptual database level. In the following we will discuss the methods used for the detection of conflicting constraints specified as well as the techniques used for the conflict resolution. The conflict management represents the internal layer of the proposed approach and isresponsible to enforce two different kinds of integrity constraints in the security semantics specified: application independent and application dependent integrity constraints. Conflict management is performed by our prototype implementation in LDL. For a more detailed study of conflict management we refer to [16].4.1 Integrity of Security SemanticsApplication independent integrity constraints are rules that must be valid in each MLS database. By expressing the security constraints introduced on the conceptual representation of the database application, integrity constraints might be violated. In the proposed system, those conflicts are detected automatically by the implemented rule system, the conflicts are resolved and finally notified to the designer. However, in the case a conflict involves an application independent integrity constraint, the designer is not given a possibility to override the changes performed by the tool. Some of the following integrity properties have first been proposed within the SeaView project [5] and have been carefully defined in the Jajodia-Sandhu model [3]. For conflict management we consider:[I1]Multilevel integrity property: Each property must have a security label. This is satisfied because during initial classifying each characteristic property is classified with the default security level.[I2]Entity integrity property: A multilevel security object O m with identifying property K satisfies entity integrity property if for all occurrences o∈O m1. A i∈K⇒ val(A i)≠null (with val(A i) the value of property A i in o)2. A i,A j∈K⇒ val(C i) = val(C j) (with val(C) classification of property A in o)3. A i∉K⇒ val(C K)≤val(C i). (with val(C K) classification of the key-value in o) Entity integrity states that an indentifying property may not be null, must be uniformly classified and its classification must be dominated by all other classifications of the other attributes. This is necessary because by having only access to part of the key for lower cleared users it would not be possible to uniquely identify objects. Please note that this may contradict to certain applications, for example, in applications where access to key-properties should be denied while access to some other non-identifying properties should be possible (e.g. for statistical queries).[I3]Foreign key property: Let K be the identifying property in multilevel security object O m and and let it be a foreign key K' in multilevel security object O m'. The foreign key property is valid, if val(C K) ≤val(C K'). The foreign key property guarantees that no dangling references between depending objects will occur for users cleared to access lower classified data only.[I4]Near-key property: Near-key property is important in the case an association based constraint is specified. In this case the level C assigned by the constraint abc(O, X, C) is automatically propagated to each corresponding association including a near-key (or candidate key) instead of the identifying property of O.[I5]Level-based property: In order to avoid transitive dependencies (which may result into propagation cycles) between level-based constraints specified, for any two level-based constraints on the same security object lbc(O, X, A) and lbc(O, X', A') A∉X'∧A'∉X must hold. Because of the entity integrity property a level-based constraint may not be defined on the key.[I6]Multiple-Classification: Each property value may only have a single classification. In the case different security constraints assign more than one level to a particular property value we refer to it as multiple-classification. Such a conflict is notified to the designer which may decide whether to apply the default resolution strategy or not.4.2 Conflict Resolution Stategies and the Example DesignClassifying is done by stepwise insertion of security constraints into the rule-base. Declaring a new constraint is an interactive process between the designer and the tool. The six integrity constraints given above must be validated for any new security constraint specified. If conflicts are detected the resolution strategy applied depends on the kind of conflict. For conflicts due to application independent constraints the integrity is preserved by propagating the required classifications to the characteristic properties involved. Application dependent constraints leading to multiple-classification of characteristic properties are notified to the designer who may decide about a proper classification. As default strategy the design tool suggests the maximum of the conflicting security levels to guarantee the highest degree of security possible. However, accepting the default strategy may lead to overclassification of the database.Let us now explain the conflict resolution strategies by applying them to the example and the security constraints developed in the preceding chapters, summarized once more:1.sic(treatment, {status}, private)2.cbc(treatment, {ssn, icd}, duration, '>', 8, confidential)3.coc(treatment, {ssn}, disease, dname, '=', carcinoma, secret)4.lbc(treatment, {course}, status)5.abc(patient, {karnofski}, private)6.if c(patient, {pname, incompatibility}, disease, {dname,medication},secret)7.agc(treatment, pssn, 5, confidential)The process starts with the initial assignment of the default security level public to each data item. The insertion of 1) results in the assignment of security level private to property status. No conflicts arise. Constraint 2) is a cbc and results into the assignment of the range [∅..C] to properties ssn and icd. That is, in the case the predicate evaluates into true classification C is assigned, otherwise the classifications remain public (i. e. the default value denoted as ∅). In order to resatisfy the application independent property that the classification of the key must be dominated by all other classifications (entity integrity property as stated above) the assigned classifications are propagated to the other properties of relationship type treatment. The propagation results into the first conflict between application dependent constraints specified. This is because of property status (which is already classifiedas private by 1)) will be multiple-classified by propagating [∅..C]. This conflict is notified to the designer. Let us consider that the designer confirms the suggested default resolution strategy resulting in the assignment of range [P..C] to property status.The next rule 3) is a coc that assigns the ssn of patients suffering from 'carcinoma' in treatment to secret.This leads to a classification range for the property ssn of [∅..S]. Again this disagrees with the already existent range of [∅..C] for ssn. Therefore, the designer has to decide whether to accept the suggested classification range [∅..S] or not. In the case of acceptance the new classification of ssn must be propagated to icd because of entity integrity (icd constitutes the second part of the key). Now the complete key takes the new classification [∅..S] which makes the propagation of [∅..S] to all other properties of treatment necessary. This propagation again causes multiple-classification of all non-identifying properties of treatment resulting in further notations for the designer (once more confirmed). Lbc 4) assigns the classification of status to course, yielding a new range of [P..S] for course. The designer receives the notation about the conflicting ranges [P..S] and [∅..S] and chooses the default resolution strategy. The remaining security constraints 5)-7) do not deal with characteristic properties but instead classify retrieval results. Because of the near-key integrity constraint 5) is also propagated to the near-key pname in patient. The remaining constraints 6) and 7) do not cause any conflicts.5 ConclusionFor security critical database applications MLS technology may be chosen as the implementation platform. In such an environment data items need to be assigned to security classifications that properly represent the security semantics of the database application. In this paper we have carefully defined the important security semantics that need to be represented during the design of a database, have developed a constraint language for expressing them, and have suggested to extend the Entity-Relationship model to capture security semantics. We see as the main contribution of our research the development of a rule-based system holding classification rules and certain integrity constraints that must be valid among the rules specified. Whenever a database designer inserts a new classification rule, the rule-base is checked for resulting conflicts. The checks are performed against the integrity constraints and all other rules already in the rule-base. In the case a classification rule causes conflicts, a conflict resolution strategy has been developed and implemented.The research presented in this paper provides the basis to assist database designers and security engineers in getting a better understanding of the security requirements of the static part of the database application. Future research in this area may be required because the security of a database may also be violated by abusing the functional part of the system. What will be necessary to do in order to achieve a high degree of data protection is to look at the dynamic aspects of MLS database applications too.。