WEBVTT

1
00:00:00.631 --> 00:00:16.983
Welcome to NxSAM training. This module is different from the others. It does not cover a screen you will work in - it covers the ideas the rest of the platform is built on, and which every other module assumes you already have.

2
00:00:17.579 --> 00:00:29.853
If you watch one of these first, watch this one. Most confusion with this product is not about where a button is. It is about what the product thinks a finding is.

3
00:00:30.466 --> 00:00:41.636
Everything starts with an asset. An asset is anything that can carry a weakness - an application, a host, an A P I, a container image.

4
00:00:41.919 --> 00:00:57.793
Audits are run against assets. Findings belong to assets. Reporting groups by them. So an inventory that is wrong makes everything built on top of it wrong too, quietly and everywhere at once.

5
00:00:58.380 --> 00:01:06.936
Assets sit in a hierarchy of three tiers, and almost every screen in the product filters, groups or reports along it.

6
00:01:07.523 --> 00:01:24.791
By default they are organisation, business unit and project, with applications and hosts underneath. But the names are configurable, per user - so what this video calls a project your deployment may call an application, a system, or a service.

7
00:01:25.363 --> 00:01:40.133
That is deliberate rather than untidy. The product is used by organisations with genuinely different structures, and forcing everyone into one vocabulary would make every report read slightly wrong to somebody.

8
00:01:40.743 --> 00:01:52.636
So when a training video and your screen disagree about a word, the structure is the same and the label has been set locally. The tiers are what matter, not the names.

9
00:01:53.205 --> 00:01:58.089
Then the distinction that causes the most confusion in this platform.

10
00:01:58.708 --> 00:02:10.695
The thing being protected persists. An audit is one assessment of it, at one point in time. Applications persist; audits accumulate against them.

11
00:02:11.307 --> 00:02:29.726
Which is why the same application shows several audits, and why a finding always belongs to a specific one. A finding does not just record what is wrong - it records when and how it was discovered, which is what makes last quarter's result comparable to this week's.

12
00:02:30.359 --> 00:02:38.501
Now the single most useful thing in this module, because it explains a question that reaches support more than any other.

13
00:02:39.097 --> 00:02:50.055
Findings do not reach dashboards the moment they exist. They reach them once the audit they belong to has passed a certain point in its life - approval.

14
00:02:50.672 --> 00:03:08.493
So an auditor can be looking at findings inside an audit while every dashboard shows nothing, and neither of them is broken. That is not a bug and it is not a delay in processing. It is the product declining to report a result nobody has stood behind yet.

15
00:03:09.085 --> 00:03:20.473
If somebody tells you the dashboard is missing findings they can plainly see, check the audit's status before you check anything else. It is very nearly always this.

16
00:03:21.075 --> 00:03:28.333
There is a second idea working alongside that gate, and it has its own word in this product: considered.

17
00:03:28.941 --> 00:03:41.167
When the same thing is assessed more than once, only one of those assessments describes the current position. That one is the considered audit, and it is what the counts are built from.

18
00:03:41.790 --> 00:03:58.432
The others are not deleted. They remain, and you can read them - they simply are not what "how many open findings do we have" is answered from, because answering that from every assessment ever run would count the same problem repeatedly.

19
00:03:59.029 --> 00:04:12.696
Which is why a newer audit replaces an older one rather than adding to it, and why completing an assessment can make a number go down. Nothing was fixed; a more recent measurement simply took over.

20
00:04:13.309 --> 00:04:25.970
You will see the word on findings searches and on audit lists. It is the answer to a question that otherwise looks like a bug: why does this finding appear in a search but not in a total.

21
00:04:26.590 --> 00:04:31.404
Two words that sound similar and describe entirely different things.

22
00:04:32.014 --> 00:04:43.759
Severity describes a finding: how serious that particular weakness is. Criticality describes an asset: how much damage its compromise would cause.

23
00:04:44.341 --> 00:05:04.031
A low severity finding on a critical asset, and a critical finding on a low asset, are very different situations. The platform records both rather than collapsing them into one number, because collapsing them is how a payment system and an internal wiki end up looking equally urgent.

