PART 5 Enterprise Privacy Policies

PART 5Enterprise Privacy Policies

Motivation Your personal data will be handled with care ???

Consumers are concerned about privacy • $15B in e-commerce lost in 2001(27% of projected revenues for 2001) • 50%+ extremely/very concerned about online privacy, 30% somewhat concerned • 37% current online consumers would buy more if not worried about privacy • 34% internet users who don't buy online would start if privacy concerns addressed • Only 6% think benefits of giving up personal information outweigh privacy concerns Source of survey data: Forrester 10/2001 ... and are taking action • 78% say have refused to give information to a business because too personal or not really needed (42% in 1990) • 80% rate privacy protection of consumer information as important in their selection of companies to patronize • Almost 50% believe they have personally been the victim of a consumer privacy invasion Source of survey data: PCG and Louis Harris poll

What happens to the data once disclosed? • How to enable businesses to work with pseudonyms? • How to authenticate and authorize, relative to a pseudonym? Focus on Enterprise Privacy Technologies Privacy-enhancing Infrastructure Privacy-enhancing Infrastructure Client Organization • Client-side PETs to • minimize data disclosed • filter data received • keep track of data • control multiple identities • ... • Infrastructure PETs to • hide relations • unlinkable credentials • Mixes • ...

Life-Cycle of Personal Data 2. Personalized use Law, regulations, privacy agreements, preferences, consent 4. Anonymized use Rules request ... authorization, obligation 1a. Collection form = data + rules delete Rules release Data Subject anonymize notify utilize 1b. Control 3. Depersonalized use disclose give consent update access withdraw consent Subject or Guardian or Authority repersonalize depersonalize Data User

Motivation • Enterprise privacy policies and their enforcement are a fundamental issue in practice: • Reflect different legal regulations • Used to capture promises made to customers • More restrictive internal practices • Incorporating customer preferences • Privacy policies may be authored, maintained, and audited in a distributed fashion • Important task is to provide tools for such management of enterprise privacy policies

Motivation • Policy refinement • Roughly, one policy refines another if using the first policy automatically also fulfills the second one. • Refinement as the central notion for many situations in policy management, e.g., checking whether an enterprise policy adheres to legal regulations • Policy composition • Notion of constructively combining two policies • Several notions exist for different purposes: • Mandatory sub-policies

Outline • The Platform for Enterprise Privacy Policies (E-P3P) • A Toolkit for Managing E-P3P Enterprise Privacy Policies • Summary

E-P3P/EPAL • Vocabulary defines scope: • Data, users, and purposes as hierarchies • Operations, obligations as lists • Rules authorize access: A[user]should be [allowed or denied] the ability to perform [action] on[data]for[purpose]under [condition]yielding an [obligation]. Example: "Email can be used for the book-of-the-month club if consent has been given and age is more than 13": • default ruling:allow, deny, don’t care

EPAL policy - a list of rules, sorted by priority • Elements of a rule • user u1, u2, … e.g., “borderless-books” • action a1, a2, … e.g., “read” • for purpose p1, p2, … e.g., “book-of-the-month-club” • on data d1, d2, … e.g., “email” • under condition c1, c2, … e.g., “age >= 18“ • yielding decision r1, r2, … e.g., “allow” • and an obligation o1, o2, … e.g., “write audit”

Semantics of EPAL: Authorization • Policy maps any well-defined authorization request(user, action, purpose, data, variable assignment)to decision  {allow, deny, don’t care} + obligations • Completion of rule set through inheritance • allow inherits down along hierarchies, deny inherits up and down • Check rules in given order for applicability • rule covers request directly / by inheritance • condition/s are satisfied(More sophisticated issue: Incomplete variable assignments: • If a deny-rule could still apply, then we let it apply • If an allow-rule may not apply, then we let it not apply ) • Decision • First applicable deny/allow-rule decides + take rule’s obligation/s • If there is none then take default ruling

 < Summary of Tools in the Toolbox P1 < P2 P1  P2 • Policy refinement for comparing policies • A policy refines another if using the first policy automatically also satisfies the second one. • Central notion in policy management: compliance with legal regulations • The main tool is policy composition • Notion of constructively combining two policies • For different purposes, several notions existAND, OR, Ordered Composition • Operators collected in an algebraic structure together with results about the relationship between composition and refinement • Mandatory sub-policies P1 & P2 P1 + P2 P1 P2 M1 D1

 (u, a, d, p, ass) P1 P2 < (r1, o1) (r2, o2) Policy Refinement Refinement intuitively means to add details to an existing policy while preserving the original privacy statements: • Ruling: Whenever the original policy allows (denies) a request, the refined policy also allows (denies) the request. • Obligation: Fulfillment of the refined obligations implies fulfillment of the original obligations for every request. r1 refines r2 and o1 refines o2

