5 Reasons Your NDR Project Missed The Mark
By Mal Fitzgerald, Sales Engineer
I’ve seen it time and again. You read about the SOC Visibility Triad, with its corner for Network Detection and Response (NDR) and thought, “That makes complete sense” and, truth be told, I completely agree with you.
So you did what we all do when a new category shows up that interests us: you read up as much as you could on the subject, spoke with your peers and resellers, went to shows to see the hot new vendors, sat through hours of demos all in an effort to shortlist and come up with a proof of concept plan.
You then ran a proof of concept, chose a clear winner, and finally implemented your new gear – after months or even years – across your network stack.
So why, after all that work, does it feel like your expected outcomes fall short?
Here are 5 reasons why your NDR project missed the mark:
You have far more encrypted traffic than you thought
Encryption is pervasive and essential in today’s modern networks, both from a North-South perspective, as well as East-West. As you envisioned utilizing NDR for your East-West traffic, hoping to investigate data crossing into the datacenter, the protocol detail you expected to use is simply not available. Therefore packets become a heavy lift for very little application layer information.
You couldn’t deploy sensors everywhere
When it comes to our real time monitoring, the reality is we tend to make decisions based on risk and budget. When it comes to NDR deployments, all too often those decisions are to place sensors in the data centers and hopefully not miss any interesting traffic throughout the rest of the network. Unfortunately, many times when we begin to investigate something that doesn’t look quite right, or when we work through a detection, the path naturally leads us to a client network in some faraway place where we couldn’t afford to deploy a sensor. A missed opportunity to see the more complete view of what is happening on your networks.
Your cloud investment has increased
You started your NDR project with a significant footprint in traditional, on-premises data centers, but since deploying, your resources in the cloud have grown exponentially. You are now playing catch-up trying to deploy virtual sensors in the correct VPC’s so as to not incur data transfer costs, as well as playing whack-a-mole trying to ensure VPC packet mirroring is turned on for every device with an attached network card, both for workloads that are pervasive as well as the more dynamic and ephemeral ones (that is why we moved to the cloud right?). You end up spending more time managing the deployment than actually monitoring your cloud traffic.
You’ve moved to a cloud provider that does not offer native packet acquisition
As we discussed in the previous item, not all cloud providers are created equal and you may have even moved into a provider who doesn’t offer packet acquisition natively. Now you’ve entered “installing agents” territory. While technically feasible, the time and effort spent deploying and managing them is generally not worth the outcomes received.
You don’t have enough control of your own detections
You and your team know your environment better than any algorithm. You have operational compliance policies already defined that dictate which devices can talk and on which ports. You know that business unit “A” never has a reason to send data to business unit “B”, and that the operational technology (OT) devices in Albuquerque should NEVER talk to a Non-RFC1918 address. But in your NDR platform, you can’t easily (and without a vendor’s assistance), create a rule set that matches any of these criteria in order to make this type of event actionable. So you end up hoping an algorithm will cover it well enough.
So What Should You Do Instead?
We’ve taken a different approach to environments that have become too dispersed, ephemeral, encrypted, and diverse (DEED) to make packet acquisition/NDR a viable option. A common denominator amongst all of the environments listed earlier is the availability of network flow logs (NetFlow, sFlow, IPFIX, Cloud Flow). On the surface you’re screaming “BUT MY PACKETS” but, as we’ve discussed, our networks have either been hardened (encrypted) to the point that packets aren’t valuable enough, or are simply too complex and challenging to actually retrieve packets from them in the first place.
Netography ingests flow from all of your on-premises network devices, as well as AWS, Azure, Google, Oracle and IBM clouds, enabling a much broader coverage into the entirety of your network. Upon ingestion those flows are enriched with external sources such as geolocation data, autonomous system information, threat intel as well as with your specific context information easily retrieved from your cloud providers, CMDB and/or EDR platforms.
This design allows us to reach wider on your network than you currently can today, while maintaining a granular level of visibility and control of the conversations happening. All while giving you the flexibility to create your own compliance and policy detections, which naturally become more valuable and actionable to your organization. All without the challenges of packet acquisition in today’s dynamic and ever changing networks.