The 3.8 Million Indicator Feed

The visible symptoms are false positives and latency, but the root causes are architectural: the pipeline treats every indicator as equally actionable, has no concept of indicator lifetime, and performs expensive lookups before reducing volume. A free feed's IP list is being used for blocking with no context about shared infrastructure. The CDN case is predictable because many feed IPs are edge nodes that host both malicious and benign customers.

A defensible order:

1. Normalize at ingest: indicator type, value normalization (lowercase domains, CIDR handling, hash format), source, first/last seen, and confidence. Reject malformed or unsupported types early.
2. Deduplicate by value plus type before enrichment. Keep source provenance as a list rather than creating duplicate rows.
3. Apply source scoring and indicator confidence: commercial curated, ISAC, free, and internal incident-derived indicators are not equivalent. Score by historical precision, not brand.
4. Apply aging and expiry: hashes may live for months; IPs and domains used for phishing may decay in days or weeks. Store last-seen and expire from automated action, not necessarily from search.
5. Enrich only what survives: ASN, geo, first-seen, malware family, and whether the value is in a CDN/cloud range. Enrichment should be cached.
6. Suppress or downgrade known shared infrastructure and business partner ranges for blocking; retain them for hunting and retrospective search.
7. Route by action: block, alert, or hunt only. Free-feed and low-confidence indicators should not drive automatic blocking.
8. Feed back confirmed true and false positives to source scoring.

Allowlisting all CDN ranges is too blunt because attackers do use cloud hosting. The better rule is: never auto-block a shared CDN IP based solely on a feed; use domain, URL path, and behavioral context; and require a second source or internal confirmation for blocking.

Build a 90-day scorecard per feed rather than comparing list sizes. Criteria:

• Uniqueness: how many indicators or detections were not present in the other six feeds or in internal incident data.
• Precision: of the alerts attributed to that feed, what percentage were confirmed true positives after analyst review? Use a consistent sample and a defined adjudication process.
• Timeliness: time from first public or vendor sighting to availability in your pipeline, measured for a sample of incidents.
• Coverage: mapping to client sectors and to the PIRs or threat models the MSSP actually sells. A feed that is strong on consumer phishing but weak on ransomware affiliates may not fit a healthcare-heavy client base.
• Actionability: how often the feed produced a block, detection, hunt, or client notification that would not otherwise have happened.
• Cost per validated detection, not cost per million indicators.
• Licensing and redistribution: whether the contract permits use in client-facing detections or reports.
• Support and provenance: can the vendor explain sourcing, false-positive handling, and takedown/retraction?

Method: create a holdout or A/B comparison where operationally possible, tag every alert with the feed that contributed it, and have analysts label outcomes. Track 'feed-attributed true positives' and 'feed-attributed false positives.' Interview five clients about which alerts they valued. Finance should see a table of cost, validated detections, analyst hours consumed, and overlap. A feed that is cheap but consumes two analyst-days per week may be the most expensive. Do not cancel a feed solely for low volume if it provides unique early warning for a high-impact PIR; do cancel one that is redundant, stale, or unlicensed for the MSSP's use.

Agree with the risk but separate the sources from the use. The problem is not 'free' by itself; it is unverified indicators being used for automated blocking and client-facing claims. A free feed can be useful for hunting, retrospective search, and context, while being unsuitable for automatic enforcement. Conversely, a paid feed can be poorly curated or stale.

Response to the client:

• Acknowledge the specific incident and show the corrective action: the free-feed indicator should not have been used to block a business partner. That is a process failure, not proof that all free sources are worthless.
• Explain the tiered model: paid/curated and internal incident data may drive blocking when confidence is high; free and OSINT sources are restricted to alerting, hunting, and enrichment unless corroborated by a second source or internal telemetry.
• Offer transparency: client reporting will state the source tier and confidence behind any block or alert, and the client can opt out of free-feed-derived blocking.
• Set a review date and provide metrics showing false-positive reduction.

Trade-offs: dropping free feeds entirely may reduce coverage of low-cost, fast-moving phishing or malware infrastructure, especially for smaller clients. Keeping them with no controls is what caused the problem. The defensible position is source-tiering plus action-tiering, not a blanket ban. If the client's contract requires a higher assurance level, honor it for that client and document the exception rather than pretending one policy fits all 1,200 clients. Also check whether the free feed's license permits commercial use inside an MSSP; many do not, which is a separate legal reason to restrict or drop it.