Académique Documents
Professionnel Documents
Culture Documents
Axel Bücker
Bill Haase
David Moore
Martin Keller
Dr. Otto Koblinger
Hai-Fun Wu
ibm.com/redbooks
International Technical Support Organization
December 2003
SG24-6999-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
This edition applies to Version 1.2 of IBM Tivoli Privacy Manager for e-business.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
iv IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
4.5.3 AHC Privacy Manager policy groups . . . . . . . . . . . . . . . . . . . . . . . . 93
4.5.4 AHC identification mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.5.5 The actors in the Tivoli Privacy Manager groups . . . . . . . . . . . . . . . 97
4.5.6 AHC privacy policy usage statements. . . . . . . . . . . . . . . . . . . . . . . . 98
4.5.7 Risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6 Technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.1 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.2 Monitor design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Contents v
6.1.1 Geographical distribution of RPF . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.1.2 Organization of RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2 Current architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2.1 Overview of the Web-based application infrastructure . . . . . . . . . . 177
6.2.2 Outline of the customer Web portals. . . . . . . . . . . . . . . . . . . . . . . . 178
6.2.3 Outline of company-internal financial applications . . . . . . . . . . . . . 179
6.2.4 Current shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.2.5 Privacy issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.1 Business vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.3.3 Corporate privacy policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.3.4 Expected benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.4 Project layout and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.4.1 Phase 1: Privacy policy design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.4.2 Phase 2: Monitor descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.4.3 Phase 3: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.5 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.5.1 Customer’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.5.2 Banking department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.3 Insurance department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.4 Trading department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.5.5 Customer relationship department’s view . . . . . . . . . . . . . . . . . . . . 188
6.6 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6.1 Data design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6.2 Privacy rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.6.3 Risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.7 Implementation architecture for declarative privacy . . . . . . . . . . . . . . . . 196
6.7.1 Declarative Privacy Monitoring concept . . . . . . . . . . . . . . . . . . . . . 196
6.7.2 Declarative XML privacy deployment descriptor file . . . . . . . . . . . . 201
6.7.3 Plug-in classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.7.4 Declarative Privacy Monitoring download site. . . . . . . . . . . . . . . . . 208
6.8 DPM monitor technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6.8.1 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.8.2 System setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.8.3 Create a P3P policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.8.4 Create a declarative privacy deployment descriptor XML file . . . . . 211
6.8.5 Provide privacyOperationPoint descriptor plug-in classes . . . . . . . 215
6.8.6 Deploy monitors in Privacy Manager . . . . . . . . . . . . . . . . . . . . . . . 220
6.8.7 Enforce privacy policies in auto insurance application . . . . . . . . . . 228
6.9 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
vi IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Appendix A. Declarative Privacy Monitoring . . . . . . . . . . . . . . . . . . . . . . 237
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Contents vii
viii IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
x IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Preface
Conducting business today involves more and more personal information of the
parties involved in the transactions. This is not limited to e-business but applies
to all companies that use computer technology for business processes in order to
store data. In this era of e-business, people have become aware that their
personal information is being used in multiple places and are asking questions
about the whereabouts of these assets.
This IBM Redbook helps privacy and security officers as well as their staff to
understand and implement the IBM Tivoli Privacy Manager in an enterprise
environment.
Part 1, “Drivers and architecture” on page 1 covers the design and architecture of
Tivoli Privacy Manager and looks at the impact of privacy issues on enterprise
policy, standards, and procedures.
1
The Fair Information Practices is a report from the Federal Trade Commission submitted to
Congress in May 2000. The document can be found at
http://www.ftc.gov/reports/privacy2000/privacy2000.pdf
Bill Haase is a part of the Tivoli Americas National Sales Engineer Team in
North America. Bill has 20 years of experience in the development of information
technology systems and over 10 years of experience in developing security and
privacy management infrastructure. He holds several certifications in security
and has contributed to the development of IBM's privacy methodology, patented
Enterprise Privacy Architecture and intellectual property including patents,
methods and architectures. In addition, he has developed most of the current
training materials and certification exams for Tivoli Privacy Manager. He serves
as an expert in privacy and security to IBM customers in North America with
expertise in regulatory compliance and systems integration.
xii IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Martin Keller is a Certified Tivoli Consultant with his own company Red Planet
Solutions, an IBM business partner in Germany. Since 1997 he has provided
professional services in Tivoli Enterprise™ and Tivoli Security products. He
holds a degree in computer science from the Fachhochschule of Fulda,
Germany. His main interests are IT architecture, e-business infrastructures and
systems and network management. Before founding Red Planet Solutions in
1998, Martin was a Senior IT Consultant for the systems integrators Softlab
GmbH and Danet GmbH in Germany.
Dr. Otto Koblinger is a Tivoli Security Consultant in the Software Group of IBM
Germany. He has many years of experience in the security area. He holds a
degree in Physics from the University of Stuttgart/Germany and received his PhD
in Science. He joined IBM Research and Development in Böblingen, Germany in
1985 and has worked in various technology areas of IBM. In 1996 he moved to
IBM Global SmartCard Solutions in Böblingen. In 1998 he joined the IBM
e-business unit in EMEA/Central Region covering security issues. Since 2001 he
has been a Business Consultant in the Security Pre-Sales Department of Tivoli
Germany.
David Moore is a Software Engineer with the Tivoli Security Integration Factory
in Australia. He has eight years of experience in developing integration
middleware and security software. He holds a degree in Computer Science from
Griffith University in Australia. Before joining IBM, David was employed as a
Software Engineer at Compaq.
Preface xiii
Jeff Miller
IBM Developer Relations
Kathy Bohrer
IBM Privacy Control Research and IBM Distinguished Engineer
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
xiv IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Part 1
Once you know what you need to protect and the potential threats and risks, you
can start addressing them. First, all the threats and risks need to be classified in
a study based on such elements as:
Direct financial loss
Indirect financial loss (such as investigation, recovery, and so on)
Loss of confidential information
Liability
Image impact
Cost of mitigation
Accepting residual risk
This study can process the same threats and risks, yet may conclude in a
different severity based on your particular business. Then the decision has to be
made whether to accept or to mitigate the risk. This process can be handled by
external consultants such as IBM Global Services. The threat identification, as
well as this severity study, is done in conjunction with the organization by
applying a standard and proven methodology.
Static
Corporate
Policy
Standards
Standards
Standards
Standards
If not existing, the first document that will be written is the corporate policy. It
must outline the high-level directions to be applied enterprise wide. It is
absolutely not technical, but is derived from the business of the enterprise and
should be as static as possible, as depicted in Figure 1-1.
Policies is a very common term and in many products you will find specific
policies sections. These are the product-related policies that are covered in
the practice or procedure documents. The corporate policy is not related to
products and is a high-level document.
4 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
control, information classification, and so on. They explain how the policy must
be applied. Changes in threats or major technology changes can impact them.
Use cases are very helpful to illustrate how policies and standards are translated
into specific practices or procedures. Use cases can be used to articulate the
step-by-step process, environment, and conditions that can help define what a
practice is and what it is not. This helps to identify and articulate risks that are not
clearly defined by the practice.
If a man asks to borrow your car, you probably would want to know a few things
before you would consider lending it to him:
Why do you want my car?
When will you return my car?
1
The OECD Web site provides different articles on the background of privacy guidelines, the version
from 1980 can be found at
http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_1_1_1_1,00.html
6 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
What do you plan to do with my car?
Are you planning to let others use my car?
If the man tells you “I would like to enter a demolition derby with your car”, then
you might not let him take it. If he tells you “My friends will each pay me a fee for
using your car but I do not know what they intend to do with it”, then you might
not let him take your car.
On the other hand, if he says “I would like to get us lunch and I will return in 20
minutes with your car and lunch for us”, then you might agree to let him borrow
your car.
The idea here is that your car is your property and you are the owner. As the
owner, you have the rights of ownership, which include controlling how your
property is used. Privacy management starts with the concept that information
belongs to the data subject of that information, and that how the organization
cares for this information must be communicated and enforced consistently to
build trust between the organization and the data subject. This is usually
communicated through policy, standards, and practices internally and through
the privacy statement and opt-in or opt-out programs externally (or to the subject
of the data collected).
Let us outline some of the key governance documents, including critical policies,
standards, and practices. Unique to privacy management are data subject choice
or consent programs, such as opt-in or opt-out programs.
Another good resource for guidance is the U.S. Federal Trade Commission,
which enforces most of the United States Federal Privacy laws. When it performs
an investigation into privacy violations it usually starts with two basic questions:
What are the privacy practices in your policy and do you follow them? According
to the U.S. Federal Trade Commission, a privacy policy should at least contain
the following five key components:2
Notice/Awareness: Notice means providing data subjects and users of
personal information with the organization’s privacy practices and the
organization’s policy. Often this includes the organization’s practices of PII
collection and lists the uses and purposes for the collection of the PII. In an
e-business environment, this would typically be done through a hypertext link
to the privacy policy or for external constituents, the privacy statement.
Consent/Choice: Any user who submits a PII should be given the
opportunity to grant consent for how his or her information will be used.
Typically, this takes the form of an opt-in/opt-out program. The policy specifies
what PII is collected and identifies for what purposes the data will be used
and if the data subject will be given an opportunity to grant consent for
specific uses.
Access/Participation: Access typically means providing the data subjects
with the ability to view, edit, or update the PII that the organization has
collected about them. It includes a contact point and a method for viewing and
correcting information stored in the organization’s databases about them.
This usually includes personally identifiable information, demographic
information and associated preferences. Most often this is used to correct
contact information such as address, phone numbers, and e-mail addresses,
as well as the ability to choose or grant consent to specific uses of their
information.
2
Source: “Privacy Online: A report to congress”, submitted on 7-11-1998, at
http://www.ftc.gov/reports/privacy3/index.html
8 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Integrity/Security: The policy includes a commitment to securely store and
maintain the integrity of the PII collected. Many privacy policies include a
commitment to secure information and prevent its access by unauthorized
users. You cannot have privacy without security and security is all about
preventing access by unauthorized users to sensitive information. Privacy is
focused on ensuring proper use for specific purposes of PII by authorized
users.
Enforcement/Redress: The privacy policy at a minimum includes a contact
point for filing a complaint or to notify the organization of a potential privacy
violation. Some policies include contact information for specific industry
programs that organizations can subscribe to, for example, the Better
Business Bureau Online (see http://www.bbb.org), TRUSTe (see
http://www.truste.org), or the Direct Marketing Association (see
http://www.the-dma.org/). The general principle is to provide a means for
the data subjects to access a resource to handle or investigate the misuse of
their information. Enforcement may include detailed specific practices
including data-handling procedures and audit procedures to verify policy
compliance. More advanced organizations may even include access to a
detailed report of how and when the data subject’s information has been
accessed, for what purposes it has been used, and by whom.
10 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Data-handling requirements
The data-handling requirements are the practices that are to be applied to
data of a specific class. Often the data classification schema is developed in a
by identifying and collecting the sets of data-handling requirements that are
required to be applied to the data that the organization retains.
12 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
retained by the organization. The data ownership and custodian standard
addresses the organization’s approach to setting data-handling requirements to
mitigate risks with different “types” of data. If an organization is the creator or
owner of data, the risks from inappropriate disclosure may be limited to loss of
competitive advantage or embarrassment by the organization. On the other
hand, if the organization is the custodian of data that it has collected from outside
the enterprise, then there are additional risks, such as liability for regulation
violations or identity theft of customers to civil penalties from contract violations.
Included in the data ownership and custodian standard are guidelines for the
identification of the organization’s role to the data under management and
assignment of responsibility for setting safeguards of the data. This standard is
often associated with the information classification and control standard
(discussed in 1.3.3, “Information classification and control standard” on page 9)
and leverages this standard to help set data-handling controls for the data. In
addition, it usually defines consent or authorization collection requirements for
use or disclosure of the data. These requirements may include limitations by
purpose or authorized business processes.
As a component of a privacy program, the third party who is submitting the data
and granting consent is the data subject of the data retained by the organization,
or in a broader sense the data owner or data submitter. The standard defines a
process for collection of consent or to grant authorization to the organization to
use data in a specific way.
14 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
An organization may have multiple data authorization procedures in place. All
data authorization procedures specify what data is collected at what time to be
analyzed in a specific way. This usually involves the collection of metadata about
the data being acted on and evaluated in some way. Privacy programs often
specify the evaluation of at least four metadata elements:
The users role of privacy group
The type or classification of the data requested
The purpose for the disclosure
The data subject’s consent or authorization for this use
The guiding principle is to be open and honest with the data submitter about the
organization’s data-handling practices when collecting their consent to the
handling practices. An important requirement of this procedure is the binding of
the policy presented to the user and the recording of the consent. Binding these
two elements together allows the organization to revise policies and maintain a
trust relationship with the data submitter. If the organization changes its
data-handling practices (for example, it revises its policy to include the ability to
transfer the data in a merger or acquisition or to lease the data to other users
outside the organization), then these new practices can be implemented with the
full knowledge that the previously collected consent was for the old policy and
does not carry over to the new. This has been a significant restriction for
organizations and challenge for organizations;,binding consent and collection
policy while providing the organization the ability to change and stay flexible.
7
Other reporting points often are Chief Information Officer, Chief Security Officer, Compliance Office
and Vice President of Marketing.
16 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
The measurement and assessment activities of the Chief Privacy Officer involves
working with individuals who have privacy complaints and auditors to assess the
organization’s compliance with the privacy program’s requirements. Both of these
activities involve assessing the organization’s business process requirements
and their uses of privacy-sensitive data.
All three of these domains have a direct impact on the success of a privacy
management program. The linkage is strong between these two roles because
you cannot have privacy without good security but you can have good security
without good privacy. Good information security is an important requirement for a
successful privacy program. While security is often more focused on keeping
unauthorized users from accessing sensitive information, privacy is often focused
on managing authorized users to use information effectively and within the
constraints necessary to achieve an organization’s strategy.
The CPO and CISO roles work together to reduce the threats to the information
retained by the organization by both authorized and unauthorized users. The
security role is focused on threats from unauthorized users and external factors
where privacy is focused on internal threats often from authorized users of the
information.
18 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
1.4.4 Human resource officer
The human resources (HR) group has a direct impact on privacy management
and a dependency on effective privacy management of the information the
organization stores about employees and contractors. The human resources
group often is the first contact point for employees, contractors, and so on within
the organization to learn about the organization’s policies and standards. HR
often provides the workforce training and re-training for compliance with these
policies, and it enforces disciplinary action if these policies are violated. Privacy
management needs to integrate HR into the processes for the establishment and
implementation of privacy management practices. Key integration points include:
Development of data classification schemes
Development of data-handling requirements for employee information
Development of employee policy education
Defining auditing and evidence requirements for employee disciplinary
actions
One best practice for this role is to identify the data that is used and disclosed,
the application and transaction that is used to access the data, and the business
purpose of the transaction at each step in the workflow. Each step that discloses
or uses privacy-sensitive information introduces the risk of appropriate
disclosure.
The best practice for managing this type of risk includes the implementation of an
authorization gate, and logging information on the access path as close to the
data storage system as possible that contains the privacy-sensitive information.
In addition, the workflow analysis should contain the applications and
8
An excellent modeling tool for business processes is Holosofx® from IBM. More information can be
found at http://www-3.ibm.com/software/integration/wbimodeler/
Two best practices that are usually implemented by the database management
team include the evaluation of the database logs and development of the
enterprise data dictionary.
The best practice to manage enterprise privacy risks is to know where all of the
privacy-sensitive information is retained. A very helpful tool for this task is an
enterprise data dictionary that includes all of the enterprise data elements and
documents the data classification of each element. Developing this enterprise
data model alone can be a very challenging task and is usually done organically
over time rather than in a single discovery effort. Documenting changes and
additions to the enterprise data dictionary helps to manage privacy threats and
risks by at least providing a map or inventory of where the privacy-sensitive
information is retained. One approach to this practice is to use a federated
database to support the task. IBM DB/2 software has this capability to develop,
20 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
maintain and manage access to an enterprise data dictionary9 and to implement
a federated database management approach.
The operations manager has reported an increased workload on the help desk
due to problems caused by employees downloading non-business related
programs onto their systems.
The standards for the networking part explain which services may be allowed on
the employee computer. The practice will then explain how to set up the Windows
or Linux clients accordingly to the standards, and the procedures will explain how
to perform a request, the requirements and the approval paths, to get special
services installed on your computer.
The existing clients will be updated and controls will be performed to verify the
compliance in addition to a further audit of the environment.
The five steps we went through may be summarized using the chart in Figure 1-2
on page 22. It is a common approach adopted in many methodologies.
9
An article on this topic can be viewed at:
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0203haas/0203haas.html.
Implement Risk
Manage Audit
The first is the concept of data ownership. If the organization accepts a property
rights framework about information, then the authority and responsibilities of
data ownership may lie outside the organization with the data subject for
personal information. This is a driver for a lot of regulation around the world. If the
organization adopts this approach to personal information, then the organization
needs to implement its responsibilities as a custodian of this information and
operate within the authority granted by the data subject. This means the
organization needs to implement a choice or consent program of some type.
22 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
implemented at an element level, but some organizations have applied
classifications at a record level. In order to meet the requirements of most privacy
regulation this needs to be updated to record level resolution. Classification or
abstraction at this level usually requires more than seven categories to
sufficiently express the organization’s data-handling requirement sets. This
would be like saying that an organization of 5,000 employees only needs three
role definitions to adequately control access to information. Abstraction by
category does tend to follow a logarithmic model to adequately express the
required number of categories, but also suggests that as few as three would be
sufficient. However, this may leave significant gaps in security and privacy and
not allow flexibility to share information in ways that benefits the organization.
Once the data has been classified, its use and disclosure needs to be managed
by an authorization model that is evaluated on every transaction that accesses or
discloses the data. Transaction level authorization is required in order to be
sensitive to the specific instances of the data that may be governed by different
consent levels for specific purposes.
Another issue that may need special consideration is the concept of asserted
user credentials. There are two interesting use cases where the user credentials
are not relevant or useful for privacy enforcement purposes. The first use case,
and most common, is when an application server uses a shared user credential
to access data stored in a back-end database. In this case, the actual user who
initiated the transaction is not represented by the user credential that is identified
as initiating this particular transaction. What is needed here is a way to express
both the shared or application credential and an asserted user credential that
represents the actual person initiating the transaction. Privacy management, and
often security management as well, require the credential of the actual user in
order to determine authorized access or disclosure of certain information.
Since these documents are used as rules within an enterprise, they must be
clear and not subject to interpretation. In addition, they must be publicly
published and available. If a policy or a standard is written but not appropriately
published, how can an employee be expected to follow it? It is not a loss of time
to train the staff on these documents, especially when it is new and complex.
It is more efficient to get the staff enforcing a policy or standard they understand
than having them fight against it. They are a key part of the global security level
of the enterprise, and when they try to bypass some policy, they put your
enterprise in danger.
24 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
The authorization models used for Data Disclosure Management are instance
based and are usually sensitive to the data type or classification of each element
in the instance record. They evaluate each transaction that records and discloses
data from storage locations. Fine-grained authorization is required and is usually
implemented through custom authorization models that do not tend to be very
flexible. Data Disclosure Management shares its requirement for a fine-grained
authorization model and the audit logging details with the privacy domain but
privacy has as an objective allowing flexibility with access and use of information.
Both domains depend on the data types and purpose of the disclosure to
determine if it is an authorized disclosure.
28 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
GUI
Application
Data Store
Authentication
Data User Authentication Application
Authorization
Store Registry Framework
Authorization
Privacy
Data Store
Applications
As you can see in Figure 2-2, the authentication and authorization service is
isolated from the application. It is provided as a service to all applications in a
company or in a domain. In the IBM Tivoli product world, the authentication and
authorization service is provided by the IBM Tivoli Access Manager products.
The User Registry is an LDAP directory implemented by the IBM Tivoli Directory
Server, which itself uses an IBM DB2® database as the data store.
30 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Regulations and laws
New regulations and laws protect the privacy of individuals.
Web-enablement of applications
Business processes are implemented in workflows that make intensive use of
intranets, extranets and the Internet. Privacy rules can‘t be enforced anymore
by business process instructions such as masking the customer name before
giving the purchases list to the market research people.
Vertical industry integration
Business processes are more and more interwoven between companies that
partner to offer a product or service. Distributed data access between
partners is very common and privacy becomes important.
Reporting requirements
Regulations and laws enforce businesses to record actions that access,
distribute, and manipulate data. This is because more and more actions that
have legal consequences are done electronically over the Internet.
Figure 2-3 shows how the privacy service is centralized and isolated for the
application.
GUI
Privacy Service
Data Store
Applications
In the IBM Tivoli product world, privacy services are provided by IBM Tivoli
Privacy Manager, which itself uses a DB2 database as the data store. Monitors
enforce data access restrictions based on privacy policies.
32 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Administrator CPO
Browser Browser
Application Layer
Service Layer
The user interface layer contains the graphical user interfaces for privacy
management administrators and for the Chief Privacy Officer and his staff. These
interfaces are Web-based and can be accessed with Microsoft or Netscape Web
browsers.
Underneath the user interface layer is the application layer. This is the layer
where privacy policies and monitor data is managed, reporting functions are
executed, and user consent is updated. The monitors trigger procedures in the
application layer to make the decision about which data fields can be exposed to
the application end user. The application layer make use of the features provided
by the service layer.
The service layer supports the application layer by providing basic functions such
as data storage and an authentication and authorization service. Data storage is
provided through a relational database where privacy policies, monitor data,
consent information and audit reports are stored. The authentication and
authorization service answers the basic questions about whether a user is who
he claims to be and what functions he is allowed to access. The most important
features of the service layer is the application monitoring service. Application
monitoring is the interception of applications to check if data access is
conforming to privacy policies.
Monitored System
Application Privacy
Data Data Privacy Database
Collecting Accessing Monitor Data
Server
Ref.Mon.
Ref.Mon.
Storage
Ref.Mon.
SDK
Monitor
API
SDK
Monitor
API
SDK
Monitor Location
API
EJB
PII
Policies
Data Store Audit Trails
Reports
Authentication and
Authorization
Service
Figure 2-5 Components of a privacy management solution with IBM Tivoli products
Monitored system
The Monitored System is the customer application that needs to be
privacy-enabled. Users of a monitored system collect PII or access PII, which is
stored in the Monitored Systems Data Store. The Monitored System is accessed
by using a GUI. Examples of Monitored Systems are ERP applications and CRM
applications and directories.
34 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Manager Console. The Web User Interface allows its users to accomplish the
following tasks:
Create and modify, export and import privacy policies
Administer monitors
Create and manage report definitions
Start and manage reports
Privacy Server
The Privacy Manager Privacy Server is the main processing component in a
privacy management architecture. It processes incoming requests from the Web
user interface and from monitors. The Privacy Server is connected to one or a set
of monitors. Incoming requests from monitors ask for decisions whether data
elements can be exposed to users of an application, or for new consent
submissions. In data access, a monitor request contains details about the identity
of the user, which storage locations are accessed, the purpose of the access,
and other defined conditions. After the Privacy Server has decided, a response is
sent to the monitor. The decision is made with consideration of data stored in the
data store and by the use of an authentication and authorization service.
Enquiries from the Web user interface are requests to create or modify Privacy
Manager configuration data, such as privacy policies, monitor definitions or
reports. This data is also stored in the data store. The Privacy Server component
is an Enterprise Application deployed on IBM WebSphere Application Server,
Advanced Edition.
These database tables are used by the Privacy Server when privacy decisions
are made and when reports are to be generated. The Privacy Database is
implemented using the IBM DB2 Universal Database™.
Monitors
To privacy-enable an application, one or more monitors need to be developed.
Monitors are adapters that exchange information with the application and the
Privacy Server. Monitors are the policy enforcement point within the architecture.
Monitors are implemented using the Monitor SDK to communicate with the
Privacy Server. Monitors also can be developed using the Reference Monitor
API, which simplifies the development (see Reference Monitor API below).
Monitors have the following functions:
Poll the Privacy Server to find out if any new configuration data, such as policy
changes or monitor definition changes, is of importance for the monitor.
Intercept an application to check if data access to PII is conforming to a
defined privacy policy.
Pass new consent submissions to the Privacy Server.
Inform the Privacy Server that PII data is accessed. This is performed for the
purpose of reporting.
SDK
The Monitor Software Development Kit (SDK) is a tool that allows customers to
develop customized monitors. It contains Java APIs that are used by a monitor to
connect to the Privacy Server and request enforcement decisions. The SDK is of
primary interest because in most customer-specific deployment cases, monitors
need to intercept existing applications that need to be privacy-enabled. The SDK
provides the following functions:
Register a monitor and get information about a registered monitor.
36 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Register and manage storage location lists.
Submission of PII storage locations and report of PII data access.
Real-time privacy policy conformance check.
Monitor exception.
Note: At the time this redbook was written, there were two monitor
implementations available on alphaWorks: the Reference Monitor as
described above and a monitor for HIPAA that adds privacy controls to the IBM
WebSphere Business Integration Collaboration for HIPAA Transaction by
monitoring claims transactions between health care payers and providers,
ensuring that privacy policies and individual privacy choices are respected.
The Reference Monitor for Tivoli Privacy Manager can be found at:
http://www.alphaworks.ibm.com/tech/refmon
The Privacy Manager Monitor for HIPAA can be found at:
http://www.alphaworks.ibm.com/tech/hipaa
38 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Privacy Database
Customer Application Privacy Server
Database
Server WebSphere
Server
Server
DB2
WebSphere Privacy
Application WebSphere Database
Container Privacy
Monitor Data
Server Storage Loct
Ref DB
Monitor Mon SDK EJB Client PII
API Policies
Audit Trails
Data Store Reports
AM Java RTE
Access Manager
Server
Policy
Server
LDAP Client
LDAP
Server
LDAP
DB2
Application
These are customer-specific applications that need to be privacy-enabled.
Usually these applications cannot be changed and have to be taken as a given.
Applications can be of any type, such as Web-based application, client/server
application, or mainframe-based. Therefore, they can be located on any type of
server in the customer environment. For interception by a Tivoli Privacy monitor,
Monitor
This is the component that has to be developed to intercept the application and
the application data store. It requires the Monitor SDK. Whenever possible a new
monitor development should be based on the Reference Monitor.
Monitor SDK
The Monitor SDK is the Java API used to develop monitors. The Monitor SDK
needs to be installed in a WebSphere container.
WebSphere container
The WebSphere container is required as a runtime environment for the monitor
and can be provided by either a WebSphere Client or a WebSphere Server. In
this WebSphere container, the monitor and the Monitor SDK are installed.
Privacy Server
The Privacy Server is a Java application that runs on IBM WebSphere
Application Server, Advanced Edition. WebSphere Application Server is a J2EE
certified application server that provides the runtime environment for the Privacy
Server. The Privacy Server runs in one Java Virtual Machine (JVM) and uses a
Web container and an Enterprise Java Bean (EJB) container. The Web container
is used for the Web user interface, and the EJB container is used for the Privacy
40 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Server core functions. To access the Privacy Database, a DB2 client needs to be
installed on this server. The Access Manager Java Runtime Environment is used
to provide access to the Tivoli Access Manager Policy Server to resolve
user-to-group mapping. The following products need to be installed on the
Privacy Server WebSphere Server:
WebSphere Application Server
DB2 client
Access Manager Java Runtime Environment
Privacy Manager Server
At this point, we want to mention a special role the LDAP Server can play, apart
from its role as data store for Tivoli Access Manager. Since an LDAP Server is a
common data store for PII data, it is practical that an LDAP Server is monitored
for privacy reasons. In this case, an LDAP Server is nothing else than a data
store for a customer application. Because the LDAP Server is a common place to
store PII data, and an LDAP Server provides a well-defined interface, Tivoli
Privacy Manager comes with a set of monitors for LDAP Servers.
Network connections
Figure 2-7 on page 43 uses the dedicated server configuration to illustrate the
network traffic and the protocols used between the components.
42 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Privacy Database
Customer Application Privacy Server
Database
Server WebSphere
Server
Server
DB2
WebSphere Privacy
Application WebSphere Database
Container Privacy
Monitor Data
Server Storage Loct
Ref DB PII
Monitor Mon SDK EJB Client
API Policies
Audit Trails
AM Java RTE
Access Manager
Server
DB2,
Policy
TCP/IP
TCP/IP
RMI, CORBA- Server
IIOP, TCP/IP
SSL, LDAP Client
TCP/IP
LDAP
DB2
Since Monitor and Privacy Server are EJB applications, they use Java Remote
Method Invocations (RMI) over CORBA-IIOP on top of TCP/IP to communicate
with each other.
Note: In Version 1.2 of the Tivoli Privacy Manager product, the Privacy Server
implements a Web Services interface based on SOAP for Monitor-to-Privacy
Server communication.
The Access Manager Java Runtime Environment uses a secure protocol based
on SSL to communicate to the Access Manager Policy Server.
The Access Manager Policy Server uses an LDAP client that communicates with
the LDAP server using the LDAP protocol, which is based on TCP/IP. Optionally,
Usually all components of the privacy management solution are located in the
secure zone behind all firewalls. However, one can think of the case where the
customer application’s front-end is located in the Demilitarized Zone (DMZ) and
the data store is in the secure zone. Because of monitor design issues, the
monitor could now be located in the DMZ, close to the application’s front-end or
in the secure zone close to the data store. In the case of the monitor being
located in the DMZ, the monitor communication would need to cross a firewall.
This would require that CORBA-IIOP needs to run across the firewall.
Customer Application
Enterprise Privacy Server
Server
DB2
WebSphere Privacy
Application WebSphere Database
Container Privacy LDAP
Monitor Data
Server Storage Loct
Database
Ref Admin Data
Monitor Mon SDK EJB PII
User Data
API Policies
Audit Trails Group Data
Data Store Reports
AM Java RTE
44 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
In the Enterprise Privacy Server configuration, components are concentrated on
one server as much as possible. This means we have one server that runs the
customer application with its data store and the monitor, which requires a
WebSphere container and the Monitor SDK. All other components are installed
on the Enterprise Privacy Server. This server contains the IBM WebSphere
Application Server with the Privacy Server EJB application, and the Access
Manager Policy Server components with its Java Runtime Environment. Also
located on this server is the LDAP server and the DB2 database, which contains
the Privacy Database and the LDAP database.
LDAP Server
In most cases privacy management is just another application using the LDAP
Server infrastructure and there are already other applications deployed that
extensively use LDAP. The LDAP infrastructure has become one of the most
critical elements in the enterprise IT infrastructure. Inherent in LDAP are
replication mechanisms to assure scalability and high availability.
46 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Replication can be used to improve performance by providing a service from
multiple machines in order to satisfy a search as quickly as possible. Replication
can also be used to improve the availability of a directory service by having more
than one server. If one of them is temporarily down, the directory service
continues to be available from another server. The IBM Tivoli Directory Server
replication is based on a master-slave replication model.
There are two types of directories with respect to replication: master and replica.
LDAP refers to the master as the master server and to the replica as the replica
server. All updates are made on the master server, and these updates are
subsequently propagated to the replica server(s). Every replica server’s
database contains an exact copy of the master server’s directory data. A replica
server can be promoted as master server if required (for example, if the master
server is out of service for an extended period of time) in order to allow write
operations to the directory during this time.
Changes can only be made to the master server. If a replica server receives a
request to update an entry, this request will be returned with a reference to the
master server using a referral.
For more information on how to set up LDAP replication, refer to the LDAP
Implementation Cookbook, SG24-5110 and the latest product documentation for
the IBM Tivoli Directory Server.
Since the Policy Server is the only component in the Access Manager framework
that answers to pdadmin calls, you cannot afford the Policy Server going down if
Privacy Server
Since Privacy Server is a J2EE application running on an IBM WebSphere
Application Server, a clone application server needs to be configured on a
different machine — in the following, we call the two machines original and
clone.
On the clone server, we have to install a DB2 client and the Privacy Manager and
WebSphere Application Server databases need to be cataloged for this DB2
client. The properties file <WAS_HOME>/properties/sas.server.props needs to
be copied from the original server to the clone server. Both nodes, original and
clone, should be displayed when running the WebSphere Administrative Console
on both nodes. Using the WebSphere Administrative Console on the clone node,
the Application Server clone needs to be created in the PMgroup by right-clicking
PMgroup -> New -> Clone. Privacy Manager and the Access Manager Java
Runtime Environment have to be installed and configured on the clone server.
The privacy.ear file needs to be copied from the original server and expanded on
the clone.
Monitors
Backup monitors are only needed if the monitors are separated from the
application. Most likely, the monitors are tightly connected to the applications and
thus can be considered part of the application. When the monitors are separated
from the application, a backup WebSphere container with the installed Monitor
SDK and the monitors needs to be triggered to take over and interface with the
application. The backup monitors have to be registered with the Privacy Server.
Privacy-enabled application
If the privacy-enabled applications require high availability, so must the monitors.
In case of a switchover, the monitor must re-register with the Privacy Server and
reload the configuration.
48 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
The following sections give hints on how these components and the underlying
operating systems can be tuned for better performance. The last subsection
gives advice on how the Privacy Server itself can be tuned.
AIX
The number of local IPC (inter-process communication) connections is restricted
on AIX. This can become an issue when a DB2 client is used to access a DB2
database on the same server. The solution is to remotely catalog a local DB2
database as remote, so that the IPC connections are used more efficiently. For
details, see the DB2 product documentation.
Solaris
On Solaris, system parameters for message queues, shared memory, and
semaphores can be tuned for better performance. Message queues, shared
memory and semaphores are low-level operating system features for IPC. In the
/etc/system file, the following changes are recommended:
Windows
If you are running a Windows 2000 Server version in a distributed environment, a
performance improvement can be achieved by optimizing the system for network
traffic instead of file sharing.
Another tuning task could be the use of Database Managed Space (DMS)
instead of System Managed Space (SMS). In the case of an SMS, a data
container is a file system directory. Tables and files are created as numerous files
within the directory. This means the tablespace is subject to file system
fragmentation and overhead during the opening and closing of multiple files. The
default installation for Tivoli Privacy Manager uses SMS.
DMS requires an up-front allocation for storage. The DMS container is a single
file in a host file system or can be created directly on a disk, bypassing the file
system altogether. In this way DMS delivers much better performance.
WebSphere tuning
As an initial starting point, it is recommended that you run the Performance Tuner
wizard that is available through the WebSphere Administrative Console. This will
tune common performance-related settings for both the WebSphere Application
Server and the Privacy Manager database. In Table 2-1 we list the important
parameters and provide an explanation and their default values.
Web container max Specifies the number 50 Default value should be sufficient. Increase if
threads of threads available to you need more than 25 parallel running
Privacy Manager Privacy Manager consoles.
consoles.
50 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Parameter Explanation Default Value calculation
value
ORB thread pool size Size of an Application 20 Example with LDAP monitors:
Server queue (Number of monitors *
through which a client LDAP.MONITOR.SERVER.CONNECTIONS.
request flows on its MAX)
way to a database. +
(Sum of
LDAP.MONITOR.SSA.THREAD.MAX, for all
monitors with enforcement ON)
+
total number of monitors
+
(Number of concurrently used consoles * 2)
Prepared statement Number of prepared 100 Data source connection pool size * 200
cache size SQL statements (200 is the approximate number of SQL
which can be stored prepared statements used by Tivoli Privacy
in a cache. Manager 1.1).
52 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
2.5 The IBM Enterprise Privacy Architecture
In this section, we introduce the IBM Enterprise Privacy Architecture (EPA),
which can be used in the early stages of a privacy project to evaluate the existing
environment, to identify existing components and functions, and to design a
product-independent solution. In later project phases, the solution will be
implemented with existing products. We discuss how Tivoli Privacy Manager fits
into this conceptional model and which components of the model are
implemented by Tivoli Privacy Manager.
Data Users
disclosure
using PII
policy
described by negotation
capture data
release PII
Data Subject
54 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Data User other
Data Subject Data User
Organization
Enterprise Applications
User
Directory and
Interaction
Security Node
Node
Privacy Data Handling Node
Support
Privacy Service Node
Tools Node
The technical component architecture consists of five nodes and the enterprise
applications. It should be noted that for each enterprise application a
corresponding Privacy Data Handling Node exists. The components are
described in the following:
Enterprise Applications Provide the actual services of the enterprise.
User Interaction Node Provides services to interact with the data
subject and other non-administrator users.
Privacy Data Handling Node Stores and protects personally identifiable
information (PII).
Privacy Service Node Is the centralized privacy management
component.
Directory and Security Node Provides services to authenticate users and to
securely exchange PII with other enterprises.
Support Tools Node Provides tools that are needed by other
components.
In Figure 2-11 on page 56, we show the components of the EPA technical
architecture and their interactions. The following sections describe each node
and its functions in detail.
PII Submit
Access Requests
56 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
management. For example, if the general privacy policy has changed, the
data subject can be informed.
The Log Analyzer examines the logs held in the Privacy Action Audit Manager. It
can generate reports on behalf of the Privacy Policy Manager or summarize logs.
The Privacy Policy Decision Point is an engine that evaluates privacy rules. It
gets an abstracted access request from a Privacy-enabled Resource Manager
and returns a decision (“allowed” or “denied”) and possibly obligations. The
decision is based on policy and consent and may be based on additional data
from other PII. For example, the condition may be whether the accessor is a
parent of the data subject for which PII is accessed. The policy and consent is
either replicated from the Privacy Service Node or else retrieved when needed.
The Privacy Action Audit Manager logs access to PII. It must be used by
Privacy-enabling Resource Managers if the privacy rules require output logging
and may be used for further privacy-relevant actions. It provides services for
auditing and for accessing history data.
The Attribute Exchange Engine supports the exchange of attributes (for example,
facts about a person) between different privacy-enabling Resource Managers or
applications, in particular with different organizations. It may also support policy
negotiation between applications.
58 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Enterprise Applications
PII Submit
Access Requests
Figure 2-12 EPA technical components implemented by IBM Tivoli Privacy Manager
Let us refer back to the Privacy Database in Figure 2-6 on page 39. We see that
the database contains policies and reports. The policies correspond to the policy
and consent data shown in EPA. The logs of the Privacy Action Audit Manager
can also be found in the Tivoli product Privacy Database. Unlike in EPA, the
Policy and Consent databases are not replicated. Instead monitors, which are
called the Privacy-enabling Resource Manager in EPA terminology, access the
Privacy Database through the Privacy Server, which is called in EPA terminology
the Privacy Policy Decision Point.
In this chapter we discuss the following five different patterns for a Privacy
Manager monitor deployment:
Proxy Monitor
Application Exit Point Monitor
Application Callout Monitor
Declarative Monitor
Business Process Monitor
The blueprint describes logical divisions of responsibility that exist within a typical
monitor. Table 3-1 lists the main responsibilities of monitors mapped to the logical
monitor components.
To assist with monitor development, Tivoli Privacy Manager for e-business ships
with a Java-based Monitor Software Development Kit (SDK). The SDK provides
the responsibilities and implementation of the Privacy Server Adapter.
64 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Additionally, Tivoli Privacy Manager for e-business provides a component named
the Reference Monitor. The Reference Monitor provides the core functionality for
the monitor implementation and storage system interface. Using the Reference
Monitor, developers are required to provide the implementation of the Storage
System Adapter.
Client or
Protocol Parser Metadata Processor
Browser
Realtime
Conformance
PIIAccess PIISubmission
and
Enforcement
Tivoli Privacy
Manager Server
66 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
system is published only to the monitor. No other client access to the storage
system is permitted.
For a TCP/IP access scenario, this requires the configuration of a server port
for the monitor and an alternate port for the storage system. For a message
queue environment, two pairs of queues would be required. A
request/response queue pair is used between a client application and the
monitor. Another pair is used between the monitor and the storage system.
If the storage system supports multiple concurrent client accesses, it may be
necessary for the Transport Adapter to support this feature also. Additionally,
if authentication or other client context information is required by the storage
system, the Transport Adapter will need to support the ability to forward such
information to the storage system.
The Protocol Adapter is responsible for reading request and response
messages. It may use the services of the Metadata Processor to interpret the
messages. Once the messages have been interpreted, the adapter can
identify the storage location names referenced in both the request and
response messages. The Protocol Adapter can also classify the operation as
an access or submission so that the messages can be dispatched to
appropriate privacy handling modules.
The Metadata Processor is responsible for obtaining storage location
information from the storage system or messages used to access the storage
system. It may obtain the metadata by using the services of the Transport
Adapter or by using its own connection to the storage system.
Trade offs
The Proxy Monitor design has the significant benefit of minimizing or
eliminating the need to modify source code on the client or storage system.
This assumes, of course, that transport endpoint connection addresses are
configurable at the storage system. The Proxy Monitor takes advantage of
this configurability to represent the storage system with respect to the clients.
The monitor intercepts client access and response traffic transparently.
Enforcement of governing privacy policy is typically feasible using the Proxy
Monitor design. The monitor is directly on the PII access paths between the
client applications and the storage system. All request and response traffic
flows through the monitor, so the monitor typically has the opportunity to filter,
modify, or deny response data.
A disadvantage of the Proxy Monitor design can be the lack of context
information available for a given access. For example, it is often difficult to
determine purpose. If the monitor is not managing the authentication to the
storage system on behalf of the client, identifying the data user can also be
difficult.
Application
Application Interface Adapter
API
Tivoli Privacy
Manager Server
68 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
The monitor is configured to be part of the monitored application. However, it is
not visible to client applications. The monitor is essentially behind the application.
The monitored application delivers events or programming invocations to the
monitor based on well-defined interfaces. On each invocation, the monitor can
perform conformance checks or notifications to Tivoli Privacy Manager server.
Appropriateness - when to use
An Exit Point Monitor pattern is ideally suited to monitored applications that
support event registration and delivery, or user-implemented code modules
that are dynamically loaded. The exit points must be associated with data
access and update activity.
Enforcement can be supported only if the monitored application supports
synchronous delivery of events or notifications to the exit point to the monitor.
A further condition is that the exit point interface supports a type of return
indicator or can modify the result data set before returning control to the
monitor application.
Architecture
The architecture of the Exit Point Monitor pattern is illustrated in Figure 3-3 on
page 68. The architecture is relatively simple and is typically driven by the exit
point interface defined by the monitored application. Using the Reference
Monitor, a new monitor should provide the implementation of the Application
Interface Adapter.
The Application Interface Adapter acts as the monitor’s storage system
adapters. It must provide the implementation of the exit point interface defined
by the monitored application. For example, if the exit point is defined in terms
of a C language export library, the Application Interface Adapter must
implement these functions. The adapter’s responsibility is to marshal the exit
point invocation parameters into method calls on the Reference Monitor.
Depending of the parameters delivered by the monitored application, it may
be necessary to use monitored application APIs to gather enough context
information for the Reference Monitor calls. The exit point delivery will drive
the Reference Monitor invocation, which will in turn drive the Monitor
Assistant invocation for required data values.
Typically part, if not all, of the monitor will be running within the process space
of the monitored application. This will certainly be the case if the integration is
based on a dynamically loaded C/C++ code library or loaded Java class.
Trade offs
The primary benefit of the Exit Point Monitor design is the minimization, or
lack of code modification required in the monitored application or the client
application. The monitor design is based on the availability of well-defined exit
point interfaces on the monitored application. The monitored application logic
remains unchanged regardless of monitor execution.
70 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
J2EE Application
Privacy
Enabled
Data
Abstraction
Privacy
Enabled
Data
Abstraction
Application
Monitor Adapter
Tivoli Privacy
Manager
Reference Monitor
Tivoli Privacy
Manager Server
72 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
can be done, and the monitor is an integrated component of the application.
Context information related to data operations tends to more meaningful than
for other monitor patterns.
The obvious disadvantage of this approach is the need to modify application
code. This disadvantage is reduced for applications that have been well
architected and have a well-defined data abstraction layer. The more data
access logic is dispersed throughout an application, the more complexity will
exist for the monitor implementation.
Other additional factors to consider include the security and transaction
contexts that exist within the application. In some situations, for example, it
may be preferable to have the monitor share the same transaction context as
the core application logic, while in other situations, a separate transaction
boundary might be preferred for the monitor. It may be reasonable to have
privacy access notifications participate in the application transaction context.
This way, the notification can be rolled back or committed within Tivoli Privacy
Manager server based on the application behavior.
Important: The Declarative Monitor does not ship with the Tivoli Privacy
Manager for e-business installation media. It is available as a Web download
at:
http://www.alphaworks.ibm.com/tech/dpm?Open&ca=daw-flnt-071703
Web.xml
Descriptor
Web Container
Client or
Browser
Custom
Tivoli Privacy Plugin
Manager Code
Declarative
Monitors
Privacy
Descriptor
Tivoli Privacy
Manager Server
74 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Table 3-2 Mapping monitor responsibility to descriptor
Monitor Responsibility Descriptor Element
76 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Another idea is to integrate the monitor as an extra step(s) of the workflow. As
one core business step is completed, the workflow engine could redirect the
output to a privacy monitor step. The privacy monitor step could filter data out
before the engine is redirected to the next core business step.
Trade offs
The existence of a workflow-driven application typically implies well-defined
access points to data. This make the job of identifying where and what to
monitor relatively simple. A further advantage of automated business
workflows for privacy monitoring is the ability to identify purpose. A workflow
itself will typically correlate to purpose for privacy monitoring. Workflow
monitoring is generally less intrusive than other monitoring approaches. The
monitor can potentially reside in its own workflow step, and remain separate
from the core business steps.
The main disadvantage of this type of monitoring is its applicability to
organizations that use automated workflow tools.
3.7 Conclusion
This chapter has given you an overview of different ways to design and
implement a privacy monitor in an existing environment. The next three chapters
take you through specific examples of real-life implementations.
In our fictional scenario the government is asking the national Agency for Health
Control (AHC) how they could help analyze the costs and benefits of the current
system and propose alternatives for changing the system, and also for help in
planning for more Web-based interaction between the insured citizens and the
AHC to offer more and better choices for the insureds.
In the future, the government wants to change the Agency for Health Control
more into a Health Management Organization (HMO).
The government assumes this could help increase the quality of the health
service across the nation, but also it would help to reduce the cost of the health
system while being more flexible in providing extended services to the people (for
which the insureds will have to pay extra).
AHC’s insureds who are electronically managed in a large database with all
national health records. Today they cannot take much advantage of it, for
example, they cannot analyze current situations because health data is
considered to be very private and sensitive. This data belongs to the insured
people and the practitioners who are considered the data owners. To make more
use of this data AHC needs explicit consent from the data owner in order to
analyze health data.
Analyzing health data can help improve the quality of the health system across
the country in general, but also to improve the quality of individual health
treatment by offering choices and bonus programs to the patients while collecting
information from them.
In the future, the government wants to transform the Agency for Health Control
into a Health Management Organization (HMO), interacting with insureds directly
to manage their health instead of paying their bills only.
1
Briefing Materials on the European Union Directive on Data Protection can be found at the Center
for Democracy & Technology (CDT) Web site: http://www.cdt.org/privacy/eudirective/
2 The OECD guidelines can be found at: http://www.oecd.org
80 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
All personal and medical data is entered manually into the national data
system by branch office staff.
– Generally this procedure means a lot of data handling and manual
interaction.
– It therefore requires much control.
– Manually entered data is never free of errors and cannot be trusted as
much as direct input by a data owner.
– Having third parties filing consent to use certain data on behalf of the data
owner can become risky and can be considered a liability issue.
– Exposing sensitive data to third parties is also a data protection issue.
Therefore minimum data handling is a key objective for AHC. Automatic data
handling can make it much easier to match the legal requirements for data
protection and also provides a way to include good audit capabilities.
2. The patient can ask the practitioner for direct reimbursement by AHC, but this
increases the overhead costs for the practitioner. Some practitioners also feel
uncomfortable with this solution, because it gives AHC more details on their
internal operations.
A practitioner might be more willing to accept a centralized health data system
if he can receive some benefits such as the following:
– Use the AHC application to directly enter patients’ personal and medical
data.
– File an approval or consent from the data owner that certain data can be
used by others according to approved policies.
– Use the data repository for research on emergency records or other
health-related information.
– Charge AHC for data entry, which is not unreasonable:
• Given the actual costs AHC spends in order to gather and enter data in
the branch offices all over the country.
• Improving the quality and trustworthiness of data for AHC.
• Reflecting explicit data owner consent for data usage.
AHC has to comply with the latest data protection act passed one year ago. This
act requires strict control over who can see personal data and a clear statement
of the purpose the given data is used for.
Practitioner’s view
The practitioners are more concerned with individual patient records and how
they can improve diagnosis and treatment plans.
Treatments from two independent practitioners are not listed within a single
patient health history.
The patient needs to hand carry other practitioners’ diagnoses to his
preferred general practitioner if he does not want to take a chance of
important data running late in the mail.
Information shared between practitioners and hospitals is not entered into the
single treatment plan but stays on a separate paper and in separate data
sets.
The practitioner does not have a complete and conclusive health history of
the patient sitting in front of him.
Patient’s view
The patient is mostly concerned with his private health care record.
82 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
He does not have a complete and conclusive overview of his health history
and his treatment plan.
He has no capability to update, print, or store his health history electronically.
Some data is often needed to answer questions from insurance companies
and so on.
If the patient’s data is stored at a doctor’s office, it becomes useless if the
patient moves to another area.
The patient does not have the chance for a conclusive discussion with other
experts to settle his mind.
It is hard to estimate if a disease was cured fast and effectively.
Patients participating in donor programs (blood, organs, and so on) cannot
store data or explicit consent electronically on a centralized database.
Very rarely does a patient still have access to his childhood history:
– It is very difficult to reconstruct a child’s health history.
– Data is basically lost.
– For parents, it is often very beneficial to know their own health problems in
their youth.
– Parents are typically not available to answer these questions when
information is needed.
Emergency view
AHC has become aware of a strong increase in the fatality rate within the
emergency system. That high rate is supported by missing online health
information urgently needed in any emergency situation.
AHC has realized that a home-grown solution that includes security and privacy
functionality exceeds its capability by far, because it would exhaust all available
IT resources and therefore lead to tremendous maintenance costs over the long
term. A home-grown solution would not be flexible enough to allow easy changes
of the applications after being released because security and privacy functions
are hardcoded into every single application. This approach also requires
recoding every time a privacy policy needs to be updated.
The emergency system could also be used for application testing, because it is a
closed environment and nicely controlled compared to the many thousands of
individual practitioners across the country.
AHC has answered this challenge with three statements on how it wants to
regain control of the health system.
1. Improve health treatment by sharing the latest and most accurate health
records with practitioners, hospitals, and emergency services.
84 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
2. Have available consolidated information on the health status of the
population.
3. Apply statistical methods to understand the average costs of treatments.
AHC also understands that it needs to reduce manual data handling in the
branch offices rather than have the practitioners doing this, so they can achieve
the following targets:
Reduce costs of data handling and operation.
Increase data quality.
Ask the patient and practitioner for consent to use certain data to analyze.
Comply with the data protection law by minimizing data handling.
Changes will also result in stronger guidance for use by patients, practitioners
and AHC.
Patients are asked for stronger participation and interaction to make certain
choices.
Patients are asked to articulate preferences, indicate participation in health
prevention programs or to provide certain health-related information.
Abiding with legal regulations, providers offer their patients certain options
and controls if they want to participate in bonus programs.
Choices can have impact on the quality of service and on the costs of
premiums.
Patients can change preferences and contracts more frequently and easily.
They can compare benefits they get from AHC and information they need to
provide to AHC, so they can finally select the offer that best fits their personal
situation.
The new insurance contracts contain a section where patients are asked to
explicitly agree to AHC’s analytical methods that optimize services and costs.
These contracts have to describe how health data will be used according to
the signed contract. Thereafter, AHC assumes implicit consent as long as the
contract is in place.
86 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
About policy and consent lifetime in a health record:
It is the patients’ personal choice to choose a specific health provider and
contract. The health provider has to inform the patient about his policies
and how he will use PII data. The patient always has the choice to change
his contract for which a certain policy applies.
From an IT point of view, changing a contract must be immediately
conveyed into the access control procedures for personal and
health-related data so that internal analysts can only see records with
proper access enforcement.
Be aware that the explicit consent a patient has given under an old policy
will stick to this data. This policy decides how this old data can be used. For
example, changes only have impact on new data collected under the new
consented policy, whereas the internal analyst still can see the old data of
the patient records he was already entitled to see before.
We have kept the examples as simple as possible. Rules are intended to provide
the reader with basic ideas about how he could match and adjust his own
examples within our environment.
88 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
consent when this general practitioner submits this treatment record to the
health service.
– If the patient has undergone a specific treatment and both parties do not
consent, neither the patient nor the general practitioner nor another
practitioner can see details of this treatment (this would also apply for
diseases under regulation or legal control).
Consent: Explicit consent per health record from either or both patient
and practitioner could be used to share some information between
practitioners.
It can also be used for other reasons, such as a patient wants to see
another practitioner for a second opinion. Approval of the PGP could be
indicated by a given consent.
Becoming an HMO
If AHC transitions to become a Health Management Organization, it might want
to use the data in a much more sophisticated and advanced way. HMOs tend to
contract with a set of doctors to which their clients (patients) must go. They have
agreements in place with the practitioners to monitor the average costs per
disease and treatment.
The AHC analysts become responsible for finding the most qualified doctors with
the highest efficiency for certain treatments on specific diseases. The
researchers’ responsibilities include supervising patients actively participating in
certain prevention programs or motivating them to undergo regular health
checkups to lower risks.
As an HMO, AHC can give rewards to patients for participating in these programs
and for giving consent to share treatment data, so the researchers and analysts
can see this data in the system and be more effective.
Be aware that it is the patients’ choice to sign up for a certain health provider and
not the technology provider’s. The HMO needs to communicate its policies to
monitor a set of data and to prove via audit lists that it abides with its policies and
signed contracts.
90 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Finally, let us consider a few patient choices:
The insured must have the free choice to opt-in or opt-out from certain
services at any time by simply changing their contract.
Data access for an AHC analyst must immediately be altered if a patient
changes certain opt choices.
Be aware that if a policy is changed, the consent a patient has given under an
old policy sticks to this data. Changes only affect new data collected under the
new consented policy, that is, an analyst can see your old data forever.
The strength of this authentication method might be justified for showing more
than just organizational data, such as date of appointment and doctor’s name.
Since the information request comes from the patient himself, the application
does not need to return the patient’s personal data because the user should
know about this anyhow.
If the patient submits a more advanced data request, such as asking for the
reason for treatment or for the diagnosis, we suggest a two-factor authentication.
This could mean providing a second password (one-time password) from the
provider, which could be a list with transaction numbers that is sent to his
registered e-mail or his residential address, or it could come via SMS to his
registered mobile phone as a single-use password. If the patient can provide
both secrets, user ID/password and one-time password, all related data is
displayed in the application.
This discussion shows that the type of authentication cannot be tied to the
person alone, but also to the type of application. Depending on the application
that somebody wants to execute, we might want to provide mechanisms of
step-up authentication to enforce a stronger authentication for the particular data
provided by the application.
Emergency
In addition to strong authentication mechanisms, access to the emergency
application should be limited to specific IP addresses for designated workstations
at hospitals and other emergency rooms, since a successful login means
unlimited access to data within the national health system.
The security aspects of this solution include both access control (security) and
data protection (privacy) points of view. Access threats can be minimized using
92 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
proper access control tools such as Tivoli Access Manager, and data protection
can be enforced using Tivoli Privacy Manager.
Tivoli Access Manager controls access on an IP address level and also supports
multiple authentication methods such as user ID/password, certificate, and other
tokens, as well as two-factor authentication. Based on the data access purpose
and the authenticated user’s credentials, Tivoli Privacy Manager can filter the
data presentation according to the business policy and de-identify the results.
Privacy Manager also logs every data access if required. Table 4-1 shows a
typical emergency data display with all patient information necessary for the
medical personnel without showing any identifying personal data except patient
ID. If required, even this ID can be faded out.
94 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Independent researcher group
The independent researcher group represents an independent researcher
called IndependentResearcher.
The Tivoli Access Manager group name is am_ahc_indresearch_group.
Emergency group
The emergency group represents health services providers called
EmergencyProviders.
The Tivoli Access Manager group name is am_ahc_emergency_group.
After defining Tivoli Privacy Manager for e-business groups and their
participants, we have to match Privacy Manager IDs to Access Manager IDs.
This is required in order to call out from Privacy Manager to Access Manager
when requesting a group membership evaluation of people accessing the
system. The actual group membership information is maintained in the LDAP
directory by Tivoli Access Manager. The corresponding group mapping table
(depicted in Figure 4-2) as well as the user mapping table (shown in Figure 4-3
on page 96) is maintained within Tivoli Privacy Manager.
In our example we use a patient enquiry application that allows doctors to query
details about patients. Since some of this data is highly sensitive, it is protected
according to our privacy rules. These rules may result in different access rights
96 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
according to the role the doctor has logged in as. For example, if the doctor logs
in as a researcher, he may not see as much details as he would if he had logged
in as an emergency ward worker.
Let us take a closer look at the different actors involved in our application
example.
98 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
GeneralPractitioners and Nurses may access all medical and identity
information for the purpose of Emergency_treatment if they are using a
workstation with a fixed, authenticated IP_address.
AHC-Analysts may access medical and identity information for the purpose of
Bonus_calculation if the patient has consented, and the category for the
treatment was CheckUp.
AHC-Researchers may access all medical information and patients’ sex, age
and area code for the purpose of Improve_Treatment if the patient has
consented, and the patient’s GeneralPractitioner has consented, and the
purpose of treatment was not STD_related.
Independent Researchers may access all medical information for the purpose
of Medical_Research if the patient is from the same area code as the
practitioner, and the age of the patient is over 21, and the treatment was
STD_related.
Independent Researchers may access all blood data for the purpose of
Blood_Level_Supply_E-mail if the patient has consented, and the purpose of
the treatment was not STD_related.
Independent Researchers may access all medical information for the purpose
of Medical_Research if the blood researcher is from the same area code as
the patient, and the patient has consented, and the patient’s
GeneralPractitioner has consented, and the treatment was Blood_Test, and
the purpose of the treatment was not STD_related.
Examples
In our examples we show four use cases of our privacy policy usage statements
above. Table 4-3 lists our example patient data with the matching patient name
and ID.
1. In the first example, parents can see their children’s health records if the
children have not opted out or the consultation was not related to birth control
Figure 4-5 Status Report seen by the parental guardians of Heidi and Mary
100 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 4-6 Records for PGP Dr. HaiFun
2. Your preferred general practitioner can see a medical treatment in his medical
records if a patient has undergone another treatment, for example as a
second qualified opinion, executed by another practitioner, if the patient and
the other practitioner have consented to show the record. Take a look at
Figure 4-7 on page 102 for an overview of Dr. Dave’s patient and medical
records showing treatment from Dr. Otto for Tony.
3. A health checkup can be seen from an AHC Analyst if the health plan
currently in place between patient and AHC does allow them to monitor
appropriate participations of the patient in the program so they can approve a
bonus without manually checking any bonus certificates the doctor might
have to sign and the patient has to mail in to AHC.
4. An independent researcher from a non-profit blood donor organization can
make the system send e-mail to all subscribed blood donors of a special
blood type if the emergency system is very low on supplies of blood group
0-extragood, without knowing the name or any other details from the
subscribed donors. An example list of people who have consented to be
selected and the reason for treatment was not excluded by a legal issue (such
as STD-related) is shown in Figure 4-8 on page 103. The researcher himself
does not see any patient details but only selects individual records. The
e-mails are sent by the application anonymously.
102 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 4-8 List of blood research records
Security recommendations
To protect the critical data in our repositories, personalized strong authentication
methods such as SmartCards with certificates or biometrics should be used as
tokens to authenticate authorized participants properly.
Other security architecture considerations include but are not limited to the
following list of tasks:
Improve network security to control access to servers.
Use security zones to control access to sensitive servers and applications.
Use firewalls or other gateways to control communication between different
security zones.
Block unwanted traffic and monitor authorized traffic.
Use reverse proxy with authentication and authorization capabilities for
access control to administration interfaces.
Place critical service and support servers in separate networks and block
access using routers or firewalls.
Improve system security to control activity on systems.
Remove unneeded components.
A more complete discussion on these topics can be found in the IBM Redbook
Enterprise Security Architecture with IBM Tivoli Solutions, SG24-6014.
104 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Monitor into the application. The section follows the general analysis and design
considerations required when developing a new monitor.
Access Manager
Access Manager User Registry
(LDAP)
Access
Online Manager
External
iv_user Health JRTE
WebSEAL
Application
Application
Privacy
Privacy
Manager
Montor
WebSphere WebSphere
Privacy Manager
Application
Policy +
Database
Configuration
Internet
DMZ Internal Production Network
Since access to the source code is available, the privacy solution design will
employ an embedded Application Callout Monitor.
PrivateMedicalDAO
Command Factory (Wrapper)
Privacy
Controller Enforcement
Servlet Value and Access MedicalDAOImpl
Objects
Business
Logic
PrivatePatientDAO
BusinessCommand (Wrapper)
(Emergency,
Client or Research ... ) Value Privacy
Browser Objects Enforcement
PatientDAOImpl
and Access
VIEW Storage
(Emergency, System
Research ...)
Thread
Context
MonitorSessionEJB
PatientDAOImpl
AHC
Monitor
Assistant
Tivoli Privacy MedicalDAOImpl
Manager
Reference Monitor
The Web application conforms to the standard J2EE application patterns. The
application is structured along well-defined areas of responsibility related to
presentation layer, business layer, and data access layer.
The main page of the application allows a user to log in and search for multiple or
individual records related to the patient’s identity and medical history details. For
our example, a combo list allows the user to specify a business purpose.
Purpose identification is discussed further in the following sections.
106 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
A controller servlet receives all URL requests. The servlet employs the command
strategy as a link to the business logic. Command objects implement a Java
interface, and are created by the controller using a factory. Concrete instances
are created based on the purpose encoded into the requested URL.
This existence of a well-defined data access layer is significant for the integration
of the callout monitor. This layer is closest to the storage system, and is the
primary location for the monitor callouts. In our example, the data access layer is
represented by the MedicalDAOImpl and PatientDAOImpl objects.
/**
* Wrapper method of ReferenceMonitor.monitoredItemConsent.
*
* @see ReferenceMonitor#monitoredItemConsent
*/
public void monitoredItemConsent(String masterKeyValue,
ArrayList monitoredItemNames,
int consentOperation)
throws ReferenceMonitorApplicationException,
ReferenceMonitorRemoteException,
MonitorAssistantException,
java.rmi.RemoteException;
/**
* Wrapper method of ReferenceMonitor.monitoredItemConsent.
*
/**
* Wrapper method of ReferenceMonitor.monitoredItemConsent.
*
* @see ReferenceMonitor#monitoredItemConsent
*/
public ConformanceCheckResults monitoredItemConformanceCheck (
String masterKeyValue,
ArrayList monitoredItemNames,
int accessOperation,
String userid,
String assertedUserid,
String applTask)
throws
ReferenceMonitorApplicationException,
ReferenceMonitorRemoteException,
MonitorAssistantException,
java.rmi.RemoteException;
}
The primary reason for the session bean wrapper is to allow for the declarative
management of J2EE XA transaction context. In some situations it may not be
desirable to include the Reference Monitor in the same transaction context as the
monitored application. Specifically, ReferenceMonitor.init() typically needs to
execute outside the transaction context of a monitored application. The
deployment descriptor marks the init method with TransactionNotSupported.
108 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
*/
public class TPMMonitorBeanBean implements javax.ejb.SessionBean {
refMon.monitoredItemAccess(masterKeyValue, monitoredItemNames,
accessOperation, userid, assertedUserid,
applTask, confResults);
}
// Call init.
try {
refMon.init(monAssist, monProps);
} catch (ReferenceMonitorException e) {
throw new CeateException(...);
}
}
For this J2EE application, the storage system is represented by the data access
objects (DAO), specifically PatientRecDAO and MedicalRecDAO and the value
objects they return.
For this example, the storage location names are defined as constant strings on
each of the DAOs. An example is shown in Example 4-4.
Other options exist for obtaining the storage location name. For example, if the
DAO handles access to a relational database using JDBC, it might be possible to
use the JDBC metadata objects to obtain the column names within the database.
Another option might consider that the property names of the value objects
returned from the DAO are the storage locations. Using Java class reflection, it is
possible to obtain the storage locations names.
110 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
MonitorAssistantException {
return StorageNamesHelper.getMonitoredItemNames();
}
/**
* Worker method for getMonitoredItemNames. Sets up
* name as a key into returnValue. The name is associated
* with a hashtable represented attributes about the storage
* location name. The only attribute currently supported
* is DESCRIPTION.
*/
private static final void addItem(
String name,
String desc,
Hashtable returnVal) {
// create the Hashtable for the description
Hashtable monitoredNameEntry = new Hashtable();
// store the description in the Hashtable
monitoredNameEntry.put(DESCRIPTION, desc);
// store the monitored item in the return value
returnVal.put(name, monitoredNameEntry);
}
/**
* This method provides the implementation of the
* AhcMonitorAssistant.getMonitoredItemNames().
*
* The storage location names are available as constant
* strings on each of the DAO interfaces for Patient,
* Provider, and Medical DOA's.
*
* @return The hastable containing storage locations
* to be registered for Patient, Provider, and Medical
* records.
*/
public static final Hashtable getMonitoredItemNames() {
// initialize the return value
Hashtable returnValue = new Hashtable();
// Patient locations
addItem(
PatientRecDAO.PATIENTID,
PatientRecDAO.PATIENTID_DESC,
returnValue);
addItem(
PatientRecDAO.BIRTHDAY,
PatientRecDAO.BIRTHDAY_DESC,
returnValue);
addItem(
PatientRecDAO.CITYCD,
PatientRecDAO.CITYCD_DESC,
returnValue);
// etc...
return returnValue;
}
Virtual storage locations are usually required when privacy policy rules have
conditions that refer to data or state information not stored in the storage system.
The locations typically represent temporary state information about the
transaction or execution context of the given data access at a given point in time.
112 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
patient-owned data that needs to be identified. For the AHC online system, the
storage location named PatientId has been chosen. This location uniquely
identifies a record in the patient table. It can also identify each medical history
record in the medical history table.
The PatientId represents the master key location for the Reference Monitor. The
AhcMonitorAssistant informs the Reference Monitor of the master key through
the getMonitoredItemMasterKeyName() method. This is shown in Example 4-7.
Note: This example has been developed using WebSphere Application Server
V4, which supports the Servlet Specification Version 2.2. Under Servlet
Specification Version 2.3, it might also be possible to use
HttpServletRequest.getUserPrincipal() to determine the authenticated user’s
identity.
The technique used for this example is to modify the business logic and data
access logic invocation methods to include a parameter for the accessor value.
This is feasible because the application does not have a high level of complexity.
The same technique that was used for identity propagation is used for application
task value propagation to the data access layer.
/**
* This method retrieves the patient record object for the
* patient identified by key.
*
* @param patientId The patient id for which identity
* data should be obtained.
* @result The PatientRecVO populated with values from the
* storage system.
* @throws DataAccessException if one the following occurs:
* No records exists for the given key.
* An error occured reading the database.
*/
public PatientRecVO findByKey(String patientId) throws
DataAccessException;
114 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
/**
* This method retrieves all patient record objects
*
* @result A list of PatientRecVO populated with
* values from the storage system.
* @throws DataAccessException if one the following occurs:
* An error occured reading the database.
*/
public List findAll() throws DataAccessException;
/**
* This method retrieves the medical record object for the
* patient identified by key.
*
* @param patientId The patient id for which medical service data
should be read.
* @result The MedicalRecordVO populated with values from the database.
* @throws DataAccessException if one the following occurs:
* The access does not conform to privacy policy.
* No records exists for the given key.
* An error occured reading the database.
*/
public MedicalRecVO findByKey(String patientId) throws
DataAccessException;
// Wrapped implementation
private MedicalRecDAO daoImpl = null;
/**
* Disabled
*/
private PrivateMedicalRecDAO() {
super();
}
/**
* Create a new wrapper for a MedicalRecDAO.
*
* @param dao The concrete implementation of the DAO
* to be wrapped.
* @param accessorId The id credential of the user
* performing operation with this DAO.
* @param purpose The business or application purpose
* for using this DAO.
*/
public PrivateMedicalRecDAO(MedicalRecDAO dao,
String accessorId,
String purpose) {
super();
this.daoImpl = dao;
this.accessorId = accessorId;
this.purpose = purpose;
}
/**
* A privacy enabled implementation of database lookup. This
* method retrieves the medical record object for the
* patient identified by key. A privacy enforcement check
* and access notification is performed against TPMS.
* Enforcement is done by obfuscating property values of
* the result value object based on conformance check.
* The enforcement achieves field level access control.
*
* @param patientId The patient id for which medical service
* data should be read.
* @result The MedicalRecordVO populated with values from the database.
* @return MedicalRecVO object that may have obfuscated property
* values based on privacy conformance checks
* @throws DataAccessException if one the following occurs:
* No records exists for the given key.
* An error occured reading the database.
116 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
*/
public MedicalRecVO findByKey(String patientId) throws
DataAccessException {
// do the real data operation
MedicalRecVO result = this.daoImpl.findByKey(patientId);
// do a conformance check and enforcement.
PrivacyEnforcement enforcement = new
PrivacyEnforcement(this.accessorId, this.purpose);
enforcement.enforcePrivacy(result);
// do an access notification
PrivacyAccess access = enforcement.createPrivacyAccess();
access.accessNotifcation(result);
return result;
}
/**
* For each value object
*/
public List findAll() throws DataAccessException {
// do the real access operation
List result = this.daoImpl.findAll();
Each of the find methods inherited from the interface definition use the wrapped
DAO implementation to perform the actual data accesses. However, after the
access has returned control to the privacy wrapper, conformance checks,
enforcement and access notification are performed against the Tivoli Privacy
Manager server.
Real-time enforcement
Real-time enforcement is linked very closely with access detection. As shown in
Example 4-9 on page 115, the enforcement occurs before the access
The conformance check callout to the Tivoli Privacy Manager server, and
enforcement has been encapsulated in the class PrivacyEnforcement. This class
has methods to handle MedicalRecVO and PatientRecVO objects. Example 4-10
shows the logic related to MedicalRecVO enforcement.
private PrivacyEnforcement() {
super();
}
/**
* Factory for PrivacyAccess notification handler.
* This is the only way to create such objects.
*/
public PrivacyAccess createPrivacyAccess() {
return new PrivacyAccess(this.getAccessorId(),
this.getPurpose(),
this.getAccessedItems(),
this.getCcr());
}
118 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
/**
* Do a conformance check and enforcement for the
* given MedicalRecVO. This method uses MonitorManager
* to do the JNDI lookup of the Refmon wrapper bean.
*/
public void enforcePrivacy(MedicalRecVO medRec)
throws DataAccessException {
try {
// JNDI lookup wrapper
MonitorManager mon = new MonitorManager();
// Set context information that will be
// required by the AhcMonitorAssistant.
// PrivacyThreadContext is a wrapper for
// ThreadLocal storage.
PrivacyThreadContext.setContextItem(
PrivacyThreadContext.MEDICAL_RECORD, medRec);
PrivacyThreadContext.setContextItem(
PrivacyThreadContext.ACCESSOR_ID, this.getAccessorId());
// do the conformance check
ConformanceCheckResults ccr =
mon.monitoredItemConformanceCheck(medRec.getPatientId(),
StorageNamesHelper.getMedicalRecNames(),
ReferenceMonitor.ACCESS_FOR_READ,
this.getAccessorId(),
null,
this.getPurpose());
this.setCcr(ccr);
// now filter the result value object properties
this.enforcePrivacy(medRec, this.getCcr());
} catch (MonitorManagerException x) {
// handle error
} catch (ReferenceMonitorException x) {
// handle error
}
}
/**
* For each false value present in the CCR, set the
* corresponding property value on the MedicalRecVO.
*
* For each true value present in the CCR, add the storage
* location name to the list of conformant accesses.
*/
private void enforcePrivacy(MedicalRecVO medRec,
ConformanceCheckResults ccr) {
Of particular interest in the example above is the use of the thread local storage.
Before the enforcement callout code invokes the Reference Monitor, the value
object being considered and the accessor identity value are placed in the thread
local storage. This is done to make them available to
AhcMonitorAssistant.lookupMonitoredItemValues(). The Reference Monitor API
does not provide any means to accomplish this. This technique is useful for
virtual storage locations. It also helps to improve performance, since the values
already read from the storage system are available in the value object.
120 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Example 4-11 Lookup monitored item values
public Hashtable lookupMonitoredItemValues(
String masterKeyValue,
ArrayList monitoredItemNames)
throws MonitorAssistantException {
Hashtable result = new Hashtable();
contextData = PrivacyThreadContext.getContextItem(
PrivacyThreadContext.PATIENT_RECORD);
if (contextData != null) {
PatientRecVO vo = (PatientRecVO)contextData;
result = LookupValueHelper.lookupPatientMonitoredItemValues(
masterKeyValue,
monitoredItemNames,
vo);
}
return result;
}
As can be seen, the thread local values are retrieved. A helper class performs
the core work of the lookup. The helper class implementation is shown in
Example 4-12.
// etc...
if (name.equals(VirtualStorageLocation.AUTHENTICATION_TYPE)) {
String val = (String)PrivacyThreadContext.getContextItem(
PrivacyThreadContext.ACCESSOR_AUTH_TYPE);
if (val != null) {
result.put(name, val);
} else {
result.put(name, "");
}
continue;
}
122 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
if (patVO == null) {
patVO = getPatientRecordForKey(masterKeyValue);
}
result.put(name, patVO.getBirthday());
continue;
}
if (name.equals(PatientRecDAO.CITYCD)) {
if (patVO == null) {
patVO = getPatientRecordForKey(masterKeyValue);
}
result.put(name, patVO.getCityCd());
continue;
}
// etc...
} catch (DataAccessException x) {
x.printStackTrace(System.out);
result.put(name, "");
}
}
return result;
}
/**
* Get a patient identity record from the data base.
* This method uses the core PatientRecDAOImpl class to
* do the lookup. Don't use the PrivatePatientRecDAO
* because that would trigger the whole conformance
* and lookup logic again resulting in a infinite
* loop.
*/
private static PatientRecVO getPatientRecordForKey(String key)
throws DataAccessException {
PatientRecVO result = null;
PatientRecDAO dao = new PatientRecDAOImpl();
result = dao.findByKey(key);
return result;
}
4.7 Conclusion
The example code discussed satisfies the needs of the four use cases
mentioned in 4.5.6, “AHC privacy policy usage statements” on page 98. The next
steps for such a project would definitely include testing use cases that exercise
The design outlined, based on monitoring at the data access layer, provides an
extensible framework for ongoing enhancements to the application. If the
application data model is expanded (for example, new tables and data access
objects), then a corresponding privacy wrapper for the DAO can be easily
implemented. If access to new conditional values is required, the use of the
Reference Monitor helps to centralize implementation in the Monitor Assistant.
This is also true for policy changes that may require new purposes and storage
locations.
124 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5
Most of these people need help from a third party which is typically the
government or a local organization helping them to get along with the necessities
of their daily life.
In full respect of the situation an individual might suffer from, the functional
requirements of a system supporting named situations can best be described as
Customer Relation Management (CRM), where client representatives act on
behalf of the client. They have to follow legal guidelines and need to respect
options and choices made by the client given in writing or over the telephone.
Acting on behalf of a client is a very common situation for any call center and
must therefore be a key component of every CRM system. However, in this
section we focus on the privacy issue.
The ASA understands itself as the attorney of citizens who find themselves in
emergency situations resulting from a personal or economic catastrophe.
Supported situations might also result if this person is not capable of participating
in the regular social life of the community without help from others.
To serve citizens best, the ASA is organized into multiple service units ( hereafter
called branches). Every branch is typically named according to the reason the
individual turns to the ASA, and employees are well trained for their particular
topics.
Therefore the ASA needs to maintain multiple databases, one for each branch.
Within the branch, access rights to certain client data is restricted to a particular
case worker only.
Note: The general privacy requirements simply state that access to data must
only be given to people approved for a certain set of data of a client. Data
access for unauthorized persons must be prevented by any means.
Checking further details of this regulation shows that an approval for any
individual worker only covers a few data entries out of the full range of client
data stored in the multi-branch databases of the ASA. But access rights must
also relate to the purpose of the request. To manage this Matrix of Rights is
perhaps the most challenging requirement we have been working through.
126 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5.2 Architecture and procedures
The ASA is organized into multiple branches, which are tasked to help citizens
with their current needs. Within every branch, case workers deal with client
cases. Every branch has its own dedicated set of workers, and interaction across
branches is kept to the absolute minimum. Also, within a single branch
communication between workers about individual issues of a client is very
restricted.
Each item of information passed along to another worker or another branch has
to contain a reason for request and the requester has to prove the need to know.
Managers are not allowed to see details of client data, but need to have a basic
knowledge about any case. Problematic situations with a client can be escalated
to management, and management becomes responsible for solving the issues.
In the remainder of this chapter we do not cover all branches and do not discuss
any specific implications, but rather want to use a particular case with an artificial
set of characters to better illustrate the current operation model. In this way, it is
much easier to describe the shortfall of the actual implementation and discuss
possible improvements that can be achieved using IBM Tivoli Privacy Manager
working with the ASA Siebel application.
The basic set of client data is very similar within every branch, but separation of
data is a legal requirement.
For every client a complete set of data is stored in the branch-related database
where the client requests help. Therefore, the client has individual customer IDs
in every single branch. A graphical representation of the distinct databases is
shown in Figure 5-1.
We categorize data into data blocks according to the special needs of every
individual branch:
Personal identity data (name, address, phone number, etc.)
Personal preferences data (language, religion, etc.)
Personal health-related data (disabilities, treatments, drugs, etc.
Personal finance-related data (income, benefit plan, spending behavior, etc.)
Personal identity-related historic data (alias, foster, caretaker, etc.)
128 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Personal behavior-related data (friends, contacts, anti-social, violent, etc.)
Note: The basic data set of our individuals and the requirements exploited in
our human services example are very similar to any insurance company or
financial institution maintaining customer data-handling contracts, connecting
insurance agencies and providing help centers.
The challenging part of this chapter is to explain the special situations the
clients of human services are involved in, the special data case workers need
to retrieve on behalf of their clients, and the purpose this data is used for.
Human services is one of the most challenging use cases and definitively
requires the most secure solution to protect data from unauthorized access.
Let us take a closer look at some data that is collected by the case workers. This
data includes many delicate details that are typically stored in the client’s data
record within the different branch databases.
Relevant data is often split into two parts: Data fields indicating evidence and a
course result, and data fields with details on the client. Both field types are
protected individually and by separate privacy rules.
Child Protection data
– (Preferred) name, sex, age, address
– Parents (name, address, age, occupation, foster parents Y/N)
– Siblings (Y/N, name, sex, age, school, step-siblings Y/N)
– School (address, contact person, school problems)
– Benefits from ASA - Child Protection unit
• Case worker
• Recommended accommodation
• Other benefits and support
– Alias names
– Relatives (address, relation, caretaker Y/N)
The Juvenile Justice branch has similar entries but includes more Y/N flags:
Juvenile Justice
– (Preferred) name, sex, age, address
• Lives alone Y/N
• Has partner Y/N
• Contact to parents Y/N
– Alias names
– Parents, name, address, occupation Y/N, details, police record Y/N
• Divorced Y/N, (responsible parent)
• Single parent Y/N
• Foster Y/N
• Caretaker (carer) Y/N, address, name of birth, parents, relatives Y/N
– Siblings Y/N, name, sex, age, school, step-siblings Y/N
– Education
• Contact school worker
• School Y/N, knows conviction Y/N, rude Y/N, and so on
• Apprenticeship Y/N, company, knows conviction Y/N, rude Y/N
– Behavior
• Contact street worker
• Anti-social Y/N, details
• Rude Y/N, details (responds to reasonable facts, objections)
• Violent Y/N, details (contacts, and so on)
• Drugs Y/N, details (contacts, and so on)
• Steals Y/N, details (contacts, and so on)
– Benefits from the ASA - Juvenile Justice
• Case worker
• Recommended accommodation
• Treatments, therapies
– Previous convictions still active Y/N, details
– Police record Y/N, details
130 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
– Under strict observation Y/N, details
– Contact information
• Name and address of friends
• Name and address of associates the child visits regularly
• Confessed membership with groups Y/N, details
Public Housing
– Name, address, sex, age
• Martial status (married Y/N since, divorced Y/N since, single Y/N)
• Partner Y/N
• Children (name, sex, age, school Y/N, including step and foster
children)
• Number of persons in household
– Occupation
• Applicant: training, employed Y/N, income, details
• Partner Y/N: training, employed Y/N, income, details
• Other adults Y/N: education, employed Y/N, income, details
– Benefits from the ASA - Public Housing branch
• Case worker
• Approved number of rooms
• Actual number of rooms
• Other benefits and support
Mental Health
– Name, address, sex, age
– Spouse Y/N
– Caretaker Y/N, name, address
– Children Y/N, name, sex, age, school, problems, active foster Y/N
– Employed Y/N, (employer knows about problem: Y/N), contact worker
– Personal situation
• On medicine Y/N, drugs Y/N, mental confusion Y/N, suicidal Y/N
(speaks about it, committed attempts), can live alone Y/N
– Medical history
• Disabilities Y/N, details
• Abused Y/N, details
• Raped Y/N, details
• Active treatments Y/N, details (depression, surgeries, and so on)
• Former treatments Y/N, details
The ASA department manager assigns case workers or lead case workers, but
cannot see detailed client data.
132 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 5-2 An atypical household: The Privacy Manager family
Services provided
Table 5-1 gives an overview of what services are provided by the ASA.
Mary x x Mother
Jim x x x Foster-son
Peter x x Son
Bob x x x Son
Paul x x Household
member,
foster care
Matthew x x Mary’s
friend, Paul’s
stepfather
134 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Betty: case worker_2, Disability, assigned to Mary and Bob.
Charlie: case worker_3: Child Protection, assigned to Jim and Bob.
Bob informs Charlie about violence of Matthew towards his step-son Paul, Jim
and Mary and his violence influence on Peter.
Dan: case worker_4: Juvenile Justice, assigned to Peter.
Egon: Family case worker for Mary and assigned lead case worker for this
household. He enrolls Matthew and Peter as new household members and
adds Matthew as new partner of Mary.
Fran is the front-desk case worker taking calls from police, hospitals and so
on.
After a client appointment, the case worker performs the following tasks:
Write a report.
Store some of the data in the branch-related database.
Send a visitation memo to the lead case worker.
As the lead case worker, Egon is informed by the individual case worker on his
current activities. He can maintain his own folder to archive team results, but
cannot access any data other than that within his own branch.
The housing benefits are based on some very generic statements such as:
Marital status, age, number of persons in household and so on
Income
Number and age of children
Bonus (based on degree of disabilities, social programs and therapies they
participate in)
However, Ann can only see the extra benefits Mary gets from public housing and
she cannot access the data of the other branches to check for the extra benefits
Mary would be entitled due to a Bonus (see list above). Also, Ann cannot access
the income of the other household members and she cannot see the latest
changes made by Egon entering Matthew and Peter as new household
Ann expects the paperwork to be available soon and asks Mary to return for
another appointment. Because Mary needs to take a half day off to make it to the
ASA office, this is very inconvenient. Although Ann trusts Mary, she cannot sign
for any additional benefits before any confirmation from the other branches is
available.
If Mary wanted to have a consolidated entitlement on her benefits from the ASA,
she could go to the supervising manager. He can pull together all papers and
data needed. She could also ask him to start working on her additional requests
for more benefits. At the end he would make a fair judgment, but Mary does not
feel comfortable with this procedure, because this calculation is done manually,
and the supervisor will have very deep knowledge of all her very personal data
and those of the children. On top of this, the supervisor process is also
acknowledged to be very slow.
The ASA further requires that the implementation must be easy and flexible
enough to maintain and change existing privacy definition and protection rules,
so the ASA can easily solve the following tasks:
Adapt to changing reasons and rules why benefits are given to clients.
Make use of knowledge other parties have gained about ASA clients.
Include latest direction and policies from the government.
Comply with new guidelines released by the Social Security Administration.
It repeatedly happens that management can access too many details on client
data, which has caused some irritation and has biased management in their
decision. Since management must assign a lead case worker, they need to see
certain data before they can decide on a lead case worker acting for a certain
household. They also have to adjust and balance the workload for every case
worker and therefore need to figure out the case workers’ priorities to protect
136 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
most wanted case workers. An alert-notification capability to enhance case
worker safety was a key issue for many years and is urgently needed. However,
alert notification needs the same granularity as we have discussed for the client
data.
As of today, the front-desk worker Fran can connect the police with any juvenile
case worker on the phone to discuss the actual police case. The case worker
does not have access to any information on the juvenile’s history with the ASA,
nor does he know this juvenile by heart, nor his parents or friends, because he
might not be responsible for the district the juvenile lives.
Later we will return to this scenario and check how the new business vision
changes this inquiry.
Be aware that the ASA will become involved in this case anyhow, because at
the end they need to work with the juvenile and with his parents.
The ASA will be called in on the court hearing of the juvenile, and therefore
needs to assign a case worker for the juvenile.
Therefore, it might be very beneficial for both juvenile and ASA to start this
interactive process as soon as a police call comes in.
However, after a recent violent incident at the local school, all media have raised
severe doubts about the ASA’s performance and efficiency. The media have
pointed to the fact that the ASA’s client data is not shared between workers
across branches. Some journalists have done some quick research on the case,
Since these details have been broadcast all over the media, they are generating
strong pressure on the ASA management to revise procedures and come up with
a conclusive answer to improve operational efficiency and protect the privacy of
client data to a level that is legally requested.
The ASA needs to make client data access more convenient and efficient for
case workers and for other staff.
138 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
They also want to be ensured that no modification of existing applications will be
needed when extending this project to other branches in the future by
externalizing the complex data protection issue outside of their Siebel
application.
This external privacy layer needs to take care of privacy issues related to legal
requirements of the four branches that will be linked together in the first project
phase, but also needs to be extendable for future requirements of the other
branches, which are planned to be integrated in the next project phase.
The privacy layer also needs to take care of any adjustments according to
upcoming privacy rules and regimentation either due to legal changes or (much
more likely) to changes in political guidance without touching the implemented
and operational Siebel CRM applications.
The privacy layer is also intended to support an easier integration and more
effective communication with participants working outside of the ASA offices but
linked into the ASA information flow, such as general health care practitioners,
nurses, and so on.
140 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5.5 Functional requirements
Management and case worker require many business functions to request client
data in order to get their jobs done, but they also need new functions to improve
and enrich client support.
The goal is to have Tivoli Privacy Manager implemented so that the ASA can
work with basic Siebel objects, prevent safeguarded data from being displayed
with Privacy Manager intercepting and checking storage location mapping, P3P
rules, and other privacy conditions.
Although Siebel functions are more preconfigured compared to the basic Web
applications we described in Chapter 4, “Health care provider using a
WebSphere application” on page 79, they are not as standardized as the Web
container described in Chapter 6, “Financial provider using multiple J2EE
applications” on page 175. Let us discuss the requirements reflecting the
scenarios we have discussed at the beginning of this chapter when describing
the shortfalls of the current ASA system.
Using this request, the front desk worker can find the juvenile (and his parents) in
the ASA database with the following intentional omissions:
She cannot see other branch data for the juvenile or the parents.
She can only verify basic dependencies, such as who the existing case
workers are.
If the police provides more detailed information in the call by specifically asking
the ASA for Peter’s case (evaluate_police, Peter) more immediate actions are
possible.
Fran finds Peter in the ASA database and can see or initiate the following:
– Name verification OK; the ASA can handle it.
– No address is displayed because Peter’s age is under 18 years.
– Lives at home flag shows (Y).
– Parental guardian shows (Mary, mother).
– Display lead case worker (Egon).
– Show behavior flag (Y).
– Post an alert to Egon to have Peter picked up by his parents.
– Copy Dan (case worker juvenile) for more information and preparation.
Thereafter Egon checks the data using the ASA function assess_household.
– He informs Mary to go to the police station to pick up Peter.
– He can see the Violence flag of Matthew and react appropriately.
– He and Dan can work with the police and other authorities to find some
treatments for Peter.
Mary has been picked up in the streets having a total breakdown. She has been
taken to a hospital for checkup and treatment. The hospital calls the front desk
and talks to Fran. This is the list of data accessible to the front desk to
evaluate_health for a hospital call:
Client name
Parental guardians
142 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Emergency contact
Lives with household (flag)
Household members’ behavior flag (violence)
Assigned case worker
Personal health status including medical history, active treatment, takes
drugs, suicidal, and so on
Fran can see the following details of Mary’s data by accessing the
evaluate_health function:
Name and address (verification OK; ASA: we know her and can handle case)
Lives with household (Y)
Can live alone (Y)
Medical history (Y)
On medicine/drugs (N)
Ongoing therapy (Y)
Dangerous (N)
Mental confusion (N)
Suicidal (N)
Truly responds to questions (Y)
Emergency contact: (household, name, address)
Violence-alarm household (Y) (this is Matthew, but we show no names)
Displays family case worker: Egon
Displays disability case worker: Betty
Fran notifies Betty to check with Mary immediately, and she informs the family
case worker Egon to initiate the next steps.
This system finally provides information needed by every case worker so that
he/she is much better prepared to work more efficiently in his client’s best
interest, also supporting parents, police, and community as much as possible.
The new process positions the ASA as a valuable service provider to police and
community and not as a simple data provider as before.
It prevents information being disclosed to the police that is not really needed
in this situation.
It initiates a proper enrollment process for a new case, providing the most
correct information and dependencies and at the same time preventing
duplication.
Be aware that the ASA will become involved in this case anyhow. Therefore it
is very beneficial for all parties to start the interactive process as soon as
possible.
Mary has given her consent that the ASA branches can share certain data. Also,
Matthew has agreed that his data can be shared for housing benefits.
Mary has consented to allow the housing branch to see all her
housing-related data.
Mary has not given permission to housing to see details about her foster-son
Jim (this data is kept in the child care branch).
Mary has not consented to allow any other branches to see her data.
Let us take a look at the housing list as Ann can see it using the business
function calculate_benefits. The detailed information in brackets ( ) is not
displayed to Ann. It is only given here for better understanding and visualization
of data access being prevented by Privacy Manager.
Client name, address
Household members
Household member(s) income
Household member(s) benefits from all ASA branches
Qualifying housing statements from other ASA branches (recommended
accommodation data field)
144 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
– Peter 14
– Bob 16
– Paul 17, approved; Egon: Family, Lead (for Charlie: Child care, Foster)
Income:
– Employer: Penthouse Cleaners: $12,000 per year
– Benefits ASA Family support $8,000 per year
– Benefits ASA child care: $4,800 per year (Jim, foster parents)
– Benefits ASA disability Mary: $1,200 per year
– Benefits ASA disability Bob: $4,800 per year
– Benefits ASA child care Paul: $2,400 (foster, 50% step-son Matthew)
– Benefits ASA Unemployment Matthew: $8,000 per year (unemployment
support)
Housing status: 3 bedrooms
– (Needed: 5 bedrooms)
For housing from other branches:
– Mary: bigger bedroom urgently needed, Egon: Family
(Egon: Matthew acting as family father - double bedroom)
– Bob: bigger room needed, Betty: Disability
(Betty: extended room for wheelchair to fit in)
– Jim: separate room, Charlie: Child care
(Charlie: Jim suffers from abuse and attitude by Matthew)
– Paul: separate room, growing up fast, Charlie: Child care
(Charlie: suffers from violence and attitude of his stepfather)
– Peter: separate room, Dan: Juvenile
(Dan: strong violent, Charlie: violent to brothers)
Note: Ann cannot see the details why the case workers from the other
branches have requested more room, but she can read the room-statements in
the housing field for Mary. She also cannot find out how Matthew makes his
money nor what the relations between Mary, Jim, Peter, and Matthew are.
Lead case worker Egon needs to pull together all personal data of Mary including
all qualifying disabilities from herself and all other household members. If
completed quickly he could submit the enrollment document with his laptop right
from Mary’s house and fulfill the enrollment time line.
Some data fields are not immediately accessible to Egon because of missing
consent from Mary to share data (child care and so on). However, since the
changing of consent has become an online process at the ASA, Mary can
change her consent online while Egon is still present at the house. This helps
Egon pull all necessary data for an enrollment right after the changes have been
made by Mary using his laptop.
Let us take a look at the list as Egon can see it using the business function
assess_case:
Name, address
Household member(s)
Household member(s) occupation
Household gross income
Household member(s) handicaps:
– Qualifying disabilities (own, others)
– Qualifying mental health problems (own, other)
– Qualifying partner situation (unemployed, violent)
Let us take a look at the family support detail list for Mary:
Address: Manhattan, NY, 42nd Street, 19th Floor, Tel. (190) 666 9999
Partner: Matthew, 45, unemployed
Children
– Jim 6, Kindergarten
– Peter 14, School
– Bob 16, School
– Paul 17, Apprenticeship
Total persons in household: 6
– Requestee takes care of 5 persons
Total household income: $42,000
– Requestee regularly employed: Y, employer: Penthouse Cleaners
– Last participation at a mother recovery program: 1999
146 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Health Status:
– Mary: Mental Health, level 3, Betty (Mental health)
(mental drugs since 1999, suicide attempt 1999, 2001)
Disability Status
– Mary: Hearing, 50% (Mental health)
– Bob: Wheelchair, 100% (Disability service)
Ongoing ASA treatment support for the household: temporary substitute for
mother needed
– Jim, ongoing therapy (Child care)
– Peter, difficult education (Juvenile justice)
– Bob, handicapped wheelchair (Disability service)
– Paul, special care needed (Child care)
– Matthew, home, violent (Family care)
Let us take a look at the data as the case worker can see it using the business
function assess_behavior:
Client name, address
Parental guardian
Household member(s) violence flag
Client behavior information
– Client home behavior
– Client school behavior
– Client named_friends
Client named_friend behavior
The child case worker Charlie, who is responsible for Jim, asks the family case
worker Egon for help and proposes a consultation between Egon and Mary.
Egon and Mary also discuss the possible negative influence of the friends Peter
is spending a great amount of time with.
Mary gives the names of three of Peter’s friends to Egon: (Good, Bad, Ugly).
The names were also given by Peter to Dan (his juvenile justice case worker),
so they are already stored in Peter’s data in the juvenile branch.
Egon can check the behavior flag of the named friends’ Juvenile Justice records
executing the function access_behavior provided by Mary’s ID. Mary’s ID also
enables the case worker to look up Peter’s data because Mary is the parental
guardian of Peter. Egon cannot see any details of the entries, because the data
has been entered by the general school case worker Scott after his session with
the school principal.
To avoid misuse, the requestor ID, date, and purpose of this request are written
to an audit log.
Here are the results being displayed after Egon’s access_behavior request:
Good, named_friend, violence: N
Bad, named_friend, violence: Y
Ugly, named_friend, violence: N
Let us take a look at an example. Jim’s name and medical number are explicitly
stored in the Family Support record for Mary within the data block Children
(Jim).
The ASA system offers the capability to read the behavior flag of any client and
returns the violence flag if there is any evidence filled in by street case worker
Rody.
148 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Lead case worker Egon is approved to check the ASA system for
violence_evidence but must assert Peter’s name while he is consulting Mary
(mother) before he can submit a request to check the contact-field in Peter’s
record. The request actually returns the listed names of the three juveniles that
Peter has explicitly listed.
An individual consultation between Mary and the street case worker Rody also
revealed that Peter was spending a lot of time with a gang known for small drug
deals and strong violence. Although further details are not provided, the given
answer check with case worker xyz to discuss details of contacts is good enough
for every guardian to start a discussion with the juvenile and make plans about
how to improve the situation.
Let us take a look at the data as management can see it using the business
function assign_case worker:
Client name
Client demographics
Client branch IDs
Client benefits
Household member(s)
Household member(s) demographics
Household member(s) disabilities
Ho us hold behavior flag
Management needs to see certain data of the client, including benefits that have
been requested, but also the number of household members and difficulties a
case worker may have to face when working with the household to make the best
use of the skills a case worker provides.
150 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5.6 Implementation architecture
The ASA has an already established application environment based on Siebel.
The functions required for case management are analogous to the concepts
implemented by CRM systems. This is of course the primary function of Siebel.
So the goal of this privacy monitoring implementation is the integration of the
Tivoli Privacy Manager server and a privacy monitor into Siebel. The high-level
architecture is illustrated in Figure 5-3 on page 152.
Monitor
Reference Privacy
Exit Point
Monitor Manager
(eScript)
Database
152 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5.7 Technical implementation
This section describes the technical implementation of the Privacy Manager and
Siebel integration. Technical background information related to Siebel and the
generic privacy monitor for Siebel is also presented.
Applications running on the Siebel server are built on top of the standard Siebel
architecture. A summary illustration of the Siebel application architecture is
shown in Figure 5-4 on page 154.
P re s e n ta tio n L a ye r
(C o n tro ls , A p p le ts , V ie w s , S c r e e n s )
B u s in e s s O b je c ts
B u s in e s s C o m p o n e n ts
D a ta A b s tr a tio n L a ye r
D a ta b a s e
The Siebel architecture requires that access to its stored data must follow this
sequence. The presentation layer is typically defined in terms of HTML.
Components of the presentation (for example, applets, controls, and so on) are
linked to Siebel Business Objects. The Business Objects represent major
functional areas or entities within an organization. For example, the ASA may
define a Business Object for a client case. The Business Objects are linked to
Business Components. A Business Component represents the data of major
entities within an organization. The components are composed of fields that map
to table columns managed by the data abstraction layer. A Business Component
may be used or referenced by multiple Business Objects.
154 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
5.7.2 Monitor architecture background
As with all monitors, the key design decision is where to place the monitor. Based
on the Siebel server application architecture and the general principle of
monitoring close to the data, the monitor has been integrated into the Business
Component layer. The monitor design is illustrated in Figure 5-5.
Presentation Layer
(Applets, Controls, Views, Screens)
Privacy Manager
Server
Business Objects
WebSphere
Reference
Monitor
Business Components
TPM Business Servlce
Locate Storage
Component Monitor
PII Operation Locations and
QueryEvent Assistant
Values
Web
TPM Web Serivce
Data Abstration Layer Service
Proxy
Adapter
Database
The first point to note about the monitor is that it has distributed components
executing within Siebel and WebSphere Application Server. This is required
because the detection of PII access and submission resides within a Business
Component event trigger implemented using native Siebel eScript. Instances of
Business Components allow for the registration and triggering of events when
they are accessed. A challenge for this integration is to enable the invocation of
the Java-based Reference Monitor from this eScript code. Since the PII access
and submission detection is based on Siebel event triggers, the Siebel monitor is
classified as an application exit point style of monitor.
Once detected (for example, triggered), the event handling code invokes a Siebel
Business Service. This Business Service then forwards the call onto the
Reference Monitor, which is running in a WebSphere server. SOAP/HTTP is
used to transport the calls. The SOAP invocation activates an EJB-based Web
service adapter for the Reference Monitor.
Storage location names and conditional value retrieval are performed by the
Monitor Assistant and Privacy Manager Siebel Business Service. As always with
the Reference Monitor, the Monitor Assistant is requested to obtain the values of
given storage location names identified by a master key value. The Monitor
Assistant forwards this request to the Privacy Manager Business Service via
Siebels J2C Connector. Some eScript code executing in the Business Service
interrogates the target Business Objects and Components for the required
values. The results are then returned to the Monitor Assistant and Reference
Monitor.
Enforcement strategies
Enforcement of governing privacy policy is a non-rivial task within Siebel. A
number of strategies exist for enforcement, all of which involve customized
eScript coding in the Business Component event handlers. This code must be
supplied by the installer of the monitor. Fortunately, the adapter distribution
supplies sample eScript code that may be used as the basis for the
customization. The enforcement sample code is available in query.txt. This is an
example of the type of customization required for the BusComp_Query event.
This event is triggered when a given Business Component is accessed to be
read. This event handler is the recommended location for PII access detection
because all data operations within Siebel flow through the Business Components
and the monitor models storage locations as Business Component attribute
fields.
156 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Example 5-1 Real-time enforcement check within BusComp_Query
// Load the Privacy Manager Business Service
var tpmSvc = TheApplication().GetService("PrivacyManager");
With enforcement check results now available from Tivoli Privacy Manager
server, the required enforcement strategy may be employed.
No enforcement
One enforcement option supported by the monitor is no enforcement. This is
done by setting var enforcementOption = 0 in the eScript declarations of the
monitored Business Component. For a detailed configuration, see IBM Tivoli
Privacy Manager for e-business Monitor Developer’s Guide, Version 1.2,
SC32-1286.
if (conformance == "false") {
if (trace == 1) {
// do some tracing
};
if (enforcementOption == 1) {
// Raise an application exception to deny access to all data
TheApplication().RaiseErrorText(“...");
};
Record-level enforcement
Record-level enforcement can be achieved by refining the query to exclude the
non-conformant records accessed. It is supported by the integration monitor. It
may be configured by setting var enforcementOption = 2 in the eScript
declarations of the monitored Business Component. This type of enforcement is
best suited to Siebel screens based on list applets. The idea is to remove an
entire row from the display if at least one field of the row is non-conformant. A
record is flagged as non-conformant in the conformance result property set from
the Privacy Manager Business Service. The code from the sample
BusComp_Query eScript, shown in Example 5-3, implements record-level
enforcement.
158 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
var recordId = record.GetValue();
if (enforcementOption == 2) {
// Setup an array of strings that will help build
// a refine query statement to exclude the non conformant
// record ids, eg Id does not equal ‘123’.
aRecordsNonConformant[i] = "[Id]<>'" + ToString(recordId) + "'";
};
}
var searchst = aRecordsNonConformant.join(" AND ");
// Refine the query
this.RefineQuery();
this.SetSearchExpr(searchst);
// prevent recursion
enterEventFlag = 1;
this.ExecuteQuery();
enterEventFlag = 0;
this.ClearToQuery();
}
Field-level enforcement
Field-level enforcement requires significant setup and configuration in Siebel.
The intuitive approach would be to modify the value of the given non-conformant
field within the query event handler of the monitored Business Component.
However, this has the unfortunate effect of updating the actual value stored in the
database with the enforcement value. This behavior results because Siebel
commits updates made to a Business Component to the database.
160 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
}
Privacy Manager
Server
WebSphere
Public Housing Juvenile Justice
Business Business
Reference
Components Components
Monitor
Web
TPM Web Serivce
Data Abstration Layer Service
Proxy
Adapter
Database
The monitored Business Components are described below. Note that the Copy
Of prefixed field names are defined to enable the eScript code with the
BusComp_Query event handlers to enforce privacy policy. These fields are
registered as storage locations within Tivoli Privacy Manager server and are
classified as PII.
162 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Important: Business Component field names are registered as storage
locations by the Siebel monitor. Those locations that are classified as PII
within Privacy Manager must have a corresponding “Copy Of” prefixed name
defined within the Siebel Business Component. This is a requirement for the
recommended enforcement technique of the monitor. See discussion of
Enforcement Strategies in the previous sections.
The ASA has defined one shared Business Component that can be used to
reconcile all branch client identifiers with the global identifier for a given client.
This Business Component is shown in Example 5-6. This Business Component
will be nominated as the master Business Component in the configuration of the
monitor.
The Business Components for Public Housing defined within Siebel are shown in
Example 5-7.
HOUSING_CLIENTS
AsaClientId
HousingId
PropertyId
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
Marital Status
Copy Of Marital Status
Partner
Copy Of Partner
Occupation
Copy of Occupation
The Business Components for Child Protection defined within Siebel are shown
in Example 5-8.
CHILD_PARENTS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
164 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Age
Copy Of Age
Occupation
Copy Of Occupation
CHILD_SIBLINGS
AsaClientId
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
School
Copy Of School
IsStep
CHILD_FOSTER_PARENTS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
Age
Copy Of Age
Occupation
Copy Of Occupation
CHILD_CARETAKERS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
Age
Copy Of Age
Occupation
Copy Of Occupation
The Business Components for Juvenile Justice defined within Siebel are shown
in Example 5-9.
JJ_CLIENT_SIBLINGS
AsaClientId
166 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
School
Copy Of School
IsStep
JJ_CLIENT_ASSOCIATES
Name
Address
VisitsRegularly
The Business Components for Mental Health defined within Siebel are shown in
Example 5-10.
MH_CLIENT_CHILDREN
AsaClientId
Name
Copy Of Name
Age
Copy Of Age
Sex
Copy Of Sex
School
Copy Of School
Problems
Copy Of Problems
IsFoster
Copy Of IsFoster
MH_CLIENT_MEDICAL_HISTORY
AsaClientId
HasDisabilities
Copy Of HasDisabilities
DisabilityDetails
Copy Of DisabilityDetails
IsAbused
Copy Of IsAbused
AbusedDetails
Copy Of AbusedDetails
IsRaped
Copy Of IsRaped
RapedDetails
Copy Of RapedDetails
HasCurrentTreatments
Copy Of HasCurrentTreatments
CurrentTreatmentsDetails
168 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Copy Of CurrentTreatmentsDetails
HasPreviousTreatments
Copy Of HasPreviousTreatments
PreviousTreatmentsDetails
Copy Of PreviousTreatmentsDetails
Components of the Siebel privacy monitor must be deployed within Siebel. The
primary tasks needed to deploy the monitor components into Siebel are:
1. Import the monitor project, TPM.sif, into Siebel. This will set up the
TPM_Discovery and PrivacyManager Business Services used to
communicate to and from Tivoli Privacy Manager server.
2. Complete eScript for conditional value lookup. This is done by customizing
the CustomizedTargetBcLookup function on the TPM_Discovery Business
Service.
3. Create a Web service to enable the outbound communication to Tivoli Privacy
Manager server. This is done by importing the PMRefmonEJB.wsdl definition
file into Siebel.
4. Deploy eScript into each of the monitored Business Components. This
includes:
– Defining the master key for monitoring. For the scenario, the master key
used will be AsaClientId, since this an intra-branch global identifier within
ASA. This field is present on all Business Components with ASA. This is
done by setting var bcMasterKeyField = "AsaClientId"; in the
declarations sections of the monitored Business Components.
– Adding the code from the getbcfields.txt file to the declarations section of
the monitored Business Components. This enables the monitor to
dynamically obtain the list of Business Component field names to be
monitored.
– Setting up the PII access detection eScript code in the BusComp_Query
event handler of the monitored Business Components. The template
eScript code for this is available in the query.txt file.
The monitor allows for a number of configurations and customizations via its
property files. The property files are:
com_ibm_tivoli_integration_pm_refmon.properties
This is the set of properties that define the behavior of the Reference Monitor.
See the Reference Monitor Guide for details.
J2EE.properties
The set of properties required by the Monitor SDK. The properties in this file
enable communication between the monitor and Tivoli Privacy Manager
server. See the Monitor Developer’s Guide for details.
Siebel.properties
The set of properties that define the connection used by the monitor to
communicate to Siebel. See the following section.
com_ibm_tivoli_integration_pm_siebelassist.properties
The set of properties that define how and what information is registered with
Tivoli Privacy Manager server. See the discussion below.
Siebel.properties
An example of the property configuration is shown in Example 5-11.
170 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
The most critical items to configure in this file are siebel.user.name,
siebel.user.password, and siebel.connection.string. The user name and
password should allow read access to the Siebel Business Object Repository
and the monitored Business Components.
The connection string value is composed of names of the Siebel gateway server,
Siebel server name, Siebel object manager name, and host name of the Siebel
server. The general form of the siebel.connection.string as follows:
siebel://<gateway>:<port>/<siebel enterprise name>/<object manager
name>/<siebel server name>.
See Siebel eBusiness Application Integration Volume III for further details.
# purpose filter
siebelassistant.purpose.filterCount=4
siebelassistant.purpose.filter.1=PoliceInquiry
siebelassistant.purpose.filter.2=HospitalInquiry
siebelassistant.purpose.filter.3=HousingBenefits
# custom purpose
siebelassistant.purpose.customCount=0
The master key is nominated as the client identifier field of the AsaClient
Business Component.
The storage locations are limited to the Business Components described for the
scenario. The storage location filter helps to narrow the components and their
fields that need to be monitored.
The purpose filter has been used to limit the number of Business Objects that the
monitor needs to interrogate for applTask registration. The Business Object
names listed in the configuration file are those that reference the monitored
Business Components named in the storage location filters.
172 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
group create am_asa_disability
cn=am_asa_disablility,ou=departments,o=privacyinc cn=am_asa_disability
group create am_asa_family_support
cn=am_asa_family_support,ou=departments,o=privacyinc cn=am_asa_family_support
user create ann cn=ann,ou=departments,o=privacyinc cn=ann sn=ann passw0rd
am_asa_public_housing
user modify ann account-valid yes
user create betty cn=betty,ou=departments,o=privacyinc cn=betty sn=betty
passw0rd am_asa_disability
user modify betty account-valid yes
user create charlie cn=charlie,ou=departments,o=privacyinc cn=charlie
sn=charlie passw0rd am_asa_child_protection
user modify charlie account-valid yes
user create dan cn=dan,ou=departments,o=privacyinc cn=dan sn=dan passw0rd
am_asa_juvenile_justice
user modify dan account-valid yes
user create egon cn=egon,ou=departments,o=privacyinc cn=egon sn=egon passw0rd
am_asa_family_support
user modify egon account-valid yes
user create fran cn=fran,ou=departments,o=privacyinc cn=fran sn=fran passw0rd
am_asa_front_desk
user modify fran account-valid yes
5.8 Conclusion
This chapter has presented a description of a generic social service
organization. We have discussed some of the privacy-related challenges that
confront such organizations when they wish to share sensitive information about
individuals within distinct parts of the organization. The key challenge for these
organizations is to enable parts of the organization to access an individual’s
details effectively and efficiently, while respecting the personal choices and
privacy rights of the individuals. The purpose for which information is being
accessed is a primary factor in enabling information sharing.
The liberalization of financial markets in countries around the world has been a
major factor in this drive toward globalization. Banks, securities brokers, and
insurance firms can now compete in markets all over the world. The gradual
deregulation of the financial services industry within the United States has also
been an important driver for this growth. The elimination of barriers to geographic
expansion and the loosening of other regulations, such as the Glass Steagall
Act1, has paved the way for a wave of mergers among banking, insurance, and
securities firms throughout the United States.
1
The Glass-Steagall act was a 1933 United States national law separating investment banking and
commercial banking firms. It also prohibited banks from owning corporate stock. It was designed to
confront the problem that banks in the Great Depression collapsed because they held a lot of stock.
An interesting time line can be found at:
http://www.pbs.org/wgbh/pages/frontline/shows/wallstreet/weill/demise.html
Our sample scenario involves a fictitious financial institution called Red Planet
Finance (RPF), which follows this trends. RPF as it is structured today came into
existence through mergers with corporations of the banking, insurance and
trading segments. This allows a lot of cross-selling opportunities and the
development of new financial products that are offered over the Internet.
Note: All names and references to company and other business institutions
used in this chapter are fictitious. Any match with a real company or institution
is coincidental.
RPF is one of the leading financial institutions in the United States. RPF provides
a diverse variety of financial products to its customers, including banking,
securities/commodities trading, and insurance.
176 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Canada. All IT systems that run Web-accessible applications are centralized in
Long Island. Backup and recovery data centers are also located there. It is
planned that existing regional data centers of merged firms will be shut down and
consolidated with the central data centers in Long Island. This is part of a
company-wide applied consolidation strategy to improve business process
performance and save costs.
178 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Global trade
Risk management
Cash management
Commodities
International business
Financial research
Insurance employees go the insurance Web portal, which provides the following
services:
Customer data and identity management
Term life insurance management
Auto insurance management
Customer’s view
Since the merger, the customers are no longer aware how their data is shared in
the global finance corporation. It is also not clear to them which rules apply to the
consent they have given to one or more of the pre-merger companies. The
customers now need a single point of contact where they can define and modify
their consent for all the data that is stored by RPF.
Also, because all the finance applications are Web-based and easily accessible,
company-internal privacy policies need to be defined and implemented to assure
that employees access only the data they need for their daily work. Otherwise,
data could be used for unintended purposes.
On the other hand, where reasonable and consent from the customer is given,
financial applications should share common data to offer better service and
products to the customers. For example, if a customer of the insurance
department is opening a bank account, his already collected general personal
data and his identity data could be used to process the task faster and more
conveniently.
180 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
with privacy-sensitive content. The company privacy policy needs to be refined
and detailed to address these new facts in order to maintain customers’ trust.
The following sections describe RPF‘s vision, objectives, and corporate privacy
policy.
RPF sees trust as the basis for any customer relationship. Therefore, the
customers’ privacy needs to be respected and handled individually.
To establish and maintain trust, extensive logging and reporting will help to
answer any questions raised by the customers and to satisfy any audit by
company-internal controlling or government agencies.
6.3.2 Objectives
RPF wants to do everything possible to assure the customers’ trust in RPF. In
order to reach this goal, RPF wants to give its customers any option to let them
decide how their personal data is used and exchanged. The privacy policy
statements on Web sites should be given more than lip service; they have to be
implemented in real operational systems.
Logging and reporting functions must be used to record any data item accessed
by employees, customers, or partners.
RPF collects personal data to offer its customers individual banking solutions and
products tailored to the customer’s need. RPF also wants to offer its customers
product information that can be of interest for the customer. However, whenever
personal data is collected the customer is informed.
In the corporate privacy policy, RPF states which RPF companies and which
customers are covered by the privacy policy. RPF gives its customers choices
about how personal data is shared between RPF companies and with external
companies. The customers have options down to the data element. For certain
businesses, RPF has defined special privacy policies.
182 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
RPF has developed a Web page where customers can give their consent to
certain data-handling and data-sharing tasks.
At present, the RPF customers do not have the possibility to choose from options
defining which data items can be exchanged inside RPF and outside RPF to
partners. The new privacy management solution must provide these options to
the customers.
Note: The phase of privacy policy design applies not only to this particular
DPM solution but is common to all Tivoli Privacy Manager for e-business
implementations.
184 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
6. Grouping of employees who take on the above job roles.
7. Definition of a report compilation schedule.
The application must be started before the Tivoli Privacy Manager for e-business
console can be used to map the privacy policy to the monitors defined in the
privacy descriptor XML file.
Scenario
The customers should be given the possibility to choose if the following
personally identifiable information (PII) can be shared among RPF’s
departments:
General personal data (first name, initial, last name, birthday, birthplace, sex)
Identity (identity card number, passport number, driver’s license number,
social security number, address, phone number)
Bank data for bank giro/checking accounts (balance, monthly statement,
record of money transfers)
Bank data for saving accounts (balance, interest rate)
Bank data for loans (balance, monthly payments, interest rate)
Insurance data for term life insurance (insurance sum)
Insurance data for auto insurance (type of insurance -
comprehensive/non-comprehensive)
Trading data (deposit, portfolio of securities, portfolio of stocks, portfolio of
options, record of transactions)
Customer benefits
Error-prone tasks such as data registration can be automated, and data need
be provided only once by the customer.
Contracts can be processed faster, and customers get what they want faster.
RPF can make offers that are tailored to the customer’s needs.
186 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
6.5.2 Banking department’s view
Let us take a closer look at the scenarios and the banking department benefits.
Scenarios
For certain purposes, the banking department wants to access the following data
elements:
Identity data (purpose: opening of an account)
Balance of bank giro/checking accounts (purpose: withdrawal)
Balance of saving accounts (purpose: withdrawal)
Credit limit of loans (purpose: checking, withdrawal)
Insurance sum of term life insurance (purpose: provision of loans depends on
a sufficient term life insurance)
Type of auto insurance (purpose: auto financing is only possible if car is
insured with comprehensive coverage)
Trading account portfolio (purpose: secure loans in case of personal
bankruptcy)
Scenarios
For certain purposes, the insurance department wants to access the following
data elements:
Identity data (purpose: close of new insurance agreement)
Bank account number of bank giro/checking accounts (purpose: direct debit
after close of new insurance agreement)
Scenario
For certain purposes, the trading department wants to access the following data
elements:
Identity data (purpose: opening of new deposit)
Scenarios
Basically the customer relationship department wants to cross-analyze customer
data to provide better customer information and to leverage cross-selling
opportunities. However, when analyzing customer data the customer relationship
department has to respect the customers defined privacy policy rules.
For certain purposes, the customer relationship department wants to access the
following data elements:
Identity data (purpose: save customer data to cross-analyze).
Bank data of loans (purpose: offer insurance for the new car to a bank
customer who signs an auto-financing contract).
Bank data of savings account (purpose: offer higher earning investment
options such as securities and stocks to a bank customer who has a certain
amount of savings).
Monthly bank statements (purpose: analyze customers’ money transfers for
trading and insurance to bank accounts of competing firms in order to offer
them the equivalent or better products of RPF).
188 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Trading data (purpose: if a customer’s investment strategy was not successful
and he lost money on stocks, the customer relationship department can offer
less riskier investments such as savings accounts or life insurance).
RPF benefits
Since the customer relationship department actions reach across all
departments, it benefits RPF as a whole, so this section is called RPF benefits.
Sales can be optimized across all departments.
Highly targeted product offers can be launched.
190 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Coverage
Payment
PaymentType
No-claimsBonus
Deductible
The WHO clause refers to the groups defined in 6.5, “Business requirements” on
page 186. The MAY ACCESS WHAT clauses refer to the PII defined in 6.6.1, “Data
design” on page 189. The FOR WHAT PURPOSE and the IF CONDITIONS clauses are
self-describing.
Rule 1
RULE_1
WHO
Customer
MAY ACCESS WHAT
GeneralPersonalData
IdentityData
192 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
IF CONDITIONS
Customer_Consent
RULE_END
Rule 5
RULE_5
WHO
Bank_Employees
MAY ACCESS WHAT
AutoInsurance
FOR WHAT PURPOSE
Check_full_coverage_for_auto_loan
IF CONDITIONS
Customer_Consent
RULE_END
Rule 6
RULE_6
WHO
Insurance_Employee
MAY ACCESS WHAT
BankCheckingAccount
FOR WHAT PURPOSE
Get_BankAccountNumber_for_direct_debit
IF CONDITIONS
Customer_Consent
RULE_END
Rule 7
RULE_7
WHO
Trading_Employee
MAY ACCESS WHAT
IdentityData OR
GeneralPersonalData
FOR WHAT PURPOSE
Open_TradingAccount_for_existing_customer
IF CONDITIONS
Customer_Consent
RULE_END
Rule 8
RULE_8
WHO
Bank_Employee
MAY ACCESS WHAT
TradingAccount
FOR WHAT PURPOSE
Check_Portfolio
Open trading
account for existing
customer
Trading Department Employees
Identity Data
Figure 6-2 on page 195 shows cross-department data access. This illustrates
RULE_5 and RULE_6.
194 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Defined groups Defined types of PII Defined purposes
Manage contract
(for example: increase
insurance sum)
Term Life Insurance
The invoked ServletContextListener creates the DPM monitors that are defined
in the XML privacy deployment descriptors and initializes them. Whenever the
specific servlets that are associated with the XML privacy deployment
descriptors are invoked, the ServletFilter intercepts the servlet requests and
interacts with the DPM monitors before or after the servlet or JSP execution to
enforce the privacy policies.
Note: At the time we wrote this redbook, DPM V1.1 was the available version.
In the upcoming release of DPM V1.2, privacy deployment descriptors can
also be associated with EJB component methods. WebSphere Application
Server Enterprise Edition 5.0 or later is needed to support the enforcement of
these EJB descriptors. Wherever possible, we outline differences for the
upcoming V1.2 implementation.
196 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
monitors to observe the business model described above, we discuss a few
points that help customers to better understand this framework.
EJB Module
Today the IBM Declarative Privacy Monitoring framework has implemented the
DPM monitor object that interacts with Privacy Manager to provide the DPM
monitor services. Thus there is no need for customers to implement their own
DPM monitor. However, if customers want to develop their own DPM monitor
class, they need to implement a subclass of PrivacyMonitor and supply the
proper monitorClassName with the value of the customer’s own DPM monitor
class name in the file monitor.properties. This file is located in the WAR archive
as WEB-INF\monitor.properties. The monitor classes are suggested to be placed
in com\ibm\dpm\impl\mymonitor (mymonitor is just an example).
Note on V1.2: In DPM V1.2, this file is located in the dpm.jar file as
com\ibm\dpm\resources\monitor.properties.
An example with two DPM monitors defined is shown in Figure 6-4 on page 199.
One has the name AutoInsurancePolicy and the other AutoInsurancePayment.
They contain monitored items from the auto insurance policy and auto insurance
payment databases, respectively. The viewAutoInsurance servlet is invoked to
look at details regarding a customer’s auto insurance policy and insurance
198 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
payment. It uses monitored items from both the AutoInsurancePolicy and the
AutoInsurancePayment DPM monitor. Therefore, when the servlet runs, both
monitors are called to log and enforce access to the respective items.
AutoInsurancePolicy
dskey=customer#
autoInsuran- /viewAutoInsurance
cePolicy# coverage
View customer auto insurance policy
customer# AutoInsurancePolicy#
Customer#
Coverage
deductible
noclaims-
Bonus
Configuration
Several properties in DPM are defined in the monitor.properties file for
customizing and configuration. The monitor.properties file is located as
WEB-INF/monitor.properties in the WAR archive (in DPM V1.2, this file must be
in the CLASSPATH at com/ibm/dpm/resources/monitor.properties). The
configurable items are defined as follows:
monitorClassName Key to property object for the PrivacyMonitor
implementation class.
Default:
com.ibm.dpm.impl.sdkmonitor.SDKPrivacyMonitorImpl
logFileName Key to property object for log file name.
Default: dpm.log
loggerName Key to property object for the name of the logger.
Default: com.ibm.dpm
(In DPM V1.2, the log-related properties are located in
the file com/ibm/dpm/resources/logger.properties)
loggerClassName Key to property object for Logger implementation class.
Default: com.ibm.dpm.util.logging.JLogLogger
loggerLevel Key to property object for logging level, for example
SEVERE, WARNING, INFO, and so on.
Default: WARNING
Restrictions
The DPM is designed to be used in a Web container that supports Java Servlet
Specification 2.4. It can be used in Web containers that only support Java Servlet
Specification 2.3, but with limitations. The version 2.4 specification supports the
invocation of servlet filters on a Web component method execution whether it is
either the target of the HTTP request itself, the target of a subsequent
RequestDispatcher call to another JSP, or the servlet still processing the same
request. But in version 2.3, servlet filters can only be invoked on servlets and
JSPs that are the original target of an HTTP request. To use privacy descriptors
associated with EJB component methods, WebSphere Application Server
Enterprise Edition 5.0 or later is required.
Important: Because the most current Web application platforms only support
Java Servlet Specification 2.3, the implementation of the servlet filter monitor
discussed in the following section is based on Java Servlet Specification 2.3.
This means that the DPM ServletFilter is invoked on servlets and JSPs only at
the original level of an HTTP request (for example not called using the
RequestDispatcher).
200 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
6.7.2 Declarative XML privacy deployment descriptor file
Each monitored Web or J2EE application should include an XML privacy
deployment descriptor file in each Web module that describes the privacy
semantics associated with the servlets and JSPs in that module. In addition, one
or more of these XML files can have the descriptors that describe the privacy
semantics of any EJBs used in the application. This XML privacy deployment
descriptor file is the first item required for developing DPM monitors. The entries
in the XML file are of two types: definitional and operational privacy deployment
descriptors. Let us take a closer look at these descriptors.
Definitional descriptors
The definitional descriptors are not associated with specific servlets, JSPs, or
EJBs. Rather, they may apply to any J2EE components in one or more
applications. These do not need to change just because a new component is
added to the system. However, they can be extended when new components
include additional monitor data items or perform new business tasks. Definitional
descriptors answer the following questions:
What are the resource items that need to be monitored?
What are the business tasks that may be performed?
Operational descriptors
Operational descriptors are associated with specific servlets, JSPs, or EJBs. The
privacy semantics of a particular component is described using these
descriptors, and answer the following questions:
At which component method(s) should the data user identity be determined,
and how?
At which component method(s) does a new business task begin, or what
default task should be assumed if none has been established?
At what component method(s) do PII operations occur?
Thus, when a specific servlet, JSP, or EJB method is executed, the end user
identity, the business tasks being performed, and current accessed PIIs can be
determined.
After the operational descriptor has been processed, the DPM framework stores
the component name, method name and associated operational descriptors
(actually the descriptor metadata) in a table. Thus, when the servlet, JSP, or EJB
is executed, the DPM ServletFilter or WebSphere EJB collaborator can retrieve
the appropriate operational privacy descriptor metadata for that component
method and perform the privacy monitor services.
Both definitional and operational descriptors have individual elements for further
privacy semantic information. Let us take a closer look at those elements.
<privacyMonitorDefinition> element
The <privacyMonitorDefinition> descriptor element defines a DPM monitor, or
adds to an existing monitor definition. The primary purpose of this descriptor is to
specify resource items that need to be monitored. These include both personally
identifiable information (PII) and other information that may be useful in the
evaluation of privacy policy conditions. Therefore, the resource items known to
the application components (includes servlets, JSPs and EJBs) being monitored
would be included here.
The grouping of monitored items into different named monitors is generally done
based on the item that should be associated with a data subject. For example,
auto insurance policy data is accessed via customer number; therefore, auto
insurance policy data is grouped in a <privacyMonitorDefinition> with the
subject key, customer number.
202 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
may also specify a set of monitor attributes, which are arbitrary name/value pairs.
The monitor attributes are not used by the DPM code, but are passed to the
privacy monitor classes, which may use them for implementation specific
function.
<privacyTaskDefinition> element
The <privacyTaskDefinition> descriptor element defines a set of business
tasks that may be performed by the application components being monitored.
These tasks do not have to correspond to transactions or units of work in an
application; they may be conceptual. These tasks are used to determine the
purpose of a PII operation. It is up to the privacy monitor implementation and its
underlying privacy service product to provide the mapping between task and
purpose.
<privacyIdentitySetupPoint> element
The <privacyIdentitySetupPoint> element is an operational descriptor
associated with servlets or JSPs that are points at which data user identity
should be determined for use in privacy policy conformance checks. In DPM V1.2
this is renamed to <webPrivacyIdenittySetupPoint> and there is also an
<ejbPrivacyIdentitySetupPoint>. The DPM code intercepts invocations of the
associated servlets or JSPs, determines the user identity as specified in the
descriptor, and saves that user identity for use in subsequent PII operation
conformance checks. This ensures that even if this thread performs a PII
operation under some other user identity, for example, a system identity used to
Note V1.2: In DPM V1.2, identity setup is associated with servlets and JSPs
using <webPrivacyIdentitySetupPoint>. Identity setup can also be associated
with an EJB using a <ejbPrivacyIdentityPoint> descriptor element.
<privacyTaskSetupPoint> element
The <privacyTaskSetupPoint> element is an operational descriptor associated
with servlets or JSPs that are points at which a new business task is established,
or that provide a default business task if no task has yet been established for a
request. This task information is used to determine the purpose of subsequent
PII operations. The DPM code intercepts invocations of the associated servlets,
modifies the current business task information associated with the request, and
saves that task information for use in subsequent PII operation conformance
checks.
204 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
should be used to modify the current business task associated with the request,
or the name of a generator plug-in class (see “TaskDefinitionGenerator” on
page 208) that provide the task name dynamically in the runtime.
<privacyOperationPoint> element
The <privacyOperationPoint> element is an operational descriptor associated
with servlets or JSPs that are points at which operations on personally
identifiable information are performed. The DPM code intercepts invocations of
the associated servlets specified in this descriptor and calls the appropriate
privacy monitor classes to interact with the underlying privacy services to log PII
operations and check conformance to privacy policies.
File creation
The XML syntax in this file must conform to the privacyDescriptors.xsd XML
schema (see Example A-3 on page 243). The default name of the XML privacy
deployment descriptor file is WEB-INF/privacyConfig.xml, located in the WAR
206 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
archive. The file name can be configured in the monitor.properties file with the
property key: descriptorFileName (see “Configuration” on page 199).
TaskModifierGenerator
Plug-in classes can optionally be associated with <webPrivacySetupPoint> or
<ejbPrivacySetupPoint> elements. These classes return a TaskModifier object
that is used to establish the current task for an associated servlet in the runtime.
These classes implement either the ServletTaskModifierGenerator or
EjbTaskModifierGenerator interface and must extend the MonitorPluginImpl
abstract class.
MonitoredItemDefinitionGenerator
This plug-in class returns a list of monitored item at runtime to be defined for a
monitor.
This Web site provides DPM Javadoc, required Java packages, and Readme
files. It also includes a demonstration program to show how DPM code can be
used in a very generic business model. It would be good practice to download
and experience this DPM demonstration program to understand the
implementation of the auto insurance business model discussed in the following
section.
208 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
6.8.1 Implementation overview
In this section, an overview diagram is provided to illustrate how these DPM
monitors operate in a Java 2 Enterprise Edition environment.
To demonstrate this implementation simpler, the servlets or JSPs that display the
customer’s auto insurance data page are defined as
<url-pattern>/viewInsuranceData</url-pattern> in the <servlet-mapping>
element in Web deployment descriptors (Web.xml). The Web deployment
descriptor file resides in the WAR archive of this auto insurance Web application.
viewautoInsurance
Auto Insurance Web
application
plugin
plugin
log / authorize
AutoInsuranceP
aymentMonitor Tivoli Privacy
Deployment
Descriptors Manager
AutoInsuranceP
(including Security Web Container olicyMonitor
Descriptors)
Privacy Deployment
Descriptors
After the policy editing is completed, change the P3P policy state from “Draft” to
“Published”.
210 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
See Example A-1 on page 237 as an example of a P3P policy file.
If the monitor items are retrieved from the underlying EJB JARs in the runtime,
the list of monitored items can be retrieved by naming a generator plug-in class
that will be called to get the list of monitored items at Web application load time.
For example:
<p:generatorClassName>
com.myorg.autoprivacy.AutoPolicyMonitoredItemGenerator
</p:generatorClassName>
212 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Class beanClass = Class.forName(beanClassName);
BeanInfo beanInfo = Introspector.getBeanInfo(beanClass);
PropertyDescriptor[] props = beanInfo.getPropertyDescriptors();
String itemName = null;
String description = null;
MonitoredItemDefinition itemDef = null;
for (int i = 0; i < props.length; i++) {
itemName = props[i].getName();
description = props[i].getShortDescription();
itemDef =
MonitoredItemDefinitionFactory.create(itemName,description);
items.add(itemDef);
}
} catch (Exception e) {
PrivacyPluginException ppe = new PrivacyPluginException(
“Could not get properties of Java Bean class =
‘”+beanClassName+”’.”,e);
throw ppe;
}
return ReadCollectionFactory.create(items);
}
<privacyTaskDefinition> descriptor
Since there is only one task defined in this implementation, the static task name
is defined in this descriptor.
Static task name: ViewautoInsurance.
monitorScope: “AutoInsurance*”, so it covers both monitors defined above.
<privacyIdentitySetupPoint> descriptor
In this implementation, the user identity is defined as the current J2EE remote
user.
<p:url-pattern> “/viewInsuranceData”.
“/viewautoInsurance” is defined to match the URL pattern defined in the
servlet mapping in the Web deployment descriptors.
<privacyTaskSetupPoint> descriptor
Since there is only one task defined in this implementation, the static task name
is defined in this descriptor.
Static task name: “ViewautoInsurance”
<p:url-pattern>: /viewInsuranceData
<privacyOperationSetupPoint> descriptor
This <privacyOperationSetupPoint> descriptor is specified for
“AutoInsurancePolicyMonitor” monitor.
<p:monitorName>:“AutoInsurancePolicyMonitor”
<p:enforcement>: ”true”
<p:operation>: ”USE”. The monitored items are retrieved for use by a data
user.
214 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
<p:operationInfoClassName>: See 6.8.5, “Provide privacyOperationPoint
descriptor plug-in classes” on page 215.
<p:url-pattern>: /viewInsuranceData
Sample file
Example A-2 on page 241 is an example of the declarative privacy deployment
descriptor XML file.
The three methods defined in the interface must be implemented in this class.
The following sections provide a sample of these methods.
// create a SubjectItemGroup using the data subject keys and item names
SubjectItemGroup itemGroup = SubjectItemGroupFactory.create(
ReadCollectionFactory.create(subjectKeys),
ReadCollectionFactory.create(itemNames));
216 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
return ReadCollectionFactory.create(groups);
}
getItemValues method
Example 6-9 shows the getItemValues method.
try {
// get EJB
Context ctx = new InitialContext();
Object homeObject =
ctx.lookup(“java:comp/env/AutoPolicyRefs/AutoPolicy”);
autoPolicyHome = (AutoPolicyHome)
javax.rmi.PortableRemoteObject.narrow(
homeObject, AutoPolicyHome.class );
autoPolicyEJB = AutoPolicyHome.findByPrimaryKey(subjectKey);
// get requested item values
ReadIterator iter = monitoredItemNames.iterator();
String itemName = null;
String itemValue = null;
while (iter.hasNext()) {
itemName = (String) iter.next();
if (itemName.equals(“customerNo”)) {
itemValue = subjectKey;
return ReadMapFactory.create(itemMap);
handleError method
Example 6-10 shows the handleError method.
218 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
throws PrivacyPluginException {
//Assume results contain the pair of the non conformant item name, and its
value
ByteArrayOutputStream outStream =
PrivacyServiceHelper.getServletResponseByteArrayOutputStream(response);
return returnValue;
}
220 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-7 AutoInsurancePaymentMonitor storage location classification
PII mapping
The PII mapping should look similar to Figure 6-8 on page 222 and Figure 6-9 on
page 222.
222 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Condition Rule mapping
During PII mapping, if there are any condition rules that associate to the
purposes or groups, these condition rules must be mapped to the registered
storage locations. Figure 6-10 shows the mapping of data owner can see his/her
own data subject rule for the AutoInsurancePolicyMonitor monitor.
Purpose mapping
The task name defined in <p:privacyTaskDefinition> will be mapped to a
purpose in Privacy Manager. The purpose mapping should look similar to
Figure 6-12 on page 225.
224 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-12 AutoInsurancePolicyMonitor Purpose mapping
Access ID mapping
In the <p:privacyIdentitySetupPoint>, the current J2EE remote user is defined
as the user identity. Thus, the users that log in to the viewautoInsurance page
would be mapped to the ID defined in Tivoli Access Manager. The access ID
mapping is shown in Figure 6-13 on page 226.
Group mapping
The groups defined in the P3P policies need to be mapped to the Tivoli Access
Manager groups for runtime privacy policy conformance check. The Group
mappings are shown in Figure 6-14 on page 227.
226 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-14 P3P AutoInsurance policy group mapping
228 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-16 CustomerA auto insurance data
2. He requests the customerB auto insurance record. CustomerA should not see
CustomerB’s auto insurance record, so all PIIs are blocked. Figure 6-17 on
page 230 shows the resulting page.
230 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-18 Customer A auto insurance data (all blocked)
232 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Figure 6-20 CustomerA auto insurance data
2. He requests the customerB auto insurance record. The scenario is the same
as above.
2. He requests the customerB auto insurance record. Banker would see both
customerB’s auto insurance data and his payment if customerB sets the
opt-in choice. Otherwise, customerB’s payment information would also be
blocked.
6.9 Conclusion
The above sections have described how to develop the DMP monitors in a Java 2
Enterprise Edition environment. The development includes creating a declarative
privacy deployment descriptor XML file and plug-in classes, but it has no
interaction with the underlying monitored auto insurance Web application. Thus,
it demonstrates the Declarative Privacy Monitoring technology that removes the
need for applications to be privacy aware.
234 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Part 3
Part 3 Appendixes
238 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
<DISPUTES-GROUP>
<DISPUTES resolution-type="service"
service="http://banker2002.com/cust_serv"
short-description="Banker2002.com Customer Service">
<LONG-DESCRIPTION>Questions regarding your account can be
directed to Banker2002.com. Contact us by email at
contact_us@banker2002.com.</LONG-DESCRIPTION>
<REMEDIES>
<correct/>
</REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<EXTENSION optional="yes">
<STATEMENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<DESCRIPTION>AutoInsurancePolicy</DESCRIPTION>
</STATEMENT-EXT>
</EXTENSION>
<PURPOSE>
<other-purpose required="always">view-autoinsurance: View
customer auto insurance</other-purpose>
</PURPOSE>
<RECIPIENT>
<ours>
<recipient-description>BankingGroup: Employees of the bank ,
i.e. teller, manager, etc.</recipient-description>
</ours>
<ours>
<recipient-description>InsuranceGroup: Employees of the
Insurance company, i.e. insurance officer, manager,
etc.</recipient-description>
</ours>
<ours>
<recipient-description>CustomerGoup: Auto Insurance policy
owner</recipient-description>
</ours>
<EXTENSION optional="yes">
<RECIPIENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<RECIPIENT-VALUE-EXT recipientTag="ours">
<RECIPIENT-KEY>CustomerGoup</RECIPIENT-KEY>
<CR
description="Customers can view their own information."
leftSide="data user" operation="Equal" rightSide="data
subject"/>
</RECIPIENT-VALUE-EXT>
</RECIPIENT-EXT>
</EXTENSION>
</RECIPIENT>
<RETENTION>
240 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
</RECIPIENT-EXT>
</EXTENSION>
</RECIPIENT>
<RETENTION>
<no-retention/>
</RETENTION>
<DATA-GROUP base="">
<DATA optional="no" ref="#autoinsurance.payment">
<CATEGORIES>
<financial/>
</CATEGORIES>
</DATA>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</POLICIES>
Example: A-2 Auto insurance Web application privacy descriptor XML file
<?xml version="1.0" encoding="UTF-8"?>
<p:privacyDescriptors xmlns:p="http://www.ibm.com/2003/PrivacyServices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/2003/PrivacyServices
../../../J2eePrivacyMonitor/com/ibm/dpm/resources/privacyDescriptors.xsd “>
<p:privacyMonitorDefinition>
<p:monitorName>AutoInsurancePolicyMonitor</p:monitorName>
<p:subjectKeyName>customerNo</p:subjectKeyName>
<p:monitoredItemDefinitionGroup>
<p:monitoredItemDefinition>
<p:monitoredItemName>customerNo</p:monitoredItemName>
<p:description>Auto insurance customer number</p:description>
</p:monitoredItemDefinition>
<p:monitoredItemDefinition>
<p:monitoredItemName>autoInsurancePolicyNo</p:monitoredItemName>
</p:monitoredItemDefinition>
<p:monitoredItemDefinition>
<p:monitoredItemName>currentUserid</p:monitoredItemName>
</p:monitoredItemDefinition>
<p:monitoredItemDefinition>
<p:monitoredItemName>coverage</p:monitoredItemName>
</p:monitoredItemDefinition>
</p:monitoredItemDefinitionGroup>
</p:privacyMonitorDefinition>
<p:privacyMonitorDefinition>
<p:monitorName>AutoInsurancePaymentMonitor</p:monitorName>
<p:subjectKeyName>customerNo</p:subjectKeyName>
<p:monitoredItemDefinitionGroup>
<p:monitoredItemDefinition>
242 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
</p:taskModifier><p:web-resource-collection>
<p:web-resource-name>AutoInsuranceEntryServlets</p:web-resource-name>
<p:description>AutoInsurance http entry points</p:description>
<p:url-pattern>/viewautoInsurance</p:url-pattern>
</p:web-resource-collection>
</p:privacyTaskSetupPoint>
<p:privacyOperationPoint>
<p:monitorName>AutoInsurancePolicyMonitor</p:monitorName>
<p:operation>USE</p:operation>
<p:enforcement>true</p:enforcement>
<p:operationInfoClassName>com.ibm.banker2003privacy.ViewEmployeeActivity</p:ope
rationInfoClassName>
<p:web-resource-collection>
<p:web-resource-name>viewautoInsuranceResults</p:web-resource-name>
<p:url-pattern>/viewautoInsurance</p:url-pattern>
</p:web-resource-collection>
</p:privacyOperationPoint>
<p:privacyOperationPoint>
<p:monitorName>AutoInsurancePaymentMonitor</p:monitorName>
<p:operation>USE</p:operation>
<p:enforcement>true</p:enforcement>
<p:operationInfoClassName>com.ibm.banker2003privacy.CreateAccountActivity</p:op
erationInfoClassName>
<p:web-resource-collection>
<p:web-resource-name>CreateAccount</p:web-resource-name>
<p:url-pattern>/viewautoInsurance</p:url-pattern>
</p:web-resource-collection>
</p:privacyOperationPoint>
</p:privacyDescriptors>
244 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
<xs:sequence>
<xs:element name="monitorName" type="xs:string"/>
<xs:element name="submission" type="xs:boolean" minOccurs="0"/>
<xs:element name="access" type="xs:boolean" minOccurs="0"/>
<xs:element name="enforcement" type="xs:boolean" minOccurs="0"/>
<xs:element name="storageActivityInfoClassName" type="xs:string"/>
<xs:element name="web-resource-collection"
type="Web-resource-collection"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyIdentitySetupPoint">
<xs:sequence>
<xs:element name="monitorScope" type="xs:string"/>
<xs:element name="userIdentitySource" type="UserIdentitySourceEnum"/>
<xs:element name="principalClassName" type="xs:string"
minOccurs="0"/>
<xs:element name="headerElementName" type="xs:string" minOccurs="0"/>
<xs:element name="sessionAttributeName" type="xs:string"
minOccurs="0"/>
<xs:element name="assertedUserIdentity" type="xs:string"
minOccurs="0"/>
<xs:element name="web-resource-collection"
type="Web-resource-collection"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyTaskSetupPoint">
<xs:sequence>
<xs:element name="monitorScope" type="xs:string"/>
<xs:element name="generatorClassName" type="xs:string"
minOccurs="0"/>
<xs:element name="taskModifier" type="TaskModifier" minOccurs="0"/>
<xs:element name="web-resource-collection"
type="Web-resource-collection"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyMonitorDefinition">
<xs:sequence>
<xs:element name="monitorName" type="xs:string"/>
<xs:element name="monitorAttribute" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
246 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 248. Note that some of the documents referenced here may be available
in softcopy only.
Enterprise Security Architecture with IBM Tivoli Solutions, SG24-6014
LDAP Implementation Cookbook, SG24-5110
DB2 Warehouse Management: High Availability and Problem Determination
Guide, SG24-6544
Other publications
These publications are also relevant as further information sources:
IBM Tivoli Privacy Manager for e-business Planning Guide Version 1.1,
SC32-4789
IBM Tivoli Privacy Manager for e-business Monitor Developer’s Guide Version
1.1, SC32-4790
IBM Tivoli Privacy Manager for e-business Installation Guide Version 1.1,
SC32-4791
IBM Tivoli Privacy Manager for e-business Problem Determination Guide
Version 1.1, SC32-4792
IBM Tivoli Privacy Manager for e-business, Reference Monitor Guide, Version
1.1
IBM Tivoli Privacy Manager for e-business Monitor Developer’s Guide,
Version 1.2, SC32-1286
248 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Index
A B
bean interface
access control 4
... for Reference Monitor 107
granularity 14
benchmark
standard 12
privacy 7
access ID
blood researcher 90
mapping 225
BS 7799 11
Access Manager 28, 30, 37
business layer 106
Java Runtime Environment 41
Business Process Monitor 76
WebSEAL 113
business purpose 13
access notification 117
business requirements
access/participation 8
health care environment 85
administrative users 35
human services environment 138
AIX
J2EE banking environment 186
performance considerations 49
alphaWorks 208
analyst 87 C
anonymization 82 Callout Monitor 105
Application Callout Monitor 70, 105 Chief Information Security Officer 17
application components 28 Chief Privacy Officer 16
Application Exit Point Monitor 68, 155 choice 22
application task identification 114 choice/consent 8
approval 5 class name 10
architecture classification
dedicated server 38 ... of data or information 9
enterprise server 44 classification of information 5
logical components 28 client-server application 28
physical components 38 command object 114
asserted user credentials 23 component architecture
auditor 18 dedicated server 38
auditor role 35 enterprise server 44
authentication 4, 28 high availability 46
centralized 30 IBM Enterprise Privacy Architecture 55
standard 11 logical 28
strength 91 physical 38
two-factor 92 scalability 46
authorization 28 condition rule mapping 223
centralized 30 condition rules 52
procedure 14 confidentiality 17
transaction level 23 conformance check 117–118
availability 17 consent 13, 22, 32, 89, 91, 118
awareness/notice 8 collection procedure 15
explicit 88
consent/choice 8
250 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
identity setup point 185, 198 DPM implementation 197
identity theft 13 high availability 48
IIOP communication 37 HIPAA 37
implementation architecture patterns 63
J2EE banking environment 196 proxy monitor 65
information classification 5 request 35
instance authorization 24 Siebel architecture 151
integrity 17 Siebel deployment 169
integrity/security 9 Software Development Kit 36, 40, 64
internal health researcher 90 XML file descriptor 185
ISO 17799 11–12 monitor.password 200
monitor.properties file 199
monitor.userid 200
J monitorClassName 199
J2EE
monitored system 34
application pattern 106
MonitoredItemDefinitionGenerator 208
deployment descriptors 74
monitoring 86
Java Servlet Specification 196, 200
MonitorPluginImpl 207
JVM maximum heap size 52
monitorScope 198
JVM starting heap size 51
L N
network protocols
LDAP
dedicated server configuration 42
replication 47
notice/awareness 8
LDAP directory 30
nurse 88
LDAP Monitor 66
liability 3
logFileName 199 O
loggerClassName 199 obligation 54
loggerLevel 199 operation point 185, 198
loggerName 199 operational descriptors 203
logging 18, 24, 196 OperationEnum values 205
logging standard 13 OperationInfo 207
logical component architecture 28 opt-in/opt-out 7–8, 56, 91
opt-inpt-out 185
ORB thread pool size 51
M owner
master key registration 113
... of data 10
Metadata Processor 67
monitor 32–33, 36, 40
Application Callout Monitor 70, 106 P
Application Exit Point Monitor 68, 155 P3P policies 36
Business Process Monitor 76 P3P policy 210, 227
communication protocol 37 P3P policy file 237
component responsibility 64 participants 87
Declarative Monitor 73 participation/access 8
declarative privacy monitoring 183, 196 password
definition 185 stolen, risk 103
deployment 220 patient 87–88
Index 251
patterns for monitor design 63 threats 103
performance wrapper 117
improve 120 XML descriptor file 196
performance considerations 48 Privacy Context object 72
physical component architecture 38 Privacy Data Handling Node 57
PII Privacy Database Server 41
access detection 156 Privacy Manager Console 34
data 150 Privacy Server 34, 40
data types 228 high availability 48
mapping 221 performance considerations 52
plug-in class 207 Privacy Service Node 58
policy privacyIdentitySetupPoint descriptor 213
corporate 3 privacyIdentitySetupPoint element 203
policy enforcement point 36 privacyMonitorDefinition descriptor 211
policy group 93 privacyMonitorDefinition element 202
practice privacyOperationPoint element 205
privacy 5 privacyOperationSetupPoint descriptor 214
practices 4 PrivacyServletContextListener 75
preferred general practitioner 87–88 PrivacyServletFilter 75
Prepared statement cache size 51 privacyTaskDefinition descriptor 213
presentation layer 106 privacyTaskDefinition element 203
privacy 28 privacyTaskSetupPoint descriptor 214
administrators 35 privacyTaskSetupPoint element 204
auditor 35 procedures 4
benchmark 7 property rights 22
centralized service 32 Protocol Adapter 67
corporate policy 182 protocols
data design 189 dedicated server configuration 42
database 36 proxy monitor 65
deny all data (Siebel) 157 purpose 13, 28, 35–36, 184, 210, 223
deployment descriptor XML file 184, 200–201, classification 20
206, 211, 241 determination (Siebel) 161
enforcement 117 mapping 224
field level enforcement (Siebel) 159
governance 5, 15
management architecture 32
R
real-time enforcement 117
management components 34
recipient category 93
management requirements 16
Redbooks Web site 248
monitor 32, 36
Contact us xiv
no enforcement (Siebel) 157
Reference Monitor 37, 65, 107
policies 41
Siebel integration 155
policy 8, 54
storage location 109
policy conformance check 37
replication
policy design 184
LDAP 47
policy usage statements 149
report definition 36
presentation layer enforcement (Siebel) 161
researcher 87
record level enforcement (Siebel) 158
residual risk 3
rules 191
retention policy 15
statement 7, 9
252 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
risk System Managed Space 50
data exposure 91
mitigation 17
risk assessment
T
task definition 185, 198
health care system 103
task setup point 185, 198
J2EE banking environment 195
TaskDefinitionGenerator 208
Role Based Access Control 12
TaskModifierGenerator 207
role definition standard 11
technical implementation
roles and responsibilities 10
health care environment 104
human services environment 153
S J2EE banking environment 208
scalability 46 Transport Adapter 66
scope of classification 10 trust relationship 15
security two-factor-authentication 92
threats 103
security/integrity 9
segmentation criteria 10
U
User Interaction Node 56
separation of duty 126
servlet specification 113
ServletContextListener 196, 207 V
ServletFilter 196 virtual storage location 112
ServletOperationInfo 200, 215
session bean
W
... for Reference Monitor 107 Web container max threads 50
Siebel WebSEAL
Access Manager setup 172 authentication 113
architecture background 153 WebSphere Application Server
deny all privacy data 157 performance considerations 50
eScript 155 server group 48
field level privacy enforcement 159 Windows
monitor deployment 169 performance considerations 49
no privacy enforcement 157
presentation layer privacy enforcement 161
purpose determination 161
record level privacy enforcement 158
Siebel.properties 170
SOAP 156
Solaris
performance considerations 49
standards 4
storage location 35, 156
classification 220
condition rule mapping 223
registration 37, 109
virtual 112
Storage System Adapter 66
submission detection 120
Support Tools Node 57
Index 253
254 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
IBM Tivoli Privacy Manager Solution Design and Best Practices
(0.5” spine)
0.475”<->0.875”
250 <-> 459 pages
Back cover ®