WEBVTT

1
00:00:00.629 --> 00:00:12.421
Welcome to NxSAM training. This module covers Cloud Security Posture Management - the configuration of your cloud accounts, rather than weaknesses in software.

2
00:00:12.717 --> 00:00:21.535
Cloud misconfigurations differ from every other finding in this platform in three ways, and each one changes how you work with them.

3
00:00:22.142 --> 00:00:34.751
They are created by anyone with access. A single console click can expose a storage bucket - there is no build, no release, and no code review to catch it on the way through.

4
00:00:35.351 --> 00:00:47.529
They are immediately exploitable. A publicly readable bucket is not a weakness someone might exploit at some point; it is already accessible to anyone who finds it.

5
00:00:48.135 --> 00:01:02.425
And they drift constantly. A cloud estate changes daily, so posture here is a moving picture rather than a periodic assessment - which is why this module reports alerts rather than findings from an audit.

6
00:01:03.013 --> 00:01:06.027
It starts with what you actually have.

7
00:01:06.631 --> 00:01:22.888
The asset inventory is every cloud resource discovered across your accounts. It is worth reading on its own, before any alert, because in most organisations it is the first complete answer to what do we actually run in the cloud.

8
00:01:23.480 --> 00:01:37.720
Resources appear here because they were discovered, not because anybody registered them - which is the point. The resources nobody remembers creating are exactly the ones carrying the misconfigurations.

9
00:01:38.353 --> 00:01:50.532
Each row carries the asset details, the asset type, the cloud service provider details, its status, an alert distribution, its total policies, and the last scanned date.

10
00:01:51.155 --> 00:02:06.240
Alerts Distribution is the column to scan, because it shows the severity mix rather than a total. A resource with one critical alert needs attention before one with nine low ones, and a single number would hide that.

11
00:02:06.859 --> 00:02:23.046
Total Policies is the one people overlook, and it is a coverage measure. A resource evaluated against four policies while its neighbours are evaluated against eight is not a well-behaved resource - it is one your policy set barely covers.

12
00:02:23.659 --> 00:02:38.373
And Last Scanned Date is the same trap this product sets in Container Security. A resource with no alerts and a scan date from months ago is not clean; it is unmeasured, and the two look identical in every total.

13
00:02:38.993 --> 00:02:43.038
An alert is a resource currently violating a policy.

14
00:02:43.606 --> 00:02:56.097
The word is chosen deliberately, and the difference from a vulnerability is worth understanding. A vulnerability is a property of software: it exists until someone patches it.

15
00:02:56.710 --> 00:03:13.856
An alert is a statement about right now. The resource is misconfigured at this moment. Change the configuration and the alert stops being true - not because anyone closed it, but because the condition that produced it no longer holds.

16
00:03:14.443 --> 00:03:30.726
Which means alerts resolve themselves when the underlying configuration is corrected, and can reappear the moment somebody changes it back. A recurring alert is not a failure to fix something; it is usually a process that keeps recreating it.

17
00:03:31.359 --> 00:03:41.836
Each alert ties a policy to an asset in an account, and that triple is what makes it actionable - which rule, on what, and whose account it is in.

18
00:03:42.407 --> 00:03:55.257
The list gives each an alert identifier, the policy information, the asset information, a reason, its severity, its status, when it was triggered, and when it was last updated.

19
00:03:55.859 --> 00:04:10.892
Reason is the column that saves the most time. It says why this particular resource failed this particular policy - which is usually the difference between a fix that takes five minutes and an investigation that takes an afternoon.

20
00:04:11.487 --> 00:04:27.505
And read Alert Triggered alongside Last Updated. An alert triggered months ago and updated today is a live problem somebody keeps touching. One triggered months ago and never updated since is a problem nobody has looked at.

21
00:04:28.091 --> 00:04:39.095
That pair is your ageing measure in a module that has no service-level clock, because posture alerts are not raised against a due date - they are true or they are not.

22
00:04:39.681 --> 00:04:47.497
Five filters sit above the list, and between them they answer most of the questions anybody asks of this screen.

23
00:04:48.080 --> 00:05:02.466
Severity is the one to start from, and the options here are drawn from the alerts themselves rather than a fixed list - so a level with nothing against it does not appear and cannot be filtered to an empty screen by accident.

24
00:05:03.072 --> 00:05:20.147
The other four narrow by cloud provider, asset type, alert status and compliance standard. That last one is how you answer the question an auditor actually asks: not "what is wrong", but "what is wrong that this framework cares about".

25
00:05:20.738 --> 00:05:24.229
The rules being evaluated are the policies.

26
00:05:24.830 --> 00:05:38.596
Each policy is a single condition a resource either satisfies or does not - storage is not publicly readable, encryption is enabled, logging is turned on, this port is not open to the world.

27
00:05:39.180 --> 00:05:51.622
And the compliance view rolls those same evaluations up against frameworks, so the question is this account compliant with a given standard is answered from the same data as the individual alerts.

28
00:05:52.239 --> 00:05:59.235
Its columns are the standard's name and description, the policies mapped to it, and whether it is enabled.

