Securing Data Warehouses: A Semi-automatic Approach for Inference Prevention at the Design Level

Transcription

1 Securing Data Warehouses: A Semi-automatic Approach for Inference Prevention at the Design Level Salah Triki 1, Hanene Ben-Abdallah 1, Nouria Harbi 2, and Omar Boussaid 2 1 Laboratoire Mir@cl, Département d Informatique, Faculté des Sciences Economiques et de Gestion de Sfax, Tunisie, Route de l Aéroport Km Sfax, BP {Salah.Triki,Hanene.BenAbdallah}@Fsegs.rnu.tn 2 Laboratoire ERIC, Université Lyon 2, 5 avenue P. Mendès France Bron, Cedex, France {Nouria.Harbi,Omar.Boussaid}@univ-lyon2.fr Abstract. Data warehouses contain sensitive data that must be secured in two ways: by defining appropriate access rights to the users and by preventing potential data inferences. Inspired from development methods for information systems, the first way of securing a data warehouse has been treated in the literature during the early phases of the development cycle. However, despite the high risks of inferences, the second way is not sufficiently taken into account in the design phase; it is rather left to the administrator of the data warehouse. However, managing inferences during the exploitation phase may induce high maintenance costs and complex OLAP server administration. In this paper, we propose an approach that, starting from the conceptual model of the data sources, assists the designer of the data warehouse in indentifying multidimensional sensitive data and those that may be subject to inferences. Keywords: Data warehouse, Security, Precise Inference, Partial inference. 1 Introduction Organizations have a significant amount of data that can be analyzed to identify trends, examine the effectiveness of their activities, and take decisions to increase their profits. By gathering and consolidating data issued from the organization s information system, a data warehouse (DW) allows decision makers to perform decision analyses and financial forecasts. In fact, several tools dedicated to data warehousing offer various operations for OnLine Analytical Processing (OLAP), assisting users in the decision analysis process. On the other hand, data in an organization s DW are proprietary and sensitive and should not be accessed without controles. Indeed, some data, like medical data, religious or ideological beliefs, are personal and may harm their owners if disclosed. For this, several governments passed laws for the protection of the citizens s private L. Bellatreche and F. Mota Pinto (Eds.): MEDI 2011, LNCS 6918, pp , Springer-Verlag Berlin Heidelberg 2011

2 72 S. Triki et al. lives. Among these laws, HIPAA 1 (Health Insurance Portability and Accountability Act) aims to protect patient medical data by forcing American health care establishments to follow strict safety rules. Similarly, GLBA 2 (Gramm-Leach-Bliley Act) requires U.S. financial institutions to protect customer data; on the other hand, Safe Harbor 3 allows companies conforming to transfer and use data on European Internet ; and Sarbanes-Oxley 4 Act guarantees the reliability of corporate financial data. Agencies must use strict safety rules to comply with these laws, otherwise they are punished. Securing a DW is a twofold task. The first fix the access rights of the DW users. Similar to information systems, this security task can be treated at a conceptual or logical level; the fixed access rights are enforced by the OLAP server. As for the second security task, it seeks to ban malicious users from infering prohibited information through permitted acceses. In fact, there are two types of inferences: precise inferences where the exact data values are deducted, and partial inferences where data values are partially disclosed. Inference prevention at design level reduces administration costs and maintenance of OLAP servers. Despite this, inference prevention at design level has not received enough interest from researchers. The aim of this paper is to propose an approach to model the prevention of inferences using the data source design represented as a class diagram. Our approach has two advantages over existing approaches. The first advantage is its genericity since it is applicable to any business domain. The second advantage is that it takes into account the data available to the malicious user to detect inferences; the majority of inference cases are produced by combining available data. The remainder of the paper is organized as follows: in section 2, we present a state of the art in the DW security domain at the requirement and design levels. In Section 3, we detail our approach. Section 4 presents an example illustrating the use of our approach. Finally, we summarize the work done and outline our work in progress. 2 Related Work The need for securing DW was felt long ago [1] [2]. Several proposed approaches tackled the DW security problem at the requirement, design or logical levels. At the requirement level, [3] propose a profile based on i and an approach that can model the security requirements. The proposed profile takes into account the RBAC ("Role Based Access Control") model and MAC (" Mondatory Access Control ") model. Thus, for each data to be protected, a security class must be defined in terms of: security role, security level and compartment. Using this profile, the proposed approach to model security requirements operates on three stages : i) analyzing the rules and privacy policies that exist in the organization; ii) interviewing the securityin-charge personnel to define the data to be secured; and iii) affecting security classes for each data. This approach is informally presented content-detail.html

