The missing step between an alert and a working service
Microsoft had released MS17-010 before WannaCry spread on 12 May 2017. The bulletin addressed remote code execution in Windows SMBv1. Microsoft's incident analysis described ransomware using the vulnerability to move between machines. The outbreak was therefore a test of whether an available fix had reached the systems that needed it, rather than a contest to invent a new defence during the incident.
The UK's National Audit Office later identified a specific governance gap in the NHS response: national warnings had been issued, but there was no formal mechanism for assessing local compliance before the attack. It also described disruption extending beyond directly infected organisations through shared systems and data. The distinction matters. An uninfected workstation can still be unable to deliver its service when a dependency elsewhere has failed.
Make patch exceptions expire
A patch dashboard can describe deployment activity while leaving the most difficult machines unresolved. Legacy applications, operational restrictions and missing owners tend to collect in an exception category. Calling that category an exception does not limit how long a machine remains exposed.
A useful exception has four properties: a named service owner, the reason installation is blocked, a compensating control that can be checked, and a date for a new decision. “Business critical” is a reason to plan the change carefully, not an expiry date. An exception without a revisit point can silently become the permanent operating model.
| Decision | Evidence that helps | Evidence that is insufficient |
|---|---|---|
| The fix reached the host | Installed update and relevant restart state | A successful deployment job elsewhere |
| The vulnerable path is restricted | Verified network rules covering the intended segments | A diagram labelled internal |
| The exception remains justified | Current application constraint and accountable owner | An old ticket with no recent assessment |
| The service can recover | A tested restoration path including dependencies | A backup job marked successful |
This record is short enough to maintain, but precise enough to challenge. Its purpose is to make an unresolved exposure visible to the people able to change it.
A practical check without sending exploit traffic
Start with the operating-system and update inventory. Reconcile it with the authoritative list of machines running the service; include rarely used hosts, recovery environments and systems maintained by another supplier. A fully patched managed estate says little about a machine outside that management system.
Then inspect the permitted SMB paths using authorised configuration and network inventories. Ask which business workflows require those paths and which systems can initiate connections. The aim is to understand the failure domain, rather than to run historical worm code or treat a blocked internet port as evidence of internal isolation.
Finally, verify the machine's current state after the change. A package installation record and a running service can represent different software states. Record the host, fix evidence, check time and owner together so the next reviewer can distinguish completion from intention.
An exercise for shared-service operators
Choose one synthetic unavailable dependency: a file share, scheduling system or identity service. Ask each dependent team which operations would stop and which could continue manually. Do not assume that a department reporting no infected machines would report no operational impact.
The NAO's account makes this a more useful exercise than simply asking whether everyone knows the ransomware escalation number. A cross-organisation outage tests contact routes, access to current instructions and authority to disconnect a service. Those arrangements need to work when the usual collaboration tools are unavailable.
The later CrowdStrike outage involved defective content rather than a worm, but it raises the same service-level question: which recovery capability survives the failure affecting the estate? The malware mechanism and the restoration dependency should be analysed separately.
Verify configuration and exception ownership
Two read-only checks and their limits
On supported Windows systems with the relevant management modules, an administrator can inspect the operating-system identity and configured SMB server protocols without changing them:
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, LastBootUpTime
Get-SmbServerConfiguration |
Select-Object EnableSMB1Protocol, EnableSMB2Protocol
The second command depends on the operating-system role and available SMB module. Run it only on the system being assessed, with appropriate administrative access. An unavailable cmdlet is a tooling limitation, not an unaffected finding.
These outputs answer deliberately narrow questions. They do not prove that MS17-010, or a later cumulative update containing the relevant corrections, is installed. Match the operating-system release to the vendor's update evidence and verify the running state separately. A recent boot time is likewise not evidence that the right update was installed before that boot.
For a fleet, save a normalised result with the host's managed identity and service owner. Do not publish raw infrastructure inventories as part of a public incident report. Public readers need the method and conclusion; internal responders need the machine-level evidence.
A measurable exception review
Take a small sample of patch exceptions and ask a reviewer to reconstruct why each remains open. The reviewer should be able to find the affected service, current compensating control, decision owner and next review date without interviewing the original ticket author.
Measure unresolved or contradictory records separately from confirmed vulnerable machines. That turns the exercise into an inventory-quality test rather than a misleading estimate of compromise. It also gives managers a concrete task: resolve ownership and decision gaps that prevent the technical team from acting.
The durable result is a closed loop from a security notice to an operating service: inventory, decision, deployment, verification and an expiring exception process. Counting machines that received an instruction is easier than proving that this loop worked. The 2017 record shows why the latter is the more useful measure.
