How to reduce the load on SIEM and make good use of threat-intelligence feeds

Initially, SIEM systems were created as a tool to collect information about security events within infrastructure and analyze them using external data on known cyberthreats. And for a long time, they did their job just fine. However, as both threats and the information security industry evolve, more and more threat-intelligence feeds are appearing on the market. And what’s more, their structures are significantly changing. It has become obvious to many experts that a new tool that allows navigating threat-intelligence flows is required for SIEMs to work effectively.

Why did SIEM need an assistant?

At first glance, it may seem that the more external cyberthreat data feeds you connect to your SIEM system, the more effectively it should do its job. But this is in fact not the case.

First, the more indicators a system handles — the more alerts it generates. Even if we assume that there’s a minimum number of false positives (as no one is immune to them), an analyst won’t be able to quickly navigate through millions of duplicate notifications and prioritize the important ones.

Second, existing SIEM systems are simply not designed to handle an infinite number of indicators. When you connect multiple feeds, the workload on the system increases significantly, which can have a negative impact on the incident detection rate. The same may happen if you try to implement a scenario of frequent TI-feed updates. Not that it’s completely impossible, but performance and detection rate may suffer.

In addition, a SIEM system is not suitable for more detailed work with threat-intelligence feeds directly. For example, it cannot compare the quality and detection rate of feeds from different vendors or handle different types of masks from feeds with indicators of compromise represented as URLs, hosts or domains. If an analyst needs deeper context for any indicator, an additional tool is required (and it doesn’t matter that in fact the context needed may exist in the feeds — SIEM may just not know how to access it). Finally, keep in mind the economic factor. Most SIEMs offer load-based licensing: the more indicators it processes, the more you have to pay.

How a threat-intelligence platform can help

In general, a threat-intelligence platform can resolve all the above disadvantages of SIEM systems. But to start off with, it’s an indispensable tool that allows you to navigate through a multitude of feeds from different vendors. You can connect several feeds (not necessarily in the same format) and compare them based on different parameters. For instance, you can detect indicator crossovers in different feeds, which should help to identify duplicate data flows and possibly reject some of them. You can also compare feeds based on statistical detection indices. Taking into account the fact that some vendors offer a test period to use their feeds, this might be a good way to assess their effectiveness before buying.

A threat-intelligence platform also provides the SOC analyst with many additional capabilities that simply cannot be implemented in SIEM. For example, a retro-scan feature is available, allowing double-checking of previously saved historical logs and data with reference to new feeds. Another available feature is the enrichment of indicators from various third-party sources (such as VirusTotal). Finally, a decent threat intelligence platform, starting from a specific alert, allows finding and downloading an APT report detailing the tactics, techniques and procedures of the associated attackers, as well as practical advice on how to apply countermeasures.

A threat-intelligence platform allows you to filter and download indicators, sort incidents, present all the above in a graphic interface for the convenience of the analyst, and much more. It depends on the functions of each specific platform.

How a Threat Intelligence platform fits into an analyst’s work and SIEM

By and large, a threat-intelligence platform installed on a company’s internal network performs the process of analyzing and correlating incoming data, which significantly reduces the load on the SIEM system. It allows you to generate your own alerts when threats are detected. What’s more, it integrates with your existing monitoring and response processes through an API.

Essentially, a threat Intelligence platform generates its own feed of data with detections, customized to the needs of your company. This is especially useful if you have multiple SIEM systems running in parallel on your infrastructure. Without a threat-intelligence platform, you’d have to load raw feeds into each of them.

A practical example

Let’s take a look at a fairly simple incident to see how a threat intelligence platform helps analysts. Imagine that a corporate user accessed a website from their work computer. In the threat-intelligence feed, the URL of that site is listed as malicious, so the platform identifies the incident, enriches it with context from feeds, and sends that detection to the SIEM system for registration. Next, this incident comes to the SOC analyst’s attention. The analyst sees the detection from the Malicious URL feed and decides to take a closer look at it, using a threat intelligence platform.

Directly from the detections list, he can open contextual information available from the TI flow: IP address, malicious file hashes associated with this address, security solution verdicts, WHOIS service data, and so on. For clarity, it opens a graph interface — the most convenient way to analyze the attack chain.

So far, there’s not much information: it sees the detection itself, the malicious URL detected, and the internal IP address of the machine that someone used to access that URL. By clicking on the malicious URL icon, it asks for known indicators related to that address: IP addresses, additional URLs, and malicious file hashes that have been at some point downloaded from that site.

The next step is to check whether other detections have been registered in the corporate infrastructure using the same indicators. The analyst clicks on any object (e.g., a malicious IP address) and displays additional detections in the graph. In other words, they can find out in a click which user went to which IP address (or on which machine a URL request from the DNS server returned the IP address). Similarly, it checks which users have downloaded the file whose hash is shown in the associated indicators.

There may be thousands of detections in a single incident, and it would be quite hard to sort them out by hand without the TI platform’s easy-to-use graph interface. All available context from cyberthreat data feeds is pulled to each point in the graph. The analyst can group or hide objects and apply automatic node grouping. If the analyst has any additional information sources, she can add an indicator manually and independently mark its correlations.

Therefore, the expert can reconstruct a full chain of attack and understand the way everything started. For example, a user typed the URL of a malicious site, the DNS server returned the IP address, and this user downloaded a file with a known hash from the site.

Conclusion

A high-quality threat-intelligence platform serves as a kind of intermediate link, allowing to significantly reduce the load on the SIEM system without compromising the quality of detection on the one hand, and to ease the life of the analyst on the other.