4,300 EDR alerts a day and a rule that cannot be scoped by parent process

The trap to avoid: deleting the rule. It is the only thing watching lsass, and the pen-test finding tells you analysts already discount it. Suppress the cause, not the detection.

1. Narrow exclusion on attributes, not on rule or host. The agent cannot scope by parent process, but most platforms can scope by signer certificate plus install path plus binary hash. Build the exclusion as the intersection of: vendor code-signing certificate, exact installation directory, pinned SHA-256 of the current agent binary, and the specific access mask the VSS component requests. Any one attribute failing means the alert fires. That defeats the standard bypass - copy the agent to another path, or drop an unsigned binary with the same name.

2. Scope it by endpoint group. Apply the exclusion only to the server groups that actually run the backup agent. Workstations keep the full rule. This shrinks the blast radius of a mistake.

3. Keep the events, do not discard them. Route suppressed alerts to a separate low-cost index with 30-day retention rather than dropping them. If you later suspect abuse of the backup path, you can retro-hunt; if you had deleted them, that question becomes unanswerable.

4. Fix the PowerShell root cause rather than suppress it. 210 unsigned scripts is a supply-chain and hygiene problem. Have IT sign the automation scripts and run them from a dedicated service account; use WDAC/AppLocker in audit mode first. Then alert on unsigned PowerShell from anywhere else, which is a far stronger rule than the current one. If signing cannot land in two weeks, allowlist by script hash plus parent process plus path, and report when the hash changes.

5. Handle the 40-item tail by hand. That is triageable volume for four analysts; tuning it blind is how real detections get lost.

Compensating detection. Add an alert on any lsass handle request with read/write access rights by a process outside the pinned allowlist, on comsvcs.dll MiniDump command lines, and on new .dmp files in user-writable paths.

Alert reduction is a cost metric, not a quality metric. Measure three axes.

1. Efficacy - validated detection. Before and after tuning, replay a credential-dumping corpus against an in-scope host and confirm the alert fires: comsvcs.dll MiniDump via rundll32, ProcDump, a direct MiniDumpWriteDump loader, and a Task Manager dump. Record alert-to-detection latency. If any technique was caught before and not after, the tuning fails regardless of volume.

2. Bypass the exclusion itself. Purple-team the exact attributes you allowlisted: copy the agent binary to C:\Temp, rename it, and run a dump from that path; then forge the path with a different unsigned binary. Both must alert. This is the test most teams skip and the one an attacker will run.

3. Sample the suppressed stream. Each week, pull a random sample of 50 suppressed events and have an analyst review them. Track the false-negative discovery rate. This is your early warning that the exclusion is too wide, and it needs to be a scheduled task or it will not happen.

Supporting metrics: mean time to triage (target down from 3.5 hours to under 1), queue depth at shift change, and percentage of the estate where the exclusion applies. Also track alert-to-incident conversion: if L1 currently closes 95% of alerts as benign, the 40-item tail should reset that ratio, and a persistent high benign rate means the tail also needs tuning.

Guard rails. Any change to the lsass rule goes through peer review and a documented rationale, with the coverage map updated. Set a quarterly review date on the exclusion - backup agents change binaries, and a stale hash pin will silently start generating noise again, which is exactly how the rule got discounted in the first place. Report the exclusion register to risk so the accepted residual risk is owned rather than inherited by the next analyst.

Prevention first - the tuning is only acceptable if the attack surface shrinks.

• Credential Guard and LSA protection (RunAsPPL). With PPL enabled, a non-PPL process cannot open lsass for read even with administrative rights, which structurally defeats most dump tooling rather than detecting it. Verify the backup agent has a PPL-compatible plugin or documented exemption before rolling out; a broken backup is not an acceptable trade.
• WDAC/AppLocker to prevent unsigned binaries executing from user-writable paths - this also cleans up the PowerShell problem permanently.
• Restrict SeDebugPrivilege to the smallest possible set of accounts and service identities; audit who holds it, because every holder is a potential dumper.

Detective controls that do not depend on the EDR rule.

• Sysmon Event ID 10 or EDR equivalent for lsass handle requests with suspicious granted access (e.g. 0x1010, 0x1410), alerting on anything outside the pinned allowlist.
• Command-line detection on comsvcs.dll with MiniDump, procdump -ma lsass, and known dump tool names; command-line alone is cheap and catches the lazy majority.
• File-creation alert on .dmp files above a size threshold in user-writable directories.
• Service or driver creation on domain controllers and file servers, where the tooling frequently lands.

Validation. Quarterly purple-team with three objectives: dump lsass by a novel method and confirm detection; attempt the allowlisted-path bypass and confirm the narrow exclusion rejects it; attempt a signed-binary proxy execution path. Feed results into a one-page coverage statement for risk. Run the same tests after any EDR agent upgrade, because rule semantics and exclusion support change between versions - the fact that this version cannot scope by parent process is exactly the kind of constraint that will shift under you.