WEBVTT

1
00:00:00.637 --> 00:00:10.221
Welcome to NxSAM training. This module covers Integrations: connecting the scanners and tools that actually produce your findings.

2
00:00:10.806 --> 00:00:27.618
It is the least glamorous module in the product and the one where a wrong setting does the most quiet damage. Everything downstream - ages, service levels, counts, whether a finding is even open - is decided by choices made on these screens.

3
00:00:28.208 --> 00:00:39.357
So this is not a tour of connection forms. We will go through the settings that change what your numbers mean, and say exactly what each one does when it is wrong.

4
00:00:39.924 --> 00:00:50.162
First, the shape of the thing. Integrations here come in three kinds, and knowing which kind you are looking at tells you what to expect from the screen.

5
00:00:50.796 --> 00:01:06.221
Connected tools, where the platform reaches out and pulls. Qualys, Tenable, Prisma Cloud, Cortex, Checkmarx, Fortify. These have credentials, a schedule, and a sync history you can read.

6
00:01:06.816 --> 00:01:23.507
Mapped tools, which are connected tools with an extra problem: the tool organises work into projects, and the platform organises it into assets. Somebody has to say which is which. That mapping table is most of the screen.

7
00:01:24.083 --> 00:01:42.813
And report-read tools - Acunetix, Gitleaks, Snyk, J Frog X-ray, Netsparker, Dependency Tracker. You do not connect to these at all. You upload their reports, and the configuration here tells the platform how to read the file when you do.

8
00:01:43.439 --> 00:01:59.313
That last kind surprises people. There is no connection to test and no sync to watch, so the screen looks inert. It is not - it is the ruleset that every future upload of that tool's reports will be interpreted by.

9
00:01:59.911 --> 00:02:02.468
Take a connected one first.

10
00:02:03.050 --> 00:02:11.007
It opens on the System tab, which we will come back to. The connection itself lives on the Scan tab.

11
00:02:11.601 --> 00:02:26.323
That tab holds three panels and they answer three different questions. The first is Configuration: the tool's address, the username, the password held hidden, and whether the connection goes through a proxy server.

12
00:02:26.933 --> 00:02:42.423
The proxy setting is worth flagging now, because it is the commonest reason a correct-looking configuration never connects. On a segmented network the platform often cannot reach the scanner directly, and nothing on the screen says so.

13
00:02:43.014 --> 00:03:00.472
The second panel is the master vulnerability sync - its status, when it was last initiated and when it last completed. That sync pulls the tool's own catalogue of known weaknesses, which is what gives an incoming finding its description and its guidance.

14
00:03:01.076 --> 00:03:16.873
Read those two timestamps together rather than the status alone. An initiated time with no matching completion is a sync that started and never came back - which is a different problem from one that failed, and a much easier one to miss.

15
00:03:17.473 --> 00:03:32.601
The third panel is scan settings: the report template to request, and the option profile to use - separately for vulnerability assessment and for policy compliance, because those are different scans with different settings at the tool end.

16
00:03:33.202 --> 00:03:38.709
Below that sits a table that solves a problem large estates always have.

17
00:03:38.981 --> 00:03:48.257
Its columns are the scanner, the organisation, the business unit, whether it is configured, and then an asset property name and value.

18
00:03:48.855 --> 00:04:06.456
Those last two are the mechanism. Rather than listing which hosts a scanner covers, you name a property your assets already carry - a site, a region, a data centre - and a value, and everything carrying that value is that scanner's territory.

19
00:04:07.043 --> 00:04:23.109
Which means the routing keeps working as the estate changes. A new host tagged with the right site is covered the moment it is created, without anybody editing this screen. The Configured column tells you which rows are actually live.

20
00:04:23.711 --> 00:04:38.598
And a sync history sits at the foot of the tab: the sync type, its status, when it was initiated and when it completed. Same reading habit - an initiated time with no completion is the row that deserves attention.

21
00:04:39.180 --> 00:04:54.095
Cloud posture has a third source. Cortex CSPM connects with the tenant's address, an API key ID and the key itself, with an optional proxy - and Test Connection checks them before anything is saved.

