Ransomware attacks are now big business. Gone are the days of encrypting your grandparents photos with decryption keys costing a couple hundred bucks. Gangs are now coming for your corporate data, your backups, and demanding millions.
You therefore need to demand more from your backup platform because they are coming for that first.
Not only should it be natively built to keep the attackers out (to deny their payday), it must have integrated anomaly and ransomware detection. It’s not good enough for your last line of defense to provide no assistance in what is now the most likely disaster event, a ransomware attack.
It should do the analysis within your primary backup cluster to ensure the attack is detected as soon as possible, and you shouldn’t have to buy a 3rd set of everything, wait for replication, or have to manage a separate software stack to get it.
With legacy backup, in an attack your last line of defense will leave you flying blind. You’ll have no clue what was infected where and will have to recover everything, losing good data and increasing recovery time.
Radar uses ML to detect anomalous events in your Rubrik backup sets. Once detected it then analyzes the changes against the last backup to detect if a ransomware attacked has actually occurred, and because it’s looking at the files themselves, it can’t miss a 0 day attack like a signature based detection tool can. This is continuously running in your backup cluster, automatically after each backup, no software to install, using spare compute.
This is why Radar shouldn’t be a “we might add that later feature”, you need to ensure this capability is licensed and turned-on day 1. With Radar you’ll not only get alerts and email notifications for every anomaly event, but it will also tell you with a low, medium, or high confidence if it found a ransomware infection and exactly which files were encrypted:
Radar then layers on multiple recovery workflows to minimize RTO:
This is why you need Radar yesterday. Your last line of defense will now find the infection and tell you which systems and files were infected, then help you recover them:
But, all this functionality is provided in a Rubrik UI or via email alert. How do you programmatically query these alerts to integrate them into a SIEM tool or custom alert workflow?
This is where a pre-built example script can help you hit the ground running, and that’s exactly I’ve built for you, ready to download from the link below:
The script is written in PowerShell, validated with Rubrik Polaris on 12/15/20 using PS versions 5.1, 6.0 and 7.1 on Windows 10 and Ubuntu 16.04. So yes, you can run this on Linux too!
Extract the zip file, configure the $PolarisURL, $ScriptDirectory and $CSVDirectory variables to match your Polaris instance and directories then give it a run. You’ll be prompted for your Polaris credentials (which has to be a local Polaris user, the script doesn’t support SSO) which are then encrypted and saved for subsequent headless runs. Once run, you’ll see the following:
I’m outputting the data into a CSV so you can see the data returned, but you can take this and import it, or remove this step altogether and integrate it directly into your SIEM using the same script.
If you have a REST API on your SIEM tooling and you’d like help importing the data then I’d like to work with you so we can share the example back with other readers. Hang on the page for the Drift chat prompt to appear, put in your email, share your use case and I’ll be in touch.
I also included a recovery plan creation feature in the example script, disabled by default, which creates a ready to run CSV of VMs for each Rubrik cluster with pre-configured recovery options. Importantly, each VM has the ID of the last clean snapshot to ensure a clean recovery. Watch this space because I’ll soon be integrating the capability into my Recovery Plan scripts and I’ll link it back here when done.
If you found this useful please like, share, comment. Happy scripting,