The Enterprise Privacy Authorization Language (EPAL)

- How to Enforce Privacy throughout an Enterprise

Paul Ashley, IBM Tivoli Software
Satoshi Hada, IBM Research
Günter Karjoth, IBM Research
Calvin Powers, IBM Tivoli Software
Matthias Schunter, IBM Research (mts@zurich.ibm.com; editor)

Abstract

Enterprises collect personal data while promising fair information practices to their customers. The Enterprise Privacy Authorization Language (EPAL) [4] enables an enterprise to formalize the exact privacy policy that shall be enforced within an enterprise. It formalizes the privacy promises into policies and associates a consented policy to each piece of collected data. This consented policy can then be used in access control decisions to enforce the privacy promises made.

Introduction

Consumer privacy[1] is a growing concern in the marketplace. While the concerns are most prominent for e-commerce, the privacy concerns for traditional transactions are increasing as well. Some enterprises are aware of these problems and of the market share they might loose if they do not implement proper privacy practices. As a consequence enterprises publish privacy statements that promise fair information practices[2].

Unfortunately, companies usually face the following problems:

Enterprises create stockpiles of personally identifiable information (PII[3]). Larger enterprises may not know what types of PII are collected and where it is stored.
Enterprises may neither know the consent a customer has given nor the legal regulations that apply to a specific customer record.

There are a number of risks to an enterprise if it does not manage its PII correctly. The main risks are:

Legislative Penalty: Recently there has been new privacy legislation enacted in many parts of the world. Most of these laws incorporate rules governing collection, use, retention and distribution of PII. It is up to an organization to ensure that it is compliant with any legislative requirements or industry regulations that apply to it.
Brand and Reputation Erosion: Business relationships are built on trust. Organizations that demonstrate good privacy practices can build trust. Organizations with poor privacy practices will alienate customers.
Lawsuits: Lawsuits against organizations that violate privacy regulations or promises are becoming more common. A quick search of the United States Federal Trade Commission Web Site [1] will find a number of companies that have both been charged by the FTC on privacy violations and that are under a class action lawsuit from their customers.

As a first step towards managing privacy effectively organizations publish privacy promises as text or P3P [2]. The P3P statements can be used by a P3P client (e.g. the Internet Explorer 6 web browser) to notify the user automatically whether the privacy policy of the enterprise matches that configured by the user. Although this is beneficial for stating an enterprise's privacy promises, enterprises do not have the privacy technology to enforce the promises throughout the enterprise. This has resulted in privacy violations being a common occurrence today, even from well meaning companies.

This article describes an approach towards enterprise-wide enforcement of the privacy promises. Its core is a new framework for managing collected personal data in a sensitive, trustworthy way. The framework, called the Enterprise Privacy Authorization Language (EPAL), enables enterprises to formalize and enforce privacy practices and to manage the consent of their customers.

The paper is set out as follows. The next section describes the requirements for managing private data in an enterprise. This includes five steps that we consider to be the core of privacy management. The following section outlines our new privacy policy language. The core of this language is the ability to define an enforceable privacy policy and implement it across an enterprise. We finish with a summary.

Implementing Privacy Management

For an enterprise to enforce its privacy promises and act as a custodian of their customer’s PII they need to implement the following phases:

Define an enterprise privacy policy. We have defined a new privacy policy language called EPAL for this purpose.
Deploy a policy to the IT systems that contain privacy sensitive information.
Record consent of end users to advertised privacy policy when they submit privacy sensitive data.
Enforce the privacy policy and create an audit trail of access to privacy sensitive information.
Generate both enterprise wide and individualized reports showing accesses to privacy sensitive information and their conformance to the governing privacy policy.

Figure 1 shows a high level architecture for implementing privacy management. The CPO (or one of her staff) defines the high level privacy policy using EPAL. This policy is at a high level to map to regulatory and industry requirements. Once the privacy policy is defined it is deployed across the IT systems that deal with PII data. This way the privacy policy can be enforced.

Figure 1: Implementing Privacy Management Using EPAL.

During submission of PII data, the privacy management system must create a submission record. Submission monitors will create the submission records. This data is a permanent record of when PII data was submitted by a person, what privacy policy version was in place at that time, and what the user’s preferences were.

Later, when the PII data is to be accessed for use by the enterprise, the privacy management enforcement monitors ensure that only data accesses are allowed that conform to the privacy policy. They also create access records that record which user accessed the data and for what purpose.

