IHE ITI White Paper on Access Control

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 ISST Oliver Pfaff, Markus Franke // Siemens IT Solutions // and Services Christof Strack, Heiko Lemke // SUN Microsystems • Supervisior: Rob Horn // Agfa Healthcare • Editorial Team: John Moehrke // GE Healthcare Lynn 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-trustamong 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. Access Control Paradigm: Input for the Discussion ... Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context? Privacy Consent National Law Authorization Scope, Procedure, ... Agreement Configuration Regulations EHR Definition ResourceBehaviour Policy:How may authorizedsubjects work with myEHR?

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 Purpose of Use Privacy Policy EHR, PHR, eCR, ... activates App. Policy Security Policy XDS: Shared Medical Data

30. Needs-to-Know Principle (e. g. Treatment Contract) 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. Access Policies vs. Behaviour Policies (THIS ONE...) Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context? Privacy Consent National Law Authorization Scope, Procedure, ... Agreement Configuration Regulations EHR Definition ResourceBehaviour Policy:How may authorizedsubjects work with myEHR?

32. GP RBAC Combination of DAC and RBAC [... OR THIS ONE?] 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. DAC clinic RBAC sync organization of labor at clinic and practice determines which roles may access which portions of the patient’s shared data

33. resource-ID policy consumer res.type-ID resource provider policy activation policy decision patient-ID context-ID policy-ID * subject-ID attribute value * attribute value * role-ID (func) acceptor deny role-ID (adm) purpose-ID activity-ID ... evaluates represents policy-ID * policy Attributes and Policies

34. Clinic A CIS Policy Template 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 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. Consent Clinic B CIS exchange

35. Using Policy Templates for Attribute Binding