HL7 Security Working Group Plenary Working Group Meeting 9-14 September 2012 Baltimore, Maryland Access Control

Definitions Access Ability and the means necessary to read from, write to, , or communicate data/information, or to make use of any system resource. Access Control Prevention of unauthorized use of information assets (ISO 7498-2). It is the policy rules and deployment mechanisms, which control access to information systems, and physical access to premises (OASIS XACML). Access Control Decision Function (ADF) Specialized function that makes access control decisions by applying access control policy rules to an access request, ADI (of initiators, targets, access requests, or that retained from prior decisions), and the context in which the access request is made (ISO 10181-3). See PDP. Access Control Enforcement Function (AEF) Specialized function that is part of the access path between an initiator and a target on each access control request, and enforces the decision made by the ADF (ISO 10181-3). Access Control Information (ACI) Information used for access control purposes, including contextual information (ISO 10181-3). Access Control Service (ACS) Access control service that includes embedded security management capabilities, and all other user-side access control and decision making capabilities (PEP, PDP, PIP, PAP, Obligation service, etc.) needed to enforce use-side, and system-object security and privacy policy. The ACS is responsible for creating trustworthy credentials forwarded in cross-domain assertions regarding security information and attributes. Access control services may be hierarchical and nested, distributed, or local.

Access Control Service Access Control Information (ACI) ACI is information used for access control purposes. ACI may be associated with principals such as initiators or targets, may be associated with actions, and may include contextual information (ISO/IEC 10181-3) User (Initiator) ACI  Individual access control identities Identifier of hierarchical group in which membership is asserted, for example, organizational position Identifier of functional group in which membership is asserted, for example, membership of a project or task group Role that may be taken Sensitivity markings to which access is allowed Integrity markings to which access is allowed A target access control identity and the actions allowed on the target-that is a capability Security attributes of delegates Location, for example, sign-on workstation Resource (Target) ACI  Target access control identities Individual initiator access control identities and the actions on the target allowed or denied them Hierarchical group membership access control identities and the actions on the target allowed or denied them Functional group membership access control identities and the actions on the target allowed or denied them Role access control identities and the actions on the target allowed or denied them Authorities and the actions authorized for them  Sensitivity markings Integrity markings Action ACI  ACI associated with operating zoning action (data ACI), for example: -Sensitivity markings -Integrity markings -Originator identity -Owner identity  ACI associated with the action as a whole, for example: -initiator ACI -Permitted initiator and target pairs -Permitted targets -Permitted initiators (users) -Allowed class of operations (for example, read, write) -Required integrity level. Environmental (Contextual) ACI  Time periods Route (an access may be granted only if the route being used has specific characteristics) Location (an access may be granted only to initiators at specific in-systems, workstations or terminals, or only to initiators at a specific physical location) System status (an access may be granted only for a particular ACI when the system has a particular status, for example during a disaster recovery)  Strength of authentication (an access may only be granted when authentication mechanisms of at least a given strength are use) 11/28/2018

Access Control Management Services 11/28/2018

Prototypical Security Architecture Management Services

HL7 Access Control Service Conceptional Model 3.2 Information Model Information Models provide the basis for semantic content for Access Control. Previous and concomitant work has been done by other projects and is leveraged herein. 4 Computational Viewpoint A computational viewpoint on an SAEAF/RM‐ODP system and its environment is a specification that enables distribution of the functional behavior of the system into service components which interact at interfaces. In the computational viewpoint, applications and business process realizations consist of configurations of interacting service components reflecting business roles participating in service collaborations. 5 Engineering Viewpoint This section identifies the infrastructure that is required to support functional distribution of an ODP system at the conceptual level. The ODP Functions are specified by the Reference Model and are intended to provide broad categories of functions to be considered.

HL7 Security and Privacy Domain Analysis Model 11/28/2018

Security Labels Based on HL7 Standard Vocabulary 11/28/2018

Key Access Control Information a Resource May Have 11/28/2018

RBAC: Definition and Purpose Role-Based Access Control (RBAC) is a type of policy based access control where entity access is granted based upon membership in a group (role) and where rights and privileges are bestowed upon the role rather than the entity directly Provides a mechanism for scalable management of user permissions in the form of operations on objects. Supports interoperability among healthcare and non-healthcare partners through common definitions. Provides information accessibility on a “need-to-know”, “least privilege”, “separation of duty” basis. See ISO 10181-3 for a complete list of access control information types

Harmonized RBAC Across SDOs Authenticated Object Operation (PA) Permission Assignment (UA) User PERMISSION Users Functional Roles Basic Roles SAML, XACML, WS-Trust Profiles Session = Workflow Adapted from ANSI INCITS RBAC 359-2004 Role-Based Access Control (RBAC) Role Engineering Process Version 1.3 Structural Role Standards Functional Role Standards HL7 RBAC Permission Catalog Now V2 Jan 2010!

Healthcare Scenario Roadmap Maps Work Tasks

Role of HL7 for RBAC Review and adopt standard role engineering process. Standardize healthcare permission set. Identify permission constraints. Derive preliminary role hierarchy. Define guidelines for developing RBAC models, e.g., for assigning role names and for engineering role-role constraints. Coordinate with other SDOs, e.g., W3C, OASIS, ASTM, IHE to provide an implementation path. http://www.hl7.org

Access Control Policy Components 11/28/2018

Access Control Policy Example

HL7 Healthcare Privacy & Security Classification System (HCS) Sept 2012 Ballot Standard, semantically interoperable metadata used to classify healthcare information Enables appropriate access control decisions at each layer of security services Enforces Privacy Policies Governing: End users within the custodian’s enterprise Custodian Disclosure of Segmented Data by redaction, masking, and encryption of content “payload” Access to business (inner) and transport (outer) envelopes to minimize payload disclosure Intermediaries’ receipt, storage, routing, and redisclosure Access, use, and any further redisclosure by end users within the Receiver’s System

Classification Scheme Example (Under Construction) Marking Healthcare Definition Information Attribute Principal Attribute Notes Applies To Classification Information handling marking due to expected harm of unauthorized disclosure   Classification Code Very Restricted Restricted Normal Moderate Low Unrestricted Clearance Only one classification value is permitted on the header of an information resource. It must be high water mark (most restrictive). Cover sheet, page header/footer, individual paragraphs Sensitivity A privacy label for information perceived as undesirable to share. HL7 ActPrivacyPolicy Codes In order to access sensitivity tagged data, the user must possess the “ticket” for the tag. Cover sheet, page header/footer, individuals paragraphs Compartment Information segment accessible only by members of a defined community belonging to the compartment ActSensitivityPrivacyPolicyType Codes Functional or Hierarchical Group, Authority High water mark label that applies to all information segmented by the label. Cover sheet, page header/footer Handling Caveat Information categorized as allowed for use in specific ways or for specific purposes. ActHealthInformationPurposeofUseReason Codes ActObligationSecurityPolicyType ActRefrainPolicyType Distribution Codes (Functional or Hierarchical Group, Authority) Promise (TBD) NA Functional or Hierarchical Group, Authority Applies to all information within scope of the caveat Outer envelope, Cover sheet (applies to all data under the cover sheet) Classifier Competent Authority who tags the information Authority responsible for original classification Entire document Declassification NARA retentions Policies Health care record retention policies (e.g., 85 years) Declassification Date, Classification review date 11/28/2018

11/28/2018

Sending and Receiving “Pushed” Messages 11/28/2018