WEBVTT 00:00:00.940 --> 00:00:05.150 Let's continue looking at cloud data security for the CCSP 00:00:05.350 --> 00:00:08.350 with this area on cloud data protection. 00:00:09.040 --> 00:00:12.040 In order to protect data, we need to know how it's 00:00:12.040 --> 00:00:15.360 stored and how it's processed. 00:00:16.740 --> 00:00:22.640 The key to data protection is access control, making sure that only authorized 00:00:22.640 --> 00:00:27.450 people can perform authorized functions against that data. 00:00:28.040 --> 00:00:34.810 We can say here that an entity could be a person or a process that is 00:00:34.810 --> 00:00:38.760 trying to perform some type of action against that data. 00:00:40.340 --> 00:00:45.030 The idea of access control should also be based on temporal, and 00:00:45.030 --> 00:00:48.650 that means time‑based types of isolation as well. 00:00:49.340 --> 00:00:50.130 For example, 00:00:50.130 --> 00:00:54.460 a person might only be able to get access to data during normal 00:00:54.460 --> 00:00:57.560 business hours and not outside of those hours. 00:00:58.440 --> 00:01:01.120 It also should be based on attributes, 00:01:01.130 --> 00:01:06.640 how the data is actually stored and what that data represents. 00:01:06.650 --> 00:01:07.860 For example, 00:01:08.340 --> 00:01:11.730 a person might have access to it while they're in the role of 00:01:11.730 --> 00:01:16.260 administrator, but not while they're in the role of a normal user. 00:01:18.240 --> 00:01:20.460 There are many different threats to data. 00:01:21.040 --> 00:01:25.120 Data could be subject to threats while in storage or, 00:01:25.120 --> 00:01:27.160 of course, while in transmission. 00:01:28.040 --> 00:01:33.110 In both cases, a lot of this comes down to unauthorized disclosure, a 00:01:33.110 --> 00:01:36.930 person being able to access or read data they shouldn't have been able 00:01:36.930 --> 00:01:41.530 to see. In storage, for example, gaining access to something that they 00:01:41.530 --> 00:01:44.910 should not have had in transmission to something like a 00:01:44.910 --> 00:01:49.290 man‑in‑the‑middle attack who's able to see data being transmitted from 00:01:49.290 --> 00:01:50.760 one location to another. 00:01:51.840 --> 00:01:56.280 One of the risks, of course, with both of these is the fact that the data could 00:01:56.280 --> 00:02:00.560 be altered or, of course, even deleted or lost altogether. 00:02:01.540 --> 00:02:03.560 So when we look at data protection, 00:02:03.560 --> 00:02:06.320 we need to protect it while we transmit it through 00:02:06.320 --> 00:02:09.770 things like virtual private networks, say, for example, 00:02:09.780 --> 00:02:13.810 transport layer security or internet protocol security, 00:02:13.810 --> 00:02:17.920 IPSec, or in wireless through the use of things like 00:02:18.530 --> 00:02:22.880 WPA3. When we protect data and storage, 00:02:22.880 --> 00:02:27.730 we do this, first of all, by making sure that we've got more than one copy, the 00:02:27.730 --> 00:02:32.810 replication of data so that even in the case of a hardware failure, we still 00:02:32.810 --> 00:02:35.960 have another copy we could retrieve the data from. 00:02:36.640 --> 00:02:39.840 We protect the stored data by encrypting it and 00:02:39.840 --> 00:02:42.260 making sure that unauthorized people, 00:02:42.260 --> 00:02:46.080 even if they gained access to the hardware, would not be 00:02:46.080 --> 00:02:48.460 able to have any intelligible data. 00:02:49.540 --> 00:02:53.300 One of the things that's important with this is something we'll look 00:02:53.300 --> 00:02:56.160 at in a few moments, and that is who has the key. 00:02:56.940 --> 00:02:59.140 In a number of different cases, 00:02:59.340 --> 00:03:03.310 it could be that the cloud service provider has the encryption keys, 00:03:03.310 --> 00:03:06.860 especially with transmission or in Software as a Service. 00:03:07.640 --> 00:03:09.980 But when we're dealing with Platform as a Service 00:03:09.980 --> 00:03:11.960 or Infrastructure as a Service, 00:03:12.440 --> 00:03:18.380 it could well be the cloud consumer is the only person with the key. An 00:03:18.380 --> 00:03:21.350 important way to protect data is through hashing, 00:03:21.740 --> 00:03:26.610 making sure we protect the integrity of the data, and a hash would very 00:03:26.610 --> 00:03:31.340 easily pick up if there are any alterations to the data, even minor 00:03:31.340 --> 00:03:36.970 modifications of even just a bit, for example. In the end, this all comes 00:03:36.970 --> 00:03:42.120 down to what we mentioned, access control, making sure only authorized 00:03:42.120 --> 00:03:44.960 people can do authorized functions. 00:03:46.140 --> 00:03:50.160 We also have the technologies of data loss or sometimes 00:03:50.160 --> 00:03:52.260 known as data leakage prevention. 00:03:52.940 --> 00:03:57.350 The idea of data loss or data leakage prevention is to protect 00:03:57.360 --> 00:04:01.280 data from leaking out of an organization. 00:04:01.300 --> 00:04:07.680 For example, somebody is going to send out an email, and it blocks that because 00:04:07.680 --> 00:04:11.960 it recognizes there's possibly sensitive data in that email. 00:04:13.040 --> 00:04:19.579 But one of the other parts of DLP that's not as well known is protecting from 00:04:19.589 --> 00:04:25.290 internal disclosure as well, making sure that information is not available to 00:04:25.290 --> 00:04:31.570 people within the organization that don't have a need to know. The idea of 00:04:31.570 --> 00:04:38.050 picking up data that should be protected from improper loss or leakage is by 00:04:38.050 --> 00:04:43.100 putting labels on the data to indicate this is top secret information and 00:04:43.100 --> 00:04:50.050 therefore shouldn't be traversing an open network, looking for keywords or even 00:04:50.050 --> 00:04:54.340 strings that could indicate, well, that sure looks like a credit card number, 00:04:54.340 --> 00:04:55.150 for example. 00:04:55.740 --> 00:05:00.850 So a lot of our DLP systems will pick up in cases where data 00:05:00.850 --> 00:05:05.060 may be leaked out either accidentally or intentionally by a 00:05:05.060 --> 00:05:07.560 person and block that from happening. 00:05:09.140 --> 00:05:12.840 We have something else known as DRM, digital rights 00:05:12.840 --> 00:05:17.150 management, or IRM, information rights management. 00:05:17.940 --> 00:05:23.160 This is about protecting data that does go outside of the organization. 00:05:23.740 --> 00:05:28.510 DLP tries to stop it from leaking out, but DRM says we have 00:05:28.510 --> 00:05:32.550 cases where we have to send our data out, but we want to 00:05:32.550 --> 00:05:35.350 protect it even though it is going out. 00:05:36.040 --> 00:05:41.940 We see, for example, that if I'm working on a contract for an organization, it 00:05:41.940 --> 00:05:47.240 could well be that they share sensitive information with me that I need to use 00:05:47.240 --> 00:05:50.750 to do my job, but they have a DRM protected. 00:05:51.140 --> 00:05:53.360 That means that it's encrypted. 00:05:54.040 --> 00:05:58.160 They have a log of every time I looked at that data. They can 00:05:58.640 --> 00:06:03.700 automatically expire so I'm not able to get access to that data after a 00:06:03.700 --> 00:06:07.700 certain date, and there are restrictions on what I can do with that 00:06:07.710 --> 00:06:10.300 data, for example, I can't print it out, 00:06:10.300 --> 00:06:15.710 I can't forward it. Now, this does not prevent somebody from 00:06:15.710 --> 00:06:19.630 taking a picture with their phone of what's on their screen, but 00:06:19.630 --> 00:06:21.860 it's one more layer of protection. 00:06:22.340 --> 00:06:29.520 And the idea, of course, with DRM and IRM is to hopefully provide some level 00:06:29.520 --> 00:06:34.560 of protection for the data that I have to share with an outside third party 00:06:35.240 --> 00:06:40.730 and prevent them from unauthorized actions such as copying and storing that 00:06:40.730 --> 00:06:43.660 data after it's expired, for example.