Multiple Perspectives on Security

Security Journal

Subscribe to Security Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Security Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Security Journal Authors: Pat Romanski, Zakia Bouachraoui, Elizabeth White, Liz McMillan, Terry Ray

Related Topics: PC Security Journal, Cisco Virtualization Journal, Security Journal, Telecom Innovation

Blog Feed Post

SIEM NetFlow Support: Don’t Sell Yourself Short

This is a conversation I find myself having more and more lately so I thought it would make sense to discuss in detail just exactly how security information management systems (SIEMs) and NetFlow are related and why SIEMs are a poor choice for NetFlow collection.

Customer: Adam, we have a SIEM from Vendor X. They say they already support NetFlow. Why would I need a Scrutinizer NetFlow Analyzer?

Adam: The SIEM community has confused things a bit for the customer. In response to the recent surge in NetFlow popularity, many SIEMs have added bare-minimum “check box” NetFlow support just to stay competitive. Comparing SIEM NetFlow support to an advanced flow collector such as  Scrutinizer is like comparing MS Paint to Photoshop. Sure MS Paint works, but it doesn’t do much.

Customer: Okay then, explain to me the difference between my SIEM’s NetFlow support and Scrutinizer’s NetFlow support.

Adam: Sure. First of all, let’s make one thing clear: Scrutinizer is not a SIEM and doesn’t directly compete with a SIEM. It’s a NetFlow and IPFIX Analysis technology that compliments a SIEM. Scrutinizer exports syslog events just like any other IDS, firewall, or network device. It’s better to think of Scrutinizer as a flow-based threat detection technology that feeds alerts into a SIEM, rather than something that would compete with one. Just as a traditional IDS uses packets to fuel its analysis engine, Scrutinizer uses flows to detect network-based threats and traffic bottlenecks.

Let’s talk through the various challenges a SIEM faces when collecting NetFlow:

Capturing and storing NetFlow isn’t enough.

You’ve got to analyze the incoming flows, not just grab them off the wire and dump them to disk. Flows are really only useful when you apply some intelligence to them, otherwise they’re just simple audit trails. Most SIEMs shove NetFlow records into a database or flat file, check the “NetFlow Support?” box, and call it a day. Scrutinizer not only stores the flows to disk but also generates dozens of charts, top talker reports, trending views, security alerts, and customizable thresholds.

Flow Analysis is a full time job.

SIEM vendors have their hands full developing connectors for a large variety of inputs such as syslog, SNMP, event logs, and proprietary log formats. To get the most out of NetFlow, the vendor must really understand the dozens of NetFlow fields and capabilities that are available. While flows are much more powerful than syslog, they’re also a great deal more involved to implement correctly. Ask your SIEM how many developers they have working on their NetFlow capabilities. Plixer’s entire engineering staff is focused exclusively on NetFlow and IPFIX development. It’s our full time job.

NetFlow is rapidly evolving.

In just the last two years we’ve seen such NetFlow innovations as MediaNet, NBAR, PaloAlto’s application-aware flows, and Cisco’s ASA NAT tables all make their way into NetFlow exports. The NetFlow community, especially Plixer, is in constant communication with the various infrastructure vendors helping test and develop new fields that can be used by the collector to report on an increasingly deep set of network statistics. Most SIEM vendors barely even support NetFlow v5, much less the latest and greatest from Cisco or the IPFIX community.

Performance is a major issue.

For most vendors NetFlow is an after thought, a bolt-on recently and almost always inadequately implemented. Most SIEM vendors don’t realize that one of the core values NetFlow provides is its ability to provide visibility into many different places within the network simultaneously. When you turn on NetFlow from the edge of your network all the way down to the access layer you get an amazingly deep view of the what’s going on but you’ll also generate a *lot* of flows. Ask your SIEM vendor how many flows per second their collector can handle while also doing its normal “SIEM thing”. A single Scrutinizer instance can process up to 100,000 flows per second. The unfortunate part is that the SIEM probably doesn’t even support MFSN detection so they can’t even tell if they are missing flows. They’re blind to their own shortcomings.

Flows are not events, they are flows.

Most SIEM vendors force NetFlow fields into their own event-oriented data structures. This makes sense for them given the fact that SIEMs are designed around the notion of a point-in-time event. NetFlow records are on-going and can last for anywhere from 1 second to many hours. This makes reporting on NetFlow rather awkward for most SIEMs. They are trying to force a sustained flow into a point-in-time event and it simply doesn’t work well.

SIEMs are oriented entirely toward security.

SIEMs rarely provide basic NetFlow reporting features such as Top Talkers, Interface Utilization, Capacity Planning, QoS Reporting, MediaNet reporting, or topological representations of the NetFlow exporters. This absence is a result of the SIEM’s core buyer: the security analyst. One of NetFlow’s core strengths is that it provides visibility into the network for both security and network purposes. Most security people that see the reports that can be built from NetFlow often wonder how they got along without them before.

NetFlow is often a “check box” feature.

Most SIEM vendors only recently added NetFlow and did so because the customer said something like “if you don’t have NetFlow support we’ll have to go with someone who does” so they added the bare minimum to be able to check the “NetFlow Supported?” box on the RFP. Check Box features are unfortunately common place in the vendor community. Watch out for them. Don’t sell your team short on the value NetFlow and IPFIX can provide.

One closing point to make: it might still make sense to send some of your NetFlow, especially from the Internet gateways or critical resources, to the SIEM. Sending the same flows to multiple collectors is common practice and easy to accomplish using the Scrutinizer UDP Replicator.

To learn more about Scrutinizer, visit the product page here, download a 30 day trial, or contact Plixer for a live demonstration and discussion.

If you’re new to NetFlow and are interested in hands-on training be sure to check out our Advanced NetFlow Training courses coming to a city near you.

Read the original blog entry...

More Stories By Michael Patterson

Michael Patterson, is the founder & CEO of Plixer and the product manager for Scrutinizer NetFlow and sFlow Analyzer. Prior to starting Somix and Plixer, Mike worked in a technical support role at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix and Plixer.