Secure logical schema and decomposition algorithm for proactive context dependent attribute based inference control

Abstract

Inference problem has always been an important and challenging topic of data privacy in databases. In relational databases, the traditional solution to this problem was to define views on relational schemas to restrict the subset of attributes and operations available to the users in order to prevent unwanted inferences. This method is a form of decomposition strategy, which mainly concentrates on the granularity of the accessible fields to the users, to prevent sensitive information inference. Nowadays, due to increasing data sharing among parties, the possibility of constructing complex indirect methods to obtain sensitive data has also increased. Therefore, we need to not only consider security threats due to direct access to sensitive data but also address indirect inference channels using functional and probabilistic dependencies (e.g., deducing gender of an individual from his/her name) while creating security views. In this paper, we propose a proactive and decomposition based inference control strategy for relational databases to prevent direct or indirect inference of private data. We introduce a new kind of context dependent attribute policy rule, which is named as security dependent set, as a set of attributes whose association should not be inferred. Then, we define a logical schema decomposition algorithm that prevents inference among attributes in security dependent set. The decomposition algorithm takes both functional and probabilistic dependencies into consideration in order to prevent all kinds of known inferences of relations among the attributes of security dependent sets. We prove that our proposed decomposition algorithm generates a secure logical schema that complies with the given security dependent set constraints. Since our proposed technique is purely proactive, it does not require any prior knowledge about executed queries and do not need to modify any submitted queries. It can also be embedded into any relational database management system without changing anything in the underlying system. We empirically compare our proposed method with the state of art reactive methods. Our extensive experimental analysis, conducted using TPC-H¹ benchmark scheme, shows the effectives our proposed approach.

Introduction

The evolution of technology in business applications has increased the importance of protecting sensitive data, that needs to be accessed by many different users with different access privileges. Fine grained inference control methods has become crucial to prevent the inference of unwanted sensitive information from the data disclosed only to legitimate users. In relational database management systems, usually views have been used for this purpose. In order to satisfy the given privacy policies, in view based solutions, basically direct inferences of sensitive data is prevented without considering existence of the functional and probabilistic relationships among the attributes in the database schema. These approaches have very simple purpose; that is, to determine whether to grant or deny the access, based on the predefined constraints related to the role of the user. Especially, for the attribute based access control models, the attributes that are going to be related with each other in a query are used in making the grant or deny decision of the query. However, using functional and/or probabilistic dependencies, it might be possible to obtain sensitive relationships among attributes indirectly. The aim of this paper is to propose a formal model to address this kind of sensitivity problem and describe a decomposition based solution to it.

In order to illustrate the problem of indirect inference of the relationships among security dependent attributes² through functional and probabilistic dependencies, consider a simple database application with an EMPLOYEE relation. Assume that the company would like to adjust the salaries of its employees based on their departments, positions and years of experiences according to market standards. The EMPLOYEE relation has the following schema:

EMPLOYEE=(id , phoneNumber, name, gender, salary, department, position, yearsOfExperience).

To reduce potential biases in determining salary increases, we may want to limit disclosure of gender and salary relationship using views. Also, assume that in this relation id and phoneNumber fields are two keys, and id is selected as the primary key. Therefore, probable join queries should be checked to guarantee that salary and gender fields cannot be related with each other by the help of these keys. In addition, we have assumed that there is no functional or probabilistic dependency other than the ones which make id and phoneNumber candidate keys for the EMPLOYEE relation.

A natural solution to this problem is decomposing the EMPLOYEE relation into two views as follows:

EMPLOYEE₁₁=(id , name, gender, department, position, phoneNumber, yearsOfExperience)

EMPLOYEE₁₂=(id , name, salary, department, position, phoneNumber, yearsOfExperience).

However, this decomposition is faulty since salary and gender relationship can be generated using the following query:

SELECT e1.gender, e2.salary FROM EMPLOYEE₁₁ e1, EMPLOYEE₁₂ e2 WHERE e1.id=e2.id.

To prevent this kind of join queries on keys, a further decomposition can be done:

