Maintaining Security and Timeliness in Real-Time Database Systems Quazi N. Ahmed Lucent Technologies 2139 Highway 35 Holmdel, NJ 07733
Susan V. Vrbsky Department of Computer Science The University of Alabama Tuscaloosa, AL 35487-0290
[email protected]
[email protected] (205) 348-6363
Abstract Real-time database systems can have security constraints in addition to timing constraints. Such real-time systems are typically contained in environments that exhibit hierarchical propagation of information, where mandatory access control for security is required. Conventional multi-level secure database models that implement mandatory access control are inadequate for time-critical applications and conventional real-time database models do not address security constraints. The objective of this work is to incorporate security constraints in real-time database systems in such a way that not only is security achieved, but achieving security does not degrade real-time performance significantly in terms of deadlines missed. We present two concurrency control algorithms for secure real-time databases: the Secure 2PLHP algorithm is based on a two-phase locking protocol and the Secure OPT algorithm uses the properties of an optimistic concurrency protocol. We implement the two algorithms and study their performance using a real-time database system simulation model. Our study covers both soft and firm real-time databases. Results show that both the algorithms perform fairly well in terms of security and timeliness compared to non-secure algorithms. We show that achieving increased security does not necessarily mean an increased sacrifice in real-time performance.
Submitted to the Journal of Systems and Software
-1-
Introduction Real-time database systems [7, 8, 18, 24] are identified as having timing constraints and can be found in applications, such as defense systems, industrial automation, programmed stock trading and air traffic control. The timing constraints of real-time databases are typically specified in the form of deadlines that require a transaction to be completed by a specified time. Failure to meet a deadline can cause the results to lose their value, and in some cases a result produced too late may be useless or even harmful. In addition to these timing constraints, some real-time database systems have security constraints. Security constraints are specified when multiple users share the same database and some of the users have restricted access to information from the database. Failure to enforce security requirements of the data can have negative consequences. Unfortunately, conventional secure database models are inadequate for time-critical applications, and conventional real-time database models do not address security constraints. The objective of the work described in this paper is to incorporate security constraints in real-time database systems in such a way that not only is security achieved, but achieving security does not degrade real-time performance significantly in terms of deadlines missed. A secure real-time system has to simultaneously satisfy the two goals of ensuring that the timing constraints are satisfied and the security constraints are satisfied. These two goals can conflict with each other and to achieve one goal is to sacrifice the other. Whether to maintain timeliness or security is dependent upon the system. If the system requires that security be maintained regardless of the timing constraints, then every data conflict resolved by concurrency control must be in favor of security. On the other hand, if the system requires the timing constraints be maintained, then security must be sacrificed in favor of deadlines. If the system allows a compromise between security constraints and timing constraints, then the goal is to maintain as much security as possible without violating timeliness significantly. The strategies in this work can be used for systems where security can be compromised for real-time constraints and vice versa, and also for systems where security is a correctness criteria and must be maintained. In this paper we identify factors involved in security control of real-time databases that are needed to develop suitable concurrency control algorithms. We propose a new measure of the severity of the security compromised, called the dynamic covert channel control factor, and we present two concurrency control algorithms based on this factor. The first algorithm we present utilizes two-phase locking and the second algorithm is an optimistic security control algorithm.
-2-
Both algorithms recognize the timing constraints of real-time transactions as well as security. Using a real-time database simulation, we study the effect of the algorithms on maintaining security as well as their effectiveness in maintaining real-time performance. This paper is organized as follows. In the remainder of this section we provide a background and describe related work. In Section 2 we describe the security factors upon which the secure algorithms are based and in Section 3 we present the secure two-phase locking algorithm and the secure optimistic algorithm. The simulation model is described in Section 4 and in Section 5 we present simulation results. Lastly, in Section 6 we present conclusions. 1.1 Background Deadlines can be missed in real-time database systems because of several factors.
A
transient overload, due to such factors as exception handling, may cause some transactions to miss their deadlines. Concurrency control [23, 25] is needed to ensure data integrity, but it can also cause deadlines to be missed. There are three different types of deadlines for real-time transactions: soft, hard or firm [24]. A transaction with a soft deadline may miss its deadline, yet the result produced still has some value (although the value monotonically decreases with time after the deadline). Soft transactions are allowed to complete even if a deadline is missed. On the other hand, if a hard deadline of a transaction is missed, the consequence can be catastrophic. The value assigned to a result when a deadline is missed is negative. For a firm deadline, the consequences of missing a deadline are less severe than a hard deadline, but a result produced after a deadline is useless, and is assigned a value of 0. For both firm or hard deadlines, if a deadline is not met, the transaction is discarded as soon as the deadline is missed. In this paper, we study security for both soft and firm real-time database systems. Real-time systems are commonly contained in environments that exhibit hierarchical propagation of information, such as military institutions and government agencies, where mandatory access control for security is required. Mandatory access control is typically implemented by multilevel secure (MLS) databases [6, 11, 19, 20]. All MLS models are based on the classification of the data objects and users. Data objects have security levels and users have clearance levels. A user can read a certain object only if the user’s clearance level dominates the object’s security level. According to the two Bell-LaPadula properties [6] for MLS databases, a user cannot read an object of a higher or incomparable security level than the user and all writes must take place at the user’s security level or higher.
-3-
The two Bell-LaPadula properties prevent the direct flow of information from objects and/or subjects at a higher security clearance level to subjects at a lower level, and are the basis for all MLS models. However, there can be contention for data objects as a result of the concurrent execution of transactions, and consequently, it is possible to have an indirect flow of information from objects at higher levels to subjects at lower levels due to a covert channel [17]. For example, if the results from a lower security level transaction are delayed when there is a higherlevel security transaction, then the lower security level user can determine there are transactions at higher levels, and may even be able to receive information from the length of the delay. Enforcing database security can compromise the real-time integrity by causing deadlines to be missed. For example, suppose there is a transaction with an earlier deadline at a high security level and a transaction with a later deadline at a low security level, and there is a data conflict between them. If the lower security level transaction gets the data and blocks the higher security transaction, then although security is maintained, the real-time constraints may be violated. The high security transaction has an earlier deadline, and due to its blocking may miss its deadline. If the reverse is allowed to happen to maintain the timing constraints, then security is violated as a covert channel is introduced. 1.2 Related Work There has been some work on the security of real-time databases. In [13], security of firm realtime databases is addressed. In this study, security is viewed as a correctness criterion, and the number of missed deadlines as a performance issue. They do not trade off between missed deadlines and security, but instead propose to minimize the number of missed deadlines without compromising security through the choice of concurrency control strategy. They examine the performance of such strategies as a two-phase locking priority scheme, a prioritized optimistic concurrency control algorithm and a new approach, called the dual approach. The dual approach utilizes different concurrency control strategies depending on whether transactions are at the same security level or at different security levels. In contrast, our algorithms are capable of handling transactions both at the same and at different security levels. In [9, 10] a concurrency control strategy is presented which trades off security for improved timeliness if the system does not provide the desired deadline miss percentage. The authors define the ratio: “capacity”/“mutual_information”, as a measure of the degree to which security is being satisfied by a system. The measure is adjusted dynamically to achieve the desired deadline miss percentage. Our strategies also use a system measure, a system security tolerance
-4-
level, but this level is a predetermined constant value. Whether or not to sacrifice meeting a particular deadline is determined by whether or not the system security tolerance level is achieved by the transaction. In [21, 22] a secure two-phase locking algorithm is used to allow partial violations of security for improved timeliness. The authors use “virtual locks” and “dependent locks” in order not to block a lower-access-class transaction because of a lock held by a higher-access-class transaction. Decisions are made concerning the trade-off between security and meeting deadlines by comparing two measures to resolve conflicts: the security factor and the deadline miss factor. This comparison is used to determine if a lower level transaction should be aborted or proceed when it conflicts with a higher-level transaction. If the security properties are more important, then any conflict is resolved in favor of the lower level transaction, otherwise if meeting deadlines is more important, then the higher priority transaction is given precedence. Our work also considers the need to trade-off between security and timeliness; however, our algorithms are much simpler, and they do not require additional locks, such as “virtual locks” or “dependent locks.” We provide a dynamic covert channel factor, which gives a measure of the consequence of security violation and is simpler than “capacity” both in concept and in implementation. 2. Secure Control Factors In secure real-time database systems, security can be thought of as a correctness criteria where security must be enforced or it can be thought of as a compromising criteria with timeliness where security can be sacrificed to achieve fewer deadline misses. If the system allows security to be sacrificed for timeliness, then some measure of the severity of the sacrifice is needed. In this section we present the dynamic channel control factor as such a measure. We begin by introducing the covert channel property. 2.1 Covert Channel Property If the system must make a decision whether or not to trade off security for timeliness, simply indicating whether or not a security violation could occur does not provide a measure of the severity of the sacrifice. When security violations are allowed to occur, some additional measure of the severity of the violation is needed. We have proposed in [4, 5] to consider the security levels of a transaction when a security conflict is to be resolved. The difference in security levels of transactions is used as a measure of the severity of a security violation. Ordered security levels that are adjacent to each other are by definition considered to be closer to each other than those several levels apart. Thus, the larger the difference in security levels, the greater the
-5-
severity of the covert channel. In other words, a covert channel between adjacent security levels is considered to be less severe than those at several levels apart. For example, assume there are three security levels with the ordering: Unclassified < Classified < Secret. There is a less severe covert channel between levels Unclassified and Classified, than between levels Unclassified and Secure. Our concurrency control algorithms for a secure real-time database system use security levels of transactions as well as their deadlines to resolve data conflicts. None of the algorithms discussed in Section 1.2 recognize the difference in security levels as a measure to resolve a security conflict. We believe that difference in security level is an important issue for determining whether a covert channel has to be closed by possibly sacrificing timeliness. In secure real-time database systems, where timeliness is one of the goals to be achieved, one cannot afford to sacrifice timeliness for one covert channel that is considered to be less severe than another. To be able to determine the severity or consequences of security violations, in [4, 5] we introduced the “covert channel property” for secure real time database systems. Covert Channel Property: The greater the difference in security levels between two transactions at data conflict, the greater the severity or the consequence if a covert channel is introduced. The covert channel property indicates that consequence is proportional to the difference in security or access levels. In other words, the greater the difference in access levels, the more important it is to maintain security and close the covert channel. If two conflicting transactions are at two extreme security levels, the consequence of opening a covert channel is the maximum. If the two conflicting transactions are at two adjacent security levels, the consequence is the minimum. Of course, if the two transactions are at the same security level, there is no covert channel, and hence, no consequence. 2.2 Dynamic Covert Channel It is possible for more than two transactions to be involved in a covert channel. For example, assume that there are three transactions at three different security levels: T1 at the Secret level, T2 at the Classified and T3 at the Unclassified level, where again the ordering of the security levels is Unclassified < Classified < Secret. Assume the system allows covert channels only between consecutive classification levels (the difference in classification levels is 1). If there is a covert channel between T1 and T3, then it is not allowed because the difference in
-6-
classification levels is greater than 1. If there exists a covert channel between T1 and T2, then the covert channel between T1 and T2 is allowed because the difference in classification levels is 1. If there is another covert channel between T2 and T3, then this covert channel is also allowed because again the difference in classification levels is 1. As a result, this inadvertently opens a covert channel between T1 and T3. In order to prevent this covert channel, the channel between T2 and T3 should not be allowed, even though the transactions are in consecutive classification levels. To this end, we need to keep track of the history of covert channels in which a transaction is involved. In order to identify a transaction’s previous involvement in a covert channel, each transaction T needs to have an attribute that will store its history, denoted as covert_channel_history(T). Initially, every transaction will have a zero history. As soon as a transaction is involved in a covert channel, the difference in classification levels will be added to the previous history. This can be stated as follows: For all transactions T, covert_channel_history(T) = 0
//initialization
For all transactions TL, if TL is involved in a covert channel with another transaction TH then covert_channel_history(TL) = covert_channel_history(TL) + covert_channel_history(TH) + access_level(TH) - access_level(TL) We note that, when there is a covert channel between two transactions TL and TH, such that TL is at a lower classification level and TH is at a higher classification level, only the covert-channel history of TL changes. The covert channel history of TH does not change, because TL is the one receiving the information indirectly. A discussion of the channel history when there is a partial ordering of classification levels appears in [5]. We now use the covert channel history to define the Dynamic Covert Channel Factor, which we present in this paper for the first time. If there is a covert channel between T1 and T2 and level (T1) > level (T2), then the Dynamic Covert Channel Factor (DCCF) is defined as follows:
DCCF =
Access level (T 1) − Access level(T2) + Covert_channel_history(T1) # of access levels - 1
2.3 System Security Tolerance Depending upon the system requirements, security violation may or may not be tolerated. We define the System Security Tolerance (SST) as the maximum security violation a system permits. Since a security violation is measured in terms of the DCCF, so is the tolerance. (We will also
-7-
refer to the SST as tolerance.) An SST of 0 means the system does not allow any covert channel and an SST of 1 means the system allows all possible covert channels. In other words, the system security tolerance is the value that indicates the upper limit of security violation in a system. For example, assume a system only permits a covert channel to occur if it is between two consecutive access levels. In this case, any covert channel having a difference in access levels greater than 1 is not allowed and is defined as:
1 SST = Difference in access levels = Maximum difference possible # of access levels - 1 The smaller the value of SST, the more important is the security and vice versa. In the next section we will see how we can use the system security tolerance to represent the importance of security. In a security conflict, if the DCCF is greater than the SST, then a conflict is resolved in favor of security, otherwise the conflict is resolved in favor of priority based on the real-time constraints. 3. Secure concurrency control algorithms The security factors presented in Section 2 are utilized as the basis for the two secure algorithms studied in this paper. Our first algorithm is a two-phase locking algorithm and is called the Secure 2PLHP algorithm. The second algorithm is an optimistic concurrency control algorithm, called Secure OPT. 3.1 Secure 2PLHP The first algorithm is based on the two-phase locking high priority (2PLHP) algorithm for realtime transactions. The 2PLHP algorithm [1] is a modification of the strict two-phase locking algorithm (2PL) [12] and it incorporates the real-time priority of transactions but not security. The priority of a transaction is based on its real-time constraints; the earlier its deadline, the higher its priority. When a transaction requests a lock on a data item that is held by one or more higher priority transactions, the requesting transaction waits for the data item to be released. If the data item is locked by only lower priority transactions, the lower priority transactions are restarted and the lock is granted to the requesting transaction. If priority is unique, 2PLHP is deadlock free. Given the transactions T1 and T2, where T1 is the lock-requesting and T2 is the lock-holding transaction: If Deadline(T1)Deadline(T2) and Access level(T1)>Access level(T2) Block T1
// priority and security maintained
In this case the requesting transaction is at a lower priority and a higher security level. We can abort or block the requester. There will not be any covert channel or priority violation. 2. If Deadline(T1)>Deadline(T2) and Access level(T1)SST then Abort T2 // security maintained Else Block T1 // priority maintained In this case the requester is at a lower security level and a covert channel will be introduced if it is blocked or aborted. However, if the requester is allowed to proceed and the lock-holder aborted, priority will be violated. In this case, we compute the DCCF if T2 is aborted. If the DCCF is greater than the SST, then the lock-holder (T2) is aborted, otherwise the lock-requester (T1) is blocked. 3. If Deadline(T1)Access level(T2) if DCCF>SST then Abort T1 // security is maintained Else Abort T2 //priority is maintained In this case, the requester is at a higher priority and at a higher access-level, and a covert channel will be opened if the lock holder is aborted. Here again, we need to compute the DCCF if T2 is aborted. If the DCCF is greater than the SST, then T2 is allowed to proceed and T1 aborted, otherwise T1 is granted the lock and T2 is aborted. 4. If Deadline(T1)
