WEBVTT

1
00:00:00.609 --> 00:00:11.657
Welcome to NxSAM training. This module covers Policy Compliance, and it answers a different question from every other security module in the product.

2
00:00:12.278 --> 00:00:27.502
The vulnerability modules ask what is broken. Policy Compliance asks whether a host is configured the way your standard says it should be - password rules, logging, open services, permissions, encryption settings.

3
00:00:28.103 --> 00:00:42.177
Nothing here is a vulnerability in the usual sense. A host can be fully patched and still fail dozens of policy checks, and those failures are very often exactly what an auditor asks to see.

4
00:00:42.796 --> 00:00:51.693
Four words carry this module, and they nest inside one another. Get them straight and the rest of the module follows.

5
00:00:52.286 --> 00:01:05.450
A control is a single check. Password minimum length. Whether remote root login is permitted. Each carries its own severity and the tool that evaluates it.

6
00:01:06.046 --> 00:01:25.639
The Controls list shows control details, severity, tool, how many policies include it, and who created it. That policies count is the column worth reading: a control used by more than one policy is one worth getting right, because a change to it moves every one of them.

7
00:01:26.235 --> 00:01:34.768
A policy is a named set of controls: your Linux server baseline, your database standard, a regulator's benchmark.

8
00:01:35.383 --> 00:01:52.914
Each carries its title and identifier, the tool and its identifier there, the organisation, the category it belongs to, and who created it. The row menu maps a policy to a category, or opens View Controls - what is actually inside it.

9
00:01:53.485 --> 00:02:00.219
Categories group policies. And here we reach the first rule that surprises people.

10
00:02:00.834 --> 00:02:11.932
An audit in this module is category-wise. You do not assemble an arbitrary set of policies and run them - an audit belongs to exactly one category.

11
00:02:12.538 --> 00:02:28.580
That is not a limitation someone added to keep the interface simple. The category is the axis the whole module is built on: it is the same field the audit uses to identify itself, and everything downstream is scoped by it.

12
00:02:29.184 --> 00:02:44.603
Which means the answer to why can I not mix categories in one audit is that a posture would then have no single category to belong to, and the rule that keeps postures unambiguous would have nothing to hold on to. That rule is next.

13
00:02:45.222 --> 00:03:05.425
For any given host, any given policy, and any given category, exactly one audit is the authoritative one. One policy per I P per category. And it is not a guideline in a document - the platform enforces it, which means it cannot be worked around and it cannot drift.

14
00:03:06.007 --> 00:03:20.750
Here is why it exists, and this is the part worth carrying away. A posture is a statement about how a host is configured right now. It is not a log of every time that host was ever measured.

15
00:03:21.336 --> 00:03:40.716
If two audits both counted for the same host and the same policy, the same control failure would appear twice, and the question is this host compliant would have no answer. That one rule is what makes current posture a well-defined thing at all, and one consequence follows immediately from it.

16
00:03:41.281 --> 00:03:54.514
Re-running a category's audit against a host supersedes the previous one rather than adding to it. That is why compliance figures change when an audit completes, instead of accumulating forever.

17
00:03:55.081 --> 00:04:08.366
Each audit also records what it displaced, so it is always possible to say which earlier measurement a current posture replaced. The history is kept; it simply is not what gets counted.

18
00:04:08.980 --> 00:04:19.479
There is a practical warning attached to this, and it comes from the product's own source. Reverting or deleting a completed audit is not a cheap undo.

19
00:04:20.044 --> 00:04:37.646
The authoritative pointer for each affected host is a single record that was overwritten, so undoing it means recomputing that pointer from every completed audit. It is deliberate, it is expensive, and it is not something to do casually on a large estate.

20
00:04:38.247 --> 00:04:42.216
With the rules in place, the working shape is familiar.

