In a mobile-first, cloud-first world, the attack surface has expanded past the traditional IT perimeter and enterprises need to manage identities and secured configurations to harden devices, govern and manage Shadow IT, and make sure sensitive information is safeguarded.
Recent high-impact cybersecurity events indicate that one of the most common root-causes is insecurely configured IT infrastructure. While industry continues to spend heavily on reactive measures and tools to guard against zero-day vulnerabilities, targeted attacks, and such, most attacks are enabled by weak controls, and insufficiently comprehensive configuration management practices. IBM x-force has reported a “historic 424% jump in breaches related to misconfigured cloud infrastructure, largely due to human error” (Source: IBM X-Force Threat Intelligence Index April 4, 2018).
Many enterprises, however, are behind the curve in protecting against, as well as remediating and recovering from rapid cyberattacks. This is mainly due to a poor understanding of how to assess their security posture against these types of attacks. Let’s take one of the numerous recent incidents (Code Spaces, USCENTCOM, Dow Jones, Accenture among others) and have a close look at the breach at Capital One recently. As a result of misconfigurations at the WAF and the Metadata server on AWS, over 106 million credit applications were exposed. AWS has maintained that this was not their fault; the security configurations that the credit card company failed to design into their security profiles were known for at least two years (Owasp 2017). At Accenture, at least five of their AWS storage buckets were unprotected with passwords, and unencrypted, but contained highly sensitive keys whose loss could have impacted thousands of Accenture clients.
The real question is: how was this allowed to happen, particularly in technologically astute and process sensitive companies? We know that the problem in this case studywas a Security Configuration design failure. The problem at Accenture was a configuration management run-time failure; they failed to ensure that as-running = as-designed.