Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The problem of enforcing policies about what can and what must not happen to specific data items is ubiquitous. Different enforcement infrastructures, both generic [1] and specific [2], have been proposed. The configuration of these infrastructures requires technical implementation-level policies (ILPs). End users, however, often cannot directly specify ILPs but require a higher level of abstraction, that of specification-level policies (SLPs). The problem we tackle in this paper is the automatic derivation of ILPs from SLPs. We show how to translate SLPs written in OSL [3] to ILPs that come as ECA rules [4].

The object of data usage control enforcement is abstract data (photo, song etc.), that we need to distinguish from concrete technical representations called containers (specific files, dom elements etc.). Policies on data usually need to be interpreted as policies on all representations of that data. We therefore rely on a data flow model [5] that defines system states as mappings between data and containers at a moment in time. The transition relation on states is the change in these mappings. Policy enforcement on data is done on the basis of data flow tracking which is monitored on grounds of the transition relation [5].

Because data and actions on data are specific to an application domain, a three-layered domain meta-model for refining data and actions has been proposed in [6]. This meta-model (Fig. 1) describes a domain to be composed of classes of data and actions at the end user’s level (platform-independent model: PIM), both of which are refined in terms of classes of technical concepts (platform-specific model: PSM) and classes of various implementations of them (implementation-specific model: ISM) at the lower levels in the meta-model. The refinement of user action and data is given by the vertical mappings between the model elements (data classes mapped to container classes and action classes mapped to transformer classes which are further mapped to other classes of containers and transformers at the PSM and the ISM levels). Figure 2 (taken from [7]) shows an example instance of the meta-model in Fig. 1 that refines “copy photo” in different ways in an Online Social Network (OSN).

The formal semantics of the refinements are given by combining the domain meta-model with the aforementioned data flow model. Policies are derived using this formal action refinement. The detailed formalism is described in [7].

Running Example. In an OSN implementation, user Alice wants to specify and enforce a policy “friends must never copy this data” for her photos, without any technical knowledge. We will refer to this SLP and the action refinement in Fig. 2 throughout this paper. In Sect. 3, we describe the technicalities of one implementation that helps Alice prevent her friends from copying her photos.

Fig. 1.
figure 1

The Domain Meta-model

Full size image
Fig. 2.
figure 2

An OSN instance of Fig. 1

Full size image

Contribution. This paper presents a generic methodology for automating policy derivation for usage control enforcement. A proof of concept is realized for a specific context (i.e. OSN). However, the approach is generic and can be applied to any other domain model.

2 The Generic Approach to Policy Derivation

Connecting Instances to Classes. The domain model specifies general classes of data. A specific policy is concerned with specific data items, which we need to connect to the classes in the domain model. Conceptually, we use a generic function \( getClass \) for this. The definition of the \( getClass \) function varies according to the application domain. We illustrate this with a simple example: In the OSN context, a specific image (data d) can be a profile photo, logo, banner or a cover photo (data classes). Different data classes might mean different storage and different technical refinements of the instances. E.g. (small) logos stored as blobs vs. (large) photos stored as links in a table. Relevant data classes and assignment of data elements to one or many of them is intuitive and is driven by the domain design and its implementation. This is because data classes describe how users understand different types of data in a particular context and there is no universal rule for classifying them. However, for a given context, it is easy to define \( getClass \). In Sect. 3 we show how this can be done for a particular case.

The Policy Derivation Methodology. Although end users would like to specify security requirements, in particular usage control policies [8], they are in general not capable of reasoning holistically about such policies [9]. This motivates the need for a policy specification and derivation framework that requires simple and limited user input for the specification of usage control policies. Our policy derivation approach is based on policy templates that are classes of policies. Human intervention is in two roles: a technical expert called the power user specifies the domain model and other configurations, using which, an end user specifies and automatically translates and deploys the policies. The power user only configures the policy derivation at the start, no further human intervention is needed. Policies are automatically derived in the following five steps:

