Snort or Suricata to replace Sourcefire??

zenlakin

Hello all. I recently switched jobs and am now working on a small contract and they currently have Sourcefire appliances implemented. This is a perfect time to figure out the plan moving forward with the Sourcefire appliances as they are currently end of life at the end of this year and I have been tasked to research and work with the Chief Architect to decide what we want to do for IDS/IPS moving forward. The issue right now is that the contract doesn't have a ton of money and Sourcefire quoted us around $200k to upgrade our existing system to the latest version of the software, upgrade our licensing and our appliances. That seems like a pretty hefty price to pay when from what I seem to be seeing is that the Sourcefire appliances are basically just a commercial version of Snort with a few extra features. My question is would I be able to get the same functionality out of implementing servers and vm's with Snort or Suricata with the ETPro Ruleset subscription in regards to IDS and IPS functionality as I am currently getting out of or could get out of Sourcefire? Or am I missing something?

docrice

The Series 2 appliances are being replaced by Series 3 which have additional capabilities, namely application detection, FireAMP, firewalling, and others.

In your case, one of the main considerations is the deployment model. Is this for inline or passive operation? If strictly passive, then going completely open source and ditching the commercial offering leaves you without the application identification and malware file trajectory functionality (although the latter is a separate license). That said, OpenAppID is now in alpha and this looks promising. You also need to consider the $500/sensor licensing cost for ET Pro.

Another consideration is the management console. Defense Center is nice, but can be complicated if you're not used to it. However, there are lots of bells and whistles including centralized user authentication, health policies, decent user activity auditing, customizable dashboards, etc.. Upgrading sensors is relatively straightforward without having to download the tarball, recompiling with the right options, etc.. You also have more contextual data to integrate with including Qualys/Rapid7/Tenable vuln data (assuming you're a customer of theirs) and other adjacent information like detected operating systems, usernames, and Active Directory integration (basically FireSIGHT) which can help tune your preprocessors. Flow data can also be passively collected. FireSIGHT-based recommended tuning is also a nice semi-autopilot feature.

What interface would you use to manage events if you go the open source route? Sguil? Snorby? I like Sguil a lot in the sense that it's very much more real-time than Defense Center, although in DC you can configure the Intrusion Events view to refresh every minute. The closest thing I've seen to this sense of real-time in a commercial offering is McAfee's IPS although that's very Java-heavy last time I saw it. I haven't played enough with Snorby to have an opinion, although it looks very nice.

If you're going inline, then personally I think it's a different matter. As a general rule, I prefer commercial support for inline operation if it's a critical-path sensor placement. If your sensor suffers a failure, being able to call their support and getting things turned around without resorting to running to the nearest computer parts store to fix things is a big convenience when time is a factor because the hardware is pretty consistent (plus you're outsourcing the blame when failures occur, I guess). Sourcefire's support has been pretty good in my experience.

There are a number of other small things you'll miss from Sourcefire, but if you're going completely open source (like rocking Security Onion for passive monitoring), you're talking an extended ballgame with full packet capture, although you'll need to invest properly for disk storage. As an IPS/IDS offering, Sourcefire is the closest commercial solution I've seen that comes close to NSM, but Security Onion is not meant for any inline operation work (although you could technically make it so).

I think there's a lot more time and investment necessary to size and tweak a Snort/Suricata environment, but I can see the potential savings. That said, depending on your comfort level with maintaining Snort upgrades, etc., the extra time spent and its associated costs are going to factor into your decision.

So those are a few thoughts off the top of my head without really knowing more about your hard requirements. Ultimately it really depends on what your operational needs are and the resources you have to maintain an open source deployment in terms of upgrades and tweaking.

zenlakin

Thanks for the detailed explanation and response Docrice. So the way I am reading this it appears in my environment we may be better off going with the vendor supported option as we are going to want to do inline and enable the IPS functionality and also, if I did the open source route I would be the one on the hook for all updates, tuning and management of the system as a whole which could be a full time job in itself.

docrice

In my personal philosophy, when going inline (in a very high-value location in the topology) it's pretty nice to have commercial support because it's "certified" hardware and there's an external neck to choke when something goes wrong. But that's just me. There may be other incentives to not worry about that (such as up-front capital savings and the associated support contracts).

IDS/IPS is a full-time job regardless of whether you go the commercial or open source route. I think there are pros and cons for both. I think Sourcefire's commercial offering has some nice benefits and whether the cost for them are worth it will depend on your staff levels, their expertise in the subject area, and so on.

