Multilevel Policy based Security in Distributed

Multilevel Policy Based Security in Distributed Database Neera Batra 1, Manpreet Singh2, 1

Department of Computer Engineering, M. M. Engineering College, M. M. University, Mullana [email protected] 2 Department of Computer Engineering, M. M. Engineering College, M. M. University, Mullana [email protected]

Abstract-Addressing security demands under fixed budgets and tight time constraints are becoming extremely challenging, time consuming and resource intensive. Moreover, securing the distributed database in compliance with several security guidelines makes the system more complex. Mission critical systems, military, government and financial institutions have been under tremendous pressure to secure their databases. Such requirements mandate that each system passes a strict security scan before it is deemed suitable to go into operational mode .This paper presents a framework that embeds security capabilities into distributed database by replicating different predefined security policies at different sites using multilevel secure database management system. Keywords: Policy based security, Replication, Multilevel secure database, Covert channel, Distributed database

1 Introduction A distributed database is a collection of databases which are distributed and stored on multiple computers within a network [9]. Distributed database system functions include distributed query management, distributed transaction processing, distributed metadata management and enforcing security and integrity across the multiple nodes. Database security is the system, processes, and procedures that protect a database from unintended activity. Unintended activity can be categorized as authenticated misuse, malicious attacks or inadvertent mistakes made by authorized individuals or processes. But the most important issues in security are authentication, identification [14] and enforcing appropriate access controls [8]. Databases provide many layers and types of information security, typically specified in the data dictionary, including access control, auditing, authentication and encryption. Access control [15] is a system which enables an authority to control access to areas and resources in a given physical facility or computer-based information system. An access control system, within the field of physical security, is generally seen as the second layer in the security. Authentication [4] is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are

true. All organizations, ranging from commercial organizations to social organizations, in a variety of domains such as healthcare and homeland protection, may suffer heavy losses from both financial and human points of view as a consequence of unauthorized data observation [11]. In cryptography, encryption [5] is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key Integrity. Some of the most important security requirements for database management systems are: Multi-Level Access Control, Confidentiality [11], Reliability, Integrity and Recovery. Thus, a complete solution to data security must meet the following three requirements: 1) secrecy or confidentiality refers to the protection of data against unauthorized disclosure, 2) integrity refers to the prevention of unauthorized and improper data modification [1], and 3) availability [10] refers to the prevention and recovery from hardware and software errors and from malicious data access denials making the database system unavailable. A DBMS fulfilling these mandatory requirements becomes capable of providing security at different levels. But in order to provide concurrent access of replicated data to multiple users at different locations, multilevel security mainly on distributed environment becomes a major issue. Multilevel secure database systems have a set of requirements that are beyond those of conventional database systems. A number of conceptual models exist that specify access rules for transactions in secure database systems. One important model is the Bell La Padula model. In this model, a security level is assigned to transactions and data [6]. A security level for transaction represents its clearance level and for data, the security level represents the classification level [9]. Transactions are forbidden from reading data at higher security level, and from writing data to a lower security level. Thus, by delaying low security level transactions in a predetermined manner, high security level information can be indirectly transferred to the lower security level. This is called a covert channel. A covert channel is any component or feature of a system that is misused to encode or represent information for unauthorized transmission, without violating the stated access control policy. Covert channels are paths not normally meant for information flow. In multilevel secure databases, a low security level transaction can be delayed or aborted by a high security level transaction due to shared data access. Security Policy: A computer security policy consists of a clearly defined and precise set of rules, for determining authorization as a basis for making access control decisions. A security policy captures the security requirements of an establishment or describes the steps that have to be taken to achieve the desired level of security. A security policy is typically stated in terms of subjects and objects, Given the desired subject and object, there must be a set of rules that are used by the system to determine whether a given subject can be given access to a specific object. In this paper, we focus mainly on the confidentiality requirement and we discuss access control policies to provide high-assurance confidentiality because however, access control deals with controlling accesses to the data, the discussion in this paper is also relevant to the access control aspect of integrity, that is, enforcing that no unauthorized modifications to data occur.

2 Proposed Model The proposed model consists of MLS [16] database that is distributed [2] in a replicated manner over N sites connected by a network. As shown in Figure 1, at each site when the user request is received, the first job a secure server does is to authenticate the user. Preliminary Access Control

Request 1

Authentication of User

Request 2 Request 3 User Level Request

User Manager

Confidential Level Request

Request 4

LEVEL 1

Stored Procedures

Request Verifier

Policy Decision Manager LEVEL 2

No

Query Optimizer

Audit Trail record Alert System Owner Notify User

Transaction Manager LEVEL 3 Update Database Audit Trail record Alert System Owner Notify User

