How to Integrate NDR Visibility into SIEM Detection Workflows?

To combat alert fatigue, we created a priority matrix that maps findings from the NDR against SIEM results. For instance, if a network alert identifies a suspicious scan but there's no response from the endpoint, it gets tagged as medium priority. If both systems trigger an alert, it’s raised to high priority. It took several tuning cycles, but now our triaging process is quicker and more reliable.

For our Kubernetes clusters, we wanted network visibility but didn't want to deploy a physical tap. We implemented an NDR that captures traffic via CNI-level mirroring and then sends summary alerts to our SIEM. Most parsing is done by the NDR, and we utilize Stellar Cyber for context before forwarding. This approach sped up our deployment and significantly reduced noise.

Initially, we faced an avalanche of alerts after adding the NDR. To tackle this, we clearly categorized alerts into network-only, endpoint-only, and combined alerts. We also set up a system that suppresses alerts if the SIEM has already detected the same threat. After about a week of tweaking, we managed to reduce upstream noise by 70%, and our response workflows largely remained the same.

We successfully merged our NDR platform with our SIEM by normalizing alert schemas and tagging alerts by subnet and identity. This approach helped us identify lateral movement attempts that the endpoint detection and response (EDR) logs missed. We used a SIEM API to hook it all up, and the workflows are directly tied to our ticketing system, which made everything flow much smoother.

Our system is designed to trigger a single incident when both endpoint and network telemetry surpass certain thresholds. This setup helps reduce siloed alert notifications and speeds up investigations. The correlation logic in our SIEM plays a crucial role, matching alerts by timestamps and IP addresses. We're now considering how to incorporate host and user context as well.