How do we choose which backup to restore from after a cyberattack?

Start

A system's data must be restored after a cyberattack

The newest backup is often the wrong one. Attackers are often inside for days or weeks before they encrypt, and a copy taken after they arrived may hold their tools, their accounts or data they changed. Restoring last night's copy after ransomware is the classic mistake. Ask this for each data set of each system.

• Then: Get the earliest sign of the attacker, not the encryption time

Step

Get the earliest sign of the attacker, not the encryption time

The earliest sign is the earliest time the investigation has found the attacker active on this system or anything that could reach it, such as a new administrator account or a first remote session. Record it with its source and who found it. It can move earlier as the investigation learns more, so ask again at every update.

• Then: List every copy with when it was taken and where it is held

Step

List every copy with when it was taken and where it is held

For each data set the service needs, list the copies available: the date and time each was taken, and where it is held. Mark which were taken before the earliest sign. Include copies that production administrator credentials cannot change or delete; those are the ones most likely to have survived.

• Then: Check each candidate's integrity and scan it in isolation

Step

Check each candidate's integrity and scan it in isolation

Check the integrity of each candidate copy before it is restored, and scan it for malware and this attack's indicators inside the isolated recovery environment, never on the production network. Something the attacker placed before anyone noticed can sit in a copy from before the earliest sign. A copy the attacker could have reached is never restored without both checks.

• Then: Did any copy from before the earliest sign pass both checks?

Decision

Did any copy from before the earliest sign pass both checks?

A usable copy was taken before the earliest sign, passed its integrity check and scanned clean. A copy that passed both checks but was taken after the earliest sign is still not used: the attacker was already inside. If you are not sure a copy predates the attacker, it does not count. If the checks have not finished, the answer is not yet known.

• Yes: Choose the newest of those copies as the recovery point
• No, none passed: Rebuild and recover the data from other sources; tell the crisis lead
• Not yet known: Restore nothing until the checks finish

Outcome

Rebuild and recover the data from other sources; tell the crisis lead

With no usable copy, rebuild the system from a trusted source and recover its data from wherever else it exists: suppliers, customers' confirmations, emails, paper. Tell the crisis lead at once: the service will take longer and the recovery order may change.

Step

Restore nothing until the checks finish

Until each candidate copy has been checked and scanned, nothing is restored from it. The incident response plan's rule is plain: never restore from a copy the attacker could have reached without checking it. When the checks finish, ask the question again.

• Then: Did any copy from before the earliest sign pass both checks? (back to an earlier step)

Step

Choose the newest of those copies as the recovery point

Of the copies taken before the earliest sign that passed both checks, choose the newest. The technical recovery lead recommends and the incident manager decides. Record the copy's date and time beside the earliest sign, with who decided: that is the evidence the clean-room checklist asks for. In the pack's illustration, last night's copy passed both checks and was still not used.

• Then: Has eradication been confirmed for this system?

Decision

Has eradication been confirmed for this system?

No system is restored before eradication is confirmed to the incident manager for it: the way in closed, what the attacker left removed, credentials reset and the weakness patched, with no new attacker activity since containment. A system restored onto a network the attacker still holds is lost again. If confirmation has not come, answer no.

• Yes, confirmed: Restore it in the recovery environment onto the prepared system
• No, or not yet: Hold the restore; recheck the earliest sign at each update

Step

Hold the restore; recheck the earliest sign at each update

Keep the chosen copy ready and restore nothing. While eradication continues, ask the investigation at each update whether it has found an earlier sign, and choose again if it has. Then ask again whether eradication is confirmed.

• Then: Has eradication been confirmed for this system? (back to an earlier step)

Step

Restore it in the recovery environment onto the prepared system

Restore the chosen copy inside the isolated recovery environment, onto the system rebuilt or patched as the incident manager decided. Check its integrity again and scan the restored data before anything else connects to it.

• Then: Has the investigation since found an earlier sign of the attacker?

Decision

Has the investigation since found an earlier sign of the attacker?

The earliest sign moves when the investigation finds older activity, such as a first remote session days before the alert. A copy that was before the old sign may be after the new one. If it is, the restored system may hold what the attacker placed. In the pack's illustration, an earlier sign moved the recovery point back a day and the data lost from 74 to 98 hours.

• Yes: Choose again; the restored system goes back to be rebuilt
• No: Record the data lost and name who recovers it

Step

Choose again; the restored system goes back to be rebuilt

Run the choice again against the new earliest sign. A system restored from a copy now after the earliest sign goes back to the rebuild stage. That is the price of a clean restore: more data lost, recovered from other sources.

• Then: Did any copy from before the earliest sign pass both checks? (back to an earlier step)

Step

Record the data lost and name who recovers it

The data lost is the time from the recovery point to when the system stopped or was isolated. Record it beside the recovery point objective. The business owner names who recovers what was lost, and from where: suppliers' records, customers' confirmations, emails, paper, a stock count.

• Then: Is the data lost within the recovery point objective?

Decision

Is the data lost within the recovery point objective?

A clean restore often loses more than the objective allows, because the recovery point falls before the attacker arrived, not before the encryption. That is still the right copy. Compare the hours lost with the objective the business owner agreed.

• No, more was lost: Raise an objective gap for the excess loss
• Yes: Reconcile the restored data with its other sources

Step

Raise an objective gap for the excess loss

A loss larger than the objective is an objective gap at stand-down, even when it came from a clean restore. Its owner agrees the change that closes it within 10 working days by the pack's default, with a due date, and the service's risk owner is told so the risk is reassessed. Which change closes it is for the owner and the business to decide.

• Then: Reconcile the restored data with its other sources

Step

Reconcile the restored data with its other sources

A restore can be clean and still wrong: orders taken after the recovery point, payments with no order, stock that left on a paper pick list. Compare the restored data with each source outside the system, explain every difference, and record what was entered again and by whom.

• Then: Go on to validation and the checks before reconnection

Outcome

Go on to validation and the checks before reconnection

The data is back from a copy you can defend. The system now passes the sweep for persistence, the business owner's test and the incident plan's recovery criteria before it reconnects in stages. Its own backups must run and be checked once it returns, so there is a clean copy if the attacker comes back.