The combination of submission and enforcement monitors allow the enterprise to demonstrate that it is a good custodian of data and gives the enterprise some assurance that it is enforcing its stated privacy policy.

EPAL a New Privacy Policy Language

The Enterprise Privacy Authorization Language (EPAL) [4] is a language for formalizing enterprise-internal privacy practices[4]. Its core is an authorization scheme that defines whether certain actionss are allowed or not.

Requirements of fine-grained Privacy Policies

The exact syntax of the set of rules defining a privacy policy will depend on the language used. However, in general the policy contains the following elements:

Data Users: Data Users are used to classify individuals who are accessing or receiving data. Data Users are required in a privacy context, as privacy policies will depend on the relationship between the individual requesting data and in the individual who the data is about. For example, one type of Data User might be physician while another might be primary care physician.
Actions: Some privacy policies make distinctions about who can perform activities based on the action begin performed. For example, a policy might say that anyone in the company can create a customer record, but that only certain Data Users are allowed to read that record.
Data Categories:Privacy policies must define the types of data which the enterprise will be holding. Typically, the data types used in privacy policies are high-level descriptions of data, such as customer contact information. Detailed, low-level descriptions are not typically required in privacy policies.
Purposes: Data access requests are made for a specific purpose or purposes. This represents how the data is going to be used by the recipient. For example, the data may be used for marketing or for fulfilling the individual's order.
Conditions: Rules can be qualified based upon additional conditions. Often, legislation or privacy policies make statements based on specified conditions. For example, COPPA [3] imposes requirements on data received from persons less than 13 years of age. Another common condition is that the user must have consented before PII can be used for a particular purpose.
Obligations: A privacy policy may also state that when a certain access is allowed, the enterprise must take some additional steps. An example is that all accesses against a certain type of data for a given purpose must be logged. Another might be that PII must be deleted if its owner has not performed business with the enterprise for one year.

The elements are then used as the terminology to express privacy rules expressing what requested data accesses are allowed or denied, and under what conditions:

ALLOW [Data User] TO PERFORM [Action] ON [Data Type] FOR [Purpose] IF [Condition] AND CARRY OUT [Obligation].

or alternatively

DENY [Data User] TO PERFORM [Action] ON [Data Type] FOR [Purpose] IF [Condition] AND CARRY OUT [Obligation].

Details of the Language

The EPAL policy language categorizes the data an enterprise holds and the rules which govern the usage of data of each category. Since EPAL is designed to capture privacy policies in many areas of responsibility, the language cannot predefine the elements of a privacy policy. Therefore, an EPAL document either starts with definitions of the elements which are used to build the policy or else imports them from a base-policy.

An EPAL policy is essentially a set of privacy rules. A rule is a statement that includes a ruling, a data user, an action, a data category, and a purpose. A rule may also contain conditions and obligations. Each rule contains a precedence level.

A EPAL policy document consists of three main sections:

Policy Information: This is used to identify the policy. It consists of information such as Issuer, Version Number, Start Date, End Date, Replacement Policy Name, Replacement Policy Version.
Definitions: This defines all of the possible components that can be used in the following rules. Here is where Data Users, Data Categories, Purposes, Actions, Context Models, Conditions and Obligations are defined.
ALLOW or DENY: Rules to define whether Data Users are ALLOWed or DENYed to perform Action on Data Category for Purpose under Conditions.

The following examples show how EPAL is used to express privacy policy rules:

privacy policy (informal)	Allow a sales agent or a sales supervisor to collect a customer's data for order entry if the customer is older than 13 years of age and the customer has been notified of the privacy policy. Delete the data 3 years from now.
ruling	allow
user category	sales department
action	store
data category	customer-record
purpose	order-processing
condition	the customer is older than 13 years of age
obligation	delete the data 3 years from now

Rules are used to determine if a request is allowed or denied. A request contains a user category, an action, a data category, and a purpose. Continuing with the same enterprise as above, consider the following request.

request (informal)	A person acting as a sales agent and an employee requests to collect a customer's email for order entry.
user category	sales department
action	store
data category	customer-record
purpose	order-processing

The above rule allows the request, so the sales agent would be permitted to store the customer's contact information. Additional rules can then govern how this stored data may be used.

Here are some other examples showing the rules defined in XML:

Email can be used for the book-of-month club only if consent has been given and age is more than 13. In EPAL, this looks as follows (note that the condition is declared in the vocabulary part):

