Problem solve Get help with specific problems with your technologies, process and projects.

Justifying Snort

Intrusion detection systems like Snort can be invaluable to your customers and their networks. Learn how to justify Snort to your customers by highlighting its capabilities.

Service provider takeaway: Service providers will learn how to communicate the value of Snort to customers.

There's a good chance that as a value-added reseller (VAR) or security service provider, you believe Snort and similar tools are valuable. However, there are plenty of technical folks that believe Snort is a waste of time. The goal of this Snort Report is to help you communicate the value of Snort to those customers whose IT departments are resistant to the open source tool. Although I focus on the value of Snort, you can apply this approach to any similar product.


I believe the majority of objections to the value of Snort stem from the fact that it's called an intrusion detection system (IDS). Looking closely at that label, we should assume that an IDS is a "system" that "detects" "intrusions." The ultimate IDS would be 100% accurate in its ability to perform that role. A simple question flows naturally from the perception that an IDS is supposed to detect intrusions: "If you can detect intrusions, why can't you prevent them?" At first glance this question makes sense. We should prevent activity that has been 100% identified as being an intrusion.

Upon hearing this, IDS salespeople rushed back to their engineers with requirements for an "IDS" that "prevented intrusions." Hence, the "intrusion prevention system" (IPS) was born.

The IDS is usually offline, meaning it listens to traffic on a network tap or switch SPAN port. The IPS is usually inline, meaning it directly sits on the path of production traffic as a bridged network element. The IDS is passive; it doesn't take action based on what it sees. The IPS is active; it permits or denies traffic based on what it sees. Both the IDS and IPS make judgments on the traffic they see using signatures, protocol inspection and other mechanisms.

Let's return to the question that gave birth to the IPS: "If you can detect it, why not prevent it?" It turns out that "I am willing to drop traffic"-type certainty is fairly difficult to achieve when inspecting network traffic. While it's easy to say you don't want to be hacked, converting that into actionable, programmatic logic is exceptionally difficult.

This is not the case for simpler security devices like traditional layer 3-4 network firewalls. Proper network firewall policy says "allow traffic to/from these IP addresses (like Customer A), allow traffic to/from these TCP/UDP ports (like Port 80), and so on and deny everything else." Does this mean traffic from Customer A to Port 80 on your Web server is guaranteed to be benign? Absolutely not.

This is the reason for the relative longevity of the firewall as a security device, despite the myriad problems of this situation. While the firewall was long ago accepted as an exposure limitation device and a point of control, no one with any real security sense believed a firewall would prevent a compromise. The idea was to limit the hosts and services exposed to the Internet and thereby decrease (but not eliminate) the likelihood of being compromised.

An IPS that implements the simplistic protective logic of a traditional network firewall is just that -- a firewall. A firewall allows traffic with certain characteristics, such as an IP address or port. The IPS must make more complex judgments, basing its decision on layer 7 content. We already know this is a difficult problem for an IDS. Why is the case any different for an IPS?

More on Snort
Check out our archive of Snort tips for all of your Snort concerns.

In reality, there's little difference. Actually, there is one difference I'll state here for the sake of fairness, although I doubt all vendors implement this feature. As an inline device, the IPS is in a unique position. Because an IDS is passive, it cannot change the traffic sent to a target in order to make that traffic more palatable to the IDS. The IPS, on the other hand, can implement "traffic scrubbing," performing tasks like reassembling IP fragments and passing them in reassembled form to the target (assuming the reassembled traffic doesn't violate any security rules). Scrubbing helps reduce the potential for insertion and evasion attacks, because the post-scrubbing traffic seen by the IPS is the same as seen by the target.

Aside from scrubbing, it turns out that the IPS suffers from the same problems as the IDS. If the IPS cannot be 100% certain that what it sees is malicious, do we want it to stop the traffic? If you don't stop it, what should you do? A reasonable answer is to fire an alarm. Suddenly we're back where we started; you just defined the operating model for an IDS.

Traffic Intelligence Systems

When talking about the value of Snort, I suggest you abandon the term IDS for something that more accurately describes the purpose of the product and frames expectations appropriately. In my blog post "Operational Traffic Intelligence System Woes," I coined the term Traffic Intelligence System (TIS) "to describe any network-centric product that inspects traffic for detection or resistance purposes." (I used "resistance" instead of "prevention" because prevention eventually fails.)

A TIS provides digital situational awareness. While it doesn't necessarily "detect intrusions," its main purpose is to help you understand what's happening on the network. This is why I deploy Snort -- I want to get some idea of how my network is being used or abused without having to manually inspect traffic myself. Snort takes a look, makes some judgments and leaves the final verdict to me. If I could be so confident in Snort's ability to identify intrusions, then I should implement those capabilities into a filtering product.

I must point out a few other reasons (besides the technical difficulty of identifying malicious traffic) that stop operators from putting Snort into filtering mode. In the companies I defend, Snort is not watching worthless networks. These are production environments supporting business processes and operated by other teams. These competing interests are seldom likely to agree with deploying a product that can stop traffic based on criteria that can be tough to troubleshoot or even understand.

Another problem is the acquired taste for network intelligence. Far too many security professionals put all their faith in so-called "prevention" and have no Plan B when prevention fails. This crowd is unlikely to see the value in products like Snort that, instead of definitively pointing to attacks, provide indicators of attacks. Such indicators could include unusual traffic volumes or timing, traffic to unexpected parties or using different services or methods. While none of these elements is 100% reliable as an intrusion indicator, they do merit investigation. This is network intelligence backed for network forensics, a realm where the highest-end security analysts operate. This is the place where you'll find counter-intelligence operations, military organizations and very mature industries like the financial sector.

The bottom line is that if you treat Snort as a Traffic Intelligence System, it will succeed. You'll gain a better understanding of what's happening on the network. You won't necessarily learn exactly what's happening without collecting additional data, which is where I introduce the concept of network security monitoring. That is the topic for a future Snort Report. If you insist that Snort is an IDS (or think in the literal terms of what "IDS" means) you'll run right toward an IPS, then find yourself at a dead end. IDS may be "dead" but TIS will never die.

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.

Dig Deeper on Managed network services technology

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.