Development Methodologies

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
5 hours 58 minutes
Difficulty
Intermediate
CEU/CPE
6
Video Transcription
00:00
>> Welcome back to Cybrary's ISEEP course.
00:00
I'm your instructor, Brent roads.
00:00
Let's jump into development methodologies.
00:00
In this video, we're going to look at
00:00
development methodologies and we're going to look
00:00
at the common security tests that you do
00:00
regardless of the development methodology used.
00:00
The first development methodology
00:00
we're going to talk about here
00:00
created in the 1970's is waterfall.
00:00
Waterfall is very much like its namesake.
00:00
It's a cascade of activities or a flow of
00:00
activities that you do
00:00
throughout the course of a development.
00:00
You start with your system requirements
00:00
and if you do everything right,
00:00
you end up with a system in operations.
00:00
This is a very rigid methodology,
00:00
not a lot of flexibility here.
00:00
What does that mean? That means if you
00:00
create a requirement and system
00:00
requirements and it captures
00:00
what the customer needs incorrectly.
00:00
Once you get to the end and operations,
00:00
you may never validate
00:00
that actual system because you built it incorrect.
00:00
Because of the rigidity of
00:00
the waterfall model you can see it,
00:00
there's very few places where you can go actually
00:00
back and change or fix something along the way.
00:00
That is one of the downfalls of this model.
00:00
The next model we're going to talk about is
00:00
the systems engineering V. It was developed in the 1980s.
00:00
The idea here was to get a system into
00:00
operations and maintenance from
00:00
the beginning of a concept of operations.
00:00
You've probably seen and heard
00:00
those terms previously and what we've
00:00
talked about and do verification and validation.
00:00
This is also a very linear type project,
00:00
a project methodology or development methodology.
00:00
When you get from concept
00:00
of operations into implementation,
00:00
you don't have a lot of
00:00
flexibility to make changes along the way.
00:00
Although, because you see the arrow there,
00:00
when we're looking at requirements architecture
00:00
and you're doing that verification and validation,
00:00
you might actually stop
00:00
the development here and go back and fix something.
00:00
Obviously, that's very expensive
00:00
from a cost perspective,
00:00
but at least you can do
00:00
it whereas in waterfall you couldn't.
00:00
The third methodology we're going to
00:00
talk about is spiral.
00:00
Spiral introduced a construct
00:00
here on the 1990s of prototyping.
00:00
The idea here was, instead of
00:00
what we see with the system engineering V and waterfall,
00:00
we actually now develop
00:00
test capabilities that we try
00:00
out before we actually put them into operations.
00:00
This was a novel approach.
00:00
This allowed us to actually go through
00:00
an iterative process and look at the risk along
00:00
the way with different prototypes
00:00
as opposed to trying to do that
00:00
all at the end when we were doing testing and
00:00
say the systems engineering V or waterfall.
00:00
So a much more flexible process,
00:00
but still somewhat linear and
00:00
execution but better [NOISE].
00:00
The fourth methodology is
00:00
scaled agile or scaled agile framework.
00:00
This is a methodology that is used to develop
00:00
very complex systems and actually
00:00
develop them in a shorter timeframe.
00:00
The idea here, pulling in the idea of
00:00
the prototyping from spiral,
00:00
agile development operates in
00:00
2-3 weeks spins or activity cycles,
00:00
where capability is created and put into
00:00
the hands of the user for checking, testing, and use.
00:00
This is very different and unique
00:00
to scale down and to the agile methodology.
00:00
Here, we actually integrate the users as
00:00
product owners to actually help
00:00
influence how we develop the system.
00:00
This is a very flexible methodology.
00:00
It is not just used for
00:00
systems engineering software entering
00:00
that engineering and that kind of thing.
00:00
The agile methodology, it
00:00
can be applied to different
00:00
industry verticals, which is unique.
00:00
It is very complex and
00:00
it requires a lot of training to execute correctly.
00:00
What we see a lot of the times
00:00
is organizations say they're agile,
00:00
but they're actually doing
00:00
waterfall and slapping some agile stuff into it.
00:00
You have to be really careful and
00:00
understand that these methodologies aren't
00:00
necessarily always what they seem
00:00
sometimes they're applied incorrectly.
00:00
If you were to do true agile,
00:00
you would be very
00:00
flexible in your development and potentially much
00:00
faster than the other methodologies
00:00
we talked about previously.
00:00
As in EC, there are
00:00
things that you are going to do no matter
00:00
which methodology is chosen
00:00
for the organization you support.
00:00
You're going to do risk assessments.
00:00
That's a given. You have to be able to
00:00
understand the risks of the systems being developed.
00:00
You're going to help the security folks
00:00
conduct vulnerability assessment.
00:00
You're going to look at could
00:00
a system be exploited based on the way it's designed.
00:00
Audit and compliance.
00:00
Obviously, if there's regulations,
00:00
laws that thing is ECs,
00:00
that is our job to figure out.
00:00
One of my favorite things to do as
00:00
an EC is the trade studies,
00:00
where we're going to talk about trade studies in detail.
00:00
You have a good idea what it is,
00:00
but that's where we look at the ability of
00:00
technical and non-technical solutions to solve problems,
00:00
I will tell you as an EC sometimes
00:00
we have to come back and say, "You know what?
00:00
That really great piece of technology
00:00
isn't the best way to solve the problem.
00:00
We can simply solve that with a process or a policy or,
00:00
or something in the non-technical realm."
00:00
One of the other things we do as ECs is we help to
00:00
write the testing requirements
00:00
for these very complex systems.
00:00
That is truly systems engineering work.
00:00
In fact, in my experience as
00:00
a systems engineer over the years,
00:00
I will tell you that I have written
00:00
a lot of tests requirements,
00:00
whether it's for the systems I
00:00
was helping to develop or somebody else was
00:00
developing so that they could be tested accurately
00:00
and fully to ensure that they were
00:00
going to operate securely.
00:00
In this lesson, we covered development methodologies.
00:00
We're going to circle back and see those again.
00:00
I guarantee you if you're studying
00:00
for ISEEP those are important things to know.
00:00
Then we talked about the common security tasks
00:00
that an EC does in
00:00
support of development methodologies.
00:00
We'll see you next time.
Up Next