Automated Scanning With a Noisy Tool
A security team deploys an automated configuration scanner across 900 servers. The first full scan returns 14,000 findings. Triage shows roughly 70 percent are duplicates or accepted-risk items already documented, 20 percent are low-severity informational notes, and the remainder include 40 findings rated critical. The scanner has no authenticated access to 120 servers, so it reports them as 'unreachable' rather than scanning them. The team lead proposes raising the severity threshold so only criticals are reported, to 'cut the noise and get the team focused.' A developer notes that last month a critical finding turned out to be a false positive caused by the scanner misreading a config file, and the team spent two days on it.
1. Assess the proposal to raise the severity threshold, including what it would and would not fix.
Read the worked answer
The proposal treats a triage and coverage problem as a reporting problem, so it fixes the symptom and hides two real issues.
What it fixes: the team sees fewer items, so attention is less diluted. That is real but shallow.
What it does not fix, and makes worse:
- The 70 percent duplicates/accepted risks are a deduplication and suppression problem. Raising the threshold leaves them in the data (just below the line) and does nothing to stop them recurring. Proper fix: suppression rules keyed to a documented accepted-risk register, so they are excluded with a reason and re-evaluated on a schedule.
- The 120 unreachable servers are a coverage gap misreported as a status. A threshold change makes these invisible - and unreachable hosts are where unpatched, unmonitored risk concentrates. This is the most dangerous part of the proposal.
- The 20 percent informational items are legitimately low priority; filtering them is reasonable, but they should be archived, not discarded, because they are the raw material for trend analysis.
- False positives are unaffected by threshold. The developer's example shows the team needs a validation step before acting on any single finding, critical or not.
Net: the threshold change reduces visible volume while increasing blind spots. That is the wrong trade.
2. Propose a triage process that addresses noise, coverage, and false positives together.
Read the worked answer
A layered process, each layer with an owner and a record:
- Coverage first. Treat 'unreachable' as its own tracked category, not a scan result. Fix authentication for the 120 hosts or document why each cannot be scanned and what compensating control covers it. Report coverage percentage alongside findings - a clean report on 780 of 900 hosts is not a clean report.
- Deduplicate and suppress with reasons. Map the 70 percent to the accepted-risk register. Each suppression cites an owner, a justification, and a review date. Suppressed items stay queryable.
- Validate before escalating. Any finding - especially criticals - gets a quick confirmation step (manual check or second tool) before it consumes team time. This directly addresses the two-day false positive.
- Tier the response by validated severity and exposure, not raw scanner score: internet-facing criticals first, then internal criticals, then highs, with informational items archived for trend reporting.
- Measure the pipeline, not the count: time-to-validate, time-to-remediate, suppression rate, coverage rate. Those metrics show whether noise is actually falling or just being hidden.
The governing idea: reduce noise by explaining and routing findings, not by not looking at them.