WEBVTT 00:00:01.040 --> 00:00:03.860 When it comes to protecting our data in the cloud, 00:00:04.340 --> 00:00:06.430 we need to monitor for compliance. 00:00:06.940 --> 00:00:11.560 This is why we have to take a look at cloud data event management as well. 00:00:12.340 --> 00:00:14.690 What we see is that, in many cases, cloud 00:00:14.690 --> 00:00:16.820 deployments are kind of forgotten about. 00:00:16.830 --> 00:00:17.460 In fact, 00:00:17.840 --> 00:00:21.340 many organizations have no idea how many different cloud 00:00:21.340 --> 00:00:24.870 deployments they're using until maybe they install something 00:00:24.870 --> 00:00:28.840 like a CASB and it opens their eyes to see how much data they 00:00:28.840 --> 00:00:30.760 have in various places on the cloud. 00:00:31.640 --> 00:00:33.760 We need to monitor for compliance, 00:00:33.970 --> 00:00:37.290 compliance with contracts and service‑level agreements. 00:00:37.670 --> 00:00:42.760 The first step is always to ensure there's a contract there that stipulates and 00:00:42.760 --> 00:00:48.680 mandates what type of data protection must be provided as an agreement between 00:00:48.680 --> 00:00:51.860 both the cloud consumer and cloud service provider. 00:00:53.140 --> 00:00:54.940 Then we monitor for compliance. 00:00:55.140 --> 00:00:59.440 We review the logs. Who accessed the data? And this is 00:00:59.440 --> 00:01:02.810 something that should be done on a regular basis. 00:01:02.820 --> 00:01:08.510 Are people accessing the data at strange times? Are people accessing 00:01:08.510 --> 00:01:12.810 the data who don't have a business need to know? And this is something 00:01:12.810 --> 00:01:18.030 that we have to look for to try to discover if there is some misuse of 00:01:18.030 --> 00:01:20.860 our data or inappropriate access. 00:01:21.520 --> 00:01:24.710 We should carefully review access controls. 00:01:24.900 --> 00:01:29.060 Maybe a person worked in one area and needed access to this data, but 00:01:29.060 --> 00:01:32.830 they've moved. They don't need that anymore, and that should be removed 00:01:32.830 --> 00:01:37.940 under principles of, say, need to know. We should make sure we have 00:01:37.940 --> 00:01:41.100 encryption and the encryption is being applied. 00:01:41.540 --> 00:01:45.410 We've seen cases where an organization believed that all of their 00:01:45.410 --> 00:01:49.170 network traffic was encrypted, but when they started to look at it, 00:01:49.180 --> 00:01:51.520 it obviously wasn't being encrypted. 00:01:52.340 --> 00:01:55.120 The other thing we should review is to make sure that old 00:01:55.120 --> 00:01:59.110 equipment is being destroyed, and no one is going to be able to 00:01:59.110 --> 00:02:03.650 pick up our data off of a piece of equipment that a cloud 00:02:03.650 --> 00:02:05.750 service provider has discarded. 00:02:07.240 --> 00:02:12.020 When we do log review, one of the problems is that there's just too much of it. 00:02:12.440 --> 00:02:17.710 We have enormous amounts of log data and certainly not enough 00:02:17.710 --> 00:02:20.360 time to be able to look at it all manually. 00:02:21.240 --> 00:02:27.840 There is a cost associated with storing logs, as well as the performance 00:02:27.840 --> 00:02:34.250 impact on our networks and systems from creating all of these logs. But we 00:02:34.250 --> 00:02:40.060 need a team of people that has the skills and, of course, tools necessary to 00:02:40.060 --> 00:02:44.660 be able to take a look at a log and find the things that are important to 00:02:44.660 --> 00:02:51.210 doing analysis of those logs. A lot of the different events we are going to 00:02:51.210 --> 00:02:55.610 look for, we're going to examine according to what IP address maybe did they 00:02:55.610 --> 00:02:56.250 come from? 00:02:56.840 --> 00:03:02.220 Where in the world were they located at the time? And, of course, to try 00:03:02.220 --> 00:03:09.620 to identify who it was. Was it an authorized entity or was it a suspicious 00:03:09.630 --> 00:03:12.350 entity trying to get access to our systems? 00:03:13.140 --> 00:03:17.890 The idea of geolocation and identifying where a person is 00:03:18.140 --> 00:03:20.920 is also used within an organization. 00:03:20.920 --> 00:03:25.230 Maybe a person's access is different if they're in the office than, for 00:03:25.230 --> 00:03:28.160 example, if they're not working in the office that day, 00:03:28.170 --> 00:03:32.870 they're working from home or at a remote location. There can come 00:03:32.870 --> 00:03:37.810 times that we need to do an investigation. And an investigation in 00:03:37.810 --> 00:03:41.770 the cloud becomes a little more challenging because we have to have 00:03:41.770 --> 00:03:47.160 the cooperation of the cloud provider to provide us the logs and 00:03:47.160 --> 00:03:48.550 information we need. 00:03:49.240 --> 00:03:54.690 So there should always be within a service‑level agreement an establishment of 00:03:54.700 --> 00:04:01.790 a communication path or liaison who we can reach out to that is our primary 00:04:01.790 --> 00:04:07.220 point of contact if we need some information. That liaison will then ensure 00:04:07.220 --> 00:04:12.290 that the information we get is complete and hasn't been altered in some way 00:04:12.290 --> 00:04:14.250 before it was provided to us. 00:04:15.800 --> 00:04:18.700 So this should be done through, obviously, a formal 00:04:18.700 --> 00:04:22.570 agreement because an investigation could, of course, end 00:04:22.570 --> 00:04:24.750 up being a legal matter as well. 00:04:25.440 --> 00:04:31.220 And this also should review what happens if law enforcement needs access to 00:04:31.220 --> 00:04:35.970 our data? There can be times that maybe law enforcement shows up at a cloud 00:04:35.970 --> 00:04:39.860 service provider and they want access to our data. 00:04:39.870 --> 00:04:42.880 We want to make sure that they only get access to the 00:04:42.880 --> 00:04:45.450 data that they are authorized to obtain. 00:04:46.040 --> 00:04:49.660 But obviously, we want to be compliant with any type of 00:04:49.670 --> 00:04:52.160 court mandate, warrant, and so on. 00:04:52.640 --> 00:04:57.540 And the idea of law enforcement is an important thing here because, in 00:04:57.540 --> 00:05:03.740 some cases, even a cloud provider may be required not to disclose the 00:05:03.740 --> 00:05:06.710 fact that some type of warrant has been issued. 00:05:06.860 --> 00:05:10.540 We want to cover this. We want to deal with what happens if the 00:05:10.540 --> 00:05:14.350 cloud provider finds out that one of our employees was maybe 00:05:14.350 --> 00:05:17.050 doing something that is improper, 00:05:17.340 --> 00:05:22.760 even possibly illegal based on those cloud‑based services as well. 00:05:24.240 --> 00:05:28.120 We want to be compliant with the needs of regulators who when 00:05:28.120 --> 00:05:31.160 they're trying to enforce things like privacy laws, 00:05:31.540 --> 00:05:35.860 want us to be able to prove that unauthorized people aren't looking 00:05:35.870 --> 00:05:41.420 at our data, for example. We also have to look at this area of 00:05:41.430 --> 00:05:44.450 criticality and therefore data availability. 00:05:44.940 --> 00:05:49.520 Will the data be available when it's required in a timely manner, for 00:05:49.520 --> 00:05:54.290 example? And that includes not just production data, 00:05:54.290 --> 00:05:56.390 but sometimes archived data. 00:05:56.410 --> 00:06:00.540 Even going back in logs, how long do we keep our logs? 00:06:00.540 --> 00:06:03.030 Do we keep them for 7 days, 00:06:03.030 --> 00:06:09.320 30 days or years? As well as if a request comes in, how quickly 00:06:09.320 --> 00:06:12.660 can that data be then provided back to us? 00:06:14.340 --> 00:06:17.900 It also should be in some type of acceptable format. 00:06:17.980 --> 00:06:23.060 We put the data in a format that we'll be able to read or use as well. 00:06:24.240 --> 00:06:28.980 One of the things that has been a tremendous advantage for many 00:06:28.980 --> 00:06:33.260 companies ever since the days of managed security service providers 00:06:33.840 --> 00:06:37.050 was the use of a security operation center. 00:06:37.740 --> 00:06:39.960 Now, many companies have their own, 00:06:40.340 --> 00:06:45.330 but especially many small companies, it just wouldn't pay for them 00:06:45.330 --> 00:06:50.130 to try to develop the skills or the personnel necessary to do 00:06:50.130 --> 00:06:52.460 proper investigations and monitoring. 00:06:53.040 --> 00:06:56.380 So, those were often provided through a managed security 00:06:56.380 --> 00:06:58.730 service provider as a third‑party service. 00:06:59.140 --> 00:07:02.730 But now we also see, of course, many of the cloud providers 00:07:02.940 --> 00:07:05.460 provide this type of a service as well. 00:07:07.140 --> 00:07:09.390 The advantage is that, let's say, 00:07:09.390 --> 00:07:16.130 a cloud provider hosts information for 100 different companies, and they are 00:07:16.140 --> 00:07:21.680 setting up through their security operations center monitoring of all of their 00:07:21.690 --> 00:07:26.170 hardware, networks, and that allows, of course, 00:07:26.180 --> 00:07:29.760 a central point of monitoring for those 100 companies. 00:07:30.640 --> 00:07:35.390 And it means that the people working in the SOC are getting a lot more 00:07:35.390 --> 00:07:40.180 experience than they would if they worked for any one of those individual 00:07:40.190 --> 00:07:45.410 companies. They obtain the skills they need. They have the experience. 00:07:45.410 --> 00:07:49.420 They're able, in many cases, to be able to detect something, which is 00:07:49.420 --> 00:07:52.060 abnormal faster than somebody else. 00:07:52.840 --> 00:07:54.360 There's also an advantage. 00:07:54.940 --> 00:07:57.960 Let's say of those 100 companies, one of them had a problem. 00:07:58.940 --> 00:08:03.910 Now the staff that is working on resolving that problem learns and can 00:08:03.910 --> 00:08:08.390 go to the other 99 companies and make sure they're not vulnerable or 00:08:08.390 --> 00:08:11.360 exposed to that same type of attack as well. 00:08:11.940 --> 00:08:14.650 There's a lot of advantages through these types of 00:08:14.650 --> 00:08:17.960 centralized monitoring systems. 00:08:19.840 --> 00:08:23.840 When we need to do an investigation in the cloud, obviously 00:08:23.840 --> 00:08:26.460 this depends on our type of deployment model. 00:08:26.940 --> 00:08:29.160 In the case of Software as a Service, 00:08:29.300 --> 00:08:33.990 everything rests really with a cloud service provider with the exception 00:08:33.990 --> 00:08:39.870 of things like access control. I, as a cloud consumer, determine who has 00:08:39.870 --> 00:08:45.140 access of my employees to the data, but all of the data logs and 00:08:45.140 --> 00:08:50.450 everything are really held by the cloud service provider. In the case of 00:08:50.450 --> 00:08:53.960 Platform as a Service, this can be a split responsibility. 00:08:54.340 --> 00:08:58.880 I still manage access control, but it could well be that I have certain logs 00:08:58.880 --> 00:09:02.610 that I manage, but there could be ones that are managed also by the cloud 00:09:02.610 --> 00:09:06.060 service provider as well, say, a database journal. 00:09:08.040 --> 00:09:11.930 If Infrastructure as a Service, really the primary 00:09:11.930 --> 00:09:14.960 responsibility is going to be that of the cloud consumer. 00:09:15.540 --> 00:09:20.380 The only things that the cloud service provider could be involved in was, 00:09:20.390 --> 00:09:24.960 say, physical access or the security of hardware and so on. 00:09:27.340 --> 00:09:31.360 One of the things that's important when we do an investigation 00:09:32.140 --> 00:09:35.250 is to be able to identify who was involved. 00:09:35.940 --> 00:09:40.110 And it's important here that we have the ability through logging, 00:09:40.110 --> 00:09:45.550 for example, to track all activity and be able to associate that 00:09:45.550 --> 00:09:50.950 activity with an identifier, whether or not that's a user ID or 00:09:50.950 --> 00:09:52.850 an IP address and so on. 00:09:54.140 --> 00:09:55.820 But these logs are important. 00:09:55.980 --> 00:10:00.560 They're necessary in order to do an investigation and hopefully 00:10:00.600 --> 00:10:03.560 get the right results from that investigation. 00:10:04.290 --> 00:10:10.310 So therefore, we should very strictly control who has access to those 00:10:10.310 --> 00:10:15.650 logs. We'll often see that logs will be written off to a separate system 00:10:15.730 --> 00:10:19.720 where even a system administrator is not going to be able to get in and, 00:10:19.720 --> 00:10:22.620 say, delete any entries in those logs. 00:10:23.840 --> 00:10:25.890 When we create the log, 00:10:26.060 --> 00:10:32.570 we then calculate what is the hash of that log so that over time 00:10:32.570 --> 00:10:35.080 we can prove that log has not been altered. 00:10:35.080 --> 00:10:39.720 It's still the original genuine log that was created at the time of 00:10:39.720 --> 00:10:45.180 the incident. Storing everything on a separate system can be good, For 00:10:45.180 --> 00:10:47.250 one, it may be a little less expensive, 00:10:47.740 --> 00:10:53.350 but also it can prevent unauthorized access, as well as, as we did 00:10:53.350 --> 00:10:57.960 with databases with remote journaling, one of the big advantages was 00:10:58.340 --> 00:11:01.390 that if the primary hardware was damaged, 00:11:01.400 --> 00:11:05.090 we still have all the log entries on that separate system so 00:11:05.090 --> 00:11:08.420 we can investigate and know what happened or if, in the case 00:11:08.420 --> 00:11:11.150 of a database, rebuild lost data. 00:11:12.340 --> 00:11:16.810 Doing research of, say, forensics in support of 00:11:16.810 --> 00:11:20.460 investigation is often called data discovery. 00:11:21.240 --> 00:11:26.060 When we do this, we have to be careful that we do not violate a person's rights. 00:11:26.440 --> 00:11:31.150 Everybody has certain reasonable expectations of privacy, for example. 00:11:31.540 --> 00:11:36.830 And if we allow a person to use their bring your own device 00:11:36.860 --> 00:11:40.760 laptop, both for personal and for business use, 00:11:40.990 --> 00:11:44.270 I have to be careful that if I'm doing an investigation, 00:11:44.370 --> 00:11:46.860 I'm not looking into their personal data. 00:11:47.340 --> 00:11:50.960 There is a requirement here to comply with regulations. 00:11:51.640 --> 00:11:55.450 People should know whether or not activity is being logged, 00:11:55.540 --> 00:11:59.180 and, of course, they should know whether or not we are 00:11:59.180 --> 00:12:01.560 monitoring their traffic as well. 00:12:03.140 --> 00:12:06.710 An important thing in supporting an investigation is the 00:12:06.710 --> 00:12:11.290 establishment of an unbroken record of everything that has 00:12:11.290 --> 00:12:15.480 happened with any type of evidence during the investigation, and 00:12:15.480 --> 00:12:17.860 this is called a chain of custody. 00:12:18.640 --> 00:12:23.860 It's an unbroken record of who had access to that. 00:12:24.440 --> 00:12:25.870 What did they do with it? 00:12:25.960 --> 00:12:28.460 And, of course, when was this? 00:12:28.470 --> 00:12:34.400 How did they protect it and so on? The problem is that in the cloud 00:12:34.400 --> 00:12:39.010 this becomes more difficult because it's not one person who's the 00:12:39.010 --> 00:12:45.050 evidence custodian who can demonstrate they have had control of 00:12:45.050 --> 00:12:46.750 that evidence at all times. 00:12:47.140 --> 00:12:47.460 No, 00:12:47.460 --> 00:12:51.660 originally it came from somebody at the cloud provider out to the cloud 00:12:51.660 --> 00:12:57.120 consumer. And so there's already a bit of a break there in the evidence 00:12:57.120 --> 00:13:02.920 chain. When our evidence is provided by a third party, 00:13:02.920 --> 00:13:06.010 it's never going to be as trustworthy as something that 00:13:06.010 --> 00:13:09.420 we then actually gathered ourselves. 00:13:09.430 --> 00:13:12.570 How do we know that that third party didn't alter it, 00:13:12.580 --> 00:13:17.470 for example? How trustworthy are they? And as well, did they have 00:13:17.470 --> 00:13:21.860 the skill to make sure that all of the relevant evidence was 00:13:21.860 --> 00:13:25.830 obtained and provided? So for all of this, 00:13:25.830 --> 00:13:28.960 we should have clearly defined procedures. 00:13:28.970 --> 00:13:35.560 How do we protect our information and our investigations so that we hopefully 00:13:35.570 --> 00:13:42.460 will have genuine correct information so that the correct analysis can be 00:13:42.460 --> 00:13:48.100 done? One thing that should be brought in here is the idea of non‑disclosure 00:13:48.100 --> 00:13:53.850 agreements. A non‑disclosure agreement means that if a person has access to 00:13:53.850 --> 00:13:58.540 certain sensitive information, they will not share that with anyone else. 00:13:58.540 --> 00:14:00.860 They will not disclose that to someone else. 00:14:01.240 --> 00:14:04.550 And that, of course, goes everything from business partners to 00:14:04.550 --> 00:14:08.460 competitors to, of course, even a partner or spouse. 00:14:09.240 --> 00:14:16.970 The idea of the NDA is that a cloud provider's staff can have access to our 00:14:16.970 --> 00:14:22.430 sensitive data, and they have to know that it's not permissible for them to 00:14:22.430 --> 00:14:26.960 discuss our data with anyone else at any time. 00:14:28.340 --> 00:14:33.650 In summary, this is the most important domain of the CCSP. 00:14:34.240 --> 00:14:38.260 We've looked at the importance of securing data in the cloud, 00:14:38.940 --> 00:14:42.770 and, of course, this included looking at the areas of data 00:14:42.770 --> 00:14:45.150 classification and from that ownership, 00:14:45.740 --> 00:14:50.840 the appropriate controls such as access control and masking, and, of 00:14:50.840 --> 00:14:55.650 course, having a log so we have a record of what actually was done. 00:14:55.650 --> 00:15:00.910 This in the end was all about securing data throughout the data 00:15:00.910 --> 00:15:07.120 lifecycle so that it was protected at all times, in all forms, and, 00:15:07.120 --> 00:15:08.800 of course, in all places.