Cloud Security (CSPM)¶
Cloud Security Posture Management covers how your cloud accounts are configured — storage that is publicly readable, over-permissive roles, unencrypted databases, security groups open to the world.
Why cloud posture is its own problem¶
Cloud misconfigurations differ from other findings in three ways that change how you work with them:
They are created by anyone with access. A single console click can expose a storage bucket. There is no build or release to catch it.
They are immediately exploitable. A publicly readable bucket is not a weakness someone might exploit — it is already accessible to anyone who finds it.
They drift constantly. Cloud estates change daily, so posture is a moving picture rather than a periodic assessment.
What the module holds¶
Cloud posture reaches NxSAM from more than one platform, and the module has a set of screens for each, because the platforms describe posture differently.
Prisma CSPM — four screens, fed by Prisma Cloud:
| Screen | Shows |
|---|---|
| Asset Inventory | The cloud resources discovered in your accounts |
| Alerts | Resources currently violating a policy |
| Compliance | How your cloud estate measures against frameworks |
| Policies | The rules being evaluated |
CSPM — five screens, fed by Cortex CSPM and SentinelOne CSPM:
| Screen | Shows |
|---|---|
| Assets | The cloud resources discovered, with their open issues and cases |
| Issues | Individual findings — one rule failing against one or more assets |
| Cases | Issues grouped into a single piece of work, with a severity of their own |
| Rules | The individual checks that raise issues |
| Policies | Named groups of rules, and whether each group is switched on |
The two sets do not merge. A resource that both platforms see appears once under each, and the counts on one set say nothing about the other.
Rules, issues and cases¶
The CSPM screens use three words that are easy to run together, and the module is much easier to read once they are kept apart:
- A rule is a single check — "storage must not be publicly readable".
- An issue is that rule failing against a resource. One rule can raise many issues; the issue row says how many assets it touches.
- A case collects related issues into one thing to work on, and carries its own severity and status. Fixing a case is fixing every issue in it.
Every row on those three screens links sideways — an asset to its issues, an issue to its case and its rule, a rule to its issues, a policy to its rules — so you can start from whichever you were asked about and reach the others without searching.
Alerts, not vulnerabilities¶
1 where you are · 2 policy, asset and account
A CSPM alert says a resource is currently in a state a policy forbids. That is a statement about now — fix the configuration and the alert clears on the next evaluation.
This differs from a vulnerability, which describes a flaw that persists until patched. It is why cloud alert counts move far more than vulnerability counts, and why a spike is often one change affecting many resources rather than a genuine deterioration.
Reading alerts well¶
- Public exposure first. Anything reachable from the internet outranks internal misconfigurations regardless of the severity label.
- Identity and access next. Over-permissive roles are the route from a small foothold to a large incident.
- Look for patterns. The same misconfiguration across many resources usually means a template, module or provisioning pipeline is producing it. Fix the source and the resources follow.
Fix the pattern, not the resource
Correcting fifty individually misconfigured buckets achieves nothing durable if the template that created them is unchanged — the next fifty arrive the same way.
Compliance view¶
The compliance screens map cloud configuration against frameworks, which is what makes cloud posture reportable to an auditor rather than only to engineers.
As with policy compliance, read the failures rather than the percentage: a high score can coexist with a small number of severe exposures.