Towards a multilevel secure database management system for real ...

12 downloads 11563 Views 410KB Size Report
Apr 19, 2010 - A real-time database management system. (RTDBMS) is a transaction processing system where transactions have explicit timing con- straints.
Towards a Multilevel Secure Database Management System for Real-Time Applications Sang H. Son? Department of Computer Science University of Virginia Charlottesville, VA 22903 Bhavani Thuraisingham The MITRE Corporation Bedford, MA 01730

on the time at which a transaction is completed. Transactions must be scheduled and processed in such a way that they can be completed before their corresponding deadlines expire. Real-time database systems are being used for a variety of applications such as process control, mission critical applications in command and control systems and radar systems, computer integrated manufacturing systems, and air traffic control systems, among others. Conventional data models and databases are not adequate for time-critical applications, since they are not designed to provide features required to support real-time transactions. They are designed to provide good average performance, while possibly yielding unacceptable worst-case response times. Very few of them allow users to specify or ensure timing constraints. During the last few years, several research and development efforts have been reported on RTDBMSs [SIGM88, HUAN9 1, KIM93, SHA9 1, SON90, SON91, SON92, SON92b, SON93, SON93bl. While the advances were being made in the area of RTDBMS, during the past decade, much work has been c a n i d out on the design and development of a multilevel secure database management system (MLSDBMS), mainly based on the relational data model (see, for example, [AFSB83, DENN87, STAC901). As a result, at present, some of these MLSDBMSs are commercially available. In these database systems, users cleared at different levels are expected to access and share a database consisting of data at different sensitivity levels. The MLSDBMS must ensure

ABSTRACT Database systems for real-time applications must satisfy timing constraints associated with transactions, in addition to maintaining data consistency. In addition to real-time requirements, security is usually required in many applications, because sensitive information must be safeguarded. Multilevel security requirements introduce a new dimension to transaction processing in real-time database systems. This paper addresses issues that must be investigated in order to design and develop a multilevel secure database management system for real-time applications.

1. INTRODUCTION A real-time database management system (RTDBMS) is a transaction processing system where transactions have explicit timing constraints. Typically, a timing constraint is expressed in the form of a deadline, a certain time in the future by which a transaction needs to be completed. A deadline is said to be hard if it cannot be missed or else the result is useless. If a deadline can be missed, it is a soji deadline. With soft deadlines, the usefulness of a result may decrease after the deadline is missed. In RTDBMS, the correctness of transaction processing depends not only on maintaining consistency constraints and producing correct results, but also

m

f ' h i s WO& was supported in part by

ONR.by IBM,

and by

131 0-8186-4130-4/93$03.00 0 1993 IEEE

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 19,2010 at 19:28:19 UTC from IEEE Xplore. Restrictions apply.

Transaction Characterization: In addition

that users obtain data classified at or below their security levels. Most of these MLSDBMSs are expected to be used for C31 applications. In principle, however, any database system that maintains sensitive information to be shared by multiple users with different levels of security clearance requires multilevel security. Many of these applications also require RTDBMSs. As more and more of such systems are in use, one cannot avoid the need for integrating them. That is, the RTDBMSs have to be made multilevel secure and the MLSDBMSs need to support real-time applications. To our knowledge no work has been reported on developing DBMSs which are multilevel secure and which support real-time applications. Recently, at the fifth Rome Laboratory Workshop in Database Security, we presented a note on the security impact on real-time database management systems [THUR92]. Our focus was on the security impact on transaction processing. In this paper, we review the security impact on real-time transaction processing as well as discuss architectural issues and data modeling issues to support realtime applications which are also multilevel. In section 2 we discuss the security impact on real-time transaction processing. In section 3 we discuss the impact of timing requirements on the architectures proposed for MLSDBMSs. Data model issues are discussed in section 4. The paper is concluded in section 5.

to proprieties such a s atomicity, consistency, iso-

lation, durability, deadlines, and priority, transactions in a multilevel environment have additional properties such as security levels and levels of execution. That is, each transaction is assigned a security level and it usually executes at a level which dominates its security level. For some applications, a transaction may have to change its level during execution. Many issues need to be resolved. For example, should a higher level transaction have higher priority over a lower level transaction or is the transaction priority independent of the security level? Transaction Scheduling: In a non-realtime MLSDBMS, scheduling algorithms are being designed in such a way that whenever there is contention for a resource between transactions at different security levels, then the one at the lower level has the priority. However, in a realtime environment, transactions have deadlines and priorities assigned to them. These priorities may interfere with the security levels. The question is, what is best way to schedule transactions which not only ensures that the deadlines are met, but also guarantees that higher level transactions do not interfere with lower level ones? Is it at all possible to design such scheduling algorithms or should some compromise be made between security and timeliness? Concurrency Control: This is closely related to transaction scheduling. In a non-realtime MLSDBMS, algorithms such as locking, timestamping, and validation are being adapted to function in such a way that higher level transactions do not interfere with lower level ones. The question is, what is the impact of deadlines on these algorithms? We illustrate the essential points with an example. One of the solutions that is being proposed for concurrency control in an MLSDBMS is for transactions at different levels to work with multiple copies of a data item. Suppose 0 is an Unclassified data item. Two copies of 0 are maintained at the Unclassified level, 01 for Unclassified transactions and 0 2 for higher level (i.e., Confidential, Secret, and Topsecret) transactions. Suppose a Secret transaction requests a read operation on 0 2 and an Unclassified transaction is already writing into 01. Then the Secret

2. TRANSACTION PROCESSING Timing constraints have been found to have conflicts with consistency requirements. As a result, various transaction processing algorithms have been adapted to support real-time applications [HUAN9 1, SHA91, SON91, SON921. Similarly, since security constraints have also been found to have conflicts with consistency requirements, various transaction processing algorithms have been adapted for a multilevel environment [THUR90]. When transactions have to satisfy timing, consistency, and security requirements, then there are many conflicts that have to be resolved. The impact of these requirements on transaction characterization, transaction scheduling, concurrency control, and buffer management, as discussed in [THUR92], are given below. 132

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 19,2010 at 19:28:19 UTC from IEEE Xplore. Restrictions apply.

is controlled by the operating system. When a user at level L queries for the data, the MLSDBMS must combine the data in the singlelevel files which are at or below the user’s level and give the response to the user. If a query, which could be issued as part of a transaction, has a timing deadline, then the recombination algorithm has to be adapted accordingly. It has been noted that the recombination algorithms have an impact on performance. Therefore, the suitability of such an architecture for real-time applications needs to be investigated. In the trusted subject-based architecture, the database data is stored in operating system files. Access to these files is controlled by the operating system. However, the DBMS controls access to its own objects. For example, Unclassified, Confidential, and Secret tuples could be stored in a Secret file. The operating system controls access to the Secret me. A trusted module of the DBMS examines the tuples in the file and releases the tuples depending on the user’s level. In this architecture it is not necessary to recombine single-level tuples into a multilevel relation. As a result it is expected to give better performance. Therefore, it may be more appropriate for realtime applications. However, since the DBMS is trusted, it may be difficult to evaluate such a system. One of the approaches to meeting the timing constraints in both architectures is to assign priority to the data. If the query is time critical, then only the high priority data could be considered in the response.

transaction must wait until the Unclassified transaction completes the write operation and subsequently creates a new version of the modified object for the high level transactions to read. In a real-time environment, the Secret transaction could be a critical one and waiting for the Unclassified transaction to finish could result in a catastrophic situation. If on the other hand the Unclassified transaction’s write request is aborted, then the higher level transaction has interfered and a security violation occurs. If the Secret transaction is allowed to read 0 2 immediately while the Unclassified transaction is writing into 01, then there is a consistency problem as the Secret transaction is reading an older version. Buffer Management: Different buffer management algorithms are being proposed for MLSDBMSs. That is, buffers must be allocated in such a way that higher level transactions do not signal information to lower level ones by resource exhaustion. Usually lower level transactions are allocated buffers in such a way that the presence of higher level transactions are not of any concem. However, in a real-time environment, if a higher level transaction is more critical, then it must be given higher priority. As a result, a lower level transaction may have to wait for buffers. This could result in a security violation. Recovery: Research on recovery techniques for MLSDBMSs is only just beginning. Work needs to be directed towards incorporating timing constraints and deadlines of transactions into such recovery algorithms. In a non-real-time environment, transactions are recovered in such a way that higher level transactions do not interfere with lower level ones. In a real-time environment, the higher level transaction may have higher priority and may have to be recovered first. This could result in a security violation.

4. DATA MODEL ISSUES Most of the MLSDBMSs that are being developed are based on the relational data model. Recently, some work is being camed out on designing MLSDBMSs which are based on an object-oriented data model (see for example [THURgl]). From a preliminary analysis, it appears that the issues for supporting real-time applications are similar for both types of MLSDBMSs. Recently, object-oriented database systems are becoming popular for real-time applications [OOPS92]. It is claimed that the objectoriented data model has several advantages over the relational model in terms of better modeling

3. ARCHITECTURAL ISSUES Various architectures have been proposed for an MLSDBMS. These include operating system providing mandatory security and trusted subject-based architecture. In the first architecture, all of the mandatory access control is provided by the operating system. Therefore, the multilevel database data must be stored in singlelevel operating system files. Access to these files 133

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 19,2010 at 19:28:19 UTC from IEEE Xplore. Restrictions apply.

Symposium on Security and Privacy, Oakland, CA, 1987. [HUAN91] Huang, J., "Real-time Transaction Processing: Design, Implementation, and Performance Evaluation," PhD. Thesis, University of Massachusetts, Amherst, 1991. Kim, Y. and S . H. Son, "An [KIM931 Approach Towards Predictable Real-Time Transaction Processing," 5th Euromicro Workshop on RealTime Systems, Oulu, Finland, June 1993. [OOPS92] OOPSLA 92 Conference Workshop on Object-Oriented Approach and Real-time Applications, Vancouver, B.C., October 1992. [SIGM88] Special Issues on Real-time Database Systems, ACM SIGMOD Record, March 1988. Sha, L., R. Rajkumar, S. H. Son, and [SHA91] C. Chang, "A Real-Time Locking Protocol," IEEE Transactions on Computers, vol. 40,no. 7, July 1991, pp 793-800. Son, S . H., "Real-Time Database [SON901 Systems: A New Challenge," Data Engineering, vol. 13, no. 4, Special Issue on Directions for Future Database Research and Development, December 1990, pp 51-57. Son, Y. Lin, and R. Cook, "Con[SON911 currency Control in Real-Time Database Systems," Foundations of Real-Time Computing: Scheduling and Resource Management, A. Van Tilborg and G. M. Koob (eds.), Kluwer Academic Publishers, 1991. pp 185-202. [SON921 Son, S . H. and S . Koloumbis, "Replication Control for Distributed Real-Time Database Systems," 12th International Conference on Distributed Computing Systems, Yokohama, Japan, June 1992, pp 144-151. [SON92b] Son, S . H., J. Lee, and Y. Lin, "Hybrid Protocols using Dynamic

capability for complex real-world data and the encapsulation mechanisms that allow easy integration of constraints [WOLF93]. If such applications require multilevel security, then an object-oriented DBMS which supports such applications needs to be made multilevel secure. Regardless of whether the data model is relational or object-oriented, the question is, should one consider incorporating multilevel security into an RTDBMS or adapt an MLSDBMS to support real-time applications?

5. CONCLUSIONS In summary, timing constraints, consistency constraints, and security conflict with one another. It is difficult to reconcile these conflicting requirements. Even in non-real-time systems, it is difficult to achieve a balance between security and consistency. For example, in one of the solutions to concurrency control that we described earlier, multiple copies of a data item need to be maintained. This means that storage management becomes an issue. In non-multilevel real-time systems, one needs to develop techniques that ensure timeliness as well and consistency. In a multilevel real-time environment, techniques have to be developed which ensure security, timeliness, and consistency. Due to the complexities involved, we envisage that trade-offs need to be made between security, consistency, and timeliness, and algorithms have to be developed on a case-by-case basis. That is, various types of Multilevel Secure Real-time DBMSs (MLSRTDBMS) need to be identified and architectures and algorithms need to be developed for each type of system.

REFERENCES Air Force Studies Board, 1983, Committee on Multilevel Data Management Security, Multilevel Data Management Security, National Academy Press. [DENN87] Denning, D. E., et al., April 1987, "A Multilevel Relational Data Model," Proceedings of the IEEE [AFSB83]

134

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 19,2010 at 19:28:19 UTC from IEEE Xplore. Restrictions apply.

[SON931

[SON93b]

[STACY01

[THUR90]

[THURBl]

[THUR92]

[WOLF931

Operating Systems and Software, New York, New York, May 1993, pp 57-63.

Adjustment of Serialization Order for Real-Time Concurrency Control," Journal of Real-Time Systems, vol. 4, Sept. 1992, pp 269-276. Son, S . H; and S . Park, "Scheduling and Concurrency Control in RealTime Database Systems," The Third International Symposium on Database Systems for Advanced Applications (DASFAA '93),Taejon, Korea, April 1993,pp 219-226. Son, S . H., J. Lee, and H. Kang, "Approaches to Design of RealTime Database Systems," Database Systems for Next-Generation Applications - Principles and Practice, W. Kim, Y.Kambayashi, and I. Paik (eds.), World Scientific Publishing, 1993, pp 120-131. Stachour, P.,and B. Thuraisingham, June 1990, "Design of LDV - A Multilevel Secure Database Management System," IEEE Transaction on Knowledge and Data Engineering, Vol. 2, #2, 1990. Thuraisingham, B., July 1990, "Multilevel Security Issues for Distributed Database Management Systems." Technical Report, MTP 291, The MITRE Corporation, 1990 (also to appear in Computers and Security Joumal). Thuraisingham, B., "Multilevel Secure Object-Oriented Data Model: Issues on Noncomposite Objects, Composite Objects, and Versioning," Journal of Object-oriented Programming, vol. 4 , 1991 (also published in The MITRE Joumal 1992). Thuraisingham, B., "A Note on the Security Impact on Real-time Database Systems," 5th Rome Laboratory Workshop in Database Security, Fredonia, N Y , October 1992. Wolfe, V., L. Cingiser, J. Peckham, and J. Prichard, "A Model for RealTime Object-Oriented Databases," 10th IEEE Workshop on Real-Time 135

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 19,2010 at 19:28:19 UTC from IEEE Xplore. Restrictions apply.

Suggest Documents