UseCases

Use Cases

This page provides a list of use cases of relevance to PLING. The aim is to analyse them, discuss related issues and identify requirements and needs.

USE CASE 1

Title: Policy Use Case

Author: Michael Wilson, STFC Rutherford Appleton Laboratory, UK

Description: I work in a government science laboratory where we provide large national facilities in the order of 100's of millions of dollars.

Researchers from universities use our large experimental facilities to analyse samples of stuff. They produce large data files which we store, and they may use our large compute facilities to further analyse. The resulting data is stored on our 5 Petabyte data store. People then want access to the raw or analysed data. The national funding body who has paid for the research has a data policy which states that the funded researchers, staff in the funding body and their reviewers should have access to the data for 3 years, but nobody else.

The researchers work in a university who have a data access policy that all researchers in the university should retain IPR on their data and not allow others access to it for 5 years. All researchers in the university have access to the data of all other researchers in the university in order to facilitate interdisciplinary research.

The pharmaceutical company who co-sponsor the research have a policy that although others can have access to the data, they are the only ones who can use the data for commercial purposes.

One researcher on the project is submitting part of the work to her university to acquire a PhD, and does not want any body else, even in the university, to see it. Our own facilities organisation has a policy that our staff can have access to the data produced on our facilities for administration and for use in developing the facilities.

These policies need to be encoded in a policy language that a PEP can enforce, and conflicts and priorities can be resolved by a PDP.

I've not tried to define the roles precisely in an ontological manner since they arise from different bodies who have not agreed on compatible definitions. The durations are defined precisely because lawyers are accustomed to these. The data sets themselves are not defined precisely in the agreements since they are too technical to be well understood by the lawyers, or too poorly defined by the researchers.

The legal agreements include this style of authorisation limitation, and sometimes also include penalty clauses defining actions to be taken in breach of these conditions which go beyond the XACML or SAML descriptions - e.g. if x tries to access data sets to which they are not authorised then they will lose their authorisation on all data sets.

