ENCORE: TOWARDS A HOLISTIC APPROACH TO PRIVACY

Nick Papanikolaou, Sadie Creese, Michael Goldsmith

International Digital Laboratory, University of Warwick, U.K.

Marco Casassa Mont, Siani Pearson

Systems Security Lab, Hewlett Packard Laboratories, Bristol, U.K.

Keywords: Privacy policies, Policy hierarchy, Policy refinement.

Abstract: We make the case for an integrated approach to privacy management within organisations. Current

approaches to privacy management are either too high-level, enforcing privacy of personal data using legal

compliance, risk and impact assessments, or too low-level, focusing only on the technical implementation of

access controls to personal data held by an enterprise. High-level approaches tend to address privacy as an

afterthought in ordinary business practice, and involve ad hoc enforcement practices; low-level approaches

often leave out important legal and business considerations. As part of the EnCoRe project we are

developing a methodology which tries to bridge the gap between privacy risk and impact assessment with

the technical management of privacy policies. We are working to define a conceptual model as a means of

expressing policy requirements as well as users’ privacy preferences and as a way to bridge the gap

described above. We aim to show the value of this approach in collaborative case studies (including

corporate personnel management, biobanks and assisted living) in the context of the EnCoRe project.

1 INTRODUCTION

Enterprises manage and administer huge databases

of personal data which are collected as part of

normal business practice. This process is complex

and involves meeting a wide range of requirements,

including the need to satisfy data protection laws

and privacy.

There is not yet a unified view of the different

approaches to policies existing in an enterprise. In

general there are two extreme approaches to

management and enforcement of privacy policies.

There is firstly a pragmatic approach, mostly

driven by risk assessment and risk management and

tailored to current business practices. It involves

identifying suitable high level policies and points to

act on, but then typically requires the deployment of

pragmatic control points, which are very dependent

on the specific scenario/environment. In particular,

the control points enforcing policies are often

hardcoded within applications and services in an ad-

hoc way, and so cannot be easily reused in different

scenarios and organisational contexts. This makes it

very expensive to reuse with other applications.

However, this seems to be the norm in business

practice today.

On the other hand, researchers often focus

instead on a purely technical approach and narrowly

propose yet another language or formal model for

security, access control or obligations without taking

into account legal, business and operational

requirements.

Hence, related policy languages might be too

generic or detached from real requirements. What

happens is that often these languages and models are

of interest to the research community but seldom

widely adopted in real environments.

We believe that there is a major gap between the

two approaches and that there is a unique

opportunity to combine aspects of each and provide

mechanisms to bridge and provide continuity. Risk

assessment and privacy impact assessment can help

to identify threats and explore mitigations by means

of suitable controls and related high-level policies.

We believe that a conceptual model of these high-

level policies enables reasoning about them and

supports their refinement and mapping into low-

level technical policies for practical enforcement in

171

Papanikolaou N., Creese S., Goldsmith M., Casassa Mont M. and Pearson S. (2010).

ENCORE: TOWARDS A HOLISTIC APPROACH TO PRIVACY.

In Proceedings of the International Conference on Security and Cryptography, pages 171-176

DOI: 10.5220/0002987501710176

 SciTePress

an IT information system. In the EnCoRe

(“Ensuring Consent and Revocation”) project, we

are exploring this approach while specifically

focusing on an important aspect of privacy: the

management of users’ preferences with regard to the

handling of their personal data (their expressions of

consent and revocation).

Based on this position, our general approach is as

follows:

1. Policies regarding the handling of personal

data may be represented at different levels of

abstractions within an enterprise, and so a unified,

conceptual representation which allows us to

compare and integrate them is desirable;

2. Current policy management approaches, tools

and representations are suited only to particular

classes of policies within this hierarchy, and so we

aim to define approaches which bridge levels from

legal requirements all the way down to technically

implementable privacy and security policy;

3. When handling policies we want to take into

account privacy preferences expressed by data

subjects (end-users) and enforce them, hence

enabling a user-centric perspective to privacy.

4. We envisage the need for a formal access

control model embodying policy and preference

concepts which enables reasoning from an abstract

level (including legal, social and business aspects) to

a technical, implementable level.

The different levels of privacy policies and their

key characteristics are discussed in section 2.

Section 3 analyses the pros and cons of current

approaches to privacy management and proposes a

hybrid approach to the development and

enforcement of privacy policies, which takes into

account:

• legal, security and business requirements,

• the outcomes of risk and privacy impact

assessment,

• what is feasible technologically.

Section 4 discusses different levels of policy

representations and illustrates the neeed to move

towards a unified conceptual model, which should

formalise the elements of policies in the hierarchy.

This is presented in the context of a practical

example of policy enforcement for consent and

revocation. Section 5 summarises these ideas and

