Lessons Learned from the Capital One Cyberattack – Listen to Your Data Sources
Ward Cobleigh
Network Performance Management veteran, Continuous Threat Exposure Management advocate, and espouser of the Oxford comma, still trying to figure out what he wants to be when he grows up. Film at 11.
The recent Capital One Cyber Incident provides us with yet another reminder of the dangers of becoming “cloud blind” as applications and data move to the cloud. Much has been written about the potential impact and cost of this cyberattack, but rather than focus on impact, let’s look at what readily available resources you have at your disposal that can help to ensure that your company doesn’t make these kinds of headlines.
In this article we’re going to briefly look at how flow data can be leveraged to uncover security threats, the suspicious and malicious behaviors that lead to and describe cyberattacks. We’ll look at three flow-based capabilities that virtually any organization can leverage.
1. The “Misconfigured Firewall”
Capital One has acknowledged that they missed, but quickly corrected, the firewall configuration issue that ultimately gave the hacker her way in. Are you listening to your firewalls? Frequently when people think about collecting NetFlow, IPFIX, and other forms of flow data, they think about watching the Ingress traffic on edge routers to monitor traffic volumes. There’s certainly nothing wrong with this type of network telemetry but why stop there? Many firewall vendors can export their own flows that contain more than basic descriptions of the traffic flowing through the firewall, they also provide important security information such as firewall error and event codes. Listen to your firewalls.
2. Tracking Access to Cloud Resources
While the Capital One vulnerability wasn’t specific to the cloud, the data that was compromised did reside within folders in a cloud storage space. If you are housing sensitive information in the cloud, are you monitoring who’s accessing the devices that host that data? For example, Amazon’s VPC Flow Logs can be used to describe the IP traffic for a VPC, a subnet, or a network interface. Listen to your cloud resources. But let’s not just stop with basic conversation monitoring, let’s make sure we’re aware of whether any of those conversations pose a potential security threat. This can be accomplished via:
3. Black/White Listing
An advanced flow monitoring system will allow you to compare the observed conversations to public or custom blacklists to ensure that your cloud resources aren’t initiating communication with known bad actors, a sure sign that exfiltration is taking place. Alternatively, a flow monitoring system that’s been designed with security in mind will allow you to create profiles (sometimes referred to as traffic groups) that describe acceptable users and use and notify you when profile exceptions have been observed. If the unauthorized user is someone on your network, imagine the power of knowing their user id, IP and MAC addresses, even the switch port that they are attached to. Listening to your flow data means more than just counting traffic volumes. Sometimes the who, what, and where matter far more than the, how much.
Enriched flow records can provide valuable insights into security and threats. You have the data sources already. Are you listening?
Technologist
5 年I am not sure IP level monitoring would catch a misconfigured WAF, an SSRF exploit, misconfigured S3 policy and a misconfigured Role with access to metadata service off VPC would catch this. VPC flow logs don’t extent to S3 access that would be another product I assume. https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/