We provide a Web Service interface to a data portal for users, funders, commercial sponsors, administrators etc.., to access the data. How do we represent these various policies given the legal text in English, identify conflicts between them, priorities the policies where conflicts exist (ok, that's out of scope) and enforce the right policy in the PEP?

Comments

[Marco Casassa Mont, HP Labs]

Michael, thanks for sharing your use case and related requirements with us.

I understand that some of the key aspects of your use case and requirements are:

• "access" to data depends on the context, including people roles, involved institutions, intent/purpose, nature of data, etc.
• time-based constraints on data retention/access
• potential conflicts between policies defined by different stakeholders
• relevace of the legal/legislative framework
• need to formalise all these aspects in policies in a framework involving policy decision making and enforcement
• need to create awareness and handle penalty clauses

In my view, this is an interesting use case, where a blend of security and privacy policies need to be properly represented and enforced on personal/sensitive data. Further "complexity" is introduced by the need to comply with legislation and deal with the "multiparty" nature of this scenario, where competing policies exist and conflicts could arise.

Does anybody else would like to add their input and/or comments to this use case?

USE CASE 2

Title: Privacy Policy Management - Use Case

Author: Marco Casassa Mont, HP Labs, UK

Description: A recurrent use case that I came across in various contexts (EU PRIME Project, interactions with customers, etc.) is how to use policies to deal with privacy enforcement and compliance checking in organisational contexts. This is pretty much consistent with some of the points already highlighted in Michael Wilson's use case.

Organisations and enterprises collect a lot of personal data and sensitive information, in order to enable their businesses. In doing this, they need to comply with laws, legislation (HIPAA, COPPA, EU Data Protection, etc.) standards of business conduct, guidelines, etc.

Threw key aspects are of interest: (a) policy representation (b) enforcement of (privacy) policies (c) policy compliance checking

Basic privacy constraints require handling users' consent, allowing access to the data only for agreed purposes and managing the lifecycle (e.g. data transformation, minimisation, deletion, etc.) of personal data driven by privacy principles. However, also other aspects such has security and business constraints need to be kept into account.

Personal data can be stored in a variety of data repositories (databases, LDAP directories, file systems, etc.) and be accesses by people, applications, services. This data can be processed and disclosed to third parties.

A "blend" of personal preferences, business, security and privacy constraints need to be kept into account into "policies" dictating how to access, use process and disclose this information.

Some common requirements that I came across are:

- need for more "integration" of business, security and privacy policies - need to leverage state-of-the-art Identity Management solutions (that might use, in some cases, proprietary/ad-hoc policy languages ...) - need to measure and demonstrate compliance to guidelines, laws and legislation

Policies (and policy management frameworks) can play a key role to deal with privacy enforcement and compliance checking tasks. However, one of the current limitations is that these aspects are currently addressed in a "compartmentalised" way, by using different policy languages and policy management systems (for security, privacy, etc.) that do not interoperate i.e. act in stand-alone ways. This creates issues in terms of alignment of policies, their consistency and overall impact.

How to make progress by recognising than on one hand there are multiple policy languages and policy management systems and, on the other hand, more coordination and integration is required?

USE CASE 3

Title: Federated Policy Management - Use Case

Author: Marco Casassa Mont, HP Labs, UK

Description: This use case is, in some way, a generalisation of the previous one: I came across it both in enterprise and telecom contexts.

An enterprise/organisation uses a broad variety of IT tools and solutions. The enterprise IT infrastructure includes systems, tools and solutions deployed at different levels of abstractions: network, system, OS, information, application, service, business, etc. levels.

Many of the involved systems, tools and solutions are configured with and driven by "local policies", defined by using specific (sometimes ad-hoc ...) languages. These "local policies" are often the effect of (human-based) "refinements" and "deployments" of high level business/security/etc. policies. Different policies, policy decision points and policy enforcement points are used for security, business, privacy and other aspects.

- How to make sense of all of them? - How to ensure that their overall impact on the IT infrastructure is consistent with the high level policies and guidelines - How to understand what the impact of changes of "local policies" (let's say at network level or at the application level) is on the high level policies? - How to understand what the impact of changes of high-level policies is on some of these "local policies"?

This is what I call a "federated policy management" use case i.e. a use case where there is the need to understand and keep into account the overall set of policies deployed in an IT infrastructure and have an "integrated, coordinated and consistent" management of these policies.

In this use case many different policy languages are used, operating on different IT entities (at different levels of abstraction) and enforced by different policy enforcement points. It is unlikely that all these existing (local) policy languages are going to be replaced by a unique "comprehensive" language ...

Some requirements are about having a consistent "meta-representation/abstraction" of the core principles/aspects/constraints expressed by various "local policies" along with ways of defining dependencies and relationships between them.

This would help to better understand the overall heterogeneous set of operational policies, link them back to high-level policies and reason on top of it.

Did you come across similar use cases? What is your view?

USE CASE 4

Title: Location-based Access Control Policies and Privacy in Pervasive and Distributed Environments - Use Case

Author: Claudio A. Ardagna, University of Milan, Italy

Description: The diffusion and reliability that mobile technologies have achieved provide the means to exploit location information for improving current location-based services in a novel way. Location awareness supports an extended context of interaction for each user and resource in the environment, eventually modelling a number of spatial-temporal relationships among users and resources. In a location-aware environment, context is not the static situation of a predefined environment; rather, it is a dynamic part of the process of interacting with a changing environment, composed of mobile users and resources.

In the context of access control model and languages, the requester’s profile is not anymore the only thing that matters: context information and, in particular, physical location of users may also play an important role in determining access rights. The need of a Location-based Access Control (LBAC) model then arises. Location-based information now potentially available to access control modules includes the position and mobility of the requester when a certain access request is submitted. This kind of fine-grained context information potentially supports a new class of location-aware conditions regulating access to and fruition of resources. A requester then could be granted or denied access by validating location-based credentials. Main requirements regarding LBAC are:

• the integration of access control policies with location-based conditions, focusing on policies evaluation and enforcement challenges that such an extension to access control policies inevitably carries;
• when evaluating location-aware conditions, we need to consider that location-based information is radically different from other context-related knowledge inasmuch it is both approximate (all location systems have a margin of error) and time-variant (location is subject to fast changes, especially when the user is in motion).

The physical location of individuals is then rapidly becoming easily available as a class of personal information that can be processed for providing a new wave of online and mobile services, such as, Location-based Access Control service. As an effect, however, privacy concerns are increasing, calling for more sophisticated solutions for providing users with different and manageable levels of privacy. Threats to personal privacy in fact are ramping up, as witnessed by recent security incidents targeting privacy of individuals, revealed faulty data management practices, and unauthorized trading of users personal information (including ID thefts and unauthorized profiling). Location information is not immune from such threats and presents new dangers such as stalking or physical harassment. In such a scenario, the lack of location privacy protection could result in severe consequences that make users the target of fraudulent attacks:

• unsolicited advertising, the location of the user could be exploited, without her consent, to provide advertisements of products and services available nearby the user position;
• physical attacks or harassment, the location of the user could be used to carry physical assaults to individuals;
• users profiling, the location of the user, which intrinsically carries personal information, could be used to infer other sensitive information such as state of health, personal habits, professional duties, and the like;
• denial of service, the location of the user could be used to deny accesses to services under some circumstances.

The problem of protecting location privacy of the users by providing a comprehensive solution aimed at preserving location privacy of individuals through artificial perturbations of location information collected by sensing technologies arises. An important requirement of solutions trying to protect location privacy is to strike a balance between the need of service providers, requiring a certain level of location accuracy for high-quality service provisioning, and the need of users, asking to minimize the disclosure of personal location information. Three different classes of location privacy solutions have been introduced in the past: anonymity-based, obfuscation-based, and policy-based. Anonymity-based solutions have been primarily defined to protect identity privacy and then the link between location information and users identity. Obfuscation-based solution are well suited for position protection. Policy-based techniques are in general suitable for protecting both identity and location information of the users. However, they are usually difficult to understand and manage for end users.

How can we address the requirements introduced by a LBAC scenario and at the same time the need of solutions to protect the privacy of location information, still preserving a level of accuracy?

USE CASE 5

Title: Portable Access Control Policies for Social Networks (and other Web 2.0 scenarios)

Author: Giles Hogben, European Network and Information Security Agency

Description:Users need to be able to set preferences such as who can tag photos with their profile, which of their friends can and cannot access profile information (which is now possible on Facebook for example). Users need to be able to export their profiles AND the preferences they set on who can access what.

A further step would be that data would be stored encrypted in service provider stores and only decrypted (and read) by designated people in the person's social network.

All this needs portable profile data and alongside that, portable access control policies which travel with it.

USE CASE 6

Title: Authentication Strength Policies

Author: Giles Hogben, European Network and Information Security Agency

Description:Governments and companies operating remote authentication systems often need to set machine readable policies (or even human readable policies used within organisations), specifying the minimum strength of authentication tokens required to access a service. Other features of the authentication context (as it is called in SAML) are also of interest such as the linkability features of the tokens used, and the registration and issuance procedures which surround how the token is bound to the person's identity.

Many proposals abound for sets of levels describing authentication strength, but there is no standardisation in this area as yet.

USE CASE 7

Title: Corporate Security Policies

Author: Giles Hogben, European Network and Information Security Agency

Description: We see a need for a common format for sharing controls used in corporate security policies. Obviously no company would want to disclose their internal security policy, but they would want to be able to view and modify standard expressions of security policies. This would facilitate certification bodies to apply standard evaluation procedures.

USE CASE 8

Title: Selective violation of same origin policy

Author: Giles Hogben, European Network and Information Security Agency

Description: Web 2.0 developers often work hard to circumvent same-origin policies. This is a growing imperative in Web 2.0 applications. Better than workarounds would be a language to formalise conditions under which this policy can be violated.

USE CASE 9

Title: Service providers after functional separation in incumbent Telecom operators.

Author: Jean-Pierre Le Rouzic, R&D engineer at Orange labs France/Rennes

Description: For telecom providers in Europe some things could change in next years if there is a functional separation between networks and services units. This is already done in UK and will perhaps happen soon in Poland. This functional separation could help new telecom service competitors to develop and even lower the cost to create a new Telecom competitor. So it's a good thing from the point of view of the end user.

For the service providers resulting from such splits, it will be out of questions to behave as MVNO as they must differentiate heavily from competitors. In effect MVNO completely relies on other operators to implement the service they propose to their users. New service providers will certainly help new local or specialized network operators to emerge from WIFI hot spot trough merging and ask to use large corporate intranets to have an alternative to use the unique Network provider. So the service provider may use a different network infrastructure on a day to day basis based on user behaviour and market prices. So for the service operator there is a need to have a very agile Information system that is also quite secure and privacy friendly for end users.

This is actually quite close to the "In the cloud" proposal, as the networks operators in my description are "the cloud" for the service operator and they must offer a service without being able to gather information about users, and the service must stay compliant to the user contract while being offered by a changing configuration of networks.

Security problems:

• User to Service provider: The user should be reasonably sure that she is connected to the service provider; this is not as simple as it seems, DNS are often provided by network providers and they could be altered.

• User to Network provider: The user must be sure she will charge in conformance to the contract with the service operator, not by the network operator. The network operator must be sure it will be paid.

• Service provider to network provider: SLA and QoS must be negotiated and rewards and penalties are enforceable.

Privacy problems

• User to Service provider: The user should be reasonably sure that some personal information such as she is a customer of such or such large corporate should not leak to the service provider in case the service provider uses the corporate intranet as a transport channel. The user must be reasonably sure that network information related to her are not masqueraded or changed by the network operator while sent to the service operator.

• User to Network provider: Anonymity, Integrity and confidentiality of data transported probably need for encrypting as network providers will try to use Deep Packet Inspection to gather a better knowledge of the user to monetize it.

• Service provider to network provider: The business model of the Service provider should not be understandable by the network provider. For example data such as which type of customers, volumes or final prices should be hidden to the other party. It goes the other way round also.