concludes.

See www.encore-project.info.

2 POLICY LAYERS IN

ENTERPRISES

As discussed above, organisations need to cope with

a variety of policies and constraints at different

levels of abstraction, dictated by legal, social,

business and individuals. This includes security and

privacy requirements as well as data subjects’ (end-

users’) preferences.

At the highest level of the hierarchy, there is a

set of requirements which are set out by

international agreements and directives, such as the

European Data Protection Directive or the EU Safe

Harbour agreement. Further, many countries have

national data protection legislation, such as the Data

Protection Act 1998 in the UK, or the HIPAA,

GLBA, SB 1386, COPPA and various State Breach

laws in US. With regards to regulation in particular,

there are export and transborder flow restrictions on

personal data that need to be enforced. Privacy laws

and regulations constitute the topmost layers of

policy hierarchy regarding personal data with which

an enterprise must comply. Such policies are often

expressed in natural language as is typically the case

with related data subjects’ preferences.

At this high level of abstraction, security

requirements may include adherence to the

Sarbanes-Oxley Act (SOX) for financial reporting,

or the PCI Data Security Standard (DSS). These may

be refined to a set of policies at a lower level.

Similarly, business requirements include contractual

obligations, information lifecycle policies and the

enterprise’s own internal guidelines. All of the

above influence how personal data is collected,

stored and administered.

At the lowest level there are various operational,

technical policies that are machine readable and

enforceable by policy management frameworks.

This includes XACML, EPAL, P3P (Cranor et al.,

2006), P-RBAC (Ni et al., 2007), and other technical

policy languages.

Hence there are many levels of policies an

enterprise has to cope with. Ideally all these kinds of

policies should be managed and enforced

successfully, in such a way that their requirements

and stipulations are unambiguous and mutually

consistent.

In practice this can be difficult. However we

believe that by introducing a conceptual model, we

can bridge some of the disconnection between

higher and lower levels of policies.

We believe it is important to explore how to

build a conceptual model of policies bridging the

existing gaps. This involves investigating the

tradeoffs between pragmatism and generality of

policy representation approaches (so as to choose an

SECRYPT 2010 - International Conference on Security and Cryptography

172

approach that is neither overly pragmatic nor

narrowly technical) and taking into account all the

levels of policy pertaining to personal data including

legal, security and business angles.

The specific area of management of privacy

policies, security constraints, consent and revocation

(Casassa Mont et al., 2009) is of particular interest

because it is at the intersection of legislation, user

requirements and management of privacy & security

technical policies within and across organisations.

In this context, as shown in Figure 1, EnCoRe

aims to provide a solution that takes into account all

the different angles; the approach will not aim to

produce just a technical language for policies,

divorced from the realistic needs of businesses and

end-users. Rather, an assessment of risks and threats

will be made so that suitable privacy controls can be

devised. Privacy enforcement will aim to be

extensible and sufficiently general to handle a

number of different enterprise scenarios.

A wide variety of knowledge and (technical,

social and legal) expertise can be leveraged in

EnCoRe to define approaches to privacy policy

management at a legal level as well as at a technical

implementation level.

What is particularly desirable is to devise an

intermediate representation of policies that embodies

high-level requirements while being directly

translatable to (potentially existing) low-level

policies or access control languages such as

XACML. Such a representation should not be tied to

a particular implementation language. We aim to

achieve this goal as part of our EnCoRe objectives.

3 TOWARDS A CONCEPTUAL

MODEL FOR PRIVACY

POLICIES

Access control and privacy policies related to the

protection of personal data typically contain

stipulations about:

• for which purposes a data processor may collect

personal data

• which types of personal data are considered

sensitive, and hence are subject to additional

restrictions

• for how long collected personal data may be

held

• whether and how personal data may be shared

with third parties

• which actions a data processor must take in

case of a privacy breach

These reflect privacy principles that are common

to different levels of policies in the hierarchy

presented in Section 2. What is desirable is to have a

uniform conceptual representation of the policies

defined in the different layers. We consider here

some of the distinctive features of these different

types of policies, and for some we identify a general

format; this is precisely what is needed for a

conceptual representation. In future work we hope to

find the structures that are common to all the

different types of policies and to characterise them

in a formal manner.

An example of a high-level policy is the set of

data protection principles set out in the Data

Protection Act. These principles (paraphrased

versions of which follow) require that personal data

shall:

• Be processed fairly and lawfully and shall not

be processed unless certain conditions are met;

• Be obtained for a specified and lawful purpose

and shall not be processed in any manner

incompatible with that purpose;

• Be adequate, relevant and not excessive for

those purposes;

• Be accurate and, where necessary, kept up to

date;

• Not be kept for longer than is necessary for that

purpose;

• Be processed in accordance with the data

