A Medical Database Case Study for Reflective Database Access Control

1
A Medical Database Case Study for Reflective
Database Access Control

• Lars E. Olson1, Carl A. Gunter1, and Sarah
  Peterson Olson2
• 1University of Illinois at Urbana-Champaign
• 2University of Nebraska Medical Center

2
ACM-Based Access Control
Patients Patients Patients Patients Patients
Name Home Addr Optin Room Diag
Emily 1 Main St. Y 108 Flu
Fred 2 Center Ave. N 203 Broken leg
George 3 College Dr. Y 207 Lung cancer
Harriet 4 Park Blvd. N 301 Food poisoning
ACM Entries
Alice
Bob
3
ACM-Based Access Control
Patients Patients Patients Patients Patients
Name Home Addr Optin Room Diag
Emily 1 Main St. Y 108 Flu
Fred 2 Center Ave. N 203 Broken leg
George 3 College Dr. Y 207 Lung cancer
Harriet 4 Park Blvd. N 301 Food poisoning
4
ACM-Based Access Control
Second_Floor_Patients
ACM Entries
Carol
David
Fred
203
Broken leg
207
George
Lung cancer
5
ACM Weaknesses

• Complicated policies can be awkward to define
• All patients can access their own records
• Every nurse can view the records of patients
  assigned to their floor

6
Motivation

• ACMs describe extent, rather than intent
• Decision support data is often already in the
  database
• Redundancy
• Possibility of update anomalies

7
Reflective Database Access Control

• Solution access policies should contain queries
• Not limited to read-only operations
• Policies not assumed to be omniscient
• Is this a secure solution? (CCS 08)
• Is this a practical solution? (DBSec 09)
• What is it useful for? (SPIMACS 09)

8
TD and RDBAC

• Transaction Datalog an extension to classical
  datalog with update predicates
• Query on a rule may change the database state
• Audit policies
• Chinese Wall policies
• Mathematical model enables formal security
  analysis

9
Case Study Medical Database

• HIPAA legislation
• Protects privacy of patients
• Access to electronic health records must be
  restricted based on the specific roles of the
  members of their workforce.
• Idealism meets reality emergencies are common
• Commonly implemented by Honor System, e.g. sign a
  form yearly

10
Case Study Goals

• Demonstrate usefulness of RDBAC in a real-world
  scenario
• Enforce privacy constraints of HIPAA
• Address practical needs for emergency access
• NOT designed for a particular medical center
• BUT should be realistic

11
General Access Patterns
Database
12
General Access Patterns
Database
13
Example Policies

• Patients may view their own medical data
• Primary care physicians may view their own
  patients data
• Caregivers assigned to consult with a patient may
  view that patients data
• Lab technicians may enter new records for any
  patient, but the ID of the technician is included
  in the record
• Current employees may access any patients
  record, but an audit record is generated

14
Example TD Rules

• view.labResult(User, PtntID, Date, Type, ...) -
• labResult(PtntID, Date, Type, ...),
• person(PtntID, User).
• view.labResult(User, PtntID, Date, Type, ...) -
• labResult(PtntID, Date, Type, ...),
• person(UserID, User),
• hasAccess(UserID, PtntID).
• view.labResultEmerg(User, PtntID, Date, Type,
  ..., Note) -
• labResult(PtntID, Date, Type, ...),
• employee(UserID, User),
• ins.labResultAudit(UserID, PtntID, now, Note).

15
Formal Security Analysis

• No untrusted user can ever gain access to a
  patients lab results.
• Automated analysis difficult (often impossible)
  problem to solve
• Safe rewritability
• Limits domain of values that untrusted users can
  insert
• Previously established theorem to decide analysis
• Must guarantee that untrusted users cannot
  trigger actions that run as a trusted user

16
Results of Formal Analysis

• Uses upper-bound estimate on safely rewritable
  policies
• Rules with retractions, rules not safely
  rewritable omitted
• Sample database populated, verified with Prolog
• Omitted rules analyzed manually
• Analysis scalability
• Running time A increased patients doctors
• Running time B increased patients only

17
Results of Formal Analysis
18
Future Research Possibilities

• Improvements to TD
• Aggregation
• More expressive negations
• Improvements to analysis
• State-independent analysis
• Detecting irrelevant rules
• Development of Case Study
• Discretionary access to patient records
• Trusted users no longer constant
• Specifying exceptions
• Adverse drug interactions (requires negation over
  join)

19
Conclusions

• Reflective Database Access Control is a more
  flexible model than ACM-Based Access Control.
• RDBAC provides benefits for real-world scenarios.
• More expressive policies
• Formal security analysis

20
For More Information

• http//seclab.illinois.edu/
• Internet search on Illinois Security Lab or
  Reflective Database Access Control

21
Policies Defined with TD

• Policies may be written by lower-privileged users
• Problem read information from higher-privilege
  table, write to lower-privilege
• Solution
• TD rules include explicit parameter for the
  permission
• Policy subqueries are executed with definers
  privilege
• Policy body cannot do anything the definer cant
  already do manually.

22
Analysis of Omitted Rules

• Infinite domain of values to insert
• Note value from break-the-glass rules
• Prolog can sometimes handle infinite domains
• Otherwise, these values do not affect access
  privileges
• Deletions still constitute subset of maximal
  database
• Executable only by trusted users
• Only active employees may execute rules
• Only trusted users may add active employees
• Any rules that invoke omitted rules are also
  executable only by trusted users (transitive
  closure)