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