WEBVTT

1
00:00:00.638 --> 00:00:13.294
Welcome to NxSAM training. This module covers Assets, and it is worth saying at the outset why it comes so early. An asset is anything that can carry a weakness.

2
00:00:13.909 --> 00:00:29.858
Everything else in the platform hangs off this inventory. Audits are run against assets, findings belong to assets, and reporting is grouped by them. If the inventory is wrong, everything built on top of it is wrong too.

3
00:00:30.470 --> 00:00:35.426
There are six kinds of asset, and the kind matters more than it looks.

4
00:00:36.008 --> 00:00:51.738
Web applications are websites and web-based systems, identified by U R L. Mobile applications are iOS and Android apps, identified by package or bundle. Thick clients are installed desktop software.

5
00:00:52.328 --> 00:01:12.092
A P I assets are service endpoints, assessed separately from the applications that consume them. Network assets are hosts, servers and devices, identified by I P or hostname. And container assets are images, identified by repository and tag.

6
00:01:12.708 --> 00:01:29.854
The type decides which security module assesses the asset and which scanners can contribute findings to it. It is set when the asset is created, and it is not something to change casually - existing findings are attached to the asset as it was classified.

7
00:01:30.448 --> 00:01:38.447
This is the web application inventory, and the other five follow the same shape, so we will read this one carefully.

8
00:01:39.074 --> 00:01:55.525
One row per application. Application Details carries the name and its U R L. Risk Score is the asset's own score, not a finding's. Project is the grouping it sits under, and Audits is how many assessments it has had.

9
00:01:56.131 --> 00:02:16.904
Then the counts. Total is every open finding on the asset, and beside it the same number split by severity: critical, high, medium, low and informational. That split is the useful part - a total of forty means nothing until you know whether it is forty informational or forty critical.

10
00:02:17.485 --> 00:02:26.182
The Actions column is where most of the work happens, and there are nine of them on this screen. They fall into four groups.

11
00:02:26.763 --> 00:02:36.782
Viewing: View Web Application opens the asset, and View Overall Details opens its full record across every audit it has been part of.

12
00:02:37.360 --> 00:02:53.237
Editing: Edit Web Application changes the asset itself. Edit Ownership changes who is responsible for it, which is the field that decides who gets chased later. And Edit Tags changes its labels.

13
00:02:53.810 --> 00:03:11.703
Documents and reports: Add or Download Document attaches evidence to the asset. Download Overall Report produces its report. And Risk Score Overview explains how the asset's score was arrived at, rather than just showing you the number.

14
00:03:12.287 --> 00:03:27.632
And finally Delete Application, which is a soft operation - the record is hidden rather than destroyed. That is why a deleted asset's name can still appear on historical findings and older reports, which surprises people.

15
00:03:28.232 --> 00:03:38.394
Add Web Application creates one directly. Above the table sits a menu of actions that work across the whole list rather than one row.

16
00:03:38.982 --> 00:04:02.320
The four Generate options produce summaries - application, detailed, issue dashboard, and wise. Update Application Tags and Update Asset Properties change many assets at once rather than row by row. And View Queues shows the background jobs those bulk actions create, which is where you go when one seems not to have happened.

17
00:04:02.934 --> 00:04:10.793
The other inventories differ only where the kind of asset demands it, which makes them quick to learn once you know this one.

18
00:04:11.375 --> 00:04:24.995
Mobile applications read almost identically to web, with their own view and edit actions and the same severity split. The identifier is the package or bundle rather than a U R L.

19
00:04:25.562 --> 00:04:32.985
Thick clients are the same shape again, for installed desktop software tracked as assets in their own right.

20
00:04:33.575 --> 00:04:37.116
A P I assets are the leanest of the six.

21
00:04:37.696 --> 00:04:55.730
A P I Collections Details, Risk Score, Project and a Description - because an endpoint carries less context than an application does. Its actions are the familiar set: view, edit, ownership, tags, report, risk score and delete.

22
00:04:56.353 --> 00:04:59.890
Network assets are the ones that differ most.

23
00:05:00.484 --> 00:05:16.238
They carry Application Count and Active Audits, because a host is shared in a way an application is not. The rows also carry a checkbox, because network work is usually done in bulk rather than one host at a time.

24
00:05:16.801 --> 00:05:34.644
Their actions reflect that. Alongside the familiar edit and delete there is Request V A Audit directly from a row, and Import Hosts above the table for bringing in many at once. Request New V A and P T Audit does the same for a selection.

