What is CSPM?

A CSPM tool does four things in a loop: it gets read-only access to a cloud, collects the current configuration, tests it against a set of rules, and lists the failures as findings that name the exact setting or resource.

What gets read, per platform

• Microsoft 365: the tool reads tenant policy through Microsoft Graph, for example whether Conditional Access requires MFA for administrators, or whether audit log search is switched on.
• Azure: with the Reader role on a subscription it can see that a storage account or database still accepts public network access.
• Google Cloud: with viewer-level roles it can see that a virtual machine runs as the default service account, or that a service account holds owner rights.
• AWS: by assuming a read-only role it can see that a root user has no MFA, or that an S3 bucket has no Block Public Access.

Where the rules come from

Rules usually come from a published standard such as a CIS Benchmark, or from the vendor's own baseline. Each cloud also has a built-in feature in this area: Microsoft Defender for Cloud, Google Security Command Center and AWS Security Hub CSPM. Each is designed around its own provider, so teams running several clouds often add a tool that reports across all of them in one place.

Cloud services are built to be easy to switch on, and the defaults are not always the safest choice. Every new storage account, mailbox policy or role assignment is a decision someone made once and may never have revisited.

The joint NSA and CISA advisory on common misconfigurations (AA23-278a) lists the weaknesses its teams keep finding in organizations of every size. They include default configurations left in place, poorly separated user and administrator privileges, and weak or misconfigured MFA. None of these needs a clever exploit; an attacker only has to find the setting.

The cloud providers document who owns the problem in their shared responsibility models. They secure the underlying platform, while the customer stays responsible for how identities, data and services are configured. CSPM is the routine that checks your half of that split.

CSPM is often mixed up with neighbouring terms. The short version: CSPM asks "is this set up safely?", while the others ask about a different layer.

A configuration that is fine today can break tomorrow, which is why CSPM is closely tied to configuration drift.

1. Choose the standard you want to measure against. A CIS Benchmark for each platform you run is a sensible default because it is public and specific.
2. Give the tool read-only access only. Reader on Azure, a viewer-level service account on Google Cloud, an assume-role on AWS and read-only Graph permissions on Microsoft 365 are enough to collect settings.
3. Run a first scan and read the results by impact, not by count. Start with identity and public exposure findings.
4. Before you change a setting, ask what it affects. A stricter sign-in policy, for instance, can lock out users or service accounts.
5. Repeat on a schedule so that new findings show up soon after they appear.

ConfigCobra's CSPM module checks your configuration against CIS benchmarks on Microsoft 365, Azure, Google Cloud and AWS:

• Microsoft 365: CIS Microsoft 365 Foundations Benchmark v7.0.0, 160 controls across Level 1 and Level 2.
• Azure: four CIS Azure benchmarks, 339 controls in total, covered by one scan.
• Google Cloud: CIS Google Cloud Platform Foundation Benchmark v5.0.0, 93 controls.
• AWS: four CIS AWS benchmarks, 306 controls in total.

Access is read-only, so ConfigCobra never changes your tenant. For each failing control it gives a severity estimate (ConfigCobra's own prioritisation, not something CIS publishes), a copy-paste fix script or portal steps, and a PDF report with findings and evidence.