Marco Casassa Mont, Siani Pearson, Tariq Elahi and Stephen Crane

1. PRIME Languages for:- Privacy Obligation Policies- Compliance Checking Policies- Trust Constraints/Policies Marco Casassa Mont, Siani Pearson, Tariq Elahi and Stephen Crane marco.casassa-mont@hp.com, siani.pearson@hp.com, tariq.ee@hp.com, stephen.crane@hp.com Trusted Systems Lab, HP Labs, Bristol, UK

2. Presentation Outline Setting the Context Privacy Obligation Policies[Marco Casassa Mont] Compliance Checking Policies [Siani Pearson] Trust Constraints/Policies [Stephen Crane] Conclusions

3. Presentation Outline Setting the Context Privacy Obligation Policies[Marco Casassa Mont] Compliance Checking Policies [Siani Pearson] Trust Constraints/Policies [Stephen Crane] 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. Data Governance and Policy Management, Including Privacy Policies Policy Development and Modelling Monitoring, Audit, Reporting and Policy Management Data Inventory People/Roles Systems/Applications/Services Gap and Risk Analysis Policy Enforcement Confidential/Personal Data Policy Deployment

7. HPL Contribution to PRIME • PRIME Languages for: • Privacy Obligation Policies • Compliance Checking Policies • Trust Management Policies • Systems to Manage and Enforce these Policies in PRIME within Enterprises and at the User-side

8. Presentation Outline Setting the Context Privacy Obligation Policies[Marco Casassa Mont] Compliance Checking Policies [Siani Pearson] Trust Constraints/Policies [Stephen Crane] Conclusions

9. Purpose Specif. Privacy Permissions Consent Limited Collection Privacy Obligations Privacy Rights Limited Use Limited Disclosure Limited Retention Privacy Policies Privacy Obligation Policies • Privacy Obligations are Policies that describe Duties and Expectations on how PII Data Should be Managed, in particular by Enterprises (Collecting PII Data) • They are at the very base of “Privacy-aware Information Lifecycle Management” • They can be dictated by Law, Data Subjects’ Preferences and Enterprise Guidelines

10. Privacy Obligations: 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 and • Responsibilities with respect of Personal Information: • Notice Requirements • Enforcement of opt-in/opt-out options • Limits on reuse of Information and Information Sharing • Data Retention limitations …

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

12. Related Work [1/2] • - P3P (W3C): • - Definition of User’s Privacy Expectations • - Explicit Declaration of Enterprise Promises • - No Definition of Mechanisms for their Enforcement • Data Retention Solutions and Document Management • Systems. • - Limited in terms of expressiveness and functionalities. • - Focusing more on documents/files, not really on personal data • - Ad-hoc Solutions for Vertical Markets

13. - No Refined Model of Privacy Obligations - Privacy Obligations Subordinated to AC … Related Work [2/2] • Recent relevant Work done in this Space: • IBM Enterprise Privacy Architecture, including • a policy management system, a privacy enforcement • system and audit • Initial work on privacy obligations in the context of • Enterprise Privacy Authorization Language (EPAL) • XACML (OASIS): similar standard proposal

14. Our Approach in PRIME • 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

15. Obligation Management Framework Obligations Monitoring Obligations Enforcement Obligations Scheduling Privacy Preferences Privacy Obligations Personal Data (PII) Obligation Management: PRIME Model Enabling Privacy-aware Information Lifecycle Management: Data Subjects Administrators ENTERPRISE

16. Privacy Obligations: 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

17. Our Analysis of Privacy Obligations: Key Properties • Timeframe(period of validity) of obligations • Events/Contexts that trigger the need to • fulfil obligations • Target of an obligation (PII data) • Actions/Tasks/Workflows to be Enforced • Responsible for enforcing obligations • Exceptions and special cases

18. 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: Model and Representation Privacy Obligation Obligation Identifier Actions Additional Metadata (Future Extensions)

19. Privacy Obligations: Formal View Privacy Obligation is a <i,t,L(e),C(a)> tuple <i,t,e,a> <I, 2^T, 2^E, 2^A > i I: set of all unique identifiers t T: set of all possible targets e E: set of all possible events a A: set of all possible actions • L(e) : defines a logical combination (AND, OR, NOT) of events • C(a) : defines an operational combination of actions, • such as a sequence of actions

