In this episode,
we're going to talk about secure software development and the
framework that needs to be utilized in the process.
Uh This specific episode deals with the software development life cycle.
You have to remember as you're going through CYS A,
you don't need to be an expert at this.
But you can expect questions that detail specifically about in what phase
we may involve security or what phase we may start the maintenance.
These are the type of questions you should be prepared to answer.
You don't need to answer specific questions about programming
or how the programming interacts with other adjacent performance.
But you do need to have a basic understanding of the
life cycle in general and that's what we're addressing today.
The software development life cycle or SDLC
is a framework that we utilize to go from the inception of new software.
Ie what kind of software are we going to build?
What are we trying to accomplish with this software
all the way to the maintenance and support stage,
which is software is already being utilized, it's already been implemented.
But we need to be aware of the different
flaws and vulnerabilities that may come with newer technology.
How are we supporting the software as these new technologies evolve?
This is a software development life cycle that you need to be familiar with
within the requirements and design stage.
We're specifically looking at two very different aspects functional
meaning where am I getting my data from?
Am I getting to limitary data? Am I getting temperature sensor data?
What kind of functional data am I dealing with?
It also has to deal with nonfunctional data.
What am I doing with that data when I got it,
how is my software interacting with temperatures below two
°C? And how am I acting with degrees at you know, 90
°C which is, you know, basically burning the world on fire, right.
So what are those two aspects?
And how are we going to design or how
are we going to implement the software with functional
and nonfunctional parameters?
We're also going to look at the requirements gathering within the SDL steps.
When we talk about requirements gathering,
we're talking about how am I utilizing this software?
What are the basic requirements that we need hands down
oftentimes within software development?
We'll start out with this general idea of I wanna build this program
again. Let's talk about calculator. My favorite analogy, right?
So in a requirement stage, we could say I need a program that does multiplication,
division, subtraction and addition, no more, no less.
That's what I need it to do.
That's the requirements of the program that I'm building.
However, it's not uncommon for later on in the program to add added features.
Now, I need to do powers. I need to be able to go, hey, what's 10 to the power of three?
That's an additional step in the software development life
cycle that we need to be aware of.
But it's not in the initial requirement stage or the gathering stage.
However, not uncommon,
we need to analyze and plan what we're
trying to accomplish throughout this entire thing.
What is our plan for the software to uh encom,
am I only using it as a calculator or is
the calculator part of a bigger program that's being developed?
It's not uncommon to work on one part of
a project while another team is programming another part.
So in our space with a calculator,
maybe that calculator is designed to do
more than just basic calculations and we need
to be able to and prepared based on the wider project that we're building.
Finally, security and performance architecture.
We've talked about how security needs to be built in from the onset,
it needs to go through and have security front and center on its mind
if I don't build security into our program, right at the beginning stages,
when we're talking about it, when we're designing it straight from the ground up,
my cost could go easily double isn't sometimes triple
if we try to implement security after the fact,
not only that but doing security after the fact also leads to more vulnerabilities.
You're never going to be 100% secure.
Could you imagine 300,000 lines of coding and having to go through
line by line trying to figure out where to put security in.
Isn't it better just to do security from the onset
and just have it written in right at the get go
again. Security performance architecture needs to be involved right.
At the beginning of your planning stage.
During the deployment stage,
we're going to move to develop software into a production environment.
We want to be careful that we don't deploy it all at once. We want to go step by step.
Start small. Let's see how the system interacts.
So the software interacts with a single production environment.
Let's test it again.
Let's further make sure that there's no flaws or vulnerabilities,
any errors that may erupt in this production environment
as we fix those different flaws in the production environment,
then we can roll it out to more production environments.
And the list goes on.
We're continuing to test the software as
it's being deployed throughout our frameworks.
During the maintenance phase.
We're going to provide support and life cycle
adjustments to our software in a production environment.
Our sales people are doing their job, they're selling the software, making it work,
they're making our company money.
Now, we need to support it.
There's going to be specific iterations of that software that
are going to be independent from one iteration to another.
That means if I'm at a Lego factory,
it's probably going to be different than a Couch factory.
Even the software may be utilized in the same manner.
There's probably idiosyncrasies we need to be aware of and
we need to support and manage that software accordingly.
We need to ensure that the software remains operational.
You'll see uh companies and organizations like Microsoft
that comes out with a patch every other
week when it comes out identifying different flaws
or vulnerabilities associated with their specific software.
In this case,
we need to maintain the software and ensure that if
a flaw comes out or an error is detected,
that we quickly respond to it and provide patches to it accordingly.
During this phase.
We're ensuring the operational,
reliable and efficient use of the software throughout its life cycle.