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)
