Application allowlisting on high-value endpoints
On a server, on a privileged-access workstation, on a SCADA controller, the answer to 'what should run here' is finite, knowable and short. Allowlist it. Block everything else.
- Quadrant
- Strategic move
- Ease
- 2 / 5
- Impact
- 5 / 5
- Control family
- Endpoint
- Cost band
- medium
- Catalogued incidents
- 9
What the control is
Application allowlisting is the operating-system-level control that permits only an explicit list of approved executables, scripts, libraries and installers to run on a given host. Anything not on the list is blocked at the kernel layer regardless of who tries to execute it. The “list” is typically expressed as a combination of cryptographic hashes, code-signing certificates, file paths and publisher identities — the more anchored on signing identity and less on path, the more robust against attacker-controlled file placement.
The control is meaningfully different from antivirus or EDR-style detection. AV asks “is this file known-bad?” and lets unknown files run. Allowlisting asks “is this file known-good?” and blocks unknown files. The default flips from permit-unless-blocked to deny-unless-permitted, which is the right default on any host where the legitimate-software inventory is small and stable.
Application allowlisting is impractical to deploy on the general user-population endpoint estate, where the legitimate-software inventory is large, varied and changes constantly. It is highly practical on the high-value, change-controlled endpoint estate: servers, privileged-access workstations, payment-processing terminals, SCADA and PLC controllers, code-signing hosts, build agents, jump boxes. Those hosts have a knowable, short list of legitimate executables and an equally knowable list of high-impact attacker-controlled binaries that a deny-by-default would block.
Why it matters
Almost every catalogued ransomware and wiper event involves the same post-initial-access primitive: the operator drops a binary onto a host, executes it, and the binary either encrypts files, exfiltrates data or pivots laterally. Application allowlisting on the host removes that primitive. The dropped binary fails to execute; the operator sees the failure; the alerting tier surfaces the attempt; the incident contains.
NotPetya and Maersk’s recovery story are the canonical example. The wiper executed unimpeded on every endpoint it landed on, including the domain controllers and file servers that should have had a tightly-allowlisted runtime. WannaCry, in May 2017, propagated across the NHS England and global enterprise networks via the SMB worm, with the eventual encryption stage running as a foreign binary on each compromised host — a binary that would not have been on any reasonable allowlist. Industroyer (Ukrainian power grid, December 2016) and Stuxnet (Natanz, 2010) are the industrial-controls archetypes: in both cases, the attacker delivered foreign code to controllers that had no business running anything other than the vendor’s PLC firmware. HSE Ireland, Norsk Hydro, Travelex, Colonial Pipeline, JBS and the broader ransomware catalogue follow the same shape — host runs payload, payload encrypts, allowlist would have blocked the payload.
The Australian Cyber Security Centre’s Essential Eight ranks application allowlisting as one of its eight pillars precisely because the ACSC’s incident-response data shows it as the single highest-impact technical control they have measured for stopping ransomware and post-exploitation activity. The ranking is not promotional; it is empirical.
Where the regulators sit
NCSC’s “Application allowlisting” guidance is the cleanest UK-government articulation and is direct about scoping the control to high-value endpoints first. NIST SP 800-167 (“Guide to Application Whitelisting”) is the foundational US-government technical reference and walks through the deployment patterns and policy decisions in detail. The Australian Cyber Security Centre’s Essential Eight makes application control a pillar with maturity levels: at level three, allowlisting is enforced for executables, software libraries, scripts, installers, drivers and HTML applications across all workstations and servers. CIS Controls v8 Control 2 (“Inventory and Control of Software Assets”) includes the requirement. MITRE D3FEND maps the control specifically as “Executable Allowlisting” and links it to the post-exploitation ATT&CK techniques it counters.
The framework view is consistent across jurisdictions. There is no major framework that argues against the control on the high-value endpoint subset.
Where it usually breaks
Three failure modes recur. The first is scope creep — the temptation to deploy allowlisting tenant-wide on the user endpoint estate, which produces an unmanageable rule-tuning burden and inevitable rollback. The fix is to scope the deployment to the high-value endpoint population on day one and treat the user estate as a separate, lower-priority programme with different tooling.
The second is the rule-engine choice. Path-based rules are easy to write and easy for an attacker to bypass by writing a binary into an allowlisted path. Hash-based rules are robust but operationally heavy because every patch invalidates them. Publisher-and-signing-identity rules are the right balance and the modern OS-level allowlisting tools support them well. The fix is to bias the policy toward signing-identity over path.
The third is the build-pipeline interface. Allowlisting on build agents and code-signing hosts has to integrate with the legitimate change pipeline so new versions of legitimate software become allowlisted automatically. The fix is integration with the CI/CD signing infrastructure: anything signed by the corporate code-signing certificate is implicitly allowlisted; anything else is denied.
What good looks like
Application allowlisting deployed on every server, every domain controller, every privileged-access workstation, every payment-processing terminal and every controller in operational technology environments. Policy biased toward signing identity rather than path. Integration with the corporate code-signing infrastructure so new legitimate software is allowlisted automatically on signing. A monitor-mode rollout phase on each new tier of hosts before enforcement. Clear alerting on every block event, integrated with the SOC’s incident-response process.
The cost is real and the lift is multi-quarter. The benefit is that an entire class of post-initial-access attacker behaviour stops working on the hosts that hold the most-valuable assets.
Where this control would have changed the outcome
- NotPetya — Ukrainian-targeted destructive wiper A destructive wiper disguised as ransomware spread via a poisoned Ukrainian M.E.Doc tax software update, propagated through EternalBlue and credential theft, causing $10B+ globally.
- A.P. Moller-Maersk — NotPetya collateral damage NotPetya, deployed by Russian military intelligence through Ukrainian tax software, destroyed Maersk's global IT estate in hours; the shipping giant reported $300M in losses and rebuilt 45,000 PCs.
- WannaCry — global SMB-worm ransomware A North Korean ransomware worm using leaked NSA EternalBlue tooling encrypted 200,000+ Windows systems across 150 countries, including a third of NHS England Trusts.
- Ukrainian power grid — BlackEnergy + Industroyer Russian Sandworm operators twice cut Ukrainian electricity using custom ICS malware — BlackEnergy in 2015 and Industroyer in 2016 — the first confirmed cyberattacks to cause power outages.
- Stuxnet — Natanz uranium-enrichment sabotage A US/Israeli joint operation deployed a Windows worm with four zero-day exploits to physically destroy Iranian uranium centrifuges by manipulating their Siemens PLCs — the first cyber weapon.
- Ireland's HSE — Conti ransomware Conti ransomware entered Ireland's Health Service Executive via a phishing email, encrypted core clinical systems, and forced hospitals to cancel tens of thousands of appointments.
- Norsk Hydro — LockerGoga ransomware LockerGoga ransomware was pushed via Active Directory to every Norsk Hydro Windows workstation simultaneously, halting aluminium production globally and costing the company over $70M to recover.
- Travelex — Sodinokibi ransomware A New Year's Eve ransomware deployment took Travelex's foreign-exchange systems offline for weeks, contributed to its August 2020 administration, and forced UK store closures.
- Colonial Pipeline — DarkSide ransomware DarkSide ransomware encrypted Colonial Pipeline's billing, prompting a six-day shutdown of the largest US East Coast fuel pipeline; Colonial paid $4.4M, DOJ recovered $2.3M.