With increasing enterprise workloads moving to cloud services it is critical that your security monitoring shifts with it. The latest update available to QRadar’s AWS integration now allows you to perform network monitoring of your cloud environment through the consumption of VPC Flow Logs. Patrick Routh gave an introduction to VPC Flow Logs and the integration with QRadar in his blog post. In this blog, I will take this a step further and show some of the insights you can gain by pulling VPC Flows into a QRadar deployment.
AWS VPC Flow Logs give you visibility into the hosts communicating, the number of bytes and packets transferred, the time and duration of sessions, as well as whether the traffic was blocked by your network access control lists (ACLs).
A QRadar deployment can be running anywhere that has access to the AWS S3 APIs. The configured S3 buckets are monitored for any new VPC Flow Logs that are available and these are pulled into the QRadar flow pipeline for analysis and subsequent display on the Network Activity tab.
The latest DSM Configuration Guide available for download here has all the details on how to set up this integration. The environment I am using in this blog is a QRadar all-in-one console with a “default_Netflow” flow source configured on UDP port 2055. After configuring my AWS environment to export VPC Flow Logs into S3 buckets, I added a QRadar log source using the Log Source Management app, deployed changes and that was it! Flow data from my AWS environment began populating the Network Activity tab.
All of the network flow analytics that you are used to from an on-premise NetFlow or IPFIX deployment are automatically applied to the VPC Flow Logs:
- Easily identify network scans, distributed denial of service (DDoS) attacks and port scans through our superflow functionality
- Automatically classify applications of flows based on the destination port or customise our detection algorithms to your cloud applications
- Passively build a model of the assets in your cloud environment
New properties specific to the VPC Flow Logs can also be found in the UI including the network interface name where the traffic was observed, whether the firewall blocked the flow, and the AWS Account ID that was being monitored:
All of these flow properties can be used in filters, Ariel Query Language (AQL) and in the Custom Rules Engine (CRE).
To see exactly what I could determine from just VPC Flow Logs, I started monitoring an AWS environment a remote team were using for their testing. Ignoring any of the existing out-of-the-box rules, I started doing some investigations through the Network Activity tab.
As a starting point, using AQL I generated the following chart by grouping flows with the same application that were allowed by the VPC ACLs that were configured:
In this example, the majority of the traffic is the expected HTTPS web traffic to a single AWS instance, but the flows identified as potential SSH and Squid Proxy traffic are suspicious and should be investigated further. Drilling down on the Squid traffic we can see communication between some of my AWS instances, plus access from an external IP which I have blurred:
From here, I might want to create a rule to alert me to any inbound traffic on anything but port 443 that was allowed by the VPC ACLs:
Other use cases like lateral movement and data exfiltration can also be detected with the visibility you now have into your AWS environment.
Keep an eye on the X-Force App Exchange for updates to the Cloud Visibility app for new ways to visualise your VPC Flow Logs. Also, look out for more blogs here on the IBM Security Community about our other cloud integrations for your flow data.