Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If ransomware has encrypted production, do we restore or rebuild?

5 decision pointsThe pack behind this answer: Security Incident Management

Add to board memo

The short answer

Recommendation
Decide system by system, after containment, with the backups protected and the way in closed. Restore data onto the patched system only where you know the route in and every change and the attacker had no administrator rights there; otherwise rebuild from a trusted source and restore only data.
Reasoning
Attackers usually gain administrator rights and go for the backups before they encrypt, so restoring straight away can bring them back. A copy is safe only if it dates from before the earliest sign of the attacker and passes an integrity check and a scan. A restore onto a system the attacker may still control is the costliest mistake in a cyber recovery, so an open question counts as no. Plan recovery as if nothing will be paid.
Considerations
  • The steps and defaults are those of the CISO Times ransomware playbook and resilience pack, such as a 2-hour quiet period before containment is confirmed and 7 days of closer monitoring for Severity 1 and 2. Your own playbook may set different ones.
  • If no backup copy is intact and clean, rebuild and recover data from other sources, and tell the executive incident lead at once: recovery takes longer.
  • Where the attacker had administrator rights, rebuild every system it controlled, starting with the sign-in directory. After a destructive attack, rebuild in an isolated recovery environment with new administrator accounts.
  • A patch is not proof the attacker has gone. Each system reconnects only when the recovery criteria are met and its owner has confirmed in writing that it works.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartRansomware has encrypted production systemsStepStop backup jobs and protect the backupsDecisionCould isolation stop safety-critical or essential operations?StepContain least disruptive first; bring in the operations ownersStepIsolate affected devices, and the site if it may spreadDecisionIs it still spreading?StepWiden the isolation and ask for outside help if neededStepPreserve evidence before anything is wipedStepPlan recovery as if nothing will be paidStepClose the way in and remove what the attacker leftStepAgree the restore order: foundations firstDecisionAre the backups intact and clean?StepDo not restore until the backups are checkedStepRebuild from clean images; recover data from other sourcesDecisionFor this system, do you know the route in and every change?StepRestore data onto the patched system and check itStepRebuild from a clean image, then restore only dataDecisionAre the recovery criteria met for this system?OutcomeKeep it disconnected until the gap is closedOutcomeReconnect in stages under closer monitoring

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 20 steps.

  1. Start

    Ransomware has encrypted production systems

    By the time a ransom note appears, assume the attacker has been inside for some time, may still be, and may have taken data. Ransomware is usually the last stage of an attack: before encrypting, attackers typically gain administrator rights, spread and try to delete or encrypt the backups. That is why restoring straight away is often the wrong first move.

    In the pack

  2. Step

    Stop backup jobs and protect the backups

    Attackers look for the backups first. Stop synchronisation and backup jobs that touch affected systems, so encrypted files do not overwrite good copies. Confirm at least one backup copy is offline or immutable, and cut the backup system off from the affected network and the shared sign-in directory. In the pack's defaults these steps run within 30 minutes, in parallel with isolation.

    In the pack

  3. Decision

    Could isolation stop safety-critical or essential operations?

    Isolating devices or cutting off a site can stop operational systems as well as office ones. In the playbook, the incident manager isolates at once, the least disruptive way that stops the harm, and brings in the service owner and specialists before cutting off anything people depend on for safety or essential operations. Stopping a customer-facing service is the executive incident lead's decision unless waiting would let the harm spread. If isolation could stop such operations, or you cannot tell, answer yes.

    In the pack

    See also

  4. Step

    Contain least disruptive first; bring in the operations owners

    Keep containing: isolate affected devices, block what crosses between the office and operational networks, and disable affected accounts. Before cutting off anything people depend on for safety or essential operations, the incident manager brings in its service owner and specialists, with outside responders if needed, and decides with them how far to go. Where the operational network is separated from the office network, confirm the separation holds. Record the decision and the reason.

    In the pack

    See also

  5. Step

    Isolate affected devices, and the site if it may spread

    Isolate affected devices from the network without switching them off, since switching off destroys evidence in memory. Where more than one device is affected or the source is unknown, cut the site or segment off from the other sites, the hosted services and the internet, following the site isolation steps. The incident manager orders isolation without waiting for an executive, choosing the least disruptive containment that stops the spread.

    In the pack

  6. Decision

    Is it still spreading?

    No only when there has been no new encryption, alert or attacker activity across every site and hosted service for a quiet period, 2 hours in the playbook's defaults. Not yet known counts as yes. Nothing is restored into an environment where the ransomware is still active.

    In the pack

  7. Step

    Widen the isolation and ask for outside help if needed

    Widen the isolation the least disruptive way that stops it: the next site or segment, any shared administrator systems and the link to hosted services. Search for the same indicators everywhere. Ask for outside responders if your own responders cannot keep up. Before stopping anything people depend on for safety or essential operations, bring in its service owner and specialists. Then ask again whether it is still spreading.

    In the pack

    See also

  8. Step

    Preserve evidence before anything is wiped

    Evidence is the only way to know how the attacker got in, what it touched and whether data left. Photograph the ransom note, keep the first infected device on and isolated, copy sample encrypted files, and export logs before retention runs out. If a device must be reused, take a full disk image first. Rebuilding without an image is the usual way evidence is lost.

    In the pack

  9. Step

    Plan recovery as if nothing will be paid

    Do not reply to the attacker. The playbook assumes you do not pay, and restore or rebuild does not wait on any demand. Only the board or its equivalent may decide on a ransom: the board, the management board in a two-tier structure, or executive management or the owners where there is no board. Never one manager. It decides only after legal advice including a sanctions check, the insurer's view and a report to law enforcement.

    In the pack

  10. Step

    Close the way in and remove what the attacker left

    Before any system reconnects: find and close the way in, remove new accounts, scheduled tasks, remote access tools and changed directory settings, and reset credentials from clean devices, administrators first. End all signed-in sessions and patch the weakness used. Recovery starts when the monitoring provider confirms these are done with no new activity.

    In the pack

  11. Step

    Agree the restore order: foundations first

    Restore the foundations first: network, sign-in directory, backup system, endpoint protection and monitoring. Then the critical services, in the order the executive incident lead confirms. The resilience pack's default is order of recovery time, shortest first, unless another order is set and the reason recorded. Set the order and target times in advance with each service's owner, and confirm them when recovery starts.

    In the pack

    See also

  12. Decision

    Are the backups intact and clean?

    The backup provider checks and the incident manager decides. Clean means copies from before the earliest sign of the attacker, not just before the encryption. A backup that could be reached from the affected network is not safe until it has been checked.

    In the pack

    See also

  13. Step

    Do not restore until the backups are checked

    Never restore from a copy the attacker could have reached without checking it. Check integrity, find the date of the earliest sign of the attacker, and scan the candidate copies in an isolated place. Then answer the question again.

    In the pack

    See also

  14. Step

    Rebuild from clean images; recover data from other sources

    Without clean backups, rebuild each system from a clean image and recover data from wherever else it exists, such as the hosting provider, suppliers or paper records. Tell the executive incident lead at once: recovery will take longer and the restore order matters more. Engage outside responders if needed.

    In the pack

    See also

  15. Decision

    For this system, do you know the route in and every change?

    Ask it separately for each system. Yes only when the investigation has found how the attacker reached this system and accounted for every change it made there. Where the attacker had administrator rights on the system, rebuild it even if the route is known. The managed IT provider recommends, the incident manager decides, and the system owner tests. If unsure, the answer is no.

    In the pack

  16. Step

    Restore data onto the patched system and check it

    Use the newest copy from before the earliest sign of the attacker that passes its integrity check and a scan, both done in an isolated place before it goes back on the network. Restore onto the patched system, change its credentials, and turn on endpoint protection and monitoring before it reconnects.

    In the pack

    See also

  17. Step

    Rebuild from a clean image, then restore only data

    Wipe it and install again from a known-good image kept apart from the network, then restore only data from a checked copy. After a destructive attack, rebuild in an isolated recovery environment with new administrator accounts. Where the attacker had administrator rights, rebuild every system it controlled, starting with the sign-in directory. In the pack's example, the encrypted office PCs were rebuilt rather than cleaned.

    In the pack

    See also

  18. Decision

    Are the recovery criteria met for this system?

    The five criteria: the route in closed; the backup or image checked before use; the system patched, scanned and monitored with credentials changed; the owner's written confirmation that it works; the monitoring period started. A patch is not proof the attacker has gone. The resilience pack adds its clean-room checks before return, such as a sweep for persistence and reconciling the restored data.

    In the pack

    See also

  19. Outcome

    Keep it disconnected until the gap is closed

    A system that fails a criterion stays off the network. Send the gap back to the step that owns it, and tell the executive incident lead if it changes the restore order or target times.

    In the pack

  20. Outcome

    Reconnect in stages under closer monitoring

    Reconnect one site or service at a time, watched for the indicators found. In the pack's defaults the monitoring period is 7 days for Severity 1 and 2, and the incident closes only when it has passed without the attack returning, every report due has been made and the case log is complete.

    In the pack

    See also

