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
(New page: 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 [...)
 
Line 7: Line 7:
 
= The Process =
 
= The Process =
  
Formal White Paper can be found at http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_Cookbook_2008-11-10.pdf
+
Formal Process should be followed. See the References below
  
 
This breaks down to generally:
 
This breaks down to generally:

Revision as of 21:56, 15 February 2010

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.

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.

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.

The Process

Formal Process should be followed. See the References below

This breaks down to generally:

  1. Define the Scope of the Profile.
    1. Define existing Security Mitigations (e.g. ATS inclusion of Transport Layer Security)
    2. Define the Assets that need to be protected
      • This is usually the data objects, and network-services exposed
  2. Risk Process
    1. Brainstorm on potential risks (focus on risks to Data-Confidentiality, Data-Integrity, or Data-Availability)
      • See Figure 2.2.1-2: Generic Scenario Components
    2. Determine for each how bad (Impact) it would be if it did happen
      • See Figure 2.2.1-3: Guidelines of impact relevance for IHE profiles
    3. Determine each Likelyhood to happen
      • See Table 2.2.2-3: Example of probability of occurrence
    4. Calculate the Risk Value
      • See Table 2.2.2-5: Example of matrix for relevant risks identification
    5. Address the highest Risk Values first.
      • See section 2.2.3.2 Identify mitigations
    6. Each time you put a mitigation in place, you must re-assess as the mitigation may have introduced a new Risk or adjusted the Likelyhood or Impact on other Risks.
      • See section 2.2.3.3 Evaluate mitigations
  3. Write the Security Considerations section
    1. Volume 1: Security Considerations section is for risks and mitigations that are profile-wide
    2. Volume 2+: Security Considerations sections are for risks and mitigations that are transaction or content specific.
    3. focus on the relevant risks and how they have been addressed. The security section should be a literary presentation of the security constraints (e.g. mandatory or optional grouping with IHE security profile), the security features as well as a summary of the reasons why these constraints and features are required (risks addressed). It should also include a summary of the risks left to be mitigated by developers and implementers.


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