Figure 1. System Model The authentication is performed based on factors user name, password or IP address. Once user is authenticated successfully, the user’s request, IP address, and digital credentials are forwarded to the preliminary access control system which can be achieved with a firewall system filtering the traffic based on user’s request. For example, a user can check for the balance available in his account in the local databases. He doesn’t have the permission to access the similar information located in the remote databases. The preliminary access control is a valid way to improve the system efficiency because the user’s disallowed requests are terminated at an early stage. If the user’s request is allowed by the preliminary access control, the user’s request is forwarded to the security manager. The different request levels proposed are user level request (SL(Du )) and confidential level request which is further divided in to secret level request

(SL(D s ))

and top secret level request

(SL(Dt )) . If

the user is permitted access to the user level, the query is limited with the user level (SL(Q )〈 SL(Du )) otherwise the query is rolled back to confidential level transaction SL(Q ) goes through a process of verification before it security. At level second, the request can be processed. This step is carried out by database stored procedures that have built-in logic for checking the request against the policies .If the request complies with the set policies that govern its scope of applicability, the request is forwarded to query optimizer. ( ) The query optimizer further divides the request or query SL Q into various levels for distributed access and creates a new optimized query according to the data distribution. The transaction Manager pools the query in the transaction queue and allows the transaction to be executed .The lock signal is sent to the entire distributed database sites. The transaction is allowed to update the data only when it passes all the clearance from all security levels otherwise it rolls back the transaction. When there is no objection from other sites, audit trail, database system tables/views are updated to reflect the change and an audit trail is recorded otherwise the request is rejected and the system owner is alerted, the user notified and an audit trail is recorded. Thus the proposed model felicitates to access data only after passing thru multiple security levels. In this paper, use of policies is applied for access control to different users depending upon privileges given to them. The system owner is allowed to create database configuration-specific policies. These policies control and decide which changes are allowed and which ones are not. The framework gives the system owners the ability to institute a composite password where each part of the password is owned by a different member of the system owners team for added security. The purpose of using policies is to enforce system owner requirements and constraints onto a system. Policies are implemented into a database system for the purpose of making the database perform specific actions in response to attempts to alter its state or its configuration settings. Therefore the creation and enforcement of policies require the establishment of rules that invoke certain actions to be performed under certain conditions. 2.1 Consistency controlled system To implement concurrency, each transaction in this security model, must obtain a read lock before reading a data item and a write lock before writing a data item. A transaction can only read at its own level or low level but can write at its own level only [3]. This is sufficient to prove that security is not violated through data access. The access permissions in the proposed model are shown in Table 1. Let L(Tt ) denotes the top security level transaction, L(Ts ) the security level and L(Tu ) as user level transaction i.e.

L(Tu ) < L(T s ) < L(T t ) . whereas L(Z t ) denotes the data item Z as the top security level

data item, L(Ys ) the security level data item and L( X u ) as user level data item i.e.

L( X u ) < L(Y s) < L(Z t ) .

Table 1: Access Permission Data Item Transaction

L(Tt )

L(Ts )

L(Tu )

L( X u )

L(Ys )

L(Z t )

r [x]

r[y ]

r [z ] , w[z ]

r [x ] r [x ]

r [ y ] , w[ y ]

-

-

-

The execution of a distributed transaction Τ is divided into sub-transactions Τi , where n

∑ Τ . A sub-transaction i

Τi is sent to the node Ν i where the data is available and

i =1

executed under local security. If a sub-transaction fails, then the parent transaction is rolled –back and restarts after some delay to avoid repeated restart. The transaction manager determines at which node, data item requested by a transaction are located. If the data is available in the parent node Ni, it is accessed in the same node Ni, otherwise if there is no local copy and multiple copies exist at more than one node, then one copy is randomly selected and other copies of the same data are locked. In case of data replication, it implements a read-one and write-all policy for read requests. For a write request, it consults all nodes that hold a copy of the desired data item. Each node contains information about data distribution and replication. A transaction can’t request additional locks once it has issued an unlock action. It holds onto all its locks (read or write) until it completes. A top secret security level transaction must release its read lock on a low data item when a low security level transaction requests a write lock on the same data item and the aborted top secret security level transaction is restarted after some delay. Thus multiple transactions are performed simultaneously with minimum cost. 2.2 Policy Integration As mentioned earlier, our framework is built on the notion that all policies must be an integral part of the database that they are meant to defend in a fashion that makes them directly associated with its very existence. Hosting them in an external application or database or even in another database instance on the same server as the target database, introduces the risk of isolating the policies from the target database and therefore, creating an opportunity for accessing and compromising the database without any lines of defense. In our framework, the policies are fed into physical database tables where they are stored

