Transcript Slide 1

Towards Scalable
Management of
Privacy Obligations
in Enterprises
Marco Casassa Mont
Hewlett-Packard Labs
© 2006 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Privacy: An Important Aspect of Regulatory
Compliance
Regulations (incomplete list …)
4
18 July, 2015
PRIVACY
Regulatory Compliance
(Example of Process)
Privacy: Impact on Users and Enterprises
Privacy Legislation
(EU Laws, HIPAA, COPPA, SOX, GLB, Safe Harbour, …)
Customers’
Expectations
Internal
Guidelines
Applications
& Services
Personal
Data
PEOPLE
ENTERPRISE
Customers’
Satisfaction
5
18 July, 2015
Regulatory Compliance
Positive Impact on
Reputation, Brand,
Customer Retention
Privacy Obligations
•
Privacy Obligations are Policies that describe Duties and Expectations
on how PII Data Should be Managed in Enterprises
•
They dictate “Privacy-aware Information Lifecycle Management”
•
They can be defined by Privacy Laws, Data Subjects’ Preferences and
Enterprise Guidelines
Purpose Specif.
Privacy
Permissions
Consent
Limited Collection
Privacy
Privacy Limited Use
RightsLimited DisclosureObligations
Limited Retention
Privacy Policies
6
18 July, 2015
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Privacy Obligations: A Complex Topic …
Duration
Enforcement
Constraints dictated by
Obligations:
Long-term
Ongoing
• Notice Requirements
• Enforcement of
opt-in/opt-out
options
Short-term
One-time
Obligations
Types
• Limits on reuse
of Information
Other
Transactional Data
Retention & Event-driven
Dependent
Handling
on Access
Control
and Information
Sharing
• Data Retention
limitations …
Context
Independent
from Access
Control
Data Subject
“Notify User via e-mail1 If his Data is Accessed”
“Delete Data XYZ after 7 years”
Enterprise
Setting
“How Represent Privacy Obligations? How to Stick them to Personal Data?
How
to Manage, Enforce and Monitor them? How to Integrate them into current IDM solutions?”
8
18 July, 2015
Privacy Obligations: Common Aspects
• Timeframe (period of validity) of obligations
• Target of an obligation (PII data)
• Events/Contexts that trigger the need to fulfil
obligations
• Actions/Tasks/Workflows to be Enforced
• Responsible for enforcing obligations
• Exceptions and special cases
9
18 July, 2015
Technical Work in this Space
- P3P (W3C):
- Definition of User’s Privacy Expectations
- Explicit Declaration of Enterprise Promises
- No Definition of Mechanisms for their Enforcement
- Data Retention Solutions, Document Management Systems,
Ad-hoc Solutions for Vertical Markets
- Limited in terms of expressiveness and functionalities.
- Focusing more on documents/files not personal data
- IBM Enterprise Privacy Architecture, EPAL, XACML …
- No Refined Model of Privacy Obligations
- Privacy Obligations Subordinated to AC. Incorrect …
10
18 July, 2015
Our Approach in EU PRIME Project
• Privacy Obligations are “First-Class entities”:
No Subordination to Access Control/Authorization View
 Explicit Representation, Management
