Incident Response: Ransomware Detection During a Backup Window
At 01:40 a monitoring alert fires: a file server is encrypting documents at high volume, and a ransom note appears on three shares. The security lead confirms ransomware on one server. The environment has nightly backups that completed at 23:00; the backup server is on the same network segment as the affected server and its credentials are stored in a config file on a management host that the attacker appears to have reached. The last verified restore test was 7 months ago. The incident commander wants to (a) immediately wipe and rebuild the affected server to restore service before the 08:00 business start, and (b) postpone notifying the regulator until the scope is understood. The business handles personal data of about 40,000 customers.
1. Evaluate the plan to wipe and rebuild the affected server immediately.
Read the worked answer
Wiping immediately trades evidence for speed and may not even restore service safely. Before rebuild, the team must preserve volatile and non-volatile evidence (memory, logs, the ransom note, the encryption process artifacts) because scope, initial access vector, and any regulatory obligations depend on it. More importantly, rebuilding onto a network where the attacker has reached the management host and possibly the backup credentials risks re-infection - the server would be rebuilt into a compromised environment. And the backups themselves are suspect: they sit on the same segment and their credentials may be exposed, so 'restore from backup' is not a safe assumption without validating backup integrity and isolation.
The defensible sequence is contain (isolate affected hosts and the backup server), preserve evidence, determine whether backups are intact and offline/immutable, then rebuild into a cleaned environment. Restoring service by 08:00 is a goal, not a mandate that overrides containment; a rushed rebuild that gets re-encrypted is worse than a controlled delay.
2. Assess the decision to postpone regulator notification until scope is understood.
Read the worked answer
Postponing indefinitely is not defensible. With ~40,000 customers' personal data in scope and confirmed unauthorized access to a management host, there is a credible personal-data breach, and most regimes impose notification deadlines measured from awareness, not from full scoping. 'Wait until we understand scope' can consume the notification window and convert a containable incident into a compliance failure.
The correct approach is to run scoping and notification in parallel: preserve evidence and scope the data at risk while preparing a preliminary notification, and engage legal/counsel to determine the applicable deadline and whether a preliminary filing is required. The incident commander's instinct to avoid a premature, inaccurate notification is reasonable, but it must be reconciled with the legal clock. Document the decision, the information known at the time, and the basis for timing. The judgement being tested is recognizing that scoping and notification are concurrent obligations, not sequential ones.