In this episode, we're going to talk about secure software development and the framework that needs
to be utilized in the process.
This specific episode deals with the software development life cycle.
You have to remember as you're going through Cisa, you don't need to be an expert at this, but you
can expect questions that detail specifically about and what phase we may involve, security, or at
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, i.e. 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 the software is already being utilized.
It's already being 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 lifecycle 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 telemetry data?
Am I getting temperature sensor data?
What kind of functional data am I dealing with?
It also has to deal with non-functional data.
What am I doing with that data when I got it?
How is my software interacting with temperatures below two degrees Celsius?
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 non-functional 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 want to build this program again.
Let's talk about calculator.
My favorite analogy right.
So in a requirement stage we can say I need a program that does multiplication division subtraction
and addition.
No more no less.
That's what I needed 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 ten 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 encompass?
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 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 or even 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 write as 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 in 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 salespeople are doing their job.
They're selling the software, they're 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 in a Lego factory, it's probably going to be different than a couch factory, even
though 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 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.