MULTILEVEL POLICY BASED SECURITY IN DISTRIBUTED DATABASE

MULTILEVEL POLICY BASED SECURITY IN DISTRIBUTED DATABASE CHAPTER 8 Addressing security demands under fixed budgets and deadline 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 chapter 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. 8.1 INTRODUCTION Distributed database system functions include distributed query management, distributed transaction processing, distributed metadata management, enforcing security and integrity across 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 [BTH1995] and enforcing appropriate access controls [SHS1998]. Databases provide many layers and types of information security, typically specified in the data dictionary including access control, auditing, authentication and encryption. Access control is a system which enables an authority to control access to areas and resources in a given physical facility or computer-based information system [KTA2010]. An access control system, within the field of physical security, is generally seen as the second layer in the security. Authentication is the act of establishing or confirming something (or someone) as authentic, that is, the claims made by or about the subject are true [HWD2010]. All organizations, ranging from commercial organizations to social organizations, in a variety of domains such as healthcare and homeland 87

protection, may suffer heavy losses from both financial and human points of view as a consequence of unauthorized data observation [EBE2005]. In cryptography, encryption 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 [MLI2009]. Some of the most important security requirements for database management systems are: Multi-Level Access Control, Confidentiality, Reliability, Integrity and Recovery [XZH2007]. 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 [PAB1995] and 3) availability refers to the prevention and recovery from hardware and software errors and from malicious data access denials [PGH2010]. 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 [VVA2008]. A security level for transaction represents its clearance level and for data, the security level represents the classification level. 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 [XZH2007]. 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. A computer security policy consists of a clearly defined and precise set of rules for 88

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 chapter, the main focus is on the confidentiality requirement and access control policies to provide high-assurance confidentiality. This chapter not only deals with access control to the data but also with access control aspect of integrity, that is, enforcing that no unauthorized modifications to data occur. 8.2 PROPOSED MODEL The proposed model consists of Multi Level Secure database [IRA2000] that is distributed in a replicated manner over N sites connected by a network. As shown in Figure 8.1, at each site when the user request is received, the first job a secure server does is to authenticate the user. The authentication is performed based on factors such as 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 does not 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 S and confidential level request which is further divided in to secret level request SL D s and top secret level request SL. If the user is permitted access to the user level, the query is D t limited with the user level transaction SL Q SL otherwise the query is rolled back to confidential level security. At level second, the request SL Q goes through a Du D u 89

process of verification before it 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 90

other sites, audit trail and 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 is notified and an audit trail is recorded. Thus the proposed model felicitates to access data only after passing through multiple security levels. In this model, 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 about the changes to be made. 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. 8.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 [ZSZ2009]. A transaction can only read at its own level or low level but can write at its own level only [NKA2005]. This is sufficient to prove that security is not violated through data access. The access permissions considered in the proposed model are shown in Table 8.1. Let denotes the top security level transaction, the security level and T t as user level transaction i.e. L whereas denotes the data item T u L T s Z as the top security level data item, L Y s the security level data item and L X u as user level data item i.e. L Xu L Ys L Zt. L T t T s Z t T u The execution of a distributed transaction T is divided into sub-transactions T i, where T n T i i 1. A sub-transaction T i is sent to the node and executed under local security. N i where the data is available 91

Data Item Transaction Table 8.1 Access Permission X u x T t Ys r y r x r y, w y Ts x Tu Z t r r z, w z r - -, - 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 items requested by a transaction are located. If the data is available at the parent node N i, it is accessed at the same node N i, 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 not request additional locks once it has issued an unlock action. It holds onto all its locks (read or write) until it completes. A top 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 security level transaction is restarted after some delay. Thus multiple transactions are performed simultaneously with minimum cost. 8.3 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 line of defense. In our framework, the policies are fed into physical database tables where they are stored 92

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 the proposed model, 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 fact that database is aware of its operational state and 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 security policy) is intended to govern the areas of enforcement of configuration security, policies of type two and three govern fine grained access control (security 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. 8.4 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, a policy for enforcing the password life time security is considered. 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 (DBA) and power users. The validation process is performed as a response to the users input. 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. 93

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 94

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. 8.5 COMPARISON WITH OTHER RELATED APPROACHES This chapter is concerned with the application of policies to secure 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 et al. [OJO2007] 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 secure database was presented by Sang H. Son through the offering of timeliness support using partial security policies [SHS1998]. 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 [LPA2009] 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 in an unauthorized way. In [LCI2007], an OWL-DL (Web Ontology Language (OWL) ontology) is created that expresses the modeling abstractions of RBAC [Role Based Access Control]. 95 This

ontology is attached to domain ontology and explains the tasks that are performed by the security administrator and by the DL [Description Logics] classifier. The background knowledge is used to make the access decisions which are available as Semantic Web ontology. 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. 8.6 CONCLUSION This chapter 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. In this model, policies are 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. 96