Chapter 26 — Recovery and continuity decision methods | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 26 — Recovery and continuity decision methods

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["26.1 Recovery objectives"]
  N2["26.2 Choosing a restore point"]
  N3["26.3 Dependency order"]
  N4["26.4 Acceptance tests"]
  N5["26.5 Fallback and monitoring"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["26.1 Recovery objectives"]
  N2["26.2 Choosing a restore point"]
  N3["26.3 Dependency order"]
  N4["26.4 Acceptance tests"]
  N5["26.5 Fallback and monitoring"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX076"]

[Learning outcomes and connection]
    |
    v
[26.1 Recovery objectives]
    |
    v
[26.2 Choosing a restore point]
    |
    v
[26.3 Dependency order]
    |
    v
[26.4 Acceptance tests]
    |
    v
[26.5 Fallback and monitoring]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes and connection

You will be able to (1) choose a restore point using evidence about when compromise began; (2) order recovery by dependencies; (3) define acceptance tests and a return-to-service criterion; (4) plan fallback and post-recovery monitoring. Chapter 9 introduced backups and integrity; Chapter 25 produced a timeline. Recovery combines them. Chapter 27 verifies that eradication and restoration actually worked.

26.1 Recovery objectives

Recovery time objective (RTO): how long a service can be unavailable. Recovery point objective (RPO): how much data loss is tolerable, measured in time. These are business decisions, set before incidents (NIST SP 800-34 Rev. 1 covers contingency planning; SP 800-184 covers cyber-event recovery). During an incident, they become constraints on choices — but a compromise can force a restore point older than the RPO, because newer copies may contain the attacker's changes.

The Harbourline booking case shows the tension: Sequence A meets a tighter recovery time but rests on assuming the 9 March sign-in was benign.

26.2 Choosing a restore point

The restore point must precede the earliest known malicious change with a margin reflecting uncertainty about the earliest actual change. Evidence for that comes from the timeline. Snapshots after that point are suspect; replicas fed continuously from the primary are suspect from the moment the compromise began.

In the booking case, the earliest known malicious change is 22:14 on 11 March, but the attacker's access was first seen at 21:50 and an unexplained admin sign-in on 9 March at 03:00 has not been ruled out. The 21:00 snapshot precedes the observed access; the 9 March 02:00 snapshot precedes everything unexplained. Which one is safe depends on resolving that earlier sign-in, which is why the decision logic hinges on it.

26.3 Dependency order

Recover in the order dependencies require: identity before applications that authenticate against it; databases before APIs; internal services before public exposure. A dependency graph (Chapter 2) gives the order; a topological sort makes it explicit.

For Harbourline Booking, that means securing the identity provider and rotating admin credentials before restoring the database, then the API behind the proxy, and only then reopening access for staff. Restoring the API first would put a service online that still trusts credentials the attacker may hold. Write the order down and have the service owner confirm it, because dependencies seen from outside are often incomplete.

26.4 Acceptance tests

Before returning a service to users, test: integrity of data (Chapter 9 checks), absence of known indicators, correct function (create/read/update test transactions), security configuration (credentials rotated, vulnerabilities fixed) and monitoring in place. The service owner accepts the service; the responder supplies the evidence.

For the booking platform the criterion includes a scan for the known phishing domain and for any URL added by admin accounts since 9 March, plus a sample of 50 bookings checked with clinic staff. Each test has a clear pass or fail result, and the service owner signs off on the evidence rather than on reassurance.

26.5 Fallback and monitoring

Plan what happens if recovery fails: return to degraded mode, try an older copy, or keep the manual process. After return to service, monitor more intensively for a defined period with specific indicators.

For the booking platform, the fallback is Sequence B if a scan of records changed since 9 March finds indicators after Sequence A, and the monitoring period is 72 hours focused on admin sign-ins. Name the person who watches the monitoring and the action each finding triggers, otherwise heightened monitoring becomes a dashboard nobody reads.

26.6 Worked example (synthetic): booking platform recovery

Fictional. Harbourline Booking was found altered on 12 March 10:00: appointment notes contained links to a phishing page. Timeline: earliest known malicious change 11 March 22:14; attacker access via a compromised admin account first observed 11 March 21:50; earliest unexplained admin sign-in 9 March 03:00 (not yet ruled out).

Copies: nightly snapshot 11 March 02:00 (verified by checksum); hourly snapshot 11 March 21:00; read replica (continuous, trusted only partially because it mirrors the primary).

Sequence A (faster): restore from 11 March 21:00 snapshot; re-enter about 60 bookings made between 21:00 and the shutdown; RPO loss ~13 hours. Risk: if the 9 March sign-in was malicious, the attacker may have planted changes earlier.

Sequence B (safer): restore from 9 March 02:00 snapshot (before the unexplained sign-in), then re-apply legitimate changes from the transaction log selectively after review; loss of 3 days of bookings without careful replay. Risk: long recovery, replay errors.

Return-to-service criterion (both): admin credentials rotated and MFA enforced; no records containing the known phishing domain or any URL added by admin accounts since 9 March; a sample of 50 bookings verified with clinic staff; service owner sign-off; 72-hour enhanced monitoring of admin sign-ins.

Decision logic: if analysis of the 9 March sign-in clears it within the RTO, choose A; if not, choose B or A plus a scripted scan of all records changed since 9 March for indicators, with B as fallback.

26.7 Common errors and limits

Restoring the newest backup by habit.
Trusting replicas that mirrored the attacker's changes.
Recovering applications before identity and credentials are secured.
Returning service without owner acceptance or enhanced monitoring.
Choosing a restore point without resolving or bounding the earliest unexplained access, such as the 9 March sign-in.
Re-entering lost bookings from memory without checking them against clinic records.
Ending enhanced monitoring early because the first day was quiet.
Treating the read replica as a clean source when it mirrored the primary throughout the attacker's access.
Measuring recovery only by when the service came back, not by whether the restored data was verified as trustworthy.

Exercises — chapter 26

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX076 — Restore-point margin. Steps: explain why the earliest known malicious change (22:14) is not a safe restore point by itself and propose a rule for the margin. Rubric: 3 = unknown earlier activity, access began earlier (21:50), unresolved 9 March event; rule: precede the earliest unexplained access by the attacker path, not the earliest observed damage; 2 = partial; 1 = accepts 22:14; 0 = none.

EX077 — Dependency order. Inputs: components: IdP, booking DB, booking API, reminder service, public website. Steps: give a recovery order and justify each step. Rubric: 3 = IdP (credentials secured) → DB → API → reminder service → public website, with reasons; 2 = order right, reasons thin; 1 = public first; 0 = none.

EX078 — Acceptance test list. Steps: write five acceptance tests with pass criteria for Sequence A. Rubric: 3 = integrity, indicator scan, function, security configuration, monitoring, each with criterion; 2 = three; 1 = vague; 0 = none.

Chapter synthesis

Choose restore points from the timeline with a margin for unknown earlier activity, recover in dependency order, require explicit acceptance tests and owner sign-off, and keep a fallback and enhanced monitoring.

Continue studying — chapter 26 of 40

← Chapter 25 · Course chapter index · Chapter 27 →

Continue to the next authored lesson.