Musings on the Capital One Data Breach and Guardicore

Thoughts on the Capital One Attack

The ink on the Equifax settlement papers is hardly dry, and another huge data breach, this time at Capital One, is sending shock waves across North America.

The company has disclosed that in March of this year, a former systems engineer, Paige Thompson, exploited a configuration vulnerability (associated with a firewall or WAF) and was able to execute a series of commands on the bank’s servers that were hosted on AWS. About 106 million customers have had their data exposed, including names, incomes, dates of birth, and even social security numbers and bank account credentials. Some of the data was encrypted, some was tokenzied but there’s been a large amount of damage to customers, as well as to the bank’s reputation and the entire security ecosystem.

Our customers, partners and even employees have asked us to comment about the Capital One data breach. Guardicore is an Advanced Technology Partner for AWS with security competency. There are only a small number of companies with such certification and thus I’d like to think that our thoughts do matter.

First – there are a couple of positive things related to this breach:

  1. Once notified, Capital One acted very quickly. It means that they have the right procedures, processes and people.
  2. Responsible disclosure programs provide real value. This is important and many organizations should follow suit.

While not a lot of information is available, based on the content that has been published thus far, we have some additional thoughts:

Could this Data Breach Have Been Avoided?

Reading the many articles on this subject everyone is trying to figure out the same thing. How did this happen, and what could have been done to keep Capital One’s customer data more secure?

What Does a ‘Configuration Vulnerability’ Mean on AWS?

When it comes to managing security in a cloud or a hybrid-cloud environment, organizations often experience issues with maintaining good visibility and control over applications and traffic. The first step is understanding what your role is in a partnership with any cloud vendor. Being part of a shared-responsibility model in AWS means recognizing that Amazon gives you what it calls “full ownership and control” over how you store and secure your content and data. While AWS is responsible for infrastructure, having freedom over your content means you need to take charge when it comes to securing applications and data.

Looking at this data breach specifically, an AWS representative has said “AWS was not compromised in any way and functioned as designed. The perpetrator gained access through misconfiguration of the web application and not the underlying cloud-based infrastructure.”

Thompson gained access by leveraging a configuration error or vulnerability which affected a web firewall guarding a web application. By passing what seems to have been a thin (maybe even single) layer of defense, she was then able to make some kind of lateral movement across the network and then to the S3 bucket where the sensitive data was being stored.

Cloud Native Security Controls are Just Your First Layer of Defense

Can we learn anything from this incomplete information? I do think that the answer is “yes”: Cloud-native security controls provide a good start, but this alone is not enough : Best practice is to add an extra layer of detection and prevention, adding application-aware security to the cloud, just as you would expect on-premises. Defense-in-depth as a concept is not going away even in the cloud. The controls and defenses that the Cloud Service Provider includes should be seen as an add-on or part of the basic hygiene requirements.

I would argue that the built-in Cloud API for Policy Enforcement is Insufficient: SecDevOps need more effective ways to identify and block malicious or suspicious traffic than cloud APIs can achieve. When we were designing Guardicore Centra, we decided to try to develop independent capabilities whenever possible, even if it meant that we had to spend more time and put more into our development. The result is a better security solution that is independent of the infrastructure and is not limited to what a 3rd party supplier/vendor or partner provides.

Guardicore Centra is used as an added security platform for AWS as well as the other clouds. We know from our customers that acting on the facts listed below have protected them on multiple occasions.

  • Guardicore is an Advanced Technology Partner for AWS: Guardicore is the only vendor that specializes in micro-segmentation with this certification from AWS, and Guardicore Centra is fully integrated with AWS. Users can see native-cloud information and AWS-specific data alongside all information about their hybrid ecosystem. When creating policy, this can be visualized and enforced on flows and down to the process level, layer 7.
  • Micro-Segmentation Fills the Gaps of Built-in Cloud Segmentation: Many companies might rely on native cloud segmentation through cloud-vendor tools, but it would have been insufficient to stop the kind of lateral movement the attacker used to harvest these credentials in the Capital One breach. In contrast, solutions like Centra that are deployed on top of the cloud’s infrastructure and are independent are not limited. Specifically for Centra, the product enables companies to set policies at the process level itself.
  • Cloud API for Policy Enforcement is Insufficient: SecDevOps need more effective ways to block malicious or suspicious traffic than cloud APIs can achieve. In contrast, Guardicore Centra can block unwanted traffic with dynamic application policies that monitor and enforce on east-west traffic as well as north-south. As smart labeling and grouping can pull in information such as EC2 tags, users obtain a highly visible and configurable expression of their data centers, both for mapping and policy enforcement.
  • Breach Detection in Minutes, not Months: The Capital One breach was discovered on July 19th 2019, but the attack occurred in late March this year. This is a gap of almost four months from breach to detection. Many businesses struggle with visibility on the cloud, but Guardicore Centra’s foundational map is created with equal insight into all environments. Breach detection occurs in real-time, with visibility down to Layer 7. Security incidents or policy violations can be sent immediately to AWS security hub, automated, or escalated internally for mitigation.

Capital One Bank are well known for good security practices. Their contributions to the security and open source communities are tremendous. This highlights how easily even a business with a strong security posture can fall victim to this kind of vulnerability. As more enterprises move to hybrid-cloud realities, visibility and control get more difficult to achieve.

Guardicore micro-segmentation is built for this challenge, achieving full visibility on the cloud, and creating single granular policies that follow the workload, working seamlessly across a heterogeneous environment.

Want to find out more about how to secure your AWS instances?

Read these Best Practices

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

CAPTCHA ImageChange Image

‹ Back to Guardicore Blog