When we look at system development methodologies,
there's many that have been used and proposed over the years.
I've used the one here from the ISO 15288 standard just so it's an
internationally recognized standard though, of course, there are many other good
ones that are put out by NIST and other organizations as well.
The idea is that an application goes through a lifecycle, and the
stages of that start with when it's an idea or concept,
then the development of the application,
the then production of that, the utilization or use of the application,
the ongoing support and maintenance until the day it's finally retired.
The idea during the concept phase is that we look at
what is the application going to do?
The primary purpose of an application is to support a business function.
And in other words,
we need to define what will this system actually do for the
organization? This is where we see the term used problem space.
In other words,
let's really define the problem that this application is designed to
fix. Too often, we see that people start working on a solution before
they've really initially defined the problem.
The problem space is a business requirement, and we don't
come in here with a technical solution yet.
We simply understand what that business requirement is.
We need to then move on to security. Since we have a
problem that we are going to solve,
what are the security requirements that are going to
be required in this application?
And those security requirements will be based on the data that's being
processed by the application. Is this very sensitive data such as
intellectual property or personally identifiable information?
Is it financial data,
investigative data? Is the main concern with this application integrity,
confidentiality or availability? And all of those could be
equally important, or it could be that this application has
more of a focus on one than the others.
The idea, of course,
for us is that we need to gather the requirements. And a very good
document on this is from NIST, the SP800‑160.
It says that gathering the requirements is to talk to all of
the various stakeholders, and that, of course, includes the
various users of the system, the managers,
the business so that we understand what are the assets or what is
the value that this application will process?
What is the true mission or business need?
What are the security objectives?
What is the concept of operations?
How will this application work? And are there any laws,
regulations or policies that would apply to this application?
And of course,
what are the organizational constraints such as does this system have to
integrate with older legacy systems or legacy data?
Then we need to look at the system itself.
What are the system assets,
the architecture, design, and how will the system be protected? In other words,
the communications, the actual hardware,
the endpoint devices that are going to be used so that we have a secure
infrastructure to support the various business stakeholders.
And then we have to look at how will we get this all to
work together? The trade perspective,
looking at what is the way to engineer the system of business processes,
the requirements,
the risk treatment? And of course, through all of this we have
determined the protection needs. This used to be called the protection
needs elicitation, and I really like that because in many cases what we
need to do is elicit or draw out from all of these various entities
what the protection needs are.
And in many cases, why do we need to draw it out? Because they don't
know themselves what those security needs are.
So in the end, we have the outcome of how we will
then meet security requirements,
both, of course, to support the business function,
the non‑functional requirements, reporting,
for example, and logging, for example,
and the assurance to make sure that things are working correctly,
balancing, and of course, to make sure that we comply with our security
policy. And that, of course, is based on the organizational policy, but
maybe individual policies for this system as well.
During the development phase,
we know that development could be done by a number of different teams.
There could be some people working on the database calls,
other people working on the front end, other people working in some of
the supporting systems and middleware, for example.
Now, all of these various teams could be a part of the cloud consumer, or
it could, of course, be something managed even by the cloud service
provider, either through internal or external teams.
One of the things we discussed earlier is that we should follow good coding
and, of course, good documentation standards. That makes sure that the system
will run smoothly and can be maintained as well.
Good project management is important to ensure that we have
the right resources working efficiently and, of course, that
we stay on schedule and on budget.
One of the things we need to do is build in just as we do,
for example,
with a car engine, inspection ports. We have to have a way to check
the oil. We have to have a way to check the radiator fluid, and we
need to do the same with our applications.
We build in the ability to test and audit the system.
Of course,
we know that developments, especially in today's world of Agile and DevOps,
for example,
can be very dynamic. What we started out with might not be at all what we
finished with. That means we have to build in flexibility in order to meet
changing requirements and maybe even, of course, changing technologies. The idea
of Agile is to break things into manageable pieces and, of course, to be able to
create a team where we have developers,
architects, and business representatives all working together to try to
speed up the delivery of a working viable product.
We know, of course, that there's been a lot of talk about development operations
and, of course, development security operations, DevOps and DevSecOps. The
problem with all of these is that they work very well,
but the problem is that for most organizations, they don't work very
well. They don't have the maturity or the structure to make these
work. They might call themselves agile,
but they've never read the Agile Manifesto, and they're not
really following good agile practices at all.
So, as security professionals,
we need to help build in these standards, of course. An important part of
what we're doing is trying to create a quality product,
one that will work reliably to do what it should do,
and this is where quality assurance is a very important part.
Now,
this is something that often gets kind of overlooked in a poorly run
implementation of Agile or DevOps. But we should have a pipeline, a
CI/CD pipeline where we can continuously be working on development
and integration of our products,
but everything should go through the pipeline to make sure it's
properly tested and to ensure the integrity of a system that's
going to go into production. It's important that all changes are
tested. And even when we're dealing with Agile. and there's
companies that do Agile very, very well,
they can make hundreds of changes per day to their systems,
but every single one of them will go through that proper pipeline to ensure
they're following good change management and ensuring integrity of the
delivered product. When something goes into production,
then we have to make sure it remains secure. We might find vulnerabilities that
require patching, and then we need to deploy a patch that will work and make
sure that gets rolled out to all the implementations.
We want to have proper version control so we know what is the
latest version that's running and, of course, to try and ensure
we don't overwrite earlier changes.
We want to make sure the logs are enabled and, of course, reviewed.
I remember one time that we looked at a log that all of a sudden
we found. There was a report that was being generated by an
application no one had looked at in years.
And here it had some important information that we should
have looked at and paid attention to.
And of course, an important part is that the users might think of a better way
to do things. They might be having a problem, and we have to build into our
applications the ability to address those user issues.
So here we've looked at a lot of things about building secure systems.
Let's do a quick key points review.
The thing is,
the cloud provides unique security challenges to
application development operation.
Now, it also provides very great benefits.
But since I'm working with a third party,
it can be more difficult to have hands‑on control
over things such as the network,
the hardware, and so on. As a security professional, our goal
is to integrate into the development process so we can ensure
that security was thought about,
designed, and, of course, then implemented and
maintained in those cloud‑based applications.