Cookbook for Security Considerations

Healthcare today has some of the most diverse needs with regard to sharing of data and the need to securely move patient information among systems. Within Health Level Seven (HL7) there are multiple verticals that consider messaging, structures, data models, coding and the like. Security is the common thread that connects all of them. Increasingly, healthcare organizations and technology vendors are performing assessments (threat risk assessments, privacy impact assessments, business impact assessments, etc.) to ensure installed healthcare technology will have a positive impact on healthcare delivery. These assessments, often called risk assessments, are even mandated for healthcare delivery organizations in some countries. Unfortunately, key decision makers often have difficulty understanding the relevance of the risks identified, and often overlook them when writing standards.

The Goal

This Security Risk Assessment Cookbook is intended to enable HL7 domain committees and working groups to publish standards that have taken privacy and security considerations into account. This guide introduces security risk assessments and a process to facilitate completing a security risk assessment for a specific standard. Using this process will facilitate the identification of gaps in a standard’s baseline security and privacy, allowing the working group to either update the standard on their own or to send a request to the Security Working Group for assistance in filling the gap. This will lead to standards that include privacy and security as part of their base, reducing the need to “bolt” security on later. As a result, the HL7 standards will better support patient safety and improved patient outcomes.

The Process

The formal cookbook is documented and training is available in the Resources section below. This text comes from section 2 of the cookbook document

When considering security and privacy issues associated with a standard, one must:

1. Identify (See section 2.2)
   1. And clearly define the scope of the standard, including the baseline assumptions
   2. New threat scenarios and describe the type of impact that scenario implies
2. Analyze (See section 2.3)
   1. The level of impact and likelihood of occurrence for each threat scenario to determine risk
   2. Prioritize these risks in order to focus on the most important ones
3. Plan (See section 2.4)
   1. Determine mitigation strategies that should be implemented for all medium to high risk threat scenarios
4. Track (See section 2.5)
   1. Assess the effect of the application of the mitigation strategies
   2. Reassess the risks by going through steps 2 and 3 until all medium and high risk threat scenarios have been addressed
5. Document all security considerations (See section 2.6)
   1. State your security assumptions in a way that makes them clear to the reader why they are assumed
   2. State the security controls your standard has put in place and generally what risks they mitigate
   3. State any residual risks that the implementer of your standard will need to address

Resources

• HL7 gForge folder with resources http://gforge.hl7.org/gf/project/security/docman/?subdir=144
  • Tutorial Presentation on the Security Risk Assessment Cookbook Version 7.6
  • Formal Security Cookbook Paper Version 2.41
  • Template Spreadsheet for Risk Assessment Version 3

• IHE Equivalent Process

Do NOT use this tool :-)

Mitigation Tools

The following are Security and Privacy standards that HL7 has published and may be used as a Mitigation.

This list is under construction:

• HL7 ConfidentialityCode vocabulary (2.16.840.1.113883.5.25)
• Implementation Guide for CDA Release 2.0 Privacy Consent Directive
• RBAC Permissions Catalog
• SAIF - Privacy, Access and Security Services (PASS)
  • Access Control Service
  • Healthcare Audit Services
• EHR Functional Model
  • (TBD)
• Transport Specification
  • Transport Layer Security (TLS)

Examples of Risk Assessment Spreadsheets

• SAML use in CCOW -- spreadsheet not yet published
  • The risk assessment was done informally and not recorded
  • The result was a statement in the formal specification that there is an unmitigated risk that the "Authenticating" application could misbehave as it is fully trusted to set the user identity correctly.
• CDA-Consent
  • First Draft 2010, July 27th
  • Second Draft 2010, Aug 3
  • Third Draft 2010, Aug 10
  • Fourth Draft 2010, Aug 31
  • Excerpt from the formal specification of the Security Considerations section
• PASS - Accounting of Disclosures Service
  • First Draft 2010, Aug 2
  • Second Draft 2010, Aug 9
  • Third Draft 2010, Aug 16
  • Excerpt from the formal specifications of part of the Security Considerations section