By Anton Chuvakin (originally posted at Anton on Security)
While we may live in an endpoint security era, the need for network data analysis today has not vanished. As we discussed during a recent webinar with Chronicle partner Corelight, this is not about competing with endpoint or arguing about what security telemetry is “better” — this is about reminding the security leaders and professionals that your network telemetry matters. This was not only the case in the 1980s (when tcpdump was born), 1990s, 2000s, 2010s, but also today in the 2020s.
To summarize, network security monitoring still matters because you can monitor unmanaged devices (BYOD, IoT, ICS, etc.), detect threats with no agents, offer broad coverage from a few points, and be out of band.
Still, there are a few common misconceptions about network security telemetry data. I’ll cover a few, and then focus on one in particular.
- You cannot monitor encrypted data: Encryption can sap some of the value of network security monitoring, but it does not destroy it. Both layer 3 (flow) and layer 7 (rich metadata) observation have value for encrypted data whereas full packet capture may not.
- Network monitoring is only an auxiliary control, you need endpoint first: I’ve seen enough environments where this is the truth — the point is that you need an endpoint first, but then you need NDR to cover gaps, unmanaged devices, etc.
- “PCAP or it didn’t happen”: Many years ago, before we had Bro/Zeek and the choices were “flow or pcap”, this may have been true. But the reality is that in 2021, you are not saving full packet captures for weeks or months. Perhaps we have to change the slogan to “Zeek decodes or it didn’t happen.”
- Network traffic is too expensive to capture: This is not a misconception at all, if you see full packet capture as the way to go. It would be prohibitively expensive in most modern environments. However, you can get a lot of value from rich L7 metadata and this is much less expensive (but also more useful) than mere flows.
- Network data is not helpful in the cloud: While comparatively fewer people capture and monitor traffic in the cloud, the interest to do this grows rapidly (this is also discussed in depth below).
Let’s now drill down into the last point:
Why do some people think that NDR in the cloud is an anti-pattern (bad practice)?
- Everything is locked down and immutable, so why do traffic capturing?
- Everything is encrypted, so what’s there to sniff?
- Cloud logs and the new fancy observability provide visibility, why sniff traffic?
- I can do flows logs in the cloud, I don’t need “costly” packets
- Applications are dynamic and everything changes, so captures become less important over time
On the other hand, NDR fits well with public cloud environments today:
- Your main on-premise tool — EDR — may not be available at all (e.g., with containers)
- Some cloud architectures use essentially flat networks, hence NDR is very useful for East/West visibility
- Cloud API logs are not exhaustive, they can be voluminous or noisy and have an inconsistent schema
- Cloud network flow logs are shallow (just like their on-premise predecessors)
- In-app observability for security is not common yet, even if it is coming
- Given the right cloud context, you can dynamically correlate IP addresses in network traffic logs, like Zeek, to the event that happened on Google Cloud Compute Engine instances
- Cloud providers now deliver robust ways to get access to traffic (such as Google Cloud’s packet mirroring service), so make sure your NDR tool supports these cloud native mechanisms
Thus, NDR lives on in the cloud! NDR works — and this applies to both virtual machine environments and modern cloud environments even if not equally.
Stay tuned for upcoming blog posts about ways to apply cloud network traffic use cases in Chronicle.
