Monday, May 2, 2011

There is No Security Pixie Dust

At IHE, HL7, DICOM, and elsewhere those writing a Profile or Standard turn to the security-geeks in the room and ask them to fill out the now highly recommended "Security Considerations" section, or ask us which other Profile they can cut-and-paste from. The security-geeks respond with "There is no security pixie dust".

Within IHE the security-geeks have published a process the "Security Considerations Cookbook" that is intended to be used by the writers of Profiles, a process that 'considers' 'security'.  The reason why we came up with the Security Considerations Cookbook is exactly because each profile is different, and that security must really be 'considered' by the profile authors. There really is no short-circuit of the process with a cut-and-paste from another profile. There is no magic security pixie-dust.    

The profiles in the Final Text were published well before we came up with the cookbook, so they are not a good example (BPPC and XDS are good, but not simple profiles). It turns out that the Profiles where we have spent significant effort using the "Security Considerations Cookbook" have  not gone to final text yet. This is why you don't find a really good example of Security Considerations in the Final  Text Technical Framework. For good examples of Security Considerations one needs to look at the Trial Implementation supplements, But having a 'really good example' is impossible. Let me explain by example:

  • This is a really good example of a profile that has explicitly declared that ATNA is not mandatory, but if one decides to group them in their application, then the encoding of the audit message is specified.
  • The wording is not perfect, we always find some text that likely needs changing. The volume 2 stuff should actually be more clear about the 'if a developer does group with ATNA, this is the encoding'
  • But this  profile has the advantage that it is just operating on vocabulary, and thus no identifiers or clinical data.

  • This is also a really good example, especially for Vol 1.

  • This is a good example of Vol 1, and that is all that this one identifies. This is because the actual content carried by the Vol 2 transactions is unknown.

  • This is a good example of something totally different
  • This one might have the best wording in Vol 2...

But in ALL cases, you can see the influence of the RISK ASSESSMENT.
  • It is only after the risk assessment that we know if a mandatory grouping with ATNA is the right thing to do.
  • It is only after the risk assessment that we know if other things should be done, or should be explicitly NOT done.
  • Etc...

So, you MUST actually 'consider' security, through following the process defined in the Cookbook_for_Security_Considerations. There is no magic security pixie-dust.  

Note: The same is  true in the HL7 Security Considerations Cookbook