Cookbook for Security Considerations

As not all IHE profile 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 ITI Technical Committee while compiling the Security Considerations section for new profiles during the year 5 cycle (mainly XCA and RFD).

This cookbook is specifically intended for IHE profile writers. Though it is based on best practice, it is not a complete method for thorough risk assessment of a package product. IHE does not endorse any use of this cookbook outside of the scope of IHE profile editing.

After presenting the basics of risk assessment and risk mitigation, the cookbook explains how to scope Security Considerations for IHE profiles and finally provides guidelines on the effective writing of the Security Considerations section.

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

This breaks down to generally:

1. Define the Scope of the Profile.
   1. Define existing Security Mitigations
   2. Define the Assets that need to be protected
      • This is usually the data objects, and network-services exposed
2. Risk Process Risk assessment and mitigation spreadsheet
   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 for each how likely it would be 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 Likelihood 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

• Formal White Paper can be found at http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_Cookbook_2008-11-10.pdf
• Template Spreadsheet for Risk Assessment at ftp://ftp.ihe.net/Document_templates/Security_Considerations/
• The HL7 Equivalent Process
• RFC 3552 The IETF Equivalent Process

Existing Security Mitigation Profiles

Security and Privacy Profiles IHE has produced some Profiles and White Papers that can be used in the Security Considerations as mitigations for identified risks.

• [ATNA] Audit Trail and Node Authentication Basic security through (a) functional access controls, (b) defined security audit logging and (c) secure network communications.
• [BPPC] Basic Patient Privacy Consents method for recording a patient's privacy consent acknolwedgement to be used for enforcing basic privacy appropriate to the use.
• [CT] Consistent Time enables system clocks and time stamps of computers in a network to be synchronized (median error less than 1 second).
• [XUA] Cross-Enterprise User Assertion communicates claims about the identity of an authenticated principal (user, application, system...) across enterprise boundaries - Federated Identity.
• [EUA] Enterprise User Authentication enables single sign-on inside an enterprise by facilitating one name per user for participating devices and software.
• [PWP] Personnel White Pages provides basic directory information on human workforce members within an organization.
• [DSG] Document Digital Signature is a content profile that specifies digital signatures for documents.
• [HPD] Healthcare Provider Directory supports discovery and management of healthcare provider information, both individual and organizational, in a directory structure.

Integrated profile specific Security is not just about Profiles, there are specific things that can be done to a profile that address specific risks:

• XDS Metadata attributes "hash" and "size" - These attributes are manditory attributes in XDS Metadata so that end-to-end integrity can be verified. This is especially helpful in XDS where these metadata values are managed in an independent Registry from where the document is stored in the Repository.

White Papers

• HIE Security and Privacy through IHE Describes how to use the IHE security and privacy profiles to secure a Health Information Exchange
• ITI Access Control White Paper Describes how Federated Access Control is architected and how the IHE Security and Privacy Profiles fit within this architecture.

Examples of Risk Assessment Spreadsheets

• ITI-XCA Risk Analysis
• ITI-RFD Risk Analysis
• ITI-SVS Risk Analysis
• PCC-Perinatal Workflow Risk Analysis

See the specific profiles for how these risk assessments affected the Security Considerations sections.

Examples of Security Considerations sections

Patient Care Devices

This is only a example of what they could say.

Security Considerations During the Profile development there was no unusual security/privacy concerns identified. There are no mandatory security controls but the implementer is encouraged to use of the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed.