dynamic context aware access control for protecting medical records n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dynamic Context-Aware Access Control for Protecting Medical Records PowerPoint Presentation
Download Presentation
Dynamic Context-Aware Access Control for Protecting Medical Records

Loading in 2 Seconds...

play fullscreen
1 / 29

Dynamic Context-Aware Access Control for Protecting Medical Records - PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on

Dynamic Context-Aware Access Control for Protecting Medical Records. Master's Project Presentation. Junzhe Hu July 26, 2004. Outline. Introduction to our medical data security project Prior work in access control Dynamic context-aware access control CAAC schema Policy specification

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dynamic Context-Aware Access Control for Protecting Medical Records' - wyatt-macias


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
dynamic context aware access control for protecting medical records

Dynamic Context-Aware Access Control for Protecting Medical Records

Master's Project Presentation

Junzhe Hu

July 26, 2004

outline
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
authentication issues
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.
authorization issues
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
authorization issues1
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
previous work
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

previous work1
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
context based access control cbac

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

context based access control
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
caac schema
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

caac schema1
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

caac schema2
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
caac schema3
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
caac schema4
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

caac schema5
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

policy specification
Policy Specification
  • Security polices must be exchangeable between different applications.

Hospital

Pharmacy

Send prescription

Policy response

License requested

Prescription accepted

policy specification1
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.

policy specification2
Policy Specification
  • Our customized WS-Policy tags

For any authorization policy AP = (S, P, C)

a sample policy
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>

dynamic policy enforcement
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

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

dynamic policy enforcement3

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

demonstration
Demonstration
  • Demo to illustrate
    • context-aware access control
    • dynamic rule enforcement
    • extensibility of our schema
conclusions
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.
future work
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
publications
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.
acknowledgements
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