1 1 00:00:00,270 --> 00:00:01,680 Cloud threats. 2 2 00:00:01,680 --> 00:00:03,210 In this lesson, we're going to talk 3 3 00:00:03,210 --> 00:00:05,790 about some of the cloud threats and vulnerabilities 4 4 00:00:05,790 --> 00:00:08,040 because while the cloud has a lot of benefits, 5 5 00:00:08,040 --> 00:00:10,350 especially in terms of cost and operations, 6 6 00:00:10,350 --> 00:00:11,850 there are some vulnerabilities 7 7 00:00:11,850 --> 00:00:14,760 and some significant issues that we have to consider. 8 8 00:00:14,760 --> 00:00:17,220 Now, most of these vulnerabilities are going to happen 9 9 00:00:17,220 --> 00:00:19,920 in terms of identity and access management, 10 10 00:00:19,920 --> 00:00:21,750 so you really need to do a good job 11 11 00:00:21,750 --> 00:00:24,900 in securing that area because that's your privileges, 12 12 00:00:24,900 --> 00:00:27,960 that's your authorizations and your authentications. 13 13 00:00:27,960 --> 00:00:29,880 Now, what are some of the major threats? 14 14 00:00:29,880 --> 00:00:32,730 Well, it really comes down to four key areas. 15 15 00:00:32,730 --> 00:00:36,360 This includes insecure APIs, improper key management, 16 16 00:00:36,360 --> 00:00:39,690 improper logging and monitoring and unprotected storage. 17 17 00:00:39,690 --> 00:00:44,550 First, insecure application programming interfaces, or APIs. 18 18 00:00:44,550 --> 00:00:46,470 Now, the first thing I want to give you is a word 19 19 00:00:46,470 --> 00:00:47,670 of warning here. 20 20 00:00:47,670 --> 00:00:49,230 When you're using an API, 21 21 00:00:49,230 --> 00:00:52,260 you should always use it over unencrypted channel. 22 22 00:00:52,260 --> 00:00:56,970 That means SSL or TLS using an HTTPS connection. 23 23 00:00:56,970 --> 00:00:59,850 If you don't do that and you just use HTTP, 24 24 00:00:59,850 --> 00:01:02,310 you are asking for somebody to be able to get there 25 25 00:01:02,310 --> 00:01:03,285 and see what you're doing, 26 26 00:01:03,285 --> 00:01:05,790 be able to steal things like your authorization tokens 27 27 00:01:05,790 --> 00:01:07,440 and then use that against you. 28 28 00:01:07,440 --> 00:01:08,700 This is a major issue, 29 29 00:01:08,700 --> 00:01:10,500 so you want to make sure you secure your APIs 30 30 00:01:10,500 --> 00:01:12,480 by having end-to-end encryption. 31 31 00:01:12,480 --> 00:01:14,340 Now, anytime you start getting data 32 32 00:01:14,340 --> 00:01:17,040 when you're running an API, what should you do with it? 33 33 00:01:17,040 --> 00:01:20,550 Well, if you said input validation, you would be right. 34 34 00:01:20,550 --> 00:01:21,630 All of your data received 35 35 00:01:21,630 --> 00:01:24,900 by an API must pass server-side validation routines 36 36 00:01:24,900 --> 00:01:28,050 before you start performing things on that data 37 37 00:01:28,050 --> 00:01:30,330 because you want to make sure nobody's going to use that 38 38 00:01:30,330 --> 00:01:31,770 as a way to inject some code 39 39 00:01:31,770 --> 00:01:34,260 into your site and cause issues. 40 40 00:01:34,260 --> 00:01:36,810 Another thing you have to consider when dealing with APIs, 41 41 00:01:36,810 --> 00:01:39,300 especially when you want to make sure API is secure 42 42 00:01:39,300 --> 00:01:40,920 is you need to think about error handling, 43 43 00:01:40,920 --> 00:01:43,710 and more importantly, error messages. 44 44 00:01:43,710 --> 00:01:45,810 If I as an attacker can go against your system 45 45 00:01:45,810 --> 00:01:47,640 and start putting things against your API, 46 46 00:01:47,640 --> 00:01:49,680 and you start giving me error messages related 47 47 00:01:49,680 --> 00:01:51,990 to authentication and authorization, 48 48 00:01:51,990 --> 00:01:53,280 those things can give me clues 49 49 00:01:53,280 --> 00:01:54,870 on how to exploit your system. 50 50 00:01:54,870 --> 00:01:57,120 So when you want to give somebody an error message, 51 51 00:01:57,120 --> 00:01:59,130 make sure it's been sanitized. 52 52 00:01:59,130 --> 00:02:00,960 You want to make sure it's as simple as possible 53 53 00:02:00,960 --> 00:02:02,430 and just tell us what the error is 54 54 00:02:02,430 --> 00:02:04,470 without giving too much detail. 55 55 00:02:04,470 --> 00:02:05,640 The final thing we have to think about 56 56 00:02:05,640 --> 00:02:08,280 with APIs is we want to make sure they're not subject 57 57 00:02:08,280 --> 00:02:09,930 to a denial-of-service attack. 58 58 00:02:09,930 --> 00:02:11,310 And the way we can do this is 59 59 00:02:11,310 --> 00:02:14,310 by implementing throttling or rate limiting mechanisms. 60 60 00:02:14,310 --> 00:02:16,830 This will protect us from a denial-of-service attack. 61 61 00:02:16,830 --> 00:02:18,720 Essentially, an API can sit 62 62 00:02:18,720 --> 00:02:21,690 and take a certain amount of input from its users. 63 63 00:02:21,690 --> 00:02:22,950 It can also get requests 64 64 00:02:22,950 --> 00:02:25,320 for a certain amount of input from its users. 65 65 00:02:25,320 --> 00:02:26,910 And when it does this, it needs to be able 66 66 00:02:26,910 --> 00:02:28,320 to know what that is. 67 67 00:02:28,320 --> 00:02:31,260 For instance, one of the APIs I use has a rate limit 68 68 00:02:31,260 --> 00:02:33,330 of 100 requests per minute. 69 69 00:02:33,330 --> 00:02:35,460 If I do more than 100 requests per minute, 70 70 00:02:35,460 --> 00:02:37,890 it will stop me, it won't answer them, 71 71 00:02:37,890 --> 00:02:40,710 and it will start ignoring my IP for at least 20 minutes 72 72 00:02:40,710 --> 00:02:42,540 and then I can go back and ask again. 73 73 00:02:42,540 --> 00:02:44,220 So these are things they can put in place 74 74 00:02:44,220 --> 00:02:45,900 to prevent somebody from just going and going, 75 75 00:02:45,900 --> 00:02:46,733 hey, give me an answer. 76 76 00:02:46,733 --> 00:02:47,940 Hey, give me an answer. Hey, give me an answer. 77 77 00:02:47,940 --> 00:02:50,100 Hey, give me an answer over and over and over again 78 78 00:02:50,100 --> 00:02:52,140 causing a denial-of-service. 79 79 00:02:52,140 --> 00:02:54,000 Now, the second main area we want to talk about 80 80 00:02:54,000 --> 00:02:56,040 is improper key management. 81 81 00:02:56,040 --> 00:02:57,420 Now, this is a really important thing 82 82 00:02:57,420 --> 00:02:59,970 because a lot of the things you're going to use your keys for 83 83 00:02:59,970 --> 00:03:01,950 are things like cryptography, 84 84 00:03:01,950 --> 00:03:04,020 authentication, and authorization. 85 85 00:03:04,020 --> 00:03:06,660 And so these are areas to help you secure your stuff. 86 86 00:03:06,660 --> 00:03:08,370 And if you're not having proper key management, 87 87 00:03:08,370 --> 00:03:10,560 you're going to have a very insecure API. 88 88 00:03:10,560 --> 00:03:12,420 Whenever you're using an API, 89 89 00:03:12,420 --> 00:03:13,470 you need to make sure you're using 90 90 00:03:13,470 --> 00:03:16,080 secure authentication and authorization. 91 91 00:03:16,080 --> 00:03:17,190 How do you do that? 92 92 00:03:17,190 --> 00:03:18,270 But we've already talked about things 93 93 00:03:18,270 --> 00:03:21,200 like SAML and OAuth and OIDC, 94 94 00:03:21,200 --> 00:03:23,730 and you want to use those things to do your authentication 95 95 00:03:23,730 --> 00:03:26,790 and authorization before you access data. 96 96 00:03:26,790 --> 00:03:28,770 Another word of warning I have for you here. 97 97 00:03:28,770 --> 00:03:32,190 Do not hard code or embed your key in the source code. 98 98 00:03:32,190 --> 00:03:33,660 We talked about this back when we talked 99 99 00:03:33,660 --> 00:03:35,490 about best coding practices. 100 100 00:03:35,490 --> 00:03:36,780 You never want to hard code 101 101 00:03:36,780 --> 00:03:39,450 or embed the actual key inside the source code. 102 102 00:03:39,450 --> 00:03:40,283 Why? 103 103 00:03:40,283 --> 00:03:42,750 Because if an attacker can get ahold of your source code 104 104 00:03:42,750 --> 00:03:44,100 or reverse engineer it, 105 105 00:03:44,100 --> 00:03:45,660 they're going to have access to your keys. 106 106 00:03:45,660 --> 00:03:47,580 So you never want to do that. 107 107 00:03:47,580 --> 00:03:49,530 Another thing we want to think about is when we're dealing 108 108 00:03:49,530 --> 00:03:51,090 with keys, anytime you have a key 109 109 00:03:51,090 --> 00:03:53,460 that you're no longer needing, go ahead and delete it. 110 110 00:03:53,460 --> 00:03:55,260 If it's unnecessary, delete it. 111 111 00:03:55,260 --> 00:03:57,180 And anytime you start moving your system 112 112 00:03:57,180 --> 00:03:59,700 from a design environment to a staging environment 113 113 00:03:59,700 --> 00:04:02,460 to a production environment, you should regenerate keys 114 114 00:04:02,460 --> 00:04:03,360 and get new keys 115 115 00:04:03,360 --> 00:04:05,220 because those that have been the development pipeline 116 116 00:04:05,220 --> 00:04:07,410 have been exposed to a lot of programmers 117 117 00:04:07,410 --> 00:04:08,760 and a lot of reviewers. 118 118 00:04:08,760 --> 00:04:09,900 So when you're going to production, 119 119 00:04:09,900 --> 00:04:12,690 you want to generate new keys that nobody knows. 120 120 00:04:12,690 --> 00:04:14,580 Finally, the other thing you have to think about 121 121 00:04:14,580 --> 00:04:17,010 is making sure that you have hardening policies 122 122 00:04:17,010 --> 00:04:19,050 in place for any of your client hosts 123 123 00:04:19,050 --> 00:04:22,290 and any of your servers and the development workstations. 124 124 00:04:22,290 --> 00:04:24,600 Anything you're working on should always be hardened 125 125 00:04:24,600 --> 00:04:26,910 and they should only run whitelisted applications, 126 126 00:04:26,910 --> 00:04:29,220 especially things that are going to touch your services 127 127 00:04:29,220 --> 00:04:31,290 and things that are going to touch your API. 128 128 00:04:31,290 --> 00:04:32,123 Anytime you're dealing 129 129 00:04:32,123 --> 00:04:33,720 with a system that's making these keys, 130 130 00:04:33,720 --> 00:04:36,000 it needs to be secured as well. 131 131 00:04:36,000 --> 00:04:37,590 The third main area we want to talk about 132 132 00:04:37,590 --> 00:04:39,450 is logging and monitoring, and one 133 133 00:04:39,450 --> 00:04:41,610 of the big problems is insufficient logging 134 134 00:04:41,610 --> 00:04:43,770 and monitoring of cloud services. 135 135 00:04:43,770 --> 00:04:45,210 Now, again, here's a word of warning. 136 136 00:04:45,210 --> 00:04:47,490 If you're dealing with a software as a service, 137 137 00:04:47,490 --> 00:04:50,130 many times you're not going to have any ability 138 138 00:04:50,130 --> 00:04:52,830 to access log files or monitoring tools. 139 139 00:04:52,830 --> 00:04:54,540 For instance, think about Gmail. 140 140 00:04:54,540 --> 00:04:56,490 That is a software as a service tool. 141 141 00:04:56,490 --> 00:04:57,450 If you use Gmail, 142 142 00:04:57,450 --> 00:05:00,030 can you go in there and look at your log files? 143 143 00:05:00,030 --> 00:05:01,710 Can you go in there and look at your audit logs? 144 144 00:05:01,710 --> 00:05:03,510 Can you go in there and look at your monitoring tools to see 145 145 00:05:03,510 --> 00:05:04,950 if the service is up and down? 146 146 00:05:04,950 --> 00:05:07,950 No, because that's Google's job, not your job. 147 147 00:05:07,950 --> 00:05:10,290 And so this is a weak area for us if we start using a lot 148 148 00:05:10,290 --> 00:05:12,600 of software as a service inside of our companies. 149 149 00:05:12,600 --> 00:05:14,700 Now remember, when you're dealing with logs, 150 150 00:05:14,700 --> 00:05:18,390 your logs have to be copied from these elastic workstations 151 151 00:05:18,390 --> 00:05:20,730 into some place for long-term storage. 152 152 00:05:20,730 --> 00:05:22,770 For example, when we have a cloud service 153 153 00:05:22,770 --> 00:05:24,660 and we spin up a new virtual machine 154 154 00:05:24,660 --> 00:05:25,770 and we use it for a while 155 155 00:05:25,770 --> 00:05:26,790 because we have a higher demand, 156 156 00:05:26,790 --> 00:05:28,560 and then that demand is gone, 157 157 00:05:28,560 --> 00:05:30,900 if we're storing those logs on that machine 158 158 00:05:30,900 --> 00:05:32,490 and that machine now is deprovisioned, 159 159 00:05:32,490 --> 00:05:34,020 we just lost all the logs. 160 160 00:05:34,020 --> 00:05:36,420 So you want to make sure those are copied off 161 161 00:05:36,420 --> 00:05:39,090 to a non-elastic storage unit, and they're there 162 162 00:05:39,090 --> 00:05:40,920 for long-term retention based 163 163 00:05:40,920 --> 00:05:43,140 on your data retention policies. 164 164 00:05:43,140 --> 00:05:44,760 The fourth and final area we want to talk 165 165 00:05:44,760 --> 00:05:46,980 about is unprotected storage. 166 166 00:05:46,980 --> 00:05:48,960 Now, there are lots of ways you can do storage 167 167 00:05:48,960 --> 00:05:51,210 inside the cloud, but most storage containers 168 168 00:05:51,210 --> 00:05:53,550 are going to be referred to as one of two things. 169 169 00:05:53,550 --> 00:05:56,460 They're either going to be called buckets or blobs. 170 170 00:05:56,460 --> 00:05:57,480 When you call them buckets, 171 171 00:05:57,480 --> 00:05:59,520 this is something that we use inside of AWS. 172 172 00:05:59,520 --> 00:06:02,610 When we talk about blobs, it's usually in Microsoft Azure. 173 173 00:06:02,610 --> 00:06:05,400 Either way, we're talking about cloud storage here. 174 174 00:06:05,400 --> 00:06:06,990 Essentially, when we have a file 175 175 00:06:06,990 --> 00:06:09,030 and we want to save it someplace, we have to put it 176 176 00:06:09,030 --> 00:06:12,080 in a container and that container, a bucket or a blob 177 177 00:06:12,080 --> 00:06:14,070 is going to be someplace that we store it. 178 178 00:06:14,070 --> 00:06:15,390 And that can be actually located 179 179 00:06:15,390 --> 00:06:16,860 in lots of different places. 180 180 00:06:16,860 --> 00:06:18,420 For instance, your container could be 181 181 00:06:18,420 --> 00:06:20,100 in the East Coast or the West Coast. 182 182 00:06:20,100 --> 00:06:22,590 It could be in a specific region or any region. 183 183 00:06:22,590 --> 00:06:23,423 But the big thing 184 184 00:06:23,423 --> 00:06:26,250 is you can't nest one container in another. 185 185 00:06:26,250 --> 00:06:28,680 Each container is going to host its own data objects, 186 186 00:06:28,680 --> 00:06:31,470 which are those files that we want to store on that system. 187 187 00:06:31,470 --> 00:06:33,990 Now, once you have that, you have to set up access control 188 188 00:06:33,990 --> 00:06:36,450 and this is where my word of warning comes in. 189 189 00:06:36,450 --> 00:06:38,820 Access control to storage is administered 190 190 00:06:38,820 --> 00:06:40,500 through your container policies. 191 191 00:06:40,500 --> 00:06:42,900 It's also done through your IAM authorizations 192 192 00:06:42,900 --> 00:06:45,240 and it's done through object ACLs. 193 193 00:06:45,240 --> 00:06:46,710 By combining these three things, 194 194 00:06:46,710 --> 00:06:48,990 you can get a good level of security 195 195 00:06:48,990 --> 00:06:51,780 but if you misconfigure them, it can be a problem. 196 196 00:06:51,780 --> 00:06:53,550 And that brings us to the other problem here. 197 197 00:06:53,550 --> 00:06:56,040 A lot of times, people have incorrect permissions. 198 198 00:06:56,040 --> 00:06:57,390 Why does that happen? 199 199 00:06:57,390 --> 00:06:59,430 Well, because when you create a new storage container 200 200 00:06:59,430 --> 00:07:00,870 or bucket or blob, 201 201 00:07:00,870 --> 00:07:03,210 it's going to create default read, write permissions 202 202 00:07:03,210 --> 00:07:05,280 for that thing during creation. 203 203 00:07:05,280 --> 00:07:06,750 And if you don't go and change those, 204 204 00:07:06,750 --> 00:07:08,610 you're going to leave those and they're going to be left over 205 205 00:07:08,610 --> 00:07:11,190 and that's going to cause incorrect permissions later on. 206 206 00:07:11,190 --> 00:07:13,050 So you always want to make sure you modify those permissions 207 207 00:07:13,050 --> 00:07:14,940 to the level you need. 208 208 00:07:14,940 --> 00:07:16,290 The next thing we want to talk about here 209 209 00:07:16,290 --> 00:07:18,000 is incorrect origin settings, 210 210 00:07:18,000 --> 00:07:21,270 which is another issue inside of insecure storage. 211 211 00:07:21,270 --> 00:07:22,140 Now, this happens 212 212 00:07:22,140 --> 00:07:25,140 because when you're dealing with content delivery networks, 213 213 00:07:25,140 --> 00:07:26,940 you have to configure what's known 214 214 00:07:26,940 --> 00:07:29,970 as a Cross-Origin Resource Sharing policy. 215 215 00:07:29,970 --> 00:07:32,490 This is a CORS policy. 216 216 00:07:32,490 --> 00:07:35,370 Now, when we talk about a cross-origin sharing policy, 217 217 00:07:35,370 --> 00:07:37,380 this is a content delivery network policy 218 218 00:07:37,380 --> 00:07:39,270 that instructs the browser to treat requests 219 219 00:07:39,270 --> 00:07:41,970 from nominated domains as safe. 220 220 00:07:41,970 --> 00:07:43,800 Essentially, you're going to put things out 221 221 00:07:43,800 --> 00:07:45,450 into the content delivery network. 222 222 00:07:45,450 --> 00:07:46,470 These are little edges 223 223 00:07:46,470 --> 00:07:48,630 of the cloud service all over the world 224 224 00:07:48,630 --> 00:07:50,820 and if you're using things from multiple domains 225 225 00:07:50,820 --> 00:07:53,730 because they're all coming from different CDN edge points, 226 226 00:07:53,730 --> 00:07:55,410 they have to be able to trust each other 227 227 00:07:55,410 --> 00:07:58,680 and that's what your CORS policy is going to do for you. 228 228 00:07:58,680 --> 00:08:00,660 Now, the last word of warning I have for you 229 229 00:08:00,660 --> 00:08:03,210 is that a weak CORS policy can expose your site 230 230 00:08:03,210 --> 00:08:06,330 to vulnerabilities, such as cross-site scripting attacks. 231 231 00:08:06,330 --> 00:08:08,280 So you want to be aware of this, and you want to make sure 232 232 00:08:08,280 --> 00:08:10,280 that your policies are written properly.