Cyber-ransomware criminals need to make sure that you cannot simply recover your encrypted data via your backups. They must make it look like paying is your only option. And if you do not have a strategy that takes this into account, unfortunately, you may be up the creek without a paddle. because how do they make their case? Bylooking for ways to infect your backups, way before you find out you have been compromised.
That means your standard disaster recovery scenarios provide insufficient protection against this type of event. You need to think beyond DRP and give consideration to what John Beattie and Michael Shandrowski call "Cyber Incident Recovery Risk management" (CIR-RM).
Companies recognize that they need to work to safeguard their data from cyber attacks. But what exactly does that mean? In practical terms, you need to make sure that your production data is protected against encryption and any other form of alteration; This is about your actual day to day production data, but also your research data. it also also about the intellectual property you built up over perhaps decades of operation. You research data is perhaps not used in day to day operations, but perhaps it is invaluable for upcoming projects or future investments.
When you consider your current disaster recovery scenarios and plans, and even you rcurrent disaster recovey exercises, ask yourself: do these plans, exercises and results cover you in the event of a cyber attack? This article explores what you should be looking at to give yourself the upper hand.
Standard disaster recovery (or even Business Continuity) deals with events that happen suddenly and have a defined impact.
With defined impact I mean things that happen at a certain time and have an effect on a class of assets as of that time.
This typically means that you have an event (the trigger) like an earthquake, a fire, water damage, a bomb or misile attack, or someting simple as a (prolonged) power-outage on a certain datacenter or office.
This type of event, from a disaster recovery standpoint is easy to grasp. the vent happened at point in time x (eg. March 10, 2022, 9:30PM). Therefore impact is from that time. We found out 10 minutes later. management processes too another hour to kick in. To fix it, we need to restore the systems as of the time of impact and then try to reconstruct any business after that. With some good planning, our recovery systems will have kicked in a minute or so after the actual event, Incident Management started the recovery from 9:45PM and we're on our way. If we are really good, the automated failover systems kicekd in at 9:31PM and before we're even notified, we're already running in the DR location, thanks to continuous synchronisation to our hot site.
if you do not recongnize yourself in this scenario, please contact me to see how you can get to that level.
But when you deal with a cyber attack involving ransomware, that scenario will not help you.
Cybersecurity ransomware attacks follow a very different playbook.
The time of effectuation is not when the encryption kicks in and you can no longer get to your data. The real date of infection may be months in the past. That means that you may not be able to restore data fromjust before you notice. The infected files will most likely be present in your backups. And that means that when you restore data (files and databases), you will restore the infection along with it, hence the hacker can simply reactivate the encryption algorithms, or the algorithims will auto execute based on the current date or something similar.
Worse, the backup themselves may have been encrypted as well, making restoration impossible. If you think this is too far-fetched, think about the business case. If the backup is easily accessible, why would you pay? Exactly! You wouldn't. The the modus operandi of such a hacker is:
This shows why traditional Disaster Recovery methods do not protect you, and neither do standard backup policies.
From here it follows that your standard Return Time Objectives (RTO - How fast will you be back up and running) and Return Point Objectives (RPO - What is the maximum data loss you are willing to endure), nor your Maximum Outage Time (MOT) will be met.
When you think about it, your recent backups and all the replicatioyou put in place are useless.
I know this is not what you want to hear, but it is reality. All the replication and "High-Availabilty" your put in place is useless against these attacks.
Why? Because any encryption they effect to your main site is immediately replicated to the high Availability site; As in "micro seconds."
Let's take a step back here.
You need to ensure that your backups are secured, Yes, but also means that you can restore to a separate system and then do additional checks on the files.
Typical IT Ops personnel are told to ensure the continuity of systems when sudden catastrophic events occur. In the case of "normal"
Stay tuned to receive updates to this article.