Why you should use Suricata IDS to alert on IOCs

Summary

In this post, I will explain why you should utilize Suricata IDS to alert on Network-Based Indicators of Compromise (IOCs), what are the traditional approach and its limitations, How Suricata will differ & what advantages you will get.

Introduction

Traditionally, SOC Operators used network Indicators of Compromise (IOCs) (eg: domains, IP…etc.) to detect malicious activity in their network.

This is normally done by matching the list of IOCs (obtained from feeds) against the network logs that is extracted from network appliances like firewalls & proxies.

All of the above operations normally happens in the SIEM solution, where it will integrate with the Threat Intelligence Feeds (source of IOCs) and the different sources of logs. Then The SIEM will creates a list of matches that will indicate the presence of an IOC activity in the monitored network.

Although the above approach “works”, it has a list of fundamental limitations:

Problem 1: You cannot match against what is not already extracted, shipped & integrated with the SIEM:

If you are planning to alert on malicious FQDNs (which you should!), there are potential locations where those can be found, including DNS logs, proxy logs, NetFlow data…etc. Each of those data sources needs to be shipped & integrated with the SIEM first so that they can be used.

Integrating multiple logs sources requires considerable amount of time depending on the SIEM used & type/number of logs sources.

Problem 2: To find the needle in the haystack, you need to have the full haystack

If you are only collecting blocked network communications from your network firewall, you might miss malicious network activities that were not blocked, in which you need to collect the full communications to have complete coverage.

And if you are not collecting DNS logs from your resolvers, you might miss different DNS based threats like malware that uses DNS as a C2 channel.

The above means that you should extract it all, which leads to the third issue.

Problem 3: The haystack is getting bigger & bigger.

The good old days where your network uplinks won’t exceed a 100Mbps are well gone. Today’s network heavy applications easily use gigabits of network bandwidth per second.

This means that the amount of extracted logs or Events Per Seconds (EPS) grows and will keep on growing. This will put a lot of pressure on SIEM solutions since they will have to be scaled continuously.

Letting the cost issue aside, not all SIEM solutions can scale well and you might find yourself spending your time sys-admining the SIEM rather than triaging & responding to alerts.

And to make things worse, if you are not using these extracted logs for network forensics use-cases, most of that data will have a very limited value. This is because malicious network activity will be only a very small fraction of your collected network activities.

All of the above limitations and more can be solved by using modern Open Source intrusion detection system solutions like Suricata to alert on IOCs.

Features like IPRep & DataRep introduced in recent versions of Suricata allows you to match millions of network-based IOCs (eg: domains, IPs…) against 10’s of gigabits of network traffic.

But how this will solve the above issues? Let me explain

1. no need to integrate 10 different data sources into the SIEM to be able to alert on IOCs

Suricata can do it all, it already supports all the famous network protocols and the list is growing, this means it can see and alert on malicious traffic that your dns resolver, your firewall & proxy sees, all in one place.

This means that you will be able to have more visibility with less integration & configuration.

2. Suricata sees it all

Since Suricata operates on network traffic, you are no longer limited to the visibility of your log source or SIEM. as long the malicious activity has detectible network footprint, Suricata will be able to alert on it.

For Example, even if your network clients are bypassing your local DNS Resolver by using a public one (eg: 8.8.8.8), Suricata will still have visibility on these activities while you DNS Resolver logs will not!

3. Suricata will only send you what you need

Having a miss configured server that is flooding your SIEM with useless logs? Forget that, Suricata will only send you alerts of IOCs matches, no more, no less.

This means that you will only need to store a fraction of the amount of data (or EPS in SIEM terms) in comparison to the traditional approach.

Moreover, with features like thresholds, you can reduce the amount of alerts data even more!

And although Suricata can extract NetFlow-like & dpi-like data, if you do not have a network forensics use-cases then probably you don’t need all of this data.

4. bonus: Suricata will give you more context

Having access to payload data is extremely useful when triaging malicious network activities.

Suricata do provide you with both base64-encoded and printable payload data, while most of the traditional log sources only extracts certain fields from the supported protocols.

All the above advantages that Suricata offers can be utilized today with minimum effort if you are using IDSTower.

How IDSTower can help?

IDSTower not only will automatically setup & configure those features in Suricata, it will also Integrate with Threat Intelligence Feeds to download IOCs and push them to Suricata, all with a single click!

If you are interested to learn more on how IDSTower can help you enhance your network security operations, please take a look at the Features that IDSTower offers.