Ransomware Protection Solution

Best solution for Healthcare, Financial and any industry that needs to protect sensitive information and its availability (with 1 Million Dollar Guarantee)

Ransomware is the fastest growing malware threat, targeting users of all types —from the home user to the corporate network. On an 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.

What is Ransomware?

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 to the victim to regain access to the system or data. Recent iterations target enterprise end users, making awareness and training a critical preventive measure.

Is my Company Vulnerable to Ransomware Attacks?

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:

  • Backups: Do we backup all critical information? Are the backups stored offline? Have we tested our ability to revert to backups during an incident?
  • Risk Analysis: Have we conducted a cybersecurity risk analysis of the organization?
  • Staff Training: Have we trained staff on cybersecurity best practices?
  • Vulnerability Patching: Have we implemented appropriate patching of known system vulnerabilities?
  • Application Whitelisting: Do we allow only approved programs to run on our networks?
  • Incident Response: Do we have an incident response plan and have we exercised it?
  • Business Continuity: Are we able to sustain business operations without access to certain systems? For how long? Have we tested this?
  • Penetration Testing: Have we attempted to hack into our own systems to test the security of our systems and our ability to defend against attacks?
  • Enterprise Ransomware solution: Have we evaluated any solution which acts as an additional layer on top of all preventive steps that we have taken?

Which regulations will company comply by using Ransomware enterprise solutions?

  • PCI DSS3.1 Requirement 5
  • HIPAA Security Rule requirement 164.308(a)(5)(ii)(B), decreases organizational risk by evaluating malware based on system behavior and reduces malware exposure to organizations.

Six Things Your Next Generation Endpoint Protection (NGEP) Must Do 

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:

1. Known Attack Prevention

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.

2. Dynamic Exploit Detection

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.

3. Advanced Malware Detection

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.)

4. Mitigation

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 inception stages of the attack lifecycle will minimize damage and speed remediation.

5. 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.

6. Forensics

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.

Which operating systems are supported?

Ransomware protection can be installed on following operating systems.

  • Windows 7, 8, 8.1, 10
  • Windows Server 2008 R2, 2012 R2
  • OS X 10.9.x, 10.10.x, 10.11
  • Red Hat Linux, CentOS 6.5 and above

Features and Benefits of our solution

  • Broad platform support – Windows | OS X | Linux
  • Attack visualization with real-time forensics
  • Policy-based mitigation and remediation options
  • On-premise or cloud management options
  • Protection from all attack vectors – malware, exploits, live/insider threats
  • Over 4x lower TCO
  • One platform for antivirus, anti-exploit, and forensics
  • Low CPU utilization at 1-2%

Request for a free Demo of the Product by calling us now at 515-865-4591 or email us at Bob@supremusgroup.com

FAQ on Ransomware & HIPAA Compliance

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 implementation of security measures that can help prevent the introduction of malware, including ransomware. Some of these required security measures include:

  • implementing a security management process, which includes conducting a risk analysis to identify threats and vulnerabilities to electronic protected health information (ePHI) and implementing security measures to mitigate or remediate those identified risks;
  • implementing procedures to guard against and detect malicious software;
  • training users on malicious software protection so they can assist in detecting malicious software and know how to report such detections; and
  • implementing access controls to limit access to ePHI to only those persons or software programs requiring access.

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 an accurate and thorough risk analysis, to a reasonable and appropriate level. For example, although there is a 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 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:

  • detect and conduct an initial analysis of the ransomware;
  • contain the impact and propagation of the ransomware;
  • eradicate the instances of ransomware and mitigate or remediate vulnerabilities that permitted the ransomware attack and propagation;
  • recover from the ransomware attack by restoring data lost during the attack and returning to “business as usual” operations; and
  • conduct post-incident activities, which could include a deeper analysis of the evidence to determine if the entity has any regulatory, contractual or other obligations as a result of the incident (such as providing notification of a breach of protected health information), and incorporating any lessons learned into the overall security management process of the entity to improve incident response effectiveness for future security incidents.
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 receive 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:

  • a user’s realization that a link that was clicked on, a file attachment opened, or a website visited may have been malicious in nature;
  • an increase in activity in the central processing unit (CPU) of a computer and disk activity for no apparent reason (due to the ransomware searching for, encrypting and removing data files);
  • an inability to access certain files as the ransomware encrypts, deletes and re-names and/or relocates data; and
  • detection of suspicious network communications between the ransomware and the attackers’
    command and control server(s) (this would most likely be detected by IT personnel via an
    intrusion detection or similar solution).

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 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 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:

  • determine the scope of the incident to identify what networks, systems, or applications are affected;
  • determine the origination of the incident (who/what/where/when);
  • determine whether the incident is finished, is ongoing or has propagated additional incidents throughout the environment; and
  • determine how the incident occurred (e.g., tools and attack methods used, vulnerabilities exploited).

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:

  • contain the impact and propagation of the ransomware;
  • eradicate the instances of ransomware and mitigate or remediate vulnerabilities that permitted the ransomware attack and propagation;
  • recover from the ransomware attack by restoring data lost during the attack and returning to “business as usual” operations; and
  • conduct post-incident activities, which could include a deeper analysis of the evidence to determine if the entity has any regulatory, contractual or other obligations as a result of the incident (such as providing notification of a breach of protected health information), and incorporating any lessons learned into the overall security management process of the entity to improve incident response effectiveness for future security incidents.

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 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 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.

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.

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 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:

  • documentation of the risk assessment demonstrating the conclusions reached;
  • documentation of any exceptions determined to be applicable to the impermissible use or disclosure (see 45 C.F.R. 164.402(1)) of the PHI; and
  • documentation demonstrating that all notifications were made, if a determination was made that the impermissible use or disclosure was a reportable breach.
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)).