I spent a lot of time talking to customers at RSA 2019 and a message that resonated with a lot of them was using your network as a sensor. I believe this is because SOC analysts often dig through log data or full packet capture—but then overlook network metadata because it isn’t available to them or they don’t know how to properly use it. This blog will give you a high-level view of what you might be missing out on by not collecting and analyzing network metadata such as IPFIX/NetFlow.
Why should I use network metadata?
When you already have log data and full packet capture, collecting network metadata can seem redundant. But we find that they each provide different data at different levels of granularity. Sometimes you only need a hammer instead of a sledgehammer. Network metadata can be that hammer in your toolbox.
Another reason to use network metadata is that you can store it for much longer than full packets. When the average length of a malware infection on the network isn’t found for 6 months, this is huge—I don’t know of too many companies keeping full packets (at all observation points) for 6 months.
Another big benefit is since this is metadata and it is so much more lightweight, we can use contextual details from many solutions to supplement the data we have collected.
What type of elements do we collect?
Inside Scrutinizer, we can collect thousands of elements from all sorts of different observation points. Some common ones (besides the standard tuple) are:
- Wireless
- AP information
- MAC address
- SSID information
- Applications
- Routers
- URLs
- QoS
- VLAN ID
- VRF tag
- Firewalls
- ACLs
- Usernames
- NAT information
- Firewall events such as Denies
What can I do with this data?
In my role, I often teach end users about the nuances of NetFlow/IPFIX since it’s an evolving technology with a lots of different information elements that can be sent. I find that a lot of end users think that all they are going to see is packet header information, but that couldn’t be further from the truth. A great example of this is some of the data we can collect from DNS—I’ll use our FlowPro Defender as an example.
In the screenshot below, you can see some common fields we can collect from these devices. This can include requested domains, which can be used to monitor CDN traffic, as well as check if hosts are reaching out to blacklisted sites.
Faster automated response
So far, we have talked a lot about what types of details we can get through metadata from a reactive standpoint. We don’t expect anyone to sit in front of a console all day, so we take it a step further with behavior-based algorithms that run unattended and alarm on any suspicious behaviors. Since these use behaviors rather than signatures, they can alarm on zero-day exploits as well as polymorphic malware.
These alarms will help correlate any network security events and help teams establish good network hygiene.
SecOps of the Future:
With these potentially new tools in your arsenal, you are now well equipped for handling the ever-changing threats in today’s networks. If you’re new to collecting this data or are having problems with lack of visibility into your network, reach out to our team today to see how we can help!
