Security Vision
Almost every modern security monitoring system can work with Threat Intelligence. Manufacturers of SIEM, EDR, XDR, and NGFW constantly talk about IOC, feeds, IP address reputation, and automatic event enrichment.
In practice, everything looks a little different.
After connecting a dozen free TI sources, the SOC suddenly starts seeing thousands of "compromise indicators". Half of the IP addresses turn out to be inactive for a long time, some domains no longer exist, and the number of false positives begins to annoy analysts more than real attacks.
A natural question arises: how usefulis Open Source Threat Intelligencein general, and where does the benefit end and information noise begin? Let's try to figure it out.
What is generally called Open Source Threat Intelligence
Open Source Threat Intelligence generally refers to publicly available sources of information about threats.
This can include lists of malicious IP addresses, phishing site domains,hashes of malicious files, YARA rules, Sigmarules, as well as information about APT groupings, CVEs, and information about exploiting vulnerabilities.
Almost all of this information is published free of charge by researchers, information security companies, CERT teams, and the community.
At first glance, it seems logical to connect as many such sources as possible. The more data you have, the more likely it is to detect an attack. But this is where the first problem starts.
More data doesn't mean better
Let's imagine a typical situation.
The organization has enabled open sources AbuseIPDB, AlienVault OTX, Feodo Tracker, URLHaus, PhishTank, and several GitHubrepositories with IOC. A day later, SIEM starts receiving thousands of matches.
However, after analysis, it turns out:
-
The IP address has not been used by anyone for several months.
-
the domain was deleted a week ago.
-
IOC refers to an attack five years ago.
-
the indicator occurs simultaneously in ten different sources.
Formally, Threat Intelligence works, but in fact, the analyst spends time processing a huge amount of useless information. Therefore, the main indicator of TI quality is not the amount of data, but its relevance.
What data actually works
Over the past few years, several categories of information can be identified that really help with investigations.
1. IOC of current attacks
It would seem the most obvious option. If a new phishing campaign has appeared today, then the IP addresses and domains of intruders are really useful. But there is an important caveat here. The life cycle of most such IOCs is very short.
For example, a domain lives for several hours, the VPS changes in a day, and the IP is blacklisted after the attack ends. Therefore, the indicators should be updated regularly. If a source publishes data once a week — its value drops dramatically.
2. CVE with signs of exploitation
Today, it is not enough to know that there is a new vulnerability. It is much more important to understand whether it is currently being exploited, whether there is a public exploit, and whether it is being used by real attackers.
That is why many teams are now focused not only on CVSS. For example, a CVE with a rating of 9.8 may not interest any of the attackers. A vulnerability with a rating of 7.5 is already actively used in mass attacks. For prioritization, it is much more useful to use KEV (Known Exploited Vulnerabilities) data and similar projects.
3. YARA and Sigma
These two formats have long been the industry standard. YARA allows you to search for malicious files by their structure. Sigma-describe the detection rules independently of the specific SIEM. The advantage of such rules is that they describe the behavior of the attacker, and not a specific IOC. If the IP changes tomorrow, the rule will continue to work. That is why behavioral detectors live much longer than conventional IOCs.
4. MITRE ATT&CK
Formally, ATT&CK cannot be called Threat Intelligence in the classical sense. However, almost any modern SOC uses this base. Why?
Because it allows you to answer questions such as:
-
what action does the attacker perform?
-
why it is needed;
-
what will be the next stage of the attack?
-
what techniques have already been noticed.
For building discovery scenarios, ATT&CK is often more useful than a huge list of IOCs.
What most often turns out to be noise
Now let's look at the other side. There are several categories of data that are more likely to cause problems than help.
1. Huge IP blacklists
Some free repositories contain millions of IP addresses. That sounds impressive. But the question arises: when was the last time each of them was checked? Many addresses have already changed owners, some belong to cloud platforms, and some use CDNs. As a result, the system starts signaling almost any connection.
2. GitHubUnaccompanied GitHub repositories
GitHub today is filled with thousands of repositories with IOC. The problem is that many of them have not been updated for a long time. You can find lists that are three years old, without specifying the source, and without information about the verification method. It is risky to use such data without additional validation.
3. IOC without context
Imagine a record like: 185. xxx. xxx. xxx
What should I do with it? It is not clear when the address was discovered, who used it, whether it belongs to APT, whether it participated in phishing, and whether it is currently relevant in principle? By itself, IOC says almost nothing — the real value is the context around it.
4. Automatic trust to any source
Sometimes there is an approach: "the source is open, so you can automatically block all IP addresses." This is one of the most common mistakes. Any source can make mistakes, so automatic blocking should be used very carefully, especially when it comes to critical services.
When there are too many open feeds
The problem for most organizations does not occur when the first TI source is connected, but several months later. Dozensof feeds, internal IOCs, Sigma rules, research reports, and SOC's own observations are gradually appearing. At some point, it becomes difficult to answer even a simple question: which of these indicators is really trustworthy?
That is why today they are increasingly using not just a set of IOC lists, but specialized Threat Intelligence Platform (TIP) platforms.
Their task is not to replace open sources, but to bring them to a single view, remove duplication, save the history of changes, and make it possible to evaluate the quality of each indicator.
A good TI platform allows you not only to aggregate data from different sources, but also to enrich them with additional information: the time of the first and last detection, relationships between objects used by TTP via MITRE ATT&CK, and belonging to specific malicious campaigns or APT groups. As a result, the analyst gets not just an IP address or domain, but a full-fledged context.
An example of such a platform is Security Vision TIP. An interesting feature of the platform is that it allows you to work simultaneously with open and internal Threat Intelligence sources, combining them into a single knowledge base. For example, when investigating an incident, the analyst can see not only whether it matches the IOC, but also additional information:
-
what source is the indicator received from?
-
how reliable is the source?
-
when the indicator first appeared and whether it was updated.
-
what malicious campaigns it is associated with.
-
what MITRE ATT&CK techniques were used by attackers;
-
whether this IOC was previously encountered within the organization.
However, the value of modern TIP platforms is not limited to storing indicators. In fact, they become a single threat knowledge management center. Instead of searching for information in various repositories, open databases, and research reports, the analyst works in a single interface that already contains all the necessary information and links between them. For example, if a suspicious IP address is detected in the infrastructure, the platform can automatically show which externalfeeds it is present in, which malware families it belongs to, whether it was used in known APT campaigns, which infrastructure objects have already interacted with it, and how high the level of trust in this indicator is. This amount of information significantly reduces the time required for initial analysis of an incident.
Another important feature of modern tips is automatic data enrichment (Threat Enrichment). New indicators can be supplemented with information from various sources almost without the participation of an analyst. As a result, the IOC ceases to be just an IP address or a hash of a file and turns into a full-fledged object with a description, links, tags, change history, and a confidence score.
Separately, it should be noted that the effectiveness of Threat Intelligence directly depends on how well it is integrated with other security tools. If indicators are simply stored in a separate database, their practical value is limited. A completely different situation occurs when TIP becomes part of the overall information security architecture.
For example, Security Vision TIP supports integration with SIEM, SOAR, EDR, firewalls, mail gateways, and other security tools. This allows new IOCs to be automatically used in monitoring, event correlation, automatic response, or detection rule generation processes. As a result, Threat Intelligence ceases to be a static directory and becomes an active element of infrastructure protection.
How to use Open Source TI effectively
The most efficient approach looks something like this.
1. Use multiple high-quality sources
Not twenty random repositories. Five regularly updated projects are best. For example, AlienVault OTX, URLHaus, Abuse.ch, CISA KEV, SigmaHQ.
2. Check for data freshness
For each IOC, it is desirable to know the date of publication, the date of the last update, the source, and the level of trust. A three-year-old indicator is rarely of practical value.
3. Add context
Instead of just writing: "IP found inblacklist" is much more useful to see: "IP was used by the FIN7 group in a campaign against the financial sector in June 2026." So the analyst immediately understands the level of risk.
4. Use scoring
Not all sources are equally reliable. It is good practice to assign a level of trust to each source, and regularly recalculate criticality and trust in the indicator. Then a match in several high-quality sources at once will look much more convincing.
5. Don't build detection only on IOC
The most common mistake is to completely replace analytics with IOC lists. In practice, combined rules work much more effectively.
For example, running PowerShell, downloading a file, connecting to a suspicious IP, or creating a new service. All together, it describes the attack much better than any single IOC.
What changes with the introduction of LLM
Over the past few years, Threat Intelligence has started using large language models. And we are not talking about finding new IOCs, but about interpretation.
For example, instead of a set of events: PowerShell, rundll32, certutil, unknown IP, creation of a Scheduled Task, LLM can form a clear explanation: "Most likely, there is a sequence of actions characteristic of loading a payload with subsequent pinning in the system. We recommend that you check the originof the PowerShellcommand and investigate the created scheduler task." Such descriptions significantly reduce the time required for initial analysis of an incident. At the same time, the models themselves do not replaceThreat Intelligence — they help to interpret the data already collected.
Results
Open Source Threat Intelligence remains one of the most accessible tools for improving the level of protection. But its effectiveness is determined not by the number of connected sources, but by how meaningfully they are used.
Good practices include a small number of regularly updated feeds, checking whether indicators are up-to-date, adding context, and combining IOC with behavioral analytics. This approach helps to reduce the number of false positives and focus analysts ' attention on really important events.
Ultimately, Threat Intelligence is not a collection of endless lists of IP addresses. This is a tool for understanding who is attacking, how exactly the attacker is acting, and what steps should be taken to protect the infrastructure. And the less noise that remains after processing open sources, the more likely it is to notice a real attack in time.