WEBVTT

0:00:03.680000 --> 0:00:07.660000
 First response, the first five minutes.

0:00:07.660000 --> 0:00:13.000000
 So in this video, we're going to be taking
 a look at as the title suggests

0:00:13.000000 --> 0:00:15.980000
 the first response or the
 first five minutes.

0:00:15.980000 --> 0:00:21.480000
 And you may be asking yourself the first
 five minutes after what exactly?

0:00:21.480000 --> 0:00:28.060000
 Well, the first five minutes after
 receiving an incident to analyze or

0:00:28.060000 --> 0:00:32.940000
 investigate. So what we're taking a
 look at in this video is what you

0:00:32.940000 --> 0:00:37.820000
 will be doing as an incident responder
 or what you're expected to do as

0:00:37.820000 --> 0:00:42.540000
 an incident responder with regards to
 the first five minutes after receiving

0:00:42.540000 --> 0:00:48.420000
 an incident or after receiving
 a case to investigate.

0:00:48.420000 --> 0:00:53.620000
 So first things first, I want to clarify
 a couple of things regarding

0:00:53.620000 --> 0:00:57.400000
 the term I just used and the alternative.


0:00:57.400000 --> 0:01:03.660000
 So when we talk about first response
 or hot triage, we're pretty much

0:01:03.660000 --> 0:01:05.960000
 referring generally speaking
 to the same thing.

0:01:05.960000 --> 0:01:12.120000
 So let's just take a few steps back
 and go back to the core here.

0:01:12.120000 --> 0:01:18.200000
 So when an alert is escalated to the
 incident responder, the responder's

0:01:18.200000 --> 0:01:21.640000
 very first actions are
 called first response.

0:01:21.640000 --> 0:01:26.260000
 It's often called hot triage, which
 is why I have outlined both of them.

0:01:26.260000 --> 0:01:32.520000
 So whenever you see hot triage being used,
 generally speaking, it's referring

0:01:32.520000 --> 0:01:33.760000
 to first response.

0:01:33.760000 --> 0:01:37.580000
 But from my experience, I've typically
 seen first response being used

0:01:37.580000 --> 0:01:42.080000
 more often. So what is first
 response or hot triage?

0:01:42.080000 --> 0:01:48.900000
 Well, first response is a flash assessment
 phase that converts, this looks

0:01:48.900000 --> 0:01:51.520000
 bad into yes or no.

0:01:51.520000 --> 0:01:53.720000
 And what do we do in the next hour?

0:01:53.720000 --> 0:01:59.120000
 So you're essentially going from point
 of not knowing too much about what

0:01:59.120000 --> 0:02:08.780000
 you're dealing with you actually
 know what you're dealing with.

0:02:08.780000 --> 0:02:14.860000
 And the next question is, yes or no,
 and what do we do in the next hour?

0:02:14.860000 --> 0:02:17.780000
 So first response, this
 is sort of the key.

0:02:17.780000 --> 0:02:25.260000
 The reason why you have the word first
 included in this particular term

0:02:25.260000 --> 0:02:30.140000
 or process is because it is done first,
 but more importantly, it is done

0:02:30.140000 --> 0:02:35.060000
 long before disk images, memory forensics
 or boardroom briefings begin.

0:02:35.060000 --> 0:02:39.720000
 So you're talking about, as I mentioned,
 the very the very first, or I

0:02:39.720000 --> 0:02:41.080000
 should say the first five minutes.

0:02:41.080000 --> 0:02:44.720000
 Now, of course, I'm not saying that
 it's limited to five minutes, but

0:02:44.720000 --> 0:02:48.780000
 what the first actions or the
 first response actions are.

0:02:48.780000 --> 0:02:52.480000
 So that's what first response
 or hot triage is all about.

0:02:52.480000 --> 0:02:56.320000
 So again, based on what I've just said,
 you may be asking yourself, well,

0:02:56.320000 --> 0:03:00.420000
 okay, what is the purpose
 of first response?

0:03:00.420000 --> 0:03:02.940000
 Or does it have a methodology?

0:03:02.940000 --> 0:03:04.480000
 And that that's what I'm
 going to outline here.

0:03:04.480000 --> 0:03:10.200000
 So we have a table with two columns,
 the goal and why it matters.

0:03:10.200000 --> 0:03:14.840000
 So first things first, when we're talking
 about first response, you're

0:03:14.840000 --> 0:03:17.760000
 going to want to validate the alert,
 which is very important.

0:03:17.760000 --> 0:03:20.300000
 We spoke about this in
 the previous video.

0:03:20.300000 --> 0:03:25.860000
 So you want to eliminate false escalations
 or false positives before mobilizing

0:03:25.860000 --> 0:03:28.780000
 people or taking production,
 impacting action.

0:03:28.780000 --> 0:03:34.300000
 So what you're trying to do here is
 to verify what the SOCTIO1 analyst

0:03:34.300000 --> 0:03:39.280000
 communicated or escalated to you and
 ensure it's not a false positive,

0:03:39.280000 --> 0:03:42.400000
 because again, that's a possibility.

0:03:42.400000 --> 0:03:45.800000
 And the reason why this is important
 is because again, you don't want

0:03:45.800000 --> 0:03:49.680000
 to make any ad hoc decisions regarding
 taking down a particular system

0:03:49.680000 --> 0:03:55.260000
 under the guise of a ticket or case
 being legitimate out of the box.

0:03:55.260000 --> 0:04:04.740000
 It's very important that you verify
 and validate the volatile evidence

0:04:04.740000 --> 0:04:09.040000
 if that is pertinent, depending on
 the instant you're dealing with.

