Distributed Policy Based Access to Networked ... - CiteSeerX

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
1 } // Then signal the PEP to allow the action is is controlling. Decision { authorizer.allow() }

SPL

allows for the specification of the required policy resource model elements (Java class instances) over which the conditions and actions are evaluated. If the condition evaluates to true, the action element is evaluated. One or more Import statements are used to define the resource model requirements; a Condition statement defines the logical expression; and, a Decision statement defines the action to be taken on the resource model. WPML provides two policy types; Authorization policies return a true or false result according to the policy action; Obligation policies are evaluated only for their side-effects in the Decision statement and always return a true result to the PEP. SPL does not distinguish between these types of policies, but WPML does by providing a resource model for authorization, as shown in the above textbox. The policies and metadata are stored in a local Policy Repository. A policy stored in a repository may be marked as active or inactive. WPML implements a number of policy repositories including non-persistent in-memory, and a persistent relational database. Before requesting policy decisions, a Policy Enforcement Point (PEP) registers with a PDP and provides information including its type (i.e. authorization or obligation), a description of the instance data that will be provided on decision requests, and an optional set of attributes. When a PDP receives an evaluation request from PEP, it performs a matching of the PEP metadata with the policy metadata, using type, required instance data, attributes and policy activation state. While the WPML component can be used for fine-grained filtering of the information that is exchanged among coalition members, a method for enabling such interoperation is needed. Following, we provide more details on how data federation is achieved in our system.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < IV. DISTRIBUTED POLICY-BASED CONTROL IN A DDFD Enforcing global data access policies across this type of distributed database can be achieved using a distributed version of the type of policy architecture described above. In this case the PEP and PDP components are deployed to all database nodes where policy is to be enforced. Each PDP then has access to a distributed policy repository, which uses a local database connection for writes (Store Locally) and a Gaian database connection for reads (Query Anywhere). A Policy Management Tool can be used at any node in the database to create, check and store policies locally, which will then be enforced at all PEPs. The number of nodes that are chosen to enforce policies in the network represents a trade-off between robustness of policy enforcement and overhead of policy distribution: the larger the number of nodes that enforce policies the tighter the control of data dissemination. However, policies have to be transferred to a larger number of nodes, to be analyzed and enforced, which increases the overhead of transmitting them over the network using the Query Anywhere mechanism. In the following, we describe in more details the components of the implementation and in particular the query process flow and the policy evaluation process. To enforce policies at the database nodes two types of data filtering mechanism can be deployed: •

SQL Result Filter

A SQL Result Filter receives query information at runtime, executes the query against its local and federated data sources and then filters the results received before passing them back to the querying node. The elements of query information required to implement this type of filter are: the logical table being queried, its locally federated data sources and the credentials of and general information on the originator of the query. The types of control provided are: the ability to deny access to a data source exposed by a logical table and the ability to filter the rows returned by the SQL query against that table. Regarding the latter, for each row of the ResultSet that is returned for the SQL query, a policy evaluation is requested based on the contents of that row and the context in which the query has been requested. The result of the policy evaluation might be either to return/drop the row as a partial result to the requestor (in case of an authorization policy), or even modify the contents of some (or all) of the columns of the row (in case of an obligation policy). This way, individual rows may be withheld and individual column values may be masked out or re-written. •

4

best suited to implementing Obligation policies, particularly where the obligation can be translated into some form of database stored function or procedure. The extra complexity involved is worthwhile when clear performance improvements can be made. A. Gaian Database Implementation of a SQL Results Filter As an example we describe the implementation of an SQL results filter in the Gaian Database. The filter is implemented as a Policy Enforcement Point (PEP) ‘plug-in’ that facilitates policy enforcement on the JDBC data that flows through the system. To determine the operations that need to be performed and the information required we first develop an object model that describes the “resources” of the query process, i.e. the query itself and its results. The model provides anchor classes for representing the meta-information that describes a relational schema, namely tables, rows and columns. Columns can be referenced in the policy by their name in the query, and the values of their data can be changed on the fly before being returned, according to policy decisions. A generic QueryContext anchor class represents the context in which the query is submitted, which can include arbitrary information such as the name of the user that requested it, their country affiliation and security clearance, or any other type of information that might be considered by the policies. The object resource model for relational schemas is depicted in Figure 3.

