Scaling Suricata in the Enterprise - Optimize Sensor Placement

As we’ve written before, Suricata is a high-performance network threat detection, IDS, IPS and network security monitoring (NSM) engine. It is open source and owned by a community-run nonprofit foundation, the Open Information Security Foundation (OISF). Suricata is developed by OISF, its supporting vendors and a  passionate community of volunteers.

From its humble beginnings in 2008 as a signature-based intrusion detection system (IDS), Suricata has now grown into a powerful IDS/IPS/NSM and evolved to include full-featured packet capture, scripting, and network security monitoring capabilities that rivals those of dedicated solutions. In fact, Suricata has in recent years, formed the foundation of many successful commercial products and spawned an incredible ecosystem of independent ruleset/signature and threat intelligence providers.

Challenges

For all Suricata’s capabilities, building out an enterprise-scale deployment of Suricata with mostly open source tools can be a challenge.

For example, in smaller deployments such as in a single office location, keeping the system up to date with the latest signature rulesets and/or threat intelligence can be performed manually and doesn’t take too long. But in an Enterprise deployment with multiple network segments, branch offices and cloud applications, you will want to automate that process to make sure that all the sensors are running in lock step.

In a series of blog posts, we plan to review five ways to improve the scalability of Suricata in an enterprise deployment. In each case, we try to offer a free or open source choice and in some cases we identify straightforward commercial solutions that can provide a fully-supported alternative.

In this first article, we begin with a critical starting point - Optimizing Suricata Sensor Placement.

Note: for a more complete review of all five improvements, please check out the white paper, Scaling Suricata for Enterprise Deployment. You can download your copy here >>

Optimize Your Suricata Sensor Placement

The foundation for effective network detection and response is based on the proper placement and configuration of the Suricata sensors, effectively your eyes and ears into the network traffic. Improper placement from poor planning or misconfiguration can lead to gaps in network visibility, which can allow attackers to go undetected for prolonged periods of time and to penetrate deeper into your network.

Before we discuss the specifics of placement, it is worth mentioning that Suricata may be deployed in either active (in-line) or passive (monitor only) mode. This paper is focused more on monitoring mode, typically of a SPAN/Mirror port. There are two reasons for deploying in passive monitoring mode: 1) the sensor cannot in any way affect the operations of your network and 2) the passive deployment provides greater visibility and more rich metadata context 3) attackers are much less likely to detect and locate the presence of the monitor and it is therefore less likely to become a target itself.

When considering sensor placement, you must thoroughly understand your network topology as well as which are the critical assets on the network that an attacker may attempt to compromise. You have the strategic advantage of knowing your network topology better than the attackers, so, it is crucial that the security team must work closely with the network and IT architects to identify all the critical monitoring points for your organization. Use this knowledge to your advantage.

While it is not realistic to monitor 100% of the traffic passing among all the systems in your network, it is necessary to look carefully at your options to prioritize your activities and maximize coverage.

Consider the following major areas where you may wish improve your network traffic visibility:

• Network edge - most attacks originate from the outside your network, and nearly all incidents result in some sort of communication with a command and control and exfiltration system - also outside your network. If you deploy only one network sensor in your network, it should be at the network edge. Depending upon the scale of your organization, there may be more than one ‘edge’ to your network. These could include your Internet entry/access points, partner/supplier extranet entry points, and remote office connections.
• Remote data center or colocation facility - in many organizations, some of the most critical assets are located in remote data centers. If this is the case in your network, you will want to deploy at least one sensor in that facility to monitor traffic to and from that facility.
• Public cloud resources - if you are leveraging public cloud infrastructure for hosting any mission-critical enterprise applications, you will want to deploy at least one sensor here. Most of the major cloud service providers now provide mirror interfaces that allow you to send duplicate traffic to a virtual sensor deployed in the cloud. As with other deployments in the public cloud, you have the flexibility to spin up or down new sensors fairly quickly to align with the dynamic nature of the resources you are working to protect.
• Remote/branch offices - if your network includes remote or branch offices that are directly connected to the public Internet and contain high-value network assets, you may wish to deploy a sensor on site. If, however, your branch office connections are architected such that they all home traffic to a central location, you can more easily deploy a single sensor at that location and monitor all remote office traffic from there.
• Network segmentation - in all the above examples, you may wish to deploy multiple sensors inside the network to eliminate blind spots AND to instrument individual sections of the network (e.g. for each department) in order to detect lateral (east-west) movement of adversarial activity.

Note: you may either set up the sensors physically near the correct network segment, or you can direct the appropriate traffic to the sensor network ports via a span/mirror port from a central switch location.

When deployed throughout the enterprise network at strategic locations described above, Suricata sensors can provide your security team with excellent visibility and form the foundation of a formative threat detection and response program.

More to Come on Scaling Suricata

In future blog articles, we will cover the other four suggestions that can help you improve the scalability of Suricata in your enterprise:

• Deploy centralized sensor management
• Tune the network of sensors for maximum performance
• Consolidate Suricata alerts and logs from multiple sensors
• Deploy high-level analytics to focus analysts’ time on the the things that matter

Additional Suricata Resources

If you are interested in exploring this topic further, we recommend the following resources:

• Suricata website
• OISF website
• SELKS web page
• SELKS github page
• Just released: Suricata 6 (blog article)
• Suricata dashboards for any ELK stack (open source contribution by Stamus Networks)
• Grafana dashboards for SELKS (open source contribution)
• Suricata user forum
• Strategic Sensor Placement for Intrusion Detection in Network-Based IDS (academic paper)
• Suricata Extreme Performance Tuning (SEPTun) guide - Part 1
• Suricata Extreme Performance Tuning guide - Mark II
• Official Suricata training resources
• Comparing SELKS and Stamus Security Platform (white paper)
• 11 Open Source SIEM Tools (article)
• Splunk enterprise security solutions
• Introducing the Stamus Networks App for Splunk (blog article) 
• Stamus Security Platform(web page)