0:04:09.040000 --> 0:04:15.420000
 So think of things like live network
 connections, RAM artifacts and log

0:04:15.420000 --> 0:04:19.720000
 buffers. So you want to preserve
 those types of evidence.

0:04:19.720000 --> 0:04:23.460000
 And the reason why you want to preserve
 them is because they're generally

0:04:23.460000 --> 0:04:28.600000
 speaking of volatile and can be deleted
 or can be wiped within minutes

0:04:28.600000 --> 0:04:32.800000
 for a plethora of reasons, either by
 the intruder or the attacker, or

0:04:32.800000 --> 0:04:36.060000
 just on the basis of how they work.

0:04:36.060000 --> 0:04:38.280000
 So a good example would be RAM.

0:04:38.280000 --> 0:04:43.420000
 RAM is volatile, which means when you
 shut down a system, whatever artifacts

0:04:43.420000 --> 0:04:47.300000
 may have been within the RAM that could
 have told you more about the incident

0:04:47.300000 --> 0:04:52.800000
 are now gone. So once you've validated
 the alert or the incident, as it

0:04:52.800000 --> 0:04:55.760000
 were, you then move to preserve
 volatile evidence.

0:04:55.760000 --> 0:04:58.520000
 And then you move to estimate
 the scope and risk.

0:04:58.520000 --> 0:05:03.900000
 So you decide whether one host or an
 entire subnet or cloud tenants are

0:05:03.900000 --> 0:05:06.960000
 involved. So you're trying to understand
 exactly what you're dealing with

0:05:06.960000 --> 0:05:09.240000
 here in terms in terms of scope.

0:05:09.240000 --> 0:05:13.300000
 So is it just affecting is this incident
 pertinent to just one system?

0:05:13.300000 --> 0:05:14.960000
 Or is it, you know, broad?

0:05:14.960000 --> 0:05:19.100000
 And then you move to triggering
 rapid containment if required.

0:05:19.100000 --> 0:05:22.520000
 So it's not something that you're just
 going to do, you know, by default.

0:05:22.520000 --> 0:05:28.340000
 So the why this matters is because
 early host isolation or IP blocking

0:05:28.340000 --> 0:05:30.140000
 can stop data theft.

0:05:30.140000 --> 0:05:34.900000
 So exaltration or even detonation
 or execution of ransomware.

0:05:34.900000 --> 0:05:37.680000
 So first response is
 very, very important.

0:05:37.680000 --> 0:05:42.300000
 Now, you know, there's a lot more that
 you do after first response, but

0:05:42.300000 --> 0:05:46.280000
 this sort of sets the stage for, you
 know, deeper analysis as we'll be

0:05:46.280000 --> 0:05:47.880000
 exploring the next couple of videos.

0:05:47.880000 --> 0:05:58.800000
 So as I phrase, or a saying that pretty
 much infers that you should be

0:05:58.800000 --> 0:06:00.720000
 doing this quite rapidly.

0:06:00.720000 --> 0:06:04.120000
 So, you know, when we when we take a
 look at what the typical activities

0:06:04.120000 --> 0:06:09.080000
 are within first response or hot triage,
 you know, it generally it generally

0:06:09.080000 --> 0:06:11.100000
 ranges between two to 10 minutes.

0:06:11.100000 --> 0:06:14.220000
 So what are the typical activities here?

0:06:14.220000 --> 0:06:19.420000
 And you know, I'm now taking a much closer
 look at the operational activities.

0:06:19.420000 --> 0:06:22.420000
 So firstly, you have, you
 know, open an orient.

0:06:22.420000 --> 0:06:25.520000
 So this is where you open up the ticket
 or the case, you read the ticket

0:06:25.520000 --> 0:06:28.860000
 or the case or the information
 contained therein.

0:06:28.860000 --> 0:06:31.140000
 You take note of the asset criticality.

0:06:31.140000 --> 0:06:35.420000
 So is this a system or is this ticket
 pertinent to a system that is critical

0:06:35.420000 --> 0:06:39.000000
 in terms of business impact, etc.

0:06:39.000000 --> 0:06:41.320000
 You also take a look at the SLAs.

0:06:41.320000 --> 0:06:51.580000
 This is going to be clients, whatever,
 as well as any auto containment

0:06:51.580000 --> 0:06:54.740000
 that was already applied by
 the SOC tier one analyst.

0:06:54.740000 --> 0:06:58.960000
 If you remember in the previous video,
 I mentioned that that can be the

0:06:58.960000 --> 0:07:03.780000
 tier one analyst, you know, can
 do that where applicable.

0:07:03.780000 --> 0:07:08.460000
 You then have, you know, moving on from
 that again, this is going to be

0:07:08.460000 --> 0:07:10.540000
 depending on the type of incident
 you're dealing with.

0:07:10.540000 --> 0:07:15.460000
 But, you know, you, for example, if
 you're dealing with a C, you know,

0:07:15.460000 --> 0:07:18.460000
 you'll try and rerun the triggering
 query or the search with a slightly

0:07:18.460000 --> 0:07:26.540000
 wider time window to confirm it isn't
 a passing glitch or dev lab traffic.

0:07:26.540000 --> 0:07:32.720000
 So you're just trying to, again, ensure
 or verify that you can find, you

0:07:32.720000 --> 0:07:36.700000
 know, what is being referenced within
 the ticket using, you know, to like

0:07:36.700000 --> 0:07:38.520000
 a C, for example.

0:07:38.520000 --> 0:07:41.920000
 And then you have, you know,
 pivoting through logs.

0:07:41.920000 --> 0:07:45.580000
 And in this case, you know, you pivot
 once on the key IOC, whatever that

