Ransomware is the fastest growing malware threat, targeting users of all types —from the home user to the corporate network. On average, more than 4,000 ransomware attacks have occurred daily since January 1, 2016. This is a 300 -percent increase over the approximately 1,000 attacks per day seen in 2015. There are very effective prevention and response actions that can significantly mitigate the risk posed to your organization. Ransomware targets home users, businesses, and government networks and can lead to temporary or permanent loss of sensitive or proprietary information, disruption to regular operations, financial losses incurred to restore systems and files, and potential harm to an organization’s reputation. Ransomware may direct a user to click on a link to pay a ransom; however, the link may be malicious and could lead to additional malware infections.
Antivirus vendors even admit a different approach is needed to stop unknown attacks. But trying to stay just a step ahead is not enough to stop sophisticated attacks.
Our next-generation endpoint and server protection uses several layers of attack prevention, including behavior detection and machine learning, to stop attacks that other vendors simply can’t. It also provides unparalleled threat visibility at a minimum system impact.
Ransomware is a form of malware that targets your critical data and systems for the purpose of extortion. Ransomware is frequently delivered through spearphishing emails. After the user has been locked out of the data or system, the cyber actor demands a ransom payment. After receiving payment, the cyber actor will purportedly provide an avenue for the victim to regain access to the system or data. Recent iterations target enterprise end-users, making awareness and training a critical preventive measure.
Self-Assessment question to Prevent Attacks
A commitment to cyber hygiene and best practices is critical to protecting your networks. Here are some questions you may want to ask of your organization to help prevent ransomware attacks:
Your NGEP solution needs to address six core pillars that, when taken together, can detect and prevent the most advanced attack methods at every stage of their lifecycle:
Looking for known threats won’t protect against variants or unknown attacks, but coupling it with additional security layers can pre-emptively stop known threats before they can execute on endpoints. However, instead of relying on a single vendor’s intelligence, make sure your NGEP uses a vast collection of reputation services to proactively block threats and bad sources. Be sure the NGEP vendor uses data from the cloud, indexing files for passive scanning or selective scanning to keep it lightweight, instead of performing resource-intensive system scans.
Hackers often use exploits to target code-level vulnerabilities so they can breach systems and execute malware. Drive-by downloads are a common vector for carrying out exploit attacks. NGEP should provide anti-exploit capabilities to protect against both application and memory-based attacks. This approach is much more reliable in detecting unknown attacks since the exploitation techniques themselves are not as easy to change or modify the shellcode, encoder, dropper, and payload components used in malware.
Your NGEP must be able to detect and block unknown malware and targeted attacks – even those that do not exhibit any static indicators of compromise. This involves dynamic behavior analysis – the real-time monitoring and analysis of application and process behavior based on low-level instrumentation of OS activities and operations, including memory, disk, registry, network, and more. Since many attacks hook into system processes and begin applications to mask their activity, the ability to inspect execution and assemble its true execution context is key. This is most effective when performed on the device regardless of whether it is on or offline (i.e. to protect even against USB stick attacks.)
Detecting threats is necessary, but with detection only, many attacks go unresolved for days, weeks, or months. Automated and timely mitigation must be an integral part of NGEP. Mitigation options should be policy-based and flexible enough to cover a wide range of use cases, such as quarantining a file, killing a specific process, disconnecting the infected machine from the network, or even completely shutting it down. Quick mitigation during the inception stages of the attack lifecycle will minimize damage and speed remediation.
During execution, malware often creates, modifies, or deletes system file and registry settings and changes configuration settings. These changes, or remnants that are left behind, can cause system malfunction or instability. NGEP must be able to restore an endpoint to its pre-malware, trusted state while logging what changed and what was successfully remediated.
Since no security technology claims to be 100% effective, the ability to provide real-time endpoint forensics and visibility is a must. Clear and timely visibility into malicious activity throughout an organization allows you to quickly assess the scope of an attack and take appropriate responses. This requires a clear, real-time audit trail of what happened on an endpoint during an attack and the ability to search for indicators of compromise.
Ransomware protection can be installed on the following operating systems.
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.
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:
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.
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.
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.
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:
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)).