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)
Legislation  Privacy Policies
?
Formal
Models
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
Our Approach
Select a complex legislative document: HIPAA
Derive a structured representation, formalize it, and use model checking to
evaluate static properties
Full Text
English
Reference checking
Selection
English
Command set
Privacy
commands
Model
Promela
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)
then enter right in (to, object)

Rule: A permission that is starred is transferable
command transfer (from, to, object, right)
if right* in (from, object)
then enter right in (to, object)
Privacy Commands
Request Files
Files
Sensitive files
User
Privacy Commands
Privacy API
Access Rules
Obligations
Access
Conditions
Roles
Agents
Sensitive files
Request
Files
User
Notification
Logging
Authentication
Obligations
Privacy Systems [GMS04]


Events
 Set policy event: p sets s on q for r at t
 Creation event: p creates x at t
 Publish/subscribe event: p gets x from q at t
 Action event: p does a on q at t
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
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
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
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
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]
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]
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]
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: Creating an object with
Originator Control (ORCON) rules
command CreateObject (a, s, o)
create object o
and enter originator in (a,o)
and enter subject in (s,o)
end
Rule: Copying an object with ORCON rules
command CopyObject (a, s, o, o‘)
if originator in (a, o)
and subject in (s, o)
then create object o'
and enter originator in (a, o‘)
and enter subject in (s, o‘)
end
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
Translation steps
Full Text
English
Reference checking
Selection
English
Command set
Privacy
commands
Model
Promela
Example: Own use clause
164.506(c)(1): A
covered entity may
disclose
f is use
a file ofor
protected
health
information
protected health
Agents
a, s, r
information
for its
a is an officer of a covered
own
treatment,
entity (hospital, doctor’s
payment,
or health
office, etc)
r is theoperations.
intended recipient
care
s is the subject
of the file
[HIPAA
2003]
p is a set of purpose flags
evidence is a set of
environment flags
CopyObject (a, s, o, o')
…
AllowedAsIn506c1 (a, s, r, p, f, evidence)
If “own use”' in p
and isTPO(p)
then return 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')
and insert 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
…
Example: Testimonials
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.
AsIn506a3iC (a, s, r, f, evidence)
if attempted in (a, f)
and consent not in (s, f)
and “barriers to communication” in
evidence
and “professional judgment” in evidence
then return true
else return false
end
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
Translation steps
Full Text
English
Reference checking
Selection
English
Command set
Privacy
commands
Model
Promela
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.
Example property check



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);
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]
Conclusion

Using access control techniques to understand legal privacy
regulations




Success in modeling the sections of the regulation that have
to do with uses and disclosures



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
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
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/]
Descargar

Formal Models for Legislative Privacy Policies