subject’s rights;

• Be kept secure from unauthorised or unlawful

processing and protected against accidental

loss, destruction or damage by using the

appropriate technical and organisational

measures;

• Not be transferred to a country or territory

outside the European Economic Area, unless

that country or territory ensures an adequate

level of protection for the rights and freedoms

of data subjects in relation to the processing of

personal data.

Such legislation may be translated into policies,

but for some of these, refinement and/or

interpretation will be necessary in order to translate

these into operational (technical) policies, and this is

easier to do with some policies than others. For

example, it is straightforward to do this with

notification requirements and some forms of

transborder data flow, but not for transparency and

adequacy requirements.

An example of a simple related privacy-aware

access control policies could be conceptually

expressed as an if...then...else rule:

Target: Personal Data D

if (Data Requestor wants to

access personal data D for

Purpose P)

and (data subject has given

ENCORE: TOWARDS A HOLISTIC APPROACH TO PRIVACY

173

consent for this data)

then Allow Access

else Deny Access

Similarly, for transborder data flow, rules may

also be represented in the same form, such as:

if (all source countries are

members of EEA and all target

countries are members of EEA)

then (no problems with

transborder data flow)

This type of rule is not an access control policy

or an obligation policy, but is a different type of

policy – a ‘compliance policy’.

Notice and notifications require checking for

“triggering” conditions and the context. Again, an

if...then rule could be used to capture these

concepts . For example:

if (<country legal entity

resides in> is member of

[Belgium, Portugal])

then (provide notification)

This is more like an obligation policy, but note

that it is not triggered by access control (Casassa

Mont, 2006). Another example would be that if there

were a data breach then it would be necessary to

notify the legal authorities and end users. This is an

obligation policy, of a type that is triggered by an

event.

The key point here is that it is possible to

identify some common patterns and concepts across

these types of policies along with intermediate

representations (e.g. rules) that are independent of

underlying technical policies but which may

nevertheless be fairly directly mapped onto these.

A similar analysis of policies can be made from

a business znd security perspective.

Business policies for example, relate to the

treatment of information throughout its lifecycle,

and that are also relevant to consider as background.

These include: availability and recovery time

policies, change control policies, binding contractual

arrangements with third parties, service level

agreements - SLAs) and IT governance policies.

Also in this category are internal guidelines (that can

map onto access control policies, obligation policies

and/or compliance policies), and contractual

obligations, which could relate to clauses included in

contracts with clients, or to information contained

within SLAs, etc.

Security requirements and related policies often

originate in information security standards dictating

methodologies and common security practices.

These include: PCI DSS, Standard of Good Practice

for Information Security, OCTAVE & CORAS

(these are risk management methodologies), ISO

27001/2 (an international standard outlining best

practices), BS 10012:2009 (British Standard

outlining best practices); DoD MIL-STD-1629A

(US Department of Defense risk management

methodology). Examples of requirements from PCI-

DSS are: restrict access to cardholder data by

business need to know; track and monitor all access

to network resources and cardholder data

Usually these security requirements dictate

constraints on who can do what on which protected

resource, given a specific context. Conceptually this

can be expressed in terms of access control policies:

Target: Resource X

if (Data Requestor is User

U/Role R in Context C)

then (Allow access to X)

else (Deny access)

At a conceptual level we notice similarities about

how to represent these constraints across different

domains.

In the specific case of management of personal

data, privacy and security concepts can be

conceptually bundled in a uniform representation.

For example, both privacy and security constraints

could be represented in the same

if...then...else rule model:

Target: Personal Data X

If (Data Requestor is User

U/Role R in Context C)

and (Data Requestor wants to

access personal data D for

Purpose P)

and (data subject has given

consent for this data)

then (Allow access to X)

else (Deny access)

The above examples are meant to show the value

of being able to explicitly and uniformly represent

the concepts and constraints involved in different

types of policies as a way to reason about them. We

believe that a conceptual model should provide a

way to consistently represent all these concepts

across different domains without the constraints

induced by any specific “technical” language.

To ensure continuity of the mapping between

different layers, these requirements and policies

need eventually to be mapped into enforceable

technical policies, for example in languages such as

XACML. This is where most of conceptual gaps can

be identified as well as limitations of current

technical approaches to policy languages. In the case

of technical policies, we need to take into account a

variety of details, for example where PII data and

data subjects’ preferences are stored, how to express

SECRYPT 2010 - International Conference on Security and Cryptography

174

constraints in a way that can be automatically

enforced, how to deal with consent and revocation,

etc. An example is given in the following diagram.

In this example, a basic privacy-aware access

control policy (in a “pseudo” conceptual

representation) could look like the following:

Target: <Database:DB1,

Table:T1>

if (DataRequestor.role is

“employee” and

DataRequestor.intent is

“Marketing”)

