Cloud misconfiguration

Cloud platforms ship with hundreds of settings, and each one is a decision somebody has to make. A misconfiguration appears when a setting is left at a permissive default, changed for a quick test and never reverted, or set differently in one subscription than in the rest. Nothing is hacked and nothing is unpatched: the service does exactly what it was told to do.

Typical examples on the four major platforms:

• Microsoft 365: SharePoint sites that allow "Anyone" sharing links, mailboxes that forward mail to external addresses, or a Conditional Access policy that exists but is only in report-only mode.
• Azure: a storage account that still allows anonymous read access to blobs, or a database reachable from the public internet because public network access was never turned off.
• Google Cloud: a Cloud Storage bucket whose access policy grants a role to allUsers. Google offers public access prevention as a guard rail against exactly this.
• AWS: an S3 bucket in an account where Block Public Access is not enabled, or a security group that accepts traffic from every address on an administrative port.

What these have in common is that each can be found by reading configuration. That is why the problem is tractable: you do not need to watch traffic to know a bucket is public, you only need to look at its settings.

The US National Security Agency's guidance on mitigating cloud vulnerabilities identifies misconfiguration of cloud resources as the most prevalent cloud vulnerability, one that can be exploited to reach cloud data and services. The cause is structural. Under the shared responsibility model, the provider secures the underlying infrastructure while the customer decides how identities, networks, storage and sharing are configured. Microsoft's documentation on shared responsibility states this split plainly.

Two things make the problem worse over time. First, cloud environments change daily: new subscriptions, new projects, new apps and new admins each bring fresh decisions. Second, a risky setting often looks harmless to the person who made it. The result is that exposure builds up quietly until someone outside the organisation notices it first.

Misconfiguration is often mixed up with neighbouring ideas. They answer different questions:

In short, a baseline tells you what "right" looks like, drift is one way a setting becomes wrong, and misconfiguration is the name for the wrong setting itself.

1. List every tenant, subscription, project and account you are responsible for. You cannot review what you have not found.
2. Pick a recognised baseline, such as the CIS Benchmark for each platform, so "correct" is defined by something other than opinion.
3. Start with the settings that expose things to the outside: public storage, "Anyone" sharing links, external forwarding and open administrative ports.
4. Next, review identity settings: multi-factor authentication, administrator accounts and Conditional Access.
5. Assign an owner to each finding and agree how fixes are tested before they are applied, because tightening a setting can block people or applications that depend on it.
6. Re-check on a schedule, so a fixed setting that is changed back does not go unnoticed.

ConfigCobra runs a read-only, CIS-based configuration scan, which is the check described above. It covers Microsoft 365 (CIS Microsoft 365 Foundations Benchmark v7.0.0, 160 controls), Microsoft Azure (339 controls across four CIS Azure benchmarks), Google Cloud (CIS Google Cloud Platform Foundation Benchmark v5.0.0, 93 controls) and AWS (306 controls across four CIS AWS benchmarks). Scans run on a schedule you set (daily, weekly or monthly) or ad hoc, and on Azure every finding points at the exact resource. For a failing control it generates a copy-paste fix as a script or portal steps and shows what would change in your environment before you apply it. ConfigCobra never changes a tenant itself.