WEBVTT 1 00:00:00.623 --> 00:00:10.351 Welcome to NxSAM training. This module covers Segmentation Testing, and it asks a question no other module in the product asks. 2 00:00:10.632 --> 00:00:21.419 Every other module asks what is wrong with a host. Segmentation testing asks whether the network boundaries you believe exist actually exist. 3 00:00:21.704 --> 00:00:40.171 That distinction matters because segmentation is usually something an organisation has asserted to somebody else. A card-holder data environment is isolated. Production and corporate are separated. The regulator has been told there is a boundary. 4 00:00:40.770 --> 00:00:53.356 Those are claims, and a segmentation test is how a claim becomes evidence. Which is why the findings here are not weaknesses at all - they are reachability that should not exist. 5 00:00:53.927 --> 00:00:57.105 An audit is one test of one boundary. 6 00:00:57.704 --> 00:01:07.002 The list carries audit details, the business unit it concerns, its status, the auditor, the source hosts, and who requested it. 7 00:01:07.639 --> 00:01:23.397 Source Hosts is the column that makes this a segmentation test rather than a scan. Everywhere else in the product an audit has a scope of things to examine. Here it has a set of places to test *from*. 8 00:01:23.980 --> 00:01:44.461 That is the whole idea in one column. Reachability is not a property of a host; it is a property of a pair. You cannot ask whether a database is reachable - only whether it is reachable from somewhere. And this column is only half of a pair: twelve places to test from. 9 00:01:45.051 --> 00:02:05.656 So the actions follow that logic. View Audit Source Hosts reads where the test runs from, and Edit Audit Source Hosts changes it while the audit is still a draft. View Audit Details and View Status History read the audit. Assign Auditors and View Findings come later in its life. 10 00:02:06.276 --> 00:02:16.199 View Audit Source Hosts reads that list back, and it is worth opening before anything else, because the next few minutes are about how it gets chosen. 11 00:02:16.782 --> 00:02:24.522 Which makes choosing the sources the most consequential decision in this module, and it is worth spending a moment on. 12 00:02:25.127 --> 00:02:37.545 A segmentation test proves exactly what it tested from, and nothing else. Test from three machines on the corporate network and you have proved something about those three machines. 13 00:02:38.122 --> 00:02:55.681 So pick sources that represent the places an attacker would realistically be. A corporate laptop subnet. A guest wireless range. A supplier's connection. A lower-trust environment such as development or test. 14 00:02:56.283 --> 00:03:09.757 And include the segments people forget, because those are where the exceptions live - the management network, the backup network, and whatever was built quickly during an incident two years ago and never removed. 15 00:03:10.342 --> 00:03:23.168 One host per segment is usually enough. What you are testing is the boundary, not the host, so a second machine on the same side of the same firewall adds evidence you already have. 16 00:03:23.764 --> 00:03:33.763 Two more things live on that row. View Status History is the audit trail - every state this test has been through, who moved it and why. 17 00:03:34.379 --> 00:03:49.050 Read it as a timeline. A test that was drafted, requested, and then sent back has a story in it - here, the source list was missing a segment and somebody noticed before the test ran rather than after. 18 00:03:49.661 --> 00:03:58.479 And raising a segmentation test asks for less than you might expect, because most of the decision is the source list you have just seen. 19 00:03:59.071 --> 00:04:15.836 An organisation, a name, and the destination hosts - the things you are testing towards. Manual picks them from the inventory; Upload takes a file, which is what you want when the boundary is defined by a subnet list somebody else maintains. 20 00:04:16.423 --> 00:04:32.505 Notice what is not asked for: no severity, no scanner, no schedule. A segmentation test is defined entirely by where it runs from and what it runs towards, and everything else about it is a consequence of those two lists. 21 00:04:33.087 --> 00:04:39.289 The findings are held as two related lists, and the relationship between them is the finding. 22 00:04:39.888 --> 00:04:50.002 They sit on two tabs, and the one that opens first is the one you will spend your time on - Destination Hosts. Source Host is the second. 23 00:04:50.619 --> 00:05:03.088 Sources are the hosts the test ran from: host name, host, and information about it. That is the trusted side of the boundary, or at least the side you are testing from. 24 00:05:03.686 --> 00:05:17.834 Destinations are what was reached. Each row carries a hosts identifier, the destination host, the source host it was reached from in brackets, the port it answered on, and information about it. 25 00:05:18.414 --> 00:05:33.784 Notice that the source is carried on the destination row. That is not redundancy - it is the finding. Without it you would have a list of hosts that answered, with no record of which boundary they were answering across. 26 00:05:34.363 --> 00:05:49.082 Read that structure carefully, because it is unlike anything else in the product. A destination row is not a vulnerable host. It is a statement that this host could reach that host on that port. 27 00:05:49.709 --> 00:06:05.824 Which means a segmentation finding cannot be fixed by patching anything. It is fixed by changing a firewall rule, an access control list, or a network design - and it is verified by running the test again from the same sources. 28 00:06:06.406 --> 00:06:24.897 The port is part of the finding here, as much as in a V A finding. But notice what this column actually says: not which port, only whether anything answered. Which port it was is behind View T C P on the row - and closing one says nothing about the next. 29 00:06:25.515 --> 00:06:36.691 So open it. Three services answered across this one boundary, each with the port it answered on, and the scan output the tester attached as evidence. 30 00:06:37.306 --> 00:06:56.466 This is why the Port column is a yes or no rather than a number. One boundary can carry several services, and closing the one somebody remembers says nothing about the two beside it. A remediation plan written from the column alone is a plan to close one third of this finding. 31 00:06:57.047 --> 00:07:08.433 And the row above it answers differently. Nothing was open, so there is nothing to list - which in this module is the result you were hoping for, stated plainly. 32 00:07:09.015 --> 00:07:24.746 The verbs on each row follow from that. Where something was recorded you get Edit and View; where nothing has been tested yet you get Add. So the row itself tells you how far the work has got, without opening anything. 33 00:07:25.327 --> 00:07:29.512 One thing to understand before you read your first result. 34 00:07:30.104 --> 00:07:49.821 In every other module, a screen with no findings means the assessment has not run yet. Here, an empty destination list is the result you wanted: nothing was reachable that should not have been. The numbers carrying that news are the open service counts - here, seven and two. 35 00:07:50.401 --> 00:08:06.036 So the source list matters more here than anywhere else, because it is what proves the test was actually performed. An empty destination list with no sources recorded is not evidence of isolation - it is evidence of nothing. 36 00:08:06.631 --> 00:08:19.985 If you are reviewing a segmentation test, read the sources first, then the destinations. That order is the difference between a report that demonstrates a boundary and one that merely asserts it. 37 00:08:20.581 --> 00:08:27.529 When there are findings, they are not all equal, and severity is not the right lens for sorting them. 38 00:08:28.150 --> 00:08:39.272 Ask two questions of each pair. Is this reachability intended? And if it is, is that decision written down anywhere outside this table? 39 00:08:39.865 --> 00:08:50.603 Those two answers give you three groups. Intended and documented - no action, and the test has just confirmed your documentation is accurate. 40 00:08:51.237 --> 00:09:03.920 Intended but undocumented - the reachability stays, and the exception gets written down. That is the group people skip, and it is why the same argument recurs at every assessment. 41 00:09:04.526 --> 00:09:18.624 And unintended - which is a real finding, and belongs to a network team rather than a security one. The port tells them what to look for; the source and destination tell them which device the rule is on. 42 00:09:19.238 --> 00:09:31.703 Then re-test from the same sources. A segmentation fix that has not been re-tested is an assertion again, and this whole module exists to replace assertions with evidence. 43 00:09:32.313 --> 00:09:51.117 That is Segmentation Testing. An audit defined by where it runs from, findings that are pairs rather than things, remediation that happens in network configuration rather than on a host, and an empty result that means success - provided the sources say the test was really run. 44 00:09:51.719 --> 00:10:06.826 Segmentation completes the network picture. Vulnerability Assessment tells you what is weak, penetration testing tells you what can be exploited, and segmentation tells you how far an attacker gets once they are inside.