SQL Query Filter

A SQL Query Filter is an alternative way of activating the policy enforcement. In this type of filter the incoming SQL query is modified before being executed against the local and federated data sources. This type of filter reduces the amount of data filtering that has to be performed in the DDFD node but the SQL transformation required can be very complex, even for relatively simple policies. The SQL Query Filter is

Figure 3: The resource model for performing policy evaluations on relational schemas

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < Next we develop a policy template. This is a human readable form of the high level policy statements, such as those described in Section 2, but which incorporates the resource model objects and methods as a logical representation of the policy. Since a policy template parameterizes the resource model, the same logical template can be used to create variations of the high level policy by varying the parameters. The logical policy template is then mapped directly into the SPL representation required by the WPML engine and for the policy consistency and coverage checking tools. To perform these steps we have developed a ‘Policy Authoring Tool’ which is depicted in Figure 4 and which shows the logical statements corresponding to one of the high level policy examples described in Section 2. The policy tool provides facilities to ‘Author ‘ new policies, ‘Analyze’ new policies in the context of currently deployed policies and to ‘Deploy’ new policies to the DDFD or to remove existing policies. Figure 4 illustrates the authoring of the logical policy template for the high level policy: Only grant access to data source ‘IED_Intel::Suspects' to users affiliated to ‘UK’ with security clearance of 'NATO_SECRET'

Figure 4: Policy Authoring Tool showing the template definition for the example policy

The logical policy template parameterizes the data source, the user’s affiliation and the user’s security clearance to allow for variations of this policy to be deployed. Once a new policy template or templates have been ‘Authored’ the actual policies

5

to be deployed are constructed in SPL using the available parameters and then these are ‘Analyzed’ for logical consistency and coverage with any existing deployed policies. To do this the DDFD distributed policy repository is read to determine which policies are currently deployed and these are compared with the new policies. Once the user is satisfied that the set of new policies are consistent they are then deployed into the DDFD, by storing them into the local copy of the policy repository with and an associated timestamp into the local policy repository database table and set as active. In the current Gaian Database implementation these policies are read each time a new query is performed on any node in the DDFD. Other caching mechanisms are possible when the Gaian Database is being used on constrained bandwidth or high latency networks. Each policy plug-in uses the Watson Policy Management Library (WPML) for its policy evaluation infrastructure A PEP requests policy evaluations simply by providing a set of resources (i.e. Java instances) to an evaluate() method of the policy-evaluation engine that identifies the applicable policies, runs their evaluation and returns the Boolean result. If the PEP is an authorizer, then it is responsible for enforcing the result of the policy decision (e.g. restricting access). Figure 5 shows the SPL policy corresponding to the above example policy. Import Class com.ibm.watson.pml.policy.types.IAuthorizer:authoriz er; Import Class com.ibm.watson.pml.pfg.schema.QueryContext:query Context; Import Class com.ibm.watson.pml.pfg.schema.DataSource:dataSo urce; Strategy Execute_All_Applicable; Policy { Declaration { } Condition { dataSource.getDataSource() != "IED_Intel::Suspects" && ( queryContext.getAffiliation() != "UK" || queryContext.getSecurityClearance() != "NATO_SECRET" ) } Decision { authorizer.disallow() } }:1; Figure 5: SPL corresponding to the example policy

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < In this example the policy that requires confirmation of the user’s affiliation and security clearance. To obtain this the DDFD node must also be capable of performing user authentication. The current authentication mechanism makes use of public/private key encryption. Each node holds a list of authenticated User’s with their associated password, country affiliation and security clearance. When the user issues a query, a User id and password must also be specified for every node where the query would target protected data. This solution is clearly limited and a distributed certificate based authentication mechanism is being evaluated. V. RELATED WORK As database management systems have become more interconnected and able to seamlessly exchange information using standardized interfaces, privacy concerns have led to the development of various techniques for limiting the amount of information that is being shared. These techniques primarily focus on the modification of the original query that is submitted when data is requested, which is augmented with additional filtering constraints before being answered at the data source [10]. While this approach exhibits good performance, it is not as expressive when fine-grained control regarding the filtering of data is required, and requires extensions to the schema of the data source, in order to perform filtering based on the contextual information of the query. It is the latter reason for which we chose to implement an application-layer filtering mechanism through a transparent JDBC proxy. Data federation and information integration has been extensively studied (e.g. [11] [12]) over the past several years. To the best of our knowledge, only rudimentary operations for data filtering are provided, which do not possess the expressiveness of a full-fledged policy specification language such as SPL [8]. Recently, clustered JDBC proxies [13] have also been proposed for transparent data federation (although without any filtering capabilities). Our work builds on and extends this effort. Recent research efforts in the field of medical informatics and federated healthcare databases [14] as well as XML firewalls [15] explore filtering of data that is shared using the XML language for web services. Although very similar in terms of the end goal with our approach, the emphasis there is more on access control (allow/deny rules) rather than transformation of data based on policies, as enabled by the WPML library of our system. Moreover, they require the use of XML language for information exchange, as policies are also XML-based (XACML or X-GTRBAC). Policy refinement remains one of the most ambitious goals in policy-based security management as it aims to automate the realization of high-level requirements in executable implementations. This has yet to be accomplished in a generic fashion for dynamic, distributed systems. Similarly, policy analysis combining distribution and computational devices with limited resource constraints has not been attempted, although it