3 Securing Data Warehouses 73 At design level, several studies have been carried out. [4] propose a UML profile for modeling security and extensions of OCL (Object Constraint Language) to specify security constraints. The UML profile, called SECDW (Secure Data Warehouse), includes new types, stereotypes and tagged values to model the RBAC and MAC models. [5] extended SECDW to represent the concept of conflict among multidimensional elements. However, neither work proposed an approach to design a secure DW model. On the other hand, [6] proposed an approach using the UML state-transition diagram to detect inferences in a DW design. In the state-transition diagram, the states represent the data to display and transitions represent users multidimensional queries. The approach takes into account the possibility of inferences from empty cells in a cube (i.e., unavailable data for measures), without addressing the possibility of inferences from available data. For their part, [7] proposed an approach specific to the field of market research in general and the particular case of the company GFK [9]. This approach addressed the case of partial and precise inferences. Precise inferences occur when the exact measure values is deduced, while partial inferences occur when an idea about the measure values is deduced. In this work, inferences were detected manually by studying the application domain of market research. At logical level, [5] treated the case of implementation in the multi-dimensional relational model based on the extension of the CWM ( Common Warehouse Metamodel ). This extension allows the definition of security constraints and audit rules for each element of the relational model. Security constraints allow the implementation of RBAC and MAC and audit rules can log access attempts to analyze problematic cases. After our review of the state of the art of DW security, we noticed the following four points: - Modeling access rights has been treated at the requirement, design and logical levels. Existing work ([3] [4] [5] [9]) were able to offer notations for modeling the MAC and RBAC models. However, the proposed approaches were informally described. - Prevention of inferences has been widely treated at the physical level ( [10] [11] [12] [13] [14]). This level can enduce high administrative costs and high maintenance. - Prevention of inferences at the design level has not been sufficiently addressed. The existing works ([6] [7]) do not take into account the potential inferences from the data available and are specific to a particular application domain. - Existing proposals lack assistance in identifying data from the DW that are potentially subject to inferences. In this paper, we treat the last two points by proposing at the design level: i) a UMLbased language for modeling data potentially subject to inferences, and ii) a semiautomatic approach to identify such data. 3 Proposed Approach The approach we propose is based on the data sources class diagram. In addition, it assumes that the DW schema is already designed and mapped to the data sources.

4 74 S. Triki et al. In fact, our approach fits in and complements the three types of DW design approaches: bottom-up ([15] ), top-down ([16]), and mixed ([17]). In all three types of design approaches, once the DW schema is developed, it must be matched with the data sources to indicate the source of the elements that will be used to load each element of the DW; this mapping is vital for the definition of the ETL procedures. In the case of bottom-up and mixed approaches, this mapping is produced by default since the DW schema definition is developed from the data sources. As for the topdown approaches, this mapping is needed to validate the specified DW schema. Our approach (see Fig. 1) comprises three phases. The first phase, carried out by the security designer, identifies the elements to be protected in the DW design. In the second phase, we first automatically build an inferences graph used to detect the elements which may lead to inferences; secondly, the designer distinguishes the elements that lead to precise inferences and those that lead to partial inferences. In the third phase, we automatically enrich the DW schema model by UML annotations highlighting the elements subject to both types of inferences. Note that we use in this paper the star schema to model the DW schema. 3.1 Definition of Sensitive Data Given a DW schema, the definition of sensitive data annotates the elements of the multidimensional model. It is made by the DW security designer who may be assisted by an expert in the field. The role of the domain expert is to identify the data to be protected. This data is indicated by annotations with the UML stereotype Sensitive data (see Fig. 1). 3.2 Inference Graph Construction Definition 1: An inference graph is a set of nodes connected by oriented arcs. The nodes represent the data (in the source) and the arcs indicate the direction of inference and the inference type (partial/precise). Graphical notations: An inference graph is graphically composed of: - Two types of nodes: nodes colored in gray represent the sensitive data, and nodes colored in white represent the non-sensitive data. - Two types of arcs: dotted arcs indicate partial inferences and solid arcs indicate precise inferences. Take the case of health, disease (sensitive data), treatment and service are represented by nodes. The correspondence between the disease and treatment is the inferences and their meaning (Fig. 2): Knowing the treatment, one can infer the disease. This inference is precise because two different diseases may not have the same treatment, so we have a solid arc treatment to illness. On the other hand, if in a hospital, each service treats a number of diseases, then, knowing the service, one can have an idea about the kind of disease but not its name; this is modeled by the dotted arc from service to illness.

