WEBVTT 00:07.340 --> 00:08.690 As a security analyst. 00:08.690 --> 00:11.720 A lot of times we concentrate on the technical nature of our jobs. 00:11.720 --> 00:17.540 We look at the side of understanding that we are technically proficient, and that we're being paid 00:17.540 --> 00:20.630 well for the fact that we know understand how to use the tools. 00:20.630 --> 00:26.300 We understand logging, we understand operating systems, we understand networks, we understand a plethora 00:26.300 --> 00:27.410 of technology. 00:27.410 --> 00:33.470 The problem is, is that our job isn't just the technical world, especially as a true security analyst. 00:33.500 --> 00:35.780 We need to understand the business side of it. 00:35.780 --> 00:38.240 The business side is often involves reporting. 00:38.240 --> 00:44.450 It does no good to be able to go through and be a technical wiz kid, and be able to identify specific 00:44.450 --> 00:46.400 problems in different aspects. 00:46.400 --> 00:51.230 If you can't communicate properly to those that need to know about what we found or what we're doing, 00:51.230 --> 00:56.120 it's great to be able to talk jargon with other SOC analysts and go, oh, I went and I utilized the 00:56.120 --> 01:01.670 SEM, and I identified this malware and I utilized this logging algorithm and I created my own script. 01:01.670 --> 01:02.330 That's great. 01:02.330 --> 01:03.170 That's fantastic. 01:03.200 --> 01:03.470 You're. 01:03.470 --> 01:05.000 You're great at what you do. 01:05.000 --> 01:09.200 But how does that translate over to somebody that has absolutely no idea what you're talking about when 01:09.200 --> 01:10.700 you start talking tech speak? 01:10.700 --> 01:14.240 And this is where vulnerability management reporting really comes into play. 01:14.240 --> 01:19.310 We need to be able to put all those technical words and all those technical definitions into a format 01:19.310 --> 01:23.480 that is able to be read by somebody that isn't necessarily technical. 01:23.510 --> 01:28.580 Granted, we're not going to dumb it down to a point where we have to spell everything out, but we 01:28.580 --> 01:35.840 need to provide a report that's able for our stakeholders to be able to read it with some level of technical 01:35.840 --> 01:40.250 inefficiency, meaning that, yeah, they understand part of the jargon, but they're not experts like 01:40.250 --> 01:40.880 you are. 01:40.910 --> 01:44.030 The jobs are separated, they're different, and you need to understand that. 01:44.030 --> 01:47.630 So when we go through and we start reporting, we need to provide assessment results. 01:47.660 --> 01:53.300 A lot of times those results are prioritized or provided to us via the tool that we're utilizing, whether 01:53.300 --> 01:55.340 it's Splunk or another Cem system. 01:55.340 --> 01:58.280 But the fact is those reports are not always flawless. 01:58.310 --> 02:01.790 And so a lot of times we'll go through and we'll identify identified specific assessments that have 02:01.790 --> 02:02.330 occurred. 02:02.330 --> 02:07.760 And we need to highlight these problems because you as a SOC analyst or a security analyst, your job 02:07.760 --> 02:09.680 is to understand what that means. 02:09.680 --> 02:12.290 But somebody that's in management may not. 02:12.290 --> 02:15.590 And so we need to be able to highlight the real issues that are going through. 02:15.590 --> 02:16.940 And that's part of your job. 02:16.940 --> 02:19.370 When are you able to risk prioritization. 02:19.370 --> 02:24.230 Meaning we need to say, yeah, the Cvss score on this is like a 7.8. 02:24.230 --> 02:29.450 But this one down here, which is maybe a 7.3, is actually more critical to our organization. 02:29.450 --> 02:30.590 And here's why. 02:30.590 --> 02:33.950 That risk prioritization is important for the aspect of business. 02:33.950 --> 02:40.160 And we need to communicate to our leadership or to our stakeholders why we're utilizing this type of 02:40.160 --> 02:44.450 prioritization, rather than what was spit out by this machine. 02:44.450 --> 02:46.370 We also need to look at compliance status. 02:46.400 --> 02:50.750 A lot of times when we go through these reports, there may be a compliance issue that we need to be 02:50.750 --> 02:55.790 aware of, that our management needs to be aware of, and they don't necessarily have the track record 02:55.790 --> 03:01.500 or the understanding that we do from an analyst side So if you've got a compliance issue that may have 03:01.500 --> 03:06.300 a very low risk score, but it will cost the company hundreds of thousands, if not millions of dollars 03:06.300 --> 03:08.610 because we're not falling within compliance. 03:08.610 --> 03:13.620 We need to work on that first, and we need to be able to dictate to our leadership why we're going 03:13.650 --> 03:14.460 towards that first. 03:14.490 --> 03:15.960 There's also trends. 03:16.050 --> 03:19.170 While back, there was a ransomware trend that was going around. 03:19.170 --> 03:24.270 We need to be able to say, yeah, normally we would go after this malware first, but we have indicators 03:24.270 --> 03:26.970 of ransomware, which is trending right now. 03:27.000 --> 03:30.330 Maybe we should look at this first because we don't want to have to go through that process. 03:30.360 --> 03:35.550 We also need to be able to dictate the different remediation processes that we're currently undergoing. 03:35.580 --> 03:40.080 If I've been working on a remediation process for 2 or 3 days and it's almost done, then I need to 03:40.110 --> 03:44.880 provide that update to our managers so that they understand where we are in that process. 03:45.060 --> 03:48.600 I've had managers in the past where they're like, okay, well, you know, you've been working on this 03:48.600 --> 03:49.230 for three weeks. 03:49.230 --> 03:50.910 No, I brought this up to you. 03:50.940 --> 03:54.630 You know, two days ago it had a different problem three weeks ago. 03:54.660 --> 03:58.260 A lot of times you'll find that managers look at different aspects differently than we do. 03:58.290 --> 04:02.490 They see the piece of equipment, but they don't really understand what we're doing with that equipment 04:02.550 --> 04:06.660 sometimes because they don't bother to read it, sometimes because it looks very similar, when in fact 04:06.660 --> 04:07.620 it's very different. 04:07.620 --> 04:13.200 And it's our job as the security experts, as the technical experts to be able to, uh, to explain 04:13.200 --> 04:18.090 to them why we're going through the different process or how this remediation process is undergoing. 04:18.120 --> 04:24.180 It's not uncommon also to have a main remediation process or a main problem that we've been working 04:24.180 --> 04:28.590 on, and we solve part of it, but we didn't solve the whole thing with those compensating controls 04:28.590 --> 04:30.480 or with that mitigation process. 04:30.480 --> 04:34.530 And it takes more than just a week to go through it, and they just keep seeing the same thing popping 04:34.530 --> 04:35.370 up the reports. 04:35.370 --> 04:36.840 They need to understand why. 04:36.840 --> 04:39.510 And so we need to keep a careful mind of that side of that as well. 04:39.540 --> 04:41.160 Finally, recommendations. 04:41.190 --> 04:46.110 Uh, we don't usually have the capability or the authority to say we're going to work on this because 04:46.110 --> 04:47.160 of X, Y, and z. 04:47.190 --> 04:53.340 What we need to be able to do is recommend a remediation process, or mitigation process, or some type 04:53.340 --> 04:57.600 of process of what we're going to attempt to do and why we're going that route. 04:57.600 --> 05:03.510 This is all part of that vulnerability Vulnerability management reporting aspect where the recommendations 05:03.510 --> 05:04.350 is just as important. 05:04.380 --> 05:09.750 A lot of times as the remediation process or even the assessment tools in order to explain, hey, my 05:09.750 --> 05:14.820 recommendations are we do this because it costs less money or because it does this, or it's only going 05:14.820 --> 05:19.080 to take me like three hours of repair time rather than this big issues, which is going to cost me, 05:19.110 --> 05:24.630 you know, four weeks of time of four people I can knock out, you know, 30 issues right off the bat 05:24.630 --> 05:25.200 within a day. 05:25.200 --> 05:28.800 So let's work on those 30 issues today, and we'll start on the big issue tomorrow. 05:28.920 --> 05:33.690 And that's part of that recommendation process that we often undergo as part of our jobs. 05:33.750 --> 05:38.190 When we go through this process, through vulnerability management, we need to be able to identify 05:38.220 --> 05:41.070 specifically which stakeholders belong to what. 05:41.100 --> 05:47.070 Uh, oftentimes we'll see stakeholders as a person or a department and we'll say, oh, well, the stakeholder 05:47.070 --> 05:53.010 from my organization is the C-suite, or it's my director, or it's this person, uh, specifically 05:53.010 --> 05:54.450 related to this technology. 05:54.450 --> 05:56.640 And that's yeah, those are all stakeholders. 05:56.640 --> 05:58.380 But what about the other stakeholders? 05:58.380 --> 06:05.010 If I'm working on a financial system or part of the financial enterprise, meaning the enterprise environment 06:05.010 --> 06:11.130 or the segment that is specific towards accounting or HR, their stakeholders and our technology. 06:11.160 --> 06:16.110 We just don't go around unplugging stuff or changing the enterprise environment without letting them 06:16.110 --> 06:17.430 know their stakeholders. 06:17.430 --> 06:21.840 And we need to identify those stakeholders as such so that they're aware of what we're doing. 06:21.870 --> 06:28.950 Nothing sucks more from a business aspect of having that department head, or have the department as 06:28.950 --> 06:34.890 a whole working on a major project only to have IT or cybersecurity come in and blast everything out 06:34.890 --> 06:39.240 because they didn't let financial know or that department know what's going on. 06:39.270 --> 06:40.680 This is a major issue. 06:40.680 --> 06:45.150 So we need to identify those stakeholders and keep them in the communication loop before we start messing 06:45.150 --> 06:50.160 with their specific technologies, because there could be some underlying issues, underlying projects 06:50.160 --> 06:52.410 that are ongoing that we don't know about. 06:52.410 --> 06:57.750 And doing a normal day to day basis and just unplugging it whenever we feel like could really hamper 06:57.780 --> 07:03.550 their ability to proceed, which is going to create some friction between our departments and cybersecurity. 07:03.580 --> 07:06.430 We often have friction with other departments, whether we mean to or not. 07:06.430 --> 07:07.750 It's just part of our job. 07:07.750 --> 07:13.660 Let's kind of minimize those friction points as much as possible by identifying those stakeholders and 07:13.660 --> 07:16.390 then communicating with those stakeholders what we're trying to do. 07:16.420 --> 07:18.910 We also need to identify vulnerabilities. 07:18.910 --> 07:23.680 It goes without saying that vulnerability reporting management also includes vulnerabilities, but you'd 07:23.710 --> 07:27.550 be surprised how many times a scan goes out or an assessment goes out. 07:27.550 --> 07:30.220 And we provide this detailed list of everything that's going on. 07:30.250 --> 07:32.710 Somebody picks it up, they're looking at it and they're overwhelmed. 07:32.710 --> 07:35.350 They have no idea what in the world is going on. 07:35.380 --> 07:40.120 Along with our recommendations path, we often need to identify specific flaws or weaknesses. 07:40.120 --> 07:42.970 When our system, we often perform a scan. 07:42.970 --> 07:49.000 The scan identifies vulnerabilities, but they don't necessarily identify specific flaws. 07:49.030 --> 07:55.180 As an internal working expert in your field, you should be able to identify specific flaws or weaknesses 07:55.180 --> 07:58.150 within the system that a report doesn't normally turn out. 07:58.150 --> 08:04.300 That means maybe I have a firewall or a web server that is, you know, beyond its power curve. 08:04.300 --> 08:09.430 It's getting ready to hit its end of life cycle, where Microsoft or another organization isn't going 08:09.430 --> 08:10.390 to support it anymore. 08:10.420 --> 08:12.820 That's a weakness that's getting ready to evolve. 08:12.820 --> 08:17.470 So we need to be able to go through and say, yeah, we have this piece of equipment that's hitting 08:17.470 --> 08:19.510 end of life in the next three months. 08:19.510 --> 08:21.670 We need to plan to replace that equipment. 08:21.670 --> 08:22.930 I need budget for it. 08:22.960 --> 08:26.470 A lot of times three months is not enough time, especially in enterprise environment. 08:26.470 --> 08:27.400 They need a year. 08:27.400 --> 08:32.980 So you'll see Microsoft come out and say this operating system is no longer going to be supported at 08:32.980 --> 08:33.520 this time. 08:33.520 --> 08:35.320 They usually give us a year to 18 months. 08:35.320 --> 08:40.300 We need to communicate that to management to say, yeah, I've got three servers that are no longer 08:40.300 --> 08:43.180 being supported by Microsoft in 12 months. 08:43.180 --> 08:47.890 We need to plan to replace those or upgrade those or do something with them, because we don't want 08:47.920 --> 08:50.230 unsupported servers on our enterprise environment. 08:50.230 --> 08:53.020 That's going to lead to further problems in the future. 08:53.020 --> 08:55.540 So understanding those flaws or weaknesses is important. 08:55.570 --> 08:58.150 But it doesn't just include end of life items. 08:58.150 --> 09:05.230 It also includes something like, um, uh, inadequate configurations or design flaws or even human 09:05.230 --> 09:05.680 errors. 09:05.680 --> 09:07.960 All of those can interact with vulnerabilities. 09:07.960 --> 09:13.120 There was a piece of equipment when I worked for a different company where by itself it was fine, but 09:13.120 --> 09:17.410 as soon as you added this third party vendor into it, it created a vulnerability within the system 09:17.410 --> 09:19.660 that they knew about, but nobody ever fixed. 09:19.660 --> 09:22.330 That's a weakness that wasn't being properly reported. 09:22.330 --> 09:26.560 So we need to identify that weakness and then put it part of our vulnerability management reporting 09:26.560 --> 09:27.550 process. 09:29.080 --> 09:34.180 We need to identify specific technical and non-technical aspects within our environment. 09:34.180 --> 09:41.680 If I've got a $3 billion security infrastructure and cybersecurity is well funded, which never happens, 09:41.680 --> 09:42.880 but let's pretend it does. 09:42.910 --> 09:43.480 Right? 09:43.480 --> 09:45.880 And we've got every tool we could ever ask for. 09:45.880 --> 09:50.350 And we have all these these security measures and we are just rocking and rolling. 09:50.350 --> 09:52.750 Uh, that doesn't mean that our system is 100% safe. 09:52.750 --> 09:53.380 Number. 09:53.410 --> 09:58.090 Never underestimate the stupidity of non-technical personnel. 09:58.090 --> 10:02.560 People are out there and there's a lot of stupid people out there, as I'm sure you know, it only takes 10:02.560 --> 10:07.720 one person to click on a link or do something stupid in your system to make that billion dollar system 10:07.720 --> 10:08.920 come tumbling down. 10:08.950 --> 10:14.470 We need to be able to identify specific hosts or specific problems, both technical and non-technical, 10:14.470 --> 10:19.870 whether it's people or whether it's a policy or procedure that could affect our enterprise environment 10:19.870 --> 10:20.800 as a whole. 10:20.860 --> 10:24.280 Sometimes that's IP addressing, sometimes it's segmentation. 10:24.280 --> 10:29.110 Maybe it's just a policy that doesn't make sense because it was written a decade ago and never been 10:29.110 --> 10:29.740 updated. 10:29.770 --> 10:35.080 We need to be able to identify both technical and non-technical problems within the individual clients 10:35.080 --> 10:40.780 or the individual enterprise environment and persuade or I should say, comment on those as we're going 10:40.780 --> 10:41.200 through. 10:41.230 --> 10:45.520 Now, a lot of times there would be under vulnerabilities providing specific weaknesses or flaws in 10:45.520 --> 10:46.330 our system. 10:46.330 --> 10:52.330 But how do you identify a non-technical problem as being a flaw or weakness, or a vulnerability that 10:52.330 --> 10:54.100 would need to be an affected host? 10:54.100 --> 11:00.610 And that's really that's part of the report comes into play We also need to identify specific risk scores. 11:00.610 --> 11:06.670 We talked about risk management before, but risk scores kind of point out a specific measure. 11:06.670 --> 11:11.950 As we're going through the entire vulnerability management reporting process, we really need to be 11:11.980 --> 11:18.520 able to go through and identify different Cvss scores or different scores that Quarless or Openvas or 11:18.520 --> 11:23.920 any of these scans provide us and go, yeah, the critical vulnerabilities and exposure score is this. 11:23.920 --> 11:29.200 Sometimes those scores work in our favor and we're able to convince management, oh, it's got a 9.1 11:29.200 --> 11:29.800 CVE. 11:30.100 --> 11:33.610 This is something we need to take care of immediately, because it's going to provide all kinds of problems 11:33.610 --> 11:34.120 with it. 11:34.120 --> 11:39.190 At the same time, our expertise needs to come into play and go, well, yeah, I know it's only a 5.6 11:39.190 --> 11:44.920 CVE, but for our specific system, this isn't coming into play, and it's actually more critical for 11:44.920 --> 11:48.460 our enterprise environment than this 9.1. 11:48.460 --> 11:49.960 Now does that occur often? 11:49.960 --> 11:51.970 No, it occurs very rarely. 11:51.970 --> 11:53.230 But it does happen. 11:53.230 --> 11:57.610 And you as a cybersecurity expert, need to be able to dictate those different aspects of it We need 11:57.610 --> 12:02.360 to be able to dissect that CVV score too, because don't expect management just to come in and go, 12:02.390 --> 12:08.120 oh, it's a CV 9.1 and you want to fix this 5.6 it's going to throw some shade on you and you're going 12:08.150 --> 12:12.740 to have to explain to them in a professional and technical manner why you want to go after this. 12:12.740 --> 12:18.290 5.6 at the same point, we need to be able to identify why the score is a 9.1 and compare and contrast. 12:18.290 --> 12:22.280 And this is important when it comes into these CV scores, where you need to be able to actually read 12:22.280 --> 12:27.080 them inside your environment to make a compelling argument to your management of why you want to do 12:27.110 --> 12:28.430 what you want to do. 12:28.730 --> 12:34.010 CV scores provide us a great baseline, but we want to get out of that phase of just saying, oh, it's 12:34.040 --> 12:39.350 a CV score of 9.1 and living and breathing by that CV score, because sometimes it just doesn't make 12:39.350 --> 12:41.000 sense to go through that process. 12:41.150 --> 12:42.500 It's really, really important. 12:42.530 --> 12:43.760 I cannot express this enough. 12:43.790 --> 12:49.610 You must understand how CV score works in order to accurately identify the vulnerability of your reporting 12:49.610 --> 12:52.340 management system that you want to utilize for your organization. 12:52.370 --> 12:56.840 Don't fall into that trap where the score is this, and I'm just going to do highest and lowest. 12:56.870 --> 12:58.460 That is a mistake waiting to happen. 12:58.490 --> 13:03.770 Mitigation is the process of understanding those CBE scores and those vulnerabilities and those flaws 13:03.800 --> 13:06.170 that come into your system, but being able to mitigate it. 13:06.200 --> 13:10.460 I may have a 9.1 CBE score, and I've thrown some defense in depth. 13:10.460 --> 13:12.230 I've solved some mitigating factors in there. 13:12.260 --> 13:17.060 But even though the scan is coming back and saying it's still a 9.1 with the mitigation factors I have 13:17.060 --> 13:20.840 put in place, it's more closely related to probably a 3.2. 13:21.230 --> 13:22.700 Does it actually happen like that? 13:22.700 --> 13:23.360 Absolutely not. 13:23.360 --> 13:23.660 Right. 13:23.690 --> 13:27.200 But we do those internal processes in our mind as we go forward. 13:27.230 --> 13:28.760 The CBE score is still there. 13:28.790 --> 13:30.290 We're still utilizing it. 13:30.290 --> 13:32.540 But how can we mitigate that impact. 13:32.570 --> 13:32.810 Right. 13:32.840 --> 13:39.260 Because if you remember mitigation or excuse me, um, impact times likelihood. 13:39.290 --> 13:39.740 Right. 13:39.770 --> 13:44.930 So if I can mitigate those impacts, I'm actually derailing that score down to a lower level. 13:44.930 --> 13:49.460 So I really want to go into play and provide as much mitigation to my system as possible. 13:49.490 --> 13:50.930 This could include patching. 13:50.930 --> 13:53.090 It can include, uh, configurations. 13:53.120 --> 13:55.280 It could include software updates. 13:55.400 --> 14:00.330 There's a whole host of different things that I could do, including defense in depth that would mitigate 14:00.330 --> 14:01.410 those issues. 14:01.560 --> 14:04.170 I would read through the five steps of risk management plan. 14:04.170 --> 14:06.510 It's a great summary of what's going on. 14:06.510 --> 14:08.940 You can find it at the link provided on the slide. 14:09.870 --> 14:15.750 When we look at mitigation factors and we look at flaws or vulnerabilities or even, uh misconfigurations 14:15.750 --> 14:18.540 within our system, we often need to look at recurrence. 14:18.570 --> 14:21.960 How often is the same issue popping up within our system? 14:21.960 --> 14:25.620 When we go through recurrence, we have literally three items that we could do. 14:25.650 --> 14:30.390 Just like risk, we can either accept it going, yes, I understand that this vulnerability is there. 14:30.390 --> 14:35.160 I need to understand the flaw that's taking place, and I accept that level of impact that's going to 14:35.160 --> 14:38.970 occur on my system, and it's going to occur this many times. 14:39.210 --> 14:40.410 I can mitigate the factor. 14:40.410 --> 14:43.020 We just talked about mitigation and how we want to go through that process. 14:43.020 --> 14:47.010 Or I can fully remediate the issue, i.e. get rid of it altogether. 14:47.010 --> 14:52.380 Recurrence really comes into play of the likelihood of this happening repeatedly throughout our system. 14:52.500 --> 14:58.130 I can tell you that we had a known bad piece of hardware in a company I worked for in the past, and 14:58.130 --> 15:03.020 within that we would expect to see the issue arise at least once every other week. 15:03.200 --> 15:09.890 It was a two hour drive to the specific equipment, which means every week I was driving two hours there 15:09.920 --> 15:12.080 to fix the issue and then two hours back. 15:12.110 --> 15:13.070 Here's the worst part. 15:13.100 --> 15:16.580 The fix for it that the manufacturer came out was literally just power cycling. 15:16.580 --> 15:21.890 So every week I would have to drive and take up four hours of my time, two hours there and two hours 15:21.890 --> 15:23.480 back just to power cycle the equipment. 15:23.480 --> 15:24.620 So it worked for another week. 15:24.650 --> 15:25.940 It was atrocious. 15:25.940 --> 15:26.630 It sucked. 15:26.630 --> 15:28.010 It was not good for the company. 15:28.040 --> 15:30.890 It was a waste of my time and it was a waste of company resources. 15:30.890 --> 15:32.210 But it happens. 15:32.330 --> 15:36.230 So how can we fix or remediate that issue sooner rather than later? 15:36.320 --> 15:40.430 Um, the worst part is, is that same flaw, that same vulnerability within the system that required 15:40.430 --> 15:45.530 that power cycle also meant that we had other sites that were doing the same thing that's costing your 15:45.530 --> 15:46.070 company money. 15:46.070 --> 15:49.610 And in those cases, you really have to get with the vendor and go through the process of going, I 15:49.610 --> 15:54.800 need to fix and I need one now, like not two days now, and kind of put some heat on that vendor that 15:54.800 --> 15:59.160 really goes through the management cycle, especially if you're a security analyst, to have them push 15:59.160 --> 16:03.570 on that vendor and work with other companies that have the same equipment to get the vendor to actually 16:03.570 --> 16:05.280 push through whenever possible. 16:05.460 --> 16:09.360 So recurrence, again, something that we need to be aware of as it goes through. 16:09.390 --> 16:14.130 How often does that vulnerability pop up or that flaw or that issue that I'm seeing? 16:15.180 --> 16:16.710 Finally, prioritization. 16:16.710 --> 16:19.110 We've talked about prioritization a little bit before. 16:19.110 --> 16:23.880 This is a nice little risk comparison for prioritization on a five disc chart. 16:23.910 --> 16:24.180 Right. 16:24.210 --> 16:26.400 We're looking at severity times occurrence. 16:26.400 --> 16:30.420 How critical is the issue versus how often it actually occurs. 16:30.630 --> 16:36.510 If we see this and we've talked about this before, where I've got a flaw, a vulnerability or a misconfiguration 16:36.540 --> 16:43.230 in my system and the impact that system or the severity of that system taking advantage of comes into 16:43.230 --> 16:43.440 play. 16:43.470 --> 16:43.650 Right. 16:43.680 --> 16:45.420 So let's let's kind of digress here. 16:45.450 --> 16:45.960 Right. 16:45.990 --> 16:52.470 If I've got something like telnet that I'm utilizing, well that's a pretty uh, high occurrence right. 16:52.500 --> 16:53.820 Because it's always open. 16:53.820 --> 16:56.520 So the occurrence rate would be frequent Right. 16:56.550 --> 16:59.460 However, is it a critical or major issue? 16:59.490 --> 17:06.450 I would fall or excuse me, telnet being, uh, transmission of plaintext information within my system 17:06.450 --> 17:08.190 as being very major. 17:08.190 --> 17:09.930 Uh, it could even be critical. 17:09.930 --> 17:11.490 And then we just align the two. 17:11.520 --> 17:11.760 Right. 17:11.790 --> 17:15.060 So we take the top at a for for major drop it down to frequent. 17:15.060 --> 17:17.370 And we have a critical score of 20. 17:17.400 --> 17:21.270 That means that we should probably expect that issue rather sooner rather than later. 17:21.270 --> 17:27.060 When it comes to prioritization, what about a flaw, say, in our system where the vulnerability provides 17:27.060 --> 17:28.170 remote access? 17:28.170 --> 17:32.730 That would be a critical issue because it provides remote access into our system. 17:32.730 --> 17:35.640 But you have to be a technical wiz kid in order to do it. 17:35.640 --> 17:40.680 You have to pin together certain vulnerabilities, together 3 or 4 specific vulnerabilities and provide 17:40.680 --> 17:42.030 them together and mush them together. 17:42.030 --> 17:44.910 And it takes a computer science major, somebody that really knows what they're doing. 17:44.910 --> 17:46.860 Likelihood would be improbable. 17:46.860 --> 17:52.140 And so it would drop down to a five on the critical score, which is a medium prioritization. 17:52.140 --> 17:56.970 Uh, it's just a different aspect of doing it, much like risk matrix same basic concept.