Unless you’ve been living under the proverbial rock, you likely are aware of the Capital One breach in 2019 that leaked confidential information from more than 100 million credit applications stored in the Amazon Web Services (AWS) cloud. While the perpetrator (a former AWS employee) was quickly arrested and charged, this is just not a simple case of insider threat.
There’s a deeper issue at play here – misconfigured software in the cloud. In this case, it was a misconfigured Web Application Firewall (WAF) that allowed the malicious insider to execute the breach.
While the Capital One hack did require some expertise to execute, there have been many in the recent past that were childishly simple, requiring just an active account with the same cloud provider. Case in point: the exposed Dow Jones list of high-risk individuals. This data, on an AWS S3 bucket, was accessible by any “authenticated user” via an easily guessable URL. Unlike your typical on-premise database, Amazon defines “authenticated user” as “any user that has an Amazon AWS account.” That number has exceeded a million and is growing rapidly since getting an account is free. So, it’s obvious that this is a software misconfiguration just waiting to be exploited.
This is just one example in a list that keeps growing. In a veritable Groundhog Day scenario where the same issue is repeated over and over again, data in the cloud is continuously being found to be exposed due to misconfigurations. Interestingly, even organizations that should know better often fall victim to the same shortcomings, as proven by the Verizon incident of Jun 2017 that saw 6 million customer records exposed on a misconfigured AWS S3 bucket. Ironically, this is the same company that publishes the authoritative Data Breach Investigations Report (DBIR). And if you think only profit-seeking companies are guilty, the US Department of Defense may have something to say about that.
While some of these incidents can be traced back to user error, I believe there’s also a cultural issue at play here: the “not my problem” mindset. Some people are under the wrong assumption that once the data is in the cloud, responsibility for its security lies with the cloud service provider (CSP). That’s not the case, however, as CSPs are quick to point out.
AWS, for example, clearly states that it is responsible for “Security of the Cloud” (including underlying infrastructure) while the customer is responsible for “Security in the Cloud” (e.g., configuration management, data security and user management). Google Cloud and Microsoft Azure have similar language in place. As the CSPs insist, this is a “shared security” model where the users have to carry their weight. From a technical configuration perspective, open source tools like my organization NCC Group’s very own Scout Suite have been designed to specifically identify configuration gaps and vulnerabilities within cloud environments.
Moving away from technical controls, it’s true that CSPs are responsible for the physical and environmental security of the infrastructure on which the clouds are hosted. However, this doesn’t mean that the need for physical security in the operating environment disappears. I had a client CEO say to me, and I’m quoting him word for word, “Everything is in the cloud; why do I need physical security?”
This was my response: “Let’s consider a hypothetical scenario: you’re logged into your AWS admin account on your laptop and step away for a cup of coffee; I walk in and walk away with your laptop. Will that be a security issue for you?” As you can imagine, this is akin to putting in a state-of-the-art alarm system in your home and then leaving the key in the lock. In fact, I had mentioned this anecdote in an earlier blog post about the importance of physical security in the age of the cloud.
While the cloud has truly democratized technology by allowing smaller organizations access to resources previously available only to enterprises with multi-million-dollar IT budgets, users are not absolved from their responsibilities in how those resources are secured. As you can see, as a consumer of cloud services, security in the cloud is not someone else’s problem, but very much your problem to solve.
Editor’s note: For related resources from ISACA, download our Azure audit program and find out about the new Certificate of Cloud Auditing and Knowledge (CCAK), a credential from ISACA and Cloud Security Alliance.