5 Securing Data Warehouses 75 DW schema (1) Sensitive data identification DW schema: Sensitive data identified (2.a) Inference graph construction (2.b)Partial inference Identification A B C D E Inferences graph Data sources class diagram A B C D Inference graph : Partial inference detected E (2.c) Calculating the transitive closure A B C D Graph inferences: new partial inference detected E (3) DW schema enrichment DW schema enriched Fig. 1. Proposed Approach for DW schema security

6 76 S. Triki et al. Illness Treatment Service Fig. 2. Inference graph: Example The construction of an inferences graph involves the class diagram of data sources that will load the DW. We use the mapping to prune out the inference graph built from the data sources and restrict it to only the nodes corresponding to data used for the loading of the DW schema. In our approach (see Fig. 1), the inference graph is built automatically based on the cardinality of the class diagram of the data sources. To do this, we apply the following six rules: R1. Each class is represented by a node colored in gray if the corresponding data is sensitive and colored in white otherwise. R2. Each binary association / aggregation between two classes and will be represented by an arc according to the following three cases: Case 1 (see Fig. 3 (a, b)): if the association/aggregation has cardinality on s side and cardinality 1 or 0..1 on the s side, then an arc from to is added to the inference graph (see Fig. 3 (c)) Case 2 (see Fig. 4 (a, b)): if the association/aggregation has cardinality s side and cardinality 1 or 0..1 on s side and is also connected to C3 by an association/agregation with cardinality on side and the cardinality of 1 or 0..1 on C3 s side, then two arcs are added to the inference graph. The first from to C3 and the second from C3 to (see Fig. 3 (c)) Case 3 (see Fig. 5 (a)): if the association has a class C3, then two arcs are added to the inference graph; one from C3 to and another from C3 to (see Fig. 5 (b)). 1 or or 0..1 (a) (b) (c) Fig. 3. Inference first case

7 Securing Data Warehouses 77 1 or or 0..1 C3 1or0..1 1or0..1 (a) (b) (c) Fig. 4. Inference second case C3 (a) (b) Fig. 5. Inference third case 1 or 0..1 (a) (b) (c) (d) Fig. 6. Representing composition R3. Each composition (see Fig. 6 (a)) will be represented by an arc from the component to the composite (see Fig. 6 (b)). If in addition the cardinality of the component side is 1 or 0..1 (see Fig. 6 (c)), then a second arc from the composite is added to the component (see Fig. 6 (d)). R 4. Each n-ary association with cardinalities and 1 or 0..1 will be represented by arcs from classes with cardinalities 1 or 0..1 to those with the cardinality. For example, the ternary association in Fig. 7 (a) is represented by the graph in Fig. 7 (b).

8 78 S. Triki et al. 1 or 0..1 C3 (a) (b) Fig. 7. Representing n-ary association R5. If an inheritance relationship exists between two classes (parent) and (child) and if is connected to C3 by an association with a cardinality on s side and the cardinality on C3 s side is 1 or 0..1 (see Fig. 8 (a)), then an arc is added from to C3 (See Fig. 8 (b)). R6. If an inheritance relationship exists between two classes (parent) and (child) and if is connected to C3 by an association with a cardinality 1 or 0..1 on s side and the cardinality on C3 s side is (see Fig. 8 (c)), then an arc is added from C3 to (See Fig. 8 (d)). 1 or 0..1 C3 (a) (b) 1 or 0..1 C3 (c) (d) Fig. 8. Representing an inheritance relationship The automatic construction of the inference graph does not indicate the type of inferences: partial or precise. This indication cannot be, unfortunately, deducted automatically. Thus, after constructing the inference graph, the designer must distinguish partial inferences (drawn by dotted arcs).

