1 ihe iti white paper on access control wp review cycle 1 chapter 1-2: introduction and state of the...
TRANSCRIPT
1
IHE ITI White Paper on Access Control
WP Review Cycle 1
Chapter 1-2: Introduction and State of the Art
Dr. Jörg Caumanns, Raik Kuhlisch, Olaf RodeBerlin, 13.02.09
2
Editing Team
Authors: Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISSTOliver Pfaff, Markus Franke // Siemens IT Solutions
// and Services Christof Strack, Heiko Lemke // SUN Microsystems
Supervisior: Rob Horn // Agfa Healthcare
Editorial Team: John Moehrke // GE HealthcareLynn Felhofer
Manuel Metz // GIP-DMP
3
Objective of this TeCon
- step through chapter 1-2 and consolidate core statements
- fine grained scoping of the WP boundaries (ins and outs)
- agree on the outline of chapter 3
4
Comment on the Scope and Direction of the WP
• Is this solely to provide direction to architects and implementers or will this provide direction for new profiles?
• Where’s the interoperability implication?• AC cannot be encapsulated with a single actor • consumers and providers of protected resources can only be interoperable if
their respective access control subsystems are interoperable, too
5
Chapter 1: Organization
1. Access Control in Healthcare• [Intro] [0.7 pages]• Access Control Scenarios [1.0 pages]• Objective and Outline [1.0 pages]
-------------2.7 pages
• Is the organization of chapter 1 appropriate?
6
Chapter 1: Intro
• Should a sentence on proactive measures (authorization) vs. reactive measures (audit trail) be added
• should this be discussed with more detail in another chapter?
• Scope: “This white paper points out how access control services should be integrated into healthcare IT infrastructures and how IHE can be used to support such policy-aware healthcare solutions.”
• does everybody agree on this?
• Patient Safety: “A dedicated focus will be on opportunities for preserving patient safety by keeping data accessible even in cases where the security subsystem is partly or totally unavailable.”
• sufficient?
7
Chapter 1.1: Access Control Scenarios
Motivation: Give an impression on how AC is (should be) used in healthcare
Is any important scenario missing?• Research?• Public Health?• Reimbursement?• Managed Care (health insurance)?• Quality Reports?
8
Chapter 1.2: Assumptions
• It is assumed that the design of the overall healthcare data exchange infrastructure is oriented towards the principles of a service-oriented architecture (SOA). It is further more assumed that a dedicated security architecture is set up which provides a circle-of-trust among the security and business services which are deployed among independent affinity domains.
9
Chapter 1.2: Focus
• The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a distributed access control scenario. Therefore this paper will deal with the problems of
• how to apply established principles of secure design and SOA security on the design of access control systems,
• how to model an access control solution in a way that is well suited for reasoning and evaluation, and
• how to deploy an access control solution using well understood patterns and interoperable system components.
10
Chapter 1.2: Intended Audience
...the primarly intended audience are system architects and developers who are involved in the planning, design, and realization of regional healthcare networks and comparable infrastructures where the secure exchange of patient related data among enterprises is an issue
11
Chapter 2: State of the Art
• 2.1 State of the Art [4.0 pages]• [Intro] [0.2 pages]• Principles of Secure Design [1.6 pages]• Common AC Models [1.2 pages]• Policy Based AC [1.0 pages]
• 2.2 SOA Security Principles [1.5 pages]
• 2.3 Access Control System [4.7 pages]• [Intro] [0.7 pages]• Building Blocks [1.0 pages]• Access Control Domains [1.3 pages]• Federated Healthcare Environm. [0.7 pages]• IHE Profiles [1.0 pages]
12
2.1.1 Principles of Secure Design
• Principles considered:• Economy of Mechanism Complete Mediation• Open Design Least-Common Mechanism• Fail-Safe Defaults Separation of Privilege• Least Privileges Psychological Acceptability• Reluctance to Trust Privacy Consideration• Isolation
• Is this selection OK?
• Consideration: Add an appendix on how these principles can be realized using the concepts/patterns/guidelines provides in the white paper
13
Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context?
ResourceBehaviour Policy:
How may authorizedsubjects work with my
EHR?
EHR Definition
Privacy Consent National Law
Agr
eem
ent
Con
figur
atio
n
Authorization Scope, Procedure, ...
Regulations
Access Control Paradigm: Input for the Discussion ...
14
2.1.2 Common AC Models
Considered Models• Discretionary Access Control• Mandatory Access Control (Bell-LaPadula)• Role-Based Access Control
Other Models? • Attribute-Based Access Control [doesn’t that not even fit better than RBAC?]• Clark-Wilson (transaction based, objective: integrity)• Take-Grant (graph model for permission distribution)
Bell-LaPadula (No Read-Up/No Write-Down) vs. Biba (No Read-Down/No Write-Up)?• Bell-LaPadula has a focus on confidentiality (e. g. processing of patient data) within
information flows while Biba focuses on integrity (e. g. config of devices by admins and users).
from my point of view, MAC does not fit well for complex healthcare scenarios, even though it allows for good and easy solutions on rudimentary intra-enterprise AC
15
2.1.3 Policy Based Access Control
Policy: rules for controlling the behaviour of a system
PEP: interception and decision enforcement (missing: obligation activation)
PDP: policy decision, [policy retrieval, attribute retrieval (conceptual model)]
PIP: attribute value source• wording?• part of the diagram?
PAP: policy authority, policy activation• wording?• part of the diagram?
16
2.2 SOA Security Principles
Comment: Include a short description of SAML, XACML, WS Trust
Security Token, STS are used to denote concepts/patterns, not WS Trust components• change wording?
17
2.3 Access Control System
An Access Control System (ACS) is a (logical) capsule around all authorization subsystem components that are (logically) linked with a node.
ACS = Access Control System / Service / Subsystem?
18
2.3 Access Control System
A common ACS is able to integrate components for the• Management of policies and attributes• Policy decision and policy enforcement• Security token issuing and verification (for ACS federation)
Other functionalities that should be mentioned?
19
2.3.1 Access Control System: Building Blocks
20
2.3.1 Access Control System: Building Blocks
These building blocks – which will be discussed in depth throughout the rest of this white paper - are:
• policy authority services for the management, selection, and activation of policies.
• attribute services for managing attributes an subjects, resources, etc. which have to be considered for the evaluation of policy rules
• security token services for the establishment of trust relationships to remote ACS and for the secure (with respect to integrity and authenticity) exchange of attributes and policies across domains.
• Policy enforcement and decision points which apply policies on business service requests. It is assumed that (at least on a model level) each request is mediated through the PEPs of the communicating nodes.
21
2.3.2 Access Control System: Domains (Wording?)
22
2.3.3 Federated Healthcare Environments (Wording?)
Given a circle of trust, two major federation scenarios have to be considered:• federation of resource domains: A context domain is able to request
protected resources from multiple resource domains. Therefore the ACS at the context domain has to be able to share application semantics and policies with ACSs within multiple resource domains. This includes the ability of all attribute managing domains to provide attribute values in a way that can be understood by the domain that decides on the policy.
• federation of subject domains: A resource domain accepts requests from subjects that reside in different subject domains. By federating identities, subject domains are able to discover, exchange, and synchronize attributes that relate to the same subject.
Other scenarios?
semantic interoperability as an issue?
23
2.3.4 IHE Profiles
24
XUA, EUA, PWP
The Cross-Enterprise User Assertion (XUA) integration profile provides mechanisms to exchange authenticated subject information across domain boundaries. It is therefore well suited for connecting the subject domain to the circle of trust.
By combining XUA and Kerberos-based Enterprise User Authentication (EUA) an already IHE compliant enterprise can run its own identity provider using existing technology.
The Personnel White Pages (PWP) integration profile defines how organizations might maintain attributes describing their personnel based on common LDAP technology.
By either integrating this information into XUA or by providing it to external users through security tokens (e. g. using an STS-safeguarded policy information point) the subject domain’s required functionality can be provided by already existing IHE profiles.
25
BPPC, XDS
The Basic Patient Privacy Consent (BPPC) integration profile describes how XDS registries and repositories can be used for maintaining privacy policies.
This allows for setting up a policy authority within the resource domain. By encapsulating this functionality by a security token service, privacy policies can even be exchanged in a secure manner across domain boundaries.
XDS registries are designated for the management and provisioning of resource attributes and as such provide the functionality of an attribute service.
26
Conclusion
Using existing profiles for the management of policies and resource attributes at the resource domain and for the trusted exchange of subject attributes among domains, even rather complex access control scenarios can be implemented.
Grouping table, etc?
The major white spots not recently covered by IHE integration profiles are PEP/PDP and policy authorities which are decoupled from the resource managing systems. [Agreement? Other white spots?]
Possible strategies for evolving in this direction are discussed in section 4.x of this white paper. [Agreement?]
27
Chapter 3: Policies and Attributes (1/2)
Session Control vs. Resource Control • Granularities and flavours of protected resources • The role of the “Purpose”
Resource Security through Role Based Access Control • Needs-to-know principle• role engineering and access control matrices • Role activation
The Role of the Patient • Patient Privacy Policies (Consents) • Prefetching of patient data • patient-bound tokens (e. g. EHCs) as access control measures
28
Chapter 3: Policies and Attributes (2/2)
Instantiation of access rights for organizations (section title must be changed!!)• Integration of AC Paradigms • Policy conflicts• client-side vs. resource-side enforcement
Conclusion: Policies and Attributes Needed • patient privacy policy, application policy, resource (data
protection) policy • subject attributes, resource attributes, activity attributes,
context/purpose attributes, patient attributes • policy templates • Binding of policies and attributes (and attribute sources)
29
Applications as Legal Frameworks
XDS: Shared Medical Data
Privacy Policy
Security Policy
Purpose of Use
EHR, PHR, eCR, ...
App. Policy
activates
30
Needs-to-Know Principle (e. g. Treatment Contract)
Organizational Structure(Who? Why? What?)
Medical Treatm
ent
Data Processing
Acce
ss De
man
ds
(Autho
rization
)
Role
Context/Purpose
Permissions
The objective of access control is to provide all physicians the information theyneed to know in order to treat the patient the best way
- while respecting the patient’s right towards self-determination- while protecting the confidentiality and integrity of medical data
31
Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context?
ResourceBehaviour Policy:
How may authorizedsubjects work with my
EHR?
EHR Definition
Privacy Consent National Law
Agr
eem
ent
Con
figur
atio
n
Authorization Scope, Procedure, ...
Regulations
Access Policies vs. Behaviour Policies (THIS ONE...)
32
Combination of DAC and RBAC [... OR THIS ONE?]
RBAC
clinic
RBAC
GP
DAC
sync
patient decides which organizations take part in a co-operative medical treatment for a certain disease. Only staff members of these organizations may access his shared data.
organization of labor at clinic and practice determines which roles may access which portions of the patient’s shared data
33policy
subject-ID
role-ID (adm)
policy activation
context-ID
purpose-ID
role-ID (func)
patient-ID
resource-ID
activity-ID
policy consumer
representspolicy-ID *
attribute value *
policy decision
resource provider
attribute value *
policy-ID *
evaluates
acceptor deny
...
res.type-ID
Attributes and Policies
34
Policy Template
CIS
Clinic B
CIS
Clinic A
Consent
exchange
I hereby authorise Clinic A to share all my diabetes-related medical data with diabetologists at Clinic B in case that I require a treatment while I am at Clinic B.
I hereby authorise [organizations] to share all my [kind-of] medical data with [roles] at [organizations] in case that I require a [purpose] while I am at [orgs].
instantiate
35
Using Policy Templates for Attribute Binding