0:07:45.580000 --> 0:07:49.660000
 may be, it could be an IP address, it could
 be a hash, it could be a particular

0:07:49.660000 --> 0:07:53.980000
 user account. And you're doing this
 to spot obvious lateral movement or

0:07:53.980000 --> 0:07:57.960000
 lateral spread or, you know, repeated
 hits or repeated attacks.

0:07:57.960000 --> 0:08:01.600000
 You then move on to snapshot the volatile
 data, as I mentioned in the

0:08:01.600000 --> 0:08:04.620000
 previous slide. And that's if
 the host is still online.

0:08:04.620000 --> 0:08:09.300000
 We'll talk about, you know, live response
 versus dead box later on in

0:08:09.300000 --> 0:08:13.780000
 this section. But, you know, what this
 entails is a live memory or RAM

0:08:13.780000 --> 0:08:18.560000
 capture, you know, open file list,
 you know, check the current network

0:08:18.560000 --> 0:08:20.720000
 sockets, stuff like this.

0:08:20.720000 --> 0:08:22.480000
 And then this is very important.

0:08:22.480000 --> 0:08:25.480000
 You usually, you know, once you've gone
 through all of these phases, you'll

0:08:25.480000 --> 0:08:30.340000
 make a containment decision based on
 the, you know, the fact that you're

0:08:30.340000 --> 0:08:42.060000
 validated, but also learned more about
 the nature activities ongoing and

0:08:42.060000 --> 0:08:43.160000
 the risk is high.

0:08:43.160000 --> 0:08:47.400000
 Otherwise, you know, flag for
 coordinated containment later.

0:08:47.400000 --> 0:08:50.080000
 So you can say, okay, this is not so bad.


0:08:50.080000 --> 0:08:52.480000
 I don't need, we don't need
 to do anything right now.

0:08:52.480000 --> 0:08:55.960000
 Or maybe if not completed your analysis,
 which will then take us to deep

0:08:55.960000 --> 0:09:01.380000
 analysis or full analysis as it were,
 where you then, you know, try and

0:09:01.380000 --> 0:09:02.220000
 understand the scope.

0:09:02.220000 --> 0:09:06.240000
 Because remember, containment eradication
 and recovery requires or depends

0:09:06.240000 --> 0:09:09.680000
 on thorough analysis.

0:09:09.680000 --> 0:09:12.320000
 And then finally, you have
 document and notify.

0:09:12.320000 --> 0:09:16.800000
 So, you know, just one or two clear lines
 in the case record, plus a ping

0:09:16.800000 --> 0:09:19.080000
 to the shift lead or asset owner.

0:09:19.080000 --> 0:09:22.180000
 Again, that's going to be dependent on
 the organization that you're working

0:09:22.180000 --> 0:09:30.600000
 for. And that brings us to, you know,
 how first response differs from

0:09:30.600000 --> 0:09:33.620000
 deep analysis. And don't worry if you
 don't, if you don't know what deep

0:09:33.620000 --> 0:09:40.020000
 analysis is, first response.

0:09:40.020000 --> 0:09:43.500000
 So on the left, you have hot triage
 of first response on the right, you

0:09:43.500000 --> 0:09:44.600000
 have full or deep analysis.

0:09:44.600000 --> 0:09:48.480000
 So when we talk about first response,
 this is usually two to 10 minutes,

0:09:48.480000 --> 0:09:51.300000
 of course, it can, it can
 be a bit more than that.

0:09:51.300000 --> 0:09:55.240000
 But when we when we talk about full or
 deep analysis, this can, you know,

0:09:55.240000 --> 0:10:00.160000
 range anywhere from, you know, a couple
 of minutes to hours and really

0:10:00.160000 --> 0:10:05.560000
 days. In the case of first response,
 it's high level scoping.

0:10:05.560000 --> 0:10:09.520000
 So you're, you know, trying to stop
 the bleed, you know, stop the bleed

0:10:09.520000 --> 0:10:12.480000
 decisions. This is what
 you're involved with.

0:10:12.480000 --> 0:10:16.840000
 So, you know, very, it's, it's pretty
 much what a first responder does.

0:10:16.840000 --> 0:10:20.000000
 And you know, the decisions
 that they have to make.

0:10:20.000000 --> 0:10:25.180000
 And if you hold on to that particular
 analogy or example, it will start

0:10:25.180000 --> 0:10:29.140000
 to make sense. In the case of full
 or deep analysis, you know, this is

0:10:29.140000 --> 0:10:32.640000
 where you're performing deep host or
 endpoint and network analysis and

0:10:32.640000 --> 0:10:38.920000
 forensics. You're trying to determine the
 root cause and the impact quantification.

0:10:38.920000 --> 0:10:42.620000
 In the case of hot triage of first
 response, you know, this is fairly

0:10:42.620000 --> 0:10:46.720000
 limited and you're pretty much relying
 on fast queries and live response

0:10:46.720000 --> 0:10:49.800000
 tools. So you're moving
 really quick, right?

0:10:49.800000 --> 0:10:53.020000
 And that doesn't mean that you,
 you know, you're careless.

0:10:53.020000 --> 0:10:56.080000
 That's why they're playbooks
 and all of that good stuff.

0:10:56.080000 --> 0:11:01.140000
 And a lot of first response can actually
 be automated with sore and stuff

0:11:01.140000 --> 0:11:05.380000
 like this. But I don't want to confuse
 you with that because you need

0:11:05.380000 --> 0:11:09.620000
 to know how to do it manually before you
 move into scripting and automation.

