Friday, November 27, 2009

Electronic health records could be a deadly target during a cyberwar

There is so much FUD being passed around on the 'hill'. Much of this is due to lack of spending time reading the specifications. In the attached article "Chad Skidmore" is quoted as worring that an attacker 'could' get into a system and change the clinical values thus resulting in a patient receiving the wrong treatment. I am not going to try to say that the risk is zero, but I would certainly not loose sleep over this one. There are many controls in place that prevent this threat from being realized.

Given that my blog is about Security and Privacy, I will focus on the technical measures. But there are plenty of Policy, Procedure, Protocol, and Human factors that are in play. Let me discuss the HIE solution that has been selected by HITSP. First I will discuss HITSP/SC112, specifically HITSP/TP13, specifically IHE/XDS (Cross-Enterprise Document Sharing), in this system there is a single Registry that holds metadata about each document that has been registered, and one or more Repository systems that hold the documents. The typical implementation would have a Repository in each sourcing organization, meaning that there would be a Repository in every clinic and hospital participating in an HIE . For each document in these Repositories there is metadata in the Registry, of this metadata is a byte-size and a SHA1 hash. Thus, for the threat that Chad brings up, someone would have to get access to the Repository to change the document, in a way consistent with CDA rules; and also update the Registry. They would need to do this all without causing Security Audit Events, which is a topic I will post on soon.

Now, some will say say that attacking both systems is possible. For you, I would offer yet another mitigation that HITSP offers, HITSP/C26 which is another document entry that is related to the clinical document and is an XML-Digital Signature. Thus the attacker would need to compromise the Registry, Repository, and falsify a Digital Signature; all while not creating Audit Events.

And I am sure others will recognize that the transactions are protected by HITSP/T17, otherwise known as mutual-authenticated-TLS. Thus attacking the data on the publication or the consumption side would be very difficult. (Yes I will tip my hat to, CVE-2009-3555, the man-in-the-middle attack now being frantically worked on by the TLS community. We might get a TLS 1.3 out of this and this might drive implementation).

Now, if a lesser system is used to build an HIE then the above can't be said. I know many are asking for a more simple approach. I would like to submit this very small 'Threat', as being a good example of the risk assessments that were considered as part of IHE XDS (see IHE ITI TF Vol 2x Appendix K). This should be seen as proof that IHE did consider a Risk Assessment when designing XDS. This 'Threat' may be mostly FUD, but it is one that I know is on the minds of Clinical people that are being expected to use the data when treating their patients. This is not a Threat to be taken lightly, event if it is handled nicely by the Infrastructure.