Can you imagine a situation in which you would give full control access to everyone on a Windows file server for...
sensitive information about your company? If so, would you put the server up on the public internet? If you're a security professional, your hair may be standing on end just thinking about that scenario.
As dire as the above example of the file server might seem, organizations often share data in the cloud in a way that is directly analogous. Over the past year, for example, we've seen misconfigured Amazon Simple Storage Service (S3) buckets cause data leakage when cloud storage data repositories are shared in ways that companies don't expect; impacted companies include Dow Jones, World Wrestling Entertainment Inc., Verizon Inc., as well as numerous others. It's not just S3 repositories though; researchers at RedLock Inc. more recently found similar issues with misconfiguration of the G Suite -- specifically, the accidental sharing of data to the public through a misconfiguration of Google Groups.
There is often a misconception that we cede responsibility for the entirety of configuration management in the cloud to the service provider. Or, barring that, we at least share the responsibility for configuration management in the cloud with the service provider. However, as recent events highlight, the situation is a bit more nuanced than it might appear on the surface. Not only is configuration management in the cloud equally as important as other use cases, but it is potentially even more so, as mistakes or misconfigurations can cause data to be publicly accessible -- in a location that is under active scrutiny both by researchers as well as potential attackers.
How does this happen?
From a practical point of view, the question for most practitioners based on the above is, "Can this happen to me?" The answer to that is based on a few factors. The most important thing to note at the outset is that these exposures are caused by misconfiguration -- not a vulnerability in the underlying cloud platforms. Meaning, inadvertent as it may have been, these issues occurred because someone, somewhere configured the services this way. That's good news because it means that, appropriately configured, this issue will not happen to you. It's bad news because it means that, if you have this problem, there's no patch you can apply that will suddenly fix it.
There are a few ways that this issue can arise. It can occur because of misunderstandings of how access control artifacts such as access control lists operate on these platforms. For example, S3 has a setting to allow authenticated users to access to data. It may seem obvious to interpret this as referring to users who have been authenticated as being part of the organization whose data is contained in the bucket. However, in reality, it refers to any user who has been authenticated to the Amazon platform, regardless of their employer or organizational affiliation.
Likewise, this kind of misconfiguration can also occur when individual users are responsible for setting permissions. If they either misinterpret what the permissions mean or fail to restrict access appropriately, they can inadvertently expose information beyond what they intend -- or what the organization is comfortable with. It can also arise due to the specifics of the UI in cloud services: when the UI is less flexible than needed, when it isn't intuitive or when more fine-grained settings need to be set programmatically rather than via the UI.
The short answer is that, unless you have taken steps to actively safeguard against it, configuration is a byproduct of human activity. Human error can and does occur; the astute organization plans around this and takes active measures to find and address human error when it occurs.
What can you do about it?
For organizations that use cloud storage, good practice means taking steps to prevent issues with configuration management in the cloud to the extent they can -- and to put in place measures to identify them if they do arise.
The first part of that, preventing the human error, means understanding the security features of the platforms you employ and thinking through how users might interact with that platform and the mistakes they might make along the way. For example, Google Groups for Business allows administrators to restrict sharing settings such that individuals outside the organization can't access those groups. Likewise, Amazon S3 enables administrators to set identity access management (IAM) policy that governs access to specific buckets. The details of using these features will vary according to the type of service you employ, but the salient point is that administrators know what they are, and they -- systematically and with user error in mind -- evaluate how and where they are using those features. Note that this presupposes that administrators also understand a few other things, like what cloud services are used in the first place, how they're used, what data is contained there and so on.
Fortunately, because this is ultimately an exercise in configuration management in the cloud, many of the mechanisms that security professionals are already familiar with will apply here. A tool like, for example, the Center for Internet Security Amazon Web Services Foundations benchmark, can give guidance about what specific security features exist for that platform and how to enable or configure specific settings like for CloudTrail and IAM. Hardening guides like the G Suite Security Best Practices Guide in the G Suite Administrator console can provide useful information. Ultimately though, the first step is making sure that someone is accountable for these steps being taken and that they have the time and authority to make that happen.
Beyond this, it is advantageous to put mechanisms in place that watch for these situations and provide feedback to administrators should they occur. One way to do this is through automated tools; there are several tools in the marketplace that will help monitor and track cloud service configuration, particularly those from larger, more ubiquitous providers. However, even if you don't have access to those, there are other options available. One such option is "old school" validation -- staying alert to how business teams use the cloud and enlisting partners to help ensure the configuration is appropriate. In some cases, that could be the users themselves. In larger organizations, it might be internal audit teams, particularly more technically astute teams. The specific mechanisms will vary based on the type and technical sophistication of the organization, but thinking it through and putting some validation in place is the important part.