There are many variables that can negatively impact Snort effectiveness such as modifications to taps, spans and network segmentation. Alerts to a SIEM being blocked, out of sync NTP, and malformed signatures can all cause issues. Ultimately, there are a limitless number of problems that can cause Snort or any IDS/IPS solution to be ineffective.
The problem actually isn’t related to the Snort technology or the security folks managing it. The problem is the lack of continuous instrumentation, validation and configuration assurance in place to ensure Snort is working the way you want, your changes and signatures are effective without succumbing to defensive regression.
Verodin detailed in the 2017 Security Effectiveness Report, that many security incident detection and prevention tools operate with very low success rates. In fact, it is much more common for attacks to be allowed and undetected than prevented and detected. In other words, security doesn’t work more than it works.
To improve security effectiveness, security tools like Snort need instrumentation. Verodin offers the Security Instrumentation Platform or SIP which allows you to measure, manage and improve security effectiveness. For similar deep dives into how SIP helps instrument security products, we’ve written other pieces on how Verodin SIP can be used to help instrument Palo Alto Next-Generation Firewalls and Splunk.
Snort can provide a ton of value, but in order to do so effectively, it requires instrumentation. This piece will focus on leveraging Verodin SIP to instrument Snort.
Let’s start with the Verodin Director pictured below. This is a very simple network environment and for demonstration purposes, we are leveraging Security Onion which offers a number of tools like Snort, Bro, Sguil, and many others. The network zones are made up of Desktop Users, Internal Servers, and the white circles represent the Internet. The Verodin Actors are represented within each zone as black circles.
Now let’s pick an attack to run between Verodin Network Actors. Below you’ll see that the attack chosen is the Angler Exploit Kit. Also, note on the bottom right there are Verodin Common Detection Alerts. In this example note the Emerging Threats (ET OPEN and ET PRO) and Palo Alto messages. This becomes important later on.
When we execute the Angler attack between the two Verodin Network Actors we can see the results below. First, we see that the attack was not blocked. Second, we see that an event wasn’t created. So, not only was this attack allowed but under the current configuration, nobody will even know it’s happening. That, of course, is not the outcome we would like.
So, let’s drill into the results and see if we can improve on this. As shown below, when we click on the results, it brings up the details of the attack, including the before mentioned Verodin Common Detection Alerts. In particular, let’s take a look at ET OPEN highlighted in red.
The ET OPEN Common Detect Alert is linked to the actual signature(s) we can use in Snort. Clicking on the link brings us to the Emerging Threats website (shown below) where we can choose a signature to use. In this case, we’ll use the signature highlighted in red.
We simply copy the rule and then paste it into the Snort rules (local.rules) as shown below. This phase is outside of Verodin. You are interacting directly with Snort at this point.
In addition to the copy and paste you can, of course, make alterations to the signature if you desire. Any time you add or modify within Snort, it’s important to leverage Verodin SIP to validate that Snort is working as desired. Issues might be related to the signature, the device Snort is running on, or entirely outside of Snort such as network infrastructure or VM issues. The alternative is just to add a signature and assume it’s correct, followed by hoping everything will work out when you actually get attacked. Assumption-based and hope-based security is not a foundation any of us want to build our security strategy on.
So now we do some “Snort stuff” as shown below, like running “rule-update” to well, update the rules with the new signature.
After a few seconds and a few internal scripts, Snort finishes making the updates, restarts, and the new rule is committed.
Now we want to validate that everything is working. So, let’s go back into the Verodin SIP Director and re-run the Angler attack between the Verodin Network Actors by clicking on “Run Again” highlighted in red.
Shown below, we see the final results. By adding the new Angler signature into Snort, that we received from the Emerging Threats link within the Verodin Director, we were able to successfully add a signature to Snort and validate, empirically, that Snort is working how we want.
As you can see, the attack still isn’t being blocked and that was to be expected because we didn’t do anything to prevent Angler. However, now we actually have a detection event. Snort detected the Angler attack, thanks to the new signature. It all worked! Snort also successfully forwarded the results to Splunk where we can see the message details as well as the raw event information. So, we’ve also validated that logging from Snort to Splunk is working as desired.
- Using Verodin SIP we were able to successfully validate that Snort was not detecting the Angler attack.
- We were able to use Verodin SIP to find the correct signature, in this case through an Emerging Threats link prescriptively provided the Verodin SIP Director.
- We copied the signature, pasted it into Snort, and updated the Snort rules.
- We ran the Angler attack again thus verifying that Snort did detect the Angler attack and that Snort was able to successfully log the event to Splunk.
A few extra things to consider. Splunk did not create a Splunk Notable Event, which means that the likelihood of a security analyst seeing this would be low. Therefore, it’s important to also tune Splunk to create a Notable Event predicated on a Splunk Correlation Search. To see how to do that with Verodin SIP, take a look at this blog. Instrumentation is most powerful as it relates to the entirety of your security effectiveness across prevention, detection, and response – not just one tool.
Finally, once you’ve got some things within Snort, Splunk and your other security tools working the way you like, Verodin SIP can run automated, continuous validations to ensure that what was working, stays working. If Snort stops detecting, or Splunk stops creating a Notable Event for example, you’ll be notified, thus allowing you to manage by exception. This is nice because it means Verodin SIP won’t require a dedicated FTE. You’ll simply be notified when something breaks.
Security instrumentation is a completely different way of managing, measuring and improving security effectiveness. While this piece is focused on Snort, Verodin SIP helps with security effectiveness across all your security controls across network, endpoint, cloud, and email.