and Enforcement of Privacy Obligations
• Allow Data Subjects to Express their Privacy Preferences
that are Mapped into Enterprises’ Obligations
• Provide a Solution to Enterprises to Automate the Management
and Enforcement of Privacy Obligations
11
18 July, 2015
Obligation Management System (OMS): Model
Obligations
Monitoring
Data
Subjects
Obligations
Scheduling
Obligations
Enforcement
Privacy
Preferences
Obligation
Management
Framework
Administrators
Privacy Obligations
Personal
Data (PII)
ENTERPRISE
12
18 July, 2015
Privacy Obligations: Modelling and Representation
Privacy Obligation
Obligation Identifier
Targeted Personal Data
References to stored
PII data
e.g. Database query,
LDAP reference,
Files, etc.
Triggering Events
Actions
Additional Metadata
(Future Extensions)
One or more Events
that trigger different
Actions
e.g. Event: Time-based events
Access-based
Context-based
On-Going Events
Actions: Delete, Notify, …
13
18 July, 2015
Simple Example of Privacy Obligation
<obligation ObligationId=“OBLID1”>
<target // Reference to the PII Data the obligation is associated to
<data repository>databaseA <data repository>
<data structure type=TABLE> CustomerTable </data structure>
<data attr="ALL“ @key:UserId:PSEUDO1 </data>
</target>
<events operator=“">
<event id="e1">
<type>TIMEOUT</type>
<date now="no"> 2007/10/13 14:01:00 </date>
</event>
</events>
<actions>
<action id="a1">
<type>DELETE</type>
<data attr="part">
<item> // Reference to the PII Data attribute
@key:UserId:PSEUDO1|att:CreditCard
</item>
</data>
</action>
<action id="a2">
<type>NOTIFY</type>
<method>EMAIL</method>
<to> // Reference to the PII Data attribute
@key:UserId:PSEUDO1|att:E-Mail
</to>
</action>
</actions>
</obligation>
14
18 July, 2015
Explicit Reference
to a Piece of
Customer Data
(Target)
Time-based triggering
Event
Prescribed Actions
Involving Notification
of Customer and data
Deletion
OMS: High Level System Architecture
Data
Subjects
Enforcing
Privacy-enabled
Privacy
Portal
Obligations
Monitoring
Privacy
Obligations
Admins
Obligation
Server
Applications and Services
Admins
Events
Obligation
Monitoring
ServiceObligations
Setting
Privacy
Handler
Data
MonitoringOn
TaskPersonal
Handler
Obligation
Scheduler
Workflows
Obligation
Enforcer
Action Adaptors
Obligation
Data
Ref.
Obligation Store
& Versioning
15
18 July, 2015
Audit
Server
Confidential Data
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Current Model: Association of Privacy Obligations to
Personal Data
Personal Data
+
Privacy
Obligations
Data Subjects
(Users)
Privacy
Obligations
Obligation
Management
System
Personal Data
1:1 Association
Obligations
Personal Data
Enterprise
Data Repositories
Privacy Preferences
(Deletion, Notification, etc.) are
Embedded within Obligations
ENTERPRISE
17
18 July, 2015
Association
of Privacy
Obligations
To PII Data
Example of Embedded Preferences/Refs
<obligation ObligationId=“OBLID1”>
<target // Reference to the PII Data the obligation is associated to
<data repository>databaseA <data repository>
<data structure type=TABLE> CustomerTable </data structure>
<data attr="ALL“ @key:UserId:PSEUDO1 </data>
</target>
<events operator=“">
<event id="e1">
<type>TIMEOUT</type>
<date now="no"> 2007/10/13 14:01:00 </date>
</event>
</events>
<actions>
<action id="a1">
<type>DELETE</type>
<data attr="part">
<item> // Reference to the PII Data attribute
@key:UserId:PSEUDO1|att:CreditCard
</item>
</data>
</action>
<action id="a2">
<type>NOTIFY</type>
<method>EMAIL</method>
<to> // Reference to the PII Data attribute
@key:UserId:PSEUDO1|att:E-Mail
</to>
</action>
</actions>
</obligation>
18
18 July, 2015
Explicit Reference
to a Piece of
Customer Data
Time-based triggering
Event
Prescribed Actions
Involving Notification
of Customer and data
Deletion
Current Approach: Pros and Cons
Pros
•
Provides Flexible, Fine-grained Mechanism to End-Users to Express their Privacy
Preferences
•
Supports Mechanism to Automatically Turn Privacy Preferences into Obligations
•
Supports Customisation of Obligations (Events/Actions) as long as
supported by the OMS
Cons
•
(Linear) Growth of Number of Managed Obligations depending on Size of Data
•
High Demand on Management and Monitoring Resources
•
Administrative and GUI Usability Issues in case of Large Amounts of PII data
and Associated Obligations
19
18 July, 2015
Open Issues
•
Scalability Problem when Handling Large Amounts of PII
Data (>100K) and Related Privacy Preferences:
− Too many (Similar) Obligations to be Handled
− Too many (Computational) Resources might be Required by OMS
− Difficult to Administer Large Number of Obligations (not Scalable)
•
20
Need for Adequate Administrative Tools, inclusive of Admin
GUI Capabilities (Importance of HCI Aspects …)
18 July, 2015
Open Issues: Current Administrative Tools
21
18 July, 2015
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Learning Contexts
•
PRIME: Integration of OMS Component in PRIME Integrated
Prototype (IPV1)
https://www.prime-project.eu/
•
HP:
Integration of OMS with HP OpenView Select Identity
to enable Privacy-aware Information Lifecycle Mgmt
during Identity Provisioning
http://www.hpl.hp.com/techreports/2005/HPL-2005-180.html
23
18 July, 2015
Learnt Lessons [1/3]
It is not feasible for the Enterprise to allow Users to Define
any Arbitrary Combinations of Privacy Preferences and
Constraints Specifications – even within the Types of
Obligations that an Enterprise can potentially Support:
− Involved Costs and Complexity
− Usability Aspects for End-Users (e.g. Policy Authoring)
− Not all the Potential Combinations of Constraints make
Sense …
24
18 July, 2015
Learnt Lessons [2/3]
End-Users are actually NOT so Interested in Dealing with the
Authoring of Obligations and/or Coping with Related
Complexity:
− Need for Simple and Intuitive Visual Approaches to
Capture Relevant Privacy Preferences
(Source: Karlstad University – OMS GUI Trial)
− Little Efforts should be Required: Just Express
Preferences…
− Lack of Users’ Knowledge in Privacy Matters
25
18 July, 2015
Learnt Lessons [3/3]
Enterprise Administrators Need Effective Admin Tools to
Manage and Monitor Obligations:
− Intuitive Administrative Tools and GUIs
− Easy Ways to Retrieve Obligations
− Easy Ways to Handle the Lifecycle of Obligations
26
18 July, 2015
Approach Followed in PRIME [1/2]
•
It is Preferable to Provide Users with a “List” of Predefined
Types of Privacy Obligations supported by the Enterprise
•
Each Obligation Type has a Predefined Structure (e.g. set
of Events and Actions)  “Obligation Template”
•
Each Obligation Type explicitly describes which Privacy
Preferences need to be Specified by the End-User
•
End-Users see a “Natural Language” Description of these
Obligations. They only need to Provide the related Privacy
Preferences via Simplified GUIs
27
18 July, 2015
Actual Approach Followed in PRIME [2/2]
Attempt to
Access Service
Disclose PII +
Privacy Prefs.
PRIME GUI
User
Req. PII Data +
Privacy Prefs.
Request to Disclose PII Data
& List of Relevant
Obligation Templates
Privac
y
Admin
s
Obligation Templates
(Types)
Push Instantiated
Obligation Templates
(i.e. with Privacy Prefs)
Obligation
Management
System
PRIME Toolbox
28
18 July, 2015
Obligation Template (Type):
- Defines Obligation Structure
- Defines Types of Privacy Prefs
ENTERPRISE
Example of Obligation Template
<obligation ObligationId=“OBLID1”>
<target // Reference to the PII Data the obligation is associated to
<data repository>databaseA <data repository>
<data structure type=TABLE> CustomerTable </data structure>
<data attr="ALL“ @key:UserId:[?] </data>
</target>
<events operator="">
Deletion
<event id="e1">
<type>TIMEOUT</type>
Preference:
<date now="no"> [?] </date>
</event>
Specified by User
</events>
<actions>
<action id="a1">
<type>DELETE</type>
<data attr="part">
<item> // Reference to the PII Data attribute
@key:UserId:[?]|att:CreditCard
</item>
</data>
</action>
<action id="a2">
<type>NOTIFY</type>
<method>EMAIL</method>
<to> // Reference to the PII Data attribute
@key:UserId:[?]|att:E-Mail
</to>
</action>
</actions>
</obligation>
29
18 July, 2015
User Id References:
Automatically
Filled In by OMS
Some Important Observations
•
Obligation Templates Do Not Solve the Scalability Problem:
− For each piece of PII Data  one or more Obligations
still Need to be Generated and Associated
•
However:
− All Obligations generated by an Obligation Template are Structurally
Identical (Same Set of Events/Actions)
− They only differ because of Embedded Privacy Preferences and/or
Embedded PII References
30
18 July, 2015
Towards A More Scalable Management of Privacy
Obligations
•
Why not Managing Obligations in a way that is Parametric
to Privacy Preferences and References?
•
Why not “solving” these References at the
Enforcement/Monitoring Time?
 Concept of Parametric Privacy Obligations …
