AppLocker or EDR: Choosing Between a Mitigation and a Data Source
NorthBridge Insurance runs 2,400 Windows endpoints, 600 of them servers. EDR agents cover all servers and the 400 laptops bought in the last two years; the remaining 2,000 endpoints have antivirus only. PowerShell script block logging is on for servers, off for workstations, and no endpoint forwards command-line data to the SIEM. Six months ago an intrusion started with a phishing attachment that launched a PowerShell download cradle and then used certutil -decode to unpack a loader. The team reconstructed the chain from proxy logs alone, three days after the fact. For the next fiscal year leadership has approved exactly one project: (a) AppLocker allowlisting on all 2,400 endpoints, or (b) EDR on the remaining 2,000. The CISO wants the choice argued in ATT&CK terms - which techniques each option affects, and what the residual blind spot is either way. Procurement needs an answer in two weeks and the vendor discount on option (b) expires at the end of the month.
1. Break the observed intrusion into ATT&CK techniques and state precisely which of the two proposals touches each one.
Read the worked answer
The chain maps roughly as follows: T1566.001 Spearphishing Attachment (initial access), T1204.002 Malicious File (user executes the attachment), T1059.001 PowerShell (download cradle), T1105 Ingress Tool Transfer (payload pulled from the internet), T1140 Deobfuscate/Decode Files or Information (certutil decoding), and then execution of the loader.
Option (a), AppLocker allowlisting - mitigation M1038 Execution Prevention. It targets the execution half of the chain: T1204.002 and T1059.001, and by blocking script host execution from user-writable paths it also constrains T1140. Important caveat: default AppLocker rules permit execution from %WINDIR%, and certutil.exe lives there. Unless the policy adds explicit deny rules for the binaries actually abused, the decode step survives. AppLocker produces no useful detective telemetry of its own.
Option (b), EDR - a data source decision, not a mitigation. It supplies process creation with full command lines, image loads and network connections. That supports detection of T1059.001, T1105, T1140 and the loader execution, and lets the team test whether existing rules fire at all.
The honest framing: (a) removes capability for standard users but blinds you further; (b) removes nothing but finally gives you eyes on 83 percent of the estate that currently has none.
2. The CFO argues that option (a) 'prevents the attack instead of just watching it.' How do you answer in ATT&CK terms, and what does the mitigation do not tell you?
Read the worked answer
ATT&CK mitigations are descriptive, not ranked. The matrix lists M1038 Execution Prevention against a technique as a statement that this class of control can interfere with that behaviour - it carries no coverage score, no strength rating and no implementation guidance. So 'we have M1038' is not a measurable claim; the measurable claim is 'the policy blocks these paths for these users, and we tested it.'
Three limits to press:
- Scope of the policy. Allowlisting only bites if it covers the execution paths adversaries use: user-writable directories, temporary folders, script hosts and signed-but-abusable system binaries such as certutil. A policy that permits everything under %WINDIR% leaves the observed decode step intact.
- Coverage of the estate. If the rollout staggers over 12 months, most endpoints remain unchanged through the risk window.
- What it cannot do. Mitigation is silent. It will not tell you that a user opened the attachment, that a cradle ran and failed, or that someone is probing. Prevention without visibility means the next intrusion is again reconstructed three days late from proxy logs - the exact failure that prompted this review.
The strongest answer is usually sequencing rather than choosing: prevention where it is cheap and complete, telemetry where it is absent. If only one purchase is possible now, ask which risk is larger - being exploited by a known, blocked path, or being exploited and not knowing.
3. Whichever option is chosen, what data sources must the team plan for, and how would you validate that the resulting detections work?
Read the worked answer
The techniques in the observed chain need, at minimum: process creation with full command line and parent process (T1059.001, T1140, T1204.002), file creation and image load (loader drop), and network connection or proxy telemetry to external destinations (T1105, T1071.001). Script block logging on workstations is what turns an opaque encoded blob into readable content, so it belongs on the wish list whether or not EDR arrives - EDR without script block logging still shows the command line only if it is captured in the process creation event.
Validation should be behavioural, not documentary:
- For each mapped technique pick a small set of atomic tests (an encoded PowerShell command, a certutil decode of a benign file, a suspicious parent-child pair such as winword.exe spawning powershell.exe).
- Run them on a representative endpoint in each coverage tier - server with EDR, workstation with EDR, workstation with AV only - and record whether the event was generated and whether the rule fired.
- Store the result per technique so the coverage heat map distinguishes 'rule exists' from 'rule verified to fire on this telemetry'.
- Re-run after major agent or policy changes, and log which ATT&CK version the mapping uses.
This turns the next budget conversation from an argument about vendor features into a table of techniques with a verified or unverified status against each.