Welcome to the Cloud Application Security for the CCSP domain.
This first course is going to take a look at cloud
application development security.
This is the fourth domain of the CCSP certification examination
outline. We've already taken a look at cloud concepts,
architecture, and design, cloud data security, and we put
the platform together and infrastructure that our
applications are going to run on.
So now let's build those applications before we look at
operations and then legal risk and compliance.
This domain is worth 17% of the examination.
We divided this domain into two parts, cloud application development
security and cloud application security testing.
We'll start by looking at cloud application development security.
An application is the portal, the entrance,
the gateway, and it's through an application that people can get access
to our data and systems, and therefore, it is at the application that we
must begin to deploy security mechanisms.
We can see that one of the problems is that many applications are
built with a primary focus on function and that security was not
included in the actual application requirements.
And in part, this can be because security can impact
the performance of the application.
So there's a hesitation to want to include security into the application and
maybe slow down the development and even slow down operations.
Today,
many of our applications are built from many pieces. We are
going to take a look at microservices, as compared to the old
monolithic architecture, for example. And when we have many
pieces that must join together, there's always that increased,
we could say, attack vectors.
There's an increased chance that there could be weakness
in one that could affect the others.
The other thing is that when developers receive training,
they receive training on how to write code out of slang code,
but very rarely did they receive sufficient
training in how to write secure code.
And therefore, it can be that the developers don't even know what needed to
be built into the application in order to make it secure.
There's also the problem of we're always late.
There can be a push to get the application into production, and we'll
do some of this other stuff later, and that can very definitely impact
quality and security of the application.
When we look at cloud applications, we bring in even more complexity.
Not all systems that work well in a private type of
environment can just be put onto a cloud platform.
We sometimes say they can't just be fork lifted onto the cloud.
There can be some types of applications dealing especially with real‑life
systems that must respond very quickly that really should probably not be
considered for a cloud‑based implementation.
Now,
the cloud service provider, in many cases, is probably more
secure than the majority of companies out there.
But there's always that fear, is the cloud security provider really paying
attention to the security concerns we have? And of course,
one of the things that makes this all so difficult is we have years and
decades worth of old legacy systems that were never built to be secure, and
yet here they are operating now with an interface to a modern system that's
accessible from anywhere in the world.
We also have so many different types of devices
that connect, different browsers, different types of Internet of Things devices,
different types of phones, and all of these provide the
complexity that not all of them are the same as far as a
security configuration goes.
The cloud is one more element of our architecture and
therefore increases the attack surface that could be used
to attack the applications as well.
So we need to train. One of the most important things we, as cloud
security professionals, need to do is to ensure that the people that
are writing the applications are aware of what the threats and, of
course, the solutions are.
We should encourage that everyone recognizes that security is not an option.
It's an essential part of the function of the system.
The system must be built to operate in a secure manner. And we can see here
that security and functionality are things that work better together, so the
function can work reliably to support business needs. Another problem, of
course, is problems like regression and where we reintroduce problems that
we already fixed earlier.
We need good version control to try and prevent that
type of overwriting of previous fixes.
We have to encourage that developers realize there's no
such thing as self‑documenting code.
Now, documentation is not an option.
It's something that needs to be done.
And, of course,
whenever we make a change, that must be tested. We can't just say,
well, that was a small change, so we can just put it into production.
It could be that we've made a mistake that could lead to a
gaping hole or vulnerability in our application.
So, we must encourage the use of standards, standards in how we code
and sometimes even the languages and commands we use.
We must have standards and documentation in how we document to make sure that
things are documented properly so we can maintain the programs in the future.
We should have standard test banks that we can use and test scripts to make
sure that all programs are properly tested.
Nothing should go into production without having gone through a thorough test.
And of course, we must manage change.
We see that in many cases, the application worked well at first,
but changes were made that perhaps eroded some of that security.