31
18 July, 2015
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Parametric Privacy Obligations
•
Parametric Obligation: contains a Parametric Definition of
Obligation’s Target, Events, Actions
•
Its Structure is still based on Predefined Obligation
Templates
However, once Instantiated, it contains References to
Personal Data and Privacy Preferences
•
•
Privacy Preferences are Not Embedded Anymore within
Parametric Obligations but they are Stored in a Separated
Repository (controlled by OMS)
• References are Resolved by OMS at Runtime
33
18 July, 2015
New Model based on Parametric Obligations [1/2]
Personal Data
+
Privacy
Preferences
Privacy
Preferences
Obligation
Management
System
Privacy
Obligations
Derived From
Templates
Personal Data
Data Subjects
(Users)
Privacy Prefs.
N:1 Association
Parametric
Obligation1
Parametric
Obligation2
Personal Data
Enterprise
Data Repositories
Privacy Preferences
(Deletion,
Notification,etc.)
ENTERPRISE
34
18 July, 2015
New Model based on Parametric Obligations [2/2]
•
Each Parametric Obligations Can be Associated to a
Large Set of PII Data (Target)
− Drastic Reduction of Number of Explicit Instances of (Similar)
Obligations
•
Easier Administrative Management of Obligations
•
OMS still has to Keep Track of Fine Grained Operational
Information about the Management of “Obligations” for
each Piece of PII Data:
− Status of Events
− Status of Enforced Actions
•
35
More Complexity in Obligation Definition (Target) …
18 July, 2015
Hybrid Obligation Management Model
•
Deal with both:
− “Traditional” Obligations
− Parametric Obligations
•
Parametric
Obligations
Traditional
Obligations
Hybrid Model to Address:
− Flexibility in Specifying ad-hoc Obligations
− Minimise, if Required, Redundancy of Managed Obligations – in
case of Large Number of PII Data
•
36
Give a Choice on which Type of Obligations to Use
Ensure that the Required Level of Scalability, Flexibility
and Customisation can be Provided
18 July, 2015
Discussion
•
The Proposed Model does not Limit the Control that
Users can have in Specifying Privacy Preferences
•
The Number of “Similar” Obligations Managed by the
OMS is Reduced. Less Computational Resources. More
Scalability in Managing Obligations.
•
R&D Work still needs to be Done to Provide a more
Suitable Admin GUI and related Tools to Administrators
•
Full Implementation is Required to Analyse Results and
Compare against Current OMS System …
•
This is Work in Progress …
37
18 July, 2015
Current Status and Next Steps
•
We are Extending the Current OMS System to Handle also
Parametric Obligations (i.e. Hybrid Model)
•
First Fully Working Prototype to be Completed in 2-3
months: Scalability and Performance will be Analysed and
Results Published
•
Next Steps - Continue our Research in the Context of
PRIME and HPL Projects:
− Further Refine the Hybrid/Parametric Model
− Explore the Management Lifecycle of Parametric
Obligations
− Build more Advanced Admin GUIs and Related Tools
38
18 July, 2015
Presentation Outline
• Privacy Concepts and Background
• Our Current Work on Obligation Management
• Scalability Problems and Open Issues
• Learnt Lessons
• Moving Towards Scalable Obligation Mgmt
• Conclusions
Conclusions
•
Privacy Management is Important for Enterprises
•
Focus on Providing Tools to Handle Privacy Obligations
•
First Implementation of Obligation Management System in PRIME and
HPL as a Proof-of-Concept: Scalability Issues …
•
Important Requirement: Handle Obligations on Large set of PII Data
(>100k)
•
Learnt Lessons: Avoid Defining Redundant Obligations & Simplicity
•
Moving Towards Parametric Privacy Obligations
•
Possibility to Leverage an Hybrid Model
•
Working Prototype based on this Model will be Available soon for Tests
and Comparative Analysis …
•
R&D Work in Progress …
40
18 July, 2015
BACKUP Slides
41
18 July, 2015
Privacy Obligation Refinement: Abstract vs. Refined
Obligations can be very abstract:
“Every financial institution has an affirmative and continuing
obligation to respect customer privacy and protect
the security and confidentiality of customer information”
Gramm-Leach-Bliley Act
More refined Privacy Obligations dictate Duties,
Expectations and Responsibilities on How to Handle
Personal Data:
• Notice Requirements
• Enforcement of opt-in/opt-out options
• Limits on reuse of Information and Information Sharing
• Data Retention limitations …
42
18 July, 2015
Key Requirements
• Explicit Modeling and Representation of privacy obligations
• (Strong) Association of obligations to data
• Mapping obligations into enforceable actions
• Compliance of refined obligations to high-level policies
• Tracking the evolution of obligation policies
• Dealing with Long-term Obligation aspects
• Accountability management and auditing
• Monitoring obligations
• User involvement
• Handling Complexity and Cost of instrumenting Apps and Services
43
18 July, 2015
Potential Model Implementations [1/2]
•
Based on “General Purpose Approach” to Manage
Parametric Obligation:
− General-purpose OMS Data Structure to Store Operational
Information about Events Actions
− Pros:
• it works for all types of parametric obligations
− Cons:
• it might need to be extended for new types of parametric obligations
• it cannot be optimised for each type of parametric obligations
44
18 July, 2015
Potential Model Implementations [2/2]
Based on the Concept of “Obligation Blade”:
− Each Parametric Obligation comes in a “bundle” including also the
definition of required OMS Data Structures to support that
obligation
− Pros:
• it allows for further optimisation
− Cons:
• it introduced more complexity in the definition and administration of
each type of parametric obligations
45
18 July, 2015