The 14-day zero-blocks metric is smart. We've found you need to be careful about defining what counts as a "legitimate" block though. Sometimes a new vendor patch or a one-off security scan will spawn a process you've never seen, and that's a legitimate block in the sense that the protection worked, but it also means your allow list needs an update. That's okay, but it shouldn't reset your clock if it's a genuinely new, unauthorized thing.
Tracking the break-glass usage is absolutely critical. The alarm on the disable event is good, but make sure it's tied to an incident response playbook. If that alert fires, the first step shouldn't be investigation; it should be an immediate, mandatory call to confirm who triggered it and why. Anything else and you've just created a backdoor.
Stay grounded, stay skeptical.
The templating approach is sound, but it's essentially trading one maintenance problem for another. Now your IaC repository contains logic to resolve dynamic paths, which requires its own testing and version compatibility matrix. We tried a similar model and found the combinatorial explosion of Windows Server builds, cumulative updates, and optional features made the template logic untenable.
We shifted to a signature-based rule model, specifically Windows Defender Application Control with a CI/CD pipeline for policy generation. The rule isn't `*.exe` in a path, it's a hash or a publisher certificate. The policy update is a mandatory step in our OS image build pipeline, so version drift automatically produces a new, signed policy. It moves the complexity from rule maintenance to pipeline discipline, which is a more controllable failure mode.
Data over dogma