• Komodo Research

Is my Cloud going to Rain on me? (what is a Cloud Security Review and why do I need it?)

Updated: Apr 14

The cloud can be a wild place, with dozens of acronyms, hundreds of products, and even more rulesets it is difficult enough to set up a simple working environment, let alone a secure one. Practically, the “easiness” of deploying cloud services makes it also very easy to make mistakes, even too easy.

Cloud Security Testing

Most startups and SaaS vendors will operate in the cloud for obvious reasons, while many of our clients reach out to us to perform black-box penetration tests for their platforms, they don’t put much attention to their entire cloud environment, rather only to the customer-facing “public” portion of it, usually a web-dashboard or some REST API exposed to their customers, which is only the tip of the iceberg.

Recent security breaches show that most of the leading reasons for these breaches are due to misconfiguration in the cloud security settings, as seen in the Capital One Breach and Imperva Breach.

In this blog post, we’ll debunk two common myths about cloud environments and their relation to information security, explain the process of a cloud security review, and its importance in SOC2 / ISO27001 or any other security transition and certification process.

* Note The examples given below are in Amazon’s AWS jargon, but the concept is the same for every major cloud vendor such as Google’s GCP and Microsoft's Azure.

Myth #1 – The cloud is inherently more secure than “traditional” infrastructure

Although cloud infrastructure is great for rapid development as it supports DevOps pipelines and scalability, transitioning to the cloud also has its security drawbacks.

Cloud Security Review

In cloud environments, each server (or service) uses an identity that allows it to perform actions or interact with different services. (for example, an EC2 Instance with permissions to view / edit the content of an S3 bucket). From our experience, the biggest pitfall in cloud security is the improper management of permissions for the deployed services.

In addition, moving to the cloud makes you lose the concept of an “internal network” and traditional network-based boundaries. For example, an attacker who manages to somehow “steal” the identity of a service (such as an EC2 Instance) can directly reach the AWS API (exposed to the internet by design), deploy new services, install backdoors or pull data from S3 buckets (given he has permissions to do so). The blue team in this case will have a hard time both detecting and blocking the activity.

Myth #2 – The cloud provides a better audit and security visibility

Imagine some attackers gaining access to credentials of a random EC2 instance in your environment (it doesn’t really matter how, it can vary from SSRF, Remote Code execution, or just some random exposed Git repository). Using these credentials, the attacker may try to perform any of the following:

Enumerating S3 buckets and downloading their content

Performing privilege escalation due to misconfigured IAM configuration

Setting up new rules in security groups

Installing backdoors in a container registry

Deploying Crypto mining machines

● Purging all of your data (DB’s and storage buckets)

cloud security assessment

From experience with our customers, 9 out of 10 will not detect these actions until it’s too late. A professional cloud security assessment should identify these blind spots and address these in the security report.

How to perform a cloud security review?

The attack scenarios listed above are only a fraction of the potential attack paths in modern cloud environments, in order to understand the feasibility of such an attack, a cloud security review should be performed.

By nature, a cloud security review is conducted in a “White-Box” approach, the reviewer needs permissions to the API and console access to run queries and examine the cloud configuration. As every system’s design varies, there is no automatic silver bullet - understanding the context of the system is critical for the success of the security review (For example, in some cases S3 buckets should be publicly open by design, lacking the context, this can be mistakenly treated as a “vulnerability”).

The very first activity in a cloud security review is the mapping of the cloud-based attack surface (should that Grafana / MongoDB / Elasticsearch really be accessed from the internet?).

After mapping the attack surface, the hypothesis for the points below is that an attacker now has some level of access to your cloud environment and the question we aim to answer is “what damage can an attacker do at this point?”

The topics that are examined include:

Configuration of IAM policies, groups and users

Management and configuration of storage services

Monitoring and audit rules

Backups, Redundancy and disaster recovery

● security configurations of the various services compared to security best practices


Data breaches in recent years show that security misconfiguration in the cloud is the root cause of the majority of these incidents. Implementing a cloud security review during the process of becoming SOC2 / ISO27001 compliant is just as important as performing a penetration test or a security code review for a specific system.

Just as developers are not responsible for conducting penetration tests and code reviews for their own code, Cloud operations should not oversee their own cloud security implementation. These types of security reviews should be performed by certified professionals.

Either a startup or a big corporation, when planning the security roadmap for your IT, ask yourself – “If attackers gain initial access to my cloud, what will they be able to perform?” The odds are that this question needs to be addressed by a professional, hands-on cloud security review.

As seen also in Forbes

Recent Posts

See All