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.
Well, the question is how you could add an error to the record that was sufficiently convincing to lead to wrong treatment, but still actually be noticeable amongst the blizzard of other problems in the medical record, which is why clinicians always consider multiple data points and check for consistency
ReplyDeleteHe's clearly a twit. The real threat is DoS. I know of hospitals that have been victims of DoS, and some suffered serious interference with hospital operations. Most hospital IT staff have figured this out and I don't know of any successful DoS attacks in the past two years.
ReplyDeleteI wouldn't expect HITSP transactions to do or say anything about DoS because there is nothing special about healthcare. It's the same basic DoS attack as is used elsewhere.
The really serious attacks will be social in nature. Look at how much damage a few dozen idiots screaming about mercury and vaccinations has done. The public is ripe for organized panic campaigns.