Guide

Why Threat Feeds Are Not Threat Intelligence

A feed tells you what is happening somewhere. Intelligence tells you what that means for your organisation and what you should do about it.

Many organisations that say they "do threat intelligence" mean that they receive something. A commercial feed with indicators of compromise. A weekly newsletter from a vendor. Alerts from the national CERT. A dashboard that counts ransomware incidents per sector. All of this has value, but none of it is intelligence until someone has decided what it means for this organisation, at this moment, for a specific decision.

This distinction is not academic. It explains why security teams can be overloaded with threat information and still be surprised by the incident that actually happens.

A familiar situation

The security team of a mid-sized organisation subscribes to two feeds and follows several sector reports. Each month, the CISO presents a slide to the management team with the number of blocked attacks, a list of recent vulnerabilities and a short summary of ransomware activity in Europe. The management team nods, asks whether "we are covered" and moves on to the next item.

Six months later, a supplier with remote access to the organisation's environment is compromised. The attacker uses that access to reach a file server with research data. In hindsight, the route was not unusual at all. Several reports had described exactly this pattern for the sector. It never appeared on the monthly slide, because nobody had connected the general reporting to the organisation's own suppliers, access arrangements and most valuable information.

The organisation had plenty of threat information. What it lacked was a picture of which threats applied to itself, and what that should change.

From data to action

A useful way to think about threat intelligence is as four steps, each adding something the previous step did not have.

Data

Raw observations: IP addresses, file hashes, domain names, vulnerability identifiers, log entries. Data is plentiful and cheap. It is also context-free. An IP address on a blocklist says nothing about who is behind it, what they want or whether they care about you.

Information

Data that has been organised and described. "This group uses these domains and these tools in phishing campaigns against healthcare providers." Information answers the question "what is happening?" Most vendor reports, advisories and feeds operate at this level.

Intelligence

Information that has been evaluated, combined and interpreted against a specific organisation and question. "Given our research partnerships, our reliance on two managed service providers and the way our remote access is set up, this campaign pattern is a credible route to our most sensitive data. We judge this as likely within the next twelve months, with moderate confidence." Intelligence answers "what does this mean for us?"

Action

The decision or change that follows. Restricting supplier access to named systems. Bringing forward a planned segmentation project. Testing the exact scenario. Briefing the people who would receive the first contact. Intelligence that does not lead to a decision, or at least to a conscious choice not to act, has not done its job.

A feed lives almost entirely in the first two steps. The value is in the last two.

Why more feeds rarely help

When threat intelligence does not seem to work, the usual response is to add sources. A second feed, a dark web monitoring service, another platform that aggregates everything. The result is more data and the same lack of direction.

The root cause is usually one of the following:

  • There is no question. The team collects "everything relevant" instead of starting from the decisions the organisation needs to make. Without a question, relevance cannot be judged.
  • Sources are not evaluated. A claim in a vendor blog, a post on a forum and a confirmed government advisory are treated as equally reliable. They are not.
  • Assumptions stay hidden. Conclusions are presented as facts, while they rest on assumptions about attacker motives, capabilities or the organisation's own controls that nobody has written down.
  • There is no link to the organisation. The threat picture describes the sector or the world, not the organisation's own services, suppliers, information and exposure.
  • Nobody owns the follow-up. The report is distributed, but no one is expected to decide anything based on it.

None of these problems is solved by more data. They are analytical and organisational problems.

What makes intelligence useful

Start with the decision

Good intelligence work starts by asking what the organisation needs to decide. Which security investments should take priority next year? Is it acceptable to give a new supplier remote access? Which scenarios should the next penetration test cover? What should the board know about the risk of extortion? These are intelligence requirements. They determine which sources matter and which can be ignored.

Evaluate the source and the claim separately

Two questions apply to every piece of information: how reliable is the source in general, and how credible is this specific claim? A normally reliable source can be wrong on a specific point. An unknown source can be right. Recording both judgements makes it possible to explain later why a conclusion was reached, and to revise it when new information arrives.

Make assumptions and uncertainty visible

Threat assessments always involve judgement under uncertainty. That is acceptable, as long as it is explicit. A statement such as "we assess with moderate confidence that criminal groups are more likely than state actors to target us, assuming our research data has limited resale value" is more useful than "the main threat is ransomware". It tells the reader what the conclusion depends on and when it should be reconsidered.

It also helps to write down at least one alternative explanation. If phishing attempts against the finance department have increased, is this a targeted campaign or a broader wave that happens to reach finance? The answer changes the response.

Translate threats into scenarios

Management does not decide on threat actors. It decides on scenarios: what could happen, how, with what impact, and what would reduce the likelihood or the damage. A small number of well-described scenarios, linked to the organisation's own critical services and information, is usually more useful than a long list of actors and techniques.

Frameworks such as MITRE ATT&CK help here, not as a goal in themselves but as a shared language. Mapping a relevant scenario to specific techniques makes it possible to check whether detection and controls actually exist for each step.

End with priorities

The final product should answer a simple question: what should we do differently now? That can be a short list of actions with owners and timelines, a change in the scope of a test, or an explicit decision to accept a risk. If the honest conclusion is that current priorities are right, that is also a valid outcome, as long as it is based on analysis rather than habit.

What this means for smaller organisations

Organisations without a dedicated intelligence team sometimes conclude that threat intelligence is not for them. That is understandable if threat intelligence means running a platform and processing feeds all day. It is not true if threat intelligence means answering a small number of important questions well.

An organisation of two hundred people does not need a daily stream of indicators. It does benefit from knowing which three or four scenarios are realistic for its sector and situation, what would make them possible, and whether its current security plan addresses them. That can be done periodically and in a structured way, without building an intelligence function.

The role of AI

AI can process large volumes of reporting, extract techniques, compare sources and keep track of changes much faster than a person can. FLODISQ uses an AI Threat Analyst for exactly that work. It does not replace the analytical judgement. Deciding whether a source is reliable, whether a pattern applies to a particular organisation and what the organisation should do about it remains the responsibility of human analysts, who can explain and defend their conclusions.

This division matters. A tool that produces confident conclusions without visible sources and assumptions creates the same problem as a feed, only faster.

Three things to do this quarter

  1. Write down three decisions that threat information should support in the coming year. Use them to judge which current sources are actually useful.
  2. Ask for the assumptions behind the next threat summary you receive. If they cannot be named, the summary is information, not intelligence.
  3. Pick one realistic scenario for your organisation, for example misuse of supplier access, and check step by step whether you would prevent, detect and contain it. Use the result to adjust a test plan or an investment decision.

Conclusion

Threat feeds are a source. They are not the product. The product is a clear, reasoned view of which threats are relevant to your organisation, how confident you can be about that view, and what it means for your priorities. That requires a question, source evaluation, explicit assumptions and a link to decisions. Without those, more information only makes the picture harder to read.

If you want to see what this looks like in practice, the Threat Intelligence service describes the method and the deliverables. The scenarios that come out of such an analysis are also a good starting point for security testing that reflects how an attacker would actually approach you.