Business continuity and disaster recovery - part 4 (7.3.1 - 7.3.6)

Data security incidents when discovered can be daunting and it can be tempting to implement blanket controls. Your immediate response can either help remediate or worsen the situation.

It is important that you engage with NHS England (for an NHS body) or a Cyber Incident Response company where appropriate. They will have experience and a pool of resources to assist you.

In the event of invoking the plan, it's essential that team members can be contacted and assemble the response team.

Therefore, there is a mandate that a hard copy of the contacts for the response team is kept securely and kept up to date. It is important that it is also known when it was last updated and printed.

Consideration should be given to where the copy of the contact list is located, especially in a scenario that affects access to the site (meaning the same list used for IT disaster recovery).

The contact list should be reviewed and updated at intervals. When updated the contact list should be reprinted.

It is recognised that not every incident will require accessing a 'last resort' hardcopy contact list. Storing on a source outside your network (such as NHSmail or Cloud) which is accessed from any device can seem attractive. You will need to ensure the location and security of the service is compatible with trust and national guidance. However, digital storage should be additional and not a replacement for hard copy storage.

A draft press statement should be drawn up in conjunction with your communications team to speed up the press response and ensure consistency.

There is a commercial sector link on how to handle the media following a cyber-attack in Useful resources. This provides some key points to consider when crafting skeleton statements.

These should be reviewed and updated on a regular basis.

With traditional on-premises servers, there is a classical model of backup to an offline device/media (generally tape) using a backup technique with full/ incremental backup cycles such and grandfather-father-son rotation.

This ensured you go back to multiple points in time to restore your data and thus providing redundancy if your latest backup was corrupt.

Move forward to the cloud online world and with near 100% uptime with replication between multiple locations availability and therefore backups are seen as entirely the cloud provider’s responsibility.

However, it is entirely possible for the cloud provider to have 100% uptime with your critical data being up to date and replicated but you are not able to access it.

This can happen where ransomware can encrypt not only the physically connected drives but also network drives that can be cloud hosted.

This can lead to a situation where your critical data is encrypted and this is replicated in real time to all the instances of that data. Not having any other copies of the data and being entirely reliant on the cloud provider.

Backing up to a different source has been a standard method of recovery for decades. However, when needed during an incident some organisations have found that restoring a backup has proven difficult and this has prolonged the time to return to business as usual.

This can be for a variety of reasons including:

• overused or old media
• corrupt catalogue
• bad image files
• multiple complex restores required - full and then a large number of incremental
• backup didn’t occur or backed up the wrong system
• nowhere to store the restore
• networked disk-based storage being unavailable due to the nature of the incident

For all these reasons and more, it is important that you can have confidence in the recovery of essential service through testing, documenting and routinely reviewing.

The testing should be representative of the service or system in focus and not based on routine smaller scale requests or an old live incident. For example, a routine restore of single mailbox for a returning member of staff would not be considered as enough confidence to restore a whole email system.

Whether to use live or test systems should be determined on risk and whether the test system is sufficiently representative of the live system to make the testing valid.

Just as important as the tests themselves is documenting how to restore the system as well as any issues found during the test and the plan to rectify them.

The testing frequency should be routinely periodic especially after any major change in the system or service.

Nothing to do with an 80s gameshow but a technique to keep your data safe meaning have at least 3 copies, on 2 devices, and 1 offsite

See the NCSC blog post Offline backups in an online world.