In this week’s bulletin, Charlie gives an insight into the points that should be addressed within a business continuity plan and the importance of including cyber within the plan.

When I am teaching cyber incident management, I always talk about four areas which need to be addressed when responding to a ransomware incident. They are: communications and regulation management, technical response, statutory and regulatory communication, and then continuity of operations. Continuity of operations is key in that your organisation has obligations to its customers and stakeholders and without them being fulfilled, the organisation may fail. Last week when I wrote in the bulletin about the RUSI Report: Ransomware Victim Experience, it mentioned that many people when responding found their existing business continuity plans didn’t really help. This week I thought I would look at ten reasons why your existing business continuity plans (BCPs) may not help during a ransomware event.

1. Has your plan been written specifically with a ransomware response in mind? Very few of the BCPs I have seen have any mention of cyber incidents within their scope or as one of the response issues the plan addresses. Typically, a plan will cover loss of building with the easy strategy of working from home, loss of a supplier, loss of staff, and loss of IT. If cyber is not mentioned, it has probably not been thought about. From the points below, we can see that a cyber attack has many different impacts than a ‘normal’ incident BCPs are written for.
2. Does your BCP recognise that there may be a different structure for managing a cyber incident and show how it fits within that structure when responding to a cyber incident?
3. Absolutely central to responding to a ransomware incident is the requirement to be able to operate processes manually and without IT. Very few BCPs I have seen have any manual workarounds and if they are included, they are not in sufficient detail to be able to actually carry out the activity. In responding to ransomware attacks, you often have no choice but to revert back to analogue operating regimes from 20 years ago, which very few people within the organisation remember. Manual workarounds need to take into account the extra time to conduct them, or the additional people needed to implement them. Now is an opportunity to take the time and note down the manual processes before the skillset is lost. There may be certain processes which you just can’t deliver without IT. If you are an organisation like Deliveroo providing fast food through a platform, there are far too many orders to allow for manual processing, so manual workarounds are not always possible.
4. In many ransomware attacks, the organisation’s primary communications methodology, such as Microsoft products, may be unavailable and alternative methods have to be used. I have very rarely seen this mentioned within business continuity plans. If the hackers are still within the system, they may be able to monitor all communication of those responding, making all communications insecure. BCPs should mention alternative communication methods.
5. In a cyber attack, I suspect that most RTOs will not be met. Most processes are reliant on technology for recovery. In a cyber attack, it is not just as simple as rebooting the IT system and then getting it up and going. Until you guarantee that the attackers are definitely not within the organisation’s systems, the organisation may not want to have the systems live again or connected to a network. Thus, due to the digital forensics, it might take days longer to recover, long after the activity Recovery Time Objectives (RTOs) are set at.
6. In most business continuity plans I see, there are RTOs for applications. Often, these are aspirational as they haven’t been actually confirmed with IT. Sometimes this is due to lack of communications, but often IT departments do not know them due to the lack of testing. In a cyber incident, the quicker the recovery, the more likely that the attackers can encrypt the backups as well, so the application RTO will not be met.
7. In a similar way, backups may be encrypted if they are not gapped. Recovery Point Objectives in BIA are often not designated, not agreed with IT, or may not reflect the gapped backups.
8. Most BCPs anticipate a staged recovery with some applications and activities being up within hours. Cyber incidents like the Scottish Environmental Protection Agency (SEPA), Comhairle Nan Eilean Siar (Western Isles Council), or Hackney Council, have taken months and years to recover, I suspect long after the RTO stated in the BCP.
9. A key component of pre-COVID plans was a list of PCs (mainly) or laptops needed to be recovered at a work area centre. As everyone works from home, these requirements have been lost from plans. In some cyber-attacks, there may be a need for laptops and PCs to be replaced as they might be quicker than reimaging them. If there is not a list of laptops required in a plan, you may want to reconsider putting one in and then discussing with IT where additional laptops might be purchased from, and whose plan this should be in.
10. Your suppliers and partners may not behave in the same way as during a ‘normal’ incident. Often, partners and suppliers may cut off API data flows or blacklist your organisation’s email addresses. This can make communications difficult and may slow down the recovery. Again, this should be considered and discussed in advance.

BCPs can provide a very useful tool in ensuring the continuity of operations after a cyber attack, but I think for BCPs to be effective, they need to be looked at through the lens of a cyber incident and adjusted accordingly.