5 Reasons Your NDR Project Missed The Mark

Originally published by Netography.

Written by Mal Fitzgerald, Sales Engineer, Netography.

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:

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

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

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

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

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