Hospital Ransomware Readiness: A Hardening and Recovery Plan

The design assumption has to be that the attacker will hold domain administrator credentials before they encrypt anything, because that is how these operations work. A backup that a domain administrator can delete is not a backup against ransomware; it is a backup against hardware failure, which is a different problem you have already solved. Immutability is the requirement, delivered either through object lock on the storage, a hardened appliance with its own credential boundary, or an offline copy that is physically disconnected between runs.

The commonly used formulation is three copies of the data on two different media with one copy off site, extended in modern practice with one copy immutable or offline and zero errors on the last verified restore. That last element carries the most weight and receives the least attention. Backup jobs report success routinely while producing sets that cannot be restored, and the point at which a hospital discovers this is exactly the point at which it can least afford to.

So the operating discipline is restore testing, not backup monitoring. Once a quarter, restore a real system to an isolated environment and have the department that uses it confirm the data is usable, which for a laboratory information system means a technologist looking at retrieved results rather than an engineer confirming the service started. Record how long the restore took, because that number is your actual recovery time and it is usually considerably longer than the figure in the business continuity plan.

Most hospital networks were built for connectivity, so a workstation in the outpatient billing counter can typically reach the PACS archive, the pharmacy server and the biomedical device controller directly. That flatness is what turns a single compromised endpoint into an enterprise event. Segmentation does not prevent the initial compromise; it decides how much of the hospital is inside the blast radius when it happens, and it is the single highest-value network project available to a hospital IT team.

The practical starting point is not a full microsegmentation programme. It is a small number of coarse boundaries that can be delivered without an outage: separate the medical device estate from general workstations, separate the imaging network from administrative traffic, place guest and patient wifi entirely outside the corporate network, and put management interfaces for hypervisors, storage and backup on a restricted administrative segment reachable only from hardened jump hosts. Four boundaries done properly beat twenty planned and never implemented.

The cost is operational friction, and it is honest to say so. Every interface between HMS, LIS, PACS and the modalities now needs an explicit rule, someone has to maintain those rules, and a badly documented firewall change at 3am can stop a clinical workflow. That is why segmentation should be staged during known-quiet windows with the previous configuration ready to reinstate, and why the rule set needs an owner rather than being a shared spreadsheet nobody has opened since commissioning.

Almost every large ransomware event runs through privileged credentials, so this is where a limited security budget earns most. Remove standing domain administrator rights from daily-use accounts, so that administrators hold a separate elevated account used only from a hardened workstation. Eliminate reused local administrator passwords across machines, which is what allows an attacker to move from one workstation to the next without any sophistication at all. Enforce multi-factor authentication on every remote access path, including the vendor ones.

Vendor access deserves its own paragraph because hospitals are unusually exposed here. A typical hospital has standing remote access granted to the HMS supplier, the PACS supplier, the laboratory analyser vendor, the biomedical maintenance contractor and the building management integrator, often through tools chosen by the vendor rather than by you. Convert those to brokered access: requested when needed, approved by a named person, time-limited, attributable to an individual engineer and recorded. Vendors resist this, and the resistance is a useful signal about how they manage their own risk.

Then look at the applications themselves. Hospital systems accumulate administrative accounts the way wards accumulate equipment, and it is common to find a dozen HMS users with full rights because a permission problem was once solved by escalation. Inventory them, justify each one in writing, and remove the rest. This is unglamorous work that produces no visible output, which is precisely why it is usually still outstanding when an incident occurs.

The honest position on hospital patching is that a meaningful proportion of the estate cannot be patched on the vendor-recommended schedule. A modality workstation runs a validated configuration the manufacturer will not support if you change it. An analyser interface depends on an old runtime. Devices registered with CDSCO carry manufacturer validation constraints, and biomedical engineering is right to refuse an unvalidated change on a life-supporting device. Pretending this away produces a patch policy nobody follows and a compliance record that is fiction.

The workable approach is to split the estate. General-purpose workstations, servers and infrastructure follow a normal monthly cycle with emergency out-of-band patching for critical remotely exploitable vulnerabilities. Constrained clinical devices go on a separate register with a compensating control recorded for each: network isolation, restricted protocols, no internet access, removable media disabled, and monitoring for anomalous traffic. That register, maintained jointly by IT and biomedical engineering, is also the document that answers an assessor asking how you manage unpatched clinical systems.

Push the problem upstream at purchase. Ask for the manufacturer security disclosure for any networked device, ask what the patch commitment is and for how many years, and ask what happens when the underlying operating system leaves support during the equipment life. A twelve-year imaging asset bought with a five-year software support commitment creates a security liability that the capital committee never priced. Raising it before the purchase order is far easier than raising it afterwards.

Rehearsal should escalate in three stages over a year rather than being attempted as one large exercise. Stage one is a tabletop with clinical and administrative leadership present, working through a scenario with no technical activity, purely to test decision rights and communication. Stage two is a technical restore drill in an isolated environment against a defined system, measured against its stated recovery objective. Stage three is a live failover of one tier-one application during a planned window, which is the only exercise that tells the truth.

Include the clinical downtime side in every stage. If the hospital management system is unavailable for four days, somebody has to register patients, generate identifiers that will later reconcile, record orders, issue medicines from the pharmacy and produce a bill. Those manual processes exist on paper in most hospitals and have usually never been run for more than a few hours. A drill that stops at the technical recovery misses the operational half of the problem entirely.

Write findings as owned actions with dates, then check them at the next exercise. The value of these drills is almost entirely in what they reveal about coordination: that the on-call list is out of date, that nobody has the vendor escalation number, that the manual registration book ran out after two hours, that the backup restore takes eleven hours rather than the four assumed in the plan. Those are cheap discoveries in a drill and expensive ones at 3am.

Recovery has a sequence, and doing it out of order is how hospitals get encrypted a second time during the restore. Contain first: isolate affected segments, disable the compromised accounts, and cut vendor remote access across the board until you know what happened. Report within the six-hour window that the CERT-In directions require, and start the separate personal data assessment under the Digital Personal Data Protection Act 2023 in parallel. Preserve evidence before you rebuild, because a wiped server cannot be examined afterwards.

Then rebuild in dependency order rather than in order of who is shouting loudest. Identity services and DNS come first because nothing else authenticates without them. Then the clinical systems ranked by your own tiering, which usually places patient identity and order management ahead of billing and reporting. Restore to clean infrastructure, not to the machines that were encrypted, and reset every credential in the environment including service accounts and device accounts before reconnecting anything to the general network.

Plan the return to normal working as its own project. Data captured on paper during the outage has to be entered, reconciled and attributed to the right encounter, and doing that badly leaves a clinical record with gaps that will surface during an audit or a medico-legal request years later. Decide who enters it, in what order, and how backdated entries are marked so the record shows what was recorded contemporaneously and what was reconstructed. That distinction protects both the patient record and the clinicians who wrote it.