Ransomware is a major concern these days. In many cases, it is a nightmare once it hits, and not just for desktops, but also for servers. Think about it: how would your brand-new analytics package fare if all of the disk data were encrypted by ransomware? Desktops may be the way in, but the deeper into the environment the attacker gets, the more valuable the data. This is where data protection comes to the fore: not just disaster recovery or business continuity, but protection of archival data. We need all of these to survive the latest ransomware attacks by attackers who never send you working decryption keys even if you pay. Preventing a ransomware attack is one thing. Dealing with the aftermath of an attack is another. Prevention and incident response are crucial.

Ransomware Prevention

Prevention of ransomware attacks is often related to education. If we study how most ransomware enters a system, we see that there are many ways to look at solutions. Solutions that prevent ransomware attacks may also prevent other malicious attacks. The base requirement of these tools is to prevent access to the file system where data is mounted. Yes, that is the main requirement to prevent ransomware incursions. Now, we also know that ransomware comes in via email, the browser, and applications that access the network or even email. So, what do we need? We need:

  • A system that does not mount any crucial data, does not have any crucial data upon it, or does not allow access to the file system from email, the browser, or applications.
  • A system that works with all email, browsers, and applications.

This leaves us with several options to containerize the browser:

  • A secure inside to outside virtual desktop environment with no data within the desktop.
  • A secure inside to outside virtual desktop environment presenting applications to another desktop (unity mode).
  • A secure container in which to run browsers, email programs, and applications that denies access to file systems. Such systems include Bromium vSentry and others that act as proxies for browsers, remotely executing the content and displaying just the results (such as Authentic8 Silo).

These tools will help, but not for all platforms, such as Mac and Linux unless using the proxy method. This is why we also need data protection practices that archive data rather than overwriting data.

Data Protection

Part of prevention is defense in depth. Even if we use the aforementioned tools, we should consider data protection. How are we protecting personal and business data? There are myriad tools that claim to protect your data from ransomware but have potential weaknesses. The easiest way to defend against ransomware is to have a good data protection scheme: several backups in time. The requirements of such a data protection scheme are the same as those for prevention tools:

Direct access to the backup media by the host being backed up should never be allowed.

Yes, never be allowed. This rules out mounting a backup location, such as used by Apple TimeMachine, or using a local USB device on a laptop, etc. Instead, we should use a network backup mechanism. Ah, but does this mean agents? Perhaps; it depends on the location and type of the system in question.

  • Physical Systems: These systems require an agent or endpoint application such as those from Veeam, Synology, Vembu, and Veritas, among others. This is the traditional backup approach. Veeam and Vembu endpoint tools back up to their respective enterprise servers hosting all your other backups for servers. Synology endpoint will back up to any Synology device.
  • Virtual Systems: These systems can be backed up using an agent or agentless, depending on the hypervisor in use and the location. Systems in clouds are often treated as physical systems. Those running on-premises often use the hypervisor means to do the backup.

The key is that none of these systems should mount the media to the system being backed up. At the same time, backup is just a part; you need to keep multiple versions stretching back as far as you can handle. To protect against ransomware, you must also test your backups, in case your backups contain the malware.
It is important not only to back up, but also to test the backup in some automated fashion to ensure that the backed-up material is not encrypted. Perhaps a canary system would be best. One way to do this is to always use incrementals, and if an incremental is significantly larger, to look at the data to determine if it is readable. If readable, continue; otherwise, mark it as encrypted and remove from it the ability to be automatically restored. You may even automatically restore to the previous restore point at night. Changes would be lost, but systems would be usable. Automation will be key in detecting ransomware—automation that currently does not exist within data protection tools.

Ransomware Incident

Do you have an incident response plan for ransomware? If you do not, you need one.
Incident response should include checking all the items mentioned earlier as preventatives. Why? Because if they fail, you are the hands of the malware writer. “But,” you may say, “I do backups.” Do you know if those backups restore? When was the last time you checked or tested the restore of your laptop, desktop, etc.? I do not mean testing to see if the system boots, but testing to ensure you can access critical data. Machines impacted by ransomware boot, so we need to go one step beyond a boot and ensure data is readable. Yes, such actions need to be automated. Automation helps with incident response, as the reports are the same.
Incident response requires looking into how the ransomware infected the system, tracing back the attack to the source. This is the more difficult aspect, but tools exist that can assist with this: tools such as Attivo Networks. Attivo not only provides deception techniques that fool the attacker into attacking well-known systems with well-known vulnerabilities (which normalizes automated incident response), but also provides a mechanism that does the heavy lifting of incident response, such as log gathering by various tools. This means the incident response engineer can concentrate on finding the issue, not gathering data.
Even with such tools, a well-written incident response plan is proper. The most basic requirements for incident response for ransomware are to forensically capture the impacted system and to restore the impacted system to a usable state. The former allows continued research, while the later allows continued work to be done.

Final Thoughts

There is a lot to consider when you look at specific security threats. These considerations often spread over multiple disciplines as one attempts to understand, record, and automate a response to an attack. Such responses can no longer be done by hand, nor can detection be done by hand. We just do not have enough well-trained people or even enough time in the day. Further, if you try to prevent, you need to also have an incident response plan. Prevention only works for things we know; it is the unknowns for which we need an incident response plan.
Data Protection companies need to step up their game and provide early detection of ransomware.
Do you have a ransomware incident response plan? Or an automated ransomware detection mechanism? Or even qualified data archival?