Until recently, the healthcare industry has been up in arms on whether ransomware infections should be considered reportable Health Insurance Portability and Accountability Act (HIPAA) breaches. The argument for considering ransomware a HIPAA breach was centered on the fact that covered entities lose control of protected health information (PHI). A counterargument is that ransomware is not known to exfiltrate data outside the network, and hence should not be considered a HIPAA breach.
The U.S. Health and Human Services (HHS) Office for Civil Rights finally weighed in on the discussion with new HIPAA guidance released on July 11, 2016. It covers how activities required by HIPAA can help mitigate ransomware incidents, but more importantly, it directly answers questions related to whether ransomware infections are considered reportable HIPAA breaches.
As a former sec ops lead for a large hospital network, I’ll highlight what I think are the most important excerpts of the HHS guidance and help you interpret some of the language to make it more actionable in a hospital environment.
Excerpt 1:
Is it a HIPAA breach if ransomware infects a covered entity’s or business associate’s computer system?
Whether or not the presence of ransomware would be a breach under the HIPAA Rules is a fact-specific determination. A breach under the HIPAA Rules is defined as, “…the acquisition, access, use, or disclosure of PHI in a manner not permitted under the [HIPAA Privacy Rule] which compromises the security or privacy of the PHI.” See 45 C.F.R. 164.402.6
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.
In short, the guidance is “Yes, a successful ransomware infection is considered a reportable HIPAA breach unless the covered entity can demonstrate that there is a ‘…low probability that the PHI has been compromised.’”
That makes sense, but how do you demonstrate there is a low probability that PHI has been compromised? HHS answers this question directly as well. Hospital IT Security and Compliance teams will want to pay close attention to the following section:
Excerpt 2:
How can covered entities or business associates demonstrate “…that there is a low probability that the PHI has been compromised” such that breach notification would not be required?
To demonstrate that there is a low probability that the protected health information (PHI) has been compromised because of a breach, a risk assessment considering at least the following four factors (see 45 C.F.R. 164.402(2)) must be conducted:
1. the nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification;
2. the unauthorized person who used the PHI or to whom the disclosure was made;
3. whether the PHI was actually acquired or viewed; and
4. the extent to which the risk to the PHI has been mitigated.
A thorough and accurate evaluation of the evidence acquired and analyzed as a result of security incident response activities could help entities with the risk assessment process above by revealing, for example: the exact type and variant of malware discovered; the algorithmic steps undertaken by the malware; communications, including exfiltration attempts between the malware and attackers’ command and control servers; and whether or not the malware propagated to other systems, potentially affecting additional sources of electronic PHI (ePHI). Correctly identifying the malware involved can assist an entity to determine what algorithmic steps the malware is programmed to perform. Understanding what a particular strain of malware is programmed to do can help determine how or if a particular malware variant may laterally propagate throughout an entity’s enterprise, what types of data the malware is searching for, whether or not the malware may attempt to exfiltrate data, or whether or not the malware deposits hidden malicious software or exploits vulnerabilities to provide future unauthorized access, among other factors. […]
Frequently, ransomware, after encrypting the data it was seeking, deletes the original data and leaves only the data in encrypted form. An entity may be able to show mitigation of the impact of a ransomware attack affecting the integrity of PHI through the implementation of robust contingency plans including disaster recovery and data backup plans. […]
The risk assessment to determine whether there is a low probability of compromise of the PHI must be thorough, completed in good faith and reach conclusions that are reasonable given the circumstances. […]
The above few paragraphs of commentary are perhaps the most important guidance from HHS because they outline what HHS defines as reasonable evidence and documentation for a covered entity to determine that a ransomware incident is not considered a reportable HIPAA breach.
Here are some conclusions based on my interpretation of the above HHS statements:
A ransomware incident may not be reportable if a reasonable number of the following three statements are true (I’ll leave it up to you to determine how many of these statements need to be true in order to consider a ransomware incident non-reportable.):
- The PHI involved was sufficiently encrypted or de-identified.
- The ransomware variant is identified and determined to not exfiltrate data.
- The PHI data has been successfully restored from backups.
You’ll notice I ignored the HHS factor related to who the unauthorized person is as I would consider all malware operators to be equally malicious.
The PHI involved was sufficiently encrypted or de-identified: It is clearly a best practice to de-identify PHI data that is exported from your electronic health record (EHR) application, even if it is intended to remain on the internal hospital networks. Doing so can contribute to the likelihood of concluding that a ransomware incident is not reportable.
The ransomware variant is identified and determined to not exfiltrate data: As I described following the second quoted statement, it is critical to understand the specific ransomware variant that infected the hospital network. If you know the ransomware variant, you can research it and confidently conclude that the ransomware did not exfiltrate data. At the time of this blog post, our Unit 42 threat intelligence team is not aware of a ransomware variant designed to exfiltrate data. Malware operators use a different family of malware for data exfiltration.
As strange as it sounds, ransomware operators tend to be trustworthy; they know that, in order for their business model to continue to work (i.e., for them to be paid), they need to provide the key to decrypt the files once they have been paid. Malware operators who exfiltrate data from a hospital network follow a different business model – one based on the sale of health data in underground networks.
Identifying the particular ransomware variant that infected a hospital can be difficult without the right technology because there are many ransomware variants. Our WildFire malware analysis service has evaluated over a million unique ransomware samples, which gives you an idea of the wide variety of ransomware in the wild.
Security architectures that are capable of identifying ransomware variants in hospitals are usually founded on a next-generation firewall designed to prevent malware at the network level, combined with advanced endpoint protection to stop malware at the endpoint.
The PHI data has been successfully restored from backups: As I mentioned in my previous blog posting outlining Tips to Prevent Ransomware in Healthcare Environments, it’s important to review and validate server backup processes in order to restore accessibility to ransomed PHI. Some organizations don’t realize their backups are compromised or were configured improperly until a critical restoration process fails.
Conclusion
HHS’s guidance has made it clear that healthcare organizations should be prepared for ransomware incidents. Hospitals that employ encryption or de-identification of their data at rest, build security architectures based on next-generation firewalls, deploy advanced endpoint protection, and test their backups periodically are better positioned to protect patient data, and hence are much less likely to be required to disclose a breach due to ransomware.
Additional Reading on Ransomware:
- Top Recommendations to Prevent Ransomware: an advisory report for security teams
- The Rise of Ransomware, a recent paper from our threat intelligence team, Unit 42 on the history of ransomware
Disclaimer – Do not consider any of the above statements as legal advice. You will need to review HHS’s guidance with your own compliance and legal teams.