-: Cloud Threats.
In this lesson, we're going to talk about
some of the cloud threats and vulnerabilities.
Because while the cloud has a lot of benefits,
especially in terms of cost and operations,
there are some vulnerabilities
and some significant issues that we have to consider.
Now, most of these vulnerabilities are going to happen
in terms of identity and access management.
So, you really need to do a good job in securing that area,
because that's your privileges,
that's your authorizations, and your authentications.
Now, what are some of the major threats?
Well, it really comes down to four key areas.
This includes insecure APIs, improper key management,
improper logging and monitoring, and unprotected storage.
First, insecure application programming interfaces, or APIs.
Now, the first thing I want to give you
is a word of warning here.
When you're using an API,
you should always use it over an encrypted channel.
That means SSL or TLS using an HTTPS connection.
If you don't do that, and you just use HTTP,
you are asking for somebody to be able to get there
and see what you're doing,
be able to steal things like your authorization tokens,
and then use that against you.
This is a major issue,
so you want to make sure you secure your APIs
by having end-to-end encryption.
Now, anytime you start getting data
when you're running an API, what should you do with it?
Well, if you said input validation, you would be right.
All of your data received by an API
must pass server-side validation routines
before you start performing things on that data.
Because you want to make sure nobody's going to use that
as a way to inject some code into your site
and cause issues.
Another thing you have to consider when dealing with APIs,
especially when you want to make sure API is secure,
is you need to think about error handling
and, more importantly, error messages.
If I, as an attacker, can go against your system
and start putting things against your API,
and you start giving me error messages
related to authentication and authorization,
those things can give me clues
on how to exploit your system.
So, when you want to give somebody an error message,
make sure it's been sanitized.
You want to make sure it's as simple as possible
and just tells what the error is,
without giving too much detail.
The final thing we have to think about with APIs
is we want to make sure they're not subject
to a denial of service attack.
And the way we can do this
is by implementing throttling or rate-limiting mechanisms.
This will protect us from a denial of service attack.
Essentially, an API can sit
and take a certain amount of input from its users.
It can also get requests for a certain amount
of input from its users.
And when it does this, it needs to be able
to know what that is.
For instance, one of the APIs I use
has a rate limit of 100 requests per minute.
If I do more than 100 requests per minute,
it will stop me, it won't answer them,
and it will start ignoring my IP for at least 20 minutes,
and then I can go back and ask again.
So, these are things they can put in place
to prevent somebody from just going
and going, hey, give me an answer, hey, give me an answer.
hey, give me an answer, hey, give me answer
over and over and over again, causing a denial of service.
Now, the second main area we want to talk about
is improper key management.
Now, this is a really important thing,
because a lot of the things you're going to use your keys for
are things like cryptography,
authentication, and authorization.
And so, these are the areas to help you secure your stuff.
And if you're not having proper key management,
you're going to have a very insecure API.
Whenever you're using an API,
you need to make sure you're using secure
authentication and authorization,
things like SAML and OAuth and OIDC,
and you want to use those things
to do your authentication and authorization
before you access data.
Another word of warning I have for you here,
do not hardcode or embed your key in the source code.
We talked about this back when
we talked about best coding practices.
You never want to hardcode or embed
the actual key inside the source code.
Why?
Because if an attacker can get ahold of your source code
or reverse engineer it,
they're going to have access to your keys.
So, you never want to do that.
Another thing we want to think about
is when we're dealing with keys,
anytime you have a key that you're no longer needing,
go ahead and delete it.
If it's unnecessary, delete it.
And anytime you start moving your system
from a design environment to a staging environment,
to a production environment,
you should regenerate keys and get new keys.
Because those that have been in the development pipeline
have been exposed to a lot of programmers
and a lot of reviewers.
So, when you're going to production,
you want to generate new keys that nobody knows.
Finally, the other thing you have to think about
is making sure that you have hardening policies in place
for any of your client hosts and any of your servers
and the development workstations.
Anything you're working on should always be hardened,
and they should only run whitelisted applications,
especially things that are going to touch your services
and things that are going to touch your API.
Anytime you're dealing with a system
that's making these keys, it needs to be secured, as well.
The third main area we want to talk about
is logging and monitoring.
And one of the big problems is insufficient logging
and monitoring of cloud services.
Now, again, here's a word of warning.
If you're dealing with a software as a service,
many times, you're not going to have any ability
to access log files or monitoring tools.
For instance, think about Gmail.
That is a software as a service tool.
If you use Gmail, can you go in there
and look at your log files?
Can you go in there and look at your audit logs?
Can you go in there and look at your monitoring tools
to see if the service is up and down?
No, because that's Google's job, not your job.
And so, this is a weak area for us
if we start using a lot of software as a service
inside of our companies.
Now, remember, when you're dealing with logs,
your logs have to be copied from these elastic workstations
into some place for longterm storage.
For example, when we have a cloud service
and we spin up a new virtual machine
and we use it for a while because we have a higher demand,
and then that demand is gone,
if we're storing those logs on that machine
and that machine now is deprovisioned,
we just lost all the logs.
So, you want to make sure those are copied off
to a non-elastic storage unit,
and they're there for long-term retention
based on your data retention policies.
The fourth and final area we want to talk about
is unprotected storage.
Now, there are lots of ways
you can do storage inside the cloud,
but most storage containers are going to be referred to
as one of two things.
They're either going to be called buckets or blobs.
When you call them buckets,
this is something that we use inside of AWS.
When we talk about blobs, it's usually in Microsoft Azure.
Either way, we're talking about cloud storage here.
Essentially, when we have a file
and we want to save it someplace,
we have to put it in a container,
and that container, a bucket or a blob,
is going to be someplace that we store it.
And that can be actually located
in lots of different places.
For instance, your container could be
in the East Coast or the West Coast.
It could be in a specific region or any region.
But the big thing is you can't nest
one container in another.
Each container is going to host its own data objects,
which are those files that we want to store on that system.
Now, once you have that, you have to set up access control.
And this is where my word of warning comes in.
Access control to storage is administered
through your container policies.
It's also done through your IAM authorizations,
and it's done through object ACLs.
By combining these three things,
you can get a good level of security.
But if you misconfigure them, it can be a problem.
And that brings us to the other problem here.
A lot of times, people have incorrect permissions.
Why does that happen?
Well, because when you create a new storage container
or bucket or blob,
it's going to create default read/write permissions
for that thing during creation.
And if you don't go and change those,
you're going to leave those, and they're going to be left over,
and that's going to cause incorrect permissions later on.
So, you always want to make sure you modify those permissions
to the level you need.
The next thing we want to talk about here
is incorrect origin settings,
which is another issue inside of insecure storage.
Now, this happens because when you're dealing
with content delivery networks,
you have to configure what's known
as a cross-origin resource sharing policy.
This is a C-O-R-S policy.
Now, when we talk about a cross-origin sharing policy,
this is a content delivery network policy
that instructs the browser to treat requests
from nominated domains as safe.
Essentially, you're going to put things
out into the content delivery network.
These are little edges of the cloud service
all over the world.
And if you're using things from multiple domains,
because they're all coming from different CDN edge points,
they have to be able to trust each other.
And that's what your CORS policy is going to do for you.
Now, the last word of warning I have for you
is that a weak CORS policy
can expose your site to vulnerabilities,
such as cross-site scripting attacks.
So, you want to be aware of this
and you want to make sure
that your policies are written properly.