Ransomware attacks continue to impact organizations and are increasing at an alarming rate - this is old news.
But what if I were to tell you, ransomware isn't your problem?
Remember - ransomware is malware with a specific payload (encrypt your data). Malware has been an issue far longer than the specific payload of a ransomware module. Solve the malware problem - solve the ransomware problem.
OK - so what can we do to solve the problem? Well, more than likely it's multiple things.
- Last I read over 92% of breaches investigated start with a phishing e-mail. If you're not inspecting and blocking e-mails with malicious attachments or links, that's problem #1. But remember, a Targeted Attack is most likely NOT going to show up in your threat intelligence database. For phishing e-mails using URLs, you might want to consider taking action against recently registered domains as well. For e-mails with attachments, consider adopting a general policy to block (or quarantine) any executable, documents with embedded macros or scripts, and password protected archive files. Doing this will help, but still isn't a silver bullet.
- The ransomware made it to the end-user's workstation. Are you utilizing EDR capabilities to inspect the file that do not rely on signature-based technologies? Don't let a file sit dormant (because you never know if the end-user is going to forward that file to someone that doesn't have proper protections). OK - so the ransomware evaded the initial scan...now what?
- The end-user attempts to open the file, not knowing it's actually ransomware... Does your endpoint protection policy permit execution of unsigned binaries? Does your policy permit execution of files from uncommon locations or within the end-user's own directory structure (most end-users do NOT need to do this). Do you have a list of trusted signers and only those are permitted to be executed? Does your solution conduct a pre-execution analysis to determine behavioral execution patterns in the code before allowing the code to actually run? Does your endpoint solution deploy decoy files and terminate offending processes attempting to alter them? If this still hasn't stopped the ransomware from executing...what else can you do?
- Pretty much every ransomware (and malware) module I've seen will attempt to elevate privilege so that it can conduct unrestricted activity. Does your organization issue workstations where the end-user has local administration privilege? If so, you're giving the malware an easy path to success. Instead, issue workstations with TWO accounts for the end-user. The first, a normal user account that is used for all primary work activities. The second (if you will actually permit them to conduct local admin actions), is the account with local admin rights. That account is rarely (if ever) directly logged into...instead, when the normal user initiates an action that requires admin rights, the consent process intercepts and pops up a request for the user to enter the admin account credentials. If the user did something that requires it, they enter the credentials; otherwise, it's hands off the keyboard and contact the security team for assistance!
- Ransomware will attempt to propagate to other endpoints. For example, TeslaCrypt will attempt to mount the administrative share of any other system on the local network. Are you implementing host-based firewall rules that restrict workstation -> workstation communications? End-user workstations should have a very limited field of fire when it comes to connecting to internal systems. Even if the ransomware successfully detonates on one end-user's workstation, you can limit the damage by implementing both outbound and inbound host-based rules, disabling network shares, and restricting commonly abused protocols such as RDP to only permit administrative jump systems access.
- The ransomware detonated and encrypted the endpoint. Did you implement volume shadow copy for quick restoration via a saved snapshot? First, if you didn't implement #4 above and the ransomware was able to elevate to local admin, chances are it deleted your volume snapshots (I see nearly every sample attempt to do this). However, if it did not whack the snapshots, it is a very quick and easy process to restore to the previous snapshot and the end-user will only lose changes made since that snapshot was taken (so for end-users, at least daily is recommended).
- Are your datastores only permitting approved processes and systems to access them? Ensuring both your network AND endpoint policies restrict who and what can access the datastores will help ensure ransomware cannot impact mission critical operations. And if you haven't tested your backups and rollback/recovery capabilities - it's time to do so.
By now you are hopefully thinking that what I've just laid out doesn't just help solve the ransomware problem - and that's my entire point. Implementing Zero Trust approaches such as those outlined above are best practices in solving a multitude of security headaches.
So utilize what I Call The Magnificent Seven steps to helping organizations solve their security issues. Less headaches and sleepless nights will occur!