Dynamic Context-Aware Access Control for Protecting Medical Records

1. Dynamic Context-Aware Access Control for Protecting Medical Records Master's Project Presentation Junzhe Hu July 26, 2004

2. Outline • 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 Architecture

4. Authentication 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 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 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. Previous Work • 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 User Role Permission Main idea of RBAC

8. Previous 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. CPU speed Bandwidth Name Age User ID Role Time Location IP Address 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.”

10. Context-Based Access Control Associate contextual parameters with every component in traditional RBAC • Advantage: access control is context-aware • Disadvantage: this is still a static model

11. CAAC Schema • Context-aware access control schema • Basic 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. CAAC Schema • 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. CAAC Schema • Definition 2: Context Constraint We 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. CAAC Schema • 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. CAAC Schema • 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. CAAC Schema Visualization of a CAAC authorization policy has given C: constraint P: permission S: user or role Clause n Clause 1  ……   ……  condition condition context type A predicate of context implementation Evaluated by

17. Policy Specification • Security polices must be exchangeable between different applications. Hospital Pharmacy Send prescription Policy response License requested Prescription accepted

18. Policy Specification • There are several XML-based policy languages • WS-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. Policy Specification • Our customized WS-Policy tags For any authorization policy AP = (S, P, C)

20. A 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 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. Dynamic Policy Enforcement • Implement context as web service • Context implementation is separated from application • Easy to deploy • Protected by WS-Policy

23. Dynamic Policy Enforcement • 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. Time Location UserID ObjType ObjID Trust Level CTi …… IsAuthorized CTj CTk …… CTn Dynamic Policy Enforcement Based on the context implementation hierarchy, any context type CTn can be dynamically evaluated along some evaluating path

25. Demonstration • Demo to illustrate • context-aware access control • dynamic rule enforcement • extensibility of our schema

26. Conclusions • 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 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. Publications • 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. Acknowledgements • 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