0:11:09.620000 --> 0:11:12.640000
 In the case of full or deep analysis,
 you know, this is where you have

0:11:12.640000 --> 0:11:18.400000
 full seem pivots, memory and disk imaging,
 malware analysis, reverse engineering,

0:11:18.400000 --> 0:11:20.580000
 all that good stuff.

0:11:20.580000 --> 0:11:24.900000
 And then hot triage of first response,
 who is responsible for this?

0:11:24.900000 --> 0:11:28.720000
 This is typically executed or performed
 by the on called responder, the

0:11:28.720000 --> 0:11:32.040000
 instant responder that's currently
 available or active, right?

0:11:32.040000 --> 0:11:38.740000
 In the case of full or deep analysis
 that you'll be performing, you know,

0:11:38.740000 --> 0:11:42.760000
 this may involve the entire IR team,
 specialists, management, so on and

0:11:42.760000 --> 0:11:47.400000
 so forth. So, you know, hot triage of
 first response, you're dealing with

0:11:47.400000 --> 0:11:52.700000
 the incident, you know, in the beginning
 or immediately the moment you

0:11:52.700000 --> 0:11:56.940000
 receive it or you're notified of it,
 full or deep analysis is the stuff

0:11:56.940000 --> 0:11:58.260000
 you do after that.

0:11:58.260000 --> 0:12:01.360000
 And I've sort of explained the differences
 between the two here.

0:12:01.360000 --> 0:12:04.540000
 So that brings us to the
 key question here.

0:12:04.540000 --> 0:12:09.380000
 And what are the outcomes or outputs
 of first response for yourself for

0:12:09.380000 --> 0:12:13.140000
 the organization as a whole, but also,
 you know, in terms of the next

0:12:13.140000 --> 0:12:18.400000
 steps. Well, firstly, you know, the
 first output or outcome will be a

0:12:18.400000 --> 0:12:19.900000
 validation statement.

0:12:19.900000 --> 0:12:25.120000
 So you're confirming, you know, that
 the instant is actually real.

0:12:25.120000 --> 0:12:28.240000
 An example would be, you know, confirmed
 malicious PowerShell execution

0:12:28.240000 --> 0:12:37.280000
 on the following Secondly,
 preliminary scope.

0:12:37.280000 --> 0:12:42.640000
 So you have an idea of you have a preliminary
 idea of what the scope is.

0:12:42.640000 --> 0:12:46.980000
 So that would include affected hosts,
 users, and the earliest timestamp.

0:12:46.980000 --> 0:12:52.040000
 So you have an indication as to when
 this incident started, you know,

0:12:52.040000 --> 0:12:55.520000
 and of course, this is going to be
 limited by how much data you can go

0:12:55.520000 --> 0:12:59.440000
 through in the first five to, you know,
 15 minutes, but you should have

0:12:59.440000 --> 0:13:02.660000
 a good idea of, you know, the, you
 know, you should have a preliminary

0:13:02.660000 --> 0:13:07.520000
 scope. And then the other output
 would be immediate actions taken.

0:13:07.520000 --> 0:13:10.580000
 So what immediate actions did you take?

0:13:10.580000 --> 0:13:16.740000
 So for example, isolation, firewall blocks,
 or a password reset, and then

0:13:16.740000 --> 0:13:18.060000
 you update the ticket.

0:13:18.060000 --> 0:13:19.780000
 So this is very important.

0:13:19.780000 --> 0:13:23.180000
 And again, you got an idea of what that
 was like in the previous course,

0:13:23.180000 --> 0:13:34.020000
 when we took a look at the first response,
 or hot triage, or, you know,

0:13:34.020000 --> 0:13:39.280000
 deeper analysis, you're constantly
 updating the ticket with, you know,

0:13:39.280000 --> 0:13:44.180000
 evidence snippets and the next step
 for detailed analysis, or, you know,

0:13:44.180000 --> 0:13:48.600000
 as you're performing detailed analysis,
 you'd put in your ROCs and anything

0:13:48.600000 --> 0:13:52.140000
 new that you're finding and constantly
 updated, because that allows you

0:13:52.140000 --> 0:13:56.800000
 to also build your timeline, your
 reports, all that good stuff.

0:13:56.800000 --> 0:14:03.640000
 So that brings us now to, you know,
 if we take a look at the first five

0:14:03.640000 --> 0:14:08.160000
 minutes or first response in general,
 you may have been asking yourself,

0:14:08.160000 --> 0:14:12.060000
 well, could you give us, you know, could
 you give me a checklist or something

0:14:12.060000 --> 0:14:17.660000
 that I can use that makes this actionable
 or makes those steps or procedures

0:14:17.660000 --> 0:14:19.380000
 a little bit actionable?

0:14:19.380000 --> 0:14:22.760000
 And that's exactly what we're going
 to be taking a look at right now.

0:14:22.760000 --> 0:14:26.620000
 So here I have a rapid instant
 validation checklist.

0:14:26.620000 --> 0:14:29.340000
 This is for instant validation.

0:14:29.340000 --> 0:14:31.480000
 So let's get started.

0:14:31.480000 --> 0:14:36.120000
 So the clock starts the instant an escalated
 alert hits your queue, right?

0:14:36.120000 --> 0:14:40.220000
 And the first five minutes decide whether
 you contain a breach or whether

0:14:40.220000 --> 0:14:44.900000
 you contain a breach quickly or waste
 time on a false alarm or a false

0:14:44.900000 --> 0:14:46.340000
 positive, right?

0:14:46.340000 --> 0:14:51.480000
 Now the next slide, the one after this
 contains a compact rapid instant

0:14:51.480000 --> 0:14:55.740000
 validation checklist that can be used
 every time you take ownership of

