WEBVTT 1 00:00:00.630 --> 00:00:17.126 Welcome to NxSAM training. This module covers Network Vulnerability Assessment end to end: raising the audit, uploading the report, what a second upload does to what is already there, and how to read the queue when something has not landed. 2 00:00:17.408 --> 00:00:33.594 V A is the broad, automated half of network security. A scanner sweeps the estate and reports what it recognises. The work is not the scanning - it is deciding what the results mean and keeping them honest over time. 3 00:00:34.170 --> 00:00:43.636 Everything begins with an audit. An audit is one assessment of a defined scope, and findings belong to it rather than floating free. 4 00:00:44.216 --> 00:01:05.178 The list carries grouped columns: Request Info, who asked and when it starts. Audit Details, what is being assessed. Vulnerabilities, the count so far. Audit Properties, the fields your organisation defines. Audit Status. And Data Process. 5 00:01:05.789 --> 00:01:25.265 Data Process is the column that answers most support questions in this module. A scan does not arrive as findings; it arrives as a file that has to be parsed, matched to assets, and merged with what is already recorded. That column says where the ingestion has reached. 6 00:01:25.847 --> 00:01:37.928 Request New V A Audit raises one. Everything else about an audit - who works it, what is in and out of scope, what has been found - happens from the audit's own row. 7 00:01:38.546 --> 00:01:50.218 Now a rule that explains the single most common question in this module. Findings do not roll up anywhere outside the audit until that audit is past Approved. 8 00:01:50.817 --> 00:02:05.806 So an auditor can be looking at findings inside the audit while every count outside it reads nothing, and neither of them is broken. If someone reports missing findings, check the audit's status before you check anything else. 9 00:02:06.400 --> 00:02:20.741 Two row actions here do not exist in the application modules, and each earns its place. Add More Assets extends a running audit's scope, rather than raising a second audit and splitting the results across two. 10 00:02:21.320 --> 00:02:35.615 Export Assets takes the list of what is in scope out, which is how you reconcile the audit against the scanner's own target list. Doing that before you upload is the cheapest way to catch a scope mismatch. 11 00:02:36.204 --> 00:02:50.568 Manage Audit Scope decides which assets this audit covers, and Assign Auditors decides who works it. Both change an audit in flight, which is the point - neither needs a second audit raised beside it. 12 00:02:51.166 --> 00:03:06.444 So far we have looked at audits that already exist. This is how one is raised, and it is worth going through properly, because almost every question this module produces later is decided by a field on this form. 13 00:03:07.052 --> 00:03:17.574 The form is in four parts, and the order is the order you should think in: what is being assessed, what the audit is, what documents come with it, and who runs it. 14 00:03:18.173 --> 00:03:32.991 Organization comes first because it decides what everything below it can see. Your organisation is configured with an asset uniqueness level, and that level is what makes the next two fields required or optional. 15 00:03:33.589 --> 00:03:50.806 If assets are unique at organisation level, choosing the organisation is enough. If they are unique at business unit or at project level, those fields become mandatory, because the same address can exist twice and the audit has to know which one it means. 16 00:03:51.435 --> 00:04:20.581 One rule can stop the form saving, and it lives elsewhere. Where the platform is set to allow only one on-going VA audit per asset, a request for an asset that already has one running is refused with a message naming the rule. That is a setting under System, not a fault - two concurrent scans of one host would produce two sets of findings for one state. Wait for the running audit, or take the asset out of this one's scope. 17 00:04:21.192 --> 00:04:35.986 Audit Name is yours to write, and it is the label every later screen shows. Some deployments generate it automatically and lock it; where that is switched on, this field is filled in for you and cannot be edited. 18 00:04:36.590 --> 00:04:52.680 Audit Cycle does more than label the audit. Ad hoc is a one-off; calendar is one occurrence of a recurring programme. And the choice is carried forward - it decides which upload options you are offered when the report comes back. 19 00:04:53.280 --> 00:05:09.815 Host Selection is how the scope gets in. Manual opens a picker of the assets mapped to this organisation. Upload takes a spreadsheet, for a scope too large to click through - with sample files offered, so the columns are not guessed. 20 00:05:10.438 --> 00:05:26.864 Audit Document is where the agreed scope, the rules of engagement or the client's own request letter is attached. It is not required to raise the audit, and attaching it here is what makes it available to everyone who works the audit later. 21 00:05:27.442 --> 00:05:46.154 Custom Properties are fields your own organisation added, not part of the product's form. An administrator defines them - free text, a number, a date, a dropdown, or radio options - and the ones marked mandatory must be filled before the audit can be raised. 22 00:05:46.730 --> 00:06:00.541 Scheduled decides whether the audit runs on a date rather than on request. Answering yes reveals the auditor field, because a scheduled audit needs someone assigned to it before it can run unattended. 23 00:06:01.131 --> 00:06:17.001 Request VA Audit Now stays disabled until the mandatory fields and at least one host are in place, which is deliberate: an audit with no scope is not a smaller audit, it is one that cannot run. We will leave this one unsent. 24 00:06:17.631 --> 00:06:34.228 Before any of that though, the file itself. Every one of these paths ends with a report you produce from the scanner, and the commonest reason an upload fails outright rather than partially is that the file is not shaped the way the parser expects. 25 00:06:34.826 --> 00:06:49.431 Each scanner has its own mandatory columns, and the product will refuse the whole file if any of them is missing - not skip the row, refuse the file. This is a Qualys export, with the six it must carry. 26 00:06:50.030 --> 00:07:09.171 Two things about that are worth knowing before you export. The severity column is the scanner's own scale, not this product's, and it gets mapped on the way in. And the detection score column has a valid range - a value outside it is rejected for that row rather than clamped. 27 00:07:09.776 --> 00:07:24.738 A Nessus export is a different shape entirely, and it can be either of two formats. The spreadsheet form needs ten columns, and the product prints the list for you in the upload dialog itself rather than making you find it. 28 00:07:25.340 --> 00:07:42.199 The other Nessus form is the scanner's own XML, and there the product is not looking for columns at all - it looks for two tags. If either is absent the file is refused, and that is usually a sign the export was partial rather than malformed. 29 00:07:42.793 --> 00:07:59.361 And the third scanner asks for five, with its own names for the same ideas - the address column is spelled differently, and the identifier is its own rather than either of the others. A file exported for one scanner will not load as another. 30 00:07:59.998 --> 00:08:20.436 Two practical points that apply to all of them. The delimiter is detected rather than assumed, so a semicolon-separated export is fine. And rows before the header are normal - a real export often carries a preamble, and the parser skips down to the header rather than failing on the first line. 31 00:08:21.033 --> 00:08:38.011 And the date columns are configurable rather than fixed. Your deployment decides which header carries the discovery date and what format it is written in, so if dates arrive empty after an upload the mapping is the first thing to check, not the export. 32 00:08:38.633 --> 00:08:43.973 Then the report is uploaded, and this is where the module rewards understanding. 33 00:08:44.572 --> 00:08:58.022 The product decides for itself whether this is a first upload or a re-upload, and it is not asking when you last uploaded. It looks at whether this audit has ever accepted a report into its queue. 34 00:08:58.608 --> 00:09:09.346 Which has a consequence worth knowing: if your first attempt failed to parse, it produced no queue entry, so your second attempt is still treated as the first upload. 35 00:09:09.931 --> 00:09:22.901 Which options you are offered is not a fixed list. It is computed from three things at once: the tool's workflow, whether this is a first upload or a re-upload, and the audit cycle. 36 00:09:23.502 --> 00:09:39.999 That is worth knowing before you raise a ticket about it. Two colleagues uploading to two different audits will genuinely see different options, and each will be convinced the other is looking at the wrong screen. Neither is: the list is calculated. 37 00:09:40.575 --> 00:09:51.291 There are five ways a report can be applied, and choosing the wrong one is the commonest way to damage an estate's data. We will take them in the order they matter. 38 00:09:51.883 --> 00:10:04.702 Closure includes vulnerabilities from the latest audit as closed if they are not found in the report. So it does two jobs: it adds what is new, and it closes what has gone away. 39 00:10:05.290 --> 00:10:21.861 Limited Closure does almost the same thing, with one clause removed. It closes what is not in the report, but no vulnerabilities get added. Use it for a report you trust to tell you what is fixed, but not to tell you what exists. 40 00:10:22.455 --> 00:10:33.363 Merge considers only new vulnerabilities in the latest report, and leaves everything existing exactly as it is. It never closes anything. 41 00:10:33.994 --> 00:10:51.046 Ignore skips assets that already have at least one vulnerability, and again leaves existing findings alone. And Close Only marks existing open vulnerabilities closed - and if something is not found in the audit at all, it is added and closed. 42 00:10:51.644 --> 00:10:58.254 The tool you scanned with narrows it further, and the mapping is worth memorising if you upload regularly. 43 00:10:58.860 --> 00:11:13.342 Qualys reports come in for closure. Nessus depends on which report you exported: a Full scan supports closure and limited closure, an Advisory report merges, and a Remediation report is close-only. 44 00:11:13.936 --> 00:11:29.859 That last one matters more than it sounds. A Remediation export lists what was fixed, not what exists. Applying it as a Closure would close everything it does not mention - which is almost your entire estate. 45 00:11:30.444 --> 00:11:42.238 Qualys uploads also let you choose which classes of finding to bring in. Confirmed is selected by default. Potential and Information Gathered are not. 46 00:11:42.814 --> 00:11:56.888 Those defaults are deliberate. Turning on Information Gathered will make your counts jump for things that are not weaknesses at all, so if your numbers suddenly change shape after an upload, check what was ticked. 47 00:11:57.504 --> 00:12:05.862 Closure and Limited Closure offer one more option, and it is the most powerful and the most dangerous setting in this module. 48 00:12:06.450 --> 00:12:16.256 It treats any asset that is in scope but absent from the report as having nothing wrong with it. Its previously open findings are closed. 49 00:12:16.843 --> 00:12:29.431 Used correctly that is exactly right: the asset was scanned, it came back clean, and its old findings should close. It is how an estate's numbers come down honestly. 50 00:12:30.012 --> 00:12:46.271 Used carelessly it is how an estate's numbers come down dishonestly. Scan half your hosts, upload with Closure and this option on, and the half you did not scan is treated as clean. Every finding on them closes. 51 00:12:46.849 --> 00:13:02.293 Nothing errors. No warning appears. The numbers improve. That is precisely why it is worth saying out loud in a training video: this is the one setting where the failure mode looks like success. 52 00:13:02.913 --> 00:13:13.171 When a second report arrives, the product has to decide which findings are the ones it already knows about. That decision has a definite answer. 53 00:13:13.781 --> 00:13:23.943 A finding's identity is the host it is on, the tool's own identifier for the weakness, the master record it belongs to, and the port and protocol. 54 00:13:24.543 --> 00:13:42.602 Two consequences follow, and both come up constantly. The same weakness on the same host on a different port is a different finding - and the port sits on every finding inside the host, which we will open in a moment. Closing one does not close the other. 55 00:13:43.237 --> 00:13:58.538 And because the tool's own identifier is part of identity, the same weakness reported by two different scanners arrives as two findings, until the vulnerability master ties them together. That is what the master is for. 56 00:13:59.139 --> 00:14:11.121 This screen is also shaped by volume. A scan across a thousand hosts produces tens of thousands of findings, so it rolls up by host rather than listing every one. 57 00:14:11.733 --> 00:14:28.113 Each row is a host, with a total, then the open count split by severity, and the closed count split the same way. Open and closed side by side is the useful part: a host with nothing closed has never been remediated at all. 58 00:14:28.686 --> 00:14:41.035 Opening a host gives its findings, with port and protocol, severity, status, discovered on, last observed date, S L A details and the proof of concept evidence. 59 00:14:41.600 --> 00:15:04.410 Last Observed Date is the field most people never look at, and it answers a real question. Discovered On is when the weakness first appeared. Last observed is when a scan most recently still found it. A finding whose last observed date has stopped moving may already be fixed, with nobody having closed it. 60 00:15:05.000 --> 00:15:20.276 Everything so far has been one scanner. The product supports three, and which one an audit uses is decided when the audit is raised, not here. So to see another scanner's options we open a different audit. 61 00:15:20.840 --> 00:15:28.621 This audit was raised against Tenable rather than Qualys, and the difference shows the moment the upload dialog opens. 62 00:15:29.220 --> 00:15:45.318 Tool is filled in and greyed out. That is the point worth taking away: you do not choose the scanner at upload time. If the tool here is wrong, the audit was raised against the wrong one, and that is where it has to be corrected. 63 00:15:45.900 --> 00:16:04.056 Work Flow is the first real choice, and this scanner offers all three. Upload is a file you already have. Scan asks the product to run one for you. Automated Sync keeps pulling results on a schedule without anyone uploading anything. 64 00:16:04.640 --> 00:16:18.214 Choose Scan and the form changes shape. A second field appears asking which of this vendor's two platforms the audit talks to, because they are configured separately and they do not offer the same things. 65 00:16:18.800 --> 00:16:25.554 Choosing the first of them reveals Scan Type, and this is the part that most changes what you get back. 66 00:16:26.120 --> 00:16:45.024 Full is an ordinary assessment of the whole scope. Remediation re-checks only what was already found, to confirm fixes. Advisory brings in vendor advisories rather than a sweep. Three different questions, and the product treats the answers differently. 67 00:16:45.620 --> 00:17:01.853 Watch what happens on Remediation. The file field becomes mandatory, because a remediation run needs the scan information that says which findings are being re-checked. A full scan does not need it, so the same field is optional there. 68 00:17:02.460 --> 00:17:21.430 And watch the note underneath. Everywhere else it says existing findings are closed, and anything not in the report is added and closed. On a remediation run the product drops that second half - because a remediation export confirms fixes; it does not go looking. 69 00:17:22.000 --> 00:17:40.682 Back on a full scan, the rest appears: which policy to run, which zone to run it from, which repository to file results in. These come from your scanner, not from here - an empty list means the integration is unconfigured, not that nothing exists. 70 00:17:41.300 --> 00:17:55.110 Below them are three switches. Tracking hosts that change address matters on any network using dynamic addressing: without it, the same machine looks like a new one every time it moves. 71 00:17:55.700 --> 00:18:15.390 And credentials. A scan run without them sees only what is exposed to the network; run with them it can look inside the host and report what is actually installed. The two produce very different reports from the same target, which is the commonest reason two scans of one machine disagree. 72 00:18:15.980 --> 00:18:31.061 The second platform is configured separately and asks a different set: a template type first, then either your own saved policy or one of the vendor's scanner templates, then which folder the scan is filed in and which scanner runs it. 73 00:18:31.660 --> 00:18:47.820 The third scanner is the simplest case: it has no workflow to choose at all. Selecting it puts the dialog straight into upload, because the product does not drive that scanner itself - it only takes the file the scanner produced. 74 00:18:48.420 --> 00:18:59.207 There is a second item in that menu, and it answers the question this module produces most often after an upload: what actually happened to the file I sent. 75 00:18:59.821 --> 00:19:07.439 View Uploaded Report opens a record of the recent uploads for this audit, one card each, newest first. 76 00:19:08.014 --> 00:19:25.018 Each card carries when it was requested and by whom, where it has reached, which of the five application modes was chosen, and which scanner produced it. That is enough to tell two uploads apart when someone says the numbers changed and nobody knows why. 77 00:19:25.616 --> 00:19:43.339 Severity records which risk levels were brought in. If a report was uploaded with Info unticked, those findings were never imported, and this is the only place that says so after the fact. A count that looks short is often this rather than a scanner problem. 78 00:19:43.957 --> 00:20:03.863 And the file itself is here, by name. It hands back the report exactly as it was uploaded, unchanged, which is what you want when the question is whether the scanner said something or the product misread it. Note it is the original export, not a log of what the product did with it. 79 00:20:04.479 --> 00:20:22.105 One caveat worth knowing before you rely on it: for one of the three scanners the uploaded file is deleted once it has been processed successfully, so this link will tell you the file has expired. That is not a fault; it is that scanner's files not being kept. 80 00:20:22.719 --> 00:20:31.057 The information icon beside the tool opens the reconciliation, and this is the part that answers a count nobody can explain. 81 00:20:31.647 --> 00:20:48.379 How many instances were added, how many hosts the report named that the audit could not match, how many it did match, and how many it discarded as duplicates. Together those say whether a thin number is a thin scan or a mapping problem. 82 00:20:48.996 --> 00:21:07.078 Be careful with them, though. They are separate counters, not a set of figures that add up to one total, and the product does not present them as a balance sheet. Use them to tell one kind of problem from another, not to reconcile to the last finding. 83 00:21:07.677 --> 00:21:19.592 The button at the foot opens the full history in a new tab. We will get there another way in a moment, because everything before today is on that screen rather than this one. 84 00:21:20.194 --> 00:21:29.278 Which brings us to the screen that answers the question this module generates most often: I uploaded a report, so where are my findings? 85 00:21:29.862 --> 00:21:42.425 The queue is the only place that tells you what happened between the file leaving your machine and the findings appearing on a screen. Everywhere else shows you the result; this shows you the process. 86 00:21:43.022 --> 00:22:02.784 An upload moves through states, and the row of chips above the table is the vocabulary: Pending, In Progress, Completed, Failed - and, if someone stops it, Cancelling and Cancelled. A row sitting in one of the first two for a long time is not the same problem as a row that reached Failed. 87 00:22:03.367 --> 00:22:15.810 Beside its status each row carries a summary of what the system made of the report. That is the reconciliation, and it is the part that answers a question a finding count cannot. 88 00:22:16.416 --> 00:22:33.373 It answers what the system made of the file: how many instances landed, how many hosts it could not map, how many it threw away as duplicates. That last group is where a scan that clearly ran and numbers that look wrong get reconciled. 89 00:22:33.971 --> 00:22:52.630 That distinction matters most in this module, because a report that failed to parse and a scan that genuinely found nothing produce exactly the same thing downstream: no new findings. The queue is how you tell those two apart, and it is the first place to look rather than the last. 90 00:22:53.232 --> 00:23:12.251 Before reading anything on this screen, one fact that changes what you are looking at. This page does not open on everything. It arrives filtered to the last few days, and the filter count beside the button is already showing two before you have touched it - those two are the dates. 91 00:23:12.869 --> 00:23:25.532 So an upload from last month is not missing from here; it is outside the window. If someone says a record is gone, widen the start date before you conclude anything else. 92 00:23:26.144 --> 00:23:44.111 Three of these columns sound alike and are not. Report Type is which scanner produced it. Upload Type is which application mode was chosen. Workflow is how it arrived - a file you sent, a scan the product ran, or a scheduled sync. 93 00:23:44.702 --> 00:24:01.947 Opening the filter drawer shows what you can narrow by: the application mode, the workflow, and the date window. One field is missing here that appears on some deployments - an address filter, which the product offers only for audits it runs itself. 94 00:24:02.559 --> 00:24:16.869 Reset clears the drawer and re-queries; Apply keeps what you set. Both re-ask the server rather than filtering what is already on screen, which is why a wide date range takes a moment on a busy audit. 95 00:24:17.461 --> 00:24:34.613 Each row's own menu carries two files. Queue File hands back the report as it was uploaded. Queue Summary is different: it is the list of addresses a scheduled batch covered, which is how you check that a sync looked where you expected it to look. 96 00:24:35.201 --> 00:24:52.901 Both are downloads rather than screens, so there is nothing to show you here - the point is knowing they exist and which question each one answers. Neither of them explains why a finding did not import; for that, the reconciliation figures are what you have. 97 00:24:53.512 --> 00:25:12.359 A scheduled scan that has not started yet can still be stopped, and the option to do it appears only on those rows. Once a run is under way or finished there is nothing to cancel, so the product does not offer it - an absent option here is information, not a permission problem. 98 00:25:12.954 --> 00:25:27.650 And the paging line tells you how much of the history you are seeing at once. On an audit that has been re-uploaded through a long remediation cycle this list gets long, and the row you want is usually not on the first page. 99 00:25:28.270 --> 00:25:40.522 Everything so far has been about getting findings in. This is where you work them. From the host list, the action at the end of a row opens that host's findings. 100 00:25:41.147 --> 00:25:51.860 The action is offered only where the host actually has findings. A host that came back clean has nothing to open, and the control is there but inert. 101 00:25:52.456 --> 00:26:07.563 The header names the three things that make this screen specific: the organisation, the audit it belongs to, and the host itself. The same weakness on a different host, or in a different audit, is a different screen. 102 00:26:08.160 --> 00:26:23.315 Six counters summarise the host. Total is every finding ever raised against it in this audit. Open is what is still outstanding, and it is the number worth watching. Close is what has been seen off. 103 00:26:23.914 --> 00:26:40.196 The information icon beside Open breaks that number down by severity. It is the fastest read on the screen: whether the open work is one critical finding or thirty low ones changes what you do next, and the total alone cannot tell you. 104 00:26:40.788 --> 00:26:55.033 Exploitable counts the findings a working exploit is known for. Patched and Exception handled are the two ways a finding leaves the open count without being disproved -- one fixed, one accepted with a reason recorded. 105 00:26:55.622 --> 00:27:11.812 Each finding carries three identifiers, and they answer different questions. The scanner's own identifier is how you look the finding up in the vendor's documentation. The tracking reference is how you and your team refer to it here. 106 00:27:12.429 --> 00:27:27.051 The third is the key, and it is the identity rule from earlier made visible. It combines the scanner, the finding and the port, which is exactly why the same weakness on two ports arrives as two rows rather than one. 107 00:27:27.670 --> 00:27:41.265 Severity comes with the score behind it. The band is what most people filter on, but the score is what separates two findings that share a band, and it is the scanner's own number, not ours. 108 00:27:41.869 --> 00:27:52.229 Status is set per finding, and it is a control rather than a label. Where a status change has been recorded, the date it happened sits underneath. 109 00:27:52.818 --> 00:28:15.004 Opening it offers where this finding can go next. The current status is shown at the top and cannot be re-selected. Worth knowing: not every status appears here. Some are set by the system as work completes rather than chosen by a person, so they exist on findings but are never offered as a destination. 110 00:28:15.620 --> 00:28:35.213 Two of these are the ones people misuse. False Positive says the scanner was wrong. Risk Accepted says it was right and the organisation has decided to live with it. They close the same row and they mean opposite things, so the one you pick is what the next auditor reads. 111 00:28:35.836 --> 00:28:47.942 The service level columns tell you how long this finding has to be dealt with. There is the date it falls due, the window it was given, and whether that window has already passed. 112 00:28:48.549 --> 00:28:58.832 The window comes from the severity, not from the finding, so a critical and an informational finding discovered on the same day are due on very different dates. 113 00:28:59.427 --> 00:29:08.799 The row menu carries the two history views. Status History is the one to reach for when somebody asks who closed a finding and when. 114 00:29:09.374 --> 00:29:22.515 Every transition is recorded with the person who made it and the moment they did. A finding that has moved once shows one line; one that has been argued over shows the whole argument, in order. 115 00:29:23.102 --> 00:29:37.897 Vulnerability History, alongside it, is the wider view: the same finding across every audit that has covered this host, which is how you tell a finding that keeps coming back from one that has simply never been closed. 116 00:29:38.509 --> 00:29:54.099 Above the table, the severity tabs and the search narrow what you are looking at. The search takes a vulnerability name or any of the scanner identifiers, which is the quickest way in when somebody sends you a reference and nothing else. 117 00:29:54.697 --> 00:30:08.866 And the count at the foot is the honest one: it reports what the current filter returned, not the host's total. If it disagrees with the counters at the top, that is a filter still applied, not a discrepancy. 118 00:30:09.458 --> 00:30:27.397 That is Network V A end to end. An audit that must pass Approved before it counts, a report applied one of five ways depending on your tool, an identity rule that makes the same weakness on two ports two findings, and a queue that explains everything in between. 119 00:30:27.998 --> 00:30:45.024 If you remember two things, remember these. Choose the upload type to match the report you actually exported, not the one you usually use. And when findings vanish after an upload, look at whether non-reported assets were treated as clean.