It’s all well and good thinking about protecting, detecting, and responding to an incident – but what is the point if you cannot recover? The consideration for ‘recovery’ is always last, but it’s a classic ‘chicken and egg dilemma’ as you could get some valuable benefits from prioritising it now. Read on for six key cyber recovery considerations.

If you can stop the ship from sinking, you don’t need lifeboats

You’ve spent most of your budget on protection and detection functions. You’ve tested how you would detect an incident and kick off incident response, but have you considered through to instantiating recovery and getting yourself back on your feet afterwards? We all know no defensive barrier is 100% secure, so assuming a breach will happen at some point, you need to know that your business can recover control of its systems and data and restart operations as soon as possible after an attack.

Unfortunately, the cybersecurity frameworks we all turn to for best-practice guidance share a fundamental flaw: the consideration for ‘recovery’ is always last. It’s resulted in many organisations finding themselves in an incident before they know it and being forced to build that recovery function on the fly.

Planning for cyber recovery is vital

You could get some valuable benefits (besides the obvious) out of prioritising cyber recovery now. At a minimum, you will have improved confidence in running and recovering from an incident. And, actually demonstrating how you would do this is an instrumental perspective for managing your public relations and external comms.

We can all think of a horror story where a CISO or executive has had to go to press with a poorly thought-out message about what’s happened with their cyber security incident. The ability to illustrate how you are in control will significantly improve your credibility and stakeholders’ understanding, and ultimately go a long way to protect your reputation.

Through recovery planning, you work out how you can run different elements of your business, even when other bits are cut off, maintaining those core business lines or funding avenues. Being able to demonstrate this to your insurance provider translates to lower insurance premiums because they have confidence the impacts of an incident are going to be minimised. So you’re less likely to come to them with a hefty bill that you’re looking for them to help you meet.

Six key cyber recovery considerations

1. At any given time during incident response, you need to question, are the bad actors still present on the network?

Because if they are, there is little point trying to bring yourself back online; everything you try and fix will get broken again behind you. Recovery cannot start until you know the incident is contained, threat actors have been removed, it’s confirmed they have no further access, and the damage is ascertained.

2. Think about what can affect your recovery.

For example, you need to rebuild a whole bunch of computer systems, but the file store containing the privileged credentials required to do so has been affected by the incident. Without those available, you can’t start a recovery. Or what about protecting your gold images; this is vital to ensure that when you start to rebuild things, you’re building them with clean versions and not tampered or damaged versions.

3. Give some thought to how you might run your incident away from your current IT environment.

Remember, if you’ve got a threat actor on the network, they might have access to the way that you are managing your incident. If you use Microsoft Teams (or Zoom etc.), they might have access and be able to see the artefacts you’re creating. So a safe place to discuss the incident and share artefacts is crucial.

4. Consider the crucial parts of your environment needed to maintain a minimum viable business and understand your critical systems and interconnections of those systems.

This will help avoid reaching a survivability compromise where even if you manage to recover now, it’s too late, and the business now can’t bounce back. Bear in mind that your people and their end-user computing are significant because you can do quite a lot as long as you can talk to each other. As you go through this thought process, you will probably discover some home truths about how much you are backing up, and whether you have prioritised backups based on the true priority of your organisation.

5. Dedicate a responder to prepare and update stakeholders during the incident response and recovery process.

When you are in the thick of it, multiple concurrent requests for updates will bowl you over. Plan for this and assign a communications officer role within your incident team and keep them in the loop so they can summarise the progress. It helps to have someone with good communications skills who gets cyber, but also has some diplomacy and an eye for what level of bleeding-edge information will be required to satiate the crowds. Also, it’s important to remember not everyone needs an update, even though they might ask for one. Planning out a stakeholder map and sharing this will mean you can legitimately manage the number of requests and create a synchronised update to all “required” parties. Managing them directly will likely stave off the ad-hoc requests.

6. Practice your cyber recovery, then practice again.

But most importantly, when testing your recovery, execute the plan all the way through. Don’t just stop at the first base and say “we’re just going to recover everything, and it will be fine”. The more you practice going through an end-to-end incident recovery journey, the fewer surprises you will find and the more muscle memory you’re likely to build. You should be doing something significant annually with smaller quarterly tests. It’s important to recognise that your IT environment and the threat landscape will change over time, and each activity is an opportunity to do a health check-up and learn.

There are things you can do now, don’t wait until there’s an incident before you learn how to manage it. Review your current controls now and the preparations behind it. Document what you’ve got (including the cloud) and what you would do to affect a recovery. Practice your response and recovery steps and prove that you can recover.