24
00:05:04.633 --> 00:05:10.449
The statuses a finding moves through are configurable, and it is worth knowing where they live.

25
00:05:11.056 --> 00:05:24.555
The audit finding status master defines the states a finding can be in, and the priority status master defines the priorities that can be assigned. Both are your organisation's, not ours.

26
00:05:25.159 --> 00:05:41.082
That has a consequence worth remembering when you compare two deployments, or read documentation written elsewhere. Each module also carries its own status set, so a list of statuses learned in one module does not transfer to another.

27
00:05:41.692 --> 00:05:49.480
So a status list is a local fact rather than a universal one, and it is always worth checking rather than assuming.

28
00:05:50.098 --> 00:05:56.446
One more pair that is easy to conflate, and appears on almost every findings screen.

29
00:05:57.066 --> 00:06:11.815
Validation asks whether the finding is genuine. Status asks where it has reached in its life. A finding can be validated and still open, or closed without ever having been validated at all.

30
00:06:12.438 --> 00:06:27.689
Keeping them apart is what lets the platform distinguish somebody says this is fixed from somebody checked. In a compliance or audit context those are not the same claim, and the difference is frequently the whole point of the exercise.

31
00:06:28.305 --> 00:06:33.859
And finally, the habit that will save you the most time across every module.

32
00:06:34.451 --> 00:06:52.583
Almost nothing in this platform happens instantly. Scan results are parsed and merged. Reports are generated. Exports are prepared. Bulk changes are applied. All of it runs in the background, through a queue.

33
00:06:53.181 --> 00:07:06.607
Which means there is a failure mode common to every module. A file that failed to parse and a scan that genuinely found nothing produce exactly the same thing on a dashboard: no new findings.

34
00:07:07.236 --> 00:07:20.279
The queue is the only place that tells those two apart. So when something has not appeared, read the queue before you conclude the data is wrong - it is the first place to look, not the last.

35
00:07:20.840 --> 00:07:27.617
That failure has a bigger cousin, and it is the single most useful idea in this entire programme.

36
00:07:28.222 --> 00:07:41.939
In every module, something that came back clean and something that was never successfully examined look identical in a total. Both contribute nothing. Both leave the number looking good.

37
00:07:42.551 --> 00:08:00.949
Each module gives you a way to tell them apart, and it is almost always a column people skip. A last-scanned date. A no-data or failed asset count. An error state beside passed and failed. A sync that started and never completed.

38
00:08:01.544 --> 00:08:16.026
So build the habit of asking, of any good number, whether it is good because things are healthy or because they were not looked at. That question has found more real problems than any dashboard in this product.

39
00:08:16.620 --> 00:08:22.077
One last idea, because it explains a whole family of surprises.

40
00:08:22.676 --> 00:08:38.189
When results arrive again - a re-scan, a re-upload, a scheduled sync - the platform has to decide whether each one is a finding it already holds or a new one. It does that by matching on a defined set of fields.

41
00:08:38.775 --> 00:08:57.578
That set is configurable, and it is the quiet cause of two opposite problems. Match on too little and separate findings merge, so fixing one appears to fix them all. Match on too much and nothing ever matches itself, so every scan reports everything as new.

42
00:08:58.176 --> 00:09:09.777
The second is the harder one to spot, because it looks like a busy estate rather than a broken setting: rising discovered counts, falling ages, nothing ever overdue.

43
00:09:10.398 --> 00:09:25.266
You do not need to configure this yourself. You do need to know it exists, because when counts behave strangely across a whole tool, matching is where to look before anybody starts examining individual findings.

44
00:09:25.841 --> 00:09:48.100
That is how NxSAM works. Assets everything hangs off. Audits that accumulate against things that persist. An approval gate that decides what dashboards count. Severity and criticality kept apart, validation and status kept apart, and statuses that are yours rather than ours.

45
00:09:48.685 --> 00:10:03.814
Carry three habits into the other modules and most of your questions will answer themselves. When a dashboard disagrees with a screen, check the audit's status. When something has not appeared at all, read the queue.

46
00:10:04.421 --> 00:10:17.271
And when a number looks good, ask whether it is good because things are healthy, or because they were never measured. That third habit is the one that separates reading a dashboard from understanding it.