Privacy-aware Business Process Design by an Enterprise Privacy Architecture

There is no viable technology that enables consumers to enforce proper use of their personal information throughout an enterprise. As a consequence, customers are required to trust an enterprise once they disclose their personal data. However, enterprises willing to implement fair privacy practices usually face the following problems: 

1. Business processes are designed without considering privacy requirements. Thus, enterprises are forced to create stockpiles of personally identifiable information (PII or short personal data) instead of collecting personal data when needed for the business at hand. 

2. Existing services often identify users even though their identity is not needed for the business at hand. Privacy-enhancing security technology that provides security with less data is rarely used. 

3. Enterprises store a variety of personal data. Larger enterprises may not know what types of PII are collected and where it is stored. 

4. Enterprises may neither know the consent a customer has given nor the legal regulations that apply to a specific customer record. 

From above we conclude that enterprises that want to respect the privacy of consumers need three main technologies: 

1. Privacy-enabling design, 

2. privacy management services, and 

3. privacy-enabled security services. 

Privacy-enabling design includes techniques making services more privacy friendly. A core building block is data minimisation. The goal of data minimisation is to minimise the amount of personal data than needs to be collected to achieve the objectives of an enterprise. This includes privacy-enabling applications that are designed to provide services with least the amount of data needed. Tools for such applications are pseudonymity systems and anonymous authentication schemes.

Even with privacy-enabled design, an enterprise still stores a certain amount of personal data. Therefore customers are required to trust the enterprise to use this data as promised in a privacy policy. Privacy management services help enterprises to enforce the promised practices in an auditable way.

Without computer security, a company cannot guarantee privacy. Privacy-enabled security services are needed to secure the infrastructure running the enterprise privacy management services. Nevertheless, existing security technology often provides security without privacy. Examples are non-anonymous identification and authentication schemes, data collected by intrusion detection systems, and coarse access control. In order to enable privacy, these technologies need to be transformed into privacy-enabling security services. Analogously to privacy-enabled applications, the goal is to provide security without collecting personal data about honest users.

In the remainder of this section, we introduce the IBM Enterprise Privacy Architecture (EPA), a methodology for enterprises to provide an enhanced and well-defined level of privacy to their customers. A more detailed description can be found in (Karjoth, Schunter and Waidner, 2002). 

The IBM Enterprise Privacy Architecture

The IBM Enterprise Privacy Architecture is a methodology that allows enterprises to maximise the business use of personal information while respecting privacy concerns and regulations. It provides a sustainable privacy management system, which can be customised to the total set of privacy regulations and privacy choices facing an enterprise. It includes privacy-friendly business processes, privacy-enabling security technology, and enterprise privacy management. Privacy-friendly business processes are derived from ordinary business processes by minimizing the data needed to provide the desired services. It may include switching to equivalent service alternatives that require less personal data. It may also utilise privacy-enabled security technology.

A unique aspect of EPA is that it provides an analysis of privacy in the context of real business processes by stripping privacy down to its most essential form of actors, rules and data. This is accomplished via object modelling techniques that compile a picture of privacy flows where obligations, risks and opportunities can be clearly identified. This analysis also provides clear linkage to identify which privacy enhancing technologies are appropriate and provides the raw data necessary to customise technology implementations.

Figure 5.: Building blocks of the IBM Enterprise Privacy Architecture

EPA introduces privacy-awareness and privacy services into enterprises in a systematic and complete way. Figure 5.1 illustrates its components, outlined in form of a pyramid. As a prerequisite, the EPA privacy regulation analysis identifies and structures the applicable regulations. The Management Reference Model (top 3 layers in Figure 5.1) constitutes the tip of the EPA pyramid, defining the privacy strategy and practices of the enterprise. The Privacy Agreements Framework provides a privacy-enabled model for privacy-enhanced business process re-engineering. The lowest layer is the Technical Reference Architecture that defines the technology for implementing the required privacy services.

Privacy Regulation Analysis

Regulatory compliance is a primary driver of privacy-related activity in the marketplace. Thus, it is clear that a useful picture of the regulatory landscape is a pre-requisite to developing any kind of privacy architecture. The challenge is that regulations are typically written in dense legal style with formats and terminology that tend to differ depending on their origin and purpose. 

 

EPA addresses this challenge by regulatory summary tables and regulation rules tables. Regulatory summary tables summarise the applicable regulations using a unified terminology. The regulation rules tables identify data that is in the enterprise as well as the legal restrictions on using such data. The regulation rules tables are enterprise-specific and more formal than the regulation summary table. An entry describes which party can perform which action on which type of data, the resulting privacy obligations, and a reference to the legal regulation. In addition, the four business-use phases Collection, Retention, Processing and Use (“CRPU”) are used to categorise the scope of privacy regulations.

Management Reference Model

