WEBVTT 1 00:00:00.150 --> 00:00:01.770 The newest type of virtualization 2 00:00:01.770 --> 00:00:03.540 that's becoming popular in our networks 3 00:00:03.540 --> 00:00:05.790 is known as container based virtualization 4 00:00:05.790 --> 00:00:07.980 also known as containerization. 5 00:00:07.980 --> 00:00:10.290 This type of virtualization is much more focused 6 00:00:10.290 --> 00:00:12.780 on servers instead of the end user, though. 7 00:00:12.780 --> 00:00:14.460 With this type of virtualization, 8 00:00:14.460 --> 00:00:16.440 the operating system kernel is shared across 9 00:00:16.440 --> 00:00:19.440 multiple virtual machines, but the user space 10 00:00:19.440 --> 00:00:21.720 for each virtual machine is uniquely created 11 00:00:21.720 --> 00:00:22.740 and managed. 12 00:00:22.740 --> 00:00:25.020 Containerization is a type of virtualization 13 00:00:25.020 --> 00:00:27.900 that's applied by a host operating system to provision 14 00:00:27.900 --> 00:00:31.230 an isolated execution environment for an application. 15 00:00:31.230 --> 00:00:33.390 Containerization is considered fairly secure 16 00:00:33.390 --> 00:00:35.370 because it enforces resource segmentation 17 00:00:35.370 --> 00:00:38.280 and separation at the operating system level. 18 00:00:38.280 --> 00:00:40.290 Now containerization is commonly used 19 00:00:40.290 --> 00:00:42.210 with Linux servers and some examples 20 00:00:42.210 --> 00:00:43.950 of this container based virtualization 21 00:00:43.950 --> 00:00:46.980 include things like, Docker, Parallels Virtuozzo 22 00:00:46.980 --> 00:00:48.960 and OpenVZ project. 23 00:00:48.960 --> 00:00:51.870 Now, what does containerization really look like? 24 00:00:51.870 --> 00:00:53.610 Well, you have a piece of hardware 25 00:00:53.610 --> 00:00:56.460 and then on top of that hardware, you have a Host OS, 26 00:00:56.460 --> 00:00:59.430 usually Linux, and then you have a container manager. 27 00:00:59.430 --> 00:01:02.820 Something like Kubernetes or Docker or something like that. 28 00:01:02.820 --> 00:01:05.100 Now this container manager is going to be used to create 29 00:01:05.100 --> 00:01:08.070 different containers that contain different applications. 30 00:01:08.070 --> 00:01:10.290 In this case, I have three containers. 31 00:01:10.290 --> 00:01:12.000 I have the first environment, which is based 32 00:01:12.000 --> 00:01:14.340 on the kernel of the host OS, in this example, 33 00:01:14.340 --> 00:01:16.170 a Linux system that's being used. 34 00:01:16.170 --> 00:01:18.720 And so we have container one running Linnux 35 00:01:18.720 --> 00:01:20.700 and it contains some applications there. 36 00:01:20.700 --> 00:01:23.130 Now container two can do the same thing 37 00:01:23.130 --> 00:01:25.290 and container three can do the same thing. 38 00:01:25.290 --> 00:01:27.210 Since all three containers are sharing the same 39 00:01:27.210 --> 00:01:28.980 host operating system files. 40 00:01:28.980 --> 00:01:30.750 This takes a lot less resources 41 00:01:30.750 --> 00:01:33.690 than doing pure virtualization using virtual machines. 42 00:01:33.690 --> 00:01:35.730 Like we talked about with virtualization. 43 00:01:35.730 --> 00:01:38.340 If we instead use individual virtual machines, 44 00:01:38.340 --> 00:01:40.860 each one would need its own copy of an operating system. 45 00:01:40.860 --> 00:01:43.740 And that could be 8 to 10 gigabytes for each one. 46 00:01:43.740 --> 00:01:45.000 But with containers, 47 00:01:45.000 --> 00:01:47.280 we can all share the same operating system. 48 00:01:47.280 --> 00:01:50.250 So containerization uses a lot less storage base 49 00:01:50.250 --> 00:01:52.260 and takes a lot less processing power. 50 00:01:52.260 --> 00:01:55.050 This is the real benefit of using something like a container 51 00:01:55.050 --> 00:01:56.970 from an operational perspective. 52 00:01:56.970 --> 00:01:59.970 Now, because these containers are logically isolated. 53 00:01:59.970 --> 00:02:02.100 They can't actually interface with each other. 54 00:02:02.100 --> 00:02:04.080 If I wanted to have two containers talk, 55 00:02:04.080 --> 00:02:06.480 I actually have to connect them through a virtual network 56 00:02:06.480 --> 00:02:07.890 and do the right routing and switching 57 00:02:07.890 --> 00:02:09.330 to allow them to talk. 58 00:02:09.330 --> 00:02:11.970 By default, they have no way of talking to each other 59 00:02:11.970 --> 00:02:14.310 and this is a great thing from a security standpoint 60 00:02:14.310 --> 00:02:16.410 because we have this segmentation. 61 00:02:16.410 --> 00:02:18.810 Now, here's your big warning when it comes to dealing 62 00:02:18.810 --> 00:02:20.010 with containers. 63 00:02:20.010 --> 00:02:22.890 If an attacker compromises the host OS underneath 64 00:02:22.890 --> 00:02:24.990 for example, that Linux operating system 65 00:02:24.990 --> 00:02:27.960 I was just discussing, guess what's happening? 66 00:02:27.960 --> 00:02:30.810 Well, this attack now has access to all of the containers 67 00:02:30.810 --> 00:02:33.270 in their data, because that one operating system 68 00:02:33.270 --> 00:02:35.790 is used by all of the containers being hosted. 69 00:02:35.790 --> 00:02:37.440 This is one of the biggest vulnerabilities 70 00:02:37.440 --> 00:02:38.820 when you use containers. 71 00:02:38.820 --> 00:02:40.470 I can have a container system that's running 72 00:02:40.470 --> 00:02:42.240 50 different servers right now. 73 00:02:42.240 --> 00:02:43.980 And each of these is running different servers 74 00:02:43.980 --> 00:02:46.230 and services using containerization. 75 00:02:46.230 --> 00:02:49.050 But if somebody is able to get to that one server 76 00:02:49.050 --> 00:02:52.020 underneath that Linux operating system, they now have access 77 00:02:52.020 --> 00:02:55.290 to all 50 of those hosted servers and all of their data. 78 00:02:55.290 --> 00:02:57.480 Another risk to consider is how your containers 79 00:02:57.480 --> 00:03:00.390 and other virtual machines are actually going to be hosted. 80 00:03:00.390 --> 00:03:03.210 Once we begin to rely on virtualization and cloud computing, 81 00:03:03.210 --> 00:03:05.040 it becomes very important to recognize 82 00:03:05.040 --> 00:03:07.680 that our data might be hosted on the same physical server 83 00:03:07.680 --> 00:03:09.660 as another organization's data. 84 00:03:09.660 --> 00:03:12.120 By doing so, we introduce some vulnerabilities 85 00:03:12.120 --> 00:03:13.920 into the security of our systems. 86 00:03:13.920 --> 00:03:16.950 First, if the physical server crashes due to something 87 00:03:16.950 --> 00:03:18.960 one of the other organizations is doing 88 00:03:18.960 --> 00:03:19.880 it can actually affect all 89 00:03:19.880 --> 00:03:22.500 of the organizations on that same server. 90 00:03:22.500 --> 00:03:24.960 Similarly, if one organization is not maintaining 91 00:03:24.960 --> 00:03:26.760 the security of their virtual environments, 92 00:03:26.760 --> 00:03:28.740 they're being hosted on that physical server, 93 00:03:28.740 --> 00:03:31.470 there is a possibility that an attacker can utilize 94 00:03:31.470 --> 00:03:33.900 that to the detriment of all the other organizations 95 00:03:33.900 --> 00:03:35.880 hosted on that same server. 96 00:03:35.880 --> 00:03:38.220 Just as there are concerns when interconnecting our networks 97 00:03:38.220 --> 00:03:40.170 with somebody else's, there's also concerns 98 00:03:40.170 --> 00:03:42.210 with hosting multiple organizations' data 99 00:03:42.210 --> 00:03:44.010 on the same physical server. 100 00:03:44.010 --> 00:03:46.530 It's important for us to properly configure, manage 101 00:03:46.530 --> 00:03:48.780 and audit user access to the virtual machines 102 00:03:48.780 --> 00:03:50.820 that are being hosted on those servers. 103 00:03:50.820 --> 00:03:53.850 Also, we want to make sure we ensure that our virtual machines 104 00:03:53.850 --> 00:03:56.580 have the latest patches, antivirus, animwire 105 00:03:56.580 --> 00:03:58.410 and access control in place. 106 00:03:58.410 --> 00:03:59.760 In order to minimize the risk 107 00:03:59.760 --> 00:04:02.490 of having the physical servers resources being overwhelmed, 108 00:04:02.490 --> 00:04:04.920 it's always a good idea to set up our virtual machines 109 00:04:04.920 --> 00:04:08.280 with proper failover, redundancy and elasticity. 110 00:04:08.280 --> 00:04:09.810 By monitoring network performance 111 00:04:09.810 --> 00:04:11.610 and the physical servers resources, 112 00:04:11.610 --> 00:04:13.500 we should be able to balance the load across 113 00:04:13.500 --> 00:04:15.570 several physical machines instead of relying 114 00:04:15.570 --> 00:04:17.370 on just a single one. 115 00:04:17.370 --> 00:04:19.290 Another vulnerability that might be exploited 116 00:04:19.290 --> 00:04:21.330 by an attacker is when we use the same type 117 00:04:21.330 --> 00:04:24.420 of hypervisor across all of our virtual machines. 118 00:04:24.420 --> 00:04:27.180 So for example, if our organization relies solely 119 00:04:27.180 --> 00:04:29.700 on VMware's ESXi hypervisor 120 00:04:29.700 --> 00:04:32.280 and a new exploit is created for that hypervisor, 121 00:04:32.280 --> 00:04:35.790 well an attacker could use that against all of our systems. 122 00:04:35.790 --> 00:04:38.400 So, if it's successful on one of our servers 123 00:04:38.400 --> 00:04:40.830 they're likely going to try it on the rest of our servers. 124 00:04:40.830 --> 00:04:43.260 And if all of our servers use that same platform 125 00:04:43.260 --> 00:04:46.410 in this case, VMware's ESXi, this vulnerability 126 00:04:46.410 --> 00:04:49.350 could be exploited across our entire organization. 127 00:04:49.350 --> 00:04:51.420 The challenge with this though, is that again 128 00:04:51.420 --> 00:04:53.700 if we utilize multiple hypervisor platforms 129 00:04:53.700 --> 00:04:55.620 our support costs and our training requirements 130 00:04:55.620 --> 00:04:57.360 are also going to increase. 131 00:04:57.360 --> 00:05:00.090 Most organizations for this reason do choose to use 132 00:05:00.090 --> 00:05:02.610 a single platform, but at least they're making 133 00:05:02.610 --> 00:05:04.800 a measured risk decision when they do that. 134 00:05:04.800 --> 00:05:07.290 To mitigate that risk, the organization should utilize 135 00:05:07.290 --> 00:05:09.690 proper configurations, ensure the hypervisor 136 00:05:09.690 --> 00:05:11.520 always remains patched and up to date 137 00:05:11.520 --> 00:05:14.280 and only accessible through a secure management interface, 138 00:05:14.280 --> 00:05:16.830 as well as, tightly controlling access control. 139 00:05:16.830 --> 00:05:19.230 Now, these are some of the things you must consider 140 00:05:19.230 --> 00:05:21.570 when you start faring out if you're going to virtualize 141 00:05:21.570 --> 00:05:23.880 your systems and migrate them to an on-premise 142 00:05:23.880 --> 00:05:25.410 or cloud-based solution. 143 00:05:25.410 --> 00:05:27.540 First, are you going to virtualize? 144 00:05:27.540 --> 00:05:30.360 If so, are you going to use traditional virtual machines 145 00:05:30.360 --> 00:05:32.430 or are you going to use containerization? 146 00:05:32.430 --> 00:05:34.410 What is the risk versus reward here? 147 00:05:34.410 --> 00:05:35.970 There's a balancing act that you have to do. 148 00:05:35.970 --> 00:05:37.230 It's a business decision 149 00:05:37.230 --> 00:05:39.780 and it's also a cyber security decision. 150 00:05:39.780 --> 00:05:41.460 And so you're going to have to measure these things 151 00:05:41.460 --> 00:05:44.100 and decide what is best to select for your organization 152 00:05:44.100 --> 00:05:45.723 and its particular use cases.