1 dynamic context-aware access control for protecting medical records junzhe hu july 26, 2004...
TRANSCRIPT
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
CAAC SchemaCAAC 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 SchemaCAAC Schema
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
CAAC SchemaCAAC 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 SchemaCAAC 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 SchemaCAAC Schema
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
Policy SpecificationPolicy Specification
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
Policy SpecificationPolicy Specification
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
Dynamic Policy EnforcementDynamic Policy Enforcement
Implement context as web service Context implementation is separated from application Easy to deploy Protected by WS-Policy
23
Dynamic Policy EnforcementDynamic 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
Dynamic Policy EnforcementDynamic Policy Enforcement
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