dynamic context-aware access control for protecting medical records

1

Dynamic Context-Aware Access Dynamic Context-Aware Access Control for Protecting Medical RecordsControl for Protecting Medical Records

Junzhe Hu

July 26, 2004

Master's Project Presentation

2

OutlineOutline

Introduction to our medical data security project Prior work in access control Dynamic context-aware access control

CAAC schema Policy specification Policy enforcement

Demonstration Conclusions and Future Work

3

Our Security ArchitectureOur Security Architecture

4

Authentication IssuesAuthentication Issues

We must provide flexible authentication Many devices and techniques

what you have (e-token, RFID) what you know (password, SecurID) who you are (fingerprint, iris, signature, voice)

How reliable is the authentication? incorporate trust level in the authentication token allow specification of trust level in the authorization rules

Authentication on demand User can choose how to be authenticated More secured authentication is required when needed.

5

Authorization IssuesAuthorization Issues Authorization engine must enforce complex rules.

Examples: Medical student can not see a patient's record unless

authorized by patient's attending physician A technologist can see only the data related to his/her

specialty (e.g., cardiology) Physicians must authenticate at the trust level of a

fingerprint or higher Security changes require administrator status and iris

scan identification Only employees of the medical records group can

delete patient data

6

Authorization IssuesAuthorization Issues Authorization process must be responsive to frequent

changes Existing rules may be periodically adjusted Physicians, patients, employees, etc. are a rapidly changing

group Access rules may be suspended during public health emergencies Access may be sensitive to the location, time, and/or method of

the request

Solution: a dynamic, context-aware, access control infrastructure

7

Sandu et al. formalized Role-Based Access Control in 1996

User U acting in role R is granted permission P Advantage: greatly improved efficiency Disadvantage: cannot specify fine-grained rules

Previous WorkPrevious Work

User Role Permission

Main idea of RBAC

8

Previous WorkPrevious Work

Bertino (2001) introduced Temporal RBAC Covington (2001) added location and system status

constraints Moyer and Abamad (2001) incorporated roles for subjects,

objects, and environments Georgiadis and Mavridis (2001) used team-based access

control Kumar (2002) formally proposed context-based access

control Taylor and Murty (2003) described authentication and

access in distributed systems Bonatti and Samarati (2000) regulated service access and

information disclosure on the web

9

Context-Based Access Control (CBAC)Context-Based Access Control (CBAC)

What is context?Context is “any information that can be used to characterize the situation of any entity. An entity is a person, place or object that is considered to be relevant to the interaction between a user and an application.”

NameAgeUser IDRole

TimeLocationIP Address

CPU speedBandwidth

10

Context-Based Access ControlContext-Based Access Control

Associate contextual parameters with every component in traditional RBAC

Advantage: access control is context-awareDisadvantage: this is still a static model

11

CAAC SchemaCAAC Schema

Context-aware access control schemaBasic terminology

- Data Object: the smallest unit to be accessed in an application

- Data Type: a group of data objects with the same attributes

- Data Set: the set of all data objects

- User Set: the set of potential entities that access the data objects

12


Definition 1: Context Type (CT)A context type is defined as a property related to every participant in an application when it is running.

Context Set: a set of all context types in an application.

CS = {CT1, CT2 … CTn}, 1 i n.

Context Implementation: a function of context types defined by

CI: CT1 CT2 … CTn CT, n 0

13


Definition 2: Context ConstraintWe define a context constraint as a regular expression as follows:

Context Constraint := Clause1 Clause2 … Clausei

Clause := Condition1 Condition2 … Conditioni

Condition := <CT> <OP> <VALUE>

CT is an element of CS OP is a logical operator in set {>, , , , , =} VALUE is a specific value of CT

14


Definition 3: Authorization Policy (AP)An authorization policy as a triple, AP = (S, P, C) where

S: is the subject in this policy, which could be a user or a role

P: is the permission in this policy, which is defined as a pair <M, O>, where M is an operation mode defined in {READ, APPEND, DELETE, UPDATE} and O is a data object or data type

C: is a context constraint in this policy

15


Definition 4: Data Access (DA)We define data access as a triple, DA = (U, P, RC) where U: is a user in the User Set who issues this data access P: is the permission this user wants to acquire RC (runtime context): is a set of values for every

context type in the Context Set

DA (U, P, RC) is granted iff there exists an AP (S, P, C), (1) U S and(2) P = P and (3) C is evaluated as true under RC

16


Visualization of a CAAC authorization policy

givenhasS: user or role

P: permission

C: constraint

Clause 1 Clause n……

