Object-Oriented Modeling of Security Semantics - Semantic Scholar

Object-Oriented Modeling of Security Semantics

Ernst Ellmer 1), Günther Pernul 1) , Gerti Kappel 2) 1) Institute

of Applied Computer Science and Information Systems Department of Information Engineering University of Vienna Liebigg. 4/3-4, A-1010 Vienna, Austria {ellmer  pernul @ifs.univie.ac.at} 2) Institute

of Computer Science Department of Information Systems University of Linz Altenberger Str. 69, A-4040 Linz, Austria {[email protected]}

Abstract. For applications with high requirements on the confidentiality of data a level-based access control policy may be appropriate. Designing such security critical applications is a less understood issue and thus complicated task. To guide a security administrator or database designer and in order to simplify the design activity several guidelines and a powerful modeling technique are necessary. This paper proposes an object-oriented modeling for multilevel secure database application design. The technique is build around the concept of application dependent classification constraints, supports a static, functional, as well as a dynamic view of the application, and offers an underlying design method. By means of an example we describe how the different models relate to each other and how a conceptualization of a multilevel secure application may be constructed.

Object-Oriented Modeling of Security Semantics

Abstract. For applications with high requirements on the confidentiality of data a level-based access control policy may be appropriate. Designing such security critical applications is a less understood issue and thus complicated task. To guide a security administrator or database designer and in order to simplify the design activity several guidelines and a powerful modeling technique are necessary. This paper proposes an object-oriented modeling for multilevel secure database application design. The technique is build around the concept of application dependent classification constraints, supports a static, functional, as well as a dynamic view of the application, and offers an underlying design method. By means of an example we describe how the different models relate to each other and how a conceptualization of a multilevel secure application may be constructed.

1. Introduction Object-oriented modeling of applications is widely recognized as improving the quality and understandability of designs, thus implying higher productivity and less maintenance costs. A further advantage of the object-oriented approach is its applicability both in the programming language world and the database world. Through its unifying concept of interacting objects it supports an intuitive way of modeling a problem domain independent of the chosen implementation environment.

-2-

The purpose of this paper is to shed some light on a very important yet rather unknown area for applying the object-oriented approach, namely for modeling the security semantics of applications (security relevant knowledge of the application domain). We propose an object-oriented technique for modeling database applications with high security needs. As a target database management system, i.e., the system on which the application actually should be implemented, we assume a system being able to handle multilevel data. Although the core security properties of a system include the confidentiality, the integrity, and the availability of service, the main focus of this paper is on the confidentiality aspect of information. The object-oriented technique for modeling multilevel data consists of three views on relevant information, the static view, the functional view, and the behavioral view. The static view reflects the data structure of the application, the processes of a functional schema are used to determine the methods of the multilevel objects and the dynamic schema reflects the life cycle of a multilevel object from its creation (i.e. its insertion into the database) to its deletion. The main contribution of this paper is to develop an integrated approach by considering all aspects of information (static, functionality, and behavior) that are relevant for the development of a conceptualization of a multilevel secure application. The paper is outlined as follows. We start with specifying a running example used throughout the paper. In section 2 we give a general overview of the object-oriented modeling technique and discuss its relationship to related work. The subsequent sections are devoted to a description of the main components of the object-oriented modeling technique: the static model (section 3), the functional model (section 4), the dynamic model (section 5), and the underlying method for constructing multilevel secure database applications (section 6). Section 7 concludes the paper and discusses future research.

1.1 Running Example Employees are assigned to projects. The structural part of an employee is described in terms of the social security number, name, department, skills and salary. For each project the title of the project, its objective, its respective client, and requirements of the project are kept. The functional part of the system includes a procedure for assigning employees to projects. The procedure may be invoked by each employee and a request is evaluated by comparing project requirements and skills of the employee. Due to the result of the comparison the assignment is established, or an unsuccessful request is stored in the database. Depending on certain values of their properties objects of class Employee, Assignment, and Project may be in different states. For each state, different requirements on the confidentiality are evident. A dynamic model of the application will be developed to describe all valid state transitions and corresponding classification levels.

-3-

