clearance. ⢠facts: user( sample user smith, user name sweetie, password. 2). clearance. ⢠rules: .... employee(1, 'Harold Smith', 'Artificial Intelligence',. 22300.0).
The Deductive Filter Approach to MLS Database Prototyping G. Pernul, W. Winiwarter, A M. Tjoa Institute of Applied Computer Science and Information Systems University of Vienna, Liebigg. 4/3-4, A-1010 Vienna, Austria Abstract This paper proposes building a prototyping environment as part of the standard design process of multilevel secure database applications. For this paper we see the following contributions: First, based on a careful study of multilevel security requirements we developed a security constraints language (SCL) for specifying application dependent database security semantics. Second, we implemented SCL by using the deductive database system LDL thereby offering a useful toolset with which a prototype of a multilevel secure relational database application can efficiently be developed. Prototyping will help the database designer to arrive at a consistent data classification and at a satisfactory database design.
1: Introduction Research and development in the area of multilevel secure (MLS) databases has increased dramatically in recent years. As a result the first MLS DBMS products are already commercially available. Applying the new technology to real world database applications is a difficult and complicated task and makes a careful design of the database necessary. The major problem involved is data classifying and is the important design decision of how the data of the database should be classified. Data classifying involves the assignment of a security classification to a data item and is the transformation of a security object into a multilevel security object. Classifications are rules that are assigned based on specified security constraints and must properly represent the security semantics of the application. Classification rules may become very complex and for large applications rules may conflict with other classification rules specified. To overcome this problem we propose to extend the common database development process by building an experimental prototype before the final implementation
of the database. The goal of the prototype is to achieve a concise and non-conflicting specification of the security constraints. Based on a concrete example of the application domain, the database designer and the security officer (or trusted users) are able to examine by using the prototype the adequacy of the database design and of the security classifications specified. In this paper we give the formal basis and implementation details about the prototyping language with which the prototype can be efficiently constructed without involving high development costs. As prototyping environment we have decided to use the deductive database system LDL ([4][11]) as storage manager as well as its features for the implementation of a deductive filter testing security constraints. Using a deductive filter in front of the real data has the following advantages: First, as deductive databases combine features of logic programming with relational algebra, it is possible to define recursive rules as well as complex object types like lists or sets. These perfectly meet the requirements of a security constraints language covering transitive dependencies between security constraints. Second, LDL possesses no procedural semantics, in favor of a purely declarative one. This helps to state even extremely complex security requirements in a clear and concise style which is a basic requirement for experimental prototyping. The outline of this paper is as follows: In section 2 we generally discuss the design process of a MLS database and show how experimental prototyping fits into it. Moreover, section 2 contains the references to related work. Section 3 consists of a general discussion of security requirements used to represent security semantics of database applications. This framework defines the scope of our Security Constraints Language (SCL) as shown in section 4. Section 5 contains implementation details of the experimental prototype in LDL. In section 6 we show by means of a representative example how a prototype helps in getting a clear understanding of a multilevel secure database application. Section 7 concludes the paper.
-2-
2: The design process of MLS databases In a MLS database each data item d is assigned to a classification (class(d)) while each user u to a clearance (clear(u)). Most systems implement the Bell LaPadula [1] security paradigm which distinguishes between read and write accesses. For read access the simple security property clear(u)≥class(d) must hold while for write access clear(u)=class(d) is necessary. The second condition is called the restricted *-property and is necessary to restrict information flow from high to low. The design of a MLS database usually is an iterative process, often involving trial and error. It is not clear how the process should be decomposed into well-defined steps. What is customary for the design of general purpose databases may also have some potential for the design of MLS databases. At least four different phases and activities can be identified: Requirements Analysis, Conceptual Design, Logical Design, and the final Implementation of the database application. We propose to extend this process and to include before the final implementation an experimental prototyping phase for the MLS database development process. Experimental Prototyping. Security constraints may become very complex and for large databases conflicting constraints may be unintentionally expressed. By using a prototyping system constraints may be tested based on concrete examples of the application domain. This will help the database designer to arrive at a better understanding of the security semantics of the database application. In the case the constraints are free of any conflicts and the design is adequate the database application can be implemented. A large number of literature relates to either of the different phases but there is not much work known that comprehensively addresses all aspects related to the design of a multilevel secure database application. The first attempt to develop a layered approach for the design of secure databases is given in [7]. Most work on design issues for multilevel secure databases is focused on conceptual modelling and design of security semantics of database applications. In [16] and [17] the semantic model of security is developed by extending a high-level data model with security relevant abstractions. In [8], [15], and others the Entity Relationship Approach is used to model and describe security requirements of database applications. While most of the work is focused on modelling the static part of a database only the two approaches in [2] and [12] are known that include the modelling of the security requirements of the functions a system has to perform. [18] is an approach in which it is suggested to handle the logical inference problem in MLS databases by using conceptual structures.
Techniques for the logical design of MLS databases have been proposed frequently and are mainly focused on decomposition techniques for the construction of single level fragments from multilevel base relations (for example see [9], [13], or [6]). Prototyping a database application to arrive at a satisfactory database design has been first performed in [10].
3: Requirements for a constraints language In this section we will define as the underlying basis of the prototyping environment a security constraints language (SCL). By using SCL a database designer is able to state the security requirements of a database application. We will start with giving an informal discussion of security requirements in the context of multilevel security. The discussion is followed by a careful formalization of the security requirements and of a set of consistency criteria. The formal constraint system is used as the basis for the mapping of the security requirements into logical predicates specified in LDL.
3.1: Security semantics and database applications In a multilevel context security constraints are rules with which data items and combinations of data items must be classified. The rules are used to describe the security semantics, i.e. the information what makes an event of reality classified. It is commonly agreed that security semantics are application dependent and data must be classified based on the context it appears in. In general, there are many reasons for data to be classified. The reasons may have to do with the value of the data, associations between data, the time the data is accessed, and others. In the following we will intuitively discuss representatives of the most important security constraints. For a careful definition and formalisation of the constraints see [14]. We assume a situation where three different security objects (please note the definition of security object in Section 3.2 which is slightly different from other) should be modelled in a database: Security object_1 is a set of Employees that should be represented in the database. Each instance of Employee is uniquely described by a characteristic SSN (i.e. the social security number). Of further interest are the name, the department the employee is working for, and the salary of an employee. Security object_2 is a set of Projects. Each project has as an identifying characteristic a unique project-number, has a project-name, a subject, and a client. Employees are assigned to projects. Each individual assignment is an instance of security object_3 (Assignment) and characterized by the date of the assignment and the mission the employee has to perform
-3-
during the participation in the project. For a particular project at least one employee must be assigned and each employee must work for at least one project but can only be involved in a maximum of three projects. • Simple constraints are constraints that classify certain characteristics of security objects. For example, classifying the characteristic that employees have a salary (i.e. classifying property Salary) or classifying that employees are assigned to projects (i.e. classifying security object Assignment) are examples of simple security constraints. • Content-based constraints are constraints that classify characteristic properties of instances of security objects based on the evaluation of predicates. For example, classifying the salary of employees if it is higher than 100 is a content-based constraint. • Complex constraints are constraints that involve several different security objects participating in a dependency relationship. As an example consider the classification of instances from object Assignment representing assignments of employees that have a salary higher than 100. In this case the classification of an instance of a security object is dependent on a property that is not part of the instance itself but a characteristic of an instance of a related object. In our example the classification of security object Assignment is based on a characterization of security object Employee (i.e. the salary). • Level-based constraints are constraints that classify data items based on the classification of some other characteristic property of the same security object. A situation where the department an employee works for must always be classified with the classification of the salary of the employee is an example of a level-based constraint. • Association-based constraints are constraints that restrict from combining the value of certain characteristics with an identifying property of the security object. As an example consider a situation where all salaries that are paid are unclassified. However, inferring which employee gets what salary should only be possible for users cleared to access classified information. • Inference constraints are constraints that restrict from using unclassified data to infer data which is at a higher classification. This can involve certain knowledge from outside the system. For example consider the situation where the assignments of employees to projects are considered as sensitive. However, 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.
• Aggregation constraints are constraints that restrict from combining unclassified data resulting in combined data having a classification higher than any of the constituting data items. As an example consider the situation where the information which employee is assigned to what projects is considered as unclassified. However, aggregating all assignments for a certain project and thereby inferring the information which team (aggregate of assigned employees) is responsible for what project is considered classified.
3.2: Basic definitions In order to be able to define a security constraints language for MLS database prototyping we need a clear understanding and formalization of the security requirements under consideration. For the following consider a universe of discourse UoD to be represented in a database and consisting of a set of security objects OT. Each security object O (O∈OT) consists of a set of characteristic properties {A1,...,An} and thus can be denoted by O(A1,...,An). Each property Ai is represented by a data item and defined over a domain Di. Each security object O must have an identifying property that makes instances of O distinguishable from other occurrences of the object. For simplicity we assume for any security object A1 as being such a property. Moving to a multilevel world each data item and combinations of data items are subject to security classification. In mandatory security systems a security classification is an entry in a classification lattice SC and consists of two components: a hierarchical component (usually: top-secret > secret > confidential > unclassified) together with a set of categories. Security classifications are partially ordered and thus form the lattice in the following way: Given two security classifications SC1 and SC2 (SC1,SC2∈SC), SC1≥SC2 iff the hierarchical component of SC1 is greater than or equal to that of SC2 and the categories of SC1 include the categories of SC2. For simplicity throughout the paper we assume the existence of a single category only and thus in our case for two different security classifications SC1 and SC2, SC1>SC2 or SC1,,1 retrieves value of Ai checking Cuser≥Ci decrementing i recursive predicate for checking remaining Ai if Cuser≥Ci then characteristic property is appended to result list else result list remains unchanged exit rule for recursion, starts with value of A1 as result
check(Keylevel, Onr, Anr, Key, Confirm, Level) =Level then then Confirm=1 else Confirm=0). seccheck(Onr, Anr, , Key)