Sourcefire is expensive, but it's because they expose a lot of tuning controls as they sell you the solution based on the idea of understanding intrusion detection at a lower level than other vendors and adapting your sensors to your environment. There's better situational awareness this way, but it does require more dedicated resources and skill to manage it. Other vendors typically do the "we'll write the rules for you, we won't show how you they work at a low level, and all you can do is either whitelist the IP or disable the rule during false positives" route. To me that's not really intrusion detection work and cheapens the approach to security. Often there's no documentation on how the engine internally works and if any rules you write can effectively override any factory rules you wish to keep enabled. With Sourcefire/Snort, this documentation has been available for free for a long time.

If you're very comfortable with Snort/Suricata and the maintenance involved for upgrades, configuration file changes, and so on, and your organization is willing to allocate the time and take the potential risk when the whitebox hardware fails on a rare occasion, then there's probably less benefit going the Sourcefire/Defense Center path.

No commercial hardware is perfect either as I had a Sourcefire sensor seemingly go bad on me when it stopped processing traffic through an inline pair (even though I got no health alerts or there weren't any performance metrics indicating load issues). Then again, there's always the rare occasion when a Cisco switch port goes bad as well.

Every vendor product that I've used which had IPS capability (including firewalls which had IPS functionality bolted onto them) has failed on me at a hardware level in one way or another, even though it wasn't specifically IPS-related. I did like the fact that I could ring up the vendor support and get an RMA established for immediate turnaround, although the response time is ultimately dictated by the support level agreement you sign up for.

If you haven't already, I recommend going through the Sourcefire System v4.10 or v5.2 admin guides and see what the functional comparison to open source Snort is. Yes, they're large documents, and Sourcefire does offer a four-day training class on just learning their system, but this will help clue you in whether to keep the commercial hardware or just go open source.

docrice

I forgot to mention the other nice benefit with Defense Center - reporting. The customization with reporting is pretty nice and these can be emailed to you on a schedule. Many things can be put on a schedule as well, like pulling down updates, pushing new updates out to your sensors, getting the GeoIP updates, backing up the database (which you can elect to do to an SMB share, etc.), and so on.

Reporting can summarize/detail things like events, impact, categories, etc. but also provide auditing on which user accessed which Defense Center menu sub-item at which time, etc. so you see a working trail. For some environments, having this visibility is helpful as analysts are exposed to very sensitive data.

zenlakin

Thanks again for the thorough response. For the maintenance and management of the tool, it is mainly going to be on me so as I am thinking about it more I am thinking that since our team is small and there would be a large amount of training needed, it would be best to pursue the upgrade of the Sourcefire implementation and also maybe see if we can work in some training as part of purchasing the upgrade.

docrice

Sourcefire training is good, but I don't think it really provides good security analysis training for intrusion detection, as odd as it sounds. Sure, there's some of that involved with a little bit of rule writing exercises, but vendor-specific training in general is going to be about deploying and maintaining a commercial solution.

If you're going to send multiple people to training, something you might want to consider is sending one person to the Sourcefire class, another person to SANS 503 (since there's a day just for Snort), and perhaps another person to do the Snort Rules Writing class (by Sourcefire). This will provide three different angles to the art and science of intrusion detection, and then have the staff cross-train each other.

Another good intrusion detection class (although not Snort or Sourcefire-specific) is Richard Bejtlich's Network Security Monitoring 101:

https://www.blackhat.com/us-14/training/network-security-monitoring-101.html

This is probably his old TCP/IP Weapons School 3.0 class remolded into a Security Onion-based NSM workshop. I felt his old class complemented SANS 503 pretty well.

zenlakin

So the latest word after speaking with our Chief Architect yesterday is that he is thinking of just going with a deployment of Next-Gen firewalls and utilizing the IPS functionality of those in the environment instead of upgrading the deployment of the Sourcefires...

docrice

Sourcefire Series 3 appliances actually do "next-gen" firewalling (just needs the proper licenses for the application identification, FireAMP, etc.). Given the recent Cisco acquisition, I wonder how it'll fit into the overall Cisco product scheme since the ASA-X series are also generally capable of doing this. Most firewall vendors have what is now referred to as "next-gen" capability, but Palo Alto Networks sort of popularized the term (and over-hypes it, in my opinion). I'm going to avoid using this unnecessarily over-marketed term for the moment because it's such buzzword splashed all over the industry.

If you're considering going with other vendors, one thing that you should be conscious of is what your actual intrusion detection/prevention needs are. Most firewall companies eventually migrated into the IPS space by including IPS functionality, which is a natural transition. Sourcefire went the other direction by being an IPS company first then adapting into the firewalling space. From an IPS, tuning, and event analysis/contextual perspective, I find Sourcefire's solution generally far superior, but this makes for a much more complicated solution. However, from a firewalling perspective I wish their hardware had better port density. I think Sourcefire's approach to it all makes a lot of sense, but it's certainly a handful. If you're a small shop and your intrusion detection/prevention needs are relatively superficial, then I think the Defense Center interface is relatively convoluted.