20. Privacy Obligations: Operational View OBLIGATION Oid: TARGETS: t WHEN L(e) EXECUTE C(a) Obligations As “Reactive Rules”

21. Privacy Obligation Examples Delete PII Data at a Predefined Time 1)OBLIGATION Oid1: TARGETS: t1:< DATABASE=db1, TABLE=customers, Key=CustomerName, KeyValue=abc> WHEN (current_time= date1) EXECUTE <DELETE t1> Notify Users when their PII Data is Accessed 2) OBLIGATION Oid2: TARGETS: t1:< DATABASE=db1, TABLE=customers, Key=CustomerName, KeyValue=abc, ATTRIBUTES=(e-mail) > WHEN (Access_Data_Event AND Access_Data_Event.data = t1) EXECUTE <NOTIFY BY t1.e-mail>

22. Privacy Obligation Examples Notify Users and Delete PII Data when it is not Accessed after a Predefined Date 3) OBLIGATION Oid3: TARGETS: t1:< DATABASE=db1, TABLE=customers, Key=CustomerName, KeyValue=abc ATTRIBUTES=(creditcard,e-mail)> WHEN (current_time>date1) AND (NOT (Access_Data_Event AND Access_Data_Event.data = t1 )) EXECUTE <NOTIFY BY t1.e-mail> <DELETE t1.creditcard>

23. Privacy Obligation Examples Delete PII Data and De-provision a User Account either after a specified Date Or if PII Data has been Accessed more than n Times 4) OBLIGATION Oid4: TARGETS: t1:< DATABASE=db1, TABLE=customers, Key=CustomerName, KeyValue=abc ATTRIBUTES=(creditcard,e-mail)> WHEN (current_time>date1) OR ( (Access_Data_Event AND Access_Data_Event.data = t1 ) AND (Access_Counter>n)) EXECUTE <DELETE t1.creditcard> <RUN WORKFLOW deprovision_user(t1.KeyValue)>

24. Privacy Obligation Examples Notify Users on Ongoing Bases at a Specified Interval of Time 5)OBLIGATION Oid5: TARGETS: t1:< DATABASE=db1, TABLE=customers, Key=CustomerName, KeyValue=abc, ATTRIBUTES=(e-mail)> WHEN (current_time < date1) AND (time_counter > time_interval) EXECUTE <NOTIFY BY t1.email> <RESET time_counter>

25. Privacy Obligation Examples Encrypt PII Data and Notify the administrator in case of Intrusion 6) OBLIGATION Oid6: TARGETS: t1:< DATABASE=db1, TABLE=customers> WHEN (Event-intrusion_detected) EXECUTE <ENCRYPT t1> <NOTIFY admin> Encrypt PII Data and Notify the administrator in case the System is in an inconsistent/Distrusted state 7) OBLIGATION Oid7: TARGETS: t1:< DATABASE=db1, TABLE=customers> WHEN (Event-system_distrusted) AND (DATABASE.host =system_distrusted.host) EXECUTE <ENCRYPT t1> <NOTIFY admin>

26. Privacy Obligation Examples Encrypt Address Attributes and Delete User Names in Log Files older than 6 months 8)OBLIGATION Oid8: TARGETS: t1:< FILE=../audit_log, ATTRIBUTES=(TimeStamp, UserIPaddress, UserName)> WHEN (time_counter > time_interval) EXECUTE <ENCRYPT t1.UserIpAddress> <DELETE t1.UserName WHERE t1.TimeStamp<= current_time - 6 months> <RESET time_counter>

27. Privacy Obligations: PRIME Representation in XML Format <obligation id=“gfrbg7645gt45"> <target> <database> <dbname>CustomersDB</dbname> <tname>Customers</tname> <locator> <key name=“UserID">oid_a83b8a:fdfc44df3b:-7f9c</key> </locator> <data attr="part"> <item>creditcard</item> <item>firstname</item> </data> </database> </target> <obligationitem sid="1"> <metadata> <type>LONGTERM</type> <description>Delete [creditcard,firstname] at Aug 15 17:26:21 BST 2006.]</description> </metadata> <events> <event> <type>TIMEOUT</type> <date now="no"> <year>2006</year> <month>08</month> <day>15</day> <hour>17</hour><minute>26</minute> </event> </events> <actions> <action> <type>DELETE</type> <data attr="part"> <item>creditcard</item> <item>firstname</item> </data> </action> </actions> </obligationitem> </obligation>

