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
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 ltCTgt ltOPgt ltVALUEgt
• CT is an element of CS
• OP is a logical operator in set gt, ?, ?, ?, ?,
  
• 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 ltM, Ogt, 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

given
has
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)

ltwsaDataTypegt specifies the data object or data type of permission P
ltwsaAccessTypegt specifies the operation mode of permission P
ltwsaPermissiongt specifies the permission P in an AP
ltwsseSubjectTokengt specifies the security token issued to S
ltwsseContextTokengt specifies one context condition in C
ltwsseContextTypegt specifies which context type is used in one context condition of C
20
A Sample Policy

• ltwspPolicygt
• ltwspAppliesTogt
• ltwsaEndpointReferencegt
• ltwsaDataTypegtPatientRecordlt/wsaDataType
  gt
• ltwsaAccessTypegtDeletelt/wsaAccessTypegt
• ltwsaPermissiongtDeletePatientRecordlt/wsa
  Permissiongt
• lt/wsaEndpointReferencegt
• lt/wspAppliesTogt
• ltwsseSubjectToken wspUsage"Required"gt
• ltwsseTokenTypegtMedical Records
  Stafflt/wsseTokenTypegt
• lt/wsseSubjectTokengt
• ltwspOneOrMore wspUsage"Required"gt
• ltwspAllgt
• ltwsseContextToken wspUsage"wspGreatTh
  an" wspPreference"T(password)"gt
• ltwsseContextTypegtTrust
  Levellt/wsseContextTypegt
• lt/wsseContextTokengt
• lt/wspAllgt
• lt/wspOneOrMoregt
• lt/wspPolicygt

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) Locationwhere the access request was issued
• (3) User IDwho 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 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