WEBVTT 00:07.220 --> 00:13.040 Let's face it, when you first run your first vulnerability scan against any new system or enterprise 00:13.040 --> 00:18.470 environment, you may see hundreds, if not thousands of different vulnerabilities, flaws or misconfigurations 00:18.470 --> 00:19.460 that pop up. 00:19.490 --> 00:23.870 How do we identify which ones should we work first versus which one we should work last? 00:23.900 --> 00:26.150 How is that system all made up? 00:26.180 --> 00:31.610 We need to prioritize the different vulnerabilities, flaws, and misconfigurations and a more readily 00:31.610 --> 00:34.640 easy to identify list per se. 00:34.670 --> 00:37.340 This means we need to identify the severity. 00:37.370 --> 00:41.570 When we look at severity, we're looking at the impact the system has on our environment. 00:41.570 --> 00:47.570 This means is the system, if it was exploited or if that vulnerability was exploited, how much damage 00:47.570 --> 00:50.150 would it do to our enterprise as a whole? 00:50.150 --> 00:55.520 If I've got a malware that exploits, that is being used to exploit a vulnerability and it takes down 00:55.520 --> 00:57.950 an entire server, that's a problem. 00:57.950 --> 01:02.730 However, it may not be a critical problem when we talk about criticality. 01:02.760 --> 01:05.790 We're talking about an individual component within our system. 01:05.790 --> 01:11.850 So I could have a high severity but a low criticality, meaning that if I have 15 servers and one drops 01:11.850 --> 01:12.600 off the air. 01:12.630 --> 01:16.830 Is it really that big of an issue on the enterprise environment as a whole? 01:16.860 --> 01:21.210 Probably not, as we normally keep our servers at 50% capacity. 01:21.240 --> 01:27.150 Losing one server, while yes it is a problem, doesn't necessarily mean that it has a high criticality 01:27.180 --> 01:27.870 value. 01:27.900 --> 01:34.830 However, at the same token, if I have one router and that one router goes down, the criticality could 01:34.830 --> 01:35.880 be enormous. 01:35.910 --> 01:39.540 It is a major problem because my entire network is shut down. 01:39.540 --> 01:44.760 So when we look at severity, we're looking at the overall impact of the environment where criticality 01:44.760 --> 01:47.220 is the critical component within my system. 01:47.250 --> 01:49.950 Finally, we need to look at resource availability. 01:49.980 --> 01:53.550 And do I have enough resources to accomplish what I'm trying to do? 01:53.580 --> 01:55.230 For prioritization. 01:55.260 --> 02:01.270 Again, if I have 15 servers and one drops off the air and I have enough resources to bring that server 02:01.270 --> 02:02.410 back online. 02:02.440 --> 02:05.710 Is the resource availability high or is it low? 02:05.740 --> 02:13.090 If I've got only one router and one repair mechanism, i.e. one replacement and it drops off the air, 02:13.120 --> 02:19.420 that's not only a high criticality, a high severity, but I also have low resource availability because 02:19.420 --> 02:23.020 there's only one of them and only one replacement. 02:23.050 --> 02:28.360 When we talk about resource availability, we're really referring to how much stock do I have available 02:28.360 --> 02:32.650 across my entire network to fix the issue if something were to happen to it. 02:34.690 --> 02:37.120 Overall, we need to look at different action plans. 02:37.150 --> 02:42.130 Action plans dictate how we define or how we do something within our network. 02:42.160 --> 02:49.060 Normally, an action plan goes into say, oh, I want to employ this software or I want to do this in 02:49.060 --> 02:49.930 my network. 02:49.960 --> 02:52.450 First we need to come up with different objectives. 02:52.450 --> 02:53.770 What is the objective? 02:53.770 --> 02:57.890 We need to define accurately and completely what we're trying to accomplish. 02:57.920 --> 02:59.900 It is no good to anybody. 02:59.900 --> 03:02.150 If you say, oh, I want to make the network better. 03:02.180 --> 03:03.740 That is not an objective. 03:03.740 --> 03:07.820 That is a value or a plan of action that we're trying to strive for. 03:07.850 --> 03:09.140 That's a guideline. 03:09.140 --> 03:15.470 An objective would be I want to make our network better by replacing all the routers with this newer 03:15.470 --> 03:22.730 router that has higher efficiency, better validation, better authentication, and better streamlined 03:22.760 --> 03:23.630 services. 03:23.630 --> 03:28.100 That would be an objective replacement of routers to make the network better. 03:28.130 --> 03:30.260 We've defined our objective. 03:30.290 --> 03:32.330 Finally, we want to do task. 03:32.330 --> 03:35.150 We want to break down the objectives into high level tasks. 03:35.180 --> 03:36.680 How are we going to do this? 03:36.710 --> 03:41.810 Well I need my asset department or my supply chain management to order the routers. 03:41.810 --> 03:46.760 I need to dictate to my operations department that they need to replace the routers during the maintenance 03:46.760 --> 03:47.180 window. 03:47.180 --> 03:50.870 Between this date and this date, I've identified different tasks. 03:50.870 --> 03:54.500 I need to assign the teams responsible for each one of those tasks. 03:54.530 --> 03:58.810 Usually this is done at the same time the tasks are identified, but not always. 03:58.840 --> 04:03.460 For instance, when I said, hey, I want to replace the routers with new ones, I'm going to dedicate 04:03.460 --> 04:05.170 the operations team to do so. 04:05.200 --> 04:07.210 That's assigning the responsible party. 04:07.210 --> 04:12.520 But if I just said I want to replace the routers during the maintenance window, I'm really kind of 04:12.550 --> 04:14.740 leaving a lot up to interpretation. 04:14.740 --> 04:18.130 Maybe the HR department feels like they're qualified to replace routers. 04:18.130 --> 04:19.120 You just don't know. 04:19.120 --> 04:22.990 You need to assign the proper team to assume the proper responsibility. 04:23.020 --> 04:24.970 We need to schedule deadlines. 04:24.970 --> 04:29.890 If I just said, hey, let's replace the routers with the operations team, the operations team may 04:29.890 --> 04:32.440 come back and say, well, we're down on manpower. 04:32.440 --> 04:34.390 It's going to be seven months before I can get to it. 04:34.420 --> 04:35.320 It's not a big deal. 04:35.320 --> 04:36.730 It's just replacing routers. 04:36.730 --> 04:39.010 Their schedule may be different than yours. 04:39.010 --> 04:43.330 You need to be able to say, I want the routers replaced at a certain time. 04:43.330 --> 04:48.700 We don't want to say specifics like October 14th at 239 in the morning. 04:48.700 --> 04:53.350 We want to kind of give a window that they can operate on, but we definitely want to give a deadline. 04:53.350 --> 04:56.720 We don't want that deadline to be so far out there that it's never going to get done. 04:56.750 --> 04:58.040 It's going to be forgotten. 04:58.040 --> 05:02.540 So most of the time we want our deadlines to be 30, no more than 60 days out if possible. 05:02.570 --> 05:04.820 We want our plan resource allocation. 05:04.820 --> 05:07.130 If I'm replacing routers, what does that entail? 05:07.160 --> 05:09.620 Do we need to replace Ethernet cables while we're at it? 05:09.650 --> 05:10.970 What about the connectors? 05:10.970 --> 05:12.110 How about power? 05:12.110 --> 05:14.690 What about resource allocation to make that happen? 05:14.690 --> 05:17.510 Resources include more than just supplies and assets. 05:17.540 --> 05:19.040 What about the manpower? 05:19.040 --> 05:24.230 I can have the IT team replace the router, but what if I have a bigger network imposed? 05:24.260 --> 05:29.990 Do I need to get with the hierarchy or the class two technical support to make sure that it's interfacing 05:29.990 --> 05:30.680 correctly? 05:30.680 --> 05:35.990 I need to plan my resource allocation properly so that everything is coinciding at the same time. 05:36.020 --> 05:41.540 Finally, I want to execute the change I once I've executed it and the router has been replaced, I 05:41.540 --> 05:42.530 want to monitor it. 05:42.560 --> 05:45.470 Am I still getting the same amount of traffic that I got before? 05:45.500 --> 05:48.260 Am I seeing an increase in the throughput? 05:48.260 --> 05:50.510 Is it doing what I wanted it to do? 05:50.540 --> 05:56.240 We often take baselines and those baselines provide us invaluable input of hey, this is the normal 05:56.240 --> 05:58.310 route in which the router was operating at. 05:58.340 --> 06:00.440 It's doing three terabytes per hour. 06:00.470 --> 06:03.050 That's a respectable speed for this router. 06:03.050 --> 06:07.430 We've replaced it with this new router, and it's supposed to go up to five terabytes in speed. 06:07.460 --> 06:08.990 Is it hitting that mark? 06:08.990 --> 06:10.280 Did it not hit that mark. 06:10.280 --> 06:11.690 Are we still seeing three terabytes? 06:11.690 --> 06:13.310 Maybe we're seeing one terabyte. 06:13.310 --> 06:16.790 If we're only seeing one and we normally see three, that's a major problem. 06:16.790 --> 06:21.650 We need to continually monitor that new device and make sure it's handling effectively and efficiently 06:21.650 --> 06:23.390 the way that we decided to go. 06:24.290 --> 06:26.900 We need to do awareness training and education. 06:26.900 --> 06:28.880 Did you know that 93%? 06:28.880 --> 06:35.780 I'm going to say that again, 93% of all vulnerabilities within a system or all exploits caused through 06:35.780 --> 06:38.150 vulnerabilities come from human beings. 06:38.150 --> 06:38.900 That's right. 06:38.900 --> 06:42.230 Your everyday worker is causing those problems in our network. 06:42.230 --> 06:45.440 Now, I know most of you are like, oh man, let's just hire everybody. 06:45.440 --> 06:47.690 I won't have any vulnerabilities, but let's be realistic. 06:47.720 --> 06:49.550 That's not really something we can do. 06:49.550 --> 06:52.710 So we have to provide training, awareness and education. 06:52.710 --> 06:59.070 This training and awareness and education hopefully brings down that 93% in your organization down to 06:59.100 --> 07:00.360 a respectable level. 07:00.360 --> 07:02.490 We can do that through awareness training. 07:02.700 --> 07:07.560 Awareness training means that we're going to go through, and we're going to identify different points 07:07.560 --> 07:10.020 within our network that are having issues. 07:10.020 --> 07:11.550 For instance, phishing. 07:11.550 --> 07:15.690 Usually phishing emails are a common problem within any enterprise environment. 07:15.690 --> 07:21.180 So having awareness training every once in a while to say, hey, don't click on email phishing links 07:21.180 --> 07:22.350 that you don't know. 07:22.380 --> 07:27.960 Excel documents that you didn't request isn't something you should be clicking on from an outside source. 07:27.960 --> 07:29.910 We should have password security. 07:29.940 --> 07:32.160 Why does your password need to be this long? 07:32.160 --> 07:33.480 What's the purpose? 07:33.480 --> 07:39.210 We can often create policies to our users and say, oh well, your password needs to be 24 characters 07:39.210 --> 07:39.810 in length. 07:39.840 --> 07:41.670 It needs to be in a statement format. 07:41.670 --> 07:46.140 It needs to have two numbers two letters, two uppercase, two lowercase with at least three special 07:46.140 --> 07:48.840 characters, and expect our users to follow it. 07:48.840 --> 07:54.450 But you're going to hear a lot of grumbling Often what we need to do is tell our users why we're doing 07:54.450 --> 07:55.020 something. 07:55.020 --> 07:59.940 We're doing a password security model because the old one didn't work properly, and since it didn't 07:59.940 --> 08:02.880 work properly, you're having to change your password every 30 days. 08:02.880 --> 08:06.630 And because you're having to change your password every 30 days, you're forgetting your password. 08:06.630 --> 08:12.960 If we provide context to our policies, you'll get a lot more feedback from your workers, and they'll 08:12.960 --> 08:17.670 see the need and the reliability of the policy that you're putting forth. 08:17.670 --> 08:20.880 If that doesn't work, we just technically do it and make it do them anyway. 08:20.880 --> 08:25.200 But let's be honest, it's sometimes better to know the why we don't want to treat our employees like 08:25.200 --> 08:28.770 three year old kids, because I said so is not an appropriate answer. 08:28.770 --> 08:31.680 When an employee asks you, why do I need to change my password? 08:31.710 --> 08:34.170 Or why do I need to follow these password policies? 08:34.170 --> 08:36.390 We need to do social engineering awareness. 08:36.390 --> 08:40.830 We need to make our users aware of the fact that, hey, Facebook is a problem. 08:40.830 --> 08:45.480 Getting instant messages on your telephone saying to click this link because you could reward yourself 08:45.480 --> 08:47.550 with a $100 gift certificate from subway. 08:47.580 --> 08:50.560 Not an appropriate text message to be clicking on. 08:50.560 --> 08:55.240 We need to have remote work policies and understand that, hey, when you're going through remote work, 08:55.270 --> 08:57.220 this is the avenue you need to take. 08:57.250 --> 08:58.630 You need to use a VPN. 08:58.660 --> 09:04.150 You need to provide a secure workspace to where other people cannot see your screen, which means don't 09:04.150 --> 09:09.250 remote work at Starbucks, we need to have an incident response plan and understand that our incident 09:09.250 --> 09:15.040 response could alleviate some issues, but also cause some responses that our workers not be may not 09:15.040 --> 09:16.030 be aware of. 09:16.060 --> 09:21.430 All of this comes into that training and awareness and education that we vastly need to do within our 09:21.430 --> 09:22.750 enterprise environment. 09:23.920 --> 09:26.410 Often we'll see a memorandum of understanding. 09:26.410 --> 09:35.800 Now, an MOU is a agreement between two parties to understand a specific goal or a specific objective 09:35.800 --> 09:38.890 within those two parties that's relevant to them. 09:38.890 --> 09:40.060 What do I mean by that? 09:40.060 --> 09:44.650 I saw an MOU one time that identified my department was to work with another department. 09:44.650 --> 09:50.480 At the time I worked with operations and the other department was finance and they needed access to 09:50.510 --> 09:53.360 different technologies within their environment. 09:53.360 --> 10:01.100 By having that MOU in place, we were required to facilitate and to support them in their technical 10:01.100 --> 10:05.780 uses for equipment that they might not otherwise have expertise in. 10:05.810 --> 10:12.440 For instance, in one case, we had a windows machine that didn't have Excel because we were still help 10:12.470 --> 10:15.080 desk and we still had that memorandum of understanding. 10:15.080 --> 10:19.160 We had to go out there and actually install Excel on their computer. 10:19.190 --> 10:21.650 Now you would think to yourself, oh my gosh, Excel. 10:21.650 --> 10:23.210 It's not that difficult to do. 10:23.210 --> 10:29.300 But via the memorandum, memorandum of understanding, we were required to go out there and excel and 10:29.300 --> 10:31.760 install these programs on their machines. 10:31.790 --> 10:37.490 Now I use Excel as kind of a low end documentation, but let's think about it from a different perspective. 10:37.490 --> 10:42.740 If I have two organizations and both organizations want to work together on a project, then having 10:42.740 --> 10:47.700 that memorandum of understanding that dictates how we're going to work together, how many hours we're 10:47.700 --> 10:48.390 going to do? 10:48.420 --> 10:49.800 What the scope is. 10:49.830 --> 10:55.050 What our compliance considerations should be used and what system resources that they could use within 10:55.050 --> 10:56.250 our interoperability. 10:56.280 --> 10:57.360 It all makes sense. 10:57.360 --> 11:02.790 An MOU is an important aspect within cybersecurity and within our industry, because it really dictates 11:02.790 --> 11:06.360 how we're going to work with other parties outside of our own department. 11:06.390 --> 11:14.190 Metrics and key performance indicators or KPIs are specific, time bound, relevant, attainable, and 11:14.190 --> 11:17.340 measurable quantifiable objectives. 11:17.370 --> 11:21.780 Now, I know I threw a lot of words at you, but I want you to understand how important this is. 11:21.810 --> 11:28.140 KPIs are often used by managers and by business employers to understand how we're doing within our own 11:28.140 --> 11:29.190 work environment. 11:29.220 --> 11:35.040 It wasn't uncommon when I was working in telecommunications for KPIs to be used for everything, and 11:35.040 --> 11:36.450 I do mean everything. 11:36.450 --> 11:38.670 How many tickets am I getting through a day? 11:38.670 --> 11:43.140 If I repaired this specific item, how long did it take me to repair that item? 11:43.140 --> 11:45.450 How many of those items did I replace in a week? 11:45.450 --> 11:48.310 How many critical tickets did I work versus how many major tickets? 11:48.310 --> 11:49.840 How many minor tickets? 11:49.840 --> 11:51.700 How can I improve myself? 11:51.700 --> 11:55.600 How could I understand a specific, relevant manner? 11:55.600 --> 12:02.320 When we're looking at KPIs, it's a measurable goal that is attainable, and attainable is the big portion. 12:02.320 --> 12:05.530 You can make a KPI that is extraordinary, right? 12:05.560 --> 12:10.330 You could say, oh, I want my workers to work at least 100 tickets per day, right? 12:10.330 --> 12:13.720 And each ticket takes 3 to 5 minutes to work. 12:13.720 --> 12:15.070 That's not possible. 12:15.070 --> 12:17.020 There's only so many minutes in the day. 12:17.050 --> 12:18.550 Plus there's bathroom breaks. 12:18.550 --> 12:19.750 There's lunch breaks. 12:19.750 --> 12:24.190 There's just a human concept of, yeah, I worked a ticket, but I still have to fill out the ticket 12:24.190 --> 12:24.910 properly. 12:24.940 --> 12:26.440 It needs to be attainable. 12:26.440 --> 12:28.060 Finally, it needs to be measurable. 12:28.060 --> 12:32.320 If you can't measure success, then there's no reason to having a KPI. 12:32.320 --> 12:35.260 And my instance, we measured tickets closed. 12:35.260 --> 12:42.190 How many tickets did I close with an actionable item that was not reopened within the next 24 hours? 12:42.190 --> 12:44.690 Meaning if I went out and I fixed a problem. 12:44.690 --> 12:48.290 Was another ticket open for the exact same item within 24 hours? 12:48.290 --> 12:51.920 If it was, that ticket did not count, it was not measured. 12:51.920 --> 12:56.930 So we need to identify the scope and specific instances in which our KPIs interact. 12:58.460 --> 13:03.830 We have something called SLA service level agreement A service level agreement is an agreement between 13:03.830 --> 13:08.000 two organizations that specifically state what you're going to provide. 13:08.000 --> 13:14.360 For instance, if I'm a telecommunications company and you're getting internet from me, you can state 13:14.360 --> 13:19.820 within our contractual agreement that I want a 99.9 uptime with my internet. 13:19.820 --> 13:23.060 That is a service level agreement that I'm signing off on. 13:23.060 --> 13:30.890 I'm stating as the telecommunications company that you will have a 99.9, uh, availability on your 13:30.890 --> 13:36.830 internet activity for your organization within an SLO or a service level objective. 13:36.830 --> 13:43.980 We are providing an objective that says, yes, my company promised 99.9, but maybe inside of our organization, 13:43.980 --> 13:44.940 we're saying, you know what? 13:44.970 --> 13:47.730 Let's go for 99.2%. 13:47.760 --> 13:55.230 Our goal as an organization is to provide 99.2% uptime or availability to that internet to this company. 13:55.260 --> 13:58.410 Now that's a service level objective within the own company. 13:58.440 --> 14:01.920 Finally, we have an SLA or service level indicator. 14:01.920 --> 14:05.160 This is the real number of the performance of how we did. 14:05.190 --> 14:11.430 Now SLAs, SLOs and Slis, they're usually done on a monthly, quarterly or annual basis. 14:11.430 --> 14:17.010 And so we may look at a monthly basis and say, oh well our SLA was 99.9. 14:17.040 --> 14:19.350 Our SLO is 99.2. 14:19.380 --> 14:21.090 For our internal objectives. 14:21.090 --> 14:24.300 And our SLI was 99.13. 14:24.330 --> 14:27.720 We met our SLA but we failed on our SLO. 14:27.750 --> 14:28.680 Are we in trouble? 14:28.710 --> 14:31.620 No, this was the company organization is concerned. 14:31.650 --> 14:35.310 The outside organization is happy they met their 99% uptime. 14:35.310 --> 14:39.120 But we have some work to do on our SLO for internal objectives. 14:39.120 --> 14:42.090 This is SLA slow and SLA.