Business continuity and disaster recovery - part 2 (7.1.2 - 7.1.4)

You can expand an all-encompassing business continuity plan to include data security content, alternatively expand your IT disaster recovery plan. However, where possible we would recommend you have a separate data security incident plan.

Whichever route you choose, data security should be included in any plan, even those not related to cyber incidents. For example, where a restored system that may have the full of access control not being in situ.

Generally, this is for smaller organisations that already have an all-encompassing business continuity plan. You should include sections on data security including what to do, what to avoid and scenarios. A smaller organisation business continuity plan (a generalised version of the pharmacy business continuity plan is contained in full in Useful resources.

Generally, this is for organisations that have an existing IT disaster recovery plan. The team responsible is a small set of people who would respond to data security incidents as well as the more traditional IT ones. This approach can be useful in dealing with an incident where the initial cause may not be known, such as network problem that could be caused by faulty equipment or a denial of service attack.

It is important data security is featured as prominently as the more traditional causes of incidents and includes as a minimum what to do, what to avoid and scenarios.

Good practice guidelines for business and IT security plans are referenced in Useful resources.

A set of suggested scenarios for data security testing are contained in Useful resources.

For organisations with granularity of roles and sufficient size, we would recommend a separate data security incident plan.

This will allow you to really focus on data security incidents, the actors, attack surface, basic and sophisticated attacks, the phases of the attack and the response.

There are 2 examples in Useful resources:

• the Cyber Security Incident Response Guide by Crest (The Council for Registered Ethical Security Testers)
• the Computer Security Incident Handling Guide by National Institute of Standards and Technology (NIST) U.S. Department of Commerce

Whilst both examples are very useful, it is important to note the CREST document is written from a point of view of those wishing to augment their data security response with external help. The NIST guidance in parts can be quite US centric.

The length of time it takes to resolve an incident can be prolonged by a lack of knowledge of the resources needed and their availability. This can be compounded by treating each incident in isolation and in a bespoke way rather than using lessons learned and shared resources.

The resources can be people and one widely used method is to formally set up an incident response team. This will generally be a multidisciplinary IT team which can tackle a range of incidents ranging from hardware/network failure to a large-scale malware outbreak.

It can be obvious when you need data security and protection resources to tackle a malware outbreak as it is seen as cyber issue. However, some issues not readily seen as data security and protection due to their nature e.g. server hardware failure, could bring about data security and protection challenges in their resolution.

For example, when commissioning a new server to replace the failed one, the understandable emphasis is to return the service back online with expediency and perhaps take a few short cuts (such as minimum patching, hardening and open file rights). Or it may be tempting to temporarily store file shares in the cloud during remediation, however no assessment may have been made of any legal data protection and contractual obligations before doing so. 

Just like any repair, having the right physical and digital tools at your disposal in a timely fashion can make all the difference. Having a 'grab bag' containing items such as switch, networks, diagnostic laptop (with server/network analysis software), USB drives with boot diagnostic software can be useful.

Careful consideration on how many grab bags are required and where they should be located, for example by storing them all on your main site which may have restricted access during an emergency would not be wise.

Public cloud can be a very useful resource (given its high availability and location independence) for machine images, restoration data and diagnostic software.

Whatever method you use to store your restoration resources, remember it is important that you are licensed for the software, that any data stored is secured and processed in a safe manner and that it is as up to date as it needs to be.

You should be horizon scanning via the NHS Cyber alerts portal, the Cyber Associates Network (CAN) and other sources in order to make temporary changes to your security posture.

For example, a developing situation with a widespread convincing phishing campaign that delivers a highly disruptive piece of malware could temporarily trigger

• a targeted awareness campaign
• a temporary freeze on optional updating
• blocking certain categories of websites
• elevated rights being restricted to a small cohort
• certain network segments with at risk systems (medical devices etc) being completely separated from the corporate network

Once the event has passed these, more draconian measures would be repelled.