Advances in three aspects of computing, namely reachability, pervasiveness, and autonomy, lead to highly dynamic systems, whose components increasingly manage themselves. However, their security and trustworthiness must always be evaluated in the user's context and in tight association with his personal goals and current preferences. Therefore, this paper defines an operator for policies to determine the difference in policies. This policy operator enables the user to check for additional permissions that would come along with the acceptance of a new or modified policy and can assist him in estimating the risk he puts his security or privacy in before adopting it.
The growing potential to combine devices with different capabilities and purposes has led to the development of densely networked, decentralized systems. In these systems, components are becoming increasingly autonomous; they avidly collect data in various forms and adapt to their environment as well as to the users’ requirements. Their changing and possibly conflicting demands lead to a continuous negotiation of requirements and ad hoc relationships. These features lay the technical foundation for highly dynamic systems and, thus, for a plethora of new applications building up an infrastructure of services.
When utilized for delivering tailored services to improve
customer relationship in a future supermarket [
As such systems are continuously becoming an essential feature of everyday life, the consideration of their security and privacy management is highly important. The acceptance of these systems is greatly affected by the capability of the user to keep control over the usage of his personal resources and to observe the systems’ adherence to his preferences.
The ability of autonomous components to operate independently without constant human supervision and their adaptation to current context by automated reconfiguration seem to push the user out of the control loop. For their management, the user interaction appears to be dispensable.
Yet, it is important to realize that the evaluation of security and privacy risks cannot be an issue for those expert security administrators alone, who set up some default guards constraining the system’s behavior. Although the border of automation will be moved in such environments, the user cannot be completely released from the responsibility of formulating his goals and preferences as a personal security policy. Trustworthiness and risks cannot exclusively be assessed by central administrators, especially when his privacy is endangered.
Hence, the user needs to transfer his own policy stored on a suitable communication device, such as a personal PDA, to the system. However, his policy will often not be the only clincher for the system’s security decisions. If there is a set of global security rules in place guarding the environment, the user will not be able to overrule it. The system will more likely incorporate the user’s policy and subordinate its rules to the global ones. Similarly, the resulting policy shared by the system components may be a conjunction of multiple user policies, if the system is used by more than one user at the same time.
In consequence, the high dynamics of such systems forbid
this shared policy to be permanently determined and,
therefore, to be analyzed for the components’ security behavior in
advance (technical or legal policy enforcement is not within
the scope of this paper; e.g. see [
More importantly, users are often unable to predict even
their own future behavior. As surveys have shown, users
take a very pragmatic approach to security. Willing to make
security and privacy trade-offs according to the current
situation or to the current communication partners, they adapt
their own policies or spontaneously commit their resources
and personal data to a foreign one to reflect the dynamics
of such systems [
Since users who have a method to observe and preview the
result of their interaction make significantly less
securityrelated operating errors [
Usage control policies integrate the diverse security
policy concepts into a unified policy model [
For better understanding of the next section, some
properties of the abstract syntax and semantic of EPAL are
presented, but definitively without the claim of
completeness. Hierarchies for users U , data D, purposes P and
actions A build the vocabulary V oc together with conditions
C(V ar), and obligations O. Similar to hierarchies, an
obligation model defines an imply-relation on the power set of
all obligations indicating that fulfilling a set of obligations
implies fulfilling all of its subsets. Given a vocabulary, a
policy P = (V oc, R, gc, dr, do) consists of a global enabler
gc ∈ C(V ar), the default dr of ruling r ∈ {+, ◦, −}
according to “allow”, “do not care”, and “deny”, a set of
default obligations do, and an ordered list of rules R ∈
{U × D × P × A × C(V ar) × r × ℘(O)}. A rule matches a
request q ∈ {U × D × P × A}, if its conditions are satisfied
by the given assignment χ of environment variables, and all
elements of the request are equal to or children of their rule
counterparts. The first matching rule in P gives the result
evalP (q, χ) = (r, o). For a complete specification, see [
Whenever the user wants to update his own policy, or the shared system policy is to be changed, e.g. by merging it with a new personal one, the user is faced with the question of whether to accept this new policy version or to decline it and, perhaps, enter a further round of negotiation.
For this decision, both old and new policy versions are to be compared with each other. If the new version is equivalent to or even more restrictive than the old one, an automated process can be used to indicate acceptance. What happens, however, if none of these checks is positive, and the new version is more permissive? In this case, the user needs to be called in to decide on further actions. To prevent him from being overwhelmed by complex policy sets, the difference in the new and old policy reveals to him only those permissions granted by the former, but not by the latter, i.e. a reduction to only those permissions relevant for consideration at this time.
Taking up the shop example, a non-empty difference indicates to the customer the extra permission that is not covered by the regulations P1 he has set for the treatment of his data, but that the shop demands for the usage and tailoring of its services (cf. Fig. 1(a)). Otherwise, he can verify by an empty difference that the shop’s policy P2 is more restrictive and, thus, safe to use (cf. Fig. 1(b)).
Fig. 2 shows an example reduced to the consideration of the data hierarchy: P1 allows some actions on data D1, whereas P2 allows the same actions on D2 and D4. Computing the difference, written P2−1, reveals that P2 extends the permission to D2 and its children D5 and D6, but not to D4, as it is already covered by the permission on D1 by P1. From the user’s point of view, the permission on D1 and D3 taken by P2 (i.e. P1−2) are not of primary interest, because no possibly unintended permission is inserted.
Owing to the limited space, we assume a single vocabulary
for both policies. In the style of [
A first implementation can be made using a brute force approach. One simply evaluates both input policies for any possible request q and any possible assignment χ and compares their rulings and obligation sets. A rule (q, C2, r2, o2) generated from a given q and χ is part of P2−1, if policy P1 is globally disabled and, therefore, not active in context χ, but P2 does not prohibit the requested action or commits the requester to future actions. For all other q and χ, the generated rules are part of the difference, unless o2 does not contain any new obligation and is a subset of o1. In this case, it is up to the comparison of the rulings only. If r1 is dominated by r2, i.e. r2 is more permissive, the corresponding rule is part of P2−1, too.
As this brute force approach tests all valid combinations of
requests and condition variables, their amount grows
exponentially with the number of vocabulary variables. Thus, a
more efficient algorithm is desired, e.g. by grouping requests
with the same matching rules or neglecting rules that will
always be hidden by matching rules with higher priority, as
Backes et al. propose for their efficient algorithm to test on
policy refinement [
Currently, the comparison of such policies is made by a
refinement check [
For the limited name-space of P3P, the Privacy Bird [
There is ongoing work on the evaluation of policy changes
and their compliance with meta rules, such as “separation
of duty” [
Finally, there is an approach using model checking with
dynamic logic [
In this paper, we put forward the user’s point of view on policies in dynamic systems. We argue that despite their autonomous behavior the components still need user’s supervision. While the user adapts his usage control policies over time, he needs support for observing the possible impact of the changes. For this, we define the difference between two policy versions, which reveals exactly those permissions additionally granted by the new policy.
This definition is just the first step in the direction of
usable policy management, and there is considerable work
to be done. First, an efficient algorithm for computing the
difference is to be developed. Subsequently, it will be
transfered to syntax and semantic of NAPS [