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.
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.