2. Architecture and Related Work The proposed object-oriented approach for modeling security sensitive applications consists of two levels of abstraction (see Fig. 1). The higher level of abstraction comprises three kinds of information. Firstly, three different types of models necessary to develop an integrated conceptual representation of the application. Secondly, a modeling technique (method) guiding a designer through the various steps involved in the construction of a conceptual schema of a database application, and thirdly, a set of classification constraints used to assign appropriate security labels to objects and to their attributes and methods. At the lower level of abstraction the proposed object-oriented approach for modeling multilevel data enforces integrity by checking for conflicting classification constraints specified at the level above, and for violations of basic multilevel integrity properties. Note, that in this paper we are only dealing with the higher level of abstraction; integrity and conflict management is still subject to ongoing work.

Modeling technique

modeling the static part High level of abstraction Low level of abstraction

modeling the functional part

modeling the objects behavior

Classification Constraints • Integrity Properties • Conflict Detection • Conflict Resolution

Fig. 1. Object-oriented modeling architecture

Requirements on the structural part of the database are represented in a semantic data model based on the Entity-Relationship Approach [1] and expressed by using the object diagram notation of OMT [2]. The model supports complex objects, object identity, attributes, methods, associations between objects, additional abstraction concepts like aggregation and generalization, as well as concepts to represent security relevant knowledge. For modeling the system’s functionality we have chosen to extend data flow diagramming (DFD) techniques to a multilevel context and to base our investigations on the Bell and LaPadula security paradigm [3]. The dynamic aspects of multilevel objects are expressed by adapting the behavior model of Object/Behavior Diagrams (OBD) [4] for our purposes. Classifying, i.e. assigning classifications to security objects is

-4-

performed by means of classification constraints that may be specified on concepts of the static schema, of the functional schema, and of the dynamic schema. The underlying modeling technique consists of data modeling, functional modeling, and behavior modeling by performing alternate refinements on either of the three schemes. Each refinement in one schema is influenced by both the previous version of the schema and the state of design in the other schemes. Performing such an iterative approach has the advantage of being able to check whether modeling concepts and security constraints in one schema have corresponding equivalents in the other schemes. During the last years, several object-oriented models for application design have been proposed [5]. Among the most prominent are the Booch method [6], ObjectOry [7], Responsibility-Driven Design [8], and OMT [2]. Although these models are also applied to database applications they do not explicitly support the modeling of security relevant knowledge. A similar situation is found in the non object-oriented area. Fugini in [9] was the first that pointed out the necessity of a careful database design for security critical database applications. The first attempt to use a conceptual data model to represent security semantics was made by Smith ([10], [11]). The author develops the semantic data model for security (SDMS) based on a conceptual database model and a constraint language. This was a careful and promising first step which has influenced all following approaches. A more recent approach has been made within the SPEAR project ([12], [13]). SPEAR is a high-level data model and similar to the ER approach. The model consists of an informal description of the application domain and of a mathematical specification using a formal specification language. Two further related projects are known. Both projects improve over previous approaches because they consider to include modeling the system functions, in addition to modeling the static of the application, within the conceptual modelling process. In [14] the ER model has been extended to capture limited behavior by including the operations ‘create’, ‘find’, and ‘link’ into the conceptual database representation whereas in [15] Rumbaugh’s OMT is applied for designing MLS database applications. A security classification language used to express the constraints on concepts of the ER model as described in this paper is contained in [16] while a prototyping system for prototyping MLS database applications has been reported in [17]. This work is only slightly related to security in object-oriented databases - thus, we do not include corresponding references here.

3. The Static Model The fundamental notion of object-orientation is that of an object. In our approach an object1) represents real world entities like persons, financial institutions, and accounts, and it is the target of 1. Please note the slightly different definition commonly used for the term ‘security object’.

-5-