<rule id="rule1" ruling="allow">
<data-user id="borderless-books"/>
<data-category id="email"/>
<purpose id="book-of-the-month-club"/>
<action id="read"/>
<condition id="consentToBookClub"/>
<condition id="olderThan13"/>
<obligation id="retention">
          <parameter id="days">5</parameter>
</obligation>

Parents are allowed to read any data of their children is formalzied as:

</rule>
<rule id="rule2" ruling="allow">
<data user id = "parent"/>
           <data category id = "p3p: any category"/>
           <purpose id = "p3p: current"/>
           <action id = "read"/>
</rule>

Why EPAL is Complementary to P3P

There is an existing privacy policy language called P3P [2] or the Platform for Privacy Preferences. This language (version 1.0) is a W3C recommendation (at April 16, 2002).

P3P is used to express high level privacy promises on web sites:

It allows web sites to express their privacy promises in a standard format.
Can be retrieved and interpreted by web browsers.
Web browsers can alert users if privacy settings at web sites are different to user settings in a browser.

Although P3P is well suited for expressing high level web site policies, it is not as suitable for expressing an internal enforceable privacy policy. EPAL on the other hand is designed specifically to express an internal privacy policy that can be enforced by an enterprise privacy management system.

A high level view of the differences between EPAL and P3P are shown in Table 1:

Categories: P3P has a pre-defined list of data categories. EPAL allows for an enterprise to define its own list of data categories and these may be hierarchical.
Data-Users: P3P has a pre-defined list of data users. EPAL allows for an enterprise to define its own list of data users and these may be hierarchical.
Purposes: P3P has a pre-defined list of purposes. EPAL allows for an enterprise to define its own list of purposes and these may be hierarchical.
Actions: P3P only defines the action “use”. EPAL allows for a definable list of actions.
Conditions: P3P does not define a condition language. EPAL uses the XACML condition language.
Obligations: P3P only defines the obligation “retention”. EPAL allows for a definable list of obligations.
Choices: P3P only allows for simple opt-in/opt-out choices. EPAL allows for a more generalized set of choices.

P3P is an excellent language for expressing high level privacy promises on web sites. However, EPAL should be used to define an enforceable privacy policy within an enterprise. [5]

	EPAL	P3P
Data Categories	Hierarchy	Predefined list
User	Hierarchy	Predefined list
Purposes	Hierarchy	Predefined list
Actions	List	‘use’
Conditions	XACML	none
Obligations	List	‘retention’
Privacy Choices	Generalized	+/- purposes/recipient/retention
Properties	Flexible Hierarchical Access control Enforceable Less interoperable	Simple Interoperatble Less extensible No enforcement Limited Web-centric

Table 1: EPAL vs P3P.

Summary

For an enterprise to be a good custodian of their customer’s PII data they must be able to define an enterprise privacy policy that is enforceable across the enterprise. To do this we propose five steps in privacy management that are required to manage the PII data and enforce the privacy policy. We also define a new privacy policy language called EPAL, which is specifically designed to be an internally enforceable privacy policy language for an enterprise. EPAL is complementary to W3C’s P3P.

Bibliography

[1] Federal Trade Commission, Available at http://www.ftc.gov (August 2002)

[2] W3C, The Platform for Privacy Preferences (P3P),W3C Recommendation, 16 April 2002, Available at http://www.w3.org/TR/P3P (August 2002).

[3] COPPA, Children's Online Privacy Protection Act of 1998, October 1998

[4] The Enterprise Privacy Authorization Language (EPAL), IBM Research Report, Available at http://www.zurich.ibm.com/security/enterprise-privacy/epal/, 03/03/2003.

[1] Privacy is the right of individuals to determine for themselves when, how, and to what extent information about them is communicated to others (Alan Westin).

[2] The OECD defined a set of privacy principles in 1980. The document “OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data” is considered to contain the core requirements for managing privacy today.

[3] Information is considered PII or Personally Identifiable Information if it can be linked to a person. Information that has been de-personalized or anonymized would not be considered PII - unless there are ways of linking it back to the individual through re-personalization or inference.

[4] These privacy promises can be formalized using P3P [1]. Note that P3P is coarser than the enterprise privacy practices of EPAL. While P3P may promise ``we do not disclose data'', EPAL may define the exact flows that are authorized in an enterprise.

[5] We are currently investigating how to project a P3P policy from EPAL.