0:14:55.740000 --> 0:14:56.740000
 a new case, right?

0:14:56.740000 --> 0:15:02.860000
 It can be used for, again, as the title
 suggests, rapid incident validation.

0:15:02.860000 --> 0:15:04.440000
 So this is the checklist here.

0:15:04.440000 --> 0:15:06.180000
 This is something that I developed.

0:15:06.180000 --> 0:15:10.540000
 Of course, I've sort of incorporated
 my experience or what I've learned

0:15:10.540000 --> 0:15:16.160000
 when I did work as an instant responder
 and sort of updated it to sort

0:15:16.160000 --> 0:15:21.400000
 of align with the ones you typically
 see being used, you know, even an

0:15:21.400000 --> 0:15:25.300000
 automated way or even, you
 know, manually documented.

0:15:25.300000 --> 0:15:28.920000
 So again, minute one, sorry,
 minute zero to one.

0:15:28.920000 --> 0:15:31.100000
 This is where you open
 and orient yourself.

0:15:31.100000 --> 0:15:33.460000
 So what are the actions
 you're taking here?

0:15:33.460000 --> 0:15:34.800000
 You acknowledge the ticket.

0:15:34.800000 --> 0:15:35.700000
 That's very important.

0:15:35.700000 --> 0:15:38.040000
 You acknowledge that you're
 you've received it.

0:15:38.040000 --> 0:15:41.740000
 You then read the tier one summary
 or the summary provided within the

0:15:41.740000 --> 0:15:43.160000
 ticket or the case.

0:15:43.160000 --> 0:15:46.680000
 This would be, you know, involve or would
 be specific to, you know, things

0:15:46.680000 --> 0:15:52.100000
 like the rule name, severity host or user
 affected and any auto containment

0:15:52.100000 --> 0:15:56.940000
 that was applied by the
 tier one analyst, right?

0:15:56.940000 --> 0:16:02.900000
 And then you have your, you should
 also take note of the SLA deadline.

0:16:02.900000 --> 0:16:09.320000
 And the purpose for this, you know,
 for, you know, this particular phase

0:16:09.320000 --> 0:16:16.040000
 or step is to avoid duplicating work
 and to get an idea of what triage,

0:16:16.040000 --> 0:16:22.900000
 you know, already handled in terms of
 what the software one analyst did

0:16:22.900000 --> 0:16:25.040000
 before they escalated it to you.

0:16:25.040000 --> 0:16:28.040000
 You then have minute one to two.

0:16:28.040000 --> 0:16:32.520000
 So this is where you perform a
 rerun and broaden your search.

0:16:32.520000 --> 0:16:37.160000
 So you, the actions here would be you
 re execute the original SIM query.

0:16:37.160000 --> 0:16:40.100000
 And you sort of expand the
 time, the timeframe.

0:16:40.100000 --> 0:16:47.200000
 So plus five minutes is generally speaking,
 the, the duration that you'd

0:16:47.200000 --> 0:16:48.240000
 go for to begin with.

0:16:48.240000 --> 0:16:52.320000
 And then you inspect raw events for
 passing errors or test traffic.

0:16:52.320000 --> 0:16:56.980000
 So you're just trying to ensure that,
 you know, this isn't a false positive.

0:16:56.980000 --> 0:17:00.520000
 So the purpose as listed there
 confirmed the alert is real.

0:17:00.520000 --> 0:17:03.820000
 So eliminate false escalation
 or false positives.

0:17:03.820000 --> 0:17:07.780000
 And then minutes two to three, this is
 where you, you know, scope snapshot.

0:17:07.780000 --> 0:17:13.500000
 So you try and understand again, not
 in its entirety, but what you're

0:17:13.500000 --> 0:17:17.840000
 dealing with in terms of the initial
 blast radius or the scope.

0:17:17.840000 --> 0:17:22.700000
 And this is also very useful in identifying,
 you know, lateral movement

0:17:22.700000 --> 0:17:27.520000
 early. So the actions you take here
 are, you know, pivot on IOCs like

0:17:27.520000 --> 0:17:31.360000
 IPs, hashes, users, etc.

0:17:31.360000 --> 0:17:35.380000
 And the questions you're asking yourself
 here really are who else and

0:17:35.380000 --> 0:17:40.980000
 where else. So who else affected who else
 is, you know, within the network,

0:17:40.980000 --> 0:17:44.940000
 stuff like this, where else, what
 other systems are being affected.

0:17:44.940000 --> 0:17:51.160000
 You're just trying to understand the
 scope of what you're also take is

0:17:51.160000 --> 0:17:55.040000
 to check the asset criticality and prior
 alerts on the entity to see whether

0:17:55.040000 --> 0:17:59.820000
 again, to have a historical background
 or understanding of this particular

0:17:59.820000 --> 0:18:07.200000
 asset, what type of alerts, you know,
 it's been associated with previously.

0:18:07.200000 --> 0:18:12.140000
 And you know, more importantly, the
 criticality of the, the asset.

0:18:12.140000 --> 0:18:16.440000
 And then minutes three to four, you have
 containment, a containment decision.

0:18:16.440000 --> 0:18:20.880000
 So the actions you take here are to,
 you know, isolate the host or block,

0:18:20.880000 --> 0:18:25.940000
 you know, IOC if beakening
 or impact is active.

0:18:25.940000 --> 0:18:29.960000
 Otherwise, you'd flag, you'd flag it
 as, you know, containment pending

0:18:29.960000 --> 0:18:32.600000
 for a later plan.

0:18:32.600000 --> 0:18:36.660000
 Or if you plan on having a containment
 done after you've performed deeper

