HIPAA Ransomware Protection Solution

Ransomware is a type of malware (malicious software) distinct from other malware; its defining characteristic is that it attempts to deny access to a user’s data, usually by encrypting the data with a key known only to the hacker who deployed the malware until a ransom is paid. After the user’s data is encrypted, the ransomware directs the user to pay the ransom to the hacker (usually in a cryptocurrency, such as Bitcoin) in order to receive a decryption key. However, hackers may deploy ransomware that also destroys or exfiltrates2 data, or ransomware in conjunction with other malware that does so.

Yes. The HIPAA Security Rule requires the implementation of security measures that can help prevent the introduction of malware, including ransomware. Some of these required security measures include:

The Security Management Process standard of the Security Rule includes requirements for all covered entities and business associates to conduct an accurate and thorough risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all of the ePHI the entities create, receive, maintain, or transmit and to implement security measures sufficient to reduce those identified risks and vulnerabilities to a reasonable and appropriate level. It is expected that covered entities and business associates will use this process of risk analysis and risk management not only to satisfy the specific standards and implementation specifications of the Security Rule but also when implementing security measures to reduce the particular risks and vulnerabilities to ePHI throughout an organization’s entire enterprise, identified as a result of accurate and thorough risk analysis, to a reasonable and appropriate level. For example, although there is not a Security Rule standard or implementation specification that specifically and expressly requires entities to update the firmware3 of network devices, entities, as part of their risk analysis and risk management process, should, as appropriate, identify and address the risks to ePHI of using networks devices running on obsolete firmware, especially when firmware updates are available to remediate known security vulnerabilities.

In general, moreover, the Security Rule simply establishes a floor, or minimum requirements, for the security of ePHI; entities are permitted (and encouraged) to implement additional and/or more stringent security measures above what they determine to be required by Security Rule standards.

Yes. The HIPAA Security Rule requires covered entities and business associates to implement policies and procedures that can assist an entity in responding to and recovering from a ransomware attack.

Because ransomware denies access to data, maintaining frequent backups and ensuring the ability to recover data from backups is crucial to recovering from a ransomware attack. Test restorations should be periodically conducted to verify the integrity of backed-up data and provide confidence in an organization’s data restoration capabilities. Because some ransomware variants have been known to remove or otherwise disrupt online backups, entities should consider maintaining backups offline and unavailable from their networks.

Implementing a data backup plan is a Security Rule requirement for HIPAA-covered entities and business associates as part of maintaining an overall contingency plan. Additional activities that must be included as part of an entity’s contingency plan include disaster recovery planning, emergency operations planning, analyzing the criticality of applications and data to ensure all necessary applications and data are accounted for, and periodic testing of contingency plans to ensure organizational readiness to execute such plans and provide the confidence they will be effective. See 45 C.F.R. 164.308(a)(7).

During the course of responding to a ransomware attack, an entity may find it necessary to activate its contingency or business continuity plans. Once activated, an entity will be able to continue its business operations while continuing to respond to and recover from a ransomware attack. Maintaining confidence in contingency plans and data recovery is critical for effective incident response, whether the incident is a ransomware attack or fire, or natural disaster.

Security incident procedures, including procedures for responding to and reporting security incidents, are also required by HIPAA. See 45 C.F.R. 164.308(a)(6). An entity’s security incident procedures should prepare it to respond to various types of security incidents, including ransomware attacks. Robust security incident procedures for responding to a ransomware attack should include processes to:

Unless ransomware is detected and propagation halted by an entity’s malicious software protection or other security measures, an entity would typically be alerted to the presence of ransomware only after the ransomware has encrypted the user’s data and alerted the user to its presence to demand payment. However, in some cases, an entity’s workforce may notice early indications of a ransomware attack that has evaded the entity’s security measures. HIPAA’s requirement that an entity’s workforce receives appropriate security training, including training for detecting and reporting instances of malicious software, can thus assist entities in preparing their staff to detect and respond to ransomware. Indicators of a ransomware attack could include:

If an entity believes that a ransomware attack is underway, either because of indicators similar to those above or other methods of detection, the entity should immediately activate its security incident response plan, which should include measures to isolate the infected computer systems in order to halt propagation of the attack.

Additionally, it is recommended that an entity infected with ransomware contact its local FBI or the United States Secret Service field office. These agencies work with Federal, state, local and international partners to pursue cyber criminals globally and assist victims of cybercrime.

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. A security incident is defined as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. See the definition of a security incident at 45 C.F.R. 164.304. Once the ransomware is detected, the covered entity or business associate must initiate its security incident and response and reporting procedures. See 45 C.F.R. 164.308(a)(6).