The EPA Management Reference Model addresses the enterprise-wide processes necessary for a comprehensive privacy management program. These processes are structured and linked to drive the program starting from a strategic view down through the implementation of privacy practices (see Figure 5.1).

 

Strategy defines the privacy philosophy, the high-level policies and identifies the applicable regulations. This represents the highest level of an enterprise’s privacy program and embodies its philosophy, its policies and the regulations it will adhere to. The outputs are a privacy strategy as well as a security strategy. Both define what an enterprise will do for protecting

privacy and security. 

 

Control defines the general controls necessary to enforce policy. Its components are a Privacy Requirements Process, the Information Asset Classification and Control, a Compliance Enforcement Process, a definition of the Organisational Roles and Responsibilities as well as an Employee Education Program.

 

Practices defines the incorporation of policy into business processes. This represents the level of an enterprise’s privacy program that translates privacy policy obligations into the general processes, programs and activities that will implement them. Its components are a Privacy Statement declaring the enterprise policy, a Customer Preference Program for defining opt-in and opt-out choices, an Individual Participation Process that enables customers to access their data, a Dispute Process, an External Communication Program that advertises the privacy efforts of an enterprise, and Information Access Controls that protect the enterprises’ data and resources.

Privacy Agreements Framework

The Privacy Agreements Framework models the transaction level management of privacy at the points where enterprises use personal information within business processes. This includes processes that connect the individual to the enterprise, processes linking people and departments within the enterprise, and processes linking the enterprise with third parties. This model can then be used to identify privacy agreements that are required between the players involved. The main parts of the model are players, data, and rules.

 

The players are the entities that interact while processing collected data. Basic players are data subjects (persons about whom data is collected) and different data users (enterprises or employees using the data). The player model uses an object-oriented modeling technique to identify the players, their operations on the data, as well as the interactions among the players. The result is documented using UML class and collaboration diagrams.

 

The data model identifies the data needed for the processes. Besides identifying the fields collected in forms, it classifies data into at least three categories:

 

1. Personally identifiable information is the most sensitive kind of information that can be linked to a real-world identity. Examples include a tuple name/surname or a U.S. social security number. 

2. Depersonalised Information is PII where the identifying information has been replaced by a pseudonym. Even though this data is less sensitive, some parties are able to re-personalise it by replacing the pseudonym with the identifying information. Examples include the age with a customer number.

3. Anonymised Information contains no identifying information or pseudonyms. It is the least sensitive kind of information that can be obtained by removing all personal data from a set of data. For anonymised data, it is required that identifying the data subject given the data is virtually impossible. Examples include the town of residence or an age in years on its own (i.e., without any other information that may enable identification of the data subject).

 

The rules model identifies the rules that govern the usage of data by players and their operations. It defines what player may perform which operation for what purpose. In addition, rules may impose conditions and may define obligations that result from performing an operation.

Technical Reference Architecture

To guarantee that an enterprise provides sufficient privacy to its customers, privacy-enforcement needs to be deployed on an enterprise-wide scale. All applications that handle personal data need to make sure that the handling adheres to the promised policies. An enterprise-wide privacy-management system uses at least three types of systems:

 

1. The Policy Management System enables the administrators of the system to define, change and update privacy policies. It distributes the privacy policies to the privacy enforcement systems.

2. The Privacy Enforcement System enforces the privacy protection for each individual resource that stores privacy-relevant data. It obtains policies from the policy management system and offers auditing data to the audit console. The privacy enforcement system is usually split into two parts: A resource-specific resource monitor shields the resource and a resource-independent authorisation director evaluates the policies and decides whether requests are granted or not. The authorisation director authorises operations on the collected data. After evaluating the policy, the authorisation director returns whether the request is authorised or not and whether an authorised request implies any privacy obligations. Each kind of protected resource (database, CRM system, etc.) uses a corresponding resource monitor. This monitor shields the resource from direct access. Each incoming request is translated into a call to the authorisation director. Only if the authorisation director authorises the request, the request is forwarded to the resource. The resource monitor records audit data and tracks pending privacy obligations.

3. The Audit Console System enables the Privacy Officer to review the audit information stored in the enforcement nodes and the policies distributed by the policy management systems. Audit services help organisations evaluate regulatory compliance and develop corporate privacy policies.

 

The EPA Technical Reference Architecture may be refined by a fine-grained privacy authorisation language that enables enterprises to formalise and enforce privacy practices and to manage the consent of their customers.

Other Privacy Architectures

Surprisingly, there are not many approaches that provide a unified approach to a privacy-aware business process design. The International Security, Trust, and Privacy Alliance (ISTPA) has published a Privacy Framework for the protection of personal and organisational data, which defines security, privacy, and trust services and their relationship. It provides an open, policy-configurable model consisting of 10 integrated privacy services and capabilities, which can be used as a template for designing solutions and supporting audit assessments covering security, trust, and privacy requirements.

 

22 / 38