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...
Note: The same is true in the HL7 Security Considerations Cookbook
Unfortunately, John, the language in the security cookbook assumes a level of knowledge of security that the average IHE profile writer does not have. The folks I know who have come to me about the security section and have been directed to read the cookbook usually end up more confused than when they started. If you know enough about security to understand what the cookbook is saying, you probably don't need it.
ReplyDeleteI don't know what the solution is, but "Just read the cookbook" isn't it.
There needs to be some movement in one or the other direction. As the profiles I show indicate there is no one solution. Some profiles don't even need ATNA grouping. Push type profiles are protected differently than Query like profiles (e.g. XUA is useless on Push type profiles). Some profiles will leverage the security built into the underlying standard (PWP/HPD - leverage LDAP attribute protection).
ReplyDeleteOne movement that I might suggest is a default starter kit that assumes that the transactions are cross-enterprise/community and that they contain sensitive information. I guess we could have one template for a PUSH and another for Query type.
There was 'someone' on the original cookbook committee that really objected to this and wanted ALL security mitigation to be as a result of a risk assessment that starts with zero mitigation. This seems like a good idea, but impracticable with amateurs.
That's a possibility that has promise. Content profiles would need a third kind of template, as well. Usually security discussions around content profiles end up with me, unsuccessfully, trying to explain why we can't dictate policies around control of access to sensitive information.
ReplyDelete