0:18:36.660000 --> 0:18:42.080000
 analysis. And the purpose for this
 is to prevent ongoing damage while

0:18:42.080000 --> 0:18:49.100000
 keeping, you know, by the way, I'm not
 saying you have to adhere to just

0:18:49.100000 --> 0:18:52.860000
 five minutes. This is sort of giving
 you an idea of how much time you

0:18:52.860000 --> 0:18:56.040000
 should be spending, you know, generally,
 you can also, you know, break

0:18:56.040000 --> 0:19:02.000000
 this down into an hour and change the
 unit of one to 10 minutes or whatever.

0:19:02.000000 --> 0:19:07.020000
 But the idea is to show you that, you
 know, within five, 10, 15, maybe

0:19:07.020000 --> 0:19:10.640000
 maximum of 20 minutes, this is
 what you should be focused on.

0:19:10.640000 --> 0:19:15.920000
 So when we talk about the fourth and
 the fifth minutes, this is where

0:19:15.920000 --> 0:19:20.340000
 you are documentation and notification.

0:19:20.340000 --> 0:19:23.840000
 So the actions you would be taking here
 are, you know, things like adding

0:19:23.840000 --> 0:19:28.700000
 a concise note, like, you know, validation
 result, the scope, action taken,

0:19:28.700000 --> 0:19:34.180000
 keeping the ticket updated or the case
 updated, your attachable evidence

0:19:34.180000 --> 0:19:39.460000
 that you found again, just within
 the confines of first response.

0:19:39.460000 --> 0:19:45.260000
 And then your alert stakeholders,
 if applicable or required, right?

0:19:45.260000 --> 0:19:48.800000
 And the purpose for this is fairly obvious,
 you're creating an audit trail

0:19:48.800000 --> 0:19:52.700000
 and outlining what you did when you
 did it, how you did it, so on and

0:19:52.700000 --> 0:19:57.320000
 so forth. And this keeps the team synced.


0:19:57.320000 --> 0:20:03.700000
 And it starts the, you know, MTTR counters
 or minimum time to respond,

0:20:03.700000 --> 0:20:07.300000
 which is something quite
 important as you'll see.

0:20:07.300000 --> 0:20:11.600000
 So now to sort of explain, or, you know,
 to tie everything together, I'm

0:20:11.600000 --> 0:20:16.160000
 going to use an example scenario that
 illustrates what first response

0:20:16.160000 --> 0:20:21.580000
 would look like, you know, using
 sort of a realistic incident.

0:20:21.580000 --> 0:20:28.120000
 So in this particular case,
 this is the starting point.

0:20:28.120000 --> 0:20:32.300000
 So they feel just bear with me as
 we go through the example here.

0:20:32.300000 --> 0:20:38.120000
 So just imagine, you
 know, so at 2 17 a.m.

0:20:38.120000 --> 0:20:43.080000
 on Friday, the socks paging system
 or the seem flags are high severity

0:20:43.080000 --> 0:20:48.100000
 alert. And this is what information,
 you know, they're able to deduce

0:20:48.100000 --> 0:20:54.500000
 or now bound PowerShell script on the
 host or system Fin app server one,

0:20:54.500000 --> 0:20:57.780000
 which is a finance server, as you could
 probably have deduced from its

0:20:57.780000 --> 0:21:02.860000
 host name, contacted this external
 IP address and upon initial triage

0:21:02.860000 --> 0:21:05.460000
 performed by the sock tier one analyst.

0:21:05.460000 --> 0:21:11.640000
 The IPs tied to the APT 29 infrastructure
 seen in recent threat intelligence

0:21:11.640000 --> 0:21:16.960000
 feeds. So a tier one analyst has already
 triaged the alert, judged it

0:21:16.960000 --> 0:21:22.340000
 credible and escalated the ticket to
 you, the on call instant responder.

0:21:22.340000 --> 0:21:24.400000
 Oh, exciting times ahead.

0:21:24.400000 --> 0:21:29.880000
 So if we're to use the, you know, the
 checklist that I outlined previously

0:21:29.880000 --> 0:21:33.500000
 for first response, we start
 with the first step.

0:21:33.500000 --> 0:21:36.920000
 So acknowledge and orient so minute
 zero to one, you open the ticket in

0:21:36.920000 --> 0:21:39.940000
 the IR platform that your
 organization uses.

0:21:39.940000 --> 0:21:42.900000
 Examples would be the
 hive or service now.

0:21:42.900000 --> 0:21:45.100000
 You skim the triage summary.

0:21:45.100000 --> 0:21:48.420000
 What you're looking at is a rule name,
 severity affected host timestamp

0:21:48.420000 --> 0:21:51.380000
 and any automatic containment.

0:21:51.380000 --> 0:22:01.840000
 You know, for you do this to prevent,
 as I mentioned, duplicate work and

0:22:01.840000 --> 0:22:06.260000
 ensure you know what tier one already
 did in terms of the triage.

0:22:06.260000 --> 0:22:09.880000
 You then have step two, which
 is quick validation.

0:22:09.880000 --> 0:22:12.960000
 So one to two minutes, of course,
 it can take longer.

0:22:12.960000 --> 0:22:17.280000
 This is not something you have to adhere
 by, but this is where you rerun

0:22:17.280000 --> 0:22:21.600000
 the triggering CM query, but you widen
 the window to plus five minutes.

0:22:21.600000 --> 0:22:26.400000
 This is an example of
 a Splunk SP SPL query.

0:22:26.400000 --> 0:22:27.980000
 And it's tied to the example.

