1. 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 Rode Berlin, 13.02.09

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12 2.1.1 Principles of Secure Design Principles considered: Economy of Mechanism Complete Mediation Open DesignLeast-Common Mechanism Fail-Safe DefaultsSeparation of Privilege Least PrivilegesPsychological 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. 13 Resource Access Policy: Who is allowed to access my EHR for the given purpose/context? Resource Behaviour Policy: How may authorized subjects work with my EHR? EHR Definition Privacy Consent National Law Agreement Configuration AuthorizationScope, Procedure,... Regulations Access Control Paradigm: Input for the Discussion...

14. 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. 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. 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. 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. 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. 19 2.3.1 Access Control System: Building Blocks

20. 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. 21 2.3.2 Access Control System: Domains (Wording?)

22. 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. 23 2.3.4 IHE Profiles

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

30. 30 Needs-to-Know Principle (e. g. Treatment Contract) The objective of access control is to provide all physicians the information they need 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. 31 Resource Access Policy: Who is allowed to access my EHR for the given purpose/context? Resource Behaviour Policy: How may authorized subjects work with my EHR? EHR Definition Privacy Consent National Law Agreement Configuration AuthorizationScope, Procedure,... Regulations Access Policies vs. Behaviour Policies (THIS ONE...)

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

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

34. 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. 35 Using Policy Templates for Attribute Binding