WEBVTT

1
00:00:00.619 --> 00:00:15.267
Welcome to NxSAM training. This module covers Red Teaming, and the first thing to establish is how it differs from penetration testing - because the two are often used interchangeably and they are not the same exercise.

2
00:00:15.536 --> 00:00:26.562
A penetration test asks whether a defined target can be broken into. It is scoped by system, and its output is a list of weaknesses in that system.

3
00:00:27.176 --> 00:00:45.546
A red team engagement asks whether an objective can be achieved. Reach the customer database. Obtain domain administrator. Move money. It is scoped by goal, and the systems it passes through on the way are whatever it takes.

4
00:00:46.120 --> 00:01:01.202
Which means the two answer different questions. A penetration test tells you how strong a wall is. A red team tells you whether anyone would have noticed someone climbing it - and how far they got before anyone did.

5
00:01:01.800 --> 00:01:07.789
An engagement is recorded as an audit, in the same shape as the rest of the platform.

6
00:01:08.380 --> 00:01:24.326
Request Info, Audit Details, Vulnerabilities, Audit Properties and Audit Status. The familiar structure, because an engagement still has to be requested, scoped, staffed and approved like any other assessment.

7
00:01:24.940 --> 00:01:32.365
Raising one asks for less than you might expect, and what it leaves out is as informative as what it asks.

8
00:01:32.980 --> 00:01:47.753
An organisation, and a category - internal or external, meaning whether the team starts from inside your network or from the internet like anybody else. That single choice changes what the whole exercise proves.

9
00:01:48.340 --> 00:02:02.943
There is no name field here, and that is not an omission. This tenant generates audit names automatically, so the form does not offer one - which is worth knowing before you go looking for where to type the objective.

10
00:02:03.520 --> 00:02:14.090
Approve audit is the interesting control. Ticking it approves the engagement as you raise it, and doing so reveals a field that was not there a moment ago.

11
00:02:14.680 --> 00:02:27.507
The auditor. Because an approved engagement is one that can start, and one that can start needs somebody assigned to it - so the form asks for that only once you have said it may begin.

12
00:02:28.100 --> 00:02:43.278
Cancel leaves the list as it was. Nothing is raised until the form is submitted, which matters more here than elsewhere: an engagement that exists but was never agreed is one the defenders have not been told about.

13
00:02:43.860 --> 00:02:55.918
The row menu is where the engagement is run from, and what it offers depends entirely on where the engagement has got to. This is the first row, still only requested.

14
00:02:56.480 --> 00:03:11.320
Three items. Edit its details, read its status history, delete it. There is nothing here about running the work, because none of the work can start until somebody approves it.

15
00:03:11.940 --> 00:03:20.473
View Status History is the trail, and it is one of only two items on this menu that appear whatever state the engagement is in.

16
00:03:21.060 --> 00:03:33.830
Two entries so far: drafted, then requested. That is all a trail looks like before anyone has approved anything, and it grows a line every time the engagement moves.

17
00:03:34.400 --> 00:03:47.153
Which is the point of keeping it. On an engagement that will be questioned afterwards - and they are - this is the record that says who authorised the work, and when, before any of it happened.

18
00:03:47.740 --> 00:03:53.486
Edit Audit Details reopens that same form against an engagement that already exists.

19
00:03:54.080 --> 00:04:08.037
It is offered here because this engagement is still the requester's own and still unapproved. Once somebody has approved it, changing what it was for stops being an edit and starts being a different engagement.

20
00:04:08.600 --> 00:04:17.662
Three things are worth settling before an engagement begins - and it is worth knowing up front that the record here has room for only some of them.

21
00:04:18.260 --> 00:04:33.917
The objective, stated concretely enough to be answerable. The first row here says Annual Red Team Exercise, which is a calendar entry rather than an objective - nobody can grade it, and it is still sitting at requested.

22
00:04:34.480 --> 00:04:50.187
The second row says: reach the payment database from a corporate laptop. That is answerable. It has a starting point, a target, and a yes-or-no at the end of it - and it is the one that got approved and staffed.

23
00:04:50.780 --> 00:05:13.304
The rules of engagement - what is in bounds, what is explicitly not, and what stops the exercise immediately. Denial of service, production data, physical entry, social engineering of named people: each needs a yes or a no in advance. None of that has a field here, so agree where it lives.

24
00:05:13.900 --> 00:05:33.758
And who to call. A red team engagement will eventually look exactly like a real incident to somebody, and the value of the exercise depends on that person responding as though it is. There has to be a small number of people who can confirm it is authorised, reachable at short notice.

25
00:05:34.320 --> 00:05:42.299
That last one is the piece most often skipped, and it is the one that turns a good exercise into an incident nobody planned.

26
00:05:42.900 --> 00:05:56.974
The Audit Properties column is where you might expect all of that to live. It is worth seeing what is actually there: the auditors who own the engagement, and its category. Two facts, not four.

27
00:05:57.560 --> 00:06:12.979
That does not make the rules of engagement optional. It means the platform will not hold them for you - so they have to live somewhere you can find them a year later, referenced from the engagement rather than sitting in somebody's inbox.

28
00:06:13.580 --> 00:06:21.558
Once an engagement is approved, the same menu grows. This is the second row, the one in progress.

29
00:06:22.120 --> 00:06:32.410
Five items now. The two that appeared are the two that only make sense once work can start: Assign Auditors, and View Vulnerabilities.

30
00:06:33.020 --> 00:06:44.910
Assign Auditors is who is actually doing this. Red team work is small-team work, and the names here are the people whose activity the defenders may end up investigating.