22
00:04:54.700 --> 00:05:13.814
It then has two sync actions, and the order matters. Master Sync brings the reference data - the rules and the policies. Sync brings the assets, issues and cases against them. A data sync run before the master sync has nothing to attach its issues to.

23
00:05:14.400 --> 00:05:40.067
Both report a status, the kind of run, and when it was initiated, processed and completed. Initiated without completed is a sync still running, or one that failed - read the status before concluding that data is missing. And remember which screens it feeds: the CSPM family, not the Prisma one. Connecting one does not populate the other.

24
00:05:40.660 --> 00:05:45.302
Back on Qualys, one tab deserves a chapter of its own.

25
00:05:45.880 --> 00:05:50.857
Back on the System tab, which is where the real damage gets done.

26
00:05:51.474 --> 00:06:05.090
A tool's report is a file with columns, and the platform needs to know which of those columns carries each thing it cares about. Two of them matter more than the rest: Discovered On, and Last Observed.

27
00:06:05.693 --> 00:06:20.560
Discovered On sets the opened date of a finding. Last Observed sets the date it was most recently seen. Between them they decide a finding's age, its service level, and whether it appears overdue.

28
00:06:21.178 --> 00:06:37.796
And here is the rule the product states on this screen, which everybody should know before they configure anything. The header is not mandatory. If the value is missing, or invalid, the platform uses the report's processing date instead.

29
00:06:38.389 --> 00:07:01.877
Sit with what that means. Leave this unmapped, and every finding in the file is recorded as discovered on the day you uploaded it. Nothing errors, nothing looks wrong: ages reset, service-level clocks restart, and your overdue count drops to nothing overnight. It reads as excellent progress and it is a mapping mistake.

30
00:07:02.451 --> 00:07:15.061
There is a matching format setting, because a date can be written a dozen ways and the platform will not guess. The information icon beside it lists every supported pattern with an example.

31
00:07:15.667 --> 00:07:30.726
One more stated rule: the date should be past or current. A report carrying a future date is treated as invalid, and invalid falls back to the processing date - the same silent outcome as leaving it blank.

32
00:07:31.331 --> 00:07:37.291
The System tab holds one more setting, and it is the most consequential in the module.

33
00:07:37.889 --> 00:07:52.851
You can select up to five columns to form a custom key for vulnerability matching, with a separator character between them. That key is how the platform decides whether a finding in today's report is the one it already has.

34
00:07:53.449 --> 00:08:11.842
Which makes this the setting behind the whole re-upload behaviour. A finding whose key matches an existing one updates it. A finding whose key matches nothing is new. And a finding the platform holds that the report no longer carries is a candidate for closing.

35
00:08:12.442 --> 00:08:29.710
So the key can be wrong in two directions, and they fail differently. Too narrow - say, the weakness alone without the host - and genuinely different findings collapse into one. You fix a thing on one server and it disappears from all of them.

36
00:08:30.318 --> 00:08:51.056
Too wide - including a port number or a scan identifier that changes between scans - and the same finding never matches itself. Every scan creates a new one, the old one closes, and every finding stays a few days old. Which looks like a busy estate rather than a broken setting.

37
00:08:51.643 --> 00:09:06.991
The habit worth having: choose the smallest set of columns that genuinely identifies a finding - the host and the weakness, usually - and change it only with a good reason, because changing it re-partitions everything you already hold.

38
00:09:07.575 --> 00:09:21.842
Tenable also shows a shape you will meet elsewhere. One integration, several tabs, because the vendor sells more than one product and the platform connects to each of them separately with its own settings.

39
00:09:22.442 --> 00:09:25.814
Then the mapping people expect: risk.

40
00:09:26.087 --> 00:09:41.985
A small table with the tool's own risk value on one side and the platform's rating on the other. Every incoming finding's severity is set by that table, and there are separate ones for vulnerability findings and for compliance results.

41
00:09:42.599 --> 00:09:59.269
It looks like a formality and it is not. Tools disagree with each other about what High means, and most organisations have a house view that differs from both. This table is where that view gets applied, once, to everything.

42
00:09:59.863 --> 00:10:15.592
Which makes it worth agreeing deliberately, and reviewing when it changes. Adjusting this table does not just change new findings - it changes what your existing counts mean, and anyone comparing to an older report needs telling.