Step 1: Setting up the Policy Derivation. The power user specifies the domain model used for action refinement. The power user also specifies two types of policy templates: a first set of templates for the SLPs, to be instantiated by an end user for each data element to be protected. We studied several application domains and recognized that most relevant usage control policies could be specified using limited combinations of OSL operators. Based on this, we came up with classes of SLPs that specify constraints upon classes of data and actions. As one SLP can be enforced in several ways [4], the second set of templates specifies enforcement strategies for each class of SLPs. E.g. a company enforces a policy “don’t copy document” by inhibition because the company wants to prevent data leakage and its infrastructure supports it; or, a film producer enforces “don’t play unpaid videos” by allowing corresponding events with a lower quality video because either it’s technically not feasible to inhibit the events or he wants to give a limited preview to its prospective customers. As the reasons for deciding upon an enforcement strategy don’t change very often, it is reasonable to specify the enforcement strategy for ECA rules generation in a template in order to automate the process.

Step 2: Policy Specification. End users instantiate the policy classes using templates to specify data elements, actions and other constraints like time, cardinality etc. (e.g. max. copies allowed, min. payable amount, currency etc.).

Step 3: Policy Derivation. First, we get the class of data addressed in the policy using \( getClass \). Then, data and actions are refined according to the formal policy derivation described in [7] and the resulting OSL formulas are converted into ECA rules using predefined templates.

Step 4: Connecting Data and Container. As such, data does not exist in real world, except in the mind of the humans who want to protect or abuse it. In real systems, only corresponding containers exist. Therefore, an end user writes policies on containers and specifies if he means to address the data in that container (i.e. all copies of the container) or the container itself. This is done by specifying the policy type in the SLP. Conceptually, data enters a system in an initial container and gets a data ID assigned. This process of initially mapping containers to data is called the initial binding of data and container. After the initial binding, policies that are finally deployed for enforcement are of two types: dataOnly policies apply to all representations of data at and across layers of abstraction in a machine while containerOnly policies apply to the specific container mentioned in the policy.

Step 5: Adding Context-Specific Details. According to the domain and its implementation, there are many context details that might be added to the ECA rules before deployment. E.g. policies in an OSN might address specific users and their relationships to the profile owner, and this information is known only at runtime by identifying the browsing session. Together, step 4 and 5 are called policy instantiation and they might be switched in order, depending upon the context detail to be added and the corresponding system implementation.

Generic Architecture: We build upon an existing generic usage control infrastructure with three main components: a Policy Enforcement Point (PEP), able to observe, intercept, possibly modify and generate events in the system; a Policy Decision Point (PDP), representing the core of the usage control monitoring logic; and a Policy Information Point (PIP), which provides the data-container mapping to the PDP [5]. This infrastructure was extended with a Policy Management Point (PMP) with a dedicated sub-component, the Policy Translation Point (PTP) for policy derivation using action refinement. Policy specification, instantiation and deployment is handled by the PMP.

During policy enforcement, when an event is intercepted and notified by the PEP to the PDP, the object parameter is always a container as only concrete containers exist in running systems. For a dataOnly policy, the PDP queries the PIP for the data-container mapping before deciding upon the enforcement mechanism. In case of containerOnly policies, the PDP needs no communication with the PIP as the policy and the event notification address containers.

3 Implementation and Evaluation

We instantiated the generic architecture to derive policies for the online social network SCUTA, which already had basic usage control capabilities [2]. We extended SCUTA with two types of policy specification for two classes of end users. As shown in Fig. 3, basic users only specify how sensitive they consider a particular data. Based on the sensitivity rating and a predefined trust model, SLPs are generated by the system on behalf of the user (for details, see [2]). Advanced Users specify their policies by instantiating admin-defined SLP templates that are loaded every time the page is requested. In Fig. 3, we also see an SLP template in edit mode.

In our attacker model, all the policies protect end users’ data from misuse by other social network users. The SCUTA provider is trusted. SLPs are specified by Alice. They are translated at the data receiver Bob’s end, to be enforced at two layers of abstraction in the system: Mozilla Firefox web browser [2] and Windows 7 operating system (for protecting cache files) [10].Footnote 1

Fig. 3.
figure 3

Screenshot of SCUTA showing basic and advanced policy specification

Full size image

Connecting instances to classes. In order to connect data elements to their classes, we used the database schema of SCUTA: the class of a data element is represented by the name of the table where that element is stored. E.g. an image stored in table “profile_photo” is a profile photo. As mentioned in Sect. 1, a data flow model is used to keep track of data in multiple containers. The data flow model of a particular system describes all sets of containers in that system. E.g., \( C_{File} \) is the set of all files in the data flow model of Windows 7. We reused this information in our implementation to connect containers to their classes, e.g., all members of \( C_{File} \) are of the type File.

