WEBVTT

1
00:00:00.615 --> 00:00:15.647
Welcome to NxSAM training. This module covers Network Penetration Testing. If you have taken the Vulnerability Assessment module, the audit shape here will be familiar - what a test produces is not.

2
00:00:15.928 --> 00:00:28.562
V A is broad and automated: sweep everything, report what is recognised. A penetration test is narrow and human: take a defined target and try to break into it.

3
00:00:28.829 --> 00:00:46.913
That difference shows up everywhere in this module. A scanner reports what it matched against a signature. A tester reports what they achieved, how they achieved it, and what they learned along the way - and the last of those has nowhere to go in a scanner's output.

4
00:00:47.489 --> 00:00:51.723
An audit here is one engagement against a defined scope.

5
00:00:52.345 --> 00:01:02.099
The list carries the same grouped columns as V A: Request Info, Audit Details, Vulnerabilities, Audit Properties and Audit Status.

6
00:01:02.719 --> 00:01:16.170
What is missing is as telling as what is there. There is no Data Process column, because nothing is being ingested - a tester enters findings directly rather than a file being parsed and matched.

7
00:01:16.787 --> 00:01:27.499
Request New P T Audit raises an engagement, and it is worth opening rather than pointing at, because this form is where the scope of a test is actually decided.

8
00:01:28.085 --> 00:01:44.250
Scope comes first, and it narrows. Organisation, then business unit, then project. Each choice decides what the next one offers, which is what stops a test being requested against the wrong client's estate.

9
00:01:44.865 --> 00:02:00.334
Choosing the organisation is what brings the rest of the form to life - and how much of it you must fill in depends on which one you pick. Some are configured so a host is unique across the whole estate; others only within a project.

10
00:02:00.946 --> 00:02:15.403
With that set, business unit appears beneath it. On this organisation it is optional, and the form says so by leaving it unmarked - on another it would carry the same red asterisk as the fields above it.

11
00:02:16.003 --> 00:02:27.679
Audit Details is the engagement itself: a name you will recognise in a list six months from now, and the cycle it belongs to - ad-hoc, or part of a calendar programme.

12
00:02:28.245 --> 00:02:45.969
Then the decision that has no equivalent in a scanning module: which hosts are in scope. Manual, where you pick them from the inventory, or Upload, where you supply a file - and a penetration test almost always starts from a list somebody agreed in writing.

13
00:02:46.562 --> 00:02:59.322
Select I P opens the inventory for the organisation you chose. Every host it offers belongs to that organisation - you cannot reach outside it from here, which is the point.

14
00:02:59.932 --> 00:03:18.473
Each host carries its address, its name, and whether it is reachable from outside or only from within. That last column is why this is not simply a set of tick boxes: an external host and an internal one are different pieces of work, and often different permissions.

15
00:03:19.055 --> 00:03:35.624
The count above the list tracks what you have chosen, and it is what enables the submit button on the form behind. A request with everything else filled in and no hosts cannot be sent - an engagement without a target list is not an engagement.

16
00:03:36.234 --> 00:03:46.229
Back on the form, Scheduled decides whether this is work to be planned or work starting now - and answering yes adds the question that follows from it.

17
00:03:46.815 --> 00:03:57.193
An Auditor field appears. That is the difference between a request and a booking: naming the person makes it somebody's work rather than a queue entry.

18
00:03:57.777 --> 00:04:19.893
Below that, two things worth filling in even though neither is required. A document, which is where the signed scope or the rules of engagement go. And custom properties - the fields your own organisation added, whether that is a cost centre, a change reference, or whatever your process needs to find this audit again.

19
00:04:20.499 --> 00:04:30.708
Cancel leaves nothing behind. Nothing on this form is saved until it is submitted, so you can open it, look at it, and close it again.

20
00:04:31.305 --> 00:04:41.036
Before the row itself, one control on the list. More Filters narrows by organisation, by audit status and by cycle.

21
00:04:41.613 --> 00:04:57.750
The status list here is the audit lifecycle in full - saved, requested, verified, approved, scheduled, and the rest. It is worth reading once, because it is the same vocabulary the status column and the history use.

