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

3. ACM-Based Access Control

4. ACM-Based Access Control Second_Floor_Patients Fred 203 Broken leg George 207 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. Database 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 patient’s 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 patient’s 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 patient’s 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 definer’s privilege • Policy body cannot do anything the definer can’t 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)