then ((Allow access to

T1.Condition, T1.Diagnosis)

& Enforce (Consent))

else if (DataRequestor.intent

is “Research”)

then

(Allow access to T1.Diagnosis)

& Enforce (Consent))

else (Deny access)

This policy could be potentially mapped in

technical policies such as XACML. However, an

accurate analysis of the example policy above

(Casassa Mont et al., 2006) highlights that the

management of “conditional YES” is required i.e.

postponing the check of consent at the policy

enforcement point.

This cannot be easily achieved with the current

XACML representation. As a result, in the EnCoRe

project we had to “twist” the language and

framework to achieve the desired outcomes.

A conceptual representation of policies would

have enabled reasoning about them as well as the

identification of constraints to be satisfied by the

underlying levels.

What is desirable is to have a uniform

conceptual representation of the policies across the

different layers. In this section we have briefly

discussed some of the distinctive features of the

different types of policies, and for some we have

identified a potential conceptual format; this is a

first, initial step towards a full conceptual

representation. In future work we hope to find the

structures that are common to all the different types

of policies and to characterise them in a formal

manner. We have already developed elements of a

formal access control model for consent and

revocation that can be directly leveraged in this

work.

4 CONCLUSIONS

We have discussed in this paper issues to do with the

description, management and enforcement of

policies in organisations. Specifically we highlighted

the gap existing from a high-level approach to

policies driven by risk and privacy impact

assessment and low-level technical policies.

We strongly believe this gap needs to be filled to

enable continuity of requirements and constraints

across all these levels and enable proper

enforcement of policies. To achieve this we

proposed the adoption of a conceptual policy model,

to enable reasoning and mapping of concepts at

lower levels of abstraction.

In our analysis we illustrated the range of

corresponds to a different layer of abstraction) and

some of the related, distinctive requirements;

elements of a conceptual model which characterises

the properties of these different types of policy; first

thoughts on an access control model which might be

used to describe different types of policy rules in a

uniform way, with an emphasis on user preferences.

This is work in progress. A conceptual model is

going to be researched and developed in the context

of the EnCoRe project.

ACKNOWLEDGEMENTS

The position outlined in this paper is the result of

many fruitful interactions within the EnCoRe project

(see www.encore-project.info). We thank the project

sponsors – TSB, EPSRC and ESRC.

REFERENCES

Marco Casassa Mont (2006). On the Need to Explicitly

Manage Privacy Obligation Policies as Part of Good

Data Handling Practices. Proceedings ofW3C

Workshop on Languages for Privacy Policy

Negotiation and Semantics-Driven Enforcement, 17-

18 October 2006, Ispra, Italy.

Marco Casassa Mont, Siani Pearson, Gina Kounga, Yun

Shen, and Pete Bramhall (2009). On the Management

of Consent and Revocation in Enterprises: Setting the

Context.Technical Report HPL-2009-49, HP Labs,

Bristol.

L. Cranor, B. Dobbs, S. Egelman, G. Hogben, J.

Humphrey, M. Langheinrich, M. Marchiori, M.

Presler-Marshall, J. M. Reagle, M. Schunter, D. A.

Stampley, and R. Wenning (2006). The Platform for

Privacy Preferences 1.1 (P3P1.1) Specification.

ENCORE: TOWARDS A HOLISTIC APPROACH TO PRIVACY

175

World Wide Web Consortium Note NOTEP3P11-

20061113.

Marco Casassa Mont, Robert Thyne, Privacy Policy

Enforcement in Enterprises with Identity Management

Solutions, PST 2006, 2006.

OASIS eXtensible Access Control Markup Language

(XACML). Standard available from

http://www.oasisopen.org/committees/tc_home.php?w

g_abbrev=xacml

Qun Ni, Alberto Trombetta, Elisa Bertino, and Jorge Lobo

(2007). Privacy-aware role based access control. In

Proceedings of the 12th ACM Symposium on Access

Control Models and Technologies (Sophia Antipolis,

France, June 20-22, 2007). ACM, New York, pp. 41-

50.

Rodolfo Ferrini, Elisa Bertino (2009). A Comprehensive

Approach for Solving Policy Heterogeneity. In ICEIS

2009 -Proceedings of the 11th International

Conference on Enterprise Information Systems (Milan,

Italy, May 6-10, 2009), pp. 63-68.

Ioannis Agrafiotis, Sadie Creese, Michael Goldsmith, and

Nikolaos Papanikolaou (2009). Reaching for Informed

Revocation: Shutting Off the Tap on Personal Data.

Proceedings of Fifth International Summer School on

Privacy and Identity Management for Life (Nice,

France, 7th – 11th September 2009).

SECRYPT 2010 - International Conference on Security and Cryptography

176