Let's continue looking at Cloud Application Security for CCSP by
looking at cloud application security testing.
We divided this course into two parts.
We looked at cloud application development security, now we'll look at
cloud application security testing from the perspective of how do we test
thoroughly to ensure we have a good product that goes into production? We
can say that it's testing very often that fails because we didn't test for
all of the possible conditions that this application could be subject to in
the real world.
The purpose of testing, and I remember when I was learning coding,
the professor said to us, he says,
remember the purpose of testing us not to see if the program works. It's
to see if the program will fail because that is what your users are going
to do to you. By testing thoroughly, hopefully we can find the things
that would cause a program to fail so we can prevent the release of bad
software into production.
Our goal is to find any flaws,
bugs or weaknesses that are in the software. Flaws and bugs, of course,
could be either something, which is a semantic or syntactical type of problem,
semantic being looking at the flow or logic of the program as
compared to an error such as a buffer overflow, an incorrectly
defined field, and that type of a problem as well.
Certainly, we do want to make sure the application works as it was
intended, the business function that required the application has
been met, and that is, of course, the ultimate goal of an
application, to support a business function.
There are two things we look at, verification and
validation. Verification is the assurance and the testing
to ensure that the software works.
It does what it was supposed to do. All of the functionality is there.
It's one of the things we always have to do at the beginning of
any test of an application, and that is make sure that everything
that the program was supposed to do, it does. It could well be the
program works perfectly, but doesn't do some of the things it was supposed to do.
The developer did not deliver a complete program or a complete solution.
So therefore, the first thing we need to do is check that the as
built is actually similar to the as designed.
So, we ensure that the software is working and that all of the
functionality that was in that design has been provided now in the
deliverable. Validation is the next step.
That is to ensure that what we did was actually the
right solution for the problem.
We said that a goal of gathering the requirements was to understand
the problem that this program was going to solve.
So we could have come up with a very good working program,
but just wasn't the right solution.
So the verification, yes,
it did everything that it was asked to do, but the
validation points out that, yes,
but actually we didn't come up with the right solution.
So, validation ensures that the solution we've come up with was
actually the right one to meet the business requirement.
So we go right back to the original requirement gathering.
We also have a process known as systems authorization.
This used to be called certification and
accreditation, and it's made up of two parts.
The first is the security control assessment.
We assess the security controls exactly as its name says.
And this reviews the software to make sure that there are appropriate
and adequate security controls in the software.
We don't do a security control assessment just at the end of the project.
That would be like doing a building inspection once the building was finished,
the walls were painted.
Well, we wouldn't see if there was a problem in the way the walls were built,
the electrical,
the plumbing, so we have to do inspections during the build process.
So in other words,
we review the software throughout the software development process, and
that means that we go back and look, was the risk to this software
properly identified? Do we understand the threats?
And have we then designed adequate controls to meet
those threats? Then of course,
make sure those controls were actually put in place.
Remember when you first started designing the program,
we were looking at it from a really high level, and it's only as
we got closer into writing code that we had more in depth ability
to see any problems in the code.
So therefore, risk assessment is not something we
only did once at the beginning.
But no, we reexamine to make sure that as this program is starting to be built,
that we identify any newly discovered risk, and therefore, we
have appropriate and adequate controls.
We can say that that term adequate control comes back to that
definition that an adequate control is a control that is
commensurate with the level of risk.
We have to make sure the controls that we put in place
and designed were actually working.
It could well be that we had a great plan, but in the end it didn't work.
So once we've done the security control assessment,
we make sure the controls are adequate and working.
We actually go to the systems authorization process where the
management approves the system for deployment.
This used to be known as the accreditation part of the
process. And really what it is, it's where management accepts
the risk of implementing this program.
They base that assessment of risk or acceptance of risk on the results of
the security control assessment that was provided to them.