and managed by the system owner. These tables are owned by the database itself and are not accessible to applications, application servers, or even power users. In this paper, we apply the use of policies to implement autonomic capabilities into a database. We allow the system owner to create database configuration-specific policies that decide the actual run-time behavior of the database. These policies control and decide which changes are allowed and which ones are not. This is based on the database being aware of its operational state being able to defend itself against input from various environmental sources such as users, malicious code, or external software systems. To support policy-based framework, three types of policies are enumerated that can be embed into an Oracle 10g database to demonstrate the effectiveness of the approach. While policy of type one (Top secret policy) is intended to govern the areas of enforcement of configuration security, policies of type two and three govern fine–grained access control (secret level) and user action verification(user level) respectively. The system owner can write as many policies as needed to govern database security. The policies are concise, targeted and simple which makes this approach effective, scalable, flexible and extensible. 2.3 Policy Implementation This section presents some implementation scenarios where the policy-based framework is utilized to autonomically enforce security configuration in databases thus enabling them to self-protect. To demonstrate the usability of the proposed framework we consider a policy for enforcing the password life time security. TYPE 1 (Top Security Level Policy) Example The role of this policy is to verify and control the actions of privileged users such as database administrators and power users. The validation process is performed as a response to the users input as shown below. The DBA calls a stored procedure specific for changing the life time of a password and chooses the values of the parameters he/she intends to change. These values are then verified according to the policy that governs their applicability. The policy specifies a maximum lifetime for passwords. When the specified amount of time passes and the password expires, the user or DBA must change the password otherwise access to an account is denied until a new password is supplied. For example, the following statements create and assign a profile to user john, and the PASSWORD_LIFE_TIME clause specifies that john can use the same password for 50 days before it expires. CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 30 PASSWORD_LIFE_TIME 50; ALTER USER john PROFILE prof;

The permissible number of failed login attempts and the amount of time for which accounts remain locked are specified as four and 30 days respectively. When a particular user exceeds a designated number of failed login attempts, the server automatically locks that user account. The account will unlock automatically after the passage of 30 days. After a user successfully logs into an account, the unsuccessful login attempt count for the user, if it exists, is reset to 0. TYPE 2 (Security Level Policy) Example Fine-grained access control is based on dynamically modified statements.To change any option of a user's security domain, DBA uses the ALTER USER system privilege. DBA are normally the only users that have this system privilege, as it allows a modification of any user's security domain. This privilege includes the ability to set table space quotas for a user on any table space in the database, even if the user performing the modification does not have a quota for a specified table space. Changing a user's security settings affects the user's future sessions, not current sessions. The following statement alters the security settings for user John: ALTER USER John IDENTIFIED EXTERNALLY DEFAULT TABLESPACE data_ts TEMPORARY TABLESPACE temp_ts QUOTA 100M ON data_ts QUOTA 0 ON test_ts PROFILE clerk; The ALTER USER statement here changes John’s security settings as follows: Authentication is changed to use John's operating system account. His default and temporary table spaces are explicitly set. He is given a 100M quota for the data_ts table space. His quota on the test_ts is revoked. He is assigned the clerk profile. TYPE 3 (User Level Policy) Example In an example of this type of policy, a policy is created which does not expose salaries of employees outside the sales department. SELECT ENAME, JOB, SAL, COMM from emp , dept WHERE d.deptno = e.deptno AND d.dname=”Sales”; It is important to note that the stored procedures do not allow the user to input values into variables. Instead, the procedures present the user with a set of values to select from. This is important because it removes any possibility of the users injecting variations to the expected input.

3 Comparisons with Other Related Approaches This paper is concerned with the application of policies to securing a database by embedding the policies in the database itself and enabling these policies to block every attempt to compromise the state of the database. Oliver Jorns et al.[13] proposed another security architecture that not only incorporated easy to compute and flexible transaction pseudonyms for security and privacy assurance, but also allowed the implementation of different kinds of location based services. A different approach to securing the database was presented by Sang H. Son through the offering of timeliness support using partial security policies [8]. It violates security in order to uphold a timeliness requirement and works on the basis of partial security policies. Moreover, it works in a non-replicated environment. Leon Pan[7] also worked on providing security in distributed database using preliminary and fine access control policies but in a non replicated manner and policies are stored and executed at a different server, it introduces risk of isolating the policies from the target database and can create opportunity for accessing and compromising the database without any lines of defense. In our approach, the policies are fed into physical database tables where they are stored and managed by the system owner. These tables are owned by the database itself and are not accessible to applications, application servers, or even power users. In [12], an OWL-DL ontology is created that expresses the modeling abstractions of RBAC. This ontology is attached to domain ontology and explains the tasks that are performed by the security administrator and by the DL classifier. The background knowledge is used to make the access decisions which are available as Semantic Web ontologies. The model has established a secure infrastructure to register, propagate, request and verify user attributes. This functionality is offered by network services that support single sign-on across domains and trusted user directories. Again, conversion techniques are required if the native format is different, while our approach is more flexible and easy to handle. Moreover, the implementation of the security enforcement mechanism is embedded in the database itself and inseparable part of the system making it enable for self-protection, self-healing and self-configuring.