28. Enforcing Privacy Obligations Setting Privacy Obligations On Personal Data Monitoring Privacy Obligations Obligation Management System (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

29. Open Issues and Next Steps • Current Approach Pros • Flexible Language and Approach • Extensible and Customisable Cons • Large Set of Similar Obligations might be Created • Scalability Issues • Next Steps • Address Scalability Issues • Introduce Parametric Obligations • Extend Language (Exceptions, more types of Events, Actions, etc.)

30. Presentation Outline Setting the Context Privacy Obligation Policies[Marco Casassa Mont] Compliance Checking Policies [Siani Pearson] Trust Constraints/Policies [Stephen Crane] Conclusions

31. Compliance Checking Policies • Compliance Checking Policies describe Enterprise Assurance Properties relating to how Personal Data will be Transferred, Processed and Protected • They can help Users to Check Compliance to Law, Data Subjects’ Preferences and Enterprise Guidelines • They can refer to Trust, Assurance and Contextual Properties

32. Motivation • To allow People to make Judgements about the Trustworthiness and Privacy Compliance of the Remote Receiver of their PII data e.g. a User might Check for the Compliance of an Organisation against their Customised Preferences prior to Disclosure of PII Data • Their disclosure of PII data or the continuation of a business interaction could be subject to the outcome of this checking

33. Principles • The Assessment goes beyond just Promises on behalf of the Service Provider • It assesses the levels of proof that can be provided about privacy-providing mechanisms that are used and even how they are operating • A broader Range of Information and Assurance is Assessed than just Security Information • In some cases Assurance Policies can be Checked independently of Access Control • Broadly speaking, the Conditions Checked are Necessary, not Sufficient for the Transaction to Proceed  Ultimately, it is the User who Decides how to Proceed

34. Examples in “Natural Language” • Enterprise Processing Platforms must give a High Level of Protection for my PII Data • The Enterprise Back-end must have a Valid Privacy Seal issued by a Provider I (or some authority I delegate) Trusts • The Enterprise Back-end must give Tamper-resistant Protection to Secrets • The Service Provider should support Obligation Management and Enforcement • My PII will only be Processed within EU

35. Compliance Checking Policies: Formal View Compliance Checking Template is a <ctid, pc, L(cc)> triple <ctid, pc,cc> <CTID,PC,CC> pc PC: set of all preconditions cc CC: set of all assurance/compliance clauses ctid CTID: set of all unique identifiers Compliance Checking Policy is a <ctid, L(cc)> list <cc><CC> cc CC: set of all assurance clauses ctid CTID: set of all unique identifiers • L(cc) : defines a logical combination (AND, OR, NOT) of cc

36. Compliance Checking Policies: Operational View Compliance Templates As collections of Compliance Clauses CCPT ctid: IF<pc> CheckL(cc) Compliance Checking Policies as collections of clauses as determined by pre-conditions CCP ctid: CheckL(cc)

37. Compliance Checking Examples Transfer selected PII if it adheres to Government Policy Template 1)CT ctid1: IF templateIS(Government) CHECK inEU(ReceivingLocality) AND trusted(ReceivingParty) Transfer sensitive selected PII only if it adheres to Secure Storage Policy Template 2) CT ctid2: IF templateIS(SecureStorage) CHECK NOT(isSensitive(t1)) OR (trustedPlatform(Device) AND encrypted(t1,minLevel))

38. Privacy Compliance Checking Policies: PRIME Representation in XML Format <ccpolicy> <ctid>1337</ctid> <clause1 gid=”1”> <pref1>128</pref11> <pref2>AES</pref2> </clause1> <clause2 gid=”2”> <pref1>128</pref1> </clause2> <clause3 gid=”3”> </clause3> </ccpolicy> Results: <ccpolicy> <ctid>1337</ctid> <clause1 gid=”1”> <constraint1>128</constraint1> <constraint2>AES</constraint2> <result>Y</result> <signature>abcdef1234567</signature> </clause1> <clause2 gid=”2”> <constraint1>128</constraint1> <result>Y</result> <signature>1341341234124</signature> </clause2> <clause3 gid=”3”> <result>Y</result> <signature>98765787646</signature> </clause3> </ccpolicy>

