Virta Labs Blog


OCR on ransomware and why inventory matters

Posted by Kevin Fu on Jul 13, 2016 5:19:46 PM
Find me on:

This blog post is about the long awaited fact sheet from HHS Office of Civil Rights (OCR) on ransomware, and why you should take this one seriously in terms of having an accurate inventory of networked medical devices to reduce the probability of enjoying the pleasure of reporting a breach to OCR.

While we can poké fun at government speak and their litany of acronyms, the document offers some fairly deep technical arguments on why OCR considers a ransomware attack as a breach by default. Let me say this again for emphasis. In terms of HIPAA compliance, ransomware that encrypts patient health information (PHI) is considered to have caused a breach subject to all the HIPAA pleasures if not methodically adjudicated. So what does this mean for clinical workflow and security operations?

The good news is that some health delivery organizations (HDOs) already treat malware as a breach by default, conduct regular risk assessments, and perform forensic analysis whenever malware is found. The bad news for the majority of less prepared HDOs: the OCR guidance means you just got clarity on whether ransomware results in a breach. Sorry, the answer is yes, unless you have methodical evidence to the contrary. Those tabletop exercises from your CISO on continuity of operations after a ransomware attack on clinical networks? Now you should add HIPAA compliance and breach notification to your simulations. Here's the exact wording from the OCR fact sheet:

The presence of ransomware (or any malware) on a covered entity’s or business associate’s computer systems is a security incident under the HIPAA Security Rule

When electronic protected health information (ePHI) is encrypted as the result of a ransomware attack, a breach has occurred because the ePHI encrypted by the ransomware was acquired (i.e., unauthorized individuals have taken possession or control of the information), and thus is a “disclosure” not permitted under the HIPAA Privacy Rule.

Unless the covered entity or business associate can demonstrate that there is a “...low probability that the PHI has been compromised,” based on the factors set forth in the Breach Notification Rule, a breach of PHI is presumed to have occurred. The entity must then comply with the applicable breach notification provisions, including notification to affected individuals without unreasonable delay, to the Secretary of HHS, and to the media (for breaches affecting over 500 individuals) in accordance with HIPAA breach notification requirements. See 45 C.F.R. 164.400-414.

Get Of Jail Free Card

One of the more interesting bits from the fact sheet is the discussion of get-out-of-jail-free cards. Normally, full-disk encryption (FDE) would suffice to check the box when a hard drive is lost. However, OCR is technically savvy enough to call bullshit on FDE for ransomware because ransomware runs after the FDE has been removed. Whether or not an HDO is happy about FDE being removed as a get-of-jail-free card, I have to give credit to OCR's technical analysis. FDE is effective for reducing risk of breaches for lost hard drives, but is not designed to reduce the risk of a breach while the file system is open and in active use. Well, shit.

On top of that, medical devices do a poor job at encryption of data at rest. The most progressive HDOs already know that manufacturers are reluctant to encrypt data at rest. To date, I haven't found a single medical device that encrypts data at rest. I am hoping someone sends me a device with encryption at rest so I can delete the previous sentence. So what happens when a medical device contains unencrypted PHI and depends on a bunch of third party software that doesn't appear in your inventory management system?  Do you know which devices in your clinical network run JBoss servers? Do you know the exact version of OpenSSL for each medical device? Who wrote the firmware for your network interface card in that linear accelerator that reboots during a vulnerability scan?  

When we last saw our data^H^H^H^Hhero

So rather than run around with your hair on fire, what can be done? Take a cue from the NIST cybersecurity framework and Pokémon Go.

  1. Enumerate your cybersecurity risks. Begin with an accurate inventory of your networked medical device assets. If you know your risk and threat surface, you can more easily build evidence to show a low probability that ransomware resulted in a breach of PHI. 
  2. Deploy compensating controls. It's easy to buy security tools, but it's hard to use the tools effectively while respecting clinical workflow. That's why there's step three....
  3. Continuously monitor the effectiveness of security controls. Penetration testing and vulnerability scanning are common approaches here, but are just part of the solution. With general purpose security tools, be very careful on live clinical networks so as not to cause unsafe conditions. 

IMG_2016-07-13-14363653.pngA cybersecurity risk assessment without an accurate inventory is not much better than searching only under the streetlights. If you truly know your assets, then you will be in good shape to demonstrate a low probability that the PHI has been compromised after a ransomware attack.  

But don't take my word for it.  Read the primary sources, then Go: 


Topics: Healthcare Cybersecurity, Ransomware, Medical Device Security, Legacy Medical Devices, Asset Management, Enterprise Risk Management, Inventory Management, Clinical Security, CMMS