WEBVTT 0:00:03.560000 --> 0:00:08.140000 From logs to incidents, the triage process. 0:00:08.140000 --> 0:00:13.560000 So welcome everyone to the next section of this course or I should say 0:00:13.560000 --> 0:00:19.860000 the alert triage and escalation section of this course where we're now 0:00:19.860000 --> 0:00:30.200000 going to be exploring as the name of this course. 0:00:30.200000 --> 0:00:37.180000 And we'll also talk about escalation and various aspects of the triage 0:00:37.180000 --> 0:00:41.680000 process like IOC, IOC enrichment, etc. 0:00:41.680000 --> 0:00:47.400000 But to begin with, we are starting off with the triage process. 0:00:47.400000 --> 0:00:51.880000 So the objective here is to understand what triage is or what we're referring 0:00:51.880000 --> 0:00:54.820000 to when we're talking about triage in relation to this course. 0:00:54.820000 --> 0:01:00.460000 Now, I've outlined the triage process many times in the previous two courses 0:01:00.460000 --> 0:01:02.580000 within this learning path. 0:01:02.580000 --> 0:01:07.240000 But now we're again going to be recontextualizing it and sort of explaining 0:01:07.240000 --> 0:01:11.460000 or giving you a better idea of what this means for you as an incident 0:01:11.460000 --> 0:01:17.340000 responder. So based on the structure of the course up to this point, as 0:01:17.340000 --> 0:01:21.800000 I mentioned many times within this course, the idea was to give you an 0:01:21.800000 --> 0:01:26.660000 understanding of the starting point. 0:01:26.660000 --> 0:01:32.280000 So the logging process, what logs are, how they're collected, shipped 0:01:32.280000 --> 0:01:38.840000 and then aggregated and then how they can be analyzed using a seam. 0:01:38.840000 --> 0:01:42.560000 And then we talked about detection engineering to a certain extent where 0:01:42.560000 --> 0:01:47.140000 you've gotten an understanding of how you go from just ingesting logs 0:01:47.140000 --> 0:01:51.960000 into a seam to actually building, let's say searches or detection rules 0:01:51.960000 --> 0:01:54.800000 to detect malicious activity. 0:01:54.800000 --> 0:01:58.900000 And we're now touching, we're now going to be exploring the triage process. 0:01:58.900000 --> 0:02:05.720000 So how you go from a log to an incident and in between you have the event 0:02:05.720000 --> 0:02:07.900000 and alerts on and so forth. 0:02:07.900000 --> 0:02:11.940000 So it's now going to be sort of coming full circle. 0:02:11.940000 --> 0:02:16.320000 And by the end of this section, we'll be at the point that you as an incident 0:02:16.320000 --> 0:02:21.060000 responder will, you know, that's where you'll be coming into play in terms 0:02:21.060000 --> 0:02:29.580000 of analysis. So when the tier one analyst escalates, you know, escalates 0:02:29.580000 --> 0:02:33.440000 an incident to you for investigation, that's, you know, what we'll be 0:02:33.440000 --> 0:02:35.360000 exploring from the next section onwards. 0:02:35.360000 --> 0:02:41.300000 But we need to understand how, you know, a log goes from being a log, 0:02:41.300000 --> 0:02:46.420000 you know, to being an event, to being an alert and consequently an incident, 0:02:46.420000 --> 0:02:51.260000 you know, and at which point you get involved. 0:02:51.260000 --> 0:02:54.120000 But understanding this process is very important. 0:02:54.120000 --> 0:02:58.040000 In any case, let me give you a formal introduction to this section of 0:02:58.040000 --> 0:03:02.460000 the course, which is titled triage and escalation. 0:03:02.460000 --> 0:03:07.000000 So to sort of resummarize what I said, now that you've mastered the building 0:03:07.000000 --> 0:03:11.540000 blocks of detection, you know, you know, that being how logs are generated, 0:03:11.540000 --> 0:03:15.960000 collected, shipped and normalized, as well as how they are hunted or searched 0:03:15.960000 --> 0:03:18.000000 for within a seam. 0:03:18.000000 --> 0:03:22.240000 Plus the fundamentals of writing detection rules, the next logical milestone 0:03:22.240000 --> 0:03:27.860000 or step is understanding what happens once detection rules are triggered. 0:03:27.860000 --> 0:03:32.040000 And in this video specifically, we'll shift our focus from technology 0:03:32.040000 --> 0:03:37.220000 to workflow and, you know, process in general whereby you learn how a 0:03:37.220000 --> 0:03:43.860000 raw log that matches a specific rule is transformed into an alert, you 0:03:43.860000 --> 0:03:48.880000 know, how tier one analysts triage and enrich that alert and how a fully 0:03:48.880000 --> 0:03:53.640000 scoped incident is packaged and handed off to the incident responder with 0:03:53.640000 --> 0:03:57.540000 the evidence and context needed for rapid action, which is very important 0:03:57.540000 --> 0:03:59.300000 for you to understand. 0:03:59.300000 --> 0:04:03.300000 Now, that brings us to the final point here grasping this triage pipeline 0:04:03.300000 --> 0:04:07.580000 bridges the gap between detection, engineering and incident response, 0:04:07.580000 --> 0:04:11.540000 showing you how the pieces you've already learned come together to protect, 0:04:11.540000 --> 0:04:14.460000 you know, the organization in real time. 0:04:14.460000 --> 0:04:18.320000 And in this section of the course, again, titled triage and escalation, 0:04:18.320000 --> 0:04:22.520000 you learn how raw machine generated alerts are transformed into actionable, 0:04:22.520000 --> 0:04:27.460000 well scoped incidents or cases or tickets, whatever you want to call them. 0:04:27.460000 --> 0:04:31.180000 That incident responders can immediately analyze or investigate. 0:04:31.180000 --> 0:04:34.700000 So by the end of this particular section of the course, you'll have an 0:04:34.700000 --> 0:04:38.700000 understanding of number one, the end to end process or workflow of how 0:04:38.700000 --> 0:04:44.360000 logs become alerts and how alerts become incidents. 0:04:44.360000 --> 0:04:49.040000 And secondly, the systematic triage process that is used to classify and 0:04:49.040000 --> 0:04:51.380000 rich and score alerts. 0:04:51.380000 --> 0:04:55.340000 And then finally, how incidents are escalated to incident responders in 0:04:55.340000 --> 0:05:00.820000 the form of evidence rich tickets or cases that satisfy audit SLAs and 0:05:00.820000 --> 0:05:02.240000 handoff requirements. 0:05:02.240000 --> 0:05:04.220000 Okay, so fairly simple. 0:05:04.220000 --> 0:05:07.980000 So again, you may be asking, so well, why is this important? 0:05:07.980000 --> 0:05:11.540000 I may have alluded to why it's important, but just to reiterate it, understanding 0:05:11.540000 --> 0:05:16.740000 this workflow or process is essential because an IR program speed and 0:05:16.740000 --> 0:05:20.300000 accuracy hinge on disciplined triage. 0:05:20.300000 --> 0:05:25.100000 What that means is that, you know, efficient filtering or triage prevents 0:05:25.100000 --> 0:05:30.080000 analyst fatigue, accelerates containment in the event of an incident or 0:05:30.080000 --> 0:05:34.280000 a breach and ensures critical threats are neither overlooked nor delayed 0:05:34.280000 --> 0:05:38.700000 by noise. And we'll talk about alert noise in the next video. 0:05:38.700000 --> 0:05:42.420000 Furthermore, as an incident responder, it is very important to understand 0:05:42.420000 --> 0:05:47.580000 the process or flow of how a log becomes an alert and more importantly, 0:05:47.580000 --> 0:05:51.640000 how an alert is investigated, triaged and classified as an incident. 0:05:51.640000 --> 0:05:56.900000 So you're probably already aware of this process inherently, but you need 0:05:56.900000 --> 0:06:02.040000 to understand it within, you know, a broader context, because you will 0:06:02.040000 --> 0:06:07.300000 be working in an organization and you need to understand how, you know, 0:06:07.300000 --> 0:06:11.820000 or what this process looks like, how it works and what you will be receiving 0:06:11.820000 --> 0:06:14.180000 as the incident responder. 0:06:14.180000 --> 0:06:18.000000 And knowing what you'll be receiving in terms of the case and what is 0:06:18.000000 --> 0:06:20.040000 included is very important. 0:06:20.040000 --> 0:06:24.120000 So again, if you're already an incident responder, then this is not, you 0:06:24.120000 --> 0:06:26.240000 know, going to be something that's new to you. 0:06:26.240000 --> 0:06:30.440000 But if you're an aspiring incident responder or a SOC tier one analyst, 0:06:30.440000 --> 0:06:34.600000 then this process will be very important for you to understand. 0:06:34.600000 --> 0:06:38.460000 So that brings us to the triage process. 0:06:38.460000 --> 0:06:43.340000 Before we even get into the process, what exactly does triage mean? 0:06:43.340000 --> 0:06:47.380000 Generally speaking, the context of security operations or a SOC. 0:06:47.380000 --> 0:06:53.420000 Well, in cybersecurity operations, triage is the rapid methodical filtering 0:06:53.420000 --> 0:06:59.400000 of raw security signals or logs so that only real and high impact threats. 0:06:59.400000 --> 0:07:02.320000 When I say real, I mean verified. 0:07:02.320000 --> 0:07:07.080000 So only real and high impact threats reach an incident responder. 0:07:07.080000 --> 0:07:11.360000 In essence, what you're saying is, or what triage is all about is ensuring 0:07:11.360000 --> 0:07:15.340000 that, you know, you only reach out to the responder when there's a real 0:07:15.340000 --> 0:07:18.940000 incident. And this is very important, something you may think doesn't 0:07:18.940000 --> 0:07:23.700000 happen. But a lot of the times, incident responders are really performing 0:07:23.700000 --> 0:07:29.100000 the triage and then saying, hey, you guys sent me this to investigate. 0:07:29.100000 --> 0:07:36.580000 And I fairly quickly realized or learned that this was not really an incident. 0:07:36.580000 --> 0:07:40.520000 I mean, it is a little bit suspicious, but you guys should do better. 0:07:40.520000 --> 0:07:45.480000 But in essence, that's sort of one of the issues or pitfalls that you 0:07:45.480000 --> 0:07:50.080000 typically see. But the bottom line is triage is supposed to ensure that 0:07:50.080000 --> 0:07:54.580000 you as the incident responder only deal with things that you should be 0:07:54.580000 --> 0:07:58.760000 dealing with or that you have been hired to do. 0:07:58.760000 --> 0:08:06.400000 So, you know, that's what triage is in the context of cybersecurity operations. 0:08:06.400000 --> 0:08:12.700000 But we can also use an analogy or another case where triage is very important. 0:08:12.700000 --> 0:08:17.560000 And that's medical triage where it can be summarized as follows. 0:08:17.560000 --> 0:08:21.740000 So you decide who needs a doctor now, who can wait and who is completely 0:08:21.740000 --> 0:08:24.540000 fine. And that's exactly what you're doing, right? 0:08:24.540000 --> 0:08:29.220000 And this also extends to the now, you know, coming back to cybersecurity. 0:08:29.220000 --> 0:08:34.580000 The triage process also extends to priority or criticality and ensuring 0:08:34.580000 --> 0:08:41.080000 that the most critical events or incidents are the ones that are escalated 0:08:41.080000 --> 0:08:44.260000 or communicated to the responder first, right? 0:08:44.260000 --> 0:08:49.160000 So in the context of IR specifically, triage is the process of analyzing 0:08:49.160000 --> 0:08:54.360000 and categorizing security alerts or events to determine whether they indicate 0:08:54.360000 --> 0:08:58.720000 a potential security incident, a false positive, which we'll talk about 0:08:58.720000 --> 0:09:02.500000 in the next video, or, you know, a benign activity. 0:09:02.500000 --> 0:09:07.080000 And the goal here is to quickly assess the relevance and severity of an 0:09:07.080000 --> 0:09:10.260000 event and decide on the appropriate next steps. 0:09:10.260000 --> 0:09:13.920000 And what those next steps are will become apparent shortly. 0:09:13.920000 --> 0:09:18.260000 So that then brings us to this point, which may have been a question that 0:09:18.260000 --> 0:09:19.620000 you have been asking yourself. 0:09:19.620000 --> 0:09:24.620000 And you're already aware of the first few phases, but that is how a log 0:09:24.620000 --> 0:09:26.000000 becomes an incident. 0:09:26.000000 --> 0:09:28.680000 So, you know, you ingest a log into a seam. 0:09:28.680000 --> 0:09:37.160000 What's the workflow or the journey of a log, you know, being turned into 0:09:37.160000 --> 0:09:40.400000 an incident. When I say being turned into an incident, I'm referring to 0:09:40.400000 --> 0:09:43.940000 the actions taken to the log. 0:09:43.940000 --> 0:09:49.860000 By the tier one analyst, you know, I'm not really referring to the actual 0:09:49.860000 --> 0:09:53.200000 transformation of the log because a log could be indicative of anything. 0:09:53.200000 --> 0:09:58.000000 But let's say, you know, you have a log that tells the tier one analyst 0:09:58.000000 --> 0:10:03.780000 something. What actions do they take, you know, on that log or do they 0:10:03.780000 --> 0:10:09.620000 essentially confer upon that log, you know, that takes it from just being 0:10:09.620000 --> 0:10:12.240000 a log to an alert. 0:10:12.240000 --> 0:10:15.260000 And then consequently an incident. 0:10:15.260000 --> 0:10:19.120000 And of course, the same place, a seam in detection engineering plays a 0:10:19.120000 --> 0:10:22.460000 crucial role in, you know, the first transformation. 0:10:22.460000 --> 0:10:28.700000 So converting or turning or reclassifying just a standard log or event 0:10:28.700000 --> 0:10:30.680000 into an alert, right? 0:10:30.680000 --> 0:10:33.600000 But to begin with, we have log generation. 0:10:33.600000 --> 0:10:38.160000 So as you already know, we talked about this early on endpoints, network 0:10:38.160000 --> 0:10:42.520000 devices or cloud services, generate raw logs, you then have ingestion 0:10:42.520000 --> 0:10:44.440000 and normalization. 0:10:44.440000 --> 0:10:48.740000 So the logs are shipped via, you know, syslog or beats to a seam. 0:10:48.740000 --> 0:10:51.600000 So they're passed into a common schema. 0:10:51.600000 --> 0:10:56.780000 And we, you know, we have examples of the fields afforded by this custom 0:10:56.780000 --> 0:11:01.200000 schema like vendor, the source IP, process name, et cetera. 0:11:01.200000 --> 0:11:04.420000 And then you have correlation or detection rules. 0:11:04.420000 --> 0:11:09.440000 So the seam evaluates normalized records against detection rules, signatures, 0:11:09.440000 --> 0:11:14.160000 behavioral analytics and threat intel lists or databases. 0:11:14.160000 --> 0:11:16.580000 And then you have the event creation, right? 0:11:16.580000 --> 0:11:21.240000 So a single rule, a single rule match is stamped or categorized as an 0:11:21.240000 --> 0:11:26.420000 event. This is typically automated if you have detection rules, but, you 0:11:26.420000 --> 0:11:30.220000 know, it's stamped or categorized as an event with, you know, the rule 0:11:30.220000 --> 0:11:32.120000 ID plus metadata. 0:11:32.120000 --> 0:11:34.540000 And then you have the formulation of the alert. 0:11:34.540000 --> 0:11:38.460000 So the event is scored and reached and promoted to an alert that lands 0:11:38.460000 --> 0:11:40.260000 in the tier one queue. 0:11:40.260000 --> 0:11:42.220000 And then you have the tier one triage. 0:11:42.220000 --> 0:11:45.580000 So I'm referring to the, you know, SOC analyst or SOC tier one analyst 0:11:45.580000 --> 0:11:50.660000 triage. So the analyst either dismisses it or escalates it based on their 0:11:50.660000 --> 0:11:55.020000 own analysis. And if they choose to escalate it, you know, escalation 0:11:55.020000 --> 0:11:58.800000 then converts the alert into a case or an incident. 0:11:58.800000 --> 0:12:04.540000 When, you know, I've, when the previous course, that was focused on preparation. 0:12:04.540000 --> 0:12:08.480000 We talked about incident handling platforms or incident management platforms 0:12:08.480000 --> 0:12:13.280000 like the hive. And this is where that nomenclature is coming from. 0:12:13.280000 --> 0:12:19.340000 So when you, um, when a tier one analyst escalates or wants to, you know, 0:12:19.340000 --> 0:12:22.800000 communicate to an incident responder that, hey, this is something you 0:12:22.800000 --> 0:12:26.300000 should look at. That you do it in the form of a case, right? 0:12:26.300000 --> 0:12:31.180000 And of course, the best way to think of it is a ticket, a case or just 0:12:31.180000 --> 0:12:35.060000 an incident. And then the tier two investigation begins. 0:12:35.060000 --> 0:12:36.820000 So this is where you come into play. 0:12:36.820000 --> 0:12:41.520000 So, you know, the actual incident response, um, the first step begins 0:12:41.520000 --> 0:12:47.320000 obviously with, uh, an, um, analysis because detection we've already covered, 0:12:47.320000 --> 0:12:51.060000 but the incident responder takes ownership, performs full incident handling 0:12:51.060000 --> 0:12:52.560000 in the form of analysis. 0:12:52.560000 --> 0:12:58.260000 And then the other phases of instant response that, um, which are containment, 0:12:58.260000 --> 0:13:02.020000 eradication, recovery and post -mortem or the post incident. 0:13:02.020000 --> 0:13:05.600000 Analysis. And that's, you know, basically the process. 0:13:05.600000 --> 0:13:10.500000 Um, so when we're talking about how a log becomes an incident, that's 0:13:10.500000 --> 0:13:13.920000 the process, but there's also another aspect that you need to understand. 0:13:13.920000 --> 0:13:16.500000 And that is the data pipeline, right? 0:13:16.500000 --> 0:13:20.840000 So now we're looking specifically at the pipeline, uh, which is, will 0:13:20.840000 --> 0:13:24.340000 be much easier for you to understand if you're looking at it from the 0:13:24.340000 --> 0:13:26.560000 perspective of a seem, let's say. 0:13:26.560000 --> 0:13:30.080000 So firstly, we have the log to, you know, event. 0:13:30.080000 --> 0:13:32.060000 So log becoming an event. 0:13:32.060000 --> 0:13:36.740000 So devices, endpoints and cloud services, uh, as I've already mentioned, 0:13:36.740000 --> 0:13:38.460000 you know, generate logs. 0:13:38.460000 --> 0:13:42.340000 So an example would be a window, Sysmone entry or a window, Sysmone log 0:13:42.340000 --> 0:13:46.660000 and then a C more log pipeline tool passes each log into a structured 0:13:46.660000 --> 0:13:51.540000 event. So, you know, this includes fields like the host name, process 0:13:51.540000 --> 0:13:55.880000 name, user timestamp, et cetera. 0:13:55.880000 --> 0:13:59.380000 And the second, um, part of the data pipeline, which is, um, you know, 0:13:59.380000 --> 0:14:01.100000 the event becoming an alert. 0:14:01.100000 --> 0:14:05.520000 So detection, uh, detection logic or rules, which are things like signatures, 0:14:05.520000 --> 0:14:10.000000 behavioral rules, threat, intel matches, machine learning models, et cetera, 0:14:10.000000 --> 0:14:11.840000 evaluates events. 0:14:11.840000 --> 0:14:16.020000 And then a rule hit or match is stamped as an alert and placed in the 0:14:16.020000 --> 0:14:18.480000 SOC queue with initial metadata. 0:14:18.480000 --> 0:14:22.960000 So think of things like the rule ID, asset, time, et cetera. 0:14:22.960000 --> 0:14:28.520000 And then, you know, step three, you have the alert, um, being triaged, 0:14:28.520000 --> 0:14:32.780000 right, which is sort of the core of this video, uh, which, you know, wasn't 0:14:32.780000 --> 0:14:36.280000 really explained when we are talking about the process, but with the data 0:14:36.280000 --> 0:14:38.700000 pipeline, this will make much more sense. 0:14:38.700000 --> 0:14:41.800000 So this is where the tier one analyst comes into play. 0:14:41.800000 --> 0:14:46.500000 So the tier one analysts or even automated saw playbooks work the queue, 0:14:46.500000 --> 0:14:51.900000 right? And what this looks like, uh, all the way this works can be understood 0:14:51.900000 --> 0:14:54.260000 by breaking it down into steps. 0:14:54.260000 --> 0:15:00.580000 So you have the intake and de-duplication phase where identical alerts 0:15:00.580000 --> 0:15:05.000000 are collapsed and, uh, you know, you do things like suppress known benign 0:15:05.000000 --> 0:15:09.020000 scanners. And then you have initial classification, which is very important. 0:15:09.020000 --> 0:15:13.920000 So this is where the alert is tagged with a category based on its nature. 0:15:13.920000 --> 0:15:17.680000 So if it's, you know, looks, if it's related to, you know, let's say a 0:15:17.680000 --> 0:15:21.220000 fishing attack, where it looks like a fishing attack or malware related, 0:15:21.220000 --> 0:15:25.880000 then you tag it accordingly as we did in the previous course with the 0:15:25.880000 --> 0:15:29.340000 hive, right? You saw what that looked like practically. 0:15:29.340000 --> 0:15:35.500000 You also may have additional fields or tags or categories of tags that 0:15:35.500000 --> 0:15:42.900000 allow for further enrichment in the form of, um, associating, um, the 0:15:42.900000 --> 0:15:48.620000 alert, with the relevant mitre tag TTP and a lot of seams or even EDRs 0:15:48.620000 --> 0:15:49.780000 will do this for you. 0:15:49.780000 --> 0:15:54.060000 They'll do the mitre tag TTP mapping to show you exactly where it falls 0:15:54.060000 --> 0:15:56.320000 within the mitre tag framework. 0:15:56.320000 --> 0:15:58.220000 You then have context enrichment. 0:15:58.220000 --> 0:16:00.940000 So this is less than or equal to 30 seconds. 0:16:00.940000 --> 0:16:04.760000 So this is where, you know, you pull or identify the sock tier one analyst 0:16:04.760000 --> 0:16:07.760000 will pull or identify the asset criticality. 0:16:07.760000 --> 0:16:11.140000 So it's criticality in terms of business impact. 0:16:11.140000 --> 0:16:17.340000 The user privilege, the IP reputation, recent alert history, et cetera. 0:16:17.340000 --> 0:16:19.400000 And then there's a severity scoring, right? 0:16:19.400000 --> 0:16:23.100000 So you hear a formula is typically applied. 0:16:23.100000 --> 0:16:28.180000 Of course, in most cases is going to be automated, but the formula would 0:16:28.180000 --> 0:16:30.920000 be impact times the likelihood, right? 0:16:30.920000 --> 0:16:36.500000 And this helps in labeling it, you know, in labeling the severity, right? 0:16:36.500000 --> 0:16:40.960000 So critical high, medium or low, nothing too complicated there. 0:16:40.960000 --> 0:16:43.660000 And then you have the disposition decision. 0:16:43.660000 --> 0:16:47.860000 So this is where the sock tier one analyst decides what to do once they've 0:16:47.860000 --> 0:16:52.820000 gone through all the previous steps here of context enrichment, severity, 0:16:52.820000 --> 0:16:55.540000 scoring, initial classification, et cetera. 0:16:55.540000 --> 0:16:58.940000 So they can choose to close or suppress it. 0:16:58.940000 --> 0:17:02.900000 In most cases, this means that this is a confirmed false positive or a 0:17:02.900000 --> 0:17:07.700000 policy accepted activity or they can choose to contain and resolve. 0:17:07.700000 --> 0:17:12.680000 Right. So think of a, you know, quick scripted fix like isolating a workstation 0:17:12.680000 --> 0:17:16.780000 with no escalation or there's no escalation needed. 0:17:16.780000 --> 0:17:22.020000 Now, that brings us to the key point, which is the escalation. 0:17:22.020000 --> 0:17:26.720000 So in this case, if there's anything that's uncertain, high severity or 0:17:26.720000 --> 0:17:30.620000 that requires deeper, let's say forensics, but more so deep analysis, 0:17:30.620000 --> 0:17:35.120000 it then goes to the instant responder, which makes a lot of sense, right? 0:17:35.120000 --> 0:17:38.460000 Because that's not the sock tier one analyst's job. 0:17:38.460000 --> 0:17:42.180000 It's the sock tier two analyst or incident responder. 0:17:42.180000 --> 0:17:48.240000 It's it's their job to, you know, perform this, this additional or deeper 0:17:48.240000 --> 0:17:53.000000 analysis, because, you know, the sock tier one analyst may be confused. 0:17:53.000000 --> 0:17:56.840000 You know, they may be uncertain about exactly what they're dealing with. 0:17:56.840000 --> 0:18:02.000000 And of course, there are policies and procedures that essentially lay 0:18:02.000000 --> 0:18:03.320000 out when they should be done. 0:18:03.320000 --> 0:18:07.500000 That's why the previous course where we covered preparation was very important 0:18:07.500000 --> 0:18:08.920000 for you to understand. 0:18:08.920000 --> 0:18:14.180000 In any case, you then have, you know, the fourth phase, which is where, 0:18:14.180000 --> 0:18:20.520000 you know, the, the escalated alert is turned into an incident case or 0:18:20.520000 --> 0:18:23.000000 an incident for lack of a better word. 0:18:23.000000 --> 0:18:29.200000 So for escalations, the saw or the seam solution is used to or opens an 0:18:29.200000 --> 0:18:30.400000 incident ticket. 0:18:30.400000 --> 0:18:35.320000 So for example, you know, think of service now, the hive as we explored 0:18:35.320000 --> 0:18:38.680000 in the previous course, even Jira sometimes. 0:18:38.680000 --> 0:18:42.420000 So there's many options for the platform that can be used to, you know, 0:18:42.420000 --> 0:18:45.960000 for the communication of incidents in the form of cases. 0:18:45.960000 --> 0:18:48.260000 The most popular, as I said, is the hive. 0:18:48.260000 --> 0:18:51.700000 And we, you know, we went through what that was like in terms of actually 0:18:51.700000 --> 0:18:56.120000 creating a case and then, you know, going through the investigation or 0:18:56.120000 --> 0:18:57.920000 analysis process. 0:18:57.920000 --> 0:19:03.340000 We also took a look at creating case templates that mirror, you know, 0:19:03.340000 --> 0:19:10.480000 case templates for specific types of incidents or, you know, alerts in 0:19:10.480000 --> 0:19:13.920000 the form of, you know, malware, so on and so forth. 0:19:13.920000 --> 0:19:18.660000 And then how to use prebuilt playbooks to, you know, facilitate the customization 0:19:18.660000 --> 0:19:20.340000 of these case templates. 0:19:20.340000 --> 0:19:25.280000 In any case, the key point here is that ownership is reassigned from tier 0:19:25.280000 --> 0:19:30.980000 one to tier two, you know, tier two being you, the incident responder. 0:19:30.980000 --> 0:19:33.320000 That's typically the case in most socks. 0:19:33.320000 --> 0:19:36.860000 Of course, we went through the different models of, you know, the different 0:19:36.860000 --> 0:19:40.720000 sock models and how teams are structured. 0:19:40.720000 --> 0:19:45.300000 So in this case, just know that, you know, tier two analyst is, you know, 0:19:45.300000 --> 0:19:47.100000 the incident responder. 0:19:47.100000 --> 0:19:50.760000 So that now brings us to the end to end workflow. 0:19:50.760000 --> 0:19:57.300000 So we've talked about, you know, how a log becomes an incident, the process, 0:19:57.300000 --> 0:19:59.260000 the data pipeline. 0:19:59.260000 --> 0:20:02.900000 But now we're taking a look at the triage process from the perspective 0:20:02.900000 --> 0:20:04.480000 of an end to end workflow. 0:20:04.480000 --> 0:20:08.440000 So the table in the next set of slides will provide you with an end to 0:20:08.440000 --> 0:20:12.800000 end view of the triage workflow or process complete with the actions taken 0:20:12.800000 --> 0:20:14.640000 in each phase or step. 0:20:14.640000 --> 0:20:19.120000 The ownership of the actions taken in each respective phase or step. 0:20:19.120000 --> 0:20:24.080000 So who is responsible for each phase and the deliverables, which is very 0:20:24.080000 --> 0:20:28.740000 important, the deliverables or the outputs of each phase or step of the 0:20:28.740000 --> 0:20:33.060000 triage process. So the workflow represented is important for me to point 0:20:33.060000 --> 0:20:37.500000 this out. The workflow represented in the table is platform or tool like 0:20:37.500000 --> 0:20:42.920000 Gnostic, but maps really well to the, you know, Splunk Enterprise Security, 0:20:42.920000 --> 0:20:47.360000 Elastic Security, Microsoft Teams, Sentinel, IBM, Qradar, or even a homegrown 0:20:47.360000 --> 0:20:51.560000 or home developed seamstack. 0:20:51.560000 --> 0:20:54.820000 So, yeah. So this is the table here. 0:20:54.820000 --> 0:20:56.780000 We have four columns. 0:20:56.780000 --> 0:21:00.760000 We have the phase, the key actions taken in each phase, the typical owner 0:21:00.760000 --> 0:21:06.060000 of, you know, that particular phase and then the deliverables or the outputs 0:21:06.060000 --> 0:21:08.480000 or the artifacts from that phase. 0:21:08.480000 --> 0:21:12.340000 So starting with the first phase, which we have already gone through, 0:21:12.340000 --> 0:21:15.000000 which is alert intake and deduplication. 0:21:15.000000 --> 0:21:16.640000 What are the key actions here? 0:21:16.640000 --> 0:21:18.880000 Well, you know, alerts. 0:21:18.880000 --> 0:21:26.200000 So in, you know, ingest alerts from same rule triggers, the EDR, IDS sensors, 0:21:26.200000 --> 0:21:30.000000 cloud security tools, deduplicate identical alerts. 0:21:30.000000 --> 0:21:35.040000 So hash alert ID matching and you suppress known benign signatures. 0:21:35.040000 --> 0:21:36.360000 So noise filters. 0:21:36.360000 --> 0:21:37.840000 Don't worry if you don't know what noise is. 0:21:37.840000 --> 0:21:40.260000 We'll get to that in the next video. 0:21:40.260000 --> 0:21:44.420000 The typical owner here is, you know, SOC tier one analyst or it could 0:21:44.420000 --> 0:21:48.340000 be automated if pre-processing is possible or available. 0:21:48.340000 --> 0:21:52.480000 And the deliverables or the outcomes of this phase are a clean working 0:21:52.480000 --> 0:21:56.480000 queue with unique alert IDs and timestamps. 0:21:56.480000 --> 0:22:00.600000 You then have the second phase, which is the initial classification. 0:22:00.600000 --> 0:22:05.440000 So the key actions here are identify the alert types or malware, phishing, 0:22:05.440000 --> 0:22:07.300000 brute force, etc. 0:22:07.300000 --> 0:22:12.140000 If available, you map it to, you know, MITRE attack TTPs. 0:22:12.140000 --> 0:22:18.060000 You then tag with the asset owner or business unit, if that is applicable. 0:22:18.060000 --> 0:22:22.700000 The typical owner of this phase is tier one, SOC tier one analyst, and 0:22:22.700000 --> 0:22:25.820000 then the deliverables or the artifacts are, you know, a classification 0:22:25.820000 --> 0:22:28.980000 label. So taxonomy tags. 0:22:28.980000 --> 0:22:34.060000 So it should be tagged, you know, it should be tagged and or classified 0:22:34.060000 --> 0:22:39.340000 accordingly. Based on, you know, the organizations, instant response plan 0:22:39.340000 --> 0:22:44.720000 and policies. You then have the third phase, which is context enrichment. 0:22:44.720000 --> 0:22:48.100000 So pull quick automated context. 0:22:48.100000 --> 0:22:54.600000 So what you're looking at here is things like asset criticality, use identity 0:22:54.600000 --> 0:22:59.980000 and role, geo location and reputation for IPs, domains, so, you know, 0:22:59.980000 --> 0:23:02.120000 threat intelligence feeds as well. 0:23:02.120000 --> 0:23:07.680000 You know, the previous alert history on the entity, and you can also incorporate 0:23:07.680000 --> 0:23:12.780000 open source threat intelligence, the form of sticks, taxi, virus, total, 0:23:12.780000 --> 0:23:19.360000 etc. This is typically owned by the SOC tier one analyst, and usually, 0:23:19.360000 --> 0:23:25.160000 at least in modern SOCs, assisted by the integration of SOAR. 0:23:25.160000 --> 0:23:29.840000 And the deliverables or artifacts or the outputs of this phase are enriched 0:23:29.840000 --> 0:23:31.820000 alert metadata blocks. 0:23:31.820000 --> 0:23:36.520000 So you essentially enriching as the phase name suggests, you know, you're 0:23:36.520000 --> 0:23:42.800000 sort of enriching the context associated, the context of the alert. 0:23:42.800000 --> 0:23:47.820000 And then you have phase four, which is severity scoring or prioritization. 0:23:47.820000 --> 0:23:52.640000 So the key actions taken here are, you know, you apply this scoring formula, 0:23:52.640000 --> 0:23:57.720000 for example, impact times likelihood or, you know, quite commonly, the 0:23:57.720000 --> 0:24:05.960000 CVSS score. And the key actions here in terms of questions are, you know, 0:24:05.960000 --> 0:24:08.240000 is it an external or internal asset? 0:24:08.240000 --> 0:24:10.900000 Is it a high value system? 0:24:10.900000 --> 0:24:13.380000 Was a privileged account involved? 0:24:13.380000 --> 0:24:17.260000 Are you able to detect this stage in the kill chain? 0:24:17.260000 --> 0:24:21.500000 And then the confidence in rule, so the false positive rate. 0:24:21.500000 --> 0:24:25.500000 This is the typical owner here is, you know, the SOC tier one analyst, 0:24:25.500000 --> 0:24:31.200000 or it could be automated and then checked by, you know, the tier one analyst. 0:24:31.200000 --> 0:24:35.520000 So the deliverables or artifacts here on numeric or categorical severity 0:24:35.520000 --> 0:24:39.680000 of the classification of the alert. 0:24:39.680000 --> 0:24:41.980000 So critical high, medium, low. 0:24:41.980000 --> 0:24:46.120000 And then you have the fifth phase, which is your, you know, the decision 0:24:46.120000 --> 0:24:48.800000 phase. So dismiss, contain or escalate. 0:24:48.800000 --> 0:24:52.760000 So in the case of dismissing or closing it, that, you know, usually is 0:24:52.760000 --> 0:24:57.080000 caused, you know, is usually the case when it's a false positive or is 0:24:57.080000 --> 0:25:02.660000 benign. If the tier one analyst chooses to contain or resolve it, it means 0:25:02.660000 --> 0:25:06.700000 generally that it's a straightforward fix or not something that you need 0:25:06.700000 --> 0:25:09.460000 to include the responder in. 0:25:09.460000 --> 0:25:11.540000 Or share it with, right? 0:25:11.540000 --> 0:25:16.180000 So an example would be a user clicked up a nine link that was, you know, 0:25:16.180000 --> 0:25:19.140000 block page. And then we have escalation. 0:25:19.140000 --> 0:25:22.620000 So this is when the alert requires deep analysis. 0:25:22.620000 --> 0:25:26.620000 So it moves to, you know, tier two analyst or the instant responder. 0:25:26.620000 --> 0:25:31.620000 Or if there is a dedicated instant response team, it is escalated or moved 0:25:31.620000 --> 0:25:37.900000 to them. The typical owner of this phase of the process, the triage process 0:25:37.900000 --> 0:25:39.080000 is the SOC tier one. 0:25:39.080000 --> 0:25:42.760000 And the one analyst and the deliverables or artifacts here would be a 0:25:42.760000 --> 0:25:47.660000 disposition tag and notes or documentation in the event of escalation 0:25:47.660000 --> 0:25:52.760000 because the only, the only time there will be an output here really is 0:25:52.760000 --> 0:25:57.180000 when it's being escalated to the incident response team or the incident 0:25:57.180000 --> 0:26:01.300000 responder. And then you have phase six, which is creation of the investigation 0:26:01.300000 --> 0:26:07.080000 case. So for alerts that have been escalated, you will typically see that 0:26:07.080000 --> 0:26:11.260000 a case will be opened in the ticketing or instant response handling and 0:26:11.260000 --> 0:26:13.280000 or management platform. 0:26:13.280000 --> 0:26:18.580000 Examples being, you know, service now, sec, ops, JIRA, the Hive, et cetera. 0:26:18.580000 --> 0:26:23.260000 And then, you know, you also have auto linking of artifacts. 0:26:23.260000 --> 0:26:27.840000 You know, that this is typically done. 0:26:27.840000 --> 0:26:32.740000 These artifacts are, you know, the artifacts that the tier one analyst 0:26:32.740000 --> 0:26:33.900000 was able to find. 0:26:33.900000 --> 0:26:37.960000 So this could be logs, PCAP, smell with samples, et cetera. 0:26:37.960000 --> 0:26:41.320000 There's also population of the playbook template. 0:26:41.320000 --> 0:26:46.420000 So tasks, SLAs, owners, this is all really dependent on the instant response 0:26:46.420000 --> 0:26:48.260000 policies around escalation. 0:26:48.260000 --> 0:26:52.380000 And we already looked at this with the Hive in the previous course. 0:26:52.380000 --> 0:26:54.880000 So you already know what I'm talking about here. 0:26:54.880000 --> 0:26:59.560000 And then finally, notification, you know, notify the on call instant response 0:26:59.560000 --> 0:27:01.320000 lead or the tier two analyst. 0:27:01.320000 --> 0:27:05.620000 Again, that's all really dependent on the organization and what the escalation 0:27:05.620000 --> 0:27:09.820000 process is like, whether there's a dedicated incident response team, so 0:27:09.820000 --> 0:27:10.460000 on and so forth. 0:27:10.460000 --> 0:27:15.040000 The typical owner here is going to be, you know, saw or tier saw because 0:27:15.040000 --> 0:27:19.100000 it can be automated and orchestrated. 0:27:19.100000 --> 0:27:24.440000 Or it's going to be the tier one analyst and the deliverables or the artifacts 0:27:24.440000 --> 0:27:27.720000 or the outputs here going to be, you know, the case ID, the ownership 0:27:27.720000 --> 0:27:30.440000 and the SLA clock starts. 0:27:30.440000 --> 0:27:34.520000 Right. And the responder can then the instant responder can then begin 0:27:34.520000 --> 0:27:39.520000 their work. So this is the key point when there's a handoff, right? 0:27:39.520000 --> 0:27:42.040000 So that's the documentation and handoff phase. 0:27:42.040000 --> 0:27:43.520000 So that's phase seven. 0:27:43.520000 --> 0:27:48.020000 The key actions here taken here are, you know, summarize the triage findings. 0:27:48.020000 --> 0:27:52.440000 So why this was escalated and the severity rationale. 0:27:52.440000 --> 0:27:57.440000 So essentially telling the instant responder, Hey, this is why I've escalated 0:27:57.440000 --> 0:28:01.980000 it to you. And this was the rationale behind my severity calculation, 0:28:01.980000 --> 0:28:04.920000 right, or classification as it were. 0:28:04.920000 --> 0:28:08.600000 You then attach enrichment evidence and initial queries. 0:28:08.600000 --> 0:28:11.260000 You record containment already performed. 0:28:11.260000 --> 0:28:14.640000 If it was performed, an example would be, you know, blocking a hash via 0:28:14.640000 --> 0:28:20.280000 the EDR. And then there's a handoff verbally or via workflow as defined 0:28:20.280000 --> 0:28:24.940000 in the instant response plan and policy. 0:28:24.940000 --> 0:28:29.380000 To the tier two analyst for, you know, for the actual deep dive analysis. 0:28:29.380000 --> 0:28:34.140000 So the typical owner is going to be tier one, but this is the handoff 0:28:34.140000 --> 0:28:38.380000 to the tier two analyst or the incident responder as they're called or 0:28:38.380000 --> 0:28:40.080000 even the incident response team. 0:28:40.080000 --> 0:28:44.800000 The bottom line is this is where it moves from the SOC or from threat 0:28:44.800000 --> 0:28:49.300000 detection now to, you know, instant response, more specifically beginning 0:28:49.300000 --> 0:28:57.780000 with, with detection and analysis, but more so, more so analysis. 0:28:57.780000 --> 0:29:02.240000 In any case, the deliverables or the artifacts or the output of this phase 0:29:02.240000 --> 0:29:06.460000 are going to be, you know, fully populated case record ready for analysis. 0:29:06.460000 --> 0:29:09.160000 So the incident responder can dive into it. 0:29:09.160000 --> 0:29:12.940000 And hopefully your understanding why it's important for you as an incident 0:29:12.940000 --> 0:29:31.020000 responder to. And you're not aware of, you know, how you go from a log 0:29:31.020000 --> 0:29:36.300000 to an incident, then you're sort of going to be lost as to, you know, 0:29:36.300000 --> 0:29:42.000000 why certain, certain info within the case was included and stuff like 0:29:42.000000 --> 0:29:48.680000 this. So, you know, if you're not aware of the incident response, you're 0:29:48.680000 --> 0:29:50.840000 going to be able to, you know, just to the actual process, you may be 0:29:50.840000 --> 0:29:54.800000 asking yourself, could you tell me, you know, what step is the most important 0:29:54.800000 --> 0:29:57.380000 or why each step matters to instant response? 0:29:57.380000 --> 0:30:00.980000 Well, let's take a look at the key checkpoints and, you know, the value 0:30:00.980000 --> 0:30:03.360000 for the responder, the incident responder. 0:30:03.360000 --> 0:30:05.620000 So starting off with the duplication. 0:30:05.620000 --> 0:30:06.740000 How does this help you? 0:30:06.740000 --> 0:30:09.960000 Well, it prevents duplicate work and alert fatigue. 0:30:09.960000 --> 0:30:12.660000 You don't want to be in a position where you're constantly being alerted 0:30:12.660000 --> 0:30:17.940000 or you constantly have cases being escalated or created for you to investigate 0:30:17.940000 --> 0:30:22.420000 or analyze and you realize that, again, it's, you know, this duplication. 0:30:22.420000 --> 0:30:23.900000 It's a false positive, etc. 0:30:23.900000 --> 0:30:29.180000 So that's deduplication or that's why, you know, that's the value for 0:30:29.180000 --> 0:30:31.400000 the responder. Then you have classification and enrichment. 0:30:31.400000 --> 0:30:36.160000 So the value for the responder is that it gives immediate context. 0:30:36.160000 --> 0:30:40.500000 So an example would be, you know, critical server versus test VM, privileged 0:30:40.500000 --> 0:30:41.940000 admin versus guest. 0:30:41.940000 --> 0:30:45.280000 So it is, you know, it tells you exactly what you're dealing with here 0:30:45.280000 --> 0:30:47.360000 in terms of scope, right? 0:30:47.360000 --> 0:30:49.540000 And then you have severity scoring. 0:30:49.540000 --> 0:30:53.080000 So this allows responders to triage their own workload. 0:30:53.080000 --> 0:31:00.680000 My point exactly, you need if, if incidents don't have a severity scoring, 0:31:00.680000 --> 0:31:07.140000 then the instant responder does not know exactly what to deal with first, 0:31:07.140000 --> 0:31:11.680000 right? And in addition to that, the instant responder may choose to use 0:31:11.680000 --> 0:31:17.420000 severity scoring themselves on their own basis. 0:31:17.420000 --> 0:31:20.780000 But the bottom line is that it allows responders to triage their own workload, 0:31:20.780000 --> 0:31:25.760000 hitting the highest risk incidents first or starting with them first. 0:31:25.760000 --> 0:31:30.660000 And finally, you know, the final triage checkpoint would be the evidence 0:31:30.660000 --> 0:31:36.380000 -rich ticket. So the value for the responder is that it minimizes retriage, 0:31:36.380000 --> 0:31:41.220000 letting tier two jump straight to validation analysis and, you know, scoping 0:31:41.220000 --> 0:31:42.640000 and containment. 0:31:42.640000 --> 0:31:45.480000 So very, very useful. 0:31:45.480000 --> 0:31:54.860000 And now finally, some examples, right, of what triage looks like. 0:31:54.860000 --> 0:31:55.660000 So you can see it's a very useful way to execute it. 0:31:55.660000 --> 0:31:58.060000 Partial script command doesn't really matter. 0:31:58.060000 --> 0:32:00.040000 Executed on a Windows workstation. 0:32:00.040000 --> 0:32:03.860000 So you can see it starts from the Sysmon log. 0:32:03.860000 --> 0:32:07.300000 And then you have the passing and normalization is then, you know, being 0:32:07.300000 --> 0:32:08.940000 ingested into the SEAM. 0:32:08.940000 --> 0:32:11.400000 And then you have an event here. 0:32:11.400000 --> 0:32:15.860000 And then there was a detection rule that rule matches this particular 0:32:15.860000 --> 0:32:19.660000 event for, you know, partial downloaders. 0:32:19.660000 --> 0:32:24.700000 And then that automatically triggers the creation of an alert that goes 0:32:24.700000 --> 0:32:26.760000 into the alert queue. 0:32:26.760000 --> 0:32:30.660000 And then you have a deduplication, classification enrichment. 0:32:30.660000 --> 0:32:34.380000 And then the triage decision is made by the tier one analyst. 0:32:34.380000 --> 0:32:38.260000 And then if they choose to escalate, a ticket is created and, you know, 0:32:38.260000 --> 0:32:40.260000 just given a random name here. 0:32:40.260000 --> 0:32:45.200000 They usually follow, you know, sequential or a specific naming convention. 0:32:45.200000 --> 0:32:49.720000 But going through the process now technically or formally, you know, log 0:32:49.720000 --> 0:32:55.140000 to event. So Sysmon on the system Windows 10 HR one, that's the host name 0:32:55.140000 --> 0:32:57.200000 of this fictitious system. 0:32:57.200000 --> 0:33:00.740000 So this, so Sysmon records event one. 0:33:00.740000 --> 0:33:06.700000 So that represents process create when a hidden partial spawns with it. 0:33:06.700000 --> 0:33:09.480000 The download string command line argument. 0:33:09.480000 --> 0:33:14.760000 And you had already written a detection rule to detect that kind of malicious 0:33:14.760000 --> 0:33:18.080000 activity. So that brings us to step two, move away. 0:33:18.080000 --> 0:33:23.140000 You have the event, you know, move where the event becomes an alert. 0:33:23.140000 --> 0:33:27.000000 So a Splunk in this case, the SEAM being used was a plus planks or Splunk 0:33:27.000000 --> 0:33:28.100000 correlation search. 0:33:28.100000 --> 0:33:31.880000 In this case, the search is process name and is equal to PowerShell. 0:33:31.880000 --> 0:33:33.460000 The Xeave have already done this. 0:33:33.460000 --> 0:33:40.400000 So you should understand this and command line is equal to download string. 0:33:40.400000 --> 0:33:44.300000 That fires and then it labels the match high severity. 0:33:44.300000 --> 0:33:49.420000 So you configure what is if you're automating it, you configure what constitutes, 0:33:49.420000 --> 0:33:54.540000 you know, the, you're essentially writing detection rules for what you 0:33:54.540000 --> 0:33:56.280000 think is a malicious activity. 0:33:56.280000 --> 0:34:03.440000 And then you use that to, you know, create an alert that when, you know, 0:34:03.440000 --> 0:34:07.900000 that way, when triggered, you know, pretty much. 0:34:07.900000 --> 0:34:12.000000 Labels, you know, this particular match high severity in this particular 0:34:12.000000 --> 0:34:16.360000 example. And then you have alert being triaged. 0:34:16.360000 --> 0:34:18.940000 So the tier one analyst and riches. 0:34:18.940000 --> 0:34:22.160000 The alert with asset criticality. 0:34:22.160000 --> 0:34:26.580000 So, you know, things like business laptop, for example, and then ads. 0:34:26.580000 --> 0:34:28.340000 This is the enrichment process. 0:34:28.340000 --> 0:34:30.040000 I you see enrichment process. 0:34:30.040000 --> 0:34:32.140000 So ads virus total hash result. 0:34:32.140000 --> 0:34:36.600000 And they also see no prior alerts on the host and they choose to escalate, 0:34:36.600000 --> 0:34:40.540000 right? And then you have the create, you have the creation of the case 0:34:40.540000 --> 0:34:43.200000 saw in this case, saw is used. 0:34:43.200000 --> 0:34:50.200000 So, so, so opens a service now, opens a service now, IR ticket called, 0:34:50.200000 --> 0:34:55.420000 INC. Not, not, not three one four. 0:34:55.420000 --> 0:35:01.240000 And this includes all the logs plus the hash attached and, you know, tier 0:35:01.240000 --> 0:35:06.960000 two, the tier two responder is paged or is, is actually contacted through 0:35:06.960000 --> 0:35:12.720000 whatever protocols, communication protocols have been laid out or defined 0:35:12.720000 --> 0:35:15.380000 in the instant response policies. 0:35:15.380000 --> 0:35:18.440000 So, hopefully that makes sense now. 0:35:18.440000 --> 0:35:22.500000 I know this was quite a lengthy video, but it's very important for you 0:35:22.500000 --> 0:35:27.180000 to understand this because this is very close to, you know, where your 0:35:27.180000 --> 0:35:33.140000 work is going to be away your responsibilities as an incident responder 0:35:33.140000 --> 0:35:37.600000 begin. So, with that being said, that's going to be it for this video. 0:35:37.600000 --> 0:35:40.100000 And I will be seeing you in the next video.