21
00:04:42.838 --> 00:04:55.159
Request Info, Audit Details, Vulnerabilities, Audit Properties, Audit Status - and Data Process, which this module shares with Network V A for exactly the same reason.

22
00:04:55.727 --> 00:05:15.085
A compliance scan does not arrive as results. It arrives as a file that must be parsed, matched to hosts, and merged with what is already recorded. Data Process says where that has reached, and it is the first place to look when a completed scan appears to have produced nothing.

23
00:05:15.693 --> 00:05:35.384
The row menu is where an audit's work happens: View Postures opens the results, View Status History and View Audit Chain show how it got here, and Manage Audit Scope changes what is in it. One more, Export I Ps, appears only on an audit the platform runs for itself.

24
00:05:35.982 --> 00:05:42.737
Before the results, one fact about them that changes how you read every number in this module.

25
00:05:43.321 --> 00:05:59.727
A control result is not simply pass or fail. There is a third state, Error, and it means the check could not be evaluated at all - the scanner could not authenticate, the file was not where it expected, the setting could not be read.

26
00:06:00.331 --> 00:06:14.884
That is not a pass, and the platform is careful about the difference. A passed control gets no service-level clock and no risk score. An Error gets both, exactly as a failure does.

27
00:06:15.519 --> 00:06:30.001
Which is the right treatment, because an unmeasurable control is an unanswered question rather than a satisfied one. If you only count failures, a host where authentication broke looks perfectly compliant.

28
00:06:30.604 --> 00:06:42.449
So when a compliance score improves sharply, check whether failures became passes or whether they became errors. Those look similar in a total and mean opposite things.

29
00:06:43.045 --> 00:06:46.390
The postures are where all of this arrives.

30
00:06:46.986 --> 00:06:59.764
Before the table, read the band across the top, because it answers a question the table cannot. The table tells you what was found. This tells you what was looked at.

31
00:07:00.369 --> 00:07:17.276
Total assets is the scope. Vulnerable assets are the ones with failures. Assets with no findings came back clean. And then the three that matter most: no-data assets, excluded assets, and failed assets.

32
00:07:17.878 --> 00:07:33.056
A no-data asset was in scope and produced nothing. A failed asset could not be assessed at all. Neither is compliant - but neither appears anywhere in the counts below, because there is nothing to count.

33
00:07:33.670 --> 00:07:48.921
That is the single most useful thing on this screen. A host that passed everything and a host the scanner never reached look exactly the same in a compliance percentage. Here, and only here, they are separated.

34
00:07:49.527 --> 00:08:01.211
So read this band first and the table second. If eleven hosts returned no data, your compliance figure describes the rest of the estate and quietly omits them.

35
00:08:01.838 --> 00:08:16.899
Excluded assets are different again - those you deliberately took out of scope, and the count carries a link to see which. Worth checking occasionally, because an exclusion set once tends to outlive the reason for it.

36
00:08:17.488 --> 00:08:31.152
Now the table. One row per host and policy pair: the host and its address, the policy and its identifier, the tool that measured it, a total, and then a column for each severity.

37
00:08:31.727 --> 00:08:45.825
And each severity cell is not a single number. It is a bar with the total above it, split into passed, failed and error underneath - the same three states, per severity, per host, at a glance.

38
00:08:46.410 --> 00:09:02.213
Which is why the legend above the table names all four: total, failed, passed and error. Scan the bars rather than the numbers, and a host carrying an unusual amount of amber is one where the assessment itself is not working.

39
00:09:02.805 --> 00:09:17.914
A posture is identified by the host and the control together - and, for some categories, by the instance as well. That third part is a choice your administrator makes per category, and it changes what you are counting.

40
00:09:18.504 --> 00:09:31.216
Take a permissions control that fails on forty files. With instance tracking off, that is one failing control. With it on, it is forty findings, one per file.

41
00:09:31.807 --> 00:09:50.347
Neither is wrong. Off gives you a clean list of what is misconfigured; on gives you a work list of what has to be changed. Worth knowing which way yours is set before comparing counts, because the same estate produces very different totals under the two settings.

