The cloud can be a wild place. With dozens of acronyms, hundreds of products and even more rule sets, it is difficult enough to set up a simple working environment, let alone a secure one. Practically, the ease of deploying cloud services means it is also very easy to make mistakes — even too easy.
Most startups and SaaS vendors 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 in their entire cloud environment; rather, they only focus on the customer-facing “public” portion of it, usually a web-based 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 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 discuss its importance in SOC2, ISO 27001 or any other security transition and certification process.
Myth No. 1: The cloud is inherently more secure than ‘traditional’ infrastructure.
Although cloud infrastructure is great for rapid development because it supports DevOps pipelines and scalability, transitioning to the cloud also has its security drawbacks.
In cloud environments, each server (or service) uses an identity that allows it to perform actions or interact with different services. 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 can directly reach the API (exposed to the internet by design), deploy new services, install backdoors or pull data from a public cloud storage resource (given the attacker has permissions to do so). The blue team in this case will have a hard time both detecting and blocking the activity.
Myth No. 2: The cloud provides a better audit and security visibility.
Imagine an attacker gaining access to credentials of a random virtual server 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 public cloud storage resources and downloading their content.
• Performing privilege escalation due to misconfigured web services.
• Setting up new rules in security groups.
• Installing backdoors in a container registry.
• Deploying crypto mining machines.
• Purging all of your data.
From experience with our customers, I’ve found that 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 them 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. Because 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 (e.g., in some cases, S3 buckets should be publicly open by design; lacking 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. The question you should aim to answer is, “What damage can an attacker do at this point?”
The topics that are examined should include:
• Configuration of web service 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.
Conclusion
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 or ISO 27001 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.
Whether your run a startup or a big corporation, when planning the security road map for your IT, ask yourself the following question: “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 with a cloud security review.