HIPAA-covered entities and business associates are required to develop and implement security incident procedures and response and reporting processes that they believe are reasonable and appropriate to respond to malware and other security incidents, including ransomware attacks. Entities seeking guidance regarding the implementation of security incident procedures may wish to review NIST SP 800- 61 Rev. 2, Computer Security Incident Handling Guide5 for additional information.

An entity’s security incident response activities should begin with an initial analysis to:

These initial steps should assist the entity in prioritizing subsequent incident response activities and serve as a foundation for conducting a deeper analysis of the incident and its impact. Subsequent security incident response activities should include steps to:

Part of a deeper analysis should involve assessing whether or not there was a breach of PHI as a result of the security incident. The presence of ransomware (or any malware) is a security incident under HIPAA that may also result in an impermissible disclosure of PHI in violation of the Privacy Rule and a breach, depending on the facts and circumstances of the attack. See the definition of disclosure at 45 C.F.R. 160.103 and the definition of the breach at 45 C.F.R. 164.402.

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.

When electronically 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 this 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.

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:

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 are hidden malicious software or exploits vulnerabilities to provide future unauthorized access, among other factors.

Although entities are required to consider the four factors listed above in conducting their risk assessments to determine whether there is a low probability of compromise of the ePHI, entities are encouraged to consider additional factors, as needed, to appropriately evaluate the risk that the PHI has been compromised. If, for example, there is a high risk of unavailability of the data or high risk to the integrity of the data, such additional factors may indicate compromise. In those cases, entities must provide notification to individuals without unreasonable delay, particularly given that any delay may impact healthcare service and patient safety.

Additionally, with respect to considering the extent to which the risk to PHI has been mitigated (the fourth factor) where ransomware has accessed PHI, the entity may wish to consider the impact of the ransomware on the integrity of the PHI. 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. Conducting frequent backups and ensuring the ability to recover data from backups is crucial to recovering from a ransomware attack and ensuring the integrity of PHI affected by ransomware. Test restorations should be periodically conducted to verify the integrity of backed-up data and provide confidence in an organization’s data restoration capabilities. Integrity to PHI data is only one aspect when considering to what extent the risk to PHI has been mitigated. Additional aspects, including whether or not PHI has been exfiltrated, should also be considered when determining the extent to which the risk to PHI has been mitigated.

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. Furthermore, in accordance with 45 C.F.R. 164.530(j)(iv)), covered entities and business associates must maintain supporting documentation sufficient to meet their burden of proof (see 45 C.F.R. 164.414) regarding the breach assessment – and if applicable, notification – process including:

This is a fact-specific determination. The HIPAA breach notification provisions apply to “unsecured PHI” (see 45 C.F.R. 164.402), which is protected health information (PHI) that is not secured through the use of a technology or methodology specified by the Secretary in guidance. If the electronic PHI (ePHI) is encrypted by the entity in a manner consistent with the Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals such that it is no longer “unsecured PHI,” then the entity is not required to conduct a risk assessment to determine if there is a low probability of compromise, and breach notification is not required.

However, even if the PHI is encrypted in accordance with the HHS guidance, additional analysis may still be required to ensure that the encryption solution, as implemented, has rendered the affected PHI unreadable, unusable, and indecipherable to unauthorized persons. A full disk encryption solution may render the data on a computer system’s hard drive unreadable, unusable, and indecipherable to unauthorized persons while the computer system (such as a laptop) is powered down. Once the computer system is powered on and the operating system is loaded, however, many full disk encryption solutions will transparently decrypt and encrypt files accessed by the user.

For example, if a laptop encrypted with a full disk encryption solution in a manner consistent with HHS guidance8 is properly shut down and powered off and then lost or stolen, the data on the laptop would be unreadable, unusable, and indecipherable to anyone other than the authenticated user. Because the PHI on the laptop is not “unsecured PHI”, a covered entity or business associate need not perform a risk assessment to determine a low probability of compromise or provide breach notification.

However, in contrast to the above example, if the laptop is powered on and in use by an authenticated user, who then performs an action (clicks on a link to a malicious website, opens an attachment from a phishing email, etc.) that infects the laptop with ransomware, there could be a breach of PHI. If full disk encryption is the only encryption solution in use to protect the PHI and if the ransomware accesses the file containing the PHI, the file containing the PHI will be transparently decrypted by the full disk encryption solution and access permitted with the same access levels granted to the user.

Because the file containing the PHI was decrypted and thus “unsecured PHI” at the point in time that the ransomware accessed the file, an impermissible disclosure of PHI was made and a breach is presumed. Under the HIPAA Breach Notification Rule, notification in accordance with 45 CFR 164.404 is required unless the entity can demonstrate a low probability of compromise of the PHI based on the four-factor risk assessment (see 45 C.F.R. 164.402(2)).