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