Policy Refinement • What does it mean that r1 refines r2(r1 < r2)? • If r2  {deny, allow} then r1 = r2(weak form also: r2 = allow and r1 = deny) • If r2 = out-of-scope then r1 can be arbitrary • If r2 = don’t care then r1  {deny, allow, don’t care} • Meaning of “o1 refines o2” slightly more complicated • Simply using o1 => o2 not suited, e.g., P1: o1 = “delete now”, o= “delete in a day” with o1 => oP2: o= “delete in a day”, o2 = “delete in a week” with o => o2Now “o1 refines o2” if thereexists o O1  O2 such that o1 => o=> o2 P2 P1 o2 o o1

Algebra for Policy Composition and Refinement • Policy Composition: Notion of constructively combining two policies • Collection of composition operators that are shown to work together in intuitively meaningful ways • Ordered Composition: Master / Slave composition: • Logical composition: Build the conjunction or the disjunction of two policies • Scoping Operation: Restrict a policy to sub-scope • Show suitable relations among these operators, e.g., distributivity, associativity, refinement relations etc.

 < Ordered Composition • Master / Slave Composition • Achievable by precedence shift + some tedious details (dealing with out-of-scope errors, default rulings, etc.) • Advantage: Ordered composition always refines Master! P2 P2 HighPrecedence P1 P1

Logical Composition (AND) • AND-Composition: Design a new policy that behaves as the conjunction • P3 defined semantically as follows from the following equivalence class:If P1 (r1,o1) and P2 (r2,o2) then P3 (r1,o1) AND (r2,o2) = (r1 AND r2, o1 o2) • Very useful in practice (take all applicable legal regulations and combine them into one policy possible with customer preferences, existing sticky policies etc.) • Main Question: Does such a policy P3 always exist? P1 P2 P3 & No!

Excurse: Expressiveness of E-P3P • Let P be a policy, q a request, and  an assignment on the variables in P. Then we have • eval(P,q,) = (+,o)  q* < q: eval(P,q*,) = (+,o*) • eval(P,q,) = (-,o)  q* > q: eval(P,q*,) = (-,o*) • eval(P,q,) = (-,o)  (1 out of the following three cond. holds) • q is a leaf. • q* < q: eval(P,q*,) = (+,o*) •  q* < q: eval(P,q*,) = (-,o*) with o = o* • eval(P,q,) = (don’t care,o)  o = 

Well-founded E-P3P Policies • AND/OR-Composition not possible for all E-P3P policies! • Main inherent Problem:Rules of parent element might not be related to rules of the children • Possible solution: Consider only those policies in which rules of parent elements are determined by rules of their children  well-founded policies • For well-founded policies, AND/OR – composition is well-defined

 < Legend: = Ordered composition ”+” = OR “&” = AND “” = equivalence “<“ = refinement Basic Algebraic Results (well-founded EPAL) • Idempotency: P1 & P1 P1P1 + P1 P1 • Commutativity: P1 & P2 P2 & P1P1 + P2 P2 + P1 • Associativity: (P1 & P2) & P3 P1 & (P2 & P3)(P1 + P2) + P3  P1 + (P2 + P3) • Distributivity: P1 + (P2 & P3)  (P1 + P3) & (P1 + P3)P1 & (P2 + P3)  (P1 & P2) + (P1 & P3) • Strong Absorption: P1 + (P1 & P2) < P1but not P1 & (P1 + P2) < P1

   < < < Legend: = Ordered composition ”+” = OR “&” = AND “” = equivalence “<“ = refinement “<“ = weak refinement     < < < < Advanced Algebraic Results (well-founded EPAL) • Multiplicative Refinement (conjunction is stricter than both policies): • P1 & P2< P1 • P1 & P2< P2 • Additive Refinement (each policy is at least as strict as the disjunction): • P1 P1+ P2 • P2 P1+ P2 • Master / Slave Refinement: • P1 P2< P1 • Operator Refinement: • P1 & P2P1 P2 P1 + P2   

Summary • Toolkit for maintaining, authoring, and auditing enterprise privacy languages • Mainly driven by real-life demands on privacy policies, we have introduced the following: • The notion of refinement between privacy policies as the central notion of almost any operation on privacy policies • Different notions of privacy policy composition • Algebraic structure and results on composition and refinement operators • Two-layered policies to specifically deal with enterprise internal policy management • Treatment of incomplete data in privacy policy evaluation • Explicit representation of conditions languages (context information) • All these cases together allow for capturing a variety of real-life use cases, i.e., safely changing companies promises with respect to customer requirements while abiding by the law

PART 5 Enterprise Privacy Policies