The Exclusion That Ate the SOC
Helio Manufacturing has 8,000 endpoints and a security operations center that receives about 4,000 alerts per day. Roughly 92 percent are false positives from a backup agent that scans files in a folder also used by a build pipeline. The engineering team wants a permanent exclusion for C:\BuildAgent\ and a wildcard for *.helio-dev.local, arguing that scans slow builds by 40 percent. The folder's ACL allows all domain users to write to it; a previous exclusion for a temp directory was abused by commodity malware two years ago. The endpoint protection platform supports process, path, signer, and file-hash exclusions, and audit-mode reporting. A change advisory board meets weekly, and the next audit is in eight weeks. The SOC has two analysts dedicated to alert triage and no detection-engineering role.
1. Evaluate the exclusion request. What would you approve, reject, or modify, and what evidence would you require?
Read the worked answer
Reject the wildcard. A domain wildcard covers every host in that namespace and every process, which is a permanent blind spot an attacker can use with any binary. Reject the folder exclusion as written because the ACL allows all domain users to write there, the exact condition that made the earlier temp-directory exclusion abusable.
Approve instead: a process exclusion for the build agent executable, combined with a path exclusion limited to its output directory and a signer condition. Require evidence first: two weeks of audit-mode data showing which detections fire on the build tool, the exact process path and hash, and the performance measurement that justifies the 40 percent claim. If the tool cannot be signed, require a hash-based exclusion with a change ticket and an expiry.
Make ACL remediation a precondition. Restrict write access to the build service account and a named group. Without that, no path exclusion. Consider application control allowlisting for the build directory as a compensating control.
2. Design a tuning process that reduces the 92 percent false-positive rate without creating a blind spot. Include metrics.
Read the worked answer
Tuning is not exclusion.
Classify the 4,000 daily alerts by detection rule, process, and host group. The backup agent should collapse into one rule with a known signer and path. Fix the rule logic rather than excluding the folder.
Use audit-mode reporting to measure true versus false positives for two weeks. Do not tune on one day's sample.
For each noisy rule, adjust thresholds, add signer or parent conditions, or suppress only the specific benign pattern. Keep the original rule in a test policy for comparison.
Validate with a purple-team test: run a known credential-access and ransomware simulation inside the build directory and confirm the tuned rule still fires.
Metrics: alerts per 1,000 endpoints per day, percentage closed as benign, mean time to triage, and detection coverage against a fixed test set. A drop in alert volume with unchanged coverage is success. A drop in coverage is not. With two analysts and no detection engineer, assign rule ownership explicitly or the tuning will stall.
3. What compensating controls and review conditions would you attach to any exclusion, and how would you document them for the audit?
Read the worked answer
Compensating controls: application control on the excluded path, file-integrity monitoring for new executables, EDR process and network telemetry retained even when scanning is excluded, and a weekly review of files written to the path. Confirm which sensors still report, because an exclusion often disables scanning but not process creation.
Review conditions: a 90-day expiry, a named owner in engineering, re-approval only with fresh audit data, and automatic revocation if the ACL changes or malware is found in the path.
Documentation for the audit: the business justification, exact scope (process, path, signer, hash), the risk accepted, the approver, and the review date. Map each exclusion to a change ticket and to the risk assessment. Auditors will ask why a world-writable directory is excluded; ACL remediation is the answer. Maintain an exclusion register, reconcile it against the console quarterly, and treat any exclusion without an owner and an expiry as a finding.