5. Detection, Response, and Recovery: Designing the First Hour After Discovery

5.1 Detection Is a Decision-Making Capability, Not “Alerts”

The value of detection against ransomware lies not in the number of notifications, but in the speed at which the possibility of compromise can be judged, impact limited, evidence preserved, and business impact explained. Even if logs are collected into a SIEM, a high-severity alert at night cannot be processed if the asset name, owner, normal state, operational approval, and contact route are unknown.

Log Surfaces That Should Be Prioritized

• Identity: authentication successes/failures, MFA changes, privileged roles, app consent, conditional-access exceptions.
• Endpoints/servers: EDR detections, disabling of protective functions, administrator-privilege changes, anomalous process or file operations.
• Network: externally exposed services, administrative pathways, DNS, proxies, VPN, perimeter devices.
• Cloud/SaaS: administrative operations, audit logs, data sharing, mail rules, storage operations.
• Backup/virtualization: retention changes, deletions, encryption keys, administrator logins, job failures.

Retention periods should not be decided solely by “the minimum number of days required for compliance.” Decide based on how far back one would want to look once a compromise is discovered, what contracts, regulation, and insurance require, and whether investigators can correlate timestamps.

5.2 Principles of the Initial Response

1. Confirm the immediate impact on life, safety, and critical operations.
2. Halt changes and preserve necessary evidence.
3. Isolate identities, endpoints, and connections suspected of compromise, taking impact and evidence into account.
4. Do not assume administrative pathways are normal. On the assumption that they may already be compromised, secure alternate routes for communication and administration.
5. Begin a timeline that separates facts, hypotheses, and unconfirmed items.
6. Activate the command structure spanning technical, management, legal, and public-relations functions.

“Immediately powering everything off” is not a universally correct initial response. While spread must be stopped, one must also consider the impact on volatile information, communication records, memory, logs, and services that are running. Decisions on isolation, shutdown, or powering off should be made taking into account the nature of the environment and expert advice.

5.3 Phases of Incident Response

Figure 7: The Flow of Response

Proceed through the cycle: Preparation → Detection/Analysis → Containment → Eradication/Rebuilding → Recovery/Monitoring → Review/Improvement. The results of the review are fed back into the contact network, the asset ledger, detection, restoration, and exception management.

(Full figure translation deferred — see note at top of this file.)

Preparation

Put in place the contact network, contracts, outside support, legal counsel, backups, privileged emergency access, administrative endpoints, logs, and exercises. Many of these cannot be purchased or discovered once an emergency has begun. In case the response extends over a long time or multiple days, also prepare relief staff and handover procedures in advance, during normal operations.

Detection/Analysis

Investigate what happened, since when, and which identities, endpoints, data, and operations are affected. Because initial information is incomplete, state explicitly whether something is “confirmed,” a “possibility,” or “unconfirmed,” rather than asserting it outright.

Containment

The objective is to stop the attacker’s activity and the spread of damage. Decisions such as disabling accounts suspected of compromise, isolating endpoints from the network, restricting the externally exposed surface, and temporarily suspending administrative pathways are made together with their business impact. Containment is not completed in a single operation and is updated as additional information arrives.

Eradication/Rebuilding

Beyond simply deleting malicious files, remove the intrusion route, the identities that were abused, configuration changes, persistence mechanisms, and lateral-movement pathways. Where the management plane in particular is suspect, decide the scope over which identities, endpoints, and configuration will be rebuilt from a trusted foundation.

Recovery/Monitoring

Resume priority operations on a limited basis, restoring in stages while strengthening monitoring. Recovery is deemed successful not because “the screen opens,” but because data integrity, authentication, integration, performance, monitoring, and business procedures can be verified as accepted.

Review/Improvement

Rather than fixing on a single cause, break down why the entry point was permitted, why detection was delayed, why privilege expanded, and why recovery was difficult. Attach an owner, deadline, verification method, and residual risk to each improvement item.

5.4 Evidence Preservation and the Timeline

What proves most useful later is not impressions, but time-stamped facts. Align audit logs, authentication logs, network logs, EDR events, configuration changes, tickets, and interviews with those involved to a common time reference, and keep the preserved original separate from the working copy.

This distinction serves not only later accountability, but also prevents a mistaken assumption from being treated as fact during the response itself.

5.5 External Coordination

When bringing in outside experts, insurers, legal counsel, investigative authorities, cloud/SaaS/telecom providers, or outsourcing partners during an incident, what should be shared first is not speculation but an environment diagram, contact information, the confirmed timeline, affected operations, measures already taken, and the state of log preservation. The FBI’s IC3 indicates that complaint information is useful for referral to, and investigation by, relevant agencies. [S02]

Because notification recipients and deadlines differ by country, industry, and contract, this report does not provide legal advice. During normal operations, organize the requirements for personal information, healthcare, payments, critical infrastructure, outsourcing contracts, and overseas locations together with legal counsel.

5.6 Increasing the Effectiveness of Recovery Exercises

The maturity of exercises can be raised in the following order.

1. Verify the contact network and decision-making authority in a tabletop exercise.
2. Restore a single system from backup into an isolated environment.
3. Restore at the level of a business operation, including identity, network, applications, data, and monitoring.
4. Restore on the assumption of a compromised administrator identity or a failure of the backup management plane.
5. Conduct an organization-wide exercise including management, legal, public relations, and outsourcing partners.

Do not close out an exercise’s results with the single word “success.” Record the planned time, the actual time, assumptions that broke down, procedures that depended on specific individuals, access rights, log shortfalls, post-recovery gaps, and unresolved risks, and fix them before the next exercise. This is the evidence of effectiveness.

5.7 Common Failures and Alternatives