1 / 26

Privacy APIs: Access Control Techniques to Analyze and Verify Legal Privacy Policies

Privacy APIs: Access Control Techniques to Analyze and Verify Legal Privacy Policies. Michael J. May (UPenn) , Carl A. Gunter (UIUC) , Insup Lee (UPenn) 19 th IEEE Computer Security Foundations Workshop (CSFW 2006). Legislation Þ Privacy Policies. ?. Formal Models. Privacy Laws.

season
Download Presentation

Privacy APIs: Access Control Techniques to Analyze and Verify Legal Privacy Policies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Privacy APIs: Access Control Techniques to Analyze and Verify Legal Privacy Policies Michael J. May (UPenn), Carl A. Gunter (UIUC), Insup Lee (UPenn) 19th IEEE Computer Security Foundations Workshop (CSFW 2006)

  2. Legislation Þ Privacy Policies • ? Formal Models

  3. Privacy Laws • Privacy legislation is global since companies hold/buy/sell/trade personal information everywhere • US • Health Insurance Portability and Accountability Act of 1996 (HIPAA) • Financial Services Modernization Act (Gramm-Leach-Bliley Act)(GLB) • Children’s Online Privacy Protection Act (COPPA) • Privacy Act of 1974 • EU - Privacy Directive 95/46/EC • Australia - Privacy Act 1988 • Problems • Typically informal, length, complexity • Intricately linked rules and references • A formal representation of the permissions, rules, and allowed data flows in legislative text would be helpful • What features are needed for such a representation? • We start from the ground up

  4. Our Approach • Select a complex legislative document: HIPAA • Derive a structured representation, formalize it, and use model checking to evaluate static properties Command set Selection Model Full Text Privacy commands English English Promela Reference checking

  5. Policy languages • Policy languages define a set of constructs that can be combined to write a policy • The matrix + the policy is the state of the system • Policy is often written as a rule set; policy trees or state machines may be used too • Harrison, Ruzzo, and Ullman format to write policy in a rule set • Protection Commands for operating systems • Primitive operations are transactional changes to the state of the access control matrix (ex. Enter right, create object) • Commands are combinations of primitive operations with optional guards • Originator Control (ORCON) [Graubart89] policy for controlling information • Rule: Only the owner of an object can grant permission on it command grant (from, to, object, right) if owner in (from, object) thenenter right in (to, object) • Rule: A permission that is starred is transferable command transfer (from, to, object, right) if right* in (from, object) thenenter right in (to, object)

  6. Privacy Commands Request Files Files User Sensitive files

  7. Privacy Commands Privacy API Access Rules Obligations Conditions Access Request Roles Agents Files User Notification Sensitive files Obligations Logging Authentication

  8. Privacy Systems [GMS04] • Events • Set policy event: psetssonqfor rat t • Creation event:pcreatesxatt • Publish/subscribe event:pgetsxfromqatt • Action event:pdoesaonqatt • Notation: • Objects x, y, zO • Principals p, q, r P • Permissions s  S • Actions a, b, c A • Time t • Each object x has a subject subj(x) that the object is “about” and a creation time ct(x) when it was made • Null object ^O and null principal ^P

  9. What do we need for legal texts? • Tools to add to the system • Logging • Notification • Policy concepts to add • Actor, Originator • Object tags • Environmental evidence • Concretization • Policy language that implements them • Language that reflects the way operations are done • Policy that can inspect and modify the content of objects • Result: Auditable Privacy Systems

  10. Conditions and Obligations • Level 1: Can be evaluated/enforced from the matrix state • Alice may use Bob’s email address to send him messages if he has given consent for online communications • Alice may use her right to email Bob only once • Level 2: Can be evaluated/enforced from matrix state plus parameters passed (e.g. purpose, environment flags) • Alice can’t use Bob’s email address for marketing communications unless he has given consent for it • Alice may use her right to email Bob, but she must make a note of it in the system log • Level 3: Can’t be evaluated/enforced by the system • Alice can use Bob’s email address for communicating with him if he has not responded to phone calls and Alice has reason to believe he has changed his phone number • Alice may use her right to email Bob, but must then mail him a letter with the same content

  11. Environment flags and testimonials • Environment flags help with Level 2 • Let the system communicate information about the environment to the policy • Can be Boolean flags, numbers, etc. • Are easily codified in policy text • Conditions check the flags, obligations modify them • Testimonials are needed for Level 3 • Actors make assertions about things in the environment • Conditions check them via flags, may log them • Obligations communicate back to the user, may notify

  12. Conditions example L2 – data origination tracking and purpose 164.506(a)(3)(i) A covered health care provider may, without prior consent, use or disclose protected health information created or received under paragraph (a)(3)(i)(A)-(C) of this section to carry out treatment, payment, or health care operations: … (C) If a covered health care provider attempts to obtain such consent from the individual but is unable to obtain such consent due to substantial barriers to communicating with the individual, and the covered health care provider determines, in the exercise of professional judgment, that the individual's consent to receive treatment is clearly inferred from the circumstances. [HIPAA, 2003]

  13. Conditions example L3 – Provider has attempted to obtain consent but can’t 164.506(a)(3)(i) A covered health care provider may, without prior consent, use or disclose protected health information created or received under paragraph (a)(3)(i)(A)-(C) of this section to carry out treatment, payment, or health care operations: … (C) If a covered health care provider attempts to obtain such consent from the individual but is unable to obtain such consent due to substantial barriers to communicating with the individual, and the covered health care provider determines, in the exercise of professional judgment, that the individual's consent to receive treatment is clearly inferred from the circumstances. [HIPAA, 2003]

  14. Conditions example L3 - Provider in professional judgment 164.506(a)(3)(i) A covered health care provider may, without prior consent, use or disclose protected health information created or received under paragraph (a)(3)(i)(A)-(C) of this section to carry out treatment, payment, or health care operations: … (C) If a covered health care provider attempts to obtain such consent from the individual but is unable to obtain such consent due to substantial barriers to communicating with the individual, and the covered health care provider determines, in the exercise of professional judgment, that the individual's consent to receive treatment is clearly inferred from the circumstances. [HIPAA, 2003]

  15. Privacy commands • Policy atoms are privacy commands akin to HRU commands • Some commands may have no side effects, just check conditions • We add some primitive operations to the set for matrix operations from HRU • Checking purpose, inspecting environmental evidence flags • References Rule: Copying an object with ORCON rules command CopyObject (a, s, o, o‘) if originator in (a, o) and subject in (s, o) thencreateobject o' andenter originator in (a, o‘) andenter subject in (s, o‘) end Rule: Creating an object with Originator Control (ORCON) rules command CreateObject (a, s, o) createobject o andenter originator in (a,o) andenter subject in (s,o) end

  16. Privacy APIs • A set of commands in our Privacy Commands syntax combines to make a Privacy API (auditable policy interface) • Set must be closed under references (no outside or unresolved references) • Commands can be “private” so users can not access them • Perform low level system functions such as copy, create object, modify object, etc. • Policy evaluation • Single command execution: an actor invokes a command to execute it • Evaluation can be command driven or interactive

  17. Translation steps Command set Selection Model Full Text English English Privacy commands Promela Reference checking

  18. 164.506(c)(1): A covered entity may use or disclose protected health information for its owntreatment, payment, or health care operations. [HIPAA 2003] Example: Own use clause AllowedAsIn506c1 (a, s, r, p, f, evidence) If “own use”' in p and isTPO(p) thenreturn true else return false end Disclose506c1 (a, s, r, p, f, evidence) if AllowedAsIn506c1 (a, s, r, p, f, evidence) and own in (a, f) then CopyObject (a, s, f, f') andinsert own in (r, f') and EnterDisclose (a, p, f) end Use506c1 (a, s, r, p, f, evidence) … isTPO (p) if “treatment'' in p or “payment'' in p or “healthcare operations'' in p … • f is a file of protected health information • Agents a, s, r • a is an officer of a covered entity (hospital, doctor’s office, etc) • r is the intended recipient • s is the subject of the file • p is a set of purpose flags • evidence is a set of environment flags CopyObject (a, s, o, o') …

  19. 164.506(a)(3)(i) A covered health care provider may, without prior consent, use or disclose protected health information created or received under paragraph (a)(3)(i)(A)-(C) of this section to carry out treatment, payment, or health care operations: … (C) If a covered health care provider attempts to obtain such consent from the individual but is unable to obtain such consent due to substantial barriers to communicating with the individual, and the covered health care provider determines, in the exercise of professional judgment, that the individual's consent to receive treatment is clearly inferred from the circumstances. Example: Testimonials AsIn506a3iC (a, s, r, f, evidence) if attempted in (a, f) and consent notin (s, f) and “barriers to communication” in evidence and “professional judgment” in evidence thenreturntrue elsereturnfalse end

  20. Creating the rule sets • Using above techniques we translated one section (164.506) on consent for disclosure • 2000 and 2003 versions of the rules very different • Chasing references lead to including a large section of text • Rules designed to follow the structure of the law closely • Semi-automation of the process in the future • Rule set size • 2000: 60 + 5 helper = 65 rules • 2003: 21 + 33 (by ref) + 5 helper = 59 rules

  21. Translation steps Command set Selection Model Full Text English English Privacy commands Promela Reference checking

  22. Verification using the rule sets • We use SPIN to find the problems previously detected by manual inspection. Comments on the 2000 version consent rules lead to a complete rework in the 2003 version • Ex: Ambulance workers must obtain consent for services they did for unconscious patients after the fact • Ex: Hospitals which usually do pre-operation preparations before procedures can not do so without the patient coming to sign a special designator • Ex: Doctors who render remote diagnoses can not do so without having a special paper consent form sent or faxed to them first.

  23. Property: Can a doctor see a patient record for treatment, payment, or health care operations without consent in a non-emergency situation? Invariant: No health care provider can access a patient record in a non-emergency situation without first gaining consent or obtaining it afterward File f about Paula (patient). Dan (doctor) can not gain any access permissions on f without getting consent from Paula first (or after the fact in case of inability to gain consent at first). /* initialize the matrix */ /* Dan is a doctor */ m.mat[Dan].obj[health_care_provider_group].member=1; /* Paula is a patient and the subject of file1*/ m.mat[Paula].obj[file1].subject = 1; /* Dan has the file in his system - he owns it */ m.mat[Dan].obj[file1].own = 1; p.treatment=1; p.payment=1; p.healthcare_operations=1; /* set evidences */ evidence.emergency = 0; … /* check if Dan can get access to the file*/ invariant = (m.mat[Dan].obj[file1].treat == 0) && (m.mat[Dan].obj[file1].pay == 0) && (m.mat[Dan].obj[file1].healthops == 0) && (m.mat[Dan].obj[f_new].treat == 0) && (m.mat[Dan].obj[f_new].pay == 0) && (m.mat[Dan].obj[f_new].healthops == 0); Example property check

  24. Related Work • Access control • HRU’s checking of safety properties • Fisler, et al’s Margrave for XACML • Digital Rights Management • ODRL • XrML [ContentGuard] • Formal properties [Guth, et al][Weissman, et al] • Privacy policies • EPAL [IBM], P3P [W3C] • Formal properties [Yu, et al][Hayati and Abadi 04] [Karjoth, Schunter, Backes, Powers, et al @ IBM 02-04] • Contextual Integrity [Barth, et al 06]

  25. Conclusion • Using access control techniques to understand legal privacy regulations • Model of operations on private data and allowed information flows • Translating one to the other reveals similarities between them • Differences require us to rethink some theories of access control to usage control and disclosure control • Success in modeling the sections of the regulation that have to do with uses and disclosures • Some sections are not addressable • Ex: Typographical rules for writing a privacy practices declarations • Research goal is to use formal models to better understand the implementation and evolution of regulations • Of course input from legal experts is necessary

  26. References • Carl A. Gunter, Michael J. May, and Stuart Stubblebine. A Formal Privacy System and its Application to Location Based Services.  Privacy Enhancing Technologies 2004. • UPenn IR2FM [http://www.cis.upenn.edu/~rtg/extract-fm/index.php3] • UIUC Formal Privacy [http://seclab.uiuc.edu/formalprivacy/]

More Related