Additional Policy Use Cases/Requirements

Hi all.

I'd like to share two additional (high-level) policy use cases and related requirements.

------------
1) Privacy Policy Management - Use Case & Requirements

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 informations, 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, gudelines, 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 contraints 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 "compartimentalised" 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?

-----------
2) Federated Policy Management - Use Case & Requirements

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 polciies.

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?

It would help getting your input and thoughts, in particular in terms of  implications for policies, policies languages and policy frameworks.

Marco


________________________________


[http://www.hp.ca/corporate/signature/hp_logo.gif]<http://www.hp.com/>


Marco Casassa Mont
Senior Researcher
Hewlett-Packard Labs

+44 117 3128794 Phone
+44 117 3129250 Fax
marco_casassa-mont@hp.com<mailto:marco_casassa-mont@hp.com>
http://www.hpl.hp.com<http://www.hpl.hp.com/>

External Web Page: http://www.hpl.hp.com/personal/mcm/
Blog:   http://h20325.www2.hp.com/blogs/mcm

 'All points of view are my own and not necessarily HP's as well'
Hewlett-Packard Limited registered Office: Cain Road,      Bracknell,  Berks RG12 1HN Registered No: 690597 England

The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".

________________________________

Received on Wednesday, 23 January 2008 17:11:18 UTC