How do we plan recovery from a destructive cyberattack, and how is it different from disaster recovery?

Start

You are planning how critical services return after an attack

Classic disaster recovery fails over to the second site, restores last night's backup and carries on. A destructive attack breaks that: replication copies the damage to the second site, the attacker may have been inside for weeks before the encryption, and the sign-in directory and administrator accounts you would recover with may be the attacker's. The plan has to work when none of the usual tools can be trusted.

• Then: Does the plan assume the second site, backups and accounts are sound?

Decision

Does the plan assume the second site, backups and accounts are sound?

Read the current plan for what it relies on. Failing over to a replica, restoring the newest backup or signing in with the usual administrator accounts all assume the attacker never touched them. If the plan relies on any of these, or you cannot tell, answer yes.

• Yes, or not known: Add the cyber case: production, replicas and accounts untrusted
• No, it already covers an attack: Confirm critical services, owners and agreed objectives

Step

Add the cyber case: production, replicas and accounts untrusted

Keep the technical-failure plan and add the destructive-attack case beside it. Assume production, its replicas and its administrator accounts may not be trusted. Counting failover to a second site as cyber recovery is the usual mistake: replication copies the damage. Recovery then starts from the foundations, rebuilt from sources you can trust.

• Then: Confirm critical services, owners and agreed objectives

Step

Confirm critical services, owners and agreed objectives

A critical service is a business service, such as online ordering, whose disruption beyond its maximum tolerable downtime would cause Severe harm on the risk register's scale. Each has a business owner who agrees its recovery time and recovery point; IT proposes what is achievable. The list and objectives are approved by the board or a committee it delegates to, the management board in a two-tier structure, or executive management where there is no board.

• Then: Record each service's dependencies, foundations included

Step

Record each service's dependencies, foundations included

List the systems, suppliers, data, people and sites each service needs, and link every service whose systems you restore yourself to the foundations: the sign-in directory, core network and firewalls, backup platform, endpoint protection and monitoring, and emergency administrator accounts. Record who restores each system after an attack and each recovery time with its basis: tested, contract or estimate.

• Then: Work out each service's cyber recovery time

Step

Work out each service's cyber recovery time

The cyber recovery time is the foundations' rebuild, if the service depends on them, plus the slowest system you restore yourself. Suppliers recover in parallel and are checked against their contracts. Every service then has two times. In the pack's example, dispatch was restored in 5 hours in a test onto trusted systems, and would need 17 hours after an attack: 12 hours for the foundations, then its own 5.

• Then: Is the cyber recovery time within the service's recovery time?

Decision

Is the cyber recovery time within the service's recovery time?

Compare it with the recovery time objective and with the maximum tolerable downtime. Within the objective, the plan holds after an attack. Beyond it but within the maximum, the service can survive only on its workaround. Beyond the maximum, it cannot recover in time, and it still needs a workaround to limit the harm. If you have no figure for the foundations or a system, answer no until you do.

• Yes, within the recovery time: Set the recovery order: foundations first, then by recovery time
• No, or not known: Agree a workaround that keeps the harm below Severe

Step

Agree a workaround that keeps the harm below Severe

The business owner records how the service runs without its systems, for how long, and who starts it, such as dispatch from printed pick lists. A workaround that relies on a system the attack also takes down is no workaround. One that has never been tried is recorded as untried, and nobody should rely on it until it has been.

• Then: Record the shortfall as an objective gap with an owner

Step

Record the shortfall as an objective gap with an owner

A failed check is an objective gap. Its owner agrees the change that closes it, with a due date, within 10 working days by the pack's default, and the service's risk owner is told so the risk is reassessed. Readiness reports to executive management and to your approver name every gap, including any service that would be back only after its maximum tolerable downtime.

• Then: Set the recovery order: foundations first, then by recovery time

Step

Set the recovery order: foundations first, then by recovery time

Nothing can be trusted until the sign-in directory, the network and the backup platform are. Restore the foundations first, then critical services in order of recovery time, shortest first, unless the crisis lead sets another order and records why. Set the order and target times now, in calm; the crisis lead confirms them when recovery starts.

