WEBVTT 00:07.280 --> 00:11.690 After everything is said and done, you're going to have to report out on the different aspects of what 00:11.690 --> 00:16.850 you're trying to accomplish or what you have accomplished in the past, whether it's through cybersecurity 00:16.850 --> 00:20.000 or information security or even information technology. 00:20.030 --> 00:25.220 When that process, we often utilize KPIs, which we've discussed earlier in this coursework. 00:25.220 --> 00:30.020 But how does that translate to actually reporting to hire about what's going on throughout the entire 00:30.020 --> 00:30.740 process? 00:30.740 --> 00:36.350 When it comes to metrics, we often need to utilize Excel spreadsheets or different functionalities 00:36.350 --> 00:43.550 of that Excel spreadsheet to identify or perpetuate the idea of what we've accomplished within our process. 00:43.610 --> 00:49.310 I highly discourage you from simply putting out Excel spreadsheets and going, oh, here was our KPIs, 00:49.310 --> 00:51.350 this is what we met, and so on and so forth. 00:51.380 --> 00:57.440 While those numbers are great and they identify very quickly what you accomplished or where you fall 00:57.440 --> 01:02.600 within the overall process, the fact is that you need to go through and actually articulate what those 01:02.630 --> 01:04.100 different indicators are. 01:04.100 --> 01:08.960 Within my own background, we had different indicators of how many tickets I worked, how many were 01:08.960 --> 01:14.360 successfully, uh, fixed, and how many problems I actually fixed, depending on where that problem 01:14.360 --> 01:16.250 inlined within our different systems. 01:16.280 --> 01:21.410 For instance, if I had a security issue with a specific alarm or alert, we would dictate. 01:21.410 --> 01:22.670 Here's the alert number. 01:22.700 --> 01:24.140 Here was the overall problem. 01:24.140 --> 01:25.910 Here's what I did to fix the problem. 01:25.910 --> 01:31.010 And then we would keep track of all those different aspects and provide a KPI specific to that different 01:31.010 --> 01:31.520 alert. 01:31.520 --> 01:36.830 This provided context to how long it took to fix the issue, how long it took to identify the issue 01:36.830 --> 01:42.740 and what the fix was, and if the fix changed from alert from alert, even though it was the same alert 01:42.740 --> 01:49.100 per process, these different KPIs can provide management with key details about how to streamline the 01:49.100 --> 01:53.180 issue, or to identify if I need to fix the issue in a different way. 01:53.210 --> 01:58.640 Maybe there was a fact where one technician is fixing the alert in a specific way, and it only takes 01:58.640 --> 02:03.140 five minutes, but this other technician is fixing it a different way, but it's taking 15. 02:03.170 --> 02:08.520 They may need to readdress that specific issue and provide training to the overall infrastructure of 02:08.520 --> 02:11.970 the overall employees on how to fix it in a more efficient manner. 02:11.970 --> 02:17.430 They may find an issue didn't really fix the problem because the alarm re-occurred or the alert re-occurred 02:17.430 --> 02:22.140 where we had to send another technician out to fix the same issue only a day or two later. 02:22.140 --> 02:26.100 But the individual technician didn't realize it because we have so many different technicians doing 02:26.100 --> 02:29.430 so many different things that they just didn't put one and one together. 02:29.430 --> 02:34.620 When it comes to KPIs or key performance indicators, we really need to not only understand what the 02:34.620 --> 02:38.850 key performance indicator is, but how it translates to business needs. 02:38.880 --> 02:43.860 Those business needs may translate to different policies or different procedures on how we interact 02:43.860 --> 02:45.330 with the technology itself. 02:45.330 --> 02:51.960 Those KPIs may come into question when you're presenting those specific stats on how you can evolve, 02:51.960 --> 02:57.060 or how you can change those stats for the better, or get down those numbers when you're reporting it 02:57.060 --> 02:58.290 to upper level management. 02:58.290 --> 03:00.750 There's also different trends that come into play. 03:00.750 --> 03:06.540 We often identify different trends as a phishing attack or how generative AI is being utilized within 03:06.540 --> 03:07.290 our structure. 03:07.290 --> 03:09.210 Maybe threat detection. 03:09.240 --> 03:15.120 Uh, it's not often where a higher level management will see a specific news article or a sister company 03:15.120 --> 03:21.210 and they decide, oh crap, I need to address this specific issue because this company, which is our 03:21.210 --> 03:27.390 competition, just had a bad publicity news article written about them specifically for this cyber threat. 03:27.390 --> 03:32.610 And so they jumped through hoops to make sure that we're addressing that issue before it becomes a major 03:32.610 --> 03:35.550 topic within our own individual company. 03:35.580 --> 03:38.970 These specific trends often come into play at different avenues. 03:38.970 --> 03:42.930 They can also be lead ways into problems that we may see in the future. 03:42.930 --> 03:48.570 If I have a company that's a direct competitor and I'm friends with their with their CISO or within 03:48.570 --> 03:54.300 that specific industry, maybe I can get a leg up on my own company going through the same issue and 03:54.300 --> 03:57.540 stopping it before it becomes a major issue to evolve around it. 03:57.570 --> 04:03.510 It's not uncommon to have different CISOs attend conferences and networks with one another to identify 04:03.540 --> 04:09.460 different aspects of their own corporation or government under an NDA that says, my company faced this 04:09.460 --> 04:14.650 issue, this issue and this issue, and for the trends to evolve from that particular issue, where 04:14.650 --> 04:19.450 you may have the CSO coming down and saying, hey, I want you to go through and start looking at our 04:19.450 --> 04:26.080 company for different policy validations, for specific, um, uh, specific issue, whether it's malware, 04:26.230 --> 04:32.200 whether it's a, uh, authenticated use factors because they saw something that you're unaware of that 04:32.200 --> 04:33.820 is developing into a trend. 04:33.850 --> 04:38.710 This often comes in different plays or different aspects of our organization, where a lot of times 04:38.710 --> 04:43.690 we may not know specifically what we're looking for, but we've been directed by higher level management 04:43.690 --> 04:47.500 to proceed forward in a specific issue or topic. 04:47.500 --> 04:50.110 That may not make a lot of sense to us. 04:50.140 --> 04:55.000 Just realize that there's a lot of upper echelon stuff going on in different communication factors that 04:55.000 --> 04:57.370 are being regulated to those different CISOs. 04:57.400 --> 05:04.300 It's also not common or uncommon to see, uh, the federal government come out or for different enterprise 05:04.300 --> 05:08.830 environments to interface with federal governments, where a notice has come out specifically stating, 05:08.830 --> 05:12.310 hey, there's this attack that we've seen in different industries. 05:12.310 --> 05:14.050 Make sure you're aware of it. 05:14.050 --> 05:20.980 There's the complexities of this attack where you're offered advice on how to arrange your email, uh, 05:20.980 --> 05:24.130 technology to identify specific attacks. 05:24.130 --> 05:28.420 These all develop into different trends or technologies that you may not be aware of. 05:28.450 --> 05:30.220 On the other hand, you may be aware of them. 05:30.220 --> 05:32.920 You may be tasked to go through and look at different news articles. 05:32.920 --> 05:37.660 Or maybe you're listening to a blog post where you're seeing an uptick in different attack methodologies 05:37.660 --> 05:42.610 being utilized, and you take it upon yourself to go through, identify those trends, and then safeguard 05:42.610 --> 05:45.160 your systems against those trends moving forward. 05:45.190 --> 05:49.000 These need to be attributed to a specific report and why you're doing it. 05:49.030 --> 05:49.630 Well. 05:49.630 --> 05:54.070 More often than not, high level management dictates down to us, and we don't really have to file that 05:54.070 --> 05:54.370 report. 05:54.370 --> 05:59.500 We just make a little line on a reporting status that says for management, we've started to grow or 05:59.500 --> 06:03.670 evolve towards this specific attack vector or for this specific technology. 06:03.670 --> 06:05.020 And that's a one and done thing. 06:05.020 --> 06:10.750 But if you've identified it as a proactive cyber defender or an analyst, that's saying, I've seen 06:10.750 --> 06:16.930 this in the different blogs or the different news articles, and we need to arrange or evolve our technology 06:16.930 --> 06:18.190 against a specific attack. 06:18.220 --> 06:23.560 You may be asked why, and that report needs to reflect why you're moving against this specific trend, 06:23.590 --> 06:29.440 why you used manpower that may not be readily available to safeguard against this specific trend or 06:29.440 --> 06:34.000 an attack in a proactive nature, and that report needs to be reflected as such. 06:34.030 --> 06:35.710 There's also the top ten. 06:35.740 --> 06:41.350 OWASp came out with the top ten every 3 or 4 years, and management loves to see this on reports. 06:41.350 --> 06:45.520 They love the little graphics that are associated with it that says, oh, I'm following the top ten 06:45.550 --> 06:46.090 now. 06:46.090 --> 06:50.500 You can hear my voice into the laughter behind it, because a lot of times you're thinking to yourself, 06:50.500 --> 06:52.060 oh great, I get to deal with top ten. 06:52.090 --> 06:57.010 However, I don't want to detract from the actual usability of the top ten report, especially when 06:57.010 --> 06:59.800 it comes to web application and web pages. 06:59.800 --> 07:03.580 The top ten provides us a streamlined narrative to interact with. 07:03.610 --> 07:09.490 With upper management, we can identify specific factors in our web applications that should be listed 07:09.490 --> 07:14.510 on our reporting mechanisms for upper level management, because it directly attributes to something 07:14.540 --> 07:19.430 a third party company that's widely known for web application security moving forward. 07:19.430 --> 07:24.980 So we may identify, for instance, cryptographic failures in web applications and then perplex onto 07:24.980 --> 07:32.540 why that report going, hey, I upgraded our SSL or TLS from version 1.2 to 1.3, and it directly reflects 07:32.540 --> 07:35.360 the OWASp top ten and cryptographic failures. 07:35.360 --> 07:37.010 So we'll see OWASp top ten. 07:37.010 --> 07:41.990 And it's easier for managers to go back through and identify a specific technological issue and cross 07:41.990 --> 07:45.170 reference to this open source intelligence gathering for OWASp. 07:45.200 --> 07:51.860 And then it just kind of solidifies why you did what you did and perplexity towards the the aspect of 07:51.980 --> 07:53.360 your reporting structure. 07:53.390 --> 07:58.790 Critical vulnerabilities often are up from Cvss scores or from top ten trends, or something you've 07:58.790 --> 08:00.680 never seen from a zero day attack. 08:00.680 --> 08:06.380 We want to go through and identify the life cycle of a zero day attack, and be aware of those zero 08:06.380 --> 08:08.690 day attacks as they're impending into our system. 08:08.690 --> 08:13.250 There may be a brand new attack that we've never seen before, and it may have taken you 12 hours to 08:13.280 --> 08:13.670 fix it. 08:13.670 --> 08:16.010 You've gone through the entire incident planning stage. 08:16.010 --> 08:17.510 You've remediated the issue. 08:17.540 --> 08:20.210 You've provided compensating controls and mitigations. 08:20.210 --> 08:24.140 You've worked your butt off for 60 straight hours, and then you did the lesson learned. 08:24.140 --> 08:28.820 And now it's time to report back up the chain to what you did and how you fixed the issue. 08:28.850 --> 08:35.210 Oftentimes, we need to identify the whole life cycle of a zero day attack because you're not talking 08:35.240 --> 08:36.650 to technical personnel. 08:36.680 --> 08:42.350 Upper level management is very rarely up to par when it comes to these technology issues or our our 08:42.350 --> 08:43.430 speaking patterns. 08:43.430 --> 08:50.630 When we come to technology, we may spout out things like TLS or SSL or port 25 or port 53, or you 08:50.630 --> 08:51.380 get the point. 08:51.380 --> 08:55.190 And while it makes perfect sense to us as cyber security experts, it doesn't make a whole lot of sense 08:55.190 --> 08:56.300 to upper level management. 08:56.300 --> 08:57.710 That's not their job. 08:57.740 --> 09:03.230 Our job is not only to know that technical jargon, but also be able to translate it for the business 09:03.230 --> 09:04.190 level people. 09:04.220 --> 09:09.350 To understand what we're talking about, we need to provide that theory or that dictionary to understand, 09:09.380 --> 09:14.720 hey, this is what we're talking about, and then put it into layman's terms for our department heads 09:14.720 --> 09:19.910 and for our upper level management when we go through that process, we also need to be very technical 09:19.910 --> 09:21.260 and then break it down. 09:21.290 --> 09:27.290 Don't ever underestimate the fact of how a senior level management may have insight or may have a technical 09:27.290 --> 09:28.070 background. 09:28.340 --> 09:33.080 I had a buddy of mine who thought the manager didn't have a technical background. 09:33.110 --> 09:39.710 The manager had an MBA and had no idea, but in a previous life they were a software developer and were 09:39.710 --> 09:42.200 one of the original people that had gotten into cybersecurity. 09:42.200 --> 09:47.960 They were very up to date with the process and the schematics of cybersecurity and how computers function. 09:47.960 --> 09:55.790 But the technician had talked down to them, not physically or in a way that denoted a level of scrutiny, 09:55.790 --> 10:01.730 but in a way of I'm going to make, say, everything so stupid simple that it almost made it hard for 10:01.730 --> 10:06.500 the software engineer or the CISO to actually understand what they were talking about, because they 10:06.530 --> 10:08.030 had dumbed it down so much. 10:08.270 --> 10:13.340 And I remember the CISO, as this guy is explaining this technical layman's terms of, oh, well, we 10:13.340 --> 10:18.810 had a port, which is and proceeded to talk down in a dumb way to him, where the CISO CSO actually 10:18.810 --> 10:22.860 stopped in mid-sentence and said, stop, I need you to talk to me in technical terms. 10:22.860 --> 10:24.120 Don't talk dumb to me. 10:24.120 --> 10:26.700 And he literally said it that way in an offensive manner. 10:26.700 --> 10:31.230 So we not only want to provide the technical jargon, but we also want to provide the layman's terms 10:31.230 --> 10:34.620 in a way that doesn't denote or diminish from their intelligence. 10:34.620 --> 10:38.400 If you start to talk down to somebody as you're going through their report, people will pick it up 10:38.400 --> 10:42.570 very quickly and you will be looked down upon yourself as somebody that's hard to deal with or someone 10:42.570 --> 10:43.290 to talk to. 10:43.320 --> 10:48.390 So we want to provide it in a very business and professional manner from a technical perspective, but 10:48.390 --> 10:51.480 also from a non-technical perspective that is easy to understand. 10:51.510 --> 10:57.000 By providing both avenues, we're providing a way for business managers to look at it from different 10:57.000 --> 10:59.760 perspectives and understand where we're coming from. 10:59.760 --> 11:05.280 We've also talked about service level agreements, where we have a specific boundary or a specific benchmark 11:05.280 --> 11:07.650 that we need to hit within a service level agreement. 11:07.650 --> 11:13.500 We may say, hey, I need to have 99.1% update time, and then we have a service level objectives that 11:13.500 --> 11:17.010 says even though our SLA is only 99.1%. 11:17.040 --> 11:22.260 Our SLO or objective for our company Internally is 99.3. 11:22.260 --> 11:26.520 And then our SLI is the real number when we're identifying these on a reports. 11:26.550 --> 11:29.940 A lot of times we'll put this in broad or very numeric functions. 11:29.940 --> 11:35.550 We're saying my SLA is 99.1, my SLO is 99.3. 11:35.550 --> 11:39.930 And my SLI, which is the number it actually hit is 99.2. 11:39.960 --> 11:44.970 While yes, we hit that SLA and the company is happy with us, we failed to meet our SLO. 11:45.000 --> 11:48.780 You may have to go into details of why our SLA is our SLA. 11:48.810 --> 11:51.750 Usually this is just a contract line that we're putting out. 11:51.750 --> 11:53.820 We're saying, oh well, we have a contract with this company. 11:53.820 --> 11:59.010 So our SLA is this and it's written by contractual language, but we may have to identify our specific 11:59.070 --> 12:01.680 SLO or why we came up with that SLO. 12:01.710 --> 12:06.300 Sometimes you may be the third person in line, and you're not exactly sure why we came up with this 12:06.330 --> 12:10.920 SLO, other than the fact that you were told the SLO is the SLO because it's always been the SLO. 12:10.950 --> 12:12.780 Does that need to be evolved or changed? 12:12.810 --> 12:18.390 You need to be ready, especially for reporting this out to explain why we made an SLO that was higher 12:18.390 --> 12:21.630 than our SLA, and that the reasoning behind that. 12:21.630 --> 12:27.250 So when you identify an SLO throughout your reporting structure, make sure that you clearly identify 12:27.250 --> 12:34.240 and articulate why the SLO is higher than the SLO and SLA, and why we are moving forward with that 12:34.270 --> 12:35.650 SLO hitting that point. 12:35.950 --> 12:38.980 Slides are a little bit more indicative of the real numbers. 12:38.980 --> 12:45.430 If I've got an SLI and I fail to meet my SLA, I need to be able to readily explain why our SLI was 12:45.430 --> 12:47.410 below that SLA and SLO. 12:47.440 --> 12:53.920 In terms of actual numbers, it's not enough to just say my SLA was 99 when my SLA is 99.1. 12:53.920 --> 12:58.630 We need to come up with why we failed to meet the standard, what we're doing to fix that standard, 12:58.660 --> 13:04.930 i.e. meet that standard, and the different ideologies or technologies that we're going to utilize moving 13:04.930 --> 13:05.500 forward. 13:05.500 --> 13:10.510 If we fail to meet our SLA two weeks ago, they're going to expect a rise since then. 13:10.510 --> 13:12.490 So be prepared on your report to say yes. 13:12.490 --> 13:18.640 We failed to meet our SLA last month, but so far in this month, we're tracking at this percent value. 13:18.670 --> 13:24.370 Those are questions that you can readily see coming through your brief with your higher level managers.