31
00:06:45.500 --> 00:07:00.367
The people already on the engagement are ticked. Adding somebody here is also what makes their name meaningful in the findings - every finding records who raised it, and on this kind of work that trail matters more than usual.

32
00:07:00.980 --> 00:07:06.751
One more control on this screen before the findings. More Filters.

33
00:07:07.320 --> 00:07:26.722
Organisation, audit status and category. Worth knowing that the status list here is this module's own - a red team engagement is requested, approved, not started, in progress, on hold, completed or aborted, and those are not quite the words the other modules use.

34
00:07:27.340 --> 00:07:32.751
The findings screen is the leanest in the entire product, and that is deliberate.

35
00:07:33.340 --> 00:07:44.486
The header names the engagement, its client and its category, and it is the same engagement whose objective you just read: reach the payment database from a corporate laptop.

36
00:07:45.100 --> 00:07:53.508
Beside it is an information control that carries the engagement's own identifiers and a link back to the audit it belongs to.

37
00:07:54.080 --> 00:07:58.724
There is one button on this header, and it is how findings arrive.

38
00:07:59.340 --> 00:08:17.782
Upload Report takes a spreadsheet - findings written up offline and brought in together, which is how red team work actually gets recorded. There is no scanner feeding this screen, so somebody has to type them somewhere, and doing it in one file beats doing it one row at a time.

39
00:08:18.360 --> 00:08:32.221
A sample file is offered beside the upload, and it is worth downloading once before you need it - the columns it expects are the columns the import will accept, and finding that out at the end of an engagement is the wrong time.

40
00:08:32.820 --> 00:08:38.567
Then the table itself, and what is worth noticing is how few columns it has.

41
00:08:39.160 --> 00:08:56.213
An identifier, the finding itself, its severity and its status. No scanner, no tool, no C V S S vector - because nothing here came from a scanner. Every row is something a person did, and wrote down.

42
00:08:56.800 --> 00:08:59.762
Opening one gives you the whole finding.

43
00:09:00.360 --> 00:09:09.466
Linked assets and the description open together, because on this kind of work the two belong to each other: what was reached, and how.

44
00:09:10.060 --> 00:09:19.792
Impact is the section that gets read by people who were not in the room. It is where the finding stops being a technique and becomes a consequence.

45
00:09:20.380 --> 00:09:37.886
And Recommendation. Only one section is open at a time here, which is a small design decision with a real effect: it stops the dialog becoming a wall of text and makes you read one thing at a time.

46
00:09:38.500 --> 00:09:45.448
Which brings us to how a red team result should be read, and it is not the way a vulnerability list is read.

47
00:09:46.040 --> 00:09:56.993
The severity chips do work here, and they are worth using once. Filtering to the critical findings answers a different question from reading the list in order.

48
00:09:57.580 --> 00:10:10.790
Because a red team report is a narrative, not an inventory. Five findings that chain into one another matter more than fifty that do not, and severity alone will not tell you which you have.

49
00:10:11.395 --> 00:10:27.172
Read the chain first: where it started, what it reached, and which single step, if it had failed, would have stopped the rest. That step is the finding to fix first, and it is often not the one with the highest severity on it.

50
00:10:27.762 --> 00:10:42.606
Then read what was not found, which on this kind of engagement is genuine information. If the team could not reach the objective, that is a result - provided the report says how hard they tried and where they were stopped.

51
00:10:43.207 --> 00:10:47.996
Each finding carries one action, and it is worth seeing what it is.

52
00:10:48.589 --> 00:11:04.085
Delete, and nothing else. There is no validation workflow on a red team finding and no client status, because there is no dispute to be had - somebody did this, and it is written down. That is the whole record.

53
00:11:04.715 --> 00:11:10.435
Which is also why this module is not a penetration test module with a different name.

54
00:11:10.702 --> 00:11:25.638
A penetration test is measured by coverage: every host, every endpoint, every parameter. A red team engagement is measured by whether the objective fell, and by what the defenders saw while it was falling.

55
00:11:26.236 --> 00:11:40.457
So the two produce different documents. A pentest report is a list you work through. A red team report is an account of what happened, and the list of findings is the evidence for it rather than the point of it.

56
00:11:41.050 --> 00:11:57.308
And they fail differently. A pentest that finds nothing may mean the system is sound. A red team that finds nothing more often means the objective was too narrow, or the time too short, and that is worth saying out loud in the report.

57
00:11:57.883 --> 00:12:03.004
What happens afterwards is where the value is either realised or lost.

58
00:12:03.608 --> 00:12:21.621
Every finding carries who raised it and when - you saw it at the head of the one we opened - and that timestamp is doing more work than it looks. Compared against your own detection records, it answers the question the exercise was really run to answer: did anyone notice?

59
00:12:22.209 --> 00:12:37.193
Run that comparison finding by finding and you get a detection gap analysis for free - which steps were seen, which were seen and ignored, and which passed unnoticed. That is usually worth more than the findings themselves.

60
00:12:37.792 --> 00:12:51.843
Then fix the chain, not the list. If one step in the middle would have stopped everything after it, that is the remediation with the highest return, and it will not be the row with the largest severity chip on it.

61
00:12:52.444 --> 00:13:08.344
That is Red Teaming. An engagement scoped by objective rather than by asset, a menu that changes with the state of the work, a findings list with no scanner behind it, and a report that is an account rather than an inventory.

62
00:13:08.949 --> 00:13:27.662
Three habits. State the objective as a sentence somebody could grade. Agree the rules of engagement and the contact list before anything starts, and keep them where the engagement can find them. And when the report arrives, read the chain before the severities.