Much of the propaganda for taking your data into the cloud has a “the cloud is the same, but cheaper” flavor - while this is not a terribly inaccurate four words, the CapitalOne breach does expose some wrinkles that the cloud creates for security governance. What follows is an attempt at spotlighting what these wrinkles are and what business leaders should know about them in a heuristic, minimally technical way.
Talking about “inside vs. outside” is a good lens for thinking about the extra administration burdens of the cloud. If you keep your data on-prem, operating your own data center and using it only for the data of your business, you might be blessed with a very cut-and-dried inside and outside. Your data is in a particular building, not mixed together with anyone else’s, probably protected by a firewall with a footprint more or less identical to the footprint of that building. There are less shades of gray on-prem and it is likely you created them up yourself.
If you keep your data in the cloud, there are some more potential shades of gray about inside and outside, and errors in managing shades of grey is how CapitalOne was left vulnerable. Your cloud environment is in a building with other people’s cloud environments, and maybe your cloud environment is actually a virtual server on a computer that is also simulating the cloud environments of other businesses. There might be, in principle, multiple firewalls in play (perhaps for the data center, a given physical server, and a virtual server it simulates) and there might be multiple different sets of rules governing how different servers, virtual and real, interact with these various firewalls. You can talk about inside vs. outside your virtual machine, your physical machine, a data center, a platform… This might sound a little trite and silly absent detail, and detail is unfortunately something the CapitalOne story can provide.
The CapitalOne breach exploited a misconfigured firewall, and in particular a misconfiguration that wrongly allowed CapitalOne’s servers to talk to a back-end resource inside Amazon Web Servers. This is the inside vs. outside heuristic starting to break down - the AWS resource was outside CapitalOne but still inside of Amazon. CapitalOne was secure relative to the all-the-way outside world, but assigned too much permission to an intermediate layer of systems designed to be friendly to users inside AWS, and there are in fact all kinds of actors using AWS with all kinds of motivations. One of them decided to steal data.
To return to the metaphor a moment, CapitalOne’s configuration treated AWS like a safe “inside” space, and the reality is that the cloud exposes you to systems that are neither so safe as the pure “inside” nor so dangerous as the pure “outside” of an on-prem data center. Secure use of the cloud requires recognition of shades of gray and the security risks that each presents.