5 Vexing Cloud Security Issues

Cloud environments are complex. So is the task of keeping them secure. With so many different types of cloud architectures, services and deployment models, it can be hard to know which cloud security best practices apply to your environment. That’s why it may be simpler to approach cloud security by focusing on what not to do, rather than what you have to do. In this article, we explore five common cloud security issues that can leave organizations with cloud environments ripe for attack.

1. Using default IAM settings

Among the many cloud security issues that companies struggle with, identity and access management (IAM) can be especially challenging. IAM systems provide the foundation for securing access to sensitive resources. IAM policies define who can and can’t access applications and data.

But IAM protects you only if you use it properly. And, in many cases, the IAM settings that are deployed by default to govern a cloud resource don’t provide the proper level of access control.

In addition, the IAM policies that effectively protected a resource at one point in time may become outdated, as the environment evolves. For example, you may have policies that assign access rights to a user who has changed roles within your organization and should no longer be able to access the resources in question.

To avoid a major cloud security mistake, then, make sure you proactively assess the IAM rules you have in place and determine whether they adequately protect your resources.

2. Running untrusted containers

If you deploy applications in the cloud using containers, you’re probably familiar with best practices like scanning your container images for vulnerabilities prior to deployment.

A common cloud security issue, however, is blindly trusting containers from third-party sources. It’s particularly easy to fall into this trap when you are deploying sidecar containers to connect resources like third-party logging services to your containers. You may think that, if the sidecar containers come from a company or open source project you trust, they can be deployed without issue.

The reality, of course, is that even trusted third parties can make security mistakes. You should scan all containers before deploying them, regardless of where they originate.

3. Hosting data other than containers in container registries

Another cloud security issue that has caused problems is using container registries to host resources that have no business being inside a container registry.

A classic example is the 2016 story of Vine exposing its entire source code through an unsecured container registry. While the biggest mistake in this incident was the assumption that the registry, which lacked access controls, was secure because its URL had not been publicly published, choosing to store source code inside a container registry was a poor practice in the first place. Source code should live in source code management platforms, not container registries.

While it may be tempting to use your container registries as a convenient place for uploading all types of data (which is possible in a technical sense), resist this temptation by using container registries only for their intended purpose: hosting application container images.

4. Not managing “zombie” cloud infrastructure

Zombie cloud infrastructure is cloud resources that users create without permission, and that consequently are not properly identified or managed through central IT processes. For example, a user may spin up a VM in the cloud without notifying anyone else or properly tagging it. As a result, the VM won’t be monitored or audited by whichever tools your business has in place to handle those processes. The user may also forget to shut the VM down, leaving it to run indefinitely.

Zombie infrastructure is often discussed in the context of minimizing cloud spend, since rogue resources can bloat cloud computing bills. But it’s equally dangerous from a security perspective. Unauthorized cloud resources increase the attack surface of your cloud environment, and they are at especially high risk if they are not being monitored in the way they should be.

For that reason, failure to detect and remove zombie cloud resources can be a major cloud security mistake. Avoid it by establishing clear rules within your organization regarding the process for launching cloud resources. At the same time, use monitoring and auditing to detect resources that exist within your environment but were not authorized.

For example, you could establish a policy that requires developers or IT engineers to submit a ticket whenever they spin up a cloud resource. Then, you can correlate data from your ticketing system with data from your cloud environment to identify resources that were created without an associated ticket. These would most likely turn out to be zombie cloud infrastructure.

5. Settling for compliance

If you run workloads in the cloud today (or on-premises, for that matter), there’s a decent chance--depending on which jurisdictions you operate in, as well as which types of workloads you run--that they need to comply with regulatory rules like the GDPR, CCPA or HIPAA.

Businesses tend to invest a lot of resources in complying with these frameworks, which is great. However, it may be a mistake to stop with the baseline requirements of compliance mandates. In most cases, the security rules that the major compliance frameworks impose are relatively non-specific and non-exhaustive.

Instead, set your standards higher. For instance, instead of settling for “reasonable security”--the security paradigm at the core of the GDPR--strive for maximum security. These are, of course, ambiguous terms. But the difference between them could translate to something like establishing access controls that prevent unauthorized access (which would be a form of reasonable security) versus rules that enforce least privilege and zero trust (which would be maximum security).

Conclusion: A Universal Approach to Cloud Security

No matter what your cloud architecture looks like or which types of workloads run in it, the security issues described above may jeopardize it. While effective cloud security best practices extend far beyond this list, addressing these issues head on is a good first step toward building a secure cloud environment.