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

2. 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 ). 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 ). 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 ).
Access Control Information (ACI) Information used for access control purposes, including contextual information (ISO ).
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.

3. 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 )
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

4. Access Control Management Services
11/28/2018

5. Prototypical Security Architecture
Management
Services

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

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

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

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

10. 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 for a complete list of access control information types

11. 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
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!

12. Healthcare Scenario Roadmap Maps Work Tasks

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

14. Access Control Policy Components
11/28/2018

15. Access Control Policy Example

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

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

18. 11/28/2018

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