In order to write secure applications,
we need to know what the threats are to those applications.
Part of the training we must provide is recognition and
acknowledgement of cloud‑based threats.
The threats in the cloud are, for the most part, the same
as threats not in the cloud; however,
the cloud does add in a bit more complexity.
We know that there's always been problems at the hardware level.
There could be, for example,
the meltdown specter problems with hardware that is not providing
proper isolation between different processes.
There can be problems with virtualization,
unpatched, misconfigured systems, for example. In the cloud
environment, there may be fewer network controls,
especially ones that the cloud consumer has control over. There also
can be problems at the communication layer because there are so many
different messages going back and forth,
especially when we're using multiple microservices. At the service and
application layer can be vulnerabilities and attacks as well.
And of course, in order to make everything run smoothly,
we rely on orchestration, and that requires the scheduling of various processes.
As we see from this simple slide, there can be attacks at pretty much any layer.
Therefore, we must protect and defend at every layer as well.
And one layer may lead to the compromise of another
if it's not properly protected.
Some of the common cloud vulnerabilities come because you have in a public
cloud or in many clouds multitenancy. We don't have that in a private
cloud, of course. But you have many different companies and people sharing
the same environment, the same hardware,
the same networks, and is there proper isolation between each of
those clients? Are there controls in place to make sure that one
client's data cannot be exposed to another? The other problem can be
that there's a lack of documentation,
a problem that we don't really know what's going on and where our
data is and how it's being protected, for example. There can be
insecure application program interfaces.
There's been many cases of these that a person has used an API
between a cloud‑based application and a legacy system, and that
API was using old forms of encryption.
It was insecure and riddled and full of holes.
And of course, there's the vulnerability of network‑based
attacks, everything from something as simple as a physical attack
of a cut cable to, of course, the tapping or interception of our
network communications as well.
So in order to help us recognize the threats,
there's been a couple of different models developed, for example,
STRIDE. STRIDE stands for spoofing or person masquerading as
another person or legitimate user, tampering affecting the
integrity of the data or its process. Repudiation.
I didn't do that.
You can't prove that I was the one that ordered that
product. Information disclosure,
a breach of confidentiality and data that should not have been released to an
unauthorized person. Denial of service where a person cannot use their systems
because they're blocked from gaining access, whether it's through some type of
flooding attack or even ransomware.
And a big problem, of course, is escalation of privilege,
a person's privileges and access control is not managed correctly, and they
can gain a higher level of access than they should have.
So that altogether makes the threat model of STRIDE, and these are
some of the things that we have to examine to make sure do we have
vulnerabilities in any of these areas?
Another type of threat model is known as DREAD. DREAD stands for what
type of damage would occur if there was a breach?
How easy would it be for somebody else to reproduce or create that attack?
How easy is it to exploit?
Can people easily using simple tools and techniques gain access?
Who would be affected as the users if there was a breach? And of course, is
the breach well known and is it discoverability we could say. So DREAD is
also a way to rank the seriousness of various types of possible breaches.
Another tool that can be used is PASTA.
PASTA stands for the Process for Attack Simulation and Threat Analysis. And what
it does is defines what are the objectives, in other words,
what are we trying to protect?
What is the technical scope or specifications?
And then we break the application down through a process of decomposition.
So we say,
where could we actually launch the attack, and what threats
apply to this part of the application?
We analyze those threats. We identify the various vulnerabilities, and of
course, we look at the types of attacks that could actually happen. From this,
we can determine what is the associated risk associated with this threat and
vulnerability, and from that, the level of impact should there be a breach.
Another tool is ATASM, and that is where we look at what are the problems or
the vulnerabilities associated with the architecture? Am I running my
application in an insecure environment on insecure hardware without proper
isolation or protection?
What are the threats?
What are the attack surfaces?
Can I get in through user input,
administrator input, through the database? And of course, from that,
how can I mitigate or then address those various types of threats as
well? There are a number of different ways that we can find support
for writing good applications,
good methodologies, and certainly good practices we can follow. From
the payment card industry, we've talked before about the Payment Card
Industry Data Security Standard, but they also have a whole set of
standards for payment applications,
the Payment Application Data Security Standard.
And this especially applies to building security into
applications that would be shared with multiple users.
We have the OWASP Top 10, listing for us what are the greatest
vulnerabilities, and of course, the things we should watch for
and test for in any application.
We also have the ASVS,
the Application Security Verification Standard, which helps us to make
sure that we verify that we truly have secure code, and a very good
set of standards is, of course, SAFECode,
which helps us to ensure that we actually are following good
practices in developing secure applications.
One of the things that's been very helpful is the communication provided for
us through things like the Common Weakness Enumeration Top 25. It lists for
us what are the most dangerous software weaknesses? And it is very much
linked to a couple of other good communications as well such as the Common
Vulnerability Scoring System,
the National Vulnerability Database, and the Common Vulnerability and Exposure.
We also have from CISA a lot of good information and communication,
the Cybersecurity and Infrastructure Agency that helps us to
ensure that we are all aware of what are the risks we should look
for related to application security.