At the end of July 2019, news broke of yet another data breach. Data, including Social Security numbers and personally-identifiable-information (PII), had allegedly been stolen from Capital One.
The news was particularly notable for two reasons. First, the initial details of the breach came to light through a complaint filed by the FBI in Federal court. The complaint contained both a named defendant, a timeline of events and enough breach details to infer how the attack was carried out. Second, the IT infrastructure that was breached had been hosted on Amazon Web Services (AWS). Because Capital One has been a long-time user and vocal supporter of cloud computing, the story of the breach raises a serious question for companies moving full speed ahead with their respective cloud strategies– if Capital One (a company that clearly spent significant time and money moving to the cloud) can get it wrong, how can we get security in the cloud right and prevent breaches?
What Happened?
Several pieces have been written analyzing how the attack was carried out, detected and remediated. To summarize, this was not an insider attack and was the result of a multi-layered misconfiguration which allowed the attacker to escalate privilege and exfiltrate data without being noticed by Capital One. Publicly posted data owned by Capital One was identified three months after the breach by a security researcher who then notified Capital One. Once they were aware of the issue, Capital One was able to quickly repair the issue that had allowed the breach.
Security of the Cloud
As we consider threat vectors in the cloud and how to get cloud security right, knowing this was not an insider attack is an important first step. Despite the defendant being a prior employee of Amazon, inside information was not used. Cloud providers have the benefit of scale when it comes to investing in the security of their infrastructure and services. AWS has easily accessible compliance reports of its systems and operations from third-party auditors for ISO, PCI, SOC, and other regulatory standards. In short, they already do security “of” the cloud better than practically any other company can secure its on-premises data centers.
Configuration is King
The underlying issue was a multi-layered misconfiguration of Capital One’s AWS resources. Capital One was using a Web Application Firewall (WAF) from the AWS Marketplace to secure an application. At a basic level, a WAF guards web applications by filtering out traffic that is suspected to be malicious. The WAF used by Capital One was not the AWS WAF service, so did not have the benefits of AWS’ security apparatus. AWS Marketplace appliances can be significant productivity boosters because they come preconfigured for a specific purpose and allow AWS users to leverage the expertise of other companies and products with minimal effort. However, the WAF used by Capital One had a misconfiguration which allowed the attacker to steal temporary security credentials from the server running the WAF. Further, the identity policies applied to that server were also misconfigured. This misconfiguration gave those stolen security credentials broad access to data stored by Capital One. It was a one-two punch of misconfiguration.
Security in the Cloud
Protect and Detect are two of the five security functions defined in the NIST Cybersecurity Framework. As we examine this breach, we find deficiencies in both of these areas. Proper configuration is a key element of protection. So, how do we ensure proper configuration? In short, continuously. Cloud security will never be set it and forget it. The landscape of tools, features and vulnerabilities is constantly evolving. Processes that continuously audit configuration compliance and perform vulnerability scanning using the latest Application Security Testing (S/D/IAST) are essential. Configuration compliance rules themselves need continuous improvement to cover the growing body of best practices and expanding cloud features. Identity policies need continuous review and monitoring to ensure they conform to the principle of least privilege- this is critical for limiting the blast radius in breach situations. We have no hope of responding and recovering without detection of breaches. In this case study, we see three possible detection mechanisms that would have identified this breach sooner:
• Simple monitoring – know when attempts are made to use valid security credentials for actions they are not permitted.Your applications using the credentials will not do this, but an attacker trying to discover the limits of those credentials might trip this wire.
• Honeypot detection – enable access by security credentials to an enticing target which is never touched by normal credential use and monitor if that use occurs to detect a malicious user.
• Anomaly detection – detect spikes in usage or usage patterns that are atypical.
Finally, choosing AWS managed services over 3rd party or marketplace solutions allows one to take full advantage of the secure framework all their services are built on. Security is “job zero” at AWS, a philosophy that is embraced across their entire organization and technology stack.
A Trusted Partner
The rate of change in the cloud can be difficult for organizations to keep up with when their primary objective is to deliver value, not stay current with the cloud. However, being able to defend against security threats and getting security right in the cloud require keeping up. For example, AWS recently released an updated Instance Metadata service that closes off the most significant part of the attack vector used in the Capital One breach. Keeping up is so important that it’s included in the best practices of AWS’ Well-Architected Framework. A trusted partner like Presidio can help you improve your security posture in the cloud, continuously evolve it and enable you to focus on growing your business. Contact us to learn more.