protection. Each object has a unique system-defined identity. Objects are characterized by their internal structure and their behavior. Objects with the same internal structure and behavior are grouped together into classes. Objects belonging to a class are called instances of that class. A class specifies the behavior and the internal structure of its instances. At a certain point in time the internal structure of an object is determined by the values of its attributes while the behavior is determined by methods defined for objects. Each method is characterized by the method’s name, a set of input parameters and a return value. Thus, in our notion an object class may be defined as O (A1, ..., An, M1, ..., Mm) where Ai (i=1..n) is an attribute and defined over a domain Di while Mj (j=1..m) is a method named Mj having input parameters or/and a return value of domain Dj. (Note, the domains of input parameters are not considered as security critical information.) Relationships between objects are called associations and are characterized by the number (cardinality) of the participating objects (e.g., many, zero or one, exactly one, or exactly specified). In the case associations have attributes they are treated similar to object classes. The static model includes two further structuring concepts: aggregation and generalization. An aggregation is an association with a part-of semantics while a generalization represents is-a semantics. Generalization defines an inheritance path, i.e. a subclass inherits attributes and operations from all its superclasses in addition to defining its own attributes and operations. In this setting a superclass is a generalization of the subclass while the subclass is a specialization of the superclass. Our model supports multiple inheritance which means a subclass may inherit attributes and operations from more than one superclass.

3.1 Classification Constraints Moving to a multilevel world the major question involved is in which way the attributes, methods, and instances of O should be assigned to proper security classifications. In the proposed objectoriented modeling technique this is performed by means of classification constraints and called classifying. Classifying results into the assignment of a security label to modeling concepts. Each security label out of a set of labels SL usually consists of two components: an entry in a hierarchical list of sensitivity levels (for example, unclassified < classified < secret < top_secret) and a member of a set of compartments. For simplicity, we consider in the following the existence of a single compartment only. The process of lassifying results in the transformation of O into a multilevel security object class Om (O ⇒ Om), multilevel class for short. A multilevel class Om (A1, C1, ..., An, Cn, M1, Cn+1 ..., Mm, Cn+m, OC) as well as each instance o(a1,c1,...,an,cn, M1,cn+1, ...,Mm,cm+n, oc) of Om are characterized by the following classifications: Ci is a classification for the corresponding attribute or method. Each Ci is defined over a range [Li, Hi] where Li is the lowest classification possible

-6-

