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.
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.
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)
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
Conclusion
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