When we take a look at some of the principles of secure cloud computing,
we need to recognize what are the threats that we are trying to address.
Some of the common cloud threats include attacks and failures that
could happen at any of those layers of, then the system stack
anywhere from, of course, the user layer,
which is where we often say many of the problems lie,
but then at the application layer,
through the application program interfaces, at the database layer,
of course, at the network itself, the operating system,
the hypervisors,
the hardware, and even, of course, the building or facility itself.
All of these layers have their own vulnerabilities
and potential vectors of an attack.
We also mentioned earlier the problem with administrators,
those who have access to all of these layers.
Whether it's a database administrator, a network administrator,
we know that that could be, of course, a method of a
person being able to compromise the system.
So now we have to look at what is adequate security.
The problem with the term like adequate is that it's a word that can mean
anything. When is enough enough? Maybe for one person, adequate was a very low
level of security, whereas somebody else really thinks that security should be
at the ultimate and lock everything down.
But we,
as cloud security professionals, have to understand how to be able
to put together a good security program, one,
which is based on risk like the common threats we just looked at, one,
which is able to look at what options are currently available. And the reason
I stress this is because there's been many cases in the past where a very good
type of risk mitigation option was chosen. It was the chosen of the best
available then, but things have changed.
There are better solutions today.
So as security professionals,
it's always good to take a look at what options are available, go back
to our risk register and say are today's solutions and risk
mitigations adequate according to what we could do today? Maybe we
need to repeat the risk management effort.
We also have to look at what we are required to meet by regulations.
Many of us work in sectors that are heavily regulated.
We even have a legal requirement to have a certain level of uptime
of our systems. We have regulations about the privacy of our
systems, and all of these must be considered when we're putting
together an adequate security solution.
We also have to remember that the purpose of our IT systems,
whether they are cloud‑based or not, is to support business.
We can't come out with a solution that would mean the business can't operate.
And so we have to be considerate of business goals and mission. In all of this,
we come back to the title of the slide, Cost/Benefit
Analysis. Cost/benefit analysis says I should never pay more
to protect something than it's worth.
So therefore,
knowing what the level of risk is helps us to justify the
cost we would incur in order to reduce that risk to an
adequate or acceptable level.
When we look at security controls in the cloud,
the first and very important thing to remember always is that
the first level of security in the cloud comes from contracts.
Having things in service agreements, maintenance agreements,
and contracts that we could say, well, that's kind of a soft thing,
but that is the first and most important because that justifies and mandates
what security will actually be built into our solution.
We also have to look at who would be liable if there was a problem.
And, of course, linked to that is what is the extent of that liability?
It's the sort of case where very often we see this with the
hardware is that they say if it breaks, we'll replace it.
Yeah,
but when it broke, that cost us maybe a million dollars in
lost business. They don't cover that.
That's not part of their liability.
Their liability is only the few hundred dollars of the
actual cost of that piece of hardware.
We also have to remember that a lot of this comes down
to ownership of risk. In the end,
most of the risk is owned by the cloud consumer. It's their
business. And the cloud service provider certainly has some
risk to their reputation, financial risk, and so on.
But when there's something that goes wrong,
for example, with a company that is heavily regulated,
it's not that they can turn around and say it's the
fault of the cloud service provider,
even if it was. The point is that the risk remains with that
company that chose to outsource a certain service.
One of the things we need to do, and we'll look at this especially in the next
module when we look at evaluating cloud service providers, is to have some
method that we can measure compliance, whether or not it's the right to audit,
whether or not it's the regular reviews,
even by a third party to make sure that the cloud service provider is living
up to the terms of those contracts and service agreements.
An important part of all this is to keep our systems secure, and this can
become a little bit of a challenge when we're dealing with things like
patching because we know that patching is something that is being done
usually because there's a known vulnerability.
But how do I know that, for example,
the patches are being applied? And we want to have a process
in place to make sure that's being done.
The thing is that we have a baseline. Here is our security baseline. Here
is the desired configuration of all of our systems.
Now I said desired, though, in many cases,
of course,
truly a baseline should be required settings and configuration, and it
could be based on some of those principles that we've discussed such as a
zero‑trust type of relationship and the requirement that all systems,
including even our virtual machines,
are then patched on a regular basis or quickly after the patches are available.