Lessons from the Capital One Breach

By Chris Davis, VP, Product Management

The Capital One breach will go down in history as a crystallizing cloud security narrative on the importance of continuous security and compliance posture management, much in the same way that the Target breach is history’s lesson about how one can get at credit cards by way of HVAC. Issues in the Capital One breach can be difficult to visualize and discuss because unless you have experience working with cloud services, everything in the cloud feels fluid, shared, and accessible all the time.

I recently had the privilege of joining Bloomberg Technology’s Emily Chang on camera (21:30 minute mark) to sift through “where” breakdowns in cloud-related breaches like Capital One’s occurred. For better or worse, Capital One’s breach will resonate for years, because in addition to being one of the biggest breaches in memory, there is added notoriety now that authorities have charged the alleged intruder with allegedly taking data on as many as 30 additional companies. 

As I mentioned on Bloomberg, a positive outcome from the Capital One headlines is greater awareness of how misconfigurations in security controls can have far-reaching consequences. Here are lessons we all need to take away from this:

Cloud security isn’t “broken,” or impossible 

The unfortunate part of the Capital One story are the questions people will ask about the maturity of cloud security. How secure are AWS, GCP, and Azure cloud services? It’s important to note that this particular breach had nothing to do with the cloud service provider and the security of their own infrastructure. This breach had everything to do with the mismanagement of configurations and access controls, key components of effective risk management.

The singular question that everyone should ask is, “How can I consume cloud resources as a customer and effectively measure and manage my risk of compromise?” Cybersecurity in the hybrid or multi-cloud environment demands a continuous assessment of the risk due to cyber threats and risks due to drift in compliance for highly regulated applications. The continuous assessment requires real-time visibility into cloud assets, assessment of configuration settings, review of access permissions, risk analytics for proactive actions and additional safeguards that protect the applications and associated workload running in the cloud.

Shared responsibility can strengthen trust

The security in the cloud hinges on shared responsibilities between providers and customers. AWS prominently discusses the Shared Responsibility Model. AWS is responsible for security of the cloud, including hardware, software, networking, and facilities that run AWS cloud services. Customers are responsible for security in the cloud, including the configuration of any cloud services they select and the security of any workloads that belong to the customer. Thus addressing the overall risk of the cloud application deployment. It is also imperative that enterprises leverage hybrid and multi-cloud tool set that leverages a common risk management framework such as National Institute of Technology (NIST) Risk Management Framework (RMF) or it’s companion Cyber Security Framework (CSF). This allows both proactive and reactive risk management approach for automated on-going risk management. When these things are done effectively, it strengthens trust in cloud resources.

If I were someone who has an application running on AWS cloud today, I would be sure to do the following as an outcome of the Capital One breach: 

  • Create a process to detect and analyze changes through automation
  • Review changes required in security policies to support the changing environment
  • Analyze network connections and security permissions
  • Establish frequent Identity and Access Management roles and permissions
  • Evaluate patch levels of all of the application and their platforms 
  • Implement an automated security posture management solution for continuously analyzing the cyber and compliance risk posture