• Then: Prepare the isolated recovery environment and build sources

Step

Prepare the isolated recovery environment and build sources

Rebuilding beside infected systems, or with accounts the attacker knows, invites a second attack. Decide now where the isolated recovery environment runs: no network path to production, its own new administrator accounts, no trust to the production directory. List each trusted image, baseline and installer, where it is kept out of reach of production administrators, and its recorded hash.

• Then: Could production admin credentials change or delete every backup copy?

Decision

Could production admin credentials change or delete every backup copy?

Attackers look for the backups first. At least one copy of each critical data set must be beyond the reach of production administrator credentials, and each must be backed up at least as often as its service's recovery point. If every copy can be reached that way, or you do not know, answer yes.

• Yes, or not known: Add a copy production admin credentials cannot change or delete
• No, one copy is out of reach: Write the restore, recovery point and return rules into each plan

Step

Add a copy production admin credentials cannot change or delete

Add a copy of each critical data set that production administrator credentials cannot change or delete. Keep copies far enough back to survive an attacker who was inside for weeks; the Backup & Restore Assurance pack's retention rule sets how long. Until that copy exists, a clean recovery point may not survive an attack, so raise the shortfall in your own risk process.

• Then: Write the restore, recovery point and return rules into each plan

Step

Write the restore, recovery point and return rules into each plan

For each system, record a planned route and build source for both restore and rebuild, since the incident manager decides on the day. State how the recovery point is chosen: the newest copy from before the earliest sign of the attacker, checked and scanned. List the gates a system passes before it returns, and the business owner's test.

• Then: Write down how the sign-in directory will be rebuilt

Step

Write down how the sign-in directory will be rebuilt

Most destructive attacks reach the directory, because administrator rights there open every other system. Record the route you will take, a new directory or a cleaned copy from before the attacker, how long it takes and who can do it. If a managed IT provider runs it, agree in advance that it rebuilds with new accounts from clean devices.

• Then: Name roles and deputies, and keep the plan reachable offline

Step

Name roles and deputies, and keep the plan reachable offline

The crisis lead invokes plans, sets the order and declares the end of recovery; every incident decision stays where the incident plan puts it. Only the board or its equivalent decides on a ransom: the board, the management board in a two-tier structure, or executive management or the owners where there is no board. Every role has a named deputy. Keep printed and offline copies of the plan and contact lists: the file share it normally lives on may be encrypted.

• Then: Has a recovery test of the service run in the last 12 months?

Decision

Has a recovery test of the service run in the last 12 months?

A recovery test restores the service or its systems and data, and times the result against the objectives. A tabletop exercise tests decisions and restores nothing, so it does not count. By the pack's defaults each service is tested every 12 months, and a service never tested within 6 months of its objectives being agreed. Answer no if you are not sure.

• No, or only a tabletop exercise: Schedule a recovery test and record the service as not proven
• Yes, onto trusted systems only: Plan a cyber recovery test that rebuilds the foundations
• Yes, including the foundations: Keep the plan current: review it yearly and after every test

Outcome

Schedule a recovery test and record the service as not proven

Until it is tested, the objective is a claim nobody has shown can be met. Put the test in your test plan with a date, and report the service as not proven meanwhile. Where you can, run it as a cyber recovery test in the recovery environment, so it measures the foundations too.

Outcome

Plan a cyber recovery test that rebuilds the foundations

A test that restored onto trusted systems measured the test time, not the cyber recovery time. Plan one that rebuilds the foundations in the recovery environment and then the service's systems, without touching production. In the pack's example, dispatch's next test is the first to measure the foundations' 12 hours, an estimate never tested as a whole.

Outcome

Keep the plan current: review it yearly and after every test

The plan holds for a destructive attack as well as a failure. Review it at least every 12 months by the pack's default, after every test or real recovery, and after a significant change, writing the lessons in. Report readiness as counts with every gap named, such as 2 of 5 services restored within objective, never as a score or percentage.