Practical checklist

  1. Stop backup jobs on affected systems and confirm at least one copy is offline or immutable.
  2. Contain until nothing has spread for the quiet period, and preserve evidence before anything is wiped.
  3. Close the way in, remove what the attacker left and reset credentials from clean devices.
  4. Agree the restore order with foundations first, then the critical services.
  5. Check each candidate backup's integrity and scan it in an isolated place, using copies from before the earliest sign.
  6. Decide for each system whether to restore onto the patched system or rebuild and restore only data.
  7. Check the recovery criteria for each system before it reconnects.
  8. Reconnect one site or service at a time under closer monitoring.

Evidence to have ready

  • Each restore or rebuild decision: the inputs, who recommended, who decided and when.
  • The earliest sign of the attacker and each backup copy's date, integrity check and scan result.
  • The recovery criteria results for each system, with the owner's written confirmation that it works.
  • The restore order with the reason for any change, and the times each service stopped and returned.
  • The data lost against the recovery point objective for each data set, and how it was recovered.

Assumptions

  • The steps and defaults are those of the CISO Times ransomware playbook. Your own playbook may set different ones.
  • The recovery order, the clean-room rebuild and the checks before return follow the CISO Times resilience pack, which works inside the playbook's decisions and changes none of them. Your own continuity plan may set its own order and target times.

Not covered here