4 Conclusion This paper presented an advanced approach to implement security capabilities into distributed database in order to secure systems at multilevel while maintaining consistency of the system as well. Security is a serious concern while accessing data. In this paper, use of policies is applied for access control to different users depending upon privileges given to them. Policies implemented at different security levels ensure the integrity, availability and correctness of data replicated at multiple nodes. This model can be applied for any distributed environment such as corporate, financial organization etc.

References 1.

2. 3.

4. 5. 6. 7. 8.

9. 10.

11. 12.

13.

14.

15.

16.

Piero A. Bonatti, Sarit Kraus, and V.S. Subrahmanian: Foundations of Secure Deductive Databases. IEEE transactions on knowledge and data engineering, Vol.7, No. 3, pp.406-422, (1995). Zakaria Suliman Zubi: On Distributed Database Security Aspect. International Conference on Multimedia Computing and Systems, IEEE, pp.231--235(2009). Navdeep Kaur, Rajwinder Singh, A.K.Sarje, Manoj Misra: Performance Evaluation of Secure Concurrency Control Algorithm for Multilevel Secure Distributed Database systems. IEEE, (ITCC’05), Vol. 01, pp.249--254(2005). Huaixiang Wang Deyu Dang Shi Min: The Analysis of the Security Strategy of Embedded Mobile Database. IEEE 2010, pp.476--478 (2010). Man Lin: Static Security Optimization for Real-Time Systems. IEEE Transactions on Industrial Informatics, Vol.5, No. 1, pp. 22--37(2009). Veluchandhar: A backup mechanism with concurrency control for multilevel secure distributed database systems. IEEE 2008, pp. 57--62,(2008). Leon Pan. A unified network security and fine-grained database access control model. IEEE 2009, pp. 265--269,(2009). Sang H. Son, Craig Chaney, Norris P. Thomlinson: Partial security policies to support timeliness in secure real-time databases. In Proceedings of the IEEE Symposium on Security and Privacy, pp. 136--147(1998). Bhavani Thuraisingham: Multilevel Security Issues in Distributed Database Management Systems II. Journal of Computers and Security , Vol. 10, No. 9, pp. 727-747 (1991). Parviz Ghorbanzadeh, Aytak shaddeli, Roghieh Malekzadeh, Zoleikha Jahanbakhsh: A Survey of Mobile Database Security Threats and Solutions for It. ICIS 2010, pp.676--682, (2010). Elisa Bertino and Ravi Sandhu: Database Security—Concepts, Approaches, and Challenges. IEEE transactions on dependable and secure computing,, vol.2, No.1, pp. 2--18(2005). Lorenzo Cirio1, Isabel F. Cruz1, and Roberto Tamassia2: A Role and Attribute Based Access Control System Using Semantic Web Technologies. Proceeding OTM'07 Proceedings of the 2007, Volume Part II, LNCS 4806, pp.1256--1266,Springer-Verlag Berlin, Heidelberg(2007) . Oliver Jorns1,2, Gerald Quirchmayr2,3, Oliver Jung1: A Privacy Enhancing mechanism based on Pseudonyms for Identity Protection in Location-Based Services. In Proc. Fifth Australasian Information Security Workshop (Privacy Enhancing Technologies) (AISW 2007), Ballarat, Australia. CRPIT, 68. Brankovic, L. and Steketee, C., pp. 133--142(2007). Bhavani Thuraisingham, William Ford: Security Constraint Processing in a multilevel Secure Distributed Database Management System. IEEE transactions on knowledge and data engineering, Vol. 1, No. 2, pp. 274--293(1995). Kumiko Tadano, Masahiro Kawato, Fumio Machida, and Yoshiharu Maeno: Resource Information Cache Update Control for Scalable Access Control Management Systems. IEEE 3rd International Conference on Cloud Computing, pp.538--539 (2010). Indrajit Ray, Luigi V. Mancini, Sushil Jajodia and Elisa Bertino,: ASEP: A Secure and Flexible Commit Protocol for MLS Distributed Database Systems. IEEE transactions on knowledge and data engineering, Vol. 12, No. 6, pp. 880--899(2000).