9 Securing Data Warehouses 79 In addition, to ensure that all possible inferences have been determined, approach continues with the automatic calculation of the transitive closure of graph. On the resulting graph, we distinguish two types of paths: - Precise path: it is a path where all connected nodes allow precise inferences. - Partial path: it is a path with at least one node allows partial inferences. 3.3 Enrichment of the DW Schema The inference graph is used to enrich the DW schema (see Fig. 1). To do so, our approach assumes that the mapping between elements of the DW schema and the source is already done. We exploit this mapping to apply the two following enrichment rules: - For each element of the inference graph belonging to a Precise path annotate its corresponding element in the DW schema with Precise Inference: ElementName: NameInferedData. - For each element of the inference graph belonging to a partial path annotate its corresponding element in the DW schema with "Partial Inference: ElementName: NameInferedData. our the 4 Example Fig. 9 contains the class diagram of a fictitious data source in the healthcare domain. Table 1 contains details of various classes. Fig. 10 presents a DW schema that analyzes the costs and durations of the diagnostic along the analysis axes: Disease, Treatment, Critical Illness, Transfer, Date Time, and Doctor's specialty. The latter takes the value generalist if the doctor who performed the diagnostic is a generalist and specialty of the doctor otherwise. Fig. 9. Class diagram of the data sources

10 80 S. Triki et al. Table 1. Details of Fig. 9 classes Class Date and Time Admission Diagnostic Doctor Specialty Illness Treatment Critical illness Transfer Details Date and time of a patient admission. Patient admission. Patient diagnostic. Doctor who made the diagnostic. Specialty of doctor who made the diagnosis. Illness diagnosed. Treatment necessary to cure the disease. Serious disease requiring patient transfer to another hospital where he will receive appropriate care. This association class contains the date of transfer of the patient and the hospital will welcome. Fig. 10. Multidimensional Model 4.1 Inference Graph Illness corresponding to a given patient is a sensitive information since it is part of professional secrecy in medical activities. In our example, we look at the data that allow us to infer a patient's illness. Fig. 11 contains the inference graph constructed from the cardinality of the class diagram of the source data. In this graph, gray nodes are the sensitive data; dotted arcs represent the inferences that we considered partial, and those in solid line are believed to be precise inferences. This graph shows inferences seven partial and one precise. The calculation of the transitive closure of the graph has highlighted other potential inferences. For the sake of clarity, we have shown in Fig. 12 new paths. These paths are partial because they contain nodes that allow partial inferences. In Table 2 the first column shows some new inferences composed of the paths listed in the second column. From Table 2 and Fig. 12, we can deduce that: - A user with access to the dates and times of admission and transfer data, may infer that the diagnosed illness were critical,

11 Securing Data Warehouses 81 Illness Critical Illness Treatment Admission Diagnostic Transfer Date and Time Doctor Specialty Fig. 11. Initial Inferences graph Illness Critical Illness Treatment Admission Diagnostic Transfer Date and Time Doctor Specialty Fig. 12. Inference graph after calculating the transitive closure - Access to the date and time of admission and the specialty of the doctor who performed the corresponding diagnosis on admission, allow the user to infer the type of illness the patient has - Access to treatment received by a patient, allow a user to infer the disease the patient has.

12 82 S. Triki et al. Table 2. Partial paths Inference Date and Time Diagnostic Date and Time Doctor Date and Time Transfer Date and Time Illness Partial path Date and Time Admission, Admission Diagnostic Date and Time Admission Admission Diagnostic Diagnostic Doctor Date and Time Admission Admission Diagnostic Diagnostic Transfer Date and Time Admission Admission Diagnostic Diagnostic Illness 4.2 DW Schema Enrichment Based on the inference graph and the mapping between the data source and DW schema, we get automatically the security annotation for the DW schema elements with ptential inferences (see Fig. 13). In this model, the dimensions of time and date are have the same annotation to specify that the two sets can lead to inferences. In Fig. 11, for the sake of clarity, we have not listed all the annotations. Fig. 13. DW schema annotated with the security information 5 Conclusion In this paper, we presented an approach to produce a conceptual multidimensional model annotated with information for the prevention of inferences. Our approach has two advantages over existing approaches. The first is its independence from the data domain. The second advantage is the use of available data to detect inferences. Our approach constructs a graph of inferences based on the class diagram of data sources. The class diagram allows us with the assistance of the domain expert to identify the