and Hi the highest for each classification ci (ci ∈Ci) (i=1..n+m). Classification oc is the classification of an object instance and determined by the minimum of the classification of the properties of this instance. OC is the classification of the object class and defined over the range [L, H] spanned by the minimum and maximum classification of the instances of the object class. In the proposed technique it is distinguished between classifying three different modeling concepts: attributes, methods and object instances. Classifying an attribute means classifying the value of the attribute. Classifying a method doesn’t mean classifying a possible return value of the method but classifying the method signature. This has the consequence that security subjects (users or transactions operating on behalf of users) are only aware of methods with a classification dominated by the users’ clearances. After invoking a method, the method inherits the clearance of the user and thus operates within the access restrictions imposed by the clearance. In the proposed approach, only methods building an interface to the user are subject of classification. Classifying an object means determining a minimum and maximum classification level for the object’s attribute values and the object’s methods. For the following discussion we consider a classification C from the set of security levels SL (C ∈ SL). The transformation of a security object into a multilevel security object is performed by means of security constraints representing the security semantics of the application domain. In the following we give a taxonomy of the classification constraints considered in the proposed object-oriented modeling technique: • (Simple Constraints). Let X be a set of attributes or methods of class O (X ⊆ {A1, ..., An, M1, ..., Mm}). A simple security property SiC is a classification of the form SiC (O (X)) = C1, (C ∈ SL) and results into a multilevel class Om (A1, C1, ..., An, Cn, M1,Cn+1 ..., Mm, Cn+m, OC) whereby Ci = C for all Ei ∈ X, Ci left unchanged for the remaining Ei ∉ X. • (Content-based Constraint). Let Ei ∈ X be an attribute or method2 of class O with domain Di, let P be a predicate defined on Ei and let X ⊆ {A1, ..., An, M1, ..., Mm}. A content-based constraint CbC is a security classification of the form CbC (O (X), P: Ei θ a) = C or CbC (O (X), P: Ei θ Ej) = 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 class O(A1, ..., An, M1, ..., Mm) for which a predicate evaluates into true the transformation into o(a1,c1,...,an,cn, M1,cn+1, ...,Mm,cm+n, oc) is performed. Classifications are assigned in a way that ci = C in the case Ei ∈ X, ci left unchanged otherwise. Content-based constraints classify attribute values or methods of multilevel objects based on the 1. SiC (O (*) = C means that all attributes and methods (A1, ..., An, M1, ..., Mm) of O are uniformly classified with C. 2. Here, only methods having a return value are considered.

-7-

evaluation of a predicate defined on specific attribute values or methods of this object. • (Complex Constraint). Let O, O’ be two classes and the existence of an instance o of O is dependent on the existence of a corresponding occurrence o’ of O’. That means that there exists a generalization or association relationship between O and O’. Let P(O’) be a valid predicate (in the sense of content-based constraints) defined on O’ and let X ⊆ {A1, ..., An, M1, ..., Mm} be an attribute and method 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 class O(A1, ..., An, M1, ..., Mm) for which the predicate evaluates into true in the related object o’ of O’ the transformation into o(a1, c1, ..., an, cn, M1,cn+1, ...,Mm,cm+n, oc) is performed. Classifications are assigned in a way that ci = C in the case Ei ∈ X, ci left unchanged otherwise. Complex security constraints involve two different multilevel objects participating in a dependency relationship. They are treated similar to the content-based constraints with the only difference, that the predicate is evaluated on a specific attribute value or method of the independent multilevel object yielding to a classification of attribute values and methods of the associated dependent multilevel object. • (Level-based Constraint). Let level (Ei) be a function that returns the classification ci of the value of attribute Ai or of method Mi in object o(a1, c1, ..., an, cn, M1,cn+1, ...,Mm,cm+n, oc) of a multilevel class Om. Let X be a set of attributes and methods of Om such that X ⊆ {A1, ..., An, M1, ..., Mm}. A level-based security constraint LbC is a classification of the form LbC(O (X)) = level (Ei) and results for every object o(a1, c1, ..., an, cn, M1,cn+1, ...,Mm, cm+n, oc) to the assignment cj = ci in the case Ej ∈ X. Level-based security constraints are constraints classifying attributes and methods based on the classification of some other attributes and methods of the same multilevel class. This signifies that for all instances of the multilevel class the concerned attributes and methods are always enforced to be at the same security level. While the constraints considered above classify characteristic properties of multilevel classes, the following additional constraints classify the retrieval results. This is necessary, because security may require that the sensitivity of the result of a query is different from the classifications of the constituent multilevel objects. In that way we cover the aggregation, and the logical inference problem. • (Aggregation Constraint). Let count(O) be a function that returns the number of instances returned by a particular query and belonging to security object O (A1, ..., An, M1, ..., Mm). Let X (X ⊆ {A1, ..., An, M1, ..., Mm}) be sensitive attributes and methods 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

-8-

number of instances of O returned by a query accessing properties X exceeds the value n. Under certain circumstances the combination of several instances of a multilevel class may be regarded as more sensitive than a query result consisting of a single instance only. This phenomenon is known as the aggregation problem. It occurs in cases where the number of instances of a query result is exceeding a constant value specified. • (Inference Constraint). Let PO be the set of multilevel objects involved in a potential logical inference. Let O1, O2, ..., On be a set of particular objects from PO with corresponding multilevel representation Oi (Ai1, Ci1, ..., Ain, Cin, Mi1,Ci(1+n) ..., Mim,Ci(m+n), OCi). Let Xi ⊆ {Ai1, ..., Ain,Mi1, ..., Mim}. A logical inference constraint IfC is a statement IfC (Oi(Xi),..., Oj(Xj)) = C (i, j ∈ {1..n}) and results into the assignment of security level C to the retrieval result of each query that takes Xi, ..., Xj together. Note that the special case Oi = Oj is allowed. Inference constraints restrict from using unclassified data to infer data which is classified. Inferences can occur because of hidden paths that are not explicitly represented in the conceptual data model of the multilevel application. The hidden paths may also involve knowledge from outside the database application domain. One issue related to classification constraints needs further attention, namely, how classification constraints fit into an object-oriented paradigm. One of the basic properties of object-orientation is object encapsulation, i.e. the requirement that all properties of an object class must be encapsulated within that class. How are constraints related to object classes? In the proposed model it is distinguished between two kinds of constraints: constraints that can be allocated to a specific multilevel class and constraints that cannot. To cope with the former we extend the notion of an object class by including constraints. In our model, an object class is determined by a state (attributes), a behavior (methods), and security restrictions (constraints). Constraints are inherited by subclasses next to attributes and methods. When we consider the above taxonomy of constraints, we can identify four constraints posing restrictions on specific multilevel classes and their instances, respectively. Namely, simple constraints (SiC), contentbased constraints (CbC), complex constraints (CoC), and level-based constraints (LbC) can be associated with a specific object class or instance. The result of a query, however, is not necessarily an object fitting in the class structure of the data model [18] because queries may combine information from several object classes. This is the reason why we cannot associate this kind of constraints to object classes. Therefore we view query restricting constraints as constraints allocated to the whole static object model. Our taxonomy lists two constraints restricting query results. These are the aggregation-based constraints (AgC), and the inference constraints (IfC).

-9-

3.2 Graphical Notation of the Static Model To visualize the above defined structuring concepts, multilevel data, and classification constraints, the static model supports the graphical representation (based on OMT [2]) given in Figure 2. In this representation boxes represent object classes. On top of each box the name of the class and the range of valid classifications of the class instances is shown. In addition each box contains the attributes of the object instances along with their classifications, methods and their classifications, and on the bottom of the box the constraints that can be assigned to the object class. In the graphical notation each data modeling concept is shown in full lines, while all concepts related to security are shown in dotted lines. In order to represent the security semantics of the database application, four further modeling concepts are necessary in the graphical representation: sec_aggregation, inference, security dependency and predicates. We will discuss the concepts in section 6 when explaining the underlying method (see figures 6a and 6b).

O, OC A1, C1 ..... An, Cn M1, Cn+1 ..... Mm, Cn+m

generalization object class O with classification range OC, attributes, methods corresponding classifications, and classification constraints

specialization

constraints

2

N TS

association showing cardinality zero or one and specified

×

Co

sec_aggregation leading to TS

Inference leading to Co

Security dependency

association showing cardinality one and equal or greater zero

P aggregation

Fig. 2. Graphical representation of concepts of the static model

Evaluation of predicate P

- 10 -

4. The Functional Model Data Flow Diagrams (DFDs) [19] are a widely accepted mechanism for modelling process structures. A DFD consists of four basic concepts: A process represents an activity within the application and is responsible for transforming data by either changing the values of the attributes of the data, destroying data or generating new information from existing data. Data flow is the second concept and represented by an arrow. A data store is a repository of information and an arrow from the data store pointing toward a process means that the process is reading data from the store while an arrow from the process to the store means that the process is writing on the data store. A source is an external component and responsible for starting or terminating data flow. A powerful feature of DFDs is that they provide the opportunity for hierarchical decomposition of processes and thus may be used to show different levels of abstraction. Similar to the static part, modeling the security requirements of the system functions requires some extensions to DFDs, in particular security labeling of DFD concepts and of the DFD itself. We will intuitively discuss the security semantics of a functional model by means of the examples given in Fig. 3.

...

P1 TS read from store 1

D 1 Data store 1 [U..TS]

P2 U write on store 2

D Data store 2 2 TS

...

Pn TS delete from D2

FIG. 3. Classifying system functions Modelling the functional part of a database makes the choice of a formal security policy necessary. In this example we consider the most prominent policy for information flow control, the Bell and LaPadula security paradigm [3] restricting information flow from high to low. In Fig. 3 the sensitivity of the information from data store D1 is considered ranging from [U..TS]. As process P1 is reading data store D1 it must have a clearance dominating the classification of store D1, i.e. TS. This is indicated in the DFD by appropriate labeling of P1. As there is a data flow from P1 to

- 11 -

process P2 and P1 is cleared to TS while P2 to U only, the data flow might be a source for a covert information flow channel. In the diagram this is indicated by using a bold arrow. Process P2 is writing on D2. Information in D2 is considered as being TS; however, the writing on D2 does not imply reading and therefor a clearance of U is sufficient. This is in contrast with process Pn. Pn is deleting a request stored in D2. Deleting implies read and write access, thus, the clearance of Pn must be TS. Few words are in order to explain why we believe that including functional aspects into modelling security relevant knowledge of an application is necessary. First, information flow and control flow between processes is carefully analyzed and thereby the security critical sections of the application code can be determined. This helps a security administrator when inspecting the code for possible security breaks. It also may help to localize covert information flow channels by highlighting information flows between processes which is of particular importance if data with varying classifications is involved in the data flow. Second, appropriate classifications for the methods of multilevel classes can be determined when analyzing the data flow caused by the method and the code implementing the method. Finally, information flow between processes is determined helping to outline sources for undesired information flow.

5. The Dynamic Model The intention of the dynamic model within the proposed approach is to show the life cycle of an object, that means to show the update behavior of the object. The dynamic model allows to determine events (= method invocations) which result in classification changes of objects or object attributes, and the reason (classification constraint) for the possible classification change. For modeling the dynamic part of a security sensitive application we adopt OBD [4], an approach proposed for modeling object-oriented database schemata. We first give a short overview of fundamental OBD concepts. Second we extend OBD life cycle diagrams for our purposes. Alife cycle diagram depicts the sequence of methods which can be performed on objects of the same object class, and the state changes caused by invoking methods on objects. A life cycle diagram is developed for each object class of the static model and shows which methods can be performed on objects on the appropriate class depending on the actual state of the object, and which state changes this method execution causes. For every object class an implicit attribute “inStates” is defined. This attribute records the actual states of an object. Such a state determines a certain period in the life cycle of an object. This approach is closely related to Petri nets [20] because states are similar to places while methods correspond to transitions. An OBD life cycle diagram depicts a certain state as a rectangle with a trapezoid on its top containing the name of the object class and a trapezoid on its bottom containing the name of the

- 12 -

modeled state (i.e. a value for the implicit attribute “inStates”). Methods defined on an object class are shown as rectangles connected to prestates and poststates by arcs (see Figure 4). To model security relevant knowledge the basic OBD life cycle approach is extended. In particular, classification ranges for instances of an object class, attributes along with their classification range, predicates and security dependency are included in an OBD life cycle diagram. Because of this extensions events (= methods) can be detected which cause a change of the classification of an object or of an object’s attribute. Furthermore, the classification constraint responsible for the change can be identified. In the following, we discuss which classification constraints may be fired because of a method execution. If a method execution updates an attribute two constraints have to be considered: content-based constraints and complex constraints. The constraints are included in the life cycle diagram in the same way as they are in the static model. Furtheron, we draw an arc from the methods causing the constraints to fire to the relevant constraint predicate. Figure 4 shows the graphical notation of the concepts of our dynamic security model.

O,OC A1, C1

O,OC Mj A1, C1

.....

.....

An, Cn

An, Cn

state1

state2 P TS

Fig.4 : Grahical representation of concepts of the dynamic model

The above extended life cycle diagram shows a part of the life cycle of objects of class O. An invocation of method Mj on an instance of O causes a state change of the object from state1 to state2. In addition, the content-based constraint with predicate P is fired. This firing can result in a new classification of attribute A1.

- 13 -

6. The Method The proposed modeling technique for multilevel data includes a design method consisting of a set of modeling and design guidelines. The basic idea is to perform integrated data -, function -, and behavior modeling by alternating refinements on either of the three schemes: each refinement in one schema is influenced by both the previous version of the schema and the state of design in the other schemes. Performing such an iterative approach has the advantage of being able to check whether modeling concepts and security constraints in one schema have corresponding equivalents in the other schemes. The design methodology consists of several phases (Fig. 5 shows their interaction) which will be explained by means of an example in the following.

Problem Domain 1. develop

2. classify

Static Model 6. add constraints

6. add methods 8. chonsistency checks 3. develop

Functional Model

Dynamic Model

7. security semantics

4. develop

5. classify

Conceptual Model

Fig. 5: Methodology for OO modeling of security relevant knowledge 1. Develop a static model based on the requirements specification: During this phase the basic static structure of the database is determined and graphically represented by using OMT’s object model. The example design is shown in Fig. 6(a).

- 14 -

2. Express application dependent security semantics: A first static model is enhanced by security semantics. Security semantics are specified using the classification constraints (identified in subsection 3.1) in a classification language and graphical concepts for security dependencies, (as arrow indicating source and destination of a classification), predicates (for complex or contentbased constratints), aggregation and inference classification constraint. For our example design we consider following constraints: (P1) simple constraint (SiC (Employee, {Salary}, Co)) restricting users cleared lower than Co from accessing attribute Salary; (P2) content-based constraint (CbC (Project, {Requirements}, Objective, ‘=’ ‘Research’, S)) assigning S to projects having as Objective a value of ‘Research’; (P3) complex constraint (CoC (Assignment, {*}, Project, Objective, ‘=’ ‘Research’, S)) classifying assignments referring projects with Objective = ‘Research’ with S; (P4) an aggregation constraint (AgC (Assignment, {*}, ‘3’, Co)) restricting a query result to a maximum of 3 instances for users cleared below Co; and finally (P5) an inference constraint (IfC (Employee, {Dep}, Project, {Objective}, Co)) restricting users to infer assignment information by combining employee and project data. Fig 6(b) is a graphical representation of the situation described above.

Employee

(a)

SSN Name Dep Salary Skills InStates

Project

assigned Assignment Date Function InStates

X

Co

(b)

Project, U

P3

Employee, U SSN, U Name, U Dep, U Salary, Co Skills, U InStates, U

Title Objective Client Requirements InStates

S assigned Assignment, [U...S] Date, U Function, U InStates, U

Title, U Objective, U Client, U Requirements, [U...S] InStates, U

P2 S

3 N

Co

Fig. 6: Static model and static model enhanced by classification constraints

- 15 -

3. Develop a functional schema and determine methods. At this phase of the design it is necessary to consider the functionality of the database application. In the proposed approach a DFD is developed for each database function (for example for the employee - project assignment as shown in Fig. 10). The processes of the DFD are used to determine the methods of the multilevel classes in the static model. Developing a DFD starts with a context diagram showing the highest level of abstraction consisting of only a single process and its interface to external events. The next step is to decompose the process and to show its internals. Referring to our example an assignment is established or rejected after a request for assignment is stored and evaluated. From the processes identified in the functional schema (see Fig. 10) we can derive the methods for the multilevel class Employee (reqAssign) from the context diagram and for class Assignment (create, compRequSkills, activate, and reject) from the corresponding processes in the detailed DFD. We distinguish between two kinds of methods: methods which are visible to the outside and methods which are only invoked by other methods. Only the former are subject to security level assignment. In the example, U is chosen for method reqAssign of Employee. Methods are added to the appropriate objects of the static model. 4. Develop a dynamic model for each object class of the static model. During their existence in the database objects may dynamically change their states. Each state represents a period in the life cycle of an object. As an example the life cycle of objects of class Assignment is depicted in Fig. 7 .

reject

Assignment Date Functions rejected

create triggerSync: EMPLOYEE. reqAssign

Assignment Date Functions created

compRequSkills

Assignment

Assignment

Date Functions checked

Date Functions passive

passivate Assignment activate

Date Functions activated

triggerSync: PROJMGMT. stopProj

Fig. 7. Dynamic model for object class Assignment In the example an instance of class Assignment may be in one of five different states. First, an assignment is in state created after a request was started. Next, its state is checked, which is valid after method compRequSkills has been fired. From the DFD we know the method is responsible for comparing requirements necessary to get assigned with the skills of a particular employee. Based on the outcome assignment may either be in state activated or rejected. In the case the assignment has been activated a further method is responsible for transforming the assignment into

- 16 -

state passive as soon as the corresponding project has been finished. 5. Classify objects states. Depending on its state within the life cycle the classification of an object may vary. Constraints defined on object states are based on the implicit attribute ‘inStates’ and may only involve content-based or complex classifications constraints. Referring to the example universe (see Fig. 8) we can identify the following classification constraints: (P6, P7) Requests for assignment are treated TS during states created and checked (CbC (Assignment, {*}, inStates, ‘=’, ‘created’, TS) and CbC (Assignment, {*}, inStates, ‘=’, ‘checked’, TS)). Unsuccessful requests (P8) are always treated as TS information (CbC (Assignment, {*}, inStates, ‘=’, ‘rejected’, TS)). From the static schema we know that assignments referring to a project with subject = “Research” are considered as S. This information is included in the dynamic model (P3). Further classifications include (P9) (CbC (Assignment, {*}, inStates, ‘=’, ‘active’, Date, ‘