Example Policy Derivation. Now we describe the derivation of our example policy introduced in Sect. 1: “friends must never copy this data”. Action refinement is based on the domain model shown in Fig. 2. The SLP templates (specified by the power user) and their instances (specified by end users) are stored in the SCUTA database. Figure 4 shows an example SLP template.

Fig. 4.
figure 4

An example SLP template, specified by the power user

Full size image

Each template is identified by an ID. The template text appears in the front end without the special character delimiters; the delimiters are used by the web application logic to create the GUI. Data class refers to the type of data for which the policy could be instantiated. Policy class is the XML representation of the template text with placeholders delimited by special symbols. In the GUI, the end user sees the template text with editable parts. When a template is instantiated, data and other parameter values substitute the placeholders. Generated policies are shown to the user as structured sentences in natural language.

Policy derivation and deployment is a one-click process. ECA templates are specified per SLP template. Listing 1.1 shows the ECA template (as a JSON object) for the SLP template shown in Fig. 4. Note how the template ID from Fig. 4 is used to connect the two templates. This ECA template states that in the generated ECA rule, the trigger event is a *-event which matches all events in the system; the condition comes from the action refinement whose input is the past form of the specified OSL policy; the action is to inhibit the event.

figure a
figure b

Using this ECA template, ECA rules are generated automatically. An ECA rule for the Firefox web browser is shown in Listing 1.3. The scope in line 3 of Listing 1.3 is added to the policy as part of the context information that identifies each logged-in SCUTA user (and his browsing session) uniquely. “cmd_copy” in line 6 comes from the refinement of copy action (Fig. 2). In line 7, “dataUsage” means that the container “9c73d9b7ff.jpg” is to be interpreted as data and substituted by a data ID.

figure c

Listing 1.2 shows another ECA template that generates ECA rules with “modify” enforcement strategy for the SLP template of Fig. 4: the action part says that the enforcement mechanism must replace the object in question by “icon/error.jpg”. One of the generated ECA rules is shown in Listing 1.4.

figure d

As we use templates for ECA rules generation, changing enforcement strategies is easy. The power user modifies the ECA templates and notifies the PMP for retranslating, revoking and deploying policies. In the current implementation, all deployed policies are overwritten. Modifying the PMP to selectively revoke and redeploy only those policies whose enforcement strategy has changed is trivial.

4 Related Work and Relevance

Policy derivation for access control has been investigated based on resource hierarchies [11], goal decomposition [12], action decomposition [13], data classification [14], ontology [15], etc. In usage control, several enforcements exist at and across different layers of abstraction in various types of systems [2, 3, 5, 16–18]. In all these implementations, the focus has been on the implementation of event monitors; policy derivation has not been addressed. While [19] describes an approach where high-level usage control policies are automatically refined to implementation-level policies using policy refinement rules, the refinement rules are specific to the domain in consideration. In contrast, the very idea of our work is a more generic approach that relies on instantiated domain meta models; this is the gap in usage control policy refinement that is filled by this work. A model-based semi-automated approach to usage control policy derivation is described in [6, 7]. We build on this work and achieve automated policy derivation.

5 Conclusions and Future Work

This paper provides a methodology for automating usage control policy derivation. We have also proposed the usage of policy templates in order to enable end users to specify usage control policies without having to know the underlying policy language. We do not propose any concrete syntax or design for the templates. We have deliberately kept our implementation of the templates simple with user inputs limited to multiple-choice format. In principle, policy templates could be written in XML, in plain structured text, in simple graphical format with dropdowns and checkboxes or, in advanced graphical format by dragging and connecting different blocks to write policies (along the lines of MIT Open Blocks). Policies could also be specified using free text in any natural language or standardized solutions like ODRLC (a translation from OSL to ODRLC and vice versa is shown in [3]). Also, technically-proficient users can write policies directly at the implementation level. This work does not exclude such possibility.

One limitation of this work is the static domain structure. This is a deliberately introduced limitation which does not affect the automation of policy derivation, which was the goal of this work. This limitation is being addressed in ongoing work and is therefore out of the scope of this paper.