43
00:10:16.167 --> 00:10:19.824
Now the second kind - a mapped integration.

44
00:10:20.431 --> 00:10:34.913
The tool organises work into projects. The platform organises it into assets. Neither knows about the other's names, so somebody has to join the two - and that is what the Sync tab is for.

45
00:10:35.500 --> 00:10:42.116
Two panels sit at the top, and they are genuinely different syncs rather than one thing described twice.

46
00:10:42.718 --> 00:10:56.361
Master sync pulls the tool's catalogue - the definitions of the weakness types it can report, with their descriptions and guidance. That is what turns an incoming finding from a code into something readable.

47
00:10:56.996 --> 00:11:10.110
Vulnerability sync pulls the findings themselves, for the projects that are mapped. Each panel records its own last sync type, status, and the times it was initiated and processed.

48
00:11:10.709 --> 00:11:26.818
Read those two times together rather than the status alone. An initiated time with no matching processed time is a sync that started and did not come back - which is a different failure from one that reported an error, and much easier to miss.

49
00:11:27.414 --> 00:11:42.397
Refresh, beside each, re-reads what this page is showing. It does not go and fetch anything from the tool - so if a status looks stale, refresh tells you whether the page is behind or the sync genuinely is.

50
00:11:42.977 --> 00:11:56.979
The vulnerability panel also carries a triage re-sync rule, stated plainly: it applies only above a project-count threshold, and re-runs on an interval in days. Both are yours to set.

51
00:11:57.570 --> 00:12:12.437
That threshold exists because re-checking triage decisions across a large estate is expensive. Below it the work is small enough to do every time; above it, the interval keeps it from running constantly.

52
00:12:13.032 --> 00:12:17.243
Below them is the mapping table, one row per project.

53
00:12:17.865 --> 00:12:36.379
Its columns: a serial number, the original project details, the current project details, the asset it maps to, its mapping status, its sync status, and its last sync time. Where more than one account is configured, the account appears as a column too.

54
00:12:36.970 --> 00:12:52.918
Original versus current project details is the pair worth understanding. A project renamed or moved at the tool end keeps its original identity here, so the mapping survives the rename rather than quietly becoming a second unmapped project.

55
00:12:53.483 --> 00:13:08.639
Mapping Status is the column to scan first. An unmapped project is one whose findings have nowhere to go - the sync succeeds, the results arrive, and nothing appears against any asset because no asset was named.

56
00:13:09.230 --> 00:13:19.560
That is the single commonest support question this module produces, and it is visible right here as a status rather than requiring any investigation at all.

57
00:13:20.182 --> 00:13:32.872
Sync Status and Last Sync Time then tell you whether that project is still being measured. A mapped project with a sync time from months ago is contributing stale findings to a current figure.

58
00:13:33.448 --> 00:13:38.740
Three controls sit above the table, and each solves a different problem.

59
00:13:39.337 --> 00:13:55.099
Force Sync re-pulls projects you choose rather than waiting for the schedule and rather than only taking what changed. Reach for it when you believe the platform's copy of a project is wrong - not as a routine, because it is the expensive path.

60
00:13:55.687 --> 00:14:06.643
A row already marked for force sync carries a marker of its own, so you can see at a glance which projects are being re-pulled in full every time rather than incrementally.

61
00:14:07.252 --> 00:14:25.025
Export and Import are for the mapping itself, and they are what make this workable at scale. On an estate with hundreds of projects you export the mapping, complete it in a spreadsheet alongside the people who know which project belongs to which application, and import it back.

62
00:14:25.631 --> 00:14:36.993
That is a far better use of everyone's time than mapping in the interface one row at a time - and it leaves you with a file somebody can review, which a screenful of dropdowns does not.

63
00:14:37.586 --> 00:14:53.319
Add Account exists because one tool often serves several tenants or business units. Configure more than one and the account becomes a column of its own, so two projects with the same name from different accounts stay distinguishable.

64
00:14:53.889 --> 00:15:06.971
And the two filters above the table - mapping type and sync status - are how you work the list rather than read it. Filter to unmapped, and you have your entire outstanding task in one view.

