Sayers Blog

updated_default_header

Avoiding the Capital One Breach: Defense in Depth

With the release of the criminal complaint in the recent Capital one breach we now have a better understanding of how Paige A. Thompson exfiltrated data from their cloud vendor. We don’t know all the details and can only make inferences based upon the information available.

 

Deploying CloudGuard on AWS

Case Study

 

The complaint states that a GitHub file was retrieved during the investigation with the following details:

 

1.  The file …… contained the IP address for a specific server.

2.  A firewall misconfiguration permitted commands to reach and be executed by that server which enabled access to      folders or buckets of data in Capital One’s storage space at the cloud computing company.
 

    1. The first command when executed obtained security credentials for an account…that, in turn enabled access to certain of Capital One's folders at a cloud computing company.
    2. The second command used the stolen credentials to list the names of folders or buckets of data in the storage space at cloud computing company.
    3. The third command used the stolen credentials to extract or copy data from those folders or buckets.

 

From those details this does appear to be a case of lax cybersecurity hygiene and defense-in-depth on behalf of Capital One, with a few misconfigurations lining up to allow a hacker to connect from a tor & VPN site, enumerate credentials, then use those credentials to gain access to backend storage and extract data.

 

WHAT CAN WE DO?

 

While we do know the information was stored on and compromised from an Amazon AWS tenant belonging to Capital One, we also know that Amazon (Cloud Service Provider – CSP) is not being blamed for this breach.  In the shared responsibility model, the Cloud Customer (Capital One) is always responsible for securing the data being transmitted or stored in a cloud environment.  Many documents and media analysis state is was a “misconfiguration of a firewall”.  What everyone must understand is that a firewall (especially non-enterprise firewall platforms) is one compensating control/layer.  Additional layers must be leveraged regardless of using private or public clouds.  While standards, policies, procedures and guidelines may be well defined, documented and communicated, they don’t actively stop an incident from occurring or prevent a determined individual from compromising discovered weaknesses within an environment.  Technical controls, with related SOP’s, must be implemented, configured, optimized, integrated and audited continuously (with high frequency) and validated internally and via third parties.

 

BACK TO THE BASICS: DEFENSE-IN-DEPTH

By: Christopher Willis

 

The-Fan-illustrating-technology-and-process-defense-in-depth-architectural-pictorial

 

Some additional technical controls that would have assisted in preventing, discovering and alerting to this breach are as follows:

  • Encryption - may have been used; however, compromised
  • Tokenization - was used in a limited fashion, not encompassing all sensitive fields
  • Geo location and IP reputation - preventing TOR and VPN nodes from Sweden to sensitive systems without a need-to-know
  • Network Traffic Analysis (NTA) - with EUBA capabilities to identity anomalous behavior
  • Identity Governance and Administration (IGA) - use of credentials from an account in unauthorized areas for content not related to the account in question
  • Multi-Factor / Contextual / Adaptive / Composite Authentication with Authorization, sub technology with IGA, measures to prevent an account to perform significant tasks without additional validation
  • Deep and Dark Web Monitoring to quickly identify breached data (this wasn’t even necessarily in the deep / dark web, more publicly visible and available
  • Cloud Workload Protection Platform  (CWPP) to monitor and secure cloud workloads
  • Cloud Security Posture Management (CSPM) to identify cloud misconfigurations that could lead to compromise
  • Breach and Attack Simulation (BAS) to take the hackers playbooks and run them against the environment continuously looking for misconfiguration or vulnerabilities
  • Database Activity Monitoring (DAM) or (as Gartner refers) Data Centric Audit and Protection (DCAP) to monitor database activity for anomalous or nefarious activity
  • Web Application Firewall (WAF) - While this acronym was used in the FBI complaint, it’s unclear if the technology was in-use) to prevent commands not relevant to public inquiries
  • Segmentation and layers could have made the data harder to get instead of having one check point and allowing the content to be so readily available to public domains
  • Firewall, Configuration and Security Policy Management tools include the ability to audit the firewalls (along with other technologies depending on solution) configurations and policies for apparent issues or non-compliance.  Modern tools in this area are integrating with vulnerability management and threat intelligence data to even take this further by understanding an organizations true exposure and threat landscape
  • Threat Deception to deceive the adversary into interactions that appear real, but are actually deceptive and alarming the SOC behind the scenes
  • Adversary attribution intelligence to better understand and correlate adversarial connections and campaigns to an organizations assets
  • Data Management / Critical Asset Protection Program to comprehensively discover, properly classify and non-disruptively protect data
  • Internal and public information disclosure and Bug Bounty program for communication mechanisms retrieving information on any severity vulnerability(‘s)

 

While each breach may use the same, similar or different Technique, Tactic or Procedure (TTP), every organization can take the above recommendations to develop a program that will significantly reduce or provide better visibility into potential or actual compromising incidents for any type of attack. 

We should all be aware that in the shared responsibility model organizations we are responsible for securing how data is accessed, stored or transmitted when using cloud services. There are a multitude of controls and technologies to help us build a security program that works for our unique situation, but as every situation is unique please contact Sayers to assist with protecting your on-premises, public or hybrid cloud infrastructure and critical assets.

 

Deploying CloudGuard on AWS

Case Study