Security Issues in Distributed Transaction Processing

3392

Category: IT Security & Ethics

Security Issues in Distributed Transaction Processing Systems R. A. Haraty Lebanese American University, Lebanon

IntroductIon Transaction-processing systems (TPS) are becoming increasingly more available as commercial products. However, the approaches to the issues associated with using TPS in multilevel secure environments are still in the research stage. In this article, we address the issues of multilevel security in distributed transaction-processing systems. A distributed transaction-processing system (DTPS) is a collection of a finite number of centralized transaction-processing systems connected by a computer network. Each of these transaction-processing systems is controlled by a software layer and can be accessed both remotely and locally. Properties of a DTPS, such as data replication, may have a substantial effect on the security of the system. The security policies and integrity constraints adopted at each site may result in global security having inconsistent states. We address the issues of achieving a multilevel secure DTPS, and discuss the security constraints and data replication. In this work, we address the issues of achieving a multilevel secure DTPSs system and discuss the security constraints and the replication of data items. The next section provides some background. Then, next, an overview of a distributed transaction-processing system is presented. In the fourth section, security-related issues are discussed. In the fifth section, a multilevel secure distributed transactionprocessing system is presented. Then, in the next section, future trends are presented. The final section concludes the article.

Background Several commercial and military applications require a multilevel secure transaction-processing system (MLS/TPS). In an MLS/TPS, users are assigned classification levels that we denote by “clearances,” and data items are assigned sensitivity levels. There are three interesting architectures that have been used to build MLS/TPSs from untrusted ones. These architectures are known as the integrity lock architecture, the kernelized architecture, and the data distribution architecture (Air Force Studies Board, 1983). While most of the techniques for TPS security are developed for traditional centralized TPSs, more TPS researchers are making sub-

stantial contributions to the development of a distributed TPS (Getta, 2003; Haraty, 1999; Haraty & Rahal, 2002; O’Connor & Gray, 1988). A DTPS is a collection of a finite number of TPSs connected by a computer network (Ozsu & Valduriez, 1999). Each of these TPSs is controlled by a transaction management software layer and can be accessed both remotely and locally. A DTPS integrates information from the local TPS and presents remote users with transparent methods to use the total information in the system. An effective TPS system serves to maintain the ACIDity properties (i.e., atomicity, consistency, isolation, and durability) of transactions and must be superimposed on the preexisting local TPSs (Gray & Reuter, 1993). One proposed architecture for MLS/TPS is the replicated architecture. This approach is being explored in several ongoing research efforts, including the Naval Research Laboratory Secure Information through replicated architecture (SINTRA) project (Thuraisingham, 1987). Data replication in DTPS has several implications for the security of the system. Replication allows data items in different local TPSs to be identified as logically belonging to the same entity. The security policies adopted by each site may result in global security having inconsistent states, because of the difference of local representation and management.

oVErVIEW oF dIStrIButEd tranSactIon-ProcESSIng SyStEMS A DTPS consists of a set of preexisting local TPSs {LTPSi | 1 d•i d” m}, distributed among several interconnected sites. Each LTPSi is a software layer on a set of data items Di. Figure 1 depicts the architecture of a DTPS.

SEcurIty ISSuES Processes that execute on behalf of users are referred to as subjects. Objects, on the other hand, correspond to a data item. Objects can be files, records, or even fields. In this section, we present the notion of object classification with emphasis on the problem of conflicting security constraints due to replication.

Copyright © 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

Security Issues in Distributed Transaction Processing Systems

Figure 1. Distributed transaction-­processing system

•

Access privileges of users to replicated data: Instances where a user may have different access rights on replicated data at different sites.

Several solutions have been proposed to solve these inconsistencies and define a global security policy that respects the local ones (Pfleeger, 1989; Thuraisingham, 1987). There are several ways to combine local policies. The optimal combination should give a policy that defines all component policies and is still secure.