42
00:09:50.930 --> 00:10:02.988
The row action opens the individual control results for that host - every control in that policy, what was expected, what was found, and which of the three states it ended in.

43
00:10:03.597 --> 00:10:09.830
Four controls sit along the top of the screen, and each does something the others do not.

44
00:10:10.420 --> 00:10:19.453
Upload P C Report is how a scan arrives by hand - you bring the tool's export to the platform, rather than the platform fetching it for you.

45
00:10:20.071 --> 00:10:26.849
On an audit that is still in progress, that button offers a second way in - and the second is new.

46
00:10:27.466 --> 00:10:29.231
Upload Report.

47
00:10:29.803 --> 00:10:37.518
Report Type is the scanner - Qualys or Nessus - or Manual, for a control set a person assessed by hand.

48
00:10:38.107 --> 00:10:56.262
Workflow is where the new option lives. Upload takes a report file, as it always did. Scan asks the scanner to run the benchmark and bring the result back itself. And with a Tenable connection, Automatic Scan re-runs it on a schedule.

49
00:10:56.871 --> 00:11:15.717
Choosing Scan unfolds what the scanner needs: a new scan or an existing one by its result or ID, the benchmark to run, the scan zone it runs from and the repository its results land in, whether to follow hosts across address changes, and the credentials for an authenticated scan.

50
00:11:16.293 --> 00:11:34.808
Schedule Scan is the last choice - now, or at a chosen date and time. A scheduled scan then appears in the queue like any upload, and can be cancelled while it is running. One difference from a file: a scan needs a target, so an IP is mandatory for it.

51
00:11:35.433 --> 00:11:39.237
Cancel that, and back to the completed audit.

52
00:11:39.818 --> 00:11:43.019
Next to it, Assessment Reports.

53
00:11:43.626 --> 00:11:53.474
Assessment Reports is where produced documents are requested: a P D F of this audit, generated on demand rather than kept permanently.

54
00:11:54.054 --> 00:12:02.411
And note the strip just below it, showing recent ones with their state and a download, including any still being generated.

55
00:12:03.005 --> 00:12:24.113
Update asset status records a decision about a host - that a failure is accepted, or remediated, or genuinely not applicable to it. A control that does not apply is not the same as a control that passed. On an audit the platform runs for itself, Configure Force Sync sits here instead.

56
00:12:24.705 --> 00:12:43.768
Raise Confirmatory Audit asks for the check to be run again to prove a fix, rather than someone marking it done - evidence rather than assertion. It is also why the button disappears once a confirmatory audit already exists: one re-check per claim, so the trail stays readable.

57
00:12:44.375 --> 00:12:57.969
And the audit chain link beside the audit name shows this audit's relationship to the ones before it - which, given that a new audit supersedes its predecessor, is how you find the measurement that yours replaced.

58
00:12:58.562 --> 00:13:09.349
Because everything here arrives by ingestion, the module gives you a window onto that process directly - and it answers the question this module generates most.

59
00:13:09.945 --> 00:13:21.574
Each row is one upload: its queue identifier, the policy, the report type, the upload type, the workflow it followed, its status, who initiated it and when.

60
00:13:22.160 --> 00:13:33.836
Workflow is the quiet one. It says how the result arrived, and when results are wrong that is the first thing you want to know - before you look at the numbers themselves.

61
00:13:34.429 --> 00:13:47.875
Upload type is the consequential one, and it is the same set of choices Network V A offers, because the ingestion machinery is shared. One of them behaves very differently from the rest.

62
00:13:48.449 --> 00:14:04.108
Merge is the normal choice: the new results are matched against what is already recorded and combined with it. The closure types close what the new report no longer reports. Ignore leaves existing results alone.

63
00:14:04.704 --> 00:14:23.842
Override does something else entirely. It deletes the audit's existing postures before loading, and unlinks the policy from the assets in scope - a replacement, not a stronger merge. Use it when the previous upload was simply wrong, never as a routine re-upload.

64
00:14:24.448 --> 00:14:42.245
Each row carries its own actions. Queue File is what was actually uploaded. On an upload the platform synchronises for itself, two more appear beside it: Queue Summary, what the system made of the file, and Log File, what went wrong.

65
00:14:42.875 --> 00:14:57.306
Queue File is the one to reach for when a scan has clearly landed but the numbers look incomplete, and the reason is the same failure mode as in Network V A. Read what the platform actually received rather than what you think you sent.

66
00:14:57.903 --> 00:15:07.564
A compliance result that silently failed to parse and a host that genuinely has no findings look identical on a dashboard: nothing new.

67
00:15:08.198 --> 00:15:17.953
The queue is the only place that tells those two apart, and on a failed upload it says why - which makes it the first place to look rather than the last.

68
00:15:18.542 --> 00:15:24.626
There is one more thing the queue accounts for, and it is a feature most people never find.

69
00:15:25.218 --> 00:15:42.052
A policy can carry exclusion patterns - instance strings you have decided are not worth recording. Temporary paths, build directories, a naming pattern that appears on every host and tells you nothing. Wildcards are supported.

70
00:15:42.676 --> 00:15:52.094
That is genuinely useful on a noisy control, where one real problem arrives buried under two thousand instances that are all the same fact.

71
00:15:52.684 --> 00:16:07.550
But exclusion is exactly the kind of setting that becomes invisible and then becomes wrong. So the platform does not drop those rows quietly. Every excluded row is written to a file you can download.

72
00:16:08.140 --> 00:16:23.438
And that file names the rule as well as the row: the row number, the pattern that matched, the policy, the host, the control and its name, and the instance itself. So you can always answer why something is not in the results.

73
00:16:24.005 --> 00:16:38.176
There is a second reason a row can be dropped, worth knowing because it is not a rule anybody set. An instance string longer than two hundred and fifty characters is excluded too, and it appears in the same file.

74
00:16:38.793 --> 00:16:51.789
So the habit is: when a control you expect to see is missing, download that file before assuming the scan is at fault. Most of the time the answer is in it, with the reason attached.

75
00:16:52.364 --> 00:17:00.392
Finally, the three ways a posture can reach this module, because each has its own expectations about the file.

76
00:17:00.998 --> 00:17:15.771
Two are tool exports - Qualys and Nessus - and each has its own required columns and its own optional ones. The platform knows the shape of each and will tell you which required column is missing rather than half-loading the file.

77
00:17:16.363 --> 00:17:32.762
The third is a manual upload, for a control set assessed by a person rather than scanned. That matters more than it sounds: much of a real compliance standard is not machine-checkable, and it would otherwise live in a spreadsheet nobody reports from.

78
00:17:33.361 --> 00:17:43.115
The manual sheet is laid out differently - hosts run across the columns rather than down the rows, and the platform reads that layout specifically.

79
00:17:43.707 --> 00:17:58.429
And whichever source it came from, a failing control gets its due date from the same service-level configuration Network V A uses, by host and severity. There is not a separate compliance clock to maintain.

80
00:17:59.026 --> 00:18:17.853
That is Policy Compliance. Controls inside policies inside categories describe the standard. Postures are your estate measured against it. Audits with a data-process stage are how the measurements arrive. And two rules hold it together.

81
00:18:18.467 --> 00:18:34.368
An audit is category-wise because the category is the axis everything is scoped by. And exactly one audit is authoritative per host, per policy, per category, because that is what makes current posture answerable at all.

82
00:18:34.984 --> 00:18:49.512
When compliance figures look wrong, work backwards along that chain: the postures, then the audit's data process, then the upload queue's log file. The answer is in one of those three almost every time.