02:10 ransomware at a 340-bed hospital
Northbrook Regional Health is a 340-bed hospital with a 24/7 emergency department. At 02:10 on a Saturday the night shift reports that the electronic medication administration system is throwing file-access errors, and shared drive folders now show files renamed with a .locked extension. The on-call analyst confirms the core EHR application still responds and most patient records remain readable, but the imaging archive is offline. The hospital's downtime procedures cover roughly four hours, and the nearest alternative trauma centre is 90 minutes away. Backups are nightly fulls to tape, with one tape rotated offsite each week; the most recent offsite tape left five days ago. The last documented restore test was 14 months ago. Within the next hour the CISO must decide whether to shut down the network segment serving pharmacy, which stops automated dispensing and forces paper ordering, or leave it running while the team scopes the intrusion.
1. Which element of the CIA triad is under the greatest immediate pressure, and why is 'the EHR still works' a weak basis for reassurance?
Read the worked answer
Availability is the objective under immediate pressure, but the reasoning matters more than the label, because 'the EHR still works' measures one thin slice of the triad and can be actively misleading.
- Availability: medication administration and imaging are degraded now. The real question is whether the outage stays inside the four-hour downtime window.
- Integrity: the core EHR responding does not mean its data is intact. Locked files on the shares show the encryption routine is running; the application may be serving cached pages, a read-only replica, or sessions established before encryption began. Records that render can still be stale.
- Confidentiality: current ransomware operators commonly exfiltrate before encrypting. There is no evidence either way yet, so the honest position is 'unknown', not 'unaffected'.
The practical rule: application responsiveness is a liveness signal, not an integrity or confidentiality signal. Until the analyst verifies a known recent record against a trusted source and reviews egress logs, treat the readable EHR as unverified - and write that assumption into the incident log, because paper ordering and later re-entry of results depend on it.
2. Recommend the action for the next 60 minutes and justify it against the alternatives.
Read the worked answer
Decision criteria, in order: patient safety first, then reversibility, then blast radius. Keep reversible options open and shrink the blast radius.
Recommended: isolate the pharmacy/medication segment and the file-share VLAN at the firewall/switch level. Do not power down servers - a hard shutdown may destroy volatile evidence and can corrupt the EHR database mid-transaction. Move pharmacy to paper ordering under the documented downtime procedure, and in parallel ring-fence backups by disabling the backup service account's domain credentials.
Why not 'wait and scope': encryption has already reached the file shares, so the adversary has execution in the environment. Every extra minute raises the chance the EHR database files or the backup catalog are hit, and a five-day-old offsite tape is the recovery floor.
Why not 'shut everything down': a full outage converts a partial, manageable degradation into a hospital-wide one. With the next trauma centre 90 minutes away, diversion is a real clinical harm, not a theoretical one.
Notify the incident commander and the ED charge nurse at the same time as technical containment: the clinical decision (diversion) and the technical decision are owned by different people, and both have to be made inside the same hour.
3. What does the 14-month-old restore test imply for the recovery objectives, and what would you verify before attempting a production restore?
Read the worked answer
It implies the recovery time and recovery point objectives exist only on paper. An untested backup is a hypothesis, and this one has a 14-month-old test and a five-day-old offsite tape.
Verify, in this order:
- Tape and key independence - is the tape encrypted with a key held offline? If the key-escrow service is domain-joined, the tape is only as safe as the domain.
- Catalog independence - can the team enumerate and restore without systems that are currently encrypted? A catalog on a compromised share turns a backup into decoration.
- Application consistency - EHR restore needs a database consistency check and re-verification of medication-administration records, not just file-level recovery.
- RPO arithmetic - nightly fulls with weekly offsite rotation means up to five days of potential data loss if offsite media is the fallback. Five days of lost medication history is almost certainly not clinically acceptable; say so explicitly rather than quoting target figures.
Report the current RTO/RPO as 'unverified'. Schedule the test on isolated hardware before any production restore, which could overwrite recoverable data. The board question afterwards: what architecture gives a restorable, ransomware-independent copy in hours rather than days?