39. Our Approach in PRIME Two ways in which the checking can be invoked: • As independent Assurance Compliance Checking function invoked by an entity to conduct tests against a compliance template - e.g. User initiating compliance checking of a website against their “e-commerce” policy 2) As part of the Access Control Decision Assessment within PRIME (UniMi): The Compliance checking policy can be injected into the existing Access Control Policies as predicates. e.g. IF (Access Control checks) AND IF ( Assurance Control checks)

40. Our Approach in PRIME • Trust and assurance constraints can be represented as 1st order predicate logic expressions • e.g. hasValidPrivacySeal(Issuer) & isTrusted(Issuer) • These would be conjoined to other conditions within ‘conditions element’ of data handling policies, transfer policies, etc. • Different levels of representation: • Top level e.g. checkTrustedProcessingSystem, with reference to semantics • Lower level e.g. forall x є ProcessingSystem (hasWorkingTPM(x) v …) & usesAdequateEncryption(x) & isPatched(x) & hasWorkingOMS(x), with reference to lower level semantics • Result: analogous structure to policy input (of resulting values of assurance clauses) • complexity can be shown to the user if desired • can simplify to Boolean value, e.g. for Access Control Decision point

41. Comparison with P3P (W3C) Similarities -Definition of User’s Privacy Expectations - Explicit Declaration of Enterprise Promises - Alerts when these two don't match Differences: - P3P does not define mechanisms for enforcement of enterprise promises • We go beyond labels to show which control has to be done and how to • break these down • Greater expressiveness (checks include infrastructure, IT controls, • trustworthiness…) - Provision of different degrees of ‘evidence’ • More than one policy per resource on Enterprise side and multiple personae • for the user, both via assurance policy templates

42. Open Issues and Next Steps Current Approach Pros • Flexible Language and Approach • Extensible and Customisable Cons • Trust is not a black and white issue, and the user must have overall control over how to proceed • Subjectivity and potential changeability of the decisions and representations involved • How much does this extension of the conditions element extend the expressivity of the PRIME policy languages, and are there related formal issues? • Very likely approach not yet mature enough to be a candidate for standardisation

43. Presentation Outline Setting the Context Privacy Obligation Policies[Marco Casassa Mont] Compliance Checking Policies [Siani Pearson] Trust Constraints/Policies [Stephen Crane] Conclusions

44. Trust Policies • Trust Policies typically Originate from the Individual and place Specific Requirements on the Receiving Organisation • They state in Formal Terms what Must be Done or what Must be Present before the Data Recipient will be Considered Trustworthy and a Transfer of Personal Information will be initiated • They can Impose Conditions that must be Applied to the Information after Transfer, such that the Status of the Information can be Monitored on an on-going basis (Reputation Feedback)

45. Trust Policies: Expressed Requirements • Trust Policies enable the Expression of the following basic Requirements: • Required system physical attributes, e.g. TPM: present/enabled • Required system logical attributes (system components), e.g. Obligation Manager running • Required actions to achieve compliance, e.g. fulfil specific obligations • Required action in the event of non-compliance.

46. Trust Policies: Expressed Requirements • Required off-line (or out-of-band) actions that must be performed, e.g. gathering intermediate processing results and their transfer to a third party Reputation Manager • Context Indicator, e.g. conditions that affect how the polices are interpreted • Session management requirements, e.g. details of low level integrity controls and acknowledgement reporting

47. Language: Expression • Trust Policies use a Formal Language to Express Requirements • Expressions are in general of the form: SHARING for <PURPOSE> is CONDITIONAL on <REQUIREMENT> • where <REQUIREMENT> include one or more system attributes, or one or more instructional requirements • and <PURPOSE> describes use of information • When a requirement consists of more that one REQURIEMENT, the overall requirement should be based on the logical combination derived using Connectives from Formal Logic, i.e. AND, OR, NOT, IF THEN, etc.

48. Building Trust Two Basic Approaches to Determining Trustworthiness: • Trust Assessment (passive mode) • User assesses one or more metrics describing the status of system with which data is to be shared • Trust Establishment (active mode) • Users sets one or more conditions that must be agreed to by the receiving party • Optionally user records/monitors status of agreed conditions, possibly as part of a multi-party reputation-feedback system.

49. Trustworthy Assessment REQUEST to REVEAL “TRUST” STATUS “TRUST” STATUS Assessment

50. Trust Establishment SHARE for NOT_MARKETING is CONDITIONAL on {TRUSTED_PLATFORM=TRUE} TRUST CONDITION ACCEPTED TRUST CONDITION acceptance logged Information Shared