WEBVTT 00:07.220 --> 00:11.300 There are two primary methods for addressing vulnerabilities involving our systems. 00:11.300 --> 00:16.700 One is applying patches or updates provided by the vendors and adjusting the functionality or the security 00:16.730 --> 00:18.560 settings within our systems. 00:18.590 --> 00:23.750 Typically, vendors release patches on designated days depending on the software that it's involved 00:23.750 --> 00:24.410 upon. 00:24.440 --> 00:27.290 When we initially get that patch, we want to test it. 00:27.320 --> 00:30.170 We want to make sure that it's operating in the way it should. 00:30.230 --> 00:32.120 By testing the different patches. 00:32.120 --> 00:38.540 Within a secure system, we can identify faults or flaws and how the patch interacts with our other 00:38.540 --> 00:39.920 software within our system. 00:40.130 --> 00:44.120 We want to make sure that if I'm getting a Microsoft windows patch, that it's not interfering with 00:44.150 --> 00:51.770 Adobe Acrobat or maybe one of our other, uh, proprietary, proprietary programs that we utilize on 00:51.800 --> 00:56.750 that system, if it doesn't work, then the testing fails and we don't need to implement the patch. 00:56.750 --> 00:59.150 We need to figure out what we need to fix the problem. 00:59.150 --> 01:03.660 If it does work and it validates properly, then we're going to continue to implementation. 01:03.660 --> 01:09.090 Moving to implementation means that we're going to proceed with the patching process across one segment 01:09.090 --> 01:09.930 or more. 01:09.960 --> 01:12.450 Usually we'll do one segment at a time. 01:12.450 --> 01:14.100 We'll go through and we'll say, you know what? 01:14.130 --> 01:15.570 Let's do the HR department. 01:15.570 --> 01:16.980 They've got a low computer count. 01:17.010 --> 01:22.110 Let's see how it pulls off outside the testing environment into a real world working environment. 01:22.110 --> 01:27.030 So we'll roll the patch out and again we'll validate it to make sure that it's working properly. 01:27.030 --> 01:32.730 And if everything is bright and shiny and it functions as per demand, we move on with our lives. 01:32.730 --> 01:37.080 If it doesn't and we see flaws, we see crashes within the program. 01:37.080 --> 01:42.420 Maybe the HR systems that we just implemented, the patches on it had some systems or had some tweaks 01:42.420 --> 01:44.970 in it that caused the system to crash. 01:45.000 --> 01:49.200 Maybe different programs aren't working the way they were intended, or introduced vulnerabilities that 01:49.200 --> 01:50.400 we didn't anticipate. 01:50.400 --> 01:52.920 If that occurs, we're going to perform a rollback. 01:52.950 --> 01:58.350 Usually a rollback implies that we're going to roll back the system back to its primary operating function. 01:58.350 --> 02:03.040 Before we implemented the patches, we're putting the system back the way we found it. 02:03.040 --> 02:05.170 That's all that rollback really is. 02:06.370 --> 02:09.190 Usually patches go inside of a maintenance window. 02:09.220 --> 02:13.450 I remember when I worked for several different companies, the first one hour maintenance window was 02:13.450 --> 02:16.990 from 10 p.m. to 6 a.m. we had eight hours to work. 02:16.990 --> 02:21.430 During those eight hours, we had minimal customer impact, meaning that customers didn't usually get 02:21.460 --> 02:23.530 on our systems between that time. 02:23.530 --> 02:29.980 With another company that I work for, the maintenance windows was from 12 a.m. to 4 a.m. again, not 02:29.980 --> 02:33.640 a very big maintenance window, but it didn't impact our customers. 02:33.640 --> 02:39.010 Your maintenance window is going to be dependent upon how your customers or how your organization deals 02:39.010 --> 02:40.480 with the different customers. 02:40.630 --> 02:44.680 There was another company that I was working with and I consulted with, and their maintenance window 02:44.680 --> 02:52.180 was literally from 6 p.m. to 6 a.m. all their employees only worked from 8 a.m. to 5 p.m., and so we 02:52.180 --> 02:57.280 were able to have free reign of the system and the enterprise environment literally for 12 hours. 02:57.280 --> 02:58.270 It was great. 02:58.300 --> 03:03.820 However, most systems are not like that You should anticipate having a maintenance window between about 03:03.820 --> 03:07.480 11:00 pm at night to about 3 to 4 a.m. in the morning. 03:07.480 --> 03:10.270 That's a typical maintenance window for most companies. 03:10.270 --> 03:15.130 When we provide a maintenance window, it's scheduled, even though we have this maintenance window, 03:15.130 --> 03:19.960 even if that maintenance window is for 12 hours, we just don't say, oh, it's a maintenance window. 03:19.990 --> 03:21.430 I could do whatever I want. 03:21.460 --> 03:25.240 We still want to schedule our activities if we're going through. 03:25.270 --> 03:26.980 We want to provide some insight into it. 03:27.010 --> 03:31.660 We want to tell people, hey, our systems are going to be down from this time to this time. 03:31.690 --> 03:36.370 Imagine if you were if you're that employee working on a document and you have a meeting first thing 03:36.370 --> 03:41.440 in the morning, you have to work late at night, and somebody just took down all the servers without 03:41.440 --> 03:42.220 any notice. 03:42.220 --> 03:47.140 You could be working on an important document that is badly needed for the for the security of your 03:47.140 --> 03:49.270 company in a different department. 03:49.270 --> 03:53.260 And your IT team just took down the entire system without anybody knowing. 03:53.260 --> 03:57.160 You're frantically calling the 24 hour help desk to figure out what's going on. 03:57.160 --> 04:02.620 It's creating more work for everybody involved, and you've just created not only hassles for that employee, 04:02.620 --> 04:07.010 but for the network as a whole, because you've involved 3 or 4 other departments because you didn't 04:07.010 --> 04:08.240 schedule it properly. 04:08.240 --> 04:12.740 When we do maintenance window work, we need to make sure that it's scheduled and reported properly. 04:12.770 --> 04:18.110 However, if we have an emergency within our maintenance window, that's when we want to do it. 04:18.140 --> 04:22.880 Let's say we have a critical patch and it comes out at 3:00 in the afternoon. 04:23.000 --> 04:26.480 You get with your boss and you're like, hey, this is an emergency patch. 04:26.480 --> 04:31.820 We need to implement this as soon as possible, or this system is constantly crashing and it's almost 04:31.820 --> 04:35.690 got a 50% uptime, so we can't continue to operate this way. 04:35.690 --> 04:40.280 And even though I didn't schedule it within 24 to 48 hours notice, which is normally our customer's 04:40.280 --> 04:42.830 policy, we consider it an emergency patch. 04:42.860 --> 04:47.780 You go through, you're still going to notify the employees, hey, our systems are going to be down 04:47.780 --> 04:49.160 from this time to this town. 04:49.160 --> 04:50.570 Expect outages. 04:50.570 --> 04:53.690 We still want to plan that out as much as possible. 04:53.690 --> 04:55.910 That would be considered an emergency patch. 04:55.940 --> 04:58.130 We have both planned and unplanned. 04:58.130 --> 05:02.270 When on my earlier example, when I talked about, hey, we're going to roll out patches, we have this 05:02.270 --> 05:05.520 time we want to provide that 24 to 48 hour notice. 05:05.550 --> 05:07.230 We want to plan it ahead of schedule. 05:07.230 --> 05:08.550 We want to get approval. 05:08.550 --> 05:13.920 We want to go through the process that our company has outlined to do a planned outage during the maintenance 05:13.920 --> 05:14.370 window. 05:14.400 --> 05:20.400 However, it's not uncommon to have an unscheduled or unplanned outage if we have an emergency patch 05:20.400 --> 05:22.800 or we have critical systems that are going down. 05:22.830 --> 05:26.490 Unscheduled can be during the maintenance window, or it can be during the middle of the day. 05:26.520 --> 05:30.210 More often than not, whenever possible, we want it to be during the maintenance window. 05:30.210 --> 05:34.920 But that's not always possible given the criticality of the problem or the severity of the problem that 05:34.920 --> 05:35.850 we're facing. 05:36.750 --> 05:38.370 Finally, we have exceptions. 05:38.370 --> 05:43.140 There are exceptions to everything that we do, both in it and in life itself. 05:43.140 --> 05:47.670 Sometimes we may have a critical problem, but we don't have the budget to properly fix it. 05:47.700 --> 05:50.490 We can have an exception to policy for budgeting. 05:50.490 --> 05:55.830 When we have an exception for policy for budgeting, we can implement a patch or a problem, but not 05:55.830 --> 05:57.750 go through all the nature of it. 05:57.750 --> 06:02.910 Let's say that I've got a critical system problem, and it requires a specific framework or a specific 06:02.910 --> 06:04.680 hardware to fix the issue. 06:04.710 --> 06:12.130 We can use a compensating control to facilitate an exception to that hardware in order to apply a software 06:12.130 --> 06:14.140 update that could do the same thing. 06:14.140 --> 06:19.120 While it's a compensating control, we are providing an exception via the budgeting problem. 06:19.120 --> 06:21.070 There's also risk exceptions. 06:21.070 --> 06:26.470 You may come to a point within your organization where the risk is too high, and your company just 06:26.470 --> 06:31.390 doesn't want to deal with the risk attributed to that fix, or the risk attributed to that problem. 06:31.390 --> 06:33.190 I know one company I was working with. 06:33.220 --> 06:38.800 If it was raining or specifically during Halloween, we weren't allowed on the roads with any company 06:38.830 --> 06:39.520 vehicles. 06:39.520 --> 06:46.840 Halloween was off limits from 2 p.m. until 2 a.m. the company had over 30,000 vehicles in its arsenal, 06:46.840 --> 06:53.400 and it straight out said you are not to drive on the roads on Halloween, October 31st from 2 p.m. to 06:53.400 --> 06:57.700 2 a.m. under any circumstances without director approval. 06:57.700 --> 07:02.830 This was a risk the company was not willing to take and in the incident for PR was one of the company 07:02.860 --> 07:05.980 vehicles possibly hitting a child while they were trick or treating. 07:05.980 --> 07:07.300 The risk was too great. 07:07.300 --> 07:11.740 And so that provided a risk or excuse me, an exception to a normal policy. 07:11.770 --> 07:16.390 We can do lack of vendor support if there is a vendor support that isn't available. 07:16.390 --> 07:22.450 Maybe there is a problem with one of our systems, and we need that vendor support to properly implement 07:22.450 --> 07:24.130 the fix, because we just don't know. 07:24.130 --> 07:28.120 We don't have the in-house specialties or the expertise to deal with that problem. 07:28.120 --> 07:29.980 We may need vendor support. 07:29.980 --> 07:34.480 If that vendor support isn't available on a Friday night, we may say, you know what? 07:34.480 --> 07:38.980 Let's push it off until Monday morning or Monday night when there's vendor support. 07:38.980 --> 07:41.080 We can also have prioritization. 07:41.080 --> 07:44.740 Like we've stated before, some things are more critical than others. 07:44.740 --> 07:50.530 If I have a higher priority to one item and we have this newer item that came up, it may not matter 07:50.530 --> 07:52.150 that it's also a critical item. 07:52.180 --> 07:56.590 Our vendors or our our company or organization could say, you know what? 07:56.590 --> 07:58.090 I realize this is a problem. 07:58.090 --> 08:03.310 We already have this other critical function that's a higher priority and it's already scheduled. 08:03.310 --> 08:07.390 We're going to do that instead This is our exceptions to policy.