Cloud Security (CSPM): every screen and column¶
Two families of screens, and no row actions on either — CSPM is a reporting surface rather than a working queue, because the remediation happens in the cloud provider rather than here.
- Prisma CSPM — Asset Inventory, Alerts, Compliance Standards and Policies, fed by Prisma Cloud. Described first, below.
- CSPM — Assets, Issues, Cases, Rules and Policies, fed by Cortex CSPM and SentinelOne CSPM. Described from CSPM: Assets onwards.
The two families do not share data. A resource both platforms see appears once in each, and the two Policies screens are different lists with the same name.
Asset Inventory¶
Everything the posture tool discovered across your cloud accounts.
| Column | What it holds |
|---|---|
| Asset details | The resource name and its provider identifier |
| Asset Type | S3 bucket, EC2 instance, SQL database, storage account, and so on |
| CSP Details | Which cloud, which account, which region |
| Status | Whether the resource is currently present |
| Alerts Distribution | Open alerts against it, split by severity |
| Total Policies | How many checks apply to this resource type |
| Last Scanned Date | When posture was last evaluated |
Total Policies is the column that explains an empty alert count. A resource with two applicable policies and no alerts is genuinely clean; one with forty and no alerts has probably not been evaluated yet — check Last Scanned Date before concluding it is compliant.
Alerts¶
The findings. One row is one policy failing against one resource.
| Column | What it holds |
|---|---|
| Alert ID | The provider's identifier, for cross-referencing in their console |
| Policy Info | Which check failed |
| Asset Info | Which resource, in which account |
| Reason | Why it failed — the actual configuration found |
| Severity | As the policy defines it |
| Status | Open or resolved |
| Alert Triggered | When it first fired |
| Last Updated | When it last changed |
Reason is the column people skip and should not. Two resources failing the same policy often fail it for different reasons — one bucket is public to everyone, another is public to a single partner account — and the remediation differs accordingly.
Alert Triggered against Last Updated tells you whether an alert is stable or flapping. An alert triggered months ago and updated yesterday is being re-evaluated and still failing; one triggered and updated at the same moment has fired once.
Compliance Standards¶
Which benchmarks posture is measured against.
| Column | What it holds |
|---|---|
| Standard Name | CIS AWS Foundations, PCI DSS, ISO 27001, and so on |
| Standard Description | What the standard covers |
| Mapped Policies | How many individual checks make it up |
| Enabled | Whether it is switched on |
Enabling a standard does not run anything
Standards select which policies count towards a compliance figure. The policies themselves evaluate regardless. Turning a standard on therefore changes the reported percentage immediately, with no scan involved — which surprises people who expect a delay.
Policies¶
The individual checks behind the standards.
| Column | What it holds |
|---|---|
| Policy Details | The check and what it looks for |
| CSP | Which cloud it applies to |
| Severity | What an alert from it is rated |
| Status | Whether the policy is active |
| Alerts | How many are currently open against it |
| Auto-Fix | Whether the provider can remediate it automatically |
| Last Evaluated | When it last ran |
| Created | When the policy was defined |
Auto-Fix is the most actionable column in the module. A policy marked auto-fixable can be remediated by the cloud provider without a change request — so a list of high-alert auto-fixable policies is usually the fastest available posture improvement.
It is also worth checking before escalating: an alert on an auto-fixable policy that keeps returning usually means auto-fix is available but not enabled, rather than that the fix is not working.
CSPM: Assets¶
The cloud resources the posture platform has discovered, with what is currently wrong with each. Rows are the resource; the two count columns are doors into the other screens.
| Column | What it holds |
|---|---|
| Asset Details | The resource name, and the identifier the platform knows it by |
| Asset Type | The kind of resource — a bucket, an instance, a database, a role |
| Provider | Which cloud it lives in |
| Issues → | Open issues against it, by severity. The arrow opens the Issues screen filtered to this asset |
| Cases → | Cases that include it, by severity. The arrow opens the Cases screen filtered to this asset |
| Last Observed | When the platform last saw the resource |
The severity chips above the table — Critical, High, Medium, Low — filter the list to assets carrying an issue of that severity. Asset Type and Provider are the quick filters; More Filters opens the full set, and Reset Filters clears everything at once. Export downloads the current list as shown.
Clicking the asset name opens Asset Details: the provider and its own identifier, the realm and region, the type as a category, class and name, when the resource was first and last observed, and the issues and cases against it broken down by severity.
Last Observed is what tells you whether a clean asset is clean. A resource with no issues and a Last Observed date from last night has been checked and passed. One with no issues and a Last Observed date from three weeks ago has stopped being seen — it may have been deleted, or the account it lives in may have stopped syncing — and its empty issue count is not evidence of anything.
CSPM: Issues¶
The findings. One row is one rule failing against one or more assets.
| Column | What it holds |
|---|---|
| Issue name | What was found, and the platform's identifier for it |
| Severity | As the rule rates it |
| Domain / Type | The area of posture the issue belongs to, and the kind of issue it is |
| Detection Method | How the platform found it |
| Status | Where the issue is in its lifecycle |
| Asset Count | How many resources this one issue touches |
| Case ID | The case the issue has been grouped into. Opens the Cases screen on that case |
| Rule ID | The rule that raised it. Opens the Rules screen on that rule |
Quick filters: Severity and Status. More Filters adds domain, category and detection method. Export and Reset Filters behave as on Assets.
Clicking the issue name opens Issue Details: the issue's identifier and name, its domain, detection method, asset count, the case and rule it belongs to, and when it was last updated.
Asset Count is the column to sort by when deciding what to fix first. An issue on one asset is one change. An issue on two hundred assets is almost always a template, a module or a provisioning pipeline producing the same misconfiguration repeatedly, and fixing the source clears all two hundred at once — while fixing the resources one at a time clears nothing durably.
CSPM: Cases¶
Issues grouped into one piece of work. A case is what gets assigned, tracked and closed; the issues inside it are the evidence.
| Column | What it holds |
|---|---|
| Case name | What the case is about, and its identifier |
| Severity | The case's own rating, which is not necessarily the highest issue in it |
| Status | Where the case is |
| Domain | The area of posture it covers |
| Issues → | The open issues in it, by severity. The arrow opens the Issues screen filtered to this case |
| Modified | When the case last changed |
The severity chips filter cases by their own severity. Quick filters: Domain, Severity, Status. Export and Reset Filters as elsewhere.
Clicking the case name opens Case Details: identifier and name, domain, when it was created and last modified, and its issues broken down by severity.
A case's severity is set by the platform, not summed from its issues
A case rated High can contain a Critical issue, and a case rated Critical can contain only Medium ones — the platform rates the case on what the combination means, not on the worst member. When the two disagree, the case rating is the one the platform intends you to act on.
CSPM: Rules¶
The individual checks. Every issue on the Issues screen was raised by one of these.
| Column | What it holds |
|---|---|
| Rule name | What the rule checks, and its identifier |
| Severity | What an issue from it is rated |
| Type | The kind of rule |
| Providers | Which clouds it applies to |
| Status | Whether the rule is enabled |
| Issues Count | Open issues it has raised. Opens the Issues screen filtered to this rule |
| Updated | When the rule definition last changed |
Quick filters: Provider, Rule Class, Severity, Type; More Filters for the rest. Clicking the rule name opens Rule Details: identifier, name, class, type, providers, issue count, and when the rule was created and last modified.
A disabled rule with a non-zero issue count is a rule that used to run. Its issues are historical — nothing is re-evaluating them — and they will neither clear nor grow. Either re-enable the rule in the platform or treat those issues as closed; leaving them counted as open inflates every total above them.
CSPM: Policies¶
Named groups of rules, as configured in the posture platform. A policy is how the platform decides which rules run where, so this screen explains why a rule that exists is or is not producing issues.
| Column | What it holds |
|---|---|
| Policy name | The group, and its identifier |
| Mode | How the platform applies the policy, as set in the platform |
| Rule Matching | How the policy selects its rules, as set in the platform |
| Labels | The platform's tags on the policy |
| Status | Whether the policy is enabled |
| Rules Count | How many rules it contains. Opens the Rules screen filtered to this policy |
Quick filters: Mode, Rule Matching, Status. Clicking the policy name opens Policy Details: identifier, name, description, mode, rule matching, status, rule count, and when it was created and last updated.
Mode and Rule Matching are the platform's own settings, shown here so you can read them without opening the platform. NxSAM does not change them.
Why there are no row actions¶
Everything here is evidence about a cloud account that NxSAM reads and does not control. Remediation happens in the provider's console or in the infrastructure code that produced the resource. The module's job is to say what is wrong, where, and how it compares to the standard you are being measured against — not to change it.
The CSPM screens add the sideways links — asset to issues, issue to case and rule, rule to issues, policy to rules — which is a way of reading the evidence rather than acting on it. Nothing on any of the nine screens writes back to a cloud account.