Capital One’s Cloud Misconfiguration Woes Have Been an Industry-Wide Fear
Developers and IT decision-makers should not be surprised by the recent Capital One data breach: Misconfigurations have long been the top cloud security concern. A new StackRox survey of IT decision-makers supports this finding as 60% of respondents are more worried about misconfigurations or exposures, as compared to attacks and generic vulnerabilities.
While details of the Capital One data breach are still coming to light, Security Boulevard explains that the attacker most likely identified a misconfigured firewall and pulled the IAM (identity and access management) credentials associated with the WAF (web application firewall) role. Then, those credentials were used to access to Amazon Simple Storage Service (S3) buckets where the stolen files were located.
You can bet security vendors will cite this incident to support the need for their products. Don’t let their spin fool you. Some, if not all, of the files were encrypted, so lax “data security” was not the culprit. Despite the suspect/hacker previously working for AWS, the breach is not an example of an internal threat that Data Loss Protection (DLP) solutions would address Plus, while the need for privileged access management is real, offerings from Centrify, CyberArk and others may not be directly relevant. Finally, although there is real demand to supplement cloud providers’ native security, what additional security tools would have identified the misconfiguration? According to Security Boulevard, “Capital One didn’t need to worry about the attacker turning off local logging since CloudTrail would capture everything that touched the AWS APIs.”
Perhaps the breach demonstrates that firewalls just need to be managed properly. In an AlgoSec-sponsored survey, 45% of respondents use virtual editions of traditional firewalls that are deployed in cloud in order to secure a public cloud deployment. AlgoSec’s product helps with security policy management tool, but it appears that Capital One was already doing that. Fortinet is another vendor with a firewall-related solution. Product manager Lior Cohen believes that offerings like the company’s WAF-as-a-Service reduce misconfigurations by eliminating the need for DevOps teams to configure and manage. In a post contributed to The New Stack, he writes that DevSecOps tools and methodologies would reduce application security risk.
Thirty-one percent of the aforementioned StackRox study said DevSecOps is responsible for who for operating a container security platform, up from 24% when the question was asked in 2018. Whether or not these platforms are just container orchestration platforms (e.g., Kubernetes) with security built-in, or a standalone product is up for debate.
According to Snyk’s founder Guy Podjarny, DevSecOps describes 1) security for DevOps technologies (e.g., container orchestration, CI/CD) as well as applying adapting DevOps methodologies to better address application security. If someone on a DevOps team is focused on security, that person’s role is DevSecOps, and he or she can be considered a DevSecOps engineer. If a security professional’s primary responsibility is communicating with developers, then he or she may also be considered to be DevSecOps. Podjarny believes that most DevSecOps teams are actually application security teams that are focused on the security of products and their development lifecycle.
Security-first developer tools and DevSecOps will topics for future articles. Stay tuned.
Feature image by Peter H from Pixabay.