Extending NDR visibility in AWS IaaS

Comprehensive visibility is challenging in a cloud environment. While these environments are rich sources of telemetry and logs, it is challenging for security teams to ensure that logging is configured (and stays configured) on every service, to ingest diverse log types into the SIEM, to navigate poorly designed schemas, to correlate across logs from different cloud environments and most importantly, to unearth actionable insights.

This is why security teams have long relied on network monitoring to complement application level visibility. Corelight sensors analyze network traffic to provide a bird’s-eye view of the environment and generate judgement-free evidence that is agnostic to platform, application and service.

Expanded availability

One of the key features that makes network monitoring possible in AWS is VPC traffic mirroring. This is equivalent to a TAP in the cloud that mirrors packets from EC2 instances and sends it off to a network monitoring stack. 

With VPC traffic mirroring you can monitor any EC2 instance with an attached ENI. This also includes EC2 backed ECS/EKS where you would monitor the host traffic (but not the pod-to-pod traffic). This monitoring also gets you visibility into traffic from the source EC2 instances to off-VPC services such as RedShift, Kinesis Streams, S3, etc.

We initially introduced monitoring of EC2 Nitro instances with our AWS Cloud Sensor in 2019 and extended this capability to AWS GovCloud in 2020. With the help of our AWS partners, we are now excited to extend this monitoring beyond AWS Nitro to support 12 new non-Nitro compute instance types and across 22 regions. 

Integrated Suricata

A network detection stack mimics an analyst workflow that begins with signature-based detection (using Suricata IDS) or behavioral detection (with Zeek notice.log / alert.log) and ends with an incident investigation using rich security metadata (via Corelight logs). 

Last year we offered this design pattern with an integration of Zeek and Suricata on our physical appliances. And today, we are extending this same to our AWS Cloud Sensors. Available as a limited release, customers will be able to get the power of Zeek and Suricata in a single Corelight sensor in AWS.

Suricata IOCs have been the tip of the spear in some of the recent incidents (such as the SUNBURST breach and Exchange vulnerability). With this integration, analysts will be able to quickly pivot from a Suricata alert to Corelight logs to accelerate the investigation workflow.

Use Cases

These are some of the use cases where our customers have been able to find a malicious threat actor as well as red team activity using Corelight sensors in their AWS IaaS (infrastructure as a service) environment.

Detecting network based activity 

For organizations that host a public-facing application, monitoring network activity is essential, but these detections can be very noisy and threat detections are are not as extensive. Corelight can help fill the gaps with detailed detections and rich insights into network activity.

With Corelight notice.log, you can easily detect port scans and brute force attacks. Even with encrypted connections, you can get broad security insights around SSL/TLS and SSH traffic. For example, you can monitor SSH traffic from/to your bastion hosts to look for file activity, interactive/non-interactive sessions, agent forwarding, stepping stone attack, etc.

For DNS-based activity (such as DNS data exfil or DGA detection) native threat detections that loook at VPC DNS logs are easy to evade by using a different DNS server. However, monitoring raw north-south network traffic gets you to the source of truth that is difficult to evade. With Corelight’s dns.log you can easily find data exfil attempts by looking for large and seemingly-randomized DNS requests or find DGA activity by observing the length of the query string.

Contextualizing alerts for incident investigation 

Threat detection systems might miss some things or generate a lot of false positives. Most importantly, IDS engines lack the context required to triage an alert. 

Rich network telemetry is the best complement to an alert engine – and can supply the data needed to investigate and triage. With Suricata alerts (that are now part of the Corelight NDR data), a SOC analyst can pivot using community_ID and Corelight UID through the Corelight logs to triage and resolve false positives. 

For example, when GuardDuty fires a DGA alert, you can easily pivot to Corelight logs to determine if this was generated by a legitimate request to a CDN or whether it is  evidence of C2 activity. For GuardDuty alerts, a lambda function could be used to decorate the alerts with the necessary context from Corelight logs.  

To learn more about the Corelight Cloud Sensor for AWS, download the data sheet.