WEBVTT 1 00:00.000 --> 00:03.900 So the solution behind this particular challenge was kind of a strict question, 2 00:03.900 --> 00:04.560 but it's definitely 3 00:04.560 --> 00:08.090 something that needs to be thought about as we start moving forward in our 4 00:08.090 --> 00:09.040 security planning 5 00:09.040 --> 00:13.320 for the different types of cloud environments, especially dealing with the 6 00:13.320 --> 00:14.640 Cisco infrastructure. 7 00:14.640 --> 00:18.850 Because once we get this thought process down and understood, dealing with the 8 00:18.850 --> 00:19.680 Cisco infrastructure 9 00:19.680 --> 00:23.900 for cloud security is going to be easy, I promise you. And we're going to be 10 00:23.900 --> 00:24.880 able to implement 11 00:24.880 --> 00:28.850 a lot of controls through API and all this other stuff, hints for stuff coming 12 00:28.850 --> 00:29.680 up in the future. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:30.080 --> 00:33.740 But taking a look at our scenario, was it this way? I believe so, this way. Yep 14 00:33.740 --> 00:35.120 , they're right there. 15 00:35.120 --> 00:40.560 Our conditions were that we had an exchange server that was running inside of 16 00:40.560 --> 00:41.840 the application 17 00:41.840 --> 00:47.770 container for our roles and responsibilities for platform as a service. And we 18 00:47.770 --> 00:48.640 also have a 19 00:48.640 --> 00:52.380 vulnerability that's popped up that not only affects the actual exchange server 20 00:52.380 --> 00:53.520 , but also windows. 21 00:53.520 --> 00:57.960 Now you may be wondering, does such a vulnerability exist? And guess what? It 22 00:57.960 --> 01:00.080 does. I put it on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:57.960 --> 01:00.080 does. I put it on the 23 01:00.080 --> 01:07.510 screen right there, CVE for us that notification, 2022, 41, 0, 4 is 0. I want 24 01:07.510 --> 01:08.960 to put a link for it. 25 01:08.960 --> 01:13.520 I'll below this video as well. And this was a vulnerability that not only 26 01:13.520 --> 01:13.840 affected 27 01:13.840 --> 01:17.850 the exchange server, but also messed with some of the system files for 28 01:17.850 --> 01:19.200 correction inside of the 29 01:19.200 --> 01:23.920 actual Windows server itself. So who's responsible? Well, this is a shared 30 01:23.920 --> 01:26.400 responsibility and also a shared 31 01:26.400 --> 01:32.060 risk as well. So it's going to be the customer's responsibility to be able to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:26.400 --> 01:32.060 risk as well. So it's going to be the customer's responsibility to be able to 32 01:32.060 --> 01:33.200 patch on the actual 33 01:33.200 --> 01:37.680 exchange server side, but it's going to be the provider's responsibility to go 34 01:37.680 --> 01:38.720 through and patch 35 01:38.720 --> 01:43.760 on the Windows server side. Well, we have to be able to make sure that both the 36 01:43.760 --> 01:44.640 exchange server and 37 01:44.640 --> 01:49.360 the Windows server platform are patched and everything is good to go. So the 38 01:49.360 --> 01:50.160 agreement has to be 39 01:50.160 --> 01:54.050 made between the customer and the actual provider to not only do the actual 40 01:54.050 --> 01:55.120 security patching, 41 01:55.120 --> 01:59.360 but also the follow-up vulnerability assessments to make sure that CVE does not 42 01:59.360 --> 02:00.240 exist anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:59.360 --> 02:00.240 exist anymore. 43 02:00.240 --> 02:03.280 Or that other remediations have been 44 02:03.280 --> 02:09.420 had to make sure that the vulnerability is no longer affecting the actual 45 02:09.420 --> 02:10.720 clients. Because some 46 02:10.720 --> 02:16.730 patches may not affect what we needed to and we put in ACLs or do other access 47 02:16.730 --> 02:17.920 control lists, 48 02:17.920 --> 02:22.390 like app blocker and things like that through policy. Many different things you 49 02:22.390 --> 02:23.520 could do, but the 50 02:23.520 --> 02:28.570 preferred method is that there's a vulnerability patch for it or a security 51 02:28.570 --> 02:29.840 patch that you apply 52 02:29.840 --> 02:33.860 that. And this is where we're going to have to definitely work together as a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:29.840 --> 02:33.860 that. And this is where we're going to have to definitely work together as a 53 02:33.860 --> 02:34.720 team to make sure 54 02:34.720 --> 02:39.440 that we understand this. And this kind of methodology applies to software as a 55 02:39.440 --> 02:40.480 service and also 56 02:40.480 --> 02:45.680 infrastructure as a service as well. And that's because if anything inside of 57 02:45.680 --> 02:46.560 those other containers 58 02:46.560 --> 02:51.000 that we're not in charge of are affected by a vulnerability that directly 59 02:51.000 --> 02:51.920 affects us, 60 02:51.920 --> 02:55.930 we're definitely only have to have that little come come together talk and make 61 02:55.930 --> 02:57.360 sure that everything is 62 02:57.360 --> 03:01.040 all cushy at the end of the day. Now, that being said, I want to close this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 02:57.360 --> 03:01.040 all cushy at the end of the day. Now, that being said, I want to close this 63 03:01.040 --> 03:01.920 skill out with a little 64 03:01.920 --> 03:06.880 bit more of a perplexing question at the end of this particular skill. Other 65 03:06.880 --> 03:08.080 than that, I hope this 66 03:08.080 --> 03:10.480 been informative for you and I'd like to thank you for viewing.