This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
This paper talks about a model that was designed to secure multilevel database systems. This model was named as the SeaView model. The SeaView project was a three-year program to create the design of a multilevel secure relational database system that meets the criteria for Class Al of DOD. The project produced a security policy and interpretation, a multilevel relational data model that extends the standard relational model to support explicitly labels for elements and tuples, a formal security policy model, formal top-level specifications, and implementation specifications for the new system components. In addition, it also had a demonstration system that illustrates polyinstantiation and operations on multilevel relations. The SeaView specifications contain a formal policy model of the security requirements for multilevel secure databases, as well as an abstract description of the database operations .
Accomplishments of the SeaView project
It is a belief that the sea view project has sophisticated the state of the art in multilevel database security. SeaView's major accomplishments are listed below:
- A security policy interpretation that defines what security means for a database system. There are also requirements for database consistency and integrity as they are essential components to security.
- A multilevel relational data model, which is an extension to the standard relational model that specifically accommodates element labels and affects the multilevel security on the integrity rules and operators of the relational model.
- A formal security policy model that includes security properties defining a secure state, and transition properties that further restrict allowable transitions. Properties relating to data consistency, transaction integrity, and enforcement of both value and classification constraints, as well as more traditional access control properties, are included in a two-layer hierarchical model.
- The SeaView security model requires that database integrity hold with respect to the subset of the database visible at any security level. This approach makes it possible to achieve database integrity without introducing inference channels.
- A precise formulation of polyinstantiation, which prevents low users from inferring the existence of high data objects.
- Rules to determine an appropriate label for each derived data.
- An approach of aggregation, to eliminate information leakage. SeaView requires that all data comprising an aggregate be stored at the higher, aggregate class, thus protecting it from unauthorized disclosure by an underlying mandatory security kernel.
- A rule-based approach to label the incoming data that frees the user from the burden of remembering or looking up classification rules.
- SeaView constructs multilevel relations as views over stored single-level relations. The single-level relations are stored in segments managed by an underlying mandatory security kernel. Thus, individually labeled data elements do not have to be stored in individually labeled storage objects as was supposed prior to SeaView .
The SeaView security model allows the individual data elements within a relation to be classified individually. Several previous research efforts have proposed security models for multilevel databases. The earliest of these were the Hinkehchaefer model, which supports classification at the attribute level, and the I.P. Sharp model, which supports classification at the relation level. Then the TRW model was developed to support tuple-level classification. The Navy surveillance model supports multilevel relations. This is accomplished by treating entities such as relations as containers of data, rather than as identifiers, as does SeaView. The Lock Data View model supports element-level classification and is designed for the Lock special-purpose architecture .
Few important terms that need to be understood in order to understand the SeaView security model are as follows:
- Mandatory Security: Classified data has to be protected not only from direct access by unauthorized users, but also from disclosure through indirect means, such as covert signaling channels.
- Covert Channels: These are the information channels that were not designed to be used for information flow but can be exploited by malicious software to signal high data to low users.
- Trusted subject: It is a subject (i.e, executing program) that is allows reading and writing within a range of access classes.
- Reference monitor: The concept of reference monitor was developed to demonstrate a system's trustworthiness. The reference monitor mediates each reference to an object by any subject, allowing or denying the access based on a comparison of the access classes associated with the subject and with the object.
Sea View Model
The Sea View model extends the concept of a relation to a multilevel relation, where each element and each tuple has an access class. The tuple class represents the class of the information encoded in the tuple. The model supports both multilevel real relations and views, but treats all multilevel relations as views. This is because mandatory security requires that data in a relation to be hidden from a user who is not cleared, this results in different users seeing different instances of the same relation. The different instances of a multilevel real relation are modeled by a function that returns the instance of a relation visible at a given access class, and by a property that shows how the different instances must be related to each other. It is not enough for the database system to conceal data from a user; the system must respond to the user as though the hidden data does not exist.
The SeaView approach of defining multilevel relations as views over underlying single-level base relations allows multilevel insert, delete and update operations to be decomposed into corresponding single-level operations on the single-level base relations, and lends itself to a design that uses a commercially available relational database management system for the single-level relations. The decomposition was intended to be transparent to the user, who would consider the multilevel real relations to be the actual base relations of the database system. Thus the SeaView model extends the application-independent integrity rules of the relational model, namely, entity integrity and referential integrity to multilevel real relations; allows application-dependent integrity rules to be defined on multilevel real relations; and ensures that updates of multilevel real relations are well defined. In addition, the SeaView model constrains multilevel real relations by a third application-independent integrity rule called polyinstantiation integrity, which specifies consistency for polyinstantiated tuples and elements.
The Sea View model supports a policy for data consistency that is manifest in both the application-independent integrity rules and in application dependent rules or constraints. Constraints can apply both to data values, through value constraints, and to their access classes, through classification constraints .Classification constraints provide a form of rule-based classification wherein classification can be determined by a subject; by the access class of a subject; or by the type, context, or content of the data.
Relational integrity rule:
- Entity Integrity: Null values are not allowed for primary key attributes of a relation.
- Referential Integrity: The value of a foreign key must be either null or there must be a tuple with the foreign key value for the exported reference attribute(s) in the referenced relation.
In addition, the Sea View model has a third integrity rule, called
* Polyinstantiation Integrity: It defines consistency in the presence of polyinstantiation. The standard relational operators are also extended in the Sea View model so as to compute access classes for derived tuples.
Denning has suggested a simplification of the original SeaView approach that would not provide users with the abstraction of multilevel real relations, but that would treat all multilevel relations as views, or derived relations. With the simplified approach, the application-independent integrity rules of the standard relational model require no extensions, and polyinstantiation integrity is unnecessary. Figures 1 and 2 illustrate the difference between the two approaches. Figure 1 illustrates a design approach that would implement the full generality of the SeaView model, which supports multilevel base relations; Figure 2 depicts the simplified approach, in which all base relations are single-level.
The SeaView Design
In pursuit of Class A1 assurance, in SeaView we have adopted a design approach that is built on the notion of a reference monitor for mandatory security. SeaView provides the user with the basic abstraction of a multilevel relation in which the individual data elements are individually classified. This design approach implements multilevel relations as views stored over single level relations, transparent to the user. The single-level relations are stored in segments managed by an underlying mandatory reference monitor. This underlying mandatory reference monitor performs a label comparison for subjects and the segments for which they request access, to decide whether to grant access. The access class of any particular data element in a multilevel relation is derived from the access class of the single-level relation in which the data element is stored, which in turn matches the access class of the segment in which it is stored, which is known to the reference monitor. Thus, labels for each individual data element do not have to be stored, as was supposed prior to SeaView. 
In SeaView, every database function is carried out by a single-level subject. Thus, a database system subject, when operating on behalf of a user, cannot gain access to any data whose classification is not dominated by the user's clearance. The use of only single-level subjects for routine database operations provides the greatest degree of security possible and considerably reduces the risk of disclosure of sensitive data. This approach means that there must be at least one database server instance for each active access class. Thus, the database system consists of multiple database server instances that share the same logical database.
The SeaView security model is, designed with two model layers namely the MAC model, which is the inner layer, and the TCB model, which is the outer layer
Mandatory Access Control
Sea View is a relational database with MAC. MAC stands for Mandatory Access Control. These policies apply only to multilevel databases, which are databases that contain information of different classifications.It protects data against Trojan horse. It is based on theBell-LaPadula model whereeach subject or object has a security level: Top Secret, Secret, Confidential, and Unclassified (TS>S>C>U)
Read-down: a subject S has read access to an object O if and only if level(S) >= level (O);
Write-up: a subject S has write access to an object O if and only if level(S) <= level (O);
The MAC model provides a formal statement of the SeaView mandatory security policy, which states that no user is to be given access to classified or other sensitive information unless that user has been determined to possess the requisite secrecy and integrity authorizations (clearances) for the information, based on the information's classification. This policy is formalized in terms of subjects, objects, and access classes, where each subject has a read class and write class, each object has a class, and a subject's ability to access an object depends on the classes of the subject and object. 
The MAC model assigns two access classes to each subject S: read-class(S) and write-class(S), where read class(S) >= write-class(S). The access requirements are formalized by the following two rules:
- A subject S can read data of access class c only if read-class(S) >= c, and
- A subject S can write data of access class c only if write-class(S) <= c.
How it fixes Trojan horse problem: if T has high security level, then B cannot read it; if it has low security level, the Trojan horse program, which has the same high security level as A, cannot write it.
The TCB model defines the discretionary access control policy and the supporting policies. The TCB model is a formal statement of the SeaView discretionary security policy and the supporting policies for labeling, data consistency, sanitization, and reclassification. The model includes a multilevel relation that includes real relations, snapshots, views, keys, relational expressions, and databases. It includes the application-independent integrity constraints of the multilevel relational data model and requirements for labeling derived data. It models the different relation instances seen by subjects of different access classes. It also includes application-dependent constraints (on classes and values), transactions, and discretionary access controls. 
Authorization rule used in Sea View project is as follows:
Each user or object (relation/ tuple/ attribute/ elements or attribute value) has a security level: TS, S, C or U.
Each attribute in the original table is associated with a security level, and each tuple has a security level.
The effect of hiding data in a relation leads to polyinstantiation or the simultaneous existence of like-named objects, which are distinguished only by their access classes. Specifically, it can lead to multiple tuples with the same primary key values but different access classes (polyinstantiated tuples), and to tuples that have multiple values, each at a different class, for a non-key attribute (polyinstantiated elements).
The Sea View Model supports polyinstantiated tuples and elements by representing them as distinct tuples; hence, tuples of real relations are not distinguishable by their primary key values. Because hidden and polyinstantiated data affect the two application independent integrity rules of the standard relational model, the Sea View model includes extended versions of these rules.
They are the multiple tuples with the same primary key values but different access classes. Polyinstantiation is necessary, as we hide the actions of high subjects from low subjects, thereby preventing signaling channels. Although the polyinstantiation is invisible to this subject, subjects at the higher access class can see both tuples.
Although the requirement for mandatory security is handled entirely by the MAC model, the TCB model is greatly affected by these requirements. Indeed, many of the components and properties of the TCB model are needed to address the effects of mandatory security on multilevel relational database systems. The SeaView TCB model was developed for a relational database system, and includes relations and the application-independent integrity rules of the relational model. Overall, to secure a database system that has users with different classification levels, multilevel database is the best solution.
- D. E. Denning, S. G. Akl, M. Heckman, T. F. Lunt, M. Morgenstern, P. G. Neumann, and R. R. Schell. Views for Multilevel Database Security. IEEE Trans. on Software Eng., SE-13(2):129-140, Feb. 1987
- D. E. Denning, T. F. Lunt, R. R. Schell, M. Heckman, and W. R. Shockley. A Multilevel Relational Data Model. In Proc. 1987 Symp. on Security and Privacy, 1987.
- D. E. Denning, T. F. Lunt, R. R. Schell, M. Heckman, and W. R. Shockley. The SeaView Security Model. IEEEexplore, 1988.
- D. Warren, T. F. Lunt, R. R. Schell, M. Heckman, and W. R. Shockley. A Near-Term Design for the SeaView Multilevel Database System. IEEE Symposium on security and privacy. 1988.
- D. E. Denning, T. F. Lunt, R. R. Schell, M. Heckman, and W. R. Shockley. The SeaView Security Model. IEEE Trans. On Software Eng., June. 1990.
- R.A.Whitehurst, T.F. Lunt. The SeaView Verification. IEEE.