0:22:27.980000 --> 0:22:33.880000
 So you can see I've selected the index
 as OS win, assuming that in the

0:22:33.880000 --> 0:22:37.560000
 case of this organization, the index that
 they're using for Windows endpoints

0:22:37.560000 --> 0:22:39.860000
 is called OS win.

0:22:39.860000 --> 0:22:46.660000
 The host field is specified there and
 then process name, PowerShell.exe

0:22:46.660000 --> 0:22:50.740000
 is a very good filtering and then some
 additional fine tuning, where we

0:22:50.740000 --> 0:22:56.260000
 say search command line for inclusion
 of the following IP to see whether

0:22:56.260000 --> 0:23:01.380000
 there've been any logs associated with
 any, you know, PowerShell execution

0:23:01.380000 --> 0:23:04.340000
 events that included that
 as command line arguments.

0:23:04.340000 --> 0:23:08.720000
 And then, you know, table time user
 command line parent process.

0:23:08.720000 --> 0:23:13.140000
 So what's going on here is you're confirmed
 that the event is not a passing

0:23:13.140000 --> 0:23:17.560000
 glitch, test traffic or sandbox detonation
 of, you know, malware or a

0:23:17.560000 --> 0:23:19.820000
 new tool or something like this.

0:23:19.820000 --> 0:23:21.240000
 And why do you do this?

0:23:21.240000 --> 0:23:21.940000
 It's fairly obvious.

0:23:21.940000 --> 0:23:25.740000
 You want to catch any false escalation
 or false positives before you burn

0:23:25.740000 --> 0:23:30.360000
 more hours or waste more time, or,
 you know, scare everyone within the

0:23:30.360000 --> 0:23:35.460000
 organization. So you need to verify
 that what was escalated to you is

0:23:35.460000 --> 0:23:36.320000
 indeed an incident.

0:23:36.320000 --> 0:23:40.020000
 And that may seem like, again, duplication
 of effort, but it's something

0:23:40.020000 --> 0:23:41.860000
 that you need to do and trust me.

0:23:41.860000 --> 0:23:45.800000
 There'll be many times where, you know,
 you'll actually perform the, you

0:23:45.800000 --> 0:23:50.520000
 know, initial validation or valid, you'll
 try and validate the incident.

0:23:50.520000 --> 0:23:54.600000
 And it's not, you know, it's probably
 not going to be as serious as you

0:23:54.600000 --> 0:23:58.800000
 thought, or maybe someone, a system
 administrator is playing around with

0:23:58.800000 --> 0:24:02.360000
 a couple of PowerShell scripts, at
 least in the case of this example.

0:24:02.360000 --> 0:24:05.780000
 In any case, step three, scope snapshot.

0:24:05.780000 --> 0:24:07.340000
 So minutes two to three.

0:24:07.340000 --> 0:24:12.560000
 So you pivot on IOCs like the hash
 user and IP to see if a other host

0:24:12.560000 --> 0:24:16.580000
 contacted the same IP, trying to
 understand the scope, right?

0:24:16.580000 --> 0:24:19.860000
 And the same PowerShell
 hash ran elsewhere.

0:24:19.860000 --> 0:24:22.140000
 So very, very cool.

0:24:22.140000 --> 0:24:24.020000
 Or very, very important.

0:24:24.020000 --> 0:24:26.760000
 Sorry. You're also checking
 asset criticality.

0:24:26.760000 --> 0:24:30.300000
 So in this case, we know it's a finance
 server, which means it's a crown

0:24:30.300000 --> 0:24:33.160000
 jewel, or it's a critical system.

0:24:33.160000 --> 0:24:37.180000
 And what that means is
 potential high impact.

0:24:37.180000 --> 0:24:42.640000
 So you're another, you know, another
 thing you do here, or at least in

0:24:42.640000 --> 0:24:48.100000
 the case of this example is note whether
 the, in this case, the finance

0:24:48.100000 --> 0:24:51.960000
 server shows other alerts
 in the last 24 hours.

0:24:51.960000 --> 0:24:57.360000
 And why is this important, this
 particular step or phase?

0:24:57.360000 --> 0:25:01.020000
 Well, you're trying to decide if this
 is isolated or already lateral in

0:25:01.020000 --> 0:25:04.280000
 that the threat is now moving
 on to other systems, right?

0:25:04.280000 --> 0:25:08.840000
 And the reason this is important is
 because this will guide the breadth

0:25:08.840000 --> 0:25:12.320000
 of containment eradication
 and even recovery efforts.

0:25:12.320000 --> 0:25:15.760000
 Because again, if you just go by the
 assumption that it's only affected

0:25:15.760000 --> 0:25:24.580000
 one system, and you don't try and check
 whether, you know, the IOCs, if

0:25:24.580000 --> 0:25:29.000000
 you don't try and search for whether
 the IOCs are present in logs that

0:25:29.000000 --> 0:25:32.540000
 are specific to other systems, then
 you're just going to assume it's one

0:25:32.540000 --> 0:25:37.640000
 system and you need to identify the whole
 map or the entire scope of what

0:25:37.640000 --> 0:25:39.140000
 you're dealing with.

0:25:39.140000 --> 0:25:43.280000
 You then have step four initial containment
 decisions or minute three

0:25:43.280000 --> 0:25:46.980000
 to four. So if the if the service is still
 beakening, you know, you trigger

0:25:46.980000 --> 0:25:52.560000
 EDR to isolate, you trigger EDR isolate
 host or firewall block on the

0:25:52.560000 --> 0:25:57.760000
 IP, if beaconing stopped and, you know,
 business risk of isolation is

