Advanced
We recommend Computer System
Security--An Overview as prerequisite reading for this technology description.
Conventional
database management systems (DBMS)
do not recognize different security levels of the data they store and
retrieve. They treat all data at the same security level.
Multi-level secure (MLS) DBMS schemes provide a means of maintaining a collection of data with mixed security levels. The access mechanisms allow users or programs with different levels of security clearance to store and obtain only the data appropriate to their level.
As shown in Figure 20, multi-level secure DBMS architecture schemes are categorized into two general types:
- the Trusted Subject architecture
- the Woods Hole architectures
Figure 20: MLS DBMS Schemes
The Woods Hole architectures are named after an Air Force-sponsored study on multi-level data management security that was conducted at Woods Hole, Massachusetts.
The Trusted Subject architecture is a scheme that contains a trusted DBMS and
operating system
(see Trusted Operating
Systems). The DBMS is custom-developed with all the required security
policy (the security rules that must be enforced) developed in the DBMS
itself. The DBMS uses the associated trusted operating system to make actual
disk data accesses. This is the traditional way of developing MLS DBMS
capabilities and can achieve high mandatory assurance for a particular
security policy at the sacrifice of some DBMS functionality
[Abrams 95]. This scheme results in a special purpose DBMS and operating system that requires a large amount of trusted code to be developed and verified along with the normal DBMS features.Trusted code provides security functionality and has been designed and developed using a rigorous process, tested, and protected from tampering in a manner that ensures the Designated Approving Authority (DAA) that it performs the security functions correctly. The DAA is the security official with the authority to say a system is secure and is permitted to be used. A benefit of the trusted subject architecture is that the DBMS has access to all levels of data at the same time, which minimizes retrieval and update processing. This scheme also can handle a wide range of sensitivity labels and supports complex access control. A sensitivity label identifies the classification level (e.g., confidential, secret) and a set of categories or compartments that apply to the data associated with the label.
The Woods Hole architectures assume that an untrusted (usually commercial-off-the-shelf (COTS)) DBMS is used to access data and that trusted code is developed around that DBMS to provide an overall secure DBMS system. The three different Woods Hole architectures address three different ways to wrap code around the untrusted DBMS.
The Integrity Lock architecture scheme places a trusted front end filter between the users and the DBMS. The filter provides security for the MLS. When data is added to the database, the trusted front end filter adds an encrypted integrity lock to each unit of data added to the database. The lock is viewed by the DBMS as just another element in the unit stored by the DBMS. The encrypted lock is used to assure that the retrieved data has not been tampered with and contains the security label of the data. When data is retrieved, the filter decrypts the lock to determine if the data can be returned to the requester. The filter is designed and trusted to keep users separate and to store and provide data appropriate to the user. A benefit of this scheme is that an untrusted COTS DBMS can perform most indexed data storage and retrieval.
The Kernalized architecture scheme uses a trusted operating system and multiple copies of the DBMS; each is associated with a trusted front end. The trusted front end-DBMS pair is associated with a particular security level. Between the DBMS and the database, a portion of the trusted operating system keeps the data separated by security level. Each trusted front end is trusted to supply requests to the proper DBMS. The database is separated by security level. The trusted operating system separates the data when it is added to the database by a DBMS and combines the data when it is retrieved (if allowed by the security rules it enforces for the requesting DBMS). The high DBMS gets data combined from the high and low segments of the database. The low DBMS can only get data from the low segment of the database. A benefit of this scheme is that access control and separation of data at different classification levels is performed by a trusted operating system rather than the DBMS. Data at different security levels is isolated in the database, which allows for higher level assurance. Users interact with a DBMS at the user's single-session level.
The Distributed architecture scheme uses multiple copies of the trusted front end and DBMS, each associated with its own database storage. In this architecture scheme, low data is replicated in the high database. When data is retrieved, the DBMS retrieves it only from its own database. A benefit of this architecture is that data is physically separated into separate hardware databases. Since separate replicated databases are used for each security level, the front end does not need to decompose user query data to different DBMSs.
Castano and Abrams provide thorough discussions of these alternative
architecture schemes and their merits
[Castano 95,
Abrams 95].
This technology is most likely to be used when relational databases must be
accessed by users with different security clearances. This is typical of
Command and Control systems. The different architectures suit different
needs. The Trusted Subject architecture is best for applications where the
trusted operating system and the hardware used in the architecture already
provide an assured, trusted path between applications and the DBMS
[Castano 95]. The Integrity Lock architecture provides
the ability to label data down to the row (or record) level, the ability to
implement a wide range of categories, and is easiest to validate
[Castano 95]. The Kernalized architecture scheme is
suited to MLS DBMS systems with more simple table structures because it is
economical and easier to implement for simple structures
[Castano 95]. The Distributed architecture is best
suited for DBMSs where physical separation of data by security level is
required
[Abrams 95].
The four different architectures have different maturity characteristics. As
of August 1996, an R&D A11 system and six commercial2 DBMSs have
been implemented using the Trusted Subject architecture scheme for different
assurance levels and security policies. One R&D system and one commercial
DBMS have been implemented using the Integrity Lock architecture scheme. One
R&D system and one commercial DBMS have been implemented using the
Kernalized architecture scheme
[Castano 95]. The Distributed architecture scheme has
only been used in prototype systems because of the high performance cost of
the replicater, although one commercial DBMS claims to have this feature
[Abrams
95]. This DBMS however, has not been evaluated by the National Computer
Security Center (NCSC)
[TPEP 96].
Each of the different MLS architecture schemes has different costs and limitations. The Trusted Subject architecture scheme has a closely linked DBMS and Operating System that must be proven trusted together. This makes it hardest to validate and gives it the highest accreditation cost compared to the other schemes. The Integrity Lock architecture scheme requires that a Crypto Key management system is implemented and supported in operation. The Kernalized architecture requires a DBMS for each security level, which makes it expensive as more than two or three levels are considered. The Distributed architecture requires a different hardware platform for each security level and the data replicater provides a heavy processor and I/O load for high access data.
The MLS architecture schemes have individual dependencies. The Trusted Subject
scheme is dependent on trusted schemes for a related DBMS and operating
system. The Integrity Lock scheme is dependent on cryptographic technologies
to provide the integrity lock. The Kernalized architecture scheme depends on
Trusted Operating Systems technologies. The Distributed architecture scheme is dependent on efficient automatic data replication techniques.
The alternative to these technologies is to use a single-level DBMS and use manual review of retrieved data or have every user cleared for the data in the database. That may not be feasible in a Command and Control system.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
Name of technology
|
Multi-Level Secure Database Management Schemes
|
|
Application category
|
Data Management Security (AP.2.4.2)
|
|
Quality measures category
|
Security (QM.2.1.5)
|
|
Computing reviews category
|
Operating Systems Security & Protection (D.4.6)
Security & Protection (K.6.5)
Computer-Communications Network Security and Protection (C.2.0)
|
|
[Abrams 95]
|
Abrams, Marshall D.; Jajodia, Sushil; & Podell, Harold J. Information
Security An Integrated Collection of Essays. Los Alamitos, CA: IEEE
Computer Society Press, 1995.
|
|
[Castano 95]
|
Castano, Silvana, et al. Database Security. New York, NY: ACM Press,
1995.
|
|
[DoD 85]
|
Department of Defense (DoD) Trusted Computer System Evaluation Criteria
(TCSEC) (DoD 5200.28-STD 1985). Fort Meade, MD: Department of Defense,
1985. Also available WWW
<URL:
http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html> (1985).
|
|
[TPEP 96]
|
Trusted Product Evaluation Program Evaluated Product List
[online]. Available WWW
<URL:
http://www.radium.ncsc.mil/tpep/index.html> (1996).
|
Tom Mills, Lockheed Martin
10 Jan 97 (original)
1
An A1 system is one that meets the highest (most stringent) set of
requirements in the Department of
Defense Trusted Computer Systems Evaluation Criteria (the Orange Book)
[DoD 85].
See Trusted Operating Systems
for a further description of the classes of trusted operating systems.
2
A commercial DBMS does not imply a general-purpose DBMS. It means that it can
be packaged and sold
to other people. If a MLS DBMS has been developed to provide specific security
functions that customers
need, and the customer is willing to be restricted to that set of functions
and use the same hardware and
support software, then it can be sold as a product. It is then a commercial
DBMS. The six commercial
DBMSs that have been implemented with the Trusted Subject architecture are all
different from each other, as
they have been developed with different security policies for different
hardware and software environments.
