1 / 22

A Medical Database Case Study for Reflective Database Access Control

A Medical Database Case Study for Reflective Database Access Control. Lars E. Olson 1 , Carl A. Gunter 1 , and Sarah Peterson Olson 2 1 University of Illinois at Urbana-Champaign 2 University of Nebraska Medical Center. ACM-Based Access Control. ACM-Based Access Control.

heath
Télécharger la présentation

A Medical Database Case Study for Reflective Database Access Control

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. 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)

More Related