Service Provider Takeaway: Learn how to support Snort with complementary tools and techniques when necessary.
As an independent security consultant I offered a course to customers called Network Security Operations, which covered network-centric intrusion detection, response and forensics. Students often asked, "Is this the Snort course?" And I answered, "Not exactly, but you're probably in the right place."
I've been inspecting and acting upon network traffic for 10 years. When I tell people that I use network traffic as one means to detect and respond to intrusions, many respond by saying, "So you use Ethereal, right?" I find myself responding in a similar manner to the Snort question: "Not exactly, but sometimes."
Both of these questions point to customer perceptions of common ways to detect and respond to intrusions. The digital security field is incredibly complicated and anyone who claims to be a master of the entire field is a fool. In fact, mastery of any single subject might require such narrow focus as to be of little relevance to the remainder of the field. Those who are most successful have carved some niche out of the security landscape, but still understand the rest of the arena.
Similarly, it's important to understand how a network intrusion detection system (IDS) like Snort and techniques based upon its use fit into a holistic detection and response operation. Placing Snort within an entire security program is too broad a topic to cover in this Snort Report. Rather, let's consider when a tool like Snort is independently helpful and when you should support Snort with complementary tools and techniques.
The simpler the task that Snort is asked to complete, the more likely it can operate completely by itself. In the first Snort Report, I described how Snort can act as sniffer, packet logger...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurityChannel.com
or alert generator. As a sniffer, Snort reports traffic to the console. Unless you have serious misconceptions about Snort's ability to render traffic to the screen, you don't need to run a second sniffer. The same holds true for packet logger mode. Properly configured, Snort logs packets in a manner similar to Tcpdump, Wireshark, Tshark, Dumpcap, Daemonlogger and other tools. Each has its quirks -- I prefer Daemonlogger within the Sguil framework -- but all essentially log traffic and can be standalone tools.
Once alert generation (intrusion detection) mode is enabled, the matter becomes complicated. Snort is no longer rendering or logging -- it has become a Traffic Intelligence System (TIS), as described in the last Snort Report. A TIS is valuable if it's trusted. Trust comes from being able to understand how a tool came to a certain conclusion. For example, if Snort reports seeing Attack X, you want to know how Snort made that judgment.
In simple cases, it should be easy to understand why Snort generates a particular alert. If given a simple rule and configured to report the packet that triggered that rule, Snort should provide enough information to convince you that it acted properly. In production, however, this foundation can be eroded by complicated rules, complex algorithms, insufficient context and production of "pseudo-packets" that Snort builds but that never really appeared (in that exact manner) "on the wire."
For these reasons and more (which are suitable for another article), I prefer supporting Snort with other tools, supplemented by other techniques. This isn't a criticism of Snort. It's unreasonable for anyone to rely on a single tool or technique for a problem as difficult as digital detection and response.
Using additional tools and techniques to support Snort serves two functions. First, they provide evidence to investigate when Snort points to an item of interest. Second, they provide some degree of accountability. If Snort fires a particular alert, in the absence of complementary evidence, you must decide whether to trust it, based solely on what it says. When additional evidence is present, you can inspect the complementary data to see if it corroborates Snort's findings. Ideally, Snort and the supplementary data reinforce the same conclusion.
So what sort of data do I recommend collecting? I have advocated what I've termed "Network Security Monitoring" or "NSM data" for several years: full content, session, statistical and alert data. Full content data is traffic in Libpcap format, captured completely independently of Snort by a separate process. Session data is flow or transaction information, again collected independently of Snort by a separate process. Furthermore, the sessions aren't derived from the full content. Statistical data is a high-level overview of traffic, not based on anything collected by other processes. Alerts are judgments made by tools programmed to raise red flags when certain conditions are met. Snort is one such tool, but others are available (Bro is another).
At the end of the day, you can never have enough data. The problem is balancing investigation requirements against performance, storage and management requirements. Anyone who spends a serious amount of time in this field will decide that a tool like Snort isn't enough without support, but it's incredibly powerful if used properly.
About the author
Richard Bejtlich is the founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.