29
00:05:59.814 --> 00:06:17.321
Mapped Policies is the honesty column. A standard with a large number of policies mapped is genuinely being evaluated. One with very few is being reported on without being measured, and that gap is worth knowing before somebody quotes the result.

30
00:06:17.933 --> 00:06:33.783
And Enabled decides whether it is evaluated at all. Enable the standards you are actually held to and leave the rest off - a compliance screen listing twenty frameworks nobody has asked you about makes the two that matter harder to see.

31
00:06:34.360 --> 00:06:48.770
That relationship is worth holding onto. Compliance here is not a separate assessment somebody performs. It is the same continuous evaluation, grouped by the framework you are being asked about.

32
00:06:49.368 --> 00:07:10.330
Cloud posture reaches NxSAM from more than one platform, and the module has a second set of screens for the second one. Prisma feeds the four you have just seen. Cortex CSPM and SentinelOne feed these five, under CSPM - Assets, Issues, Cases, Rules and Policies.

33
00:07:10.957 --> 00:07:27.048
The two sets do not merge. A resource both platforms see appears once under each, and the two screens called Policies are different lists with the same name - so the first thing to establish on any question is which family it is about.

34
00:07:27.660 --> 00:07:45.958
Assets is the inventory again, with one difference that matters: the two count columns are doors. Issues shows what is open against the resource by severity, Cases shows the work it is part of, and the arrow on either opens that screen already filtered to this asset.

35
00:07:46.520 --> 00:08:07.050
Last Observed is what tells you whether a clean asset is clean. No issues and a date from last night means checked and passed. No issues and a date from three weeks ago means the platform has stopped seeing it - and an empty issue count on a resource nobody is looking at is not evidence of anything.

36
00:08:07.640 --> 00:08:10.745
The asset name opens its details.

37
00:08:11.320 --> 00:08:31.419
The provider and its own identifier for the resource, the realm and region it lives in, the type as a category, a class and a name, when it was first and last observed - and its issues and cases broken down by severity. Everything the platform knows about this one resource, without leaving the list.

38
00:08:32.000 --> 00:08:35.946
Close it, and go to what those counts were counting.

39
00:08:36.520 --> 00:08:52.829
Issues are the findings. One row is one rule failing against one or more resources - what was found, how severe the rule rates it, the area of posture it belongs to, how the platform detected it, and where it is in its lifecycle.

40
00:08:53.400 --> 00:09:17.053
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 thirty-one assets is almost always a template or a pipeline producing the same misconfiguration again and again - fix the source and all thirty-one clear at once, fix them one at a time and nothing clears durably.

41
00:09:17.660 --> 00:09:35.734
Case ID and Rule ID are the other two doors. The case is the piece of work this issue has been grouped into; the rule is the check that raised it. Either opens the other screen on exactly that record, so you can start from whichever you were asked about.

42
00:09:36.340 --> 00:09:42.841
Severity and Status are the quick filters. More Filters opens the rest.

43
00:09:43.460 --> 00:10:01.690
Domain, category and detection method - the dimensions that separate a configuration finding from an identity one, and a scan result from an attack-path analysis. Reset Filters clears everything at once, and Export downloads whatever the list currently shows.

44
00:10:02.280 --> 00:10:04.073
Cases next.

45
00:10:04.640 --> 00:10:22.386
A case collects related issues into one thing to work on, and it carries a severity and a status of its own. Fixing a case is fixing every issue in it - and the Issues column opens them, split by severity, the same way it did from an asset.

46
00:10:22.985 --> 00:10:40.156
One thing to read carefully: a case's severity is set by the platform, not summed from its issues. A case rated High can hold a Critical issue. When the two disagree, the case rating is the one the platform intends you to act on.

47
00:10:40.724 --> 00:10:49.206
Rules are the checks themselves. Every issue was raised by one of these, and the Issues Count says how many.

48
00:10:49.806 --> 00:11:11.392
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 - so 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.

49
00:11:11.988 --> 00:11:32.631
And Policies are named groups of rules, as configured in the platform. Mode and Rule Matching are the platform's own settings, shown here so you can read them without opening it - NxSAM does not change them. A policy explains why a rule that exists is, or is not, producing issues.

50
00:11:33.203 --> 00:11:44.875
Nine screens, one module, and nothing on any of them writes back to a cloud account. The sideways links are a way of reading the evidence, not acting on it.

51
00:11:45.465 --> 00:11:49.460
Two habits make this module useful rather than noisy.

52
00:11:50.059 --> 00:12:05.381
The first is to treat a recurring alert as a process problem rather than a configuration one. If the same bucket becomes public every few weeks, fixing the bucket again is not the fix - something is recreating it that way.

53
00:12:05.968 --> 00:12:23.185
The second is to read the inventory when it changes, not only the alerts. A resource appearing that nobody expected is worth attention even when it violates no policy at all, because it means something was created outside whatever process you thought you had.

54
00:12:23.779 --> 00:12:41.118
That is Cloud Security Posture. An inventory of what you actually run, alerts and issues that state what is misconfigured right now, rules and policies that define what right looks like, and compliance that is the same evaluation grouped by framework.

55
00:12:41.680 --> 00:12:53.738
The mental shift this module asks for is from findings to posture. Nothing here is waiting to be patched - it is either configured correctly at this moment, or it is not.