EMPLOYEE₂₁=(id , name, department, position, phoneNumber, yearsOfExperience)

EMPLOYEE₂₂=(name, salary, department, position, yearsOfExperience)

EMPLOYEE₂₃=(name, gender, department, position, yearsOfExperience).

This decomposition may initially seem to be correct as it is not possible to join EMPLOYEE₂₂ and EMPLOYEE₂₃ using the given keys to relate salary and gender fields. However, name and salary fields appear together in EMPLOYEE₂₂ relation, and it is possible to infer gender from the name of an employee with high probability. Thus, in a correct solution, the possibility of relating salary with name should also be prevented as in the following decomposition:

EMPLOYEE₃₁=(id , name, department, position, phoneNumber, yearsOfExperience)

EMPLOYEE₃₂=(salary, department, position, yearsOfExperience)

EMPLOYEE₃₃=(name, gender, department, position, yearsOfExperience).

One of the most important point of this example is the breaking the dependencies of gender and salary attributes with the keys. Some other key distribution alternatives may be possible for the decomposed relations, and this issue will be discussed later in the paper.

By using the schema obtained with EMPLOYEE₃₁, EMPLOYEE₃₂ and EMPLOYEE₃₃, it is not possible to define any query which relates salary and gender attributes either through equijoins on keys, or through using the given probabilistic dependencies. Therefore, this decomposition satisfies the given security policy. Also note that there may be keyless relations obtained after the decomposition, as it is usual in views, and this issue will also be discussed in Section 4.

As in this example, a view based solution can be generated to satisfy a given privacy policy. There can be several policy rules, and views should be constructed to satisfy these policies. The need for defining different external layers for different inference control policies has increased by web based data sharing trend [1]. Therefore, a formal approach is needed to build a secure external layer by decomposing the relations into sub relations according to privacy policy rules and to generate relevant secure logical schema. These sub-relations can be used to generate accessible views for users. Notice that, if any attribute other than candidate keys, such as position in the example, can be used as a key due to data distribution; then, this attribute should be stated as a candidate key or should be perturbed. Most likely, this pseudo-key situation may happen either at the beginning or may occur after data is inserted to the schema. In order to solve this issue, pseudo-key can easily be added as a key to the system, and the decomposition can be applied again as the external layer is consisting of views only.

Most of the research addressing inference control problem is mainly focused on dynamic mechanisms employing query investigation or modification methods, and by also tracking the query history [2], [3], [4], [5], [6], [7]. On the other hand, our strategy in this paper is to decompose the relation into views in advance, in order to prevent the time spent by costly query modification or history tracking operations [8]. To the best of our knowledge, this is the first attempt in the literature to satisfy privacy for context dependent attribute based inference control using a proactive approach. The approach is labeled as ”proactive”, since it does not need to perform costly query history investigation, query modification, or row/attribute based joins or calculations existing in reactive strategies. Another problem with reactive strategies is the consistency. Basically, in a reactive strategy, the queries that can be issued by the user will dynamically change based on their usage history. Therefore, two users with the same rights may not be able to issue the same queries if their query history is different. This could create consistency problems from a regular user point of view. In addition to those, our method can be easily adapted for validating existing external schema against given attribute based policy rules. The proactive decomposition method described in this paper can easily be combined with other constraints such as attribute based policy rules during implementation.

In the rest of this paper, we first present a formal method to define secure logical schema for preserving context dependent attribute based privacy policies, then we define a decomposition algorithm that guarantees to produce a secure logical schema. Experiments are also performed for a comparative timing analysis against reactive strategies. This paper is organized as follows: Section 2 describes the related works in the field of security and privacy in databases. Then, the Section 3 gives the preliminaries and definitions used through the rest of the paper. Section 4 presents the decomposition algorithm that satisfies the access policies, and the proof of the algorithm. The next section, Section 5, contains experiments which makes a concrete comparison in between the proactive and reactive strategies and Section 6 briefly discusses the future work. Finally Section 7 contains the conclusion.