Three Feeds, One Lookup Table, 18,400 Alerts

Stop flattening the feeds. The core defect is that a 12-hour, high-confidence ISAC indicator and an undated OSINT IP share one severity and one table. Provenance, confidence, and first/last-seen must be carried as columns and used in matching logic.

Age by indicator type, not by feed preference:

• IPv4 addresses: 7–14 days for most, hours for suspected fast-flux or bulletproof ranges. Cloud-provider ranges age out immediately unless tied to a specific confirmed incident.
• Domains: 30–90 days, with the last-seen date driving decay.
• File hashes: effectively indefinite, but only ingested from sources that publish per-hash confidence. A hash match is a high-signal event; an IP match is not.

Match by type and purpose:

• Hashes and high-confidence ISAC indicators → alerting. These are rare enough that precision holds.
• OSINT IPs and shared-hosting ranges → enrichment only. They contribute a score to an alert raised by something else (rare destination, non-browser process making the connection) but never page an analyst alone.
• Blocking: egress deny only for ISAC and confirmed commercial high-confidence indicators, never for the OSINT aggregation.

Retire undated indicators or force them into a hunting table with no alerting path. Add an allowlist for vendor update and telemetry domains with an owner and expiry, and exclude the three cloud-provider ranges from alerting entirely - attackers do use cloud hosting, but the base rate makes an IP match there uninformative on its own.

Expected effect: the OSINT IP matches, which are most of the 18,400, become context rather than tickets. Alert volume should fall by more than an order of magnitude without removing any feed.

Adjudication

1. Start with the file, not the feed. Verify the Authenticode signature chain and validity date, the file path (does it sit in the vendor's expected install or update directory?), version and creation timestamp against the weekly updater schedule, and whether the hash matches the vendor's published artefact.
2. Check prevalence across the estate. One host with the file, when the updater normally touches many, is anomalous; the same signed binary on 200 servers is almost certainly a feed false positive or a known-good updater that some vendor flagged.
3. Interrogate the feed entry. Does the commercial source give a confidence, a malware family, a first-seen date, and a reason? A hash listed as 'associated with vendor X updater' is a much weaker signal than one tied to a named family.
4. Behaviour beats hash. Pull EDR telemetry for the process: parent, network connections, child processes, file writes. A signed updater that only talks to the vendor's CDN is behaving normally.
5. Detonate or multi-scan a copy if any of the above is inconsistent. Do not submit internal binaries to public services without approval.

What to tell the CISO: this is an indicator-precision problem, not a coverage problem. The fix is an expiring allowlist entry for the signed vendor artefact plus a provenance note back to the feed vendor - not disabling the feed. Say explicitly that the redesign keeps hash matching at full alerting severity, which is why this single low-volume alert surfaced at all; the noise is concentrated in the IP lists.

Volume and workload

• Alerts per day by feed and indicator type, to confirm the drop is where you predicted it.
• Median triage minutes per alert and total analyst hours per week on indicator matching.
• Percentage of alerts auto-enriched rather than auto-closed - auto-close without a recorded reason hides regressions.

Precision

• Weekly stratified sample: label 30 random alerts from each remaining alerting path as true positive, benign-true, or unknown, and track precision over time. Sampling matters because the surviving volume is small enough that one bad rule can dominate.

Coverage - the part that stops the redesign from becoming a quiet blind spot

• A seeded test set: monthly, insert 20 known-bad indicators drawn from an isolated test corpus or your own red-team infrastructure into the matching path and confirm each produces the expected disposition (alert, enrich, or block).
• A purple-team exercise each quarter that uses infrastructure never present in any feed, to measure detection independent of threat intel. Your own data already says 70% of confirmed malicious IPs were never in a feed - that is the number the programme must be judged on.
• Time from indicator ingestion to enforcement for the blocking path; the 2.5-hour median contact-to-block figure is the baseline to beat.

Report the trade honestly: falling alert counts alone prove nothing. Pair volume with precision samples and seeded coverage so the CISO sees that the reduction came from removing uninformative matches, not from turning off detection.