A security classification is a function that associates each subject and each object with a given level of security. Many classifications, such as the security lattice, exist (Denning, 1976). However, a well-known classification is four-value function (DOD paradigm) that classifies objects into unclassified (U), confidential (C), secret (S), and adopt top secret (TS). A simple policy that can be established using a classification function SL is as follows: Subject X can access (read) Object Y iff SL (Y) ≤ SL(X) A security constraint consists of a data specification and a security value. The data specification defines any subset of the TPS. The security values can be given by a classification function. Specific values are unclassified, confidential, secret, and top-secret. Thuraisingham (1987) defined two types of security constraints—internal constraints and external constraints: 1.

2.

Internal constraints classify the entire TPS as well as relations, attributes, and tuples within a relation. These constraints can be applied to data, as they are actually stored in the TPS. External constraints classify relationships between data and the results obtained by applying operations on the stored data, such as sum, average, and count. Among these constraints are the functional constraints and the dynamic constraints.

These security constraints are subject to inconsistency and conflicting local security constraints. A good global security approach should reject inconsistent security constraints and inconsistent clearance of users. Examples of the inconsistencies encountered include: • • •

Conflicting security constraints: Such constraints classify the same facts into different categories. Overlapped security constraints: These constraints cover overlapped data domains. Inconsistent security level of replicated data: Cases where different copies of replicated data may belong to different security cases.

MuLtILEVEL SEcurE dIStrIButEd tranSactIon-ProcESSIng SyStEMS There are two strategies for building MLS/DTPS from DTPS. These strategies include data replication and perlevel-based distribution. The scope of this article does not include the issues associated with network security; but, it is particularly important to have the various local TPSs. Instead, we will assume that interconnection between the various local TPSs is secure and focus attention on security that has to be provided due to replication and other properties specific to the TPS. The data distribution approach physically replicates low-level data at all higher-level TPSs. The advantage of the replicated architecture is that is fairly secure (McDermott & Sandhu, 1991). No performance overhead is associated with multilevel queries, because they are locally executed. On the other hand, because data is replicated, there is overhead associated with broadcasting updates of lower-level data to higher-level TPSs in a correct and secure manner. This broadcasting mechanism is known as “data synchronization” (Air Force Studies Board, 1983). In the per-level-based approach, data are physically stored in separate local TPSs according to sensitivity level. Early examples of this approach were presented by Hinke and Schaefer (1975). The advantage of this approach is that updating transactions does not produce inconsistencies. Performance overhead associated with multilevel queries is a major disadvantage.

global commitment in Secure Environment An important aspect of a correct TPS is atomic commitment (Bernstein et al., 1987). Unfortunately, the local TPS in a MLS/DTPS system cannot support atomic commitment, so the two-phase commit (2PC) protocol (Bernstein et al., 1987) cannot be implemented. 2PC is known to introduce covert channels. In order to establish a covert channel, there must be two cooperating agents/subjects in the system and an encod-

3393

S

Security Issues in Distributed Transaction Processing Systems

ing scheme. There are two main types of covert channels: covert storage channels and covert timing channels. Covert storage channels disclose information from high to low subjects by manipulating a physical object that can or cannot be seen by the low subjects. For example, suppose there are two subjects of different security levels. Suppose also that these processes share a common resource—the available disk space. The secret subject creates a secret file that takes all of the available disk space to store the file. When the low subject attempts to create a file and store it onto the common disk, its request is denied. Through this denial, the high subject can signal information to the low subject. These signals are in terms of 0 and 1 bits that the low subject has to decode and turn into useful messages. Covert timing channels can covertly send information by modulating observable delays of a common resource. This delay must be measured by low subjects cleanly; otherwise, the channel becomes noisy. For example, suppose we have two subjects again operating the low and high levels. The high subject can modulate the disk access time of the low subject by issuing numerous disk requests (thus transmitting a bit of 1) or zero disk requests (thus transmitting a zero). A system that is free from any type of covert channel is called covert channel secure. Several distributed commitment protocols have been defined. A scheduler in MLS/DTPS that produces committable execution guarantees that a distributed transaction (a unit of work with execution sites: TPS1, TPS2, …, TPSn) becomes committed after it has been locally committed. The commitment of a distributed transaction means all of its subtransactions are committed. In this article, we follow the definition proposed by Bernstein et al. (1987): If one subtransaction commits, then all other subtransactions will eventually commit. We assume, in this article, that each subtransaction of a distributed transaction is designed to be executed in only one container. One can then say that a subtransaction has a security level.