condition

condition

……

context type

context

implementation

A predicate of

Evaluated by

17

Policy SpecificationPolicy Specification

Security polices must be exchangeable between different applications.

Prescription accepted

License requested

Policy response

Send prescription

Hospital Pharmacy

18


There are several XML-based policy languagesWS-Policy (from Microsoft)SAML (Security Assertion Markup Language)XACML (eXtensible Access Control Markup Language)

We chose WS-Policy as our specification language because it is inherently supported in the Microsoft .NET framework.

19


Our customized WS-Policy tagsFor any authorization policy AP = (S, P, C)

<wsa:DataType>specifies the data object or data type of permission P

<wsa:AccessType> specifies the operation mode of permission P

<wsa:Permission> specifies the permission P in an AP

<wsse:SubjectToken> specifies the security token issued to S

<wsse:ContextToken> specifies one context condition in C

<wsse:ContextType>specifies which context type is used in one context condition of C

20

A Sample PolicyA Sample Policy<wsp:Policy> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:DataType>PatientRecord</wsa:DataType> <wsa:AccessType>Delete</wsa:AccessType> <wsa:Permission>DeletePatientRecord</wsa:Permission> </wsa:EndpointReference> </wsp:AppliesTo> <wsse:SubjectToken wsp:Usage="Required"> <wsse:TokenType>Medical Records Staff</wsse:TokenType> </wsse:SubjectToken> <wsp:OneOrMore wsp:Usage="Required"> <wsp:All> <wsse:ContextToken wsp:Usage="wsp:GreatThan" wsp:Preference="T(password)">

<wsse:ContextType>Trust Level</wsse:ContextType> </wsse:ContextToken> </wsp:All> </wsp:OneOrMore></wsp:Policy>

21

Dynamic Policy EnforcementDynamic Policy Enforcement

Dynamic context evaluation

initialize candidate policy set PS = { } for every AP in policy set, if (U in DA S in AP) and (P in DA = P in AP) put AP into PS end if end for result = “Reject” for every AP in PS if (EvaluateContexts (C in AP)) result = “Accept”

break else

result = “Reject” end if end for return result

22


Implement context as web service Context implementation is separated from application Easy to deploy Protected by WS-Policy

23


Context implementation hierarchy Primitive context:

A context type CT is a primitive context type if it has no parameters

We define five primitive context types: (1) Time— when this access request was issued(2) Location—where the access request was issued(3) User ID—who sent the request(4) Object Type —what type of data object is being accessed(5) Object ID —which particular data object is being accessed

24


Based on the context implementation hierarchy, any context type CTn

can be dynamically evaluated along some evaluating path

Time Location UserID ObjType ObjID

Trust LevelCTi …… IsAuthorized

CTj ……

CTn

CTk

25

DemonstrationDemonstration

Demo to illustrate– context-aware access control– dynamic rule enforcement– extensibility of our schema

26

ConclusionsConclusions

RBAC and CBAC, even with extensions, cannot meet the access requirements of modern healthcare environments

CAAC is an extension to CBAC that is consistent with implementation via web services

CAAC permits dynamic specification and dynamic enforcement of arbitrary access rules

Context implementation is separated from the main business logic of target applications.

27

Future WorkFuture Work

Check for potential conflict between policies Determine whether an access policy should be exposed Enforce access control across trust domains Comparison of WS-Policy vs. SAML vs. XACML

28

PublicationsPublications

Junzhe Hu and Alfred C. Weaver, A Dynamic, Context-Aware Security Infrastructure for Distributed Healthcare Applications, Pervasive Security, Privacy and Trust (PSPT2004), Boston, MA, August 2004

Junzhe Hu and Alfred C. Weaver, A Security Infrastructure for Distributed Healthcare Applications, submitted to 14th International Workshop on Research Issues on Data Engineering, Boston, MA,

March 28-29, 2004. Alfred C. Weaver, Samuel J. Dwyer III, Andrew M. Snyder, James

Van Dyke, James Hu, Xiaohui Chen, Timothy Mulholland, Andrew Marshall, Federated, Secure Trust Networks for Distributed Healthcare IT Services, IEEE International Conference on Industrial Informatics, Banff, Alberta, Canada, August 2003.

29

AcknowledgementsAcknowledgements

Past and present members of our research group: Xiaohui Chen, James Van Dyke, Andrew Marshall, Xiuduan Fang, Zhengping Wu, Andrew M. Snyder, Timothy Mulholland

David Ladd at Microsoft Research

dynamic context-aware access control for protecting medical records

Documents