Towards Scalable Management of Privacy Obligations in Enterprises

1. Towards Scalable Management of Privacy Obligations in Enterprises Marco Casassa MontHewlett-Packard Labs

2. 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

3. 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

4. PRIVACY Privacy: An Important Aspect of Regulatory Compliance Regulatory Compliance (Example of Process) Regulations (incomplete list …)

5. Privacy Legislation (EU Laws, HIPAA, COPPA, SOX, GLB, Safe Harbour, …) Internal Guidelines Customers’ Expectations Applications & Services Personal Data PEOPLE ENTERPRISE Positive Impact on Reputation, Brand, Customer Retention Customers’ Satisfaction Regulatory Compliance Privacy: Impact on Users and Enterprises

6. Purpose Specif. Privacy Permissions Consent Limited Collection Privacy Obligations Privacy Rights Limited Use Limited Disclosure Limited Retention Privacy Policies 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

7. 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

8. Duration Enforcement Long-term Ongoing Short-term Obligations One-time Types Other Event-driven Transactional Data Retention & Handling Dependent on Access Control Independent from Access Control Data Subject Context “Notify User via e-mail1 If his Data is Accessed” “Delete Data XYZ after 7 years” Enterprise “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?” Setting Privacy Obligations: A Complex Topic … • Constraints dictated by Obligations: • Notice Requirements • Enforcement of • opt-in/opt-out • options • Limits on reuse • of Information • and Information • Sharing • Data Retention • limitations …

9. 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

10. - No Refined Model of Privacy Obligations - Privacy Obligations Subordinated to AC. Incorrect … 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 …

11. 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

12. Obligation Management Framework Obligations Monitoring Obligations Enforcement Obligations Scheduling Privacy Preferences Privacy Obligations Personal Data (PII) Obligation Management System (OMS): Model Data Subjects Administrators ENTERPRISE

13. References to stored PII data e.g. Database query, LDAP reference, Files, etc. Targeted Personal Data Triggering Events One or more Events that trigger different Actions e.g. Event: Time-based events Access-based Context-based On-Going Events Actions: Delete, Notify, … Privacy Obligations: Modelling and Representation Privacy Obligation Obligation Identifier Actions Additional Metadata (Future Extensions)

14. Explicit Reference to a Piece of Customer Data (Target) Time-based triggering Event Prescribed Actions Involving Notification of Customer and data Deletion Simple Example of Privacy Obligation

15. Enforcing Privacy Obligations Setting Privacy Obligations On Personal Data Monitoring Privacy Obligations OMS: High Level System Architecture Applications and Services Data Subjects Admins Privacy-enabled Portal Events Handler Obligation Monitoring Service Monitoring Task Handler Admins Obligation Server Workflows Obligation Enforcer Obligation Scheduler Information Tracker Action Adaptors ENTERPRISE Audit Server Data Ref. Obligation Obligation Store & Versioning Confidential Data

16. 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

17. Personal Data + Privacy Obligations Association of Privacy Obligations To PII Data Privacy Obligations Personal Data 1:1 Association Obligations Privacy Preferences (Deletion, Notification, etc.) are Embedded within Obligations Current Model: Association of Privacy Obligations to Personal Data Obligation Management System Data Subjects (Users) Personal Data Enterprise Data Repositories ENTERPRISE

18. Explicit Reference to a Piece of Customer Data Time-based triggering Event Prescribed Actions Involving Notification of Customer and data Deletion Example of Embedded Preferences/Refs

19. 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

20. 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) • Need for Adequate Administrative Tools, inclusive of Admin GUI Capabilities (Importance of HCI Aspects …)

21. Open Issues: Current Administrative Tools

22. 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

23. 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

24. 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 …

25. 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

26. 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

27. Approach Followed in PRIME [1/2] • It is Preferable to Provide Users with a “List” of PredefinedTypes 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

28. Obligation Templates (Types) • Obligation Template (Type): • Defines Obligation Structure • Defines Types of Privacy Prefs Actual Approach Followed in PRIME [2/2] Attempt to Access Service Request to Disclose PII Data & List of Relevant Obligation Templates Privacy Admins Req. PII Data + Privacy Prefs. User PRIME GUI Disclose PII + Privacy Prefs. Push Instantiated Obligation Templates (i.e. with Privacy Prefs) Obligation Management System PRIME Toolbox ENTERPRISE

29. Example of Obligation Template Deletion Preference: Specified by User User Id References: Automatically Filled In by OMS

30. 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 PrivacyPreferences and/or Embedded PII References

31. 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 …

32. 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

33. 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

34. Privacy Obligations Derived From Templates Parametric Obligation1 Parametric Obligation2 New Model based on Parametric Obligations [1/2] Personal Data + Privacy Preferences Privacy Preferences Obligation Management System Personal Data Data Subjects (Users) N:1 Association Privacy Prefs. Personal Data Privacy Preferences (Deletion, Notification,etc.) Enterprise Data Repositories ENTERPRISE

35. 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 • More Complexity in Obligation Definition (Target) …

36. Hybrid Obligation Management Model Parametric Obligations Traditional Obligations • Deal with both: • “Traditional” Obligations • Parametric 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 • Give a Choice on which Type of Obligations to Use Ensure that the Required Level of Scalability, Flexibility and Customisation can be Provided

37. 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 …

38. 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

39. 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

40. 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 …

41. BACKUP Slides

42. 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 …

43. Key Requirements • ExplicitModelingand Representation of privacy obligations • (Strong) Association of obligations to data • Mappingobligations 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

44. 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

45. 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