Do you wanna build a NetFlow? Doesn’t have to be a NetFlow…
Network metadata (NetFlow, IPFIX, sFlow, etc.) provides a wealth of information about the transactions that are happening on a network. Typically, if something happens on the network, NetFlow will see it.
Traditional flow records, however, can leave a lot of the puzzle unsolved during an investigation.
Traditional Flow Record
The above example is a very generic flow record that has been prevalent in monitoring systems for a decade. I’m by no means saying this data isn’t valuable. Pattern recognition, host reputation, network forensics, capacity planning and troubleshooting are all possible with this information.
But it’s 2019, we can certainly do better.
I call the process ‘data enrichment,’ but it can go by many names. To make it work, you need to start thinking about what other data can be bound to flow data to make it more valuable. Then you need a solution and vendor who is flexible enough to help maximize the visibility you can gain from enriching the flow data.
Let’s start simple:
All organizations maintain some configuration management database (CMDB) that map IP addresses to corresponding networks. This could be in the old steel trap, but hopefully it is at least in an Excel spreadsheet—or better yet, stored in something like InfoBlox, which we have existing integrations for.
The idea is this: if you know what networks contain what IP addresses, why not overlay that information onto a report to give yourself more detail?
Simple Data Enrichment
Our story begins to get more interesting. We can now see the business unit this user belongs to. This additional metadata provides an easier way to filter and visualize data.
Have a sensitive network that should never attempt to talk to the internet?
Curious about what departments are generating the most data on the network?
Questions like these become a lot easier to alert for and answer with a simple addition of network name. However….we can do better, right?
This 10.60.1.141 user must have authenticated onto the network somehow, whether it be through Active Directory or a NAC appliance like Cisco ISE or ForeScout’s CounterACT.
Adding User Identity:
Now we are getting somewhere.
Is someone authenticating to more IP Addresses then they normally do?
Are we in a DHCP environment where user attribution is a problem?
Monitoring for credential theft and attributing events to users just became a lot easier with another slight mutation of the flow record.
There is still one pain point that our example leaves us with.
What was this user actually doing?
The internet’s move to HTTPS along with the rise of content delivery networks make it difficult to identify the true destination of data leaving out network. As I said from the beginning of this blog, we can certainly build a NetFlow, but it doesn’t have to be one.
Before the user gets to their final destination, they will have made a DNS request. If we sniff that traffic with our FlowPro Defender, we can get a complete picture of the transaction we started with.
Tying it all together:
DNS context completes the visibility project we started with and opens the doors to many more possibilities. Tracking down Domain Generation Algorithms, correlating host reputation with domain reputation, running statistics on what sites domains are most frequently visited—all of this now becomes possible.
When you are looking into solutions that collect network metadata, don’t narrow your visibility to only what the protocol natively contains. Give some thought to what type of data enrichment would make your life easier and work with your vendor to implement the solutions.
If any of the enrichment techniques discussed in this blog sound intriguing, please don’t hesitate to contact me for assistance in gathering the data.