top of page
  • Komodo Research

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

Updated: Apr 4, 2023

The cloud can be a wild place. It is difficult enough to set up a simple working environment, let alone a secure one with dozens of acronyms, hundreds of products, and even more rulesets. But, 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. However, while many of our clients reach out to us to perform black-box penetration tests for their platforms, they don’t pay much attention to their entire cloud environment. Instead, they focus on the customer-facing "public" portion, 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 misconfigurations in cloud security settings, as seen in the Capital One Breach and Imperva Breach.

This blog post will debunk two common myths about cloud environments and their relation to information security. We will also explain the cloud security review process and its importance in SOC2 / ISO27001 or any security transition and certification process.

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

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

Although cloud infrastructure is excellent for rapid development, supporting DevOps pipelines and scalability, transitioning to the cloud also has security drawbacks.

Cloud Security Review

In cloud environments, each server (or service) uses an identity 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, attackers who manage 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 they have 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 matter how, it can vary from SSRF, Remote Code execution, or just some random exposed Git repository). Using these credentials, they may try to perform any of the following:

Enumerate S3 buckets and download their content

Perform privilege escalation due to misconfigured IAM configuration

Set up new rules in security groups

Install backdoors in a container registry

Deploy Crypto mining machines

Purge 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 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. Therefore, companies should perform a cloud security review to understand the feasibility of such an attack.

By nature, a cloud security review is conducted using 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 system’s context is critical for the success of the security review (for example, in some cases, S3 buckets should be publicly open by design as lacking context, can be treated mistakenly as a “vulnerability”).

The first activity in a cloud security review is mapping the cloud-based attack surface (should one access Grafana / MongoDB / Elasticsearch from the internet?).

After mapping the attack surface, the hypothesis shown below is that an attacker now has some access to your cloud environment. So the question we aim to answer is, "what damage can an attacker do at this point?"

The topics 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 most of these incidents. Therefore, implementing a cloud security review while becoming SOC2 / ISO27001 compliant is just as important as performing a penetration test or a security code review for a specific system.

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

Whether you are 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


bottom of page