It sort of comes down to how you deal with intrusion prevention, which I find falls into two camps: let the magic box from the vendor do all the work and assume it knows what it's doing, or get your hands dirty and really learn the nuances of your environment and adapt your tools to it. While I'm an advocate of the latter, there's significantly more effort and skill to maintain that because real intrusion detection and prevention as a craft is not a set-and-forget it approach.

I haven't been happy with the relatively simplified/dumbed-down IPS capabilities of most other vendors. In my environment, every vendor (including Sourcefire) will false positive frequently out of the box (and they should, because if they don't there's something wrong with their solution) and while I've had firewall vendors come in and immediately claim, "Oh, we can replace your IPS easily," I find that firewall salespeople are generally not intrusion prevention oriented (and quite frankly don't know what they're talking about).

The skill of a firewall engineer and that of an IDS/IPS engineer/analyst are quite different, even though there's a natural overlap to some degree. In the event of a false positive, I must be able to write rules without disabling the factory rule (assuming it's still relevant) and without whitelisting IPs. Therefore the rule creation methodology and syntax along with the packet inspection workflow must be transparent to me. I'm not a fan of vendors who purposely hide their rule/signature syntax because when validating events, I don't actually know what the black box is specifically doing at the bit level.

But firewall-centric devices tend to be relatively much easier to manage from a UI perspective, generally have better port density, and from a staff training perspective are more "accessible" due to the straight-forward management. I've seen Fortinet/Check Point/Palo Alto Networks/etc. and I like each one for different reasons, but I also wouldn't consider their IPS best-of-breed (if you'll excuse yet another old buzzword). As you might surmise, I'm not a huge fan of the all-in-one-box approach, but I'm nitpicky and have very specific requirements. For organizations that don't have the resources (nor care) about doing in-depth investigative/analysis work for intrusion detection and prevention, Sourcefire is probably overkill. I hate to put it that way because there are a lot of folks out there who don't understand what intrusion detection is about and I don't want to give the impression that complex solutions like Sourcefire is unnecessary, but if your resources can't handle the tuning and adaptation workflow, then a Defense Center approach will be unmanageable.

For me, context and being able to tune is everything. Nothing beats Sourcefire (Cisco) in this regard that I've seen. If I can't write rules for my environment, I can't maintain situational awareness. The other IPS solutions bolted onto other firewall vendors tie my hands which is why I prefer analysis-centric approach.

Matodo

I've just read the whole post, because I've not read anything before that best represents my thoughts.


Great explanations docrice!

melpower79

Hi Docrice,

I have read through forum and totally agree with you and thank you for all the knowledge and information. I was wondering if I can ask you for some info. How much time( days i.e 8 hours per day) do you think it would take to upgrade 6 X sensors and 1 X DC from v4.10 to v5.4. and what are the things that we need to be aware of pre/during/post upgrade. I really appreciate your assistance.
Cheers

docrice

Upgrading from 4.x to 5.x requires a re-image of the sensors and Defense Center (now re-branded as FireSIGHT Management Center). There's no direct migration path where you install the newer software. You'll likely need to follow a careful series of steps to get to 5.4, and the amount of time will depend on the size of your databases, any maintenance windows or downtimes involved if you have inline sensors, etc..

Best consult with Cisco/Sourcefire support or your account manager (who will likely call in sales engineers) to help gauge migration time.

Another option - if you're running series 2 equipment, now is probably a good time to refresh the hardware with series 3.

jamthat

Holy crap, great stuff docrice. We're about to start an eval of the two big Cisco acquisitions (Sourcefire/Lancope), and I just had to say this was an incredibly useful read. My fear is that if we continue down the Cisco path into their 'next-gen' world, it'll become completely unmanageable and under-utilized given the size of our team..other vendors may make much more sense. Time will tell..

Sorry to bump this old thread, but at the very least it'll be seen by more people.

docrice

It's not necessarily just about the size of the team, but also the available skill set and in-depth mindset. Too many vendors try to dumb complexity down to a dashboard and some UI buttons, but that tends to oversimplify the problem resulting in a lack of awareness. For this reason I tend to much prefer solutions which are flexible/complex over ones which seem to be magic boxes but make too many assumptions. It requires more homework for sure.

Not everything is ready for automation in this evolving threat landscape.