The importance of PulledPork

Bottom line up front:  If you aren't using PulledPork, you are going to have a gigantic depreciation in functionality.

You've heard it said on the Snort lists, you've heard it on this blog, you've heard it on Twitter,  you've heard it from CNN...  okay, well, not CNN..

The importance of PulledPork.

The reason that we are very heavily insist that you are using pulledpork is primarily for two very big reasons:

1. Flowbit auto-resolution
2. Default Policy usage

• The first reason: Flowbit auto-resolution

I've written in great length about the need for flowbits, you can find a couple of my blog posts here
http://blog.snort.org/2011/05/resolving-flowbit-dependancies.html
and
http://blog.snort.org/2011/12/if-you-are-having-problems-with-your.html

The reason that I'm writing about it again, is that to refresh your memory back when we created the file-identify rule category:
http://blog.talosintel.com/2011/11/say-hello-to-file-identify-category.html

We outlined that part of this conversion was to move all flowbit names from their old names (such as http.gif) to a new format (now file.gif).  This project has now been completed and all flowbits across all files have been moved to the new format, and all the rules that "set" flowbits have been commented to be "off" by default and in no policies.

What we are relying on here is either if you are using PulledPork or the Sourcefire product, you either select your base policy (which I'll talk about in section two), or, even if you don't, PulledPork will auto-resolve the flowbit "set" names that you'll need and go through and turn those on for you.  That way you are only running rules that you need to have on based upon either the policy you are running, or the state of the rules.  We really insist that you use the disablesid and enablesid functionality in PulledPork to be able to turn the rules that you WANT for your environment on and let PulledPork auto-resolve all the dependancies you need for you.

• The second reason: Policy usage

There are four states that we place rules in when we create them, three of the states are assigned to policies.

1. Connectivity
2. Balanced
3. Security

The last state is "in no policies".

1. The first, connectivity, means "Connectivity over Security".  Meaning this is a speedy policy for people that insist on blocking only the really known bad with no false positives.  
2. The second, balanced, means "Balanced between Connectivity and Security".  Meaning that this is a good starter policy for everyone.  It's quick, has a good base coverage level, and covers the latest threats of the day.  The policy contains everything that is in Connectivity.
3. The third, security, means "Security over Connectivity".  Meaning that this is a stringent policy that everyone should strive to get to through tuning.  It's coverage is much more exhaustive, and has some policy-type rules in it.  Rules that will alert on Flash contained within an Excel file and things like that.  This policy contains everything that is in the first two.

The last state is "in no policies".  This means that we insist that you look through these by product name or CVE in order to turn them on.  These may not have a fast content match, could be false positive prone, or the vulnerability it is covering is not in a very prevalent piece of software.  

The way we make the decision about what is "on" or "off" by default when you aren't using the policies, is, if it's in balanced, it's on by default, it's it not in balanced, it's off by default.  There are a ton of exceptions to this rule, but this is the general rule of thumb.