You may be surprised to learn that Suricata produces not only IDS alerts but also produces logs of protocol transactions, flow records and full packet capture. In fact, even with rules completely disabled, Suricata will capture and log all protocol transactions. In this and subsequent articles we will illustrate these lesser-known capabilities through a real-world example.
Much has been written recently - by security pundits and vendors - about the value of combining and correlating network protocol and flow logs and security event or alert data. And for good reasons.
Combining these into a single system provides much more complete visibility into the network activity and enables broad-spectrum threat detection based on signatures, threat intelligence feeds as well as AI/ML-based anomaly detection. In addition, the protocol data provides valuable enrichment and context to the security events and can be used to identify and correlate activity associated with a given asset under attack.
Unfortunately, many still believe the old misconception that you must combine two or more different network engines to achieve this.
The truth is, Suricata natively delivers not just IDS/IPS detection and alerts, but also all the supporting evidence offered by protocol transaction logs, flow records, full packet capture and extracted files. And it does so with a single, high-performance engine (currently proven to perform at 100Gbps) with zero integration required among these functions.
So in most practical cases, you need only Suricata to generate all five types of network telemetry required for what's now being referred to as "open NDR."
Strangely, there are not many Suricata implementations that take full advantage of this fact. As we will demonstrate in this series of articles, the SELKS open source distribution was the first turnkey implementation to incorporate all these Suricata capabilities.
As long time Suricata experts, our team at Stamus Networks has taken full advantage of this native capability in our commercial Stamus ND and Stamus NDR as well as the open source SELKS solutions built on top of the Suricata engine.
The good news is, that you can take advantage of all of this capability in your Suricata implementation, too.
In future articles, we will use a single packet capture (PCAP) file run through Suricata to illustrate these native capabilities.
Suricata started as an open source intrusion detection system (IDS) / intrusion prevention system (IPS) twelve years ago in response to the performance limitations of existing open source systems. Thanks to a fanatically-dedicated team and the community’s help - Suricata has continuously evolved to stay relevant.
Earlier IDS/IPS platforms struggled to provide users with protocol transaction records needed as forensic evidence to support an incident investigation. This led many to perceive “IDS is useless because it simply overwhelms me with alerts with no context.”
Committed to overcoming these limitations, the OISF and Suricata community developed Suricata into a full blown network security monitoring solution. As a result, Suricata is now able to capture protocol transactions and network flow records to provide evidence, enrichment and correlation as a valuable complement to the original security events.
Note: for a detailed chronological review of Suricata history, see the blog post Suricata: The First 12 Years of Innovation written by my colleague, Éric Leblond.
So, you may be surprised to learn that Suricata produces not only IDS alert logs but it also captures protocol data - including flow records and transaction logs. In fact, even with rules completely disabled, Suricata will analyze and log all protocol transactions.
Each log record -- be it an alert log or a specific protocol like HTTP, TLS, SMB, KRB5, etc -- has a flow_id record. That flow_id is unique for the whole session/flow. All logs from that flow share the same ID. For example when Suricata generates an alert associated with a visit to a specific web page, it also generates HTTP transaction logs for that flow along with the file transactions, user agents, URLs, full HTTP headers and more.
Suricata can operate in the following modes:
In the next few articles, we will try to shed some light on what Suricata can produce using an example provided by reviewing a single malicious PCAP.
Additionally, learn more about getting more out of Suricata.
The second article in the series is entitled, "Suricata Myth Busting: Alerts and NSM." You can read it here >>