13 Securing Data Warehouses 83 elements to lead to precise and partial inference. These elements will be annotated in the multidimensional model. Currently, we are studying how to transfer to the logical level the annotations defined at the design level. References 1. Bhargava, B.K.: Security in data warehousing (Invited talk). In: Kambayashi, Y., Mohania, M., Tjoa, A.M. (eds.) DaWaK LNCS, vol. 1874, pp Springer, Heidelberg (2000) 2. Pernul, G., Priebe, T.: Towards olap security design - survey and research issues. In: 3rd ACM International Workshop on Data Warehousing and OLAP DOLAP 2000, Washington, DC, Novembre 10, pp (2000) 3. Soler, E., Stefanov, V., Mazón, J.-N., Trujillo, J., Fernández-Medina, E., Piattini, M.: Towards comprehensive requirement analysis for data warehouses: Considering security requirements. In: The Third International Conference on Availability, Reliability and Security ARES 2008, Barcelone, Espagne, pp IEEE Computer Society, Los Alamitos (2008) 4. Soler, E., Villarroel, R., Trujillo, J., Fernández-Medina, E., Piattini, M.: Representing security and audit rules for data warehouses at the logical level by using the common warehouse metamodel. In: The First International Conference on Availability, Reliability and Security ARES 2006, Vienne, Autriche, pp IEEE Computer Society, Los Alamitos (2006) 5. Triki, S., Ben-Abdallah, H., Feki, J., Harbi, N.: Modeling Conflict of Interest in the design of secure data warehouses. In: The International Conference on Knowledge Engineering and Ontology Development 2010, Valencia, Espagne, pp (2010) 6. Carlos, B., Ignacio, G., Eduardo, F.-M., Juan, T., Mario, P.: Towards the Secure Modelling of OLAP Users Behaviour. In: The 7th VLDB Conference on Secure Data Management, Singapore, September 17, pp Springer, Heidelberg (2010) 7. Steger, J., Günzel, H.: Identifying Security Holes in OLAP Applications. In: Proc. Fourteenth Annual IFIP WG 11.3 Working Conference on Database Security, Schoorl (near Amsterdam), The Netherlands, August (2000) 8. Icon Group Ltd. GFK AG: International Competitive Benchmarks and Financial Gap Analysis (Financial Performance Series). Icon Group International (2000) 9. Villarroel, R., Fernández-Medina, E., Piattini, M., Trujillo, J.: A uml 2.0/ocl extension for designing secure data warehouses. Journal of Research and Practice in Information Technology 38(1), (2006) 10. Haibing, L., Yingjiu, L.: Practical Inference Control for Data Cubes. IEEE Transactions on Dependable and Secure Computing 5(2), (2008) 11. Cuzzocrea, A.: Privacy Preserving OLAP and OLAP Security. In: Encyclopedia of Data Warehousing and Mining, pp (2009) 12. Zhang, N., Zhao, W.: Privacy-Preserving OLAP: An Information-Theoretic Approach. IEEE Transactions on Knowledge and Data Engineering 23(1), (2011) 13. Terzi, E., Zhong, Y., Bhargava, B.K., Pankaj, Madria, S.K.: An Algorithm for Building User-Role Profiles in a Trust Environment. In: Kambayashi, Y., Winiwarter, W., Arikawa, M. (eds.) DaWaK LNCS, vol. 2454, pp Springer, Heidelberg (2002)

14 84 S. Triki et al. 14. Bhargava, B.K., Zhong, Y., Lu, Y.: Fraud Formalization and Detection. In: Kambayashi, Y., Mohania, M., Wöß, W. (eds.) DaWaK LNCS, vol. 2737, pp Springer, Heidelberg (2003) 15. Golfarelli, M., Rizzi, S.: A Methodological Framework for Data Warehouse Design. In: ACM First International Workshop on Data Warehousing and OLAP DOLAP, Bethesda, Maryland, USA, pp. 3 9 (Novembre 1998) 16. Feki, J., Nabli, A., Ben-Abdallah, H., Gargouri, F.: An Automatic Data Warehouse Conceptual Design Approach. In: Wang, J. (ed.) Encyclopedia of Data Warehousing and Mining, 2nd edn. (2008) 17. Lujan-Mora, S., Trujillo, J.A.: Comprehensive Method for Data Warehouse Design Fifth International Workshop on Design and Management of Data Warehouses, DMDW 2003, Berlin, Allemagne (Septembre 2003)