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

PatientsName Home

AddrOptin 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 poisonin

g

ACM Entrie

s

Alice

Bob

3

ACM-Based Access Control

PatientsName Home

AddrOptin 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 poisonin

g

4

ACM-Based Access Control

Second_Floor_Patients

Fred 203

207George

Broken leg

Lung cancer

ACM Entrie

s

Carol

David

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)

Database

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

8

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

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 realistic10

General Access Patterns

11

Database

General Access Patterns

12

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

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

14

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

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

16

17

Results of Formal Analysis

1

10

100

1000

10000

100000

10,000 100,000 1,000,000 10,000,000

Number of patients

Exe

cuti

on

Tim

e (s

ec)

Running Time A

Running Time B

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

For More Information…

• http://seclab.illinois.edu/• Internet search on “Illinois Security

Lab” or “Reflective Database Access Control”

20

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.

21

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)