Tuesday, February 16, 2010

How to Write Secure Interoperability Standards

I am an active member of "Interoperability Standards" organizations: HL7, ASTM, DICOM, ISO TC215, OASIS, and IETF. I am also an active member of "Profiling" organizations: IHE, and HITSP.  I am most active in the security/privacy workgroups in these organizations, where we receive strange requests from the 'other' workgroups. These requests are a fragment of a security issue, but don't have enough information around the issue to make them actionable work items. Some of them are issues for which the organization already has a solution, such as Transport Layer Security (TLS). Some of them are simply "Security Theater".

The security workgroups decided to provide some guidance to the 'other' workgroups on how to appropriately design their standard with security-built-in. Security is about mitigating risk to Confidentiality, Integrity, and Availability. So we knew that our guidance would be an instruction set on how to do a Risk Assessment. We knew that the 'other' workgroups are made up of smart people that needed simply a little guidance, but knew that we needed to carefully craft our guidance so that it would be used. So, we wrote a "Cookbook" on the topic of  writing the "Security Considerations" section of their standard. A title that we figured would have people thinking we were giving them simple instructions, read "Cut-and-Paste", on how they should write their Security Considerations section. We know it is the most simple approach even if one must first do a risk assessment which is typically not seen as a 'simple' task.

The advantages of this approach are:
  1. The 'other' workgroup must first describe the expectations of the environment that they expect their standard will be used. This includes describing the already available underlying security technology.
  2. The 'other' workgroup uses the risk assessment tool to quantitatively prioritize the actual risks. Thus they focus on real risks, and can prioritize the most 'risky' issues. 
  3. The 'other' workgroup will flow-down unmitigated risks to the next level of design. There are risks that can't be mitigated by a standards organization. These unmitigated risks should be documented in their standard, "Security Considerations", as risks that are identified but not mitigated. This list of risks can be picked up by the next level of design.
  4. The 'other' workgroup has good documentation of issues that the 'security' workgroup should work on. The risk assessment is a clear communications tool that has the background and the risk well defined and prioritized.
These Procedures are now available at:
  • HL7 version of the "Cookbook for Security Considerations" has a really good PowerPoint training package. This one has not yet been piloted, but there are a few projects that will be running this process. These pilot projects are closely associated with the security workgroup.
  • IHE version of the "Cookbook for Security Considerations" has some good experience having used the tool on a set of profiles already. The risk assessments are not considered normative, but are archived so that they can be reviewed when the Profile gets revised. These risk assessment spreadsheets are useful reference when a new 'other' workgroup uses the tool.

In both cases, more has yet to be learned.


  1. Hi John...

    I enjoyed the small amount of time I had to spend on your blog...I actually have a deeper request....

    My name is Chris Pauer and I work for TomoTherapy in Madison...more to the point, I am a member of the IHE-RO (Radiation Oncology) Technical Committee...and we have been asked to look into authentication and authorization by our Planning Committee.

    I got "volunteered" for the task of trying to get enough information together to set a position because I had an early and strong opinion that this was not a domain that we should attempt to do a lot of work in, since the problem we are being asked to address is not specific to RO, and is not only a healthcare enterprise issue, it is a widespread corporate issue that all large organizations want to solve in some capacity...

    These opinions come from some, admittedly outdated, experiences implementing some single sign on processes at a large insurance company in Madison...

    Anyway, I am trying to get a contact to verify some of my findings in this area, and to make sure that we don't join the local "Security Theater" troupe just to satisfy the planning committee's request. My enquiries are first taking the form of giving an overview of EUA and XUA to our team, and trying to draw out quotes from the profile documents that say succinctly what the profiles cover or don't cover....

    If you could reply at cpauer@tomotherapy.com, that would be greatly appreciated, and you can take the opportunity to steer me to another contact if that is appropriate.

  2. Chris,

    From your comment it sounds like you are the person assigned by the IHE-RO domain to execute the very procedure pointed to. Go to the IHE version of the "Cookbook for Security Considerations" link. This is a Wiki article that points at the formal procedure document, has some references to existing Security focused Profiles, some existing Risk Assessments, and other goodies. I would be happy to work with you on this.

    You are absolutely correct that you should start with the Security/Privacy profiles that the ITI committee published. These are intended to be re-used across the domains. Once you have identified the base set, typically just ATNA, then you start the risk assessment.