Skip to content
Unpopular opinion: ...
 
Notifications
Clear all

Unpopular opinion: Paying for 'threat intel' feeds is a waste if your EDR vendor already has it.

1 Posts
1 Users
0 Reactions
1 Views
(@auditlog)
Estimable Member
Joined: 3 months ago
Posts: 130
Topic starter   [#4256]

I've been reviewing our aggregation layer logs and the normalized alert data we pipe into our SIEM for the last quarter, specifically cross-referencing external threat intelligence feed indicators with the detections our primary EDR platform generated autonomously. The pattern I'm observing is leading me to a potentially contentious conclusion.

Our SOC pays for two major commercial threat intel feeds. We ingest these as STIX/TAXII into our TIP, which then forwards IOCs to our EDR and network sensors. However, when I trace the lineage of our critical incidents from the last 90 days, a substantial majority of the actionable malware detections and behavioral blocks originated from our EDR's own internal intelligence. The external feeds, while generating a high volume of indicator matches, primarily flagged items already in a blocked state or associated with very low-prevalence artifacts that never progressed to execution.

Here's a simplified log analysis pattern I ran to correlate feed alerts with EDR's native detections (using pseudo-Splunk SPL for illustration):

```
index=edr_actions
| search action="blocked"
| eval detection_source=case(
match(signature_name, ".*VendorML.*"), "EDR Native",
match(signature_name, ".*Custom.*"), "Internal Hunting",
1=1, "Other"
)
| stats count by detection_source, threat_indicator_present
| where threat_indicator_present="true"
```

The results consistently showed that for blocked executions where a threat intel IOC was present (e.g., hash, domain), the EDR had already taken action based on its own sensor data and machine learning models *before* the IOC from our paid feed was even evaluated. The latency in our feed ingestion and distribution pipeline often meant the external intelligence was corroborative, not proactive.

This raises several operational and financial questions:

* **Redundancy at Scale:** Are we effectively paying twice for the same intelligence? Our EDR vendor's subscription isn't cheap, and a core part of their marketing is the global threat intelligence gathered from their entire customer base. If they are already baking that intelligence into their detection models and signatureless capabilities, what unique value does a generalized commercial feed provide that our vendor's tailored intelligence does not?
* **Alert Fatigue & Tuning Overhead:** Each external IOC generates events. These events require triage, context enrichment, and often lead to exception tuning when they collide with legitimate business activity. The signal-to-noise ratio, in my audit, has been poor.
* **Potential Exceptions:** I acknowledge there might be niches where external feeds are justified:
* Highly targeted, industry-specific (e.g., finance, healthcare) intrusion sets that a general-purpose EDR might not prioritize.
* Strategic intelligence for proactive threat hunting, where the context (TTPs, actor profiles) is more valuable than the raw IOCs.
* Compliance requirements that explicitly mandate multi-source intelligence ingestion.

I'm curious if others have performed similar log-based audits of their detection efficacy. Have you quantified the return on investment for standalone threat intel feeds in an environment with a mature, cloud-native EDR? Are we better off reallocating that budget towards enhancing our internal logging capabilities, hiring, or building custom detection rules tuned to our unique environment?


Logs don't lie.


   
Quote