Let’s start with processes
When I worked for BHP Information Technology in the 90s, there were travel policies that pretty much forbade more than 50% of an IT team (e.g., Unix System Administration for a region) from travelling with one another. At least, that’s what the general conversation around the office was. I travelled very rarely for my work back then so it wasn’t something I had to go into in great detail.
Sensible businesses will be cautious about staff travel arrangements: the net concern of course is – what happens if the plane falls out of the sky? (Or more prosaically, everyone in the team is in a car-accident on the way back from lunch?)
One of the defences against all your staff simultaneously being incapacitated of course is decent and accurate system documentation. An adage I used to use in consulting was:
Systems should be as simple as possible, but no simpler.
(Of course, this borrows heavily from Einstein.)
If you’re not familiar with the adage in terms of systems design and infrastructure, it refers to managing the risk of ‘surprise’. That is, you don’t design an enterprise data protection environment so simply that a receptionist could be brought in from a temp pool and asked to run the solution1. But, ideally, someone who has adequate skills and training should be able to familiarise themselves with the environment relatively quickly and use it without fear of surprise. Particularly if they can read or at least skim your documentation first.
Documentation. It all comes down to documentation.
So what does this have to do with recovery processes and Cyber Vaults? Quite a lot.
So why do Cyber Vaults need Recovery Processes?
Recovery from a Cyberattack is not a normal process. I’ll use some Australian vernacular here: the sh*t has hit the fan. The scenarios where you might need to invoke a recovery from Cyberattack include:
- Significant crypto-locker infection
- Industrial sabotage
- Organised crime attack
- Hactivist attack
- Insider attack
- Supply-chain attack
- Nation-state attack
You’ll note that an insider attack is mentioned explicitly up there, but that can be a vector for several of the others: sabotage, organised crime, hactivism and even nation-state.
So what’s so important about documentation?
It’s a horrible thing to have to face, but one of the consequences you have to consider in a sophisticated Cyberattack is that your window of trust for people could close significantly.
Or to put it another way: you may have to start a Cyber recovery process by sacking or suspending every person who would normally be involved in the very recovery required. I know, that sounds dire! But not all Cyberattacks will be as simple as Derek downloaded a Cryptolocker when he thought he was downloading Minesweeper.
Now, I’m not suggesting that’s going to be your default posture to every Cyberattack. But if you can’t trust your system, infrastructure or application administrators when you’re under attack, that represents a tangible challenge for recovery.
If you’re a larger business, you could have staff in other regions that could do the recovery. If you’re a smaller company though, you might need to be pulling in a short term contractor or temp administrator to assist. And guess what either of those people would need? Processes and documentation.
Cyber recovery processes shouldn’t be all bad news
I love writing documentation. However, I know I’m an outlier compared to a lot of IT people.
The important thing to keep in mind is that writing cyber recovery processes shouldn’t be a case of boiling the ocean. If you’ve already got established business continuity processes, you should have disaster recovery plans for the different systems and workloads you’re using. If that’s the case, cyber recovery processes should be an extension of these, rather than having to start from scratch.
I can’t recover because I need to recover the recovery instructions
Within business continuity there’s a requirement to plan around bootstrapping the organisation. What do you do if all the documentation is lost?
Back in the 90s, again, we had a fireproof safe that contained hard-copies of critical passwords, system build documentation, and so on. NetWorker bootstrap reports would be printed and sent off-site with tapes. When I started consulting, Google Mail was a godsend, because IT departments got the idea of having a Gmail account that received and held the ‘offsite’ copies of configuration reports.
Security, obviously, has come a long way since then. We have a plethora of tools at our disposal, and cloud-based information vaults can help. If you’re setting up a properly secured, physical cyber vault, you might even store a copy of critical processes in there – so long as you manage the security of updating documentation without putting the vault at risk, of course.
Cyber Vaults Are Business Continuity
A key message to take away from this is that a Cyber Vault isn’t a disaster recovery system, and nor is it a regular recovery system. It’s going to be part of your business continuity system, and that means you have to think of all those business continuity caveats you normally wouldn’t consider, such as: what happens if you can’t rely on your people to do the recovery?
Documentation.