25
00:05:35.267 --> 00:05:38.232
Container assets are different again.

26
00:05:38.817 --> 00:05:54.979
Registry and repository identify the image, then Org, then separate Vulnerability and Compliance figures, then Collections. Container security keeps those two figures apart because they come from different kinds of check.

27
00:05:55.561 --> 00:06:11.579
And one rule that catches everyone at least once: a tag change is a different asset. Version one point two and version one point three are two rows, not one row with a new value, because they are genuinely two different images.

28
00:06:12.164 --> 00:06:18.873
Beyond its name and identifier, every asset record carries four things that matter later.

29
00:06:19.472 --> 00:06:32.613
Ownership: who is responsible for fixing what is found on it. This drives who sees the asset and who gets chased when findings age, so it is the field most worth keeping accurate.

30
00:06:33.227 --> 00:06:52.919
Business context: organisation, business unit and project. That is used for grouping and reporting rather than for access. Environment: production, U A T, staging or development. And criticality: how much the business depends on it.

31
00:06:53.193 --> 00:07:10.938
Criticality is not severity, and confusing the two causes real mistakes. Criticality describes the asset - how much damage its compromise would cause. Severity describes a finding - how serious that particular weakness is.

32
00:07:11.214 --> 00:07:25.768
A low severity finding on a critical asset, and a critical finding on a low asset, are very different situations. That is exactly why the product records both rather than collapsing them into one number.

33
00:07:26.392 --> 00:07:32.810
An inventory is only as good as its currency, and assets reach the platform three ways.

34
00:07:33.437 --> 00:07:51.978
Created directly, one at a time, which is what the Add button does on each inventory - Add Web Application here. Imported in bulk from a spreadsheet. Or synchronised from a source of truth such as a C M D B, where that has been configured.

35
00:07:52.566 --> 00:08:00.352
Underneath the inventories sits the structure that makes them navigable, and it lives under Settings rather than under Assets.

36
00:08:00.941 --> 00:08:18.519
The grouping hierarchy has three levels. Organisation at the top, then Business Units in the middle, then Projects, which is the narrowest and the one most reports group by. Every asset sits under a project, which sits under a business unit.

37
00:08:19.081 --> 00:08:30.587
Projects is the level most reporting groups by, so it is worth keeping tidy - a project created casually for one audit tends to persist in every report afterwards.

38
00:08:31.187 --> 00:08:36.768
Asset Properties is the extension point, and the one most worth knowing about.

39
00:08:37.388 --> 00:08:57.657
Custom fields defined on assets - data classification, regulatory scope, business owner, environment - become filterable everywhere the asset appears. That includes the analytics dashboard's filter bar and the grouping list in its custom chart builder, which is where the two modules meet.

40
00:08:58.276 --> 00:09:07.357
The Asset Owner master holds the people who can be assigned as owners, which is what the ownership field on every asset draws from.

41
00:09:07.940 --> 00:09:22.158
The Network Asset Map relates hosts to the applications running on them, so a finding on an application can be traced back to the infrastructure underneath it - and a host being patched can be traced forward to what it will affect.

42
00:09:22.728 --> 00:09:33.898
Asset Sync Configuration is where a source-of-truth mapping lives: the source system's columns mapped onto the platform's asset fields, with the schedule the sync runs on.

43
00:09:34.508 --> 00:09:49.182
And the Audit Calendar Planner plans assessment coverage across a period. Each plan shows how much of it has actually been done, which is what makes a plan nobody is executing visible rather than merely filed.

44
00:09:49.769 --> 00:09:54.649
Which leaves the end of an asset's life, and one distinction to get right.

45
00:09:55.252 --> 00:10:09.592
Assets that no longer exist should be decommissioned rather than deleted. Decommissioning removes the asset from active tracking while preserving its history, so past findings and past reports remain intelligible.

46
00:10:10.183 --> 00:10:20.802
The Asset Decommissioning screen holds those requests and shows who each one is waiting on, because retiring an asset is usually an approval rather than a switch.

47
00:10:21.439 --> 00:10:35.443
That is Assets. Six kinds of asset, one inventory shape to learn, ownership that decides both responsibility and visibility, and a grouping structure that everything downstream reports against.

48
00:10:35.714 --> 00:10:52.741
If you take one thing from this module, take the first line of it. Everything else in the platform hangs off this inventory, so time spent keeping it accurate is repaid everywhere else. The next module covers Application Security.