FuturE trEndS Future work will involve taking a closer look at MLS/DTPS and defining new and better ways of handling transaction management as well as query processing. Future work will also involve extending security issues to temporal and multimedia databases.

concLuSIon The security issues presented in this article highlight the intricacies required to architect a MLS/DTPS. We hope to address these issues further and to identify potential prototypes and engineering solutions that meet the requirements of MLS for DTPS.

rEFErEncES Air Force Studies Board, Committee on Multilevel Data Management. (1983). Multilevel data management. National Research Council. Bernstein, P. A., Hadzilacos, V., & Goodman, N. (1987). Concurrency control and recovery in database systems. Reading, MA: Addison-Wesley. Denning, D. (1976). Secure information flow in computer systems. Ph.D. dissertation. Purdue University. Getta, J. R. (2003). Hybrid concurrency control in multilevel secure database systems. In Proceedings of the IASTED International Conference—Applied Informatics. Innsbruck, Austria. Gray, J., & Reuter, A. (1993). Transaction processing: Concepts and techniques. San Francisco, CA: Morgan Kaufmann. Haraty, R. A. (1999). A security policy manager for multilevel secure object oriented database management systems. In Proceedings of the International Conference on Applied Modelling and Simulation, Cairns, Queensland, Australia. Haraty, R. A., & Rahal, I. (2002). A bit vectors algorithm for accelerating queries in multilevel secure databases. In Proceedings of the International Conference on Computer Science, Software Engineering, Information Technology, e-­Business, and Applications (CSITeA’02), Foz do Iguazu, Brazil. Hinke, T., & Schaefer, M. (1975). Secure database management system, RADC-TR-75-266. McDermott, J. P., & Sandhu, R. S. (1991). A single-level scheduler for the replicated architecture for multi-secure database. In Proceedings of the Seventh Annual Computer Security Applications Conferences. O’Connor, J. P., & Gray, J. W. (1988). A distributed architecture for multilevel database security. In Proceedings of the Security Conference. Ozsu, M. T., & Valduriez, P. (1999). Principles of distributed database systems. Upper Saddle River, NJ: Prentice Hall.

3394

Security Issues in Distributed Transaction Processing Systems

Pfleeger, C. P. (1989). Security in computing. Upper Saddle River, NJ: Prentice Hall. Thuraisingham, M. B. (1987). Security of database systems. Computer and Security, 6(6).

kEy tErMS Covert Channel: This is a channel that is not meant to route information, but nevertheless does. Multilevel Secure Transaction-Processing System: This is a system whereby database users are assigned classification levels, and data items are assigned sensitivity levels.

Security Lattice: This is a partial (or total) order of security classes, where there is a least upper bound that dominates all the other security classes and a greatest lower bound that is dominated by all security classes. Subject: This corresponds to a user or, more correctly, to a process that is running on behalf of a user. Two-Phase Commit (2PC): This is an atomic commitment protocol that behaves as follows: The coordinator asks the participants to vote on commitment; if any votes No, the coordinator informs all participants to Abort; if all participants voted Yes, then the coordinator informs all participants to Commit.

This work was previously published in Encyclopedia of Information Science and Technology, edited by M. Khosrow-­Pour, pp. 2455-­2458, copyright 2005 by Information Science Reference, formerly known as Idea Group Reference (an imprint of IGI Global).

3395

S