22
00:04:58.323 --> 00:05:15.183
The vulnerability count means something different here than on a scanned module. There it is a measurement. On a penetration test it is a running total of what a person has found so far - so a low number on an audit in progress says nothing at all.

23
00:05:15.795 --> 00:05:25.477
The row actions are a smaller set than V A's, and the reason is the same one: a penetration test is scoped and staffed rather than configured.

24
00:05:26.073 --> 00:05:49.099
Assign Auditors puts people on it. View Vulnerabilities opens what has been found so far. Manage Audit Scope defines what is in and out of bounds, and View Status History shows how the engagement moved. We will open them, because on a penetration test every one of these is a contractual question rather than a setting.

25
00:05:49.690 --> 00:06:04.943
Assign Auditors is who can be put on this engagement, searchable, with the people already on it ticked. This is not an administrative detail on a test - the named tester is who the client's security team will be talking to.

26
00:06:05.547 --> 00:06:11.749
Which brings us to scope, and it deserves more attention than anything else on this screen.

27
00:06:12.327 --> 00:06:25.321
A penetration test is bounded by what was agreed, and a finding outside that boundary is one the tester was not allowed to look for. Manage Audit Scope is where that agreement is recorded.

28
00:06:25.943 --> 00:06:39.012
It holds two things. A written description - what is in, what is out, and the window the work runs in. And the documents behind it: the boundary as the client signed it off.

29
00:06:39.626 --> 00:06:51.995
This is what makes a result interpretable a year later. A reader who knows the payment provider was excluded reads an empty finding list very differently from one who does not.

30
00:06:52.570 --> 00:07:04.701
The other audit is still a draft, and its menu is not the same one. That is worth seeing rather than being told: the actions a row offers depend on where it has reached.

31
00:07:05.284 --> 00:07:23.201
Edit Tags appears here and not on the scheduled one, because tags are set while an engagement is still being shaped. The ones already applied are ticked, so it opens showing the current state rather than a blank sheet - the difference between editing tags and re-entering them.

32
00:07:23.831 --> 00:07:33.849
And View Status History is the audit trail. Every status this engagement has been through, who moved it, when, and the comment they left.

33
00:07:34.456 --> 00:07:51.579
Read it as a timeline rather than a log. The gap between requested and approved is how long the paperwork took; the gap between approved and scheduled is how long the testers were booked out. Both are worth knowing before anyone promises a date.

34
00:07:52.182 --> 00:08:00.905
The findings screen is organised the way a tester actually works, and that is the most useful thing to understand about this module.

35
00:08:01.493 --> 00:08:12.354
It is presented on three tabs - vulnerabilities, assets, and vulnerabilities groups - and each is for a different job. We will take them in turn.

36
00:08:12.942 --> 00:08:29.657
The vulnerability list is the test itself: each finding with its host, its port and its risk. Host and port together are what make a network finding actionable, because a host is not one target - it is one target per port that answers.

37
00:08:30.241 --> 00:08:40.739
The vulnerability title is a link, and behind it is the part of a finding that actually gets read: what it is, what it costs you, and what to do about it.

38
00:08:41.357 --> 00:08:59.010
Description, Impact and Recommendation. Impact is the one worth insisting on - it is the difference between a list of weaknesses and a case for spending money on them. And the S L A beneath tells you when this one was due, and whether it is already late.

39
00:08:59.634 --> 00:09:06.868
And because a tester enters findings rather than a file being parsed, there has to be a way to write one down.

40
00:09:07.448 --> 00:09:22.720
The first field is a catalogue rather than a free-text box. Picking from a known list is what makes the grouped view possible later - two testers who type the same weakness two ways produce two groups and one wrong remediation plan.

41
00:09:23.329 --> 00:09:37.188
Severity is set by the person, not derived from a score. On a penetration test that is correct: the tester knows what they actually achieved with it, and a scanner's severity cannot know that.

42
00:09:37.774 --> 00:09:51.658
Then where it applies. Assets are offered by address, and a finding can carry several - the same weakness on four hosts is recorded once, against four of them, with the port it answered on.

