This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Cookbook for Security Considerations"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
As not all HL7 standards writers are security experts, this cookbook is intended to provide basic knowledge on conducting a risk assessment and some “tricks of the trade” relevant to [[Security Considerations]] section writing. It is not only based on best practice in the field of risk assessment and mitigation but also on the experience of the Security Workgroup while compiling the [[Security Considerations]] section for new HL7 works.
+
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.  
  
This cookbook is specifically intended for HL7 standards writers. Though it is based on best practice, it is not a complete method for thorough risk assessment of a package product. HL7 does not endorse any use of this cookbook outside of the scope of HL7 standards editing.
+
== The Goal ==
  
After presenting the basics of risk assessment and risk mitigation, the cookbook explains how to scope [[Security Considerations]] for HL7 standards and finally provides guidelines on the effective writing of the [[Security Considerations]] section.
+
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 Process =

Revision as of 04:40, 16 February 2010

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

Formal Process should be followed. See the References below (This text comes from section 2)

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)

Do NOT use this tool :-)

Resources

Examples of Risk Assessment Spreadsheets

  • SAML use in CCOW -- spreadsheet not yet published
  • CDA-Consent -- spreadsheet not yet published