Cloud misconfigurations are by far the biggest threat to cloud security, according to the National Security Agency (NSA). The 2022 IBM Security X-Force Cloud Threat Landscape Report found that cloud vulnerabilities have grown a whopping 28% since last year, with a 200% increase in cloud accounts offered on the dark web in the same timeframe.

With vulnerabilities on the rise, the catastrophic impact of cloud breaches has made it clear that proper cloud security is of the utmost importance. And so the question arises: Are your organization’s misconfigured cloud resources being advertised to malicious hackers?

Cloud misconfigurations put data at risk

Cloud misconfigurations are vulnerabilities waiting to happen. Malicious attackers are always hunting for misconfigured cloud assets because they can be a doorway to the theft of location data, passwords, financial information, phone numbers, health records and other exploitable personal data. Threat actors may then leverage this data for phishing and other social engineering attacks.

These misconfigurations happen for all kinds of reasons. One cause is the failure to change default settings, which tend to be too open.

Another is configuration drift, where changes to various components are made ad hoc, without consistency across cloud assets and auditing to avoid disparities.

The sheer complexity of cloud-native platforms makes misconfigurations more common. These risks are further complicated by overstretched teams that don’t have the breadth of knowledge to find and fix the misconfigurations.

But one of the most common roots of cloud misconfiguration is a misunderstanding of who is responsible for securing cloud assets. That’s why it’s vital for your organization to understand the Shared Responsibility Model.

This model means that the cloud provider — Amazon Web Service (AWS), Microsoft Azure, Google Cloud Platform (GCP) or others — is responsible only for the cloud’s infrastructure. Their customers — you and your organization — are fully responsible for the security of your data, workloads, applications and all other assets that belong to your organization.

How can cloud assets be misconfigured? Let us count the ways.

Common cloud misconfiguration types

In the broadest sense, most cloud misconfigurations are settings left in a state that’s favorable to the aims of malicious attackers. Here are the most common categories:

1. Excessively permissive cloud access. IBM’s Threat Landscape Report found that in 99% of cases analyzed, cloud identities were excessively privileged.
2. Unrestricted ports, both inbound and outbound.
3. Secret-data management failures, such as passwords, encryption keys, API keys and admin credentials.
4. Leaving open the ICMP (Internet Control Message Protocol).
5. Disabled logging and monitoring.
6. Unsecured backups.
7. Non-validation of cloud security controls.
8. Unblocked non-HTTPS/HTTP ports.
9. Excessive potential access to containers, VMs and hosts.
10. Dangling DNSs. This results from changing a subdomain name without removing the underlying CNAME entry, which may allow an attacker to register it.

How to minimize your risk from cloud misconfigurations

Potential vulnerabilities from cloud misconfiguration never sleep. Cloud servers are always available — to legit users and malicious attackers. Every new cloud deployment increases the organization’s attack surface.

The following steps can help your organization actively defend against attackers seeking to exploit cloud misconfiguration:

1. Implement your security configuration program at the build stage, uniting security and DevOps in a single team.
2. Make sure you hire and/or develop the wide range of skills needed to configure a dynamic cloud environment. Cloud security skills include DevOps experience, automation, networking and internet protocols knowledge, security engineering knowledge, authentication and security protocols knowledge, and others.
3. Apply the Principle of Least Privilege (PoLP) for both machines and humans for access to all systems.
4. Grant the bare minimum permissions for admins to perform their specific tasks, for no longer than necessary.
5. Regularly audit for the validation of current permissions.
6. Maintain visibility through proper monitoring. For example, make sure the DevOps team can access the full stack. They don’t need admin privileges, just reader or viewer privileges so they can see what’s going on.
7. Don’t rely entirely on your cloud provider’s monitoring solution. Embrace monitoring that can be used across all your hybrid and multi-cloud environments.
8. Understand the Shared Security Responsibility model and configure it accordingly. Do not rely on your cloud provider to secure your data, applications and other assets.

Above all, remember that properly configuring the settings present in complex and hybrid cloud environments is a journey, not a destination. Keep auditing. Maintain visibility. And get the staff and expertise on board that you need to manage this complex and crucial responsibility.