43
00:09:52.276 --> 00:10:07.913
Add by also offers Upload, for the case where a scanner did the finding and a person is confirming it. Both routes end in the same list - which is the point, because a report should not be able to tell you how a finding was typed in.

44
00:10:08.482 --> 00:10:17.637
With eight findings you can read the list. With eight hundred you filter it, and the three fields here are the three questions worth asking.

45
00:10:18.225 --> 00:10:38.637
Validation, which is whether a finding has been confirmed. Status, which is where it has reached. And host, so you can hand one machine's whole list to whoever owns it. The host list is built from the findings themselves, so it only ever offers machines that actually have one.

46
00:10:39.217 --> 00:10:55.189
Three things hang off every row, and together they are the difference between a finding and a conversation. Comments are the thread - the tester reports, the owning team answers, and the re-test is agreed in writing rather than in somebody's inbox.

47
00:10:55.792 --> 00:11:11.641
The second is the document trail: what was attached, by whom, and what the finding's status was at the time. A remediation plan filed against a finding that was still open reads differently from one filed after it was fixed.

48
00:11:12.243 --> 00:11:25.141
And the third is evidence, which is where a penetration test differs most from a scan. A scanner's evidence is the signature that matched. A tester's is what they actually did.

49
00:11:25.734 --> 00:11:42.448
An observation describing what was done and what came back, and the screenshots behind it. Without this a finding is an assertion rather than a demonstration - and on a report that somebody is going to argue with, that distinction is the whole job.

50
00:11:43.052 --> 00:11:53.047
One more, and it is the one that turns a report into a trend. Vulnerability History follows a single weakness across engagements.

51
00:11:53.669 --> 00:12:07.126
Found, fixed, found again. That is the pattern worth catching, because a weakness that returns is not a testing problem - it is a process one, and no amount of re-testing will close it.

52
00:12:07.741 --> 00:12:17.231
A tester types findings in. Everything else about this screen is about getting work in from elsewhere, and getting it back out again.

53
00:12:17.802 --> 00:12:28.441
Network P T Reports carries three: upload a scanner report, bring forward findings from an earlier test, and look at what has already been uploaded.

54
00:12:29.050 --> 00:12:42.932
Add old or past vulnerabilities is the one people do not expect. A re-test usually starts from last time's findings, and re-typing them loses the history that makes the re-test worth anything.

55
00:12:43.559 --> 00:12:57.828
Each carries the status it ended on last time. That is what you are choosing between: a finding that was patched is worth re-testing, and one the customer formally accepted is a different conversation entirely.

56
00:12:58.401 --> 00:13:05.251
And View uploaded report is the ingest history - every file, who sent it, and whether it landed.

57
00:13:05.861 --> 00:13:19.673
The most recent sits at the top, and this one failed. That is worth showing, because a failed import is silent otherwise - the findings simply are not there, and nothing on the list below says why.

58
00:13:20.272 --> 00:13:40.538
The summary behind each one is the part to read. It separates findings that were added from findings already present, and both of those from hosts the file mentioned that are not in this audit's scope. That last number is not an error - it is the file telling you it covered more ground than you asked for.

59
00:13:41.147 --> 00:13:57.164
The asset view is for handing work to whoever owns a machine. One row per asset: the asset identifier, the asset itself, its accessibility, port, the number of vulnerabilities found on it, and information gathered.

60
00:13:57.762 --> 00:14:13.828
Accessibility is worth pausing on. A scanner reports a weakness whether or not it can be reached; a tester records whether they could actually get to it. Those are different facts and the second one usually decides priority.

61
00:14:14.402 --> 00:14:30.299
Information Gathered is not a finding, and this is the field people misread most often. It is what the tester learned about the host that is not itself a weakness - banners, versions, exposed services, technologies in use.

62
00:14:30.918 --> 00:14:50.130
It is recorded for two reasons. It is what the next tester needs so the reconnaissance is not repeated from scratch. And a version noted today is very often a known vulnerability six months from now, at which point that note is the fastest way to find every host affected.