0:25:57.760000 --> 0:26:03.760000
 high, plan a you plan deferred containment
 but start paperwork.

0:26:03.760000 --> 0:26:08.200000
 So this is in the case of systems that
 are, you know, business critical.

0:26:08.200000 --> 0:26:14.940000
 And, you know, one, you know, let's say
 when we're talking about containment,

0:26:14.940000 --> 0:26:20.020000
 if you sort of decided that you needed
 to take it down, well, again, if

0:26:20.020000 --> 0:26:25.860000
 this is a business critical server or
 endpoint, and, you know, the business

0:26:25.860000 --> 0:26:31.760000
 risk of isolation is high or containment
 as it were, then you can sort

0:26:31.760000 --> 0:26:37.720000
 of defer containment, but start paperwork,
 you know, as stated here.

0:26:37.720000 --> 0:26:39.300000
 So why is this important?

0:26:39.300000 --> 0:26:43.520000
 Well, for, you know, fairly obvious
 reasons, early action can stop data

0:26:43.520000 --> 0:26:46.000000
 theft or second stage payloads.

0:26:46.000000 --> 0:26:50.500000
 You then have step five, which is
 documentation and communication.

0:26:50.500000 --> 0:26:53.960000
 So when it's four to five, so, you
 know, you add a concise note to the

0:26:53.960000 --> 0:26:58.160000
 ticket or you update the case saying
 validated, I validated malicious

0:26:58.160000 --> 0:27:03.560000
 PowerShell downloads from the following
 external IP on the finance server.

0:27:03.560000 --> 0:27:05.800000
 No other hosts contacted the IP.

0:27:05.800000 --> 0:27:08.580000
 The host is isolated via CrowdStrike.

0:27:08.580000 --> 0:27:11.920000
 The next step is to perform
 deep analysis.

0:27:11.920000 --> 0:27:14.400000
 So memory capture and persistence check.

0:27:14.400000 --> 0:27:20.180000
 And you then page the finance IT contact
 if isolation may disrupt services.

0:27:20.180000 --> 0:27:24.480000
 And you attach a raw event JSON, for
 example, and your expanded search

0:27:24.480000 --> 0:27:29.060000
 results. So you essentially provide
 proof of your determination, then

0:27:29.060000 --> 0:27:32.560000
 the fact that, you know, you said no
 other hosts contacted the IP, you

0:27:32.560000 --> 0:27:34.540000
 need to provide some proof of this.

0:27:34.540000 --> 0:27:37.980000
 And why is this important for you at
 least because it creates a clear

0:27:37.980000 --> 0:27:41.760000
 audit trail and keeps
 stakeholders informed.

0:27:41.760000 --> 0:27:44.760000
 And finally, what happens next?

0:27:44.760000 --> 0:27:49.340000
 So with the incident validated and initial
 scope defined, you transition

0:27:49.340000 --> 0:27:53.500000
 into deeper analysis, which, you know,
 examples of that would be memory

0:27:53.500000 --> 0:27:59.980000
 dumps, disk triage, persistence, hunting,
 and enterprise wide IOC sweeps.

0:27:59.980000 --> 0:28:04.700000
 But the key point here is that those first
 five minutes that involve acknowledging,

0:28:04.700000 --> 0:28:09.820000
 validating, scoping, containing and
 documenting, set the foundation for

0:28:09.820000 --> 0:28:14.320000
 every decision you and the wider
 IR team will make from here on.

0:28:14.320000 --> 0:28:16.520000
 So very, very important.

0:28:16.520000 --> 0:28:21.880000
 Okay, so that was first response,
 the first five minutes.

0:28:21.880000 --> 0:28:26.180000
 And hopefully, you now have a better idea
 of what you're going to be required

0:28:26.180000 --> 0:28:33.720000
 to do when you're asked to, you know,
 investigate or analyze, you know,

0:28:33.720000 --> 0:28:35.980000
 an incident or respond to an incident.

0:28:35.980000 --> 0:28:39.540000
 Now that you have an idea of what the
 first five minutes are like, and

0:28:39.540000 --> 0:28:45.740000
 of course, remember, five minutes just
 infers are not explicitly implicitly

0:28:45.740000 --> 0:28:50.320000
 infers that it needs to be done
 or is done relatively quickly.

0:28:50.320000 --> 0:28:54.600000
 So now that you have an idea of what
 that is like, what is all about,

0:28:54.600000 --> 0:28:58.300000
 what you're required to do, what the
 inputs are, what the outputs are,

0:28:58.300000 --> 0:29:03.400000
 we can now turn our attention to, you know,
 deep analysis or deeper analysis.

0:29:03.400000 --> 0:29:07.040000
 That's a term that I sort of
 coined, not coined myself.

0:29:07.040000 --> 0:29:10.240000
 That's what I refer to it as, because
 again, if you sort of convolute

0:29:10.240000 --> 0:29:17.540000
 analysis is just one homogeneous activity,
 you don't really, it doesn't

0:29:17.540000 --> 0:29:24.260000
 really bode well for your understanding
 and where to draw those demarcation

0:29:24.260000 --> 0:29:27.460000
 lines conceptually, but also practically.


0:29:27.460000 --> 0:29:32.620000
 So if you can start to, you know, make
 these segregations or organize

0:29:32.620000 --> 0:29:37.280000
 the process in your head, then implementation
 of whatever actions pertinent

0:29:37.280000 --> 0:29:42.760000
 to the, these processes, you know, implementation
 will become much easier.

0:29:42.760000 --> 0:29:45.880000
 In any case, that's going
 to be it for this video.

0:29:45.880000 --> 0:29:48.260000
 And I will be seeing you
 in the next video.