Software Development Lifecycle
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
15 hours 43 minutes
Difficulty
Advanced
Video Transcription
00:00
>> Now, we would be totally remiss in talking about
00:00
software development without talking
00:00
about the software development life cycle.
00:00
You'll hear different organizations put out
00:00
stages of the software development life cycle.
00:00
We're going to go with the one from
00:00
NUS because that's pretty straightforward.
00:00
We're going to look at the SDLC.
00:00
What's important about the SDLC is for each step,
00:00
each phase, we implement security and we consider risks.
00:00
What are those phases, you ask?
00:00
Well, I'm glad you asked.
00:00
We start out with planning and requirements.
00:00
Of course, we start out getting the requirements because
00:00
here's where we're doing our feasibility study
00:00
to just even determine,
00:00
can I build this software at all?
00:00
We start looking at risks immediately,
00:00
we develop a business case for the software,
00:00
we determine, this is going to
00:00
meet the goals of our organization.
00:00
We can do this, we can do it well.
00:00
Here are the requirements
00:00
that are defined at an upper level.
00:00
Basically, those requirements are going to be traced
00:00
directly to stake holders based on needs that they have.
00:00
Again, based on the requirements,
00:00
we identify risks associated with the requirements.
00:00
Now, we analyze those requirements.
00:00
What we're going to do is we're going to
00:00
fine tune the requirements,
00:00
and make sure that we're really not
00:00
just satisfying what the customer asked for,
00:00
but what the customer needs.
00:00
With requirements, when you
00:00
look at the failure of most projects,
00:00
you can almost always go back
00:00
to an issue with requirements.
00:00
Maybe there was a misunderstanding of
00:00
the requirements, it wasn't well-defined.
00:00
Maybe the requirements were more
00:00
difficult than we originally considered,
00:00
whatever that may be.
00:00
But one of the things we have to do when we
00:00
take requirements from customers is
00:00
we have to make sure that customers are
00:00
providing us with the problem that they need solved.
00:00
We can't have the customer come to us and say hey,
00:00
I want to move to the Cloud.
00:00
We can do that, and I can say,
00:00
give me a check and then move
00:00
all their resources to the Cloud.
00:00
The problem is what if
00:00
that customers main goal was security?
00:00
Well, I don't know that I've accomplished the security,
00:00
I don't know that I've accomplished the need of
00:00
the customer by moving them to the Cloud,
00:00
I can think of a million ways to increase
00:00
security better than just
00:00
migrating everything to the Cloud.
00:00
When the customer gives us the solution,
00:00
sometimes the customer's wrong, we're the experts.
00:00
We want the customer to define the problem.
00:00
We are not secure enough to be in
00:00
compliance with HIPAA standards, that's their problem.
00:00
Then it's up to us
00:00
to figure out how to solve the problem.
00:00
We're the organization they came to,
00:00
we're the company that they've
00:00
hired to develop the software.
00:00
They gave us the problems,
00:00
we figure out the solution,
00:00
and then we design the solution for them.
00:00
I always think of it like
00:00
I know less than nothing about cars,
00:00
I don't know a thing about cars, don't care to.
00:00
Kelly, would you like me to show you the?
00:00
Nope. Well, how about if we look at the engine?
00:00
Nope. Not interested.
00:00
I don't go to the mechanic and say hey,
00:00
I need you to replace my thermal flux capacitor.
00:00
Because if he can find my thermal flux capacitor,
00:00
he might replace it.
00:00
But darn if my car isn't still knocking.
00:00
That was my problem.
00:00
I've got a knocking in the engine.
00:00
I thought I knew what the problem was,
00:00
I went to him and said replace this,
00:00
he replaced it but then didn't fix the problem.
00:00
When we're trying to get good requirements,
00:00
the customer gives us the problem,
00:00
we provide the solution.
00:00
That's in the analyzing and defining stage.
00:00
Then we design out that solution of how it should work.
00:00
[NOISE] We develop it,
00:00
which means we do the actual coding
00:00
into the application at that stage,
00:00
then of course we have to test it.
00:00
Now, in the testing phase,
00:00
the code is determined to
00:00
either meet its objectives or not.
00:00
Is it well-written?
00:00
Does it have structure and logic?
00:00
At the end of this process
00:00
the software ideally would be certified.
00:00
Certification means that
00:00
the technical specifications are met.
00:00
Usually that's based on the security of the software.
00:00
It performs securely in
00:00
this environment, it gets certified.
00:00
Then it's passed along to senior leadership,
00:00
senior management to authorize the product.
00:00
We take the fact that it's been certified,
00:00
it meets our real-world need,
00:00
we're going to authorize
00:00
this product to move into production.
00:00
Now, if either certification or
00:00
authorization is unobtained,
00:00
we often get a document called the POAM,
00:00
a plan of action and milestones.
00:00
I drew a blank there for a second,
00:00
plan of action and milestones.
00:00
Basically that's the document that tells us,
00:00
we had some problems in the code,
00:00
it didn't meet its vulnerability assessment
00:00
or didn't pass pen test,
00:00
here's what we need to
00:00
change and here's how we're going to approach it.
00:00
Ideally at the end of testing
00:00
we would get certified and accredited.
00:00
But if not we get a POAM
00:00
and we go back to the drawing board.
00:00
After we are certified and authorized though,
00:00
we're going to implement the software,
00:00
we're going to put it out into production,
00:00
and we're going to continue to monitor it.
00:00
These are the stages of
00:00
the software development life cycle.
00:00
What we have to do is make sure
00:00
that each step along the way,
00:00
we incorporate risk management and security.
00:00
We have to start with secure requirements,
00:00
we have to start
00:00
with making sure that our analysis is correct,
00:00
that we understand what the requirements are,
00:00
we implement after secure testing,
00:00
and we follow the processes of the secure life cycle.
00:00
That just wraps up talking about
00:00
the software development life cycle,
00:00
making sure that we incorporate security
00:00
>> into each stage.
Up Next
Instructed By
Similar Content