63
00:14:50.759 --> 00:15:01.544
The count in the vulnerabilities column is a link, and it answers the question whoever owns this machine will actually ask: not how many, but which ones.

64
00:15:02.123 --> 00:15:15.573
One host, its findings, their severity and where each has reached. This is the list you send to a system owner - it is their machine, their work, and nothing on it belongs to anyone else.

65
00:15:16.169 --> 00:15:22.683
And where an N Map scan was uploaded for a host, the port detail sits behind its own action.

66
00:15:23.295 --> 00:15:39.555
Port, protocol, state, and why the scanner decided that state. Then service, product and version - which is the reconnaissance that turns into a finding six months later, when a published vulnerability names that exact version.

67
00:15:40.122 --> 00:15:59.428
A closed port and a filtered one are not the same answer, and the reason column is what separates them. Closed means something replied and refused. Filtered means nothing replied at all - which is usually a firewall, and is a fact about the network rather than about the host.

68
00:16:00.005 --> 00:16:05.690
Ports are handled explicitly here in a way they are not anywhere else in the product.

69
00:16:06.311 --> 00:16:20.378
T C P, U D P and Other each have their own add and view actions. That is not a cosmetic split - a penetration test enumerates them separately because they are genuinely different exercises.

70
00:16:20.960 --> 00:16:38.945
T C P enumeration is fast and reliable. U D P enumeration is slow and unreliable, and is frequently skipped under time pressure. Recording them apart means the report can say which was actually done, rather than leaving a reader to assume both were.

71
00:16:39.540 --> 00:16:56.712
If you are reviewing someone else's test, that split is one of the first things worth checking. An engagement with a full T C P enumeration and an empty U D P one is not an incomplete record - it is a scoping decision, and it should have been a deliberate one.

72
00:16:57.306 --> 00:17:04.325
Which brings us to the third tab, and the question it answers is the one that decides your remediation plan.

73
00:17:04.953 --> 00:17:18.137
Vulnerability groups show each distinct weakness once, with how many findings carry it. That is the remediation view: one fix, applied everywhere that weakness was found.

74
00:17:18.735 --> 00:17:37.705
The difference between the two counts is worth knowing before you quote either. Here every weakness was found once, so the two agree. On a larger test they rarely do - forty findings can be four problems, and a plan built on the flat count is four times the size it needs.

75
00:17:38.287 --> 00:17:55.074
Both columns on this tab are links, and they go to different places. The title opens the weakness itself - the same description, impact and recommendation you would read from the flat list, because it is one weakness however many findings carry it.

76
00:17:55.663 --> 00:18:11.177
The count opens the other half: every finding carrying that weakness, with the host and port for each. That is the list you work from once you have decided to fix it - one fix, and here is everywhere it has to be applied.

77
00:18:11.786 --> 00:18:24.851
The flat list is one row per finding - vulnerability, host, port, risk, validation, status and artifacts. That is the working view, and the one you verify against.

78
00:18:25.465 --> 00:18:43.623
Validation and Status are separate here for the same reason as everywhere else in the product. Validation is whether the finding has been confirmed genuine. Status is where it has reached in its life. A finding can be validated and still open.

79
00:18:44.223 --> 00:19:04.465
Artifacts is where a penetration test differs most from a scan. A scanner's evidence is the signature that matched. A tester's evidence is a screenshot, a request and response, or a capture of what they achieved - and without it a finding is an assertion rather than a demonstration.

80
00:19:05.042 --> 00:19:26.869
The row actions are correspondingly few - Vulnerability History and Delete Vulnerability, with Edit while the finding is the tester's own draft. Changes in bulk are possible, and look at what they change: validation and status, on a selection you picked by hand. A finding here is closed by someone retesting it.

81
00:19:27.470 --> 00:19:43.944
That is Network Penetration Testing. Engagements rather than scans, findings organised by asset and port because that is how the work is done, information gathered recorded alongside weaknesses, and evidence attached to everything.

82
00:19:44.521 --> 00:20:01.834
The one thing to carry into a review: read Information Gathered and the port enumeration before you read the findings. They tell you what was actually looked at, which is what makes the findings interpretable. The next module covers segmentation testing.