As long as there have been humans, the one immutable truism is that mistakes happen. Anybody who has, for example,...
stepped on the gas thinking they were in drive while actually being in reverse can attest to the truth of this. Yes, to err is human.
In the technology world, these oops scenarios -- the very natural and very human mistakes we all make -- can translate directly into risk for organizations. A mistake in the configuration or development of devices, applications and equipment can introduce security loopholes that attackers can use to gain entry or otherwise subvert our security in a variety of unintended ways.
While this has always been the case for technology, in the cloud, the situation is compounded because mistakes are most likely both always on and internet-accessible. Meaning, when a mistake is made in the cloud, attackers can poke at it directly at any time. We've seen this play out very publicly and at surprising scale in the trade press. For example, headlines are abuzz with an Amazon Simple Storage Service (S3) bucket configuration issue at AgentRun that exposed their personally identifiable information of insurance customers -- including financial, medical and health data -- and a misconfigured Kubernetes instance that exposed secret information, including S3 bucket credentials, to whomever might choose to come and view them.
Given that cloud security misconfigurations like this continue to be an issue, the question for savvy security pros becomes, "What can we do about it to ensure that it doesn't happen to us?" Fortunately, this is a solvable problem. Just like there are methods and strategies for finding and closing misconfigurations for on-premises deployments, so too are there strategies and methods to find and close issues in the cloud. However, just as is the case for on-premises strategies, doing this requires effort, discipline and adequate preparation.
Minimizing likelihood and effect
A key element of any strategy designed to help address cloud security misconfigurations should involve doing two things in tandem. First, reduce the likelihood of cloud security misconfigurations occurring and second, take steps to minimize the effect when it does. Understanding the security model of the cloud provider used is fundamental to both. Specifically, everyone involved in any cloud deployment should understand both what the feature options are for the cloud provider you've chosen to help secure that deployment, as well as how their security model and features work. The security professionals, the engineers and application developers that use those cloud resources, and the ops teams that help support it should all have that understanding.
That doesn't sound like rocket science, but it's worth stating explicitly for a few reasons. First, because not all cloud providers are the same; securing an S3 bucket is different from securing Azure Storage, which in turn is different from securing storage in Google Cloud. They are similar conceptually, but they are not the same. Second, different services from the same provider may involve different concepts and tools relative to each other. This means that not only do you need to be educated on the specific provider's security model and philosophy, but you also need to be versed in the specific product set the company is using as well.
Being educated about what the security-relevant configuration options are and what they do is a minimum. For example, with Docker, understanding why it's problematic to run containers as root is important. On S3, understanding nuances, like that the "authenticated users" group really means "authenticated to Amazon" and not "authenticated to your app or organization," is likewise a must. Because of the variability here both by product and by service, it's useful to recognize that there is not one guide or set of best practices that will address every possible permutation at once. However, at an abstract level, there are a few key principles that can help; for example, encrypting data when possible, adopting principles of least privilege, using layered defenses, ensuring appropriate monitoring and so on -- in other words, all the same security hygiene principles that have always applied. The key component to avoiding cloud security misconfigurations is planning out how security principles will transfer over to the cloud and what options are available to you to put them into practice for your own deployment.
Trust, but verify
One thing to recognize is that, no matter what steps you take or how diligent you are, cloud security misconfigurations will still happen. There's no way to reduce the likelihood to zero; over a long enough time period, something, somewhere will be misconfigured. This means that no matter what you do to minimize the chances of cloud security misconfigurations occurring, and no matter what steps you put in place to minimize the effects, that it's still a good idea to build out some capacity to proactively look for and address cloud security misconfigurations when they do happen.
There are a few different strategies to employ to make this happen. There are automated commercial tools that can assist here, such as AlertLogic, Detectify and others, as well as open source tools like CloudSploit for AWS users. These are an option for security teams with the budget, resources and skills to interpret the results generated. The same way a vulnerability scanner is used to find and flag misconfiguration issues in on-premises technology, so too can an equivalent process be set up for cloud. Of course, it's necessary to know what cloud services the organization employs in the first place.
In addition to this, consider systematic assurance and audit activities for cloud environments. For example, technology audit teams can review a sample or subset of devices looking for possible cloud misconfiguration issues. A large organization probably won't be able to review every single object in every cloud environment -- this would be analogous to manually reviewing every node on the internal network -- but it's possible to at least look at a sample. Combined with robust training, this can be a useful short-term strategy in the event that time or budget precludes an automated approach.