6

is critical for ad hoc coalition environments. VI. CONCLUSION As ISR networks of coalition forces deployed in joint missions need to interoperate and share information amongst them, controlling the flow of this information becomes a task of paramount importance. Control of information is typically expressed through policies that filter and transform the data that is being exchanged. In this paper we described a novel system that we developed for controlled data sharing through distributed policy enforcement. It features a distributed, federated database that employs a policy management library for evaluating and enforcing such policies. Policies can be deployed and enforced on any node of the network of federated gateway nodes, which offers maximum flexibility regarding deployment scenarios. Preliminary experiments of our prototype showed promising results regarding the performance and scalability of our design.

REFERENCES [1] [2]

International Technology Alliance - http://www.usukita.org/ Bent,G., Dantressangle P., Vyvyan,D., Mowshowitz, A., and Mitsou,V. "A dynamic distributed federated database." Second Annual Conference of ITA, Imperial College, London, September (2008). [3] Bent,G., Dantressangle P., Stone,P., Vyvyan,D., Mowshowitz, A., "Experimental Evaluation of the Performance and Scalability of a Dynamic Distributed Federated Database", 3rd Annual Conference of the ITA, University of Maryland, Washington, September (2009). [4] Beigi,M.S., Calo, S., Verma,D. "Policy Transformation Techniques in Policy-based Systems Management", IEEE Policy 2004, New-York, June (2004). [5] "Derby Database" http://db.apache.org/derby [6] Calo,S., Wood,D., Zerfos,P., Vyvyan,D., Dantressangle,P., Bent, G. "Technologies for Federation and Interoperation of Coalition Networks", 12th International Conference on Information Fusion, Seattle, Washington, July (2009). [7] Groovy - http://groovy.codehaus.org/ [8] "Distributed Management Task Force (DMTF), CIM Simplified Policy Language (CIM-SPL)", Document Number DSP0231, Jan. (2007) [9] "Apache Imperius Incubator project" http://incubator.apache.org/imperius/ [10] Wang,Q., Yu,T., Li,N., Lobo,J., Bertino,E., Irwin,K. and Byun,J-W. "On the Correctness Criteria of Fine-Grained Access Control in Relational Databases", in VLDB'07, Vienna, Austria, (2008) [11] Stonebraker,M. and Wong,E. "Access Control in a Relational Database Management System by Query Modification", in Proc. of SIGMOD'74, (1974)