WEBVTT 1 00:00:00.000 --> 00:00:01.860 In this lesson, we will learn 2 00:00:01.860 --> 00:00:04.200 about root cause analysis. 3 00:00:04.200 --> 00:00:06.780 Root cause analysis is the process 4 00:00:06.780 --> 00:00:11.610 of identifying the underlying reason for a security incident 5 00:00:11.610 --> 00:00:14.130 to prevent future occurrences. 6 00:00:14.130 --> 00:00:18.150 This involves tracing the issue back to its origin 7 00:00:18.150 --> 00:00:22.380 by analyzing technical failures, vulnerabilities, 8 00:00:22.380 --> 00:00:25.320 or human errors that enabled the incident. 9 00:00:25.320 --> 00:00:29.400 The goal of root cause analysis is to understand 10 00:00:29.400 --> 00:00:32.610 how the incident occurred, whether it was due 11 00:00:32.610 --> 00:00:35.664 to misconfigurations, unpatched software, 12 00:00:35.664 --> 00:00:38.220 or procedural failures, 13 00:00:38.220 --> 00:00:41.220 and to implement long-term solutions 14 00:00:41.220 --> 00:00:43.530 that address these root causes. 15 00:00:43.530 --> 00:00:46.740 Let's learn more about root cause analysis. 16 00:00:46.740 --> 00:00:51.690 Root cause analysis or RCA is an essential process used 17 00:00:51.690 --> 00:00:55.380 to understand why a security incident happened 18 00:00:55.380 --> 00:00:58.620 and to prevent it from happening again. 19 00:00:58.620 --> 00:01:02.460 RCA goes beyond fixing symptoms of a problem 20 00:01:02.460 --> 00:01:06.960 and instead focuses on identifying the underlying reasons 21 00:01:06.960 --> 00:01:09.240 that allow the issue to occur. 22 00:01:09.240 --> 00:01:14.130 For example, a cybersecurity breach might initially appear 23 00:01:14.130 --> 00:01:17.550 to be caused by a single weak password, 24 00:01:17.550 --> 00:01:21.330 but root cause analysis will look deeper exploring how 25 00:01:21.330 --> 00:01:25.320 and why that weak password was in place to begin with. 26 00:01:25.320 --> 00:01:29.370 So the goal of root cause analysis or RCA 27 00:01:29.370 --> 00:01:32.550 is to uncover the root of the issue, 28 00:01:32.550 --> 00:01:36.720 be it a technical vulnerability, a gap in policies, 29 00:01:36.720 --> 00:01:38.970 or a need for additional training. 30 00:01:38.970 --> 00:01:42.720 Importantly, RCA is not about assigning blame 31 00:01:42.720 --> 00:01:44.790 to individuals or departments. 32 00:01:44.790 --> 00:01:47.820 Rather, it's about uncovering facts 33 00:01:47.820 --> 00:01:49.200 and building a safer, 34 00:01:49.200 --> 00:01:52.080 more secure environment for the future. 35 00:01:52.080 --> 00:01:57.080 A key technique used in root cause analysis is asking why 36 00:01:57.090 --> 00:01:59.400 over and over and over. 37 00:01:59.400 --> 00:02:03.150 This approach involves continuously questioning why each 38 00:02:03.150 --> 00:02:06.630 part of the incident occurred, breaking down the sequence 39 00:02:06.630 --> 00:02:11.460 of events, until there are no more whys to ask. 40 00:02:11.460 --> 00:02:15.390 At this point, the root cause has usually been identified. 41 00:02:15.390 --> 00:02:18.630 For instance, if a security breach occurred 42 00:02:18.630 --> 00:02:20.910 due to unauthorized access, 43 00:02:20.910 --> 00:02:24.510 root cause analysis might first ask why unauthorized 44 00:02:24.510 --> 00:02:25.920 access was possible. 45 00:02:25.920 --> 00:02:29.190 This might lead to questions about access controls, 46 00:02:29.190 --> 00:02:31.440 then to issues around monitoring 47 00:02:31.440 --> 00:02:35.190 and alerts until the analysis reveals a missing layer 48 00:02:35.190 --> 00:02:38.490 of security training or a misconfiguration. 49 00:02:38.490 --> 00:02:43.140 By continuing to ask why, RCA helps teams move past 50 00:02:43.140 --> 00:02:44.640 surface level issues 51 00:02:44.640 --> 00:02:48.090 and address the true root causes of incidents. 52 00:02:48.090 --> 00:02:52.260 One of the most important results of root cause analysis is 53 00:02:52.260 --> 00:02:55.800 that the findings are fed back into the organization's 54 00:02:55.800 --> 00:02:57.150 planning process. 55 00:02:57.150 --> 00:02:59.520 This feedback loop is critical 56 00:02:59.520 --> 00:03:03.030 because it allows the organization to adapt 57 00:03:03.030 --> 00:03:07.260 and evolve based on real incidents and responses. 58 00:03:07.260 --> 00:03:11.580 So, if RCA reveals a lack of employee training 59 00:03:11.580 --> 00:03:13.170 as a root cause, 60 00:03:13.170 --> 00:03:16.980 the organization can implement targeted training sessions 61 00:03:16.980 --> 00:03:20.670 or update their already scheduled recurring training. 62 00:03:20.670 --> 00:03:25.590 Alternatively, if RCA identifies software vulnerabilities, 63 00:03:25.590 --> 00:03:28.830 updates, or patches can be prioritized, 64 00:03:28.830 --> 00:03:32.370 this information helps improve security measures, 65 00:03:32.370 --> 00:03:35.940 update policies, and ensure that future planning 66 00:03:35.940 --> 00:03:38.010 reflects the lessons learned. 67 00:03:38.010 --> 00:03:42.202 This cyclical approach also helps reduce the likelihood 68 00:03:42.202 --> 00:03:45.180 of the same issue reappearing. 69 00:03:45.180 --> 00:03:48.570 To illustrate how root cause analysis works, 70 00:03:48.570 --> 00:03:50.190 consider a phishing attack 71 00:03:50.190 --> 00:03:53.100 that successfully compromised sensitive data. 72 00:03:53.100 --> 00:03:55.710 Initially, the team might see the issue 73 00:03:55.710 --> 00:03:57.780 as one of user error. 74 00:03:57.780 --> 00:03:59.760 Someone clicked a malicious link. 75 00:03:59.760 --> 00:04:04.410 However, by asking why repeatedly, root cause analysis 76 00:04:04.410 --> 00:04:07.710 might reveal several underlying factors. 77 00:04:07.710 --> 00:04:12.240 First, the organization may lack sufficient email filtering. 78 00:04:12.240 --> 00:04:16.290 Further, employees might not have received adequate training 79 00:04:16.290 --> 00:04:18.690 in recognizing phishing attempts. 80 00:04:18.690 --> 00:04:22.320 Finally, security policies might not be regularly 81 00:04:22.320 --> 00:04:24.330 reviewed or communicated. 82 00:04:24.330 --> 00:04:26.820 So by addressing these root causes, 83 00:04:26.820 --> 00:04:30.240 the organization can enhance email filtering, 84 00:04:30.240 --> 00:04:32.100 increase training efforts, 85 00:04:32.100 --> 00:04:35.940 and create a more effective policy review process. 86 00:04:35.940 --> 00:04:40.590 So remember, root cause analysis is a method 87 00:04:40.590 --> 00:04:43.650 for identifying the fundamental reason 88 00:04:43.650 --> 00:04:48.000 behind a security incident to prevent it from recurring. 89 00:04:48.000 --> 00:04:51.090 It involves tracing the issue to its origin 90 00:04:51.090 --> 00:04:55.410 by examining technical, procedural, or human errors. 91 00:04:55.410 --> 00:04:59.580 The process emphasizes asking why iteratively 92 00:04:59.580 --> 00:05:03.563 until the true cause is revealed, allowing organizations 93 00:05:03.563 --> 00:05:07.350 to address the underlying issue rather than 94 00:05:07.350 --> 00:05:09.120 surface level symptoms. 95 00:05:09.120 --> 00:05:13.650 Ultimately, root cause analysis findings are integrated into 96 00:05:13.650 --> 00:05:17.910 future planning, supporting proactive security improvements 97 00:05:17.910 --> 00:05:22.053 without placing blame on individuals or departments.