65
00:15:07.595 --> 00:15:13.751
One more group of settings, and it appears on almost every integration in the product.

66
00:15:14.357 --> 00:15:26.249
Three rules on one form: approval state, false-positive state, and non-approval state. Each takes a field from the tool's report, a condition, and a value.

67
00:15:26.868 --> 00:15:43.348
Together they answer a question the platform cannot guess. Your tool has its own opinion about a finding - triaged, confirmed, dismissed, marked not-an-issue - and these rules translate that opinion into the state the finding arrives in here.

68
00:15:43.924 --> 00:15:59.728
That matters because of a distinction this product draws everywhere: whether a finding is genuine is a separate question from where it has reached. These rules set the first one, at the moment of import, for every finding in the file.

69
00:16:00.343 --> 00:16:17.179
Get them wrong in one direction and everything arrives already approved, so nobody reviews anything. Wrong in the other and legitimate findings arrive marked as false positives and drop out of your counts without a person ever having looked at them.

70
00:16:17.786 --> 00:16:31.933
So configure these against a real report from your own tool, with somebody who knows what its fields contain - not from the field names alone. It is fifteen minutes that prevents a quarter of misleading numbers.

71
00:16:32.534 --> 00:16:36.027
A word on the credentials these screens hold.

72
00:16:36.629 --> 00:16:51.400
The account you give an integration should be able to read results and nothing else. It does not need to launch scans, change scan policies, or administer the tool, unless you have specifically chosen for it to.

73
00:16:52.006 --> 00:17:09.827
That matters more here than in most places, because this is a credential that sits in a configuration and works continuously without anyone watching it. A read-only account that leaks is an information problem; an administrative one is a much larger problem.

74
00:17:10.400 --> 00:17:24.426
Use a dedicated account rather than a person's, too. Integrations outlive employment, and an integration that stops working the week somebody leaves is a failure nobody predicted but everybody could have.

75
00:17:25.038 --> 00:17:29.586
Then the part that is genuinely different from everything after it.

76
00:17:30.168 --> 00:17:43.626
A first sync pulls history - every asset the tool knows about, and every finding it is currently reporting. On an established estate that is an enormous amount of data arriving at once.

77
00:17:44.207 --> 00:17:56.962
So expect it to take time, expect the counts to jump, and expect the first look at your dashboards afterwards to be alarming. Nothing got worse - you have simply finished looking.

78
00:17:57.577 --> 00:18:11.345
Subsequent syncs are incremental and unremarkable. If a routine sync ever takes as long as the first one did, something has changed worth understanding - usually a scope change at the tool end.

79
00:18:11.959 --> 00:18:28.290
The container integration shows this as a history you can read: the sync type, the image type, the status, and the initiated and completed times. Which is exactly the evidence you want when somebody asks whether a scan actually ran.

80
00:18:28.906 --> 00:18:35.109
Once running, an integration needs watching - and the platform gives you a place to watch it.

81
00:18:35.694 --> 00:18:50.444
Task information is where the scheduled work is registered - every recurring job the platform runs for you. An integration that silently stopped is the failure mode to look for, because nothing on a dashboard says so.

82
00:18:51.051 --> 00:19:07.572
That is the recurring shape of this whole product. A sync that stopped and an estate with no new findings look identical from the outside. This list tells you what is scheduled; the sync history on each integration tells you whether it ran.

83
00:19:08.180 --> 00:19:19.182
Which gives a simple habit worth adopting: when findings stop appearing from a tool, check that the integration is still running before you conclude anything about the estate.

84
00:19:19.798 --> 00:19:39.922
That is Integrations. Three kinds of integration - connected, mapped, and report-read. Credentials scoped to reading. A first sync unlike every one after it. And a mapping table whose status column answers most of the questions this module generates.

85
00:19:40.548 --> 00:19:57.980
Three settings decide what your numbers mean. Map the discovered date, or every finding will look new. Choose the matching key carefully, because it decides what counts as the same finding. And set the state rules from a real report.

86
00:19:58.571 --> 00:20:09.408
Get those right at the start. They are the parts everyone rushes, and they quietly determine whether the figures in this platform mean what people think they mean.