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

2. 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. 3 Our Security Architecture

4. 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. 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. 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. 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 Work UserRole Permission Main idea of RBAC

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

10. 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. 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. 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 = {CT 1, CT 2 … CT n }, 1  i  n.  Context Implementation: a function of context types defined by CI: CT 1  CT 2  …  CT n  CT, n  0

13. 13 CAAC Schema Definition 2: Context Constraint We define a context constraint as a regular expression as follows: Context Constraint := Clause 1  Clause 2 …  Clause i Clause := Condition 1  Condition 2 …  Condition i Condition :=  CT is an element of CS  OP is a logical operator in set {>, , , , , =}  VALUE is a specific value of CT

14. 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, 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. 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. 16 CAAC Schema Visualization of a CAAC authorization policy givenhas S: user or role P: permission C: constraint Clause 1 Clause n ……  condition ……  context type context implementation A predicate of Evaluated by

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

18. 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. 19 Policy Specification Our customized WS-Policy tags For any authorization policy AP = (S, P, C) specifies the data object or data type of permission P specifies the operation mode of permission P specifies the permission P in an AP specifies the security token issued to S specifies one context condition in C specifies which context type is used in one context condition of C

20. 20 A Sample Policy PatientRecord Delete DeletePatientRecord Medical Records Staff Trust Level

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

23. 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. 24 Dynamic Policy Enforcement Based on the context implementation hierarchy, any context type CT n can be dynamically evaluated along some evaluating path TimeLocationUserIDObjTypeObjID Trust Level CT i …… IsAuthorized CT j …… CT n CT k

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

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