December 8, 2025 • 45 mins
Check us out at: https://www.cisspcybertraining.com/
Get access to 360 FREE CISSP Questions: https://www.cisspcybertraining.com/offers/dzHKVcDB/checkout
Get access to my FREE CISSP Self-Study Essentials Videos: https://www.cisspcybertraining.com/offers/KzBKKouv
A single malicious insider flipped Disney menus to Wingdings and tampered with allergy labels—proof that weak offboarding and sloppy access can turn small privileges into big threats. We take that lesson and translate it into a practical roadmap for secure software: clear requirements, security controls in design, disciplined code reviews, honest UAT, and change management that prevents chaos and rollback roulette.
From there, we compare the major development models through a security lens. Waterfall shines when predictability and compliance evidence are non‑negotiable, with strong documentation and defined testing phases. Spiral brings a risk-first mindset, iterating through planning, analysis, engineering, and evaluation so teams can learn early and pivot with purpose. Agile and DevSecOps embed security into user stories, definition of done, and sprint reviews, using short cycles, prioritized backlogs, and continuous testing to catch vulnerabilities before they calcify into technical debt.
We also put structure around improvement. The Capability Maturity Model shows how to move from ad hoc heroics to standardized, measurable, and optimized practices that satisfy auditors and reduce incidents. The IDEAL model guides change itself—initiate with sponsorship, diagnose gaps, establish plans and metrics, act through implementation and training, and learn via feedback and retrospectives—so security improvements stick. Throughout, we share practical tips: how to weigh security controls against usability, why executive support unlocks real progress, and how to choose the right lifecycle for your risk, regulation, and release cadence.
If you’re preparing for the CISSP or leading teams that ship software, this is your playbook for building security into every step without slowing down what matters. Enjoyed the conversation? Subscribe, share with a teammate, and leave a review with your biggest SDLC win—or your most painful lesson.
Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.
Join now and start your journey toward CISSP mastery today!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (00:00):
Welcome to the CISSP Cyber Training Podcast, where we
provide you the training andtools you need to pass the CISSP
exam the first time.
Hi, my name is Sean Gerber, andI'm your host for this
action-packed informativepodcast.
Join me each week as I providethe information you need to pass
the CISSP exam and grow yourcybersecurity knowledge.
(00:21):
Alright, let's get started.
SPEAKER_01 (00:25):
Hey, I'm Sean Gerber with CISSP Cyber Training and
hope you all are having abeautifully blessed day today.
Today is an amazing day.
Yes, we are going to be gettinginto domain eight, and we're
going to be delving deep intothe overall development
methodologies that areassociated in domain eight.
And this comes down to youragile, your waterfall, your
spiral, and so forth.
So, yes, hang on, put yourseatbelt on.
(00:48):
It's going to be an amazingride.
Way more than I could everimagine.
Yeah, make sure your seatbelt ison because you're probably
driving into work.
But that being aside, before weget started, real quick, there
is an article in Wired magazinefrom a Matt Burgess and a Lily
Hay Newman.
And they they talk about acouple different aspects, but
there was one aspect in herethat I thought I just wanted to
(01:10):
bring to your attention.
And the reason is because, asmany of you are listening to
this podcast, you probably comefrom an IT background.
Well, obviously, if you'resitting for the C the CISSP, you
have some level of IT so thatyou can get the prerequisites to
get the exam or thecertification.
But there was uh an article inhere about an individual who
changed the menus at DisneyWorld.
(01:33):
And the point of it came into islike, well, you're like, okay,
so what?
Right?
He changed the menu.
Well, he changed the menu, andhe the reason he did this was
because, well, he wanted parts,he was fired from the company,
but he still had access to thepasswords.
Well, I would have wonder isokay, what else did he have
access to, right?
So he had access to thepasswords, and before he left,
(01:54):
he ended up changing them to theWingdings font, which basically
isn't completely consisted ofsymbols.
So the menus went all tosymbols, and that caused all
kinds of chaos and pandemoniumbecause people could not get
their nachos and cheese withMickey Mouse, right?
So that's a terrible thing tohappen.
But that the point of it is thefact that if you have
(02:14):
individuals within yourorganization, you should, if you
don't already, and that's justpart of the CISP, we bring this
up, is have a great exitstrategy so that when the person
is leaving your organization,they are actually, instead of
just in case of just walked out,their credentials are terminated
and ended at the same time.
Because you know what?
You don't know what they can doafter they leave the
(02:35):
organization, especially ifthey're in IT and they have the
ability to remote back into yourorganization.
So it's interesting how thishappened.
But the federal complaint thatthey set out there was that he
had changed the menu listing sayuh to say that foods with
peanuts in them were safe forpeople with allergies, which
that could have been really bad,right?
Somebody takes that underadvisement and then they end up
(02:58):
eating it and getting very, verysick, or potentially even dying
in some cases.
So that is a huge deal.
Uh, he locked 14 employees outof their accounts trying to log
in with an automated script.
So obviously, he had some ITskills.
And so, therefore, yes, thatwould have been somebody you'd
bid on your radar and watchlist.
And then he also maintained afolder of personal information
(03:19):
about employees that turned upat one person's home.
So, again, this individual issomeone who is a malicious
insider who had plans to dosomething to the organization.
Now, the question if is he knewhow to do scripts?
Did he do a logic bomb?
Did he do any of those differentaspects to your organization
that you now have to go in anddig out, which causes lots of
(03:40):
time, lots of energy, and Iwouldn't put it past him if he's
able to do these things, couldhe have done something else like
that?
So something to consider if youhave employees that have IT
skills in your organization,right?
It's always something toconsider.
All right, so we're gonna moveinto domain eight.
So let's get into it.
Okay, domain eight, eight dotone.
(04:01):
This is how to understand andintegrate security into the
software development lifecycle.
So your SDLC.
So we're gonna get into somedifferent topics, and these are
the ones that I will tell you inmany ways kind of really caused
some consternation with folksjust because of the fact that
it's a lot to put in place, andif you don't deal in the
development world, it can be alittle bit overwhelming.
(04:22):
Okay, development methodologies.
This deals with agile,waterfall, DevOps, and
DevSecOps.
So we're gonna be dealing withthe software development
lifecycle.
Now, if you all have dealt withthe software development
lifecycle, if you have or if youhaven't, something for you to
really get good atunderstanding.
And the reason I say this isbecause in today's world, as you
see, everything has some levelof IT in it, right?
(04:45):
From development standpoints toIT connectivity, you name it,
it's in there.
And so understanding of thissoftware development lifecycle
is an important factor becauseit's highly it's highly likely
you will have developers workingwith you and for you in the
future if you do not already.
So, the one thing around theSDLC is the fact that there's
(05:05):
some key activities you need tounderstand from the conceptual
design, functional requirements,you know, what is the purpose of
it, conceptual design is as whyit's made, uh, the control
specifications, and what arethose requirements specifically
set around the controls, thedesign review, your code review,
and how you're gonna do codereview, and user acceptance
training, and then maintenanceand change management.
(05:26):
These are key activities thatyou'll hear words for.
And you UAT, I actually, when Ifirst started in the development
space and trying to understandit, I didn't quite understand
what UAT was.
But it's a really good topic,obviously.
For users have to accept this,the amount of information that's
coming to them.
They have to test it, they haveto accept it, and then from
there they decide which way theywant to go.
(05:47):
So we'll kind of walk throughthis a little bit and see,
understand how each of thesework.
So, your conceptual design, it'sagreed upon by all of your
stakeholders.
So, what is the overall designfor your development plan?
It's a high-level, clear, andsuccinct point of what you're
trying to accomplish.
The goal is not to make this toocomplicated when you're first
designing it, the conceptualaspects of it.
(06:10):
Because what will happen is whenyou work with your users and
with the stakeholders, they mayhave changes to it.
So you want to avoid making thisway more complicated than it
needs to be.
It needs to be abstract as a oran introduction of how things
are gonna happen.
So, this is like your pitchdesign.
What do you want it to do?
And then it defines your endgoal and the output of what you
want to accomplish with theoverall design itself.
(06:32):
So, what are the functionalrequirements?
There are system functionalrequirements that have to be
defined, and this is where youwould do them.
These would be how they're gonnainteroperate with other systems,
what's going to happen, how dothey communicate with each
other, how are they gonna actfor the user, and so forth.
Now, the stakeholders need to beconnected with the functionality
because they need to know howit's gonna work.
(06:53):
One thing to be considering iswhen you're talking with the
stakeholders, make sure theyunderstand what they are trying
to accomplish with this tool.
If they don't know, so I've beenhad multiple times where the
stakeholders are senior leaders,they have an idea of what they
want, but they don't trulyunderstand how they want it to
work.
Make sure that you bring insomebody else in the
conversation with you thatunderstands it a little bit more
(07:15):
granular so that they can helpconnect the senior leaders with
what the functionality is goingto be.
And then it's referring towhat's during the it's referred
to during their developmentprocess.
That's the functionalrequirements.
When you when you're developingit, you're gonna come back to
the functional piece.
What do you want it to do?
How do you want it to operate?
How do you want it to interact?
Okay, so what are the controlspecifications?
(07:36):
Now, the control specifications,these are additional steps with
functional requirements.
What do they have to havehappen?
It adds security controls to thedesign function when you're
doing the different specificcontrols that you have in place.
You want to make sure thatyou're continually bringing up
security in this conversation.
It's important, it's imperativerealistically.
One, there could be compliancerequirements and legal
(07:57):
requirements for this.
Two, it's just good businesssense that you want to do that.
Now, the one thing you have toavoid, and this can happen, is
if you have a bunch of securitypeople in the room and they're
all secure developers andthey've done it for a while,
they really know it.
And I'm not saying this is bad,I think this is good.
But if you're a stakeholder, youneed to weigh the risk of the
security controls you have inplace with what you're trying to
(08:20):
accomplish, because the securitycontrols can add extra stuff to
your overall plan, which, if itdoes, then can add challenges to
your individuals that are usingthe tool.
So you gotta weigh out the riskversus reward on this piece of
it.
Now you want to incorporateencryption where you can, where
it's appropriate, and then youwant to be proactive in
(08:40):
reevaluating during the majorrevisions.
So what that means is that asyou go back and do a revision,
you want to make sure that youstay proactive with these
controls and that you'reconstantly trying to fix them.
Now, the design review, this iswhere user interface and user
experience are designed, andthen this is where the
stakeholders will review thework and approve the overall
design.
So this is what you have a plan,you have a review, you're gonna
(09:02):
walk through it, the userinterface, how it's gonna play
out, your or the UEI, the userexperience, and how that's gonna
play out, and then you're alsogonna make sure that the
stakeholders are aligned withthe plan.
Once they're aligned with theplan, they sign off on it, then
work can begin.
Now, the code review, this waswhere the developers begin
coding.
Now you want to make sure thatyou connect with your coders on
(09:23):
this to that you have a goodplan and you have to watch them.
And I don't mean that in a badway, but I mean what'll happen
is coders will add moreinformation to it potentially
than what is necessarily needed.
So you need to make sure thatyou have all that under control.
Now, this is where the differentmethodologies come into play the
agile, the waterfall, and soforth.
These will allow updates to itas you go forward, but you need
(09:46):
to make sure that you stayconnected with how the coders
are developing your code.
And this is be a code reviewwalkthrough, and this is where
you have specific milestones setup.
You could have a code reviewwalkthrough once a week.
Uh, it could be part of yoursprint, it could be part of the,
it could be once every twoweeks.
It depends upon your overallplan and how you have it set up,
but it should have milestones inwhat you're trying to accomplish
(10:08):
from a development point ofview.
Now you have a security reviewwalkthrough of the code as well,
and this is where you would haveindividuals look at it from a
security perspective and makesure that it meets the needs
that you're trying to accomplishthat were spoiled out in the
requirements earlier set.
So, again, developers begincoding, you have a code review
walkthrough, and then yoursecurity is tied into the
overall code review.
(10:28):
User acceptance testing, this iscompleted prior to going to
production.
So prior to you pushing andmashing the big green button to
send the thing into production,you want to make sure the users
accept what they have you havecreated.
And it's imperative to do thisbecause the last thing you want
to have go out there is you sendit into production and then the
users go, uh yeah, that's notwhat I wanted.
You don't want that.
(10:49):
Have I had that happen to me?
It's very uncomfortable and it'syeah, it's not good.
So you want to make sure thatthey test it before, or they
they try it, the users try itbefore you actually put it into
production.
You're looking for any obviouserrors that you may come up
with.
You know, the button's supposedto be green, but it was blue,
right?
You want to make sure that it uhopens up the web page and the
(11:11):
fonts are not windings orthey're uh normal cabriolet,
whatever that is, you want tomake sure that they have those
obvious errors that you'retrying to fix.
You're not trying to find allthe errors in it, though.
You want the users to try tounderstand it.
Does it make sense?
Does it flow?
Does it meet their needs?
And this includes where they'retesting every little menu,
going, yep, uh-huh, yep, no, Idon't like that font color.
(11:33):
I don't like that backgroundcolor, those types of things.
Then once it's once complete,the code is then deployed to
production, and then that'swhere the fun begins.
Uh, you have your maintenanceand change management.
This will have this window herethat ensures that maintenance is
built into the planning process.
Vulnerabilities and updated codeare sent out, and then you need
(11:54):
to have a formalized changemanagement process to make
changes to your code.
It's imperative that you do thatas well.
So you gotta have the changemanagement piece.
We've talked about this a lot inthe CISSP training, that you
have to have a good formalizedchange management process.
And the reason isn't just tomake a bureaucratic challenge,
it's to follow, have coursechanges, have documented
(12:14):
changes, you know it'soccurring.
And then when things gosideways, which they always do,
you have a way to be able to goback and look at what happened
and then make modificationsbased on it.
So let's get into the differentlife cycle models.
What are these?
Okay, so we're gonna talk aboutwaterfall, spiral, agile, and
(12:34):
software capability maturitymodel, and then other it's more
of a framework, and then ideal.
Okay, so these are the oneswe're gonna get into, and these
are the ones I pull out of the CI SP Cyber Trade, or not CIP
Cyber Training book, ISC SquaredCyber Training.
Yeah, no, I can't even speak.
The ISC Squared C I SSP book.
This is where we pulled them outof there.
Yeah, there are other lifecyclemodels, but these are the ones
(12:55):
we focused on specificallybecause they're called out in
the ISC Squared book.
So the waterfall model.
So if you're able to video orsee the video on this, you'll
see how the waterfall modelworks.
And it all just kind of flewsdownhill.
That's the ultimate purpose ofit.
And so we'll get into some ofthe positives and the negatives
that roll with this model.
I've dealt with both uh withthis one and with Agile, my two
(13:16):
primary ones that I've focusedon.
Uh the spiral I've dealt with alittle bit, and a couple of the
other ones that are just ontacit kind of activities.
So this one was developed in the1970s, the waterfall model.
It's a series of iterativeactivities, okay?
And these activities arebasically seven different steps.
So you have the systemrequirements, and we'll get into
each of these here in just aminute, but and you have your
(13:38):
software requirements, you haveyour preliminary design, you
have your detailed design, youhave code and debug, you have
testing, and then you haveoperations and maintenance.
So, as you know, we just talkedabout this at the beginning.
We kind of went through the samelevel of steps, different names,
different kinds of terms, butoverall it's a very similar
process than what we justmentioned just a little while
(13:59):
ago.
So, what is the waterfall model?
What does it do?
It provides feedbacks fordefects that are found.
So the goal is that as thisthing goes through each of these
steps, the system requirements,the software requirements, it's
looking for feedback on thedefects and then it goes back up
to the next step.
And we'll kind of get into butit's like your system
requirements.
(14:19):
Okay, you move it, it's uh yougot all the requirements you
need.
Okay, now let's go into thesoftware requirements.
And then if the softwarerequirements there are errors,
it will go back, it'll step backone level.
It'll go back up to systemrequirements.
Now, if errors are discoveredlater down the fall, later down
the steps, such as in the codeand debug area, well, no, you
(14:40):
can't, there's not a whole lotyou can go back to the system
requirement.
You have to follow through withthe fall, unless it's something
that is like, oh my gosh,terribly bad that you have to go
back and fix.
But for the most part, if it's asmall design change or something
that along those lines, it hasto keep on going.
And then you'll come back andreiterate it with a with a new
(15:01):
version.
So the result is verificationand validation process you must
have in place before you move onto the next step.
So, what are some of thestrengths with your waterfall
methodology in your model?
It's predictable and you canhave control.
So the waterfied waterfallstructure does approach the
(15:21):
minimizes the unexpected changesyou may have, providing a more
foundational or more stablefoundation for enforcing
security policies and reducingyour overall risk.
It's predictable.
You have a plan, you follow theplan, and you operate with the
plan.
There's detailed documentationthat goes with this.
So with each of the waterfallprojects, they have a very clear
(15:43):
and very specific audit trail,which is very beneficial when
you're dealing with complianceand regulatory standards.
Now you'll come to find outthere are various regulatory
standards that are going torequire you, especially in the
development space, to have thataudit record in place.
So you need to have that done.
They also have defined testingphases.
These are distinct testingphases that allow for
(16:05):
comprehensive security testingto ensure your requirements are
met before it's actuallydeployed.
So you having this definedtesting phase is an important
part.
And then lastly, because wementioned earlier, change
management.
It does have a really strongchange management policies as
well once the changes arelimited, once your phase is
(16:25):
completed.
So it doesn't allow you to goback.
If you get halfway down theline, you go, oh no, I forgot my
screwdriver.
Well, that's really not anappropriate screwdriver, drinker
screwdriver as your screwdriver.
You forgot your screwdriver atthe top.
Okay, it doesn't even make anysense, but that's okay.
You forgot something reallyimportant to you.
You forgot it.
What did you do?
Oh, I want to go back to thetop.
(16:46):
You cannot.
So the change management processallows you to only go up one
more step, but it for the mostpart, you have to follow
through.
And this does help aid inreducing the likelihood of
introducing new vulnerabilitieslate in the project.
So, what are some limitations inAgile security?
It's inflexible, it does involvewith involving the various
(17:07):
security threats that are inplace.
So let's just sayhypothetically, you are
mid-flight into this waterfallmodel and you realize, oh no, we
have a big security threat.
It doesn't, it doesn't have theflexibility that you may need
for iterative improvement.
And the rigidity can delay theadoption of new security
measures or fixes if a threatpops up.
(17:27):
Now, you'll have to go backthrough the whole process if you
find something that is reallybad.
But at the end of the day, now,granted, I say this, you if you
got halfway through and you wentand realized, oh no, OMG, we
have like the worst hack ever.
Okay, yeah, you're not going tocontinue.
You you'll back it up, right?
But the ultimate goal is thatyou don't back it up for just
(17:48):
normal fixes or for securityvulnerabilities that you find
that may not, you don't reallyknow the effect of them.
You don't know what's going on.
Because to stop a waterfallsprint, lack of a better term,
in midstream is very challengingand it causes a lot of
confusion.
So you really want to follow allthe way through with this
process.
Uh the rigidity can adopt thedelay the adoptive security
(18:11):
measures or fixes, which we kindof talked about.
Now they do have limitedresponse to the change.
So waterfall does notaccommodate iterative updates,
making it challenging to respondwhen you have security
requirements or emergingthreats.
And then for long-term projects,this limitation can require
revisiting earlier phases, whichcan be costly, especially from
(18:34):
opportunity costs, or if you'rehiring contractors from an
actual capital loss cost thatcan add up.
And depending upon theleadership, they may not want to
do it, right?
Because of it, just say, forinstance, this development
process took 18 gazilliondollars, and now they're like,
hey, sir, I need to go and askfor some more money.
And they're gonna go, no, youcan't have any more money.
(18:54):
So, yes, it's one of thosethings that causes some
challenges.
And then delayed securitytesting.
Testing can only occur after theimplementation phase, which can
lead to higher costs as well ifthe vulnerability is discovered
late in the development process.
So it can add a lot of differentthings.
It does it does work very well,though.
The waterfall model works verywell, it allows you to get to a
(19:16):
point, it has milestones.
It's a really good program orproject management type of model
because it's step one, step two,step three, step four.
Step C.
I said step C, step three.
Yes, my wife gets on my case.
I can't speak most days, must behaving like mini strokes or
something.
Okay, so now we're gonna getinto waterfall versus agile and
devsec ops.
(19:36):
So the waterfall is best suitedfor project with the stable
requirements and regulatoryconstraints.
It's a one that you'll want tohave when you're dealing with it
because of the thoroughdocumentation and predefined
security checkpoints that youplace in here, and that's an
important part.
It works well in the highlyregulated industry, such as
government, healthcare, andwhere documentation and
adherence is important.
(19:58):
I'm working in the healthcareindustry right now and Oh yeah,
baby, you gotta have lots ofdocumentation.
It's to the point where you justkind of want to throw up because
it's a lot of stuff.
And you have a lot of reallygreat people working really
hard, but they don't get it veryfar very quickly because of all
the extra stuff that has tohappen.
So it causes a little bit of achallenge.
Agile and DevSecOps.
(20:18):
So now what's the differencewith them?
They're better suited forprojects where security needs to
adapt quickly to evolvingthreats and requirements.
It does allow for continuoustesting and integration, and
they're more suitable fordynamic environments where it
must be continuously tested andthe response to new
vulnerabilities are highlighted.
So that's the difference betweenit.
So you got to kind of thinkabout which way works best for
(20:38):
you depending upon theenvironment that you're trying
to get into versus um waterfallversus agile and devsychops.
Next one we're gonna be gettinginto is the spiral model.
Yes, as you look at thisdiagram, you'll see my beautiful
drawing on the right hand side.
Yes, it's very pretty.
It looks like a second graderused a crayon.
Did not turn out so well.
I didn't know how to make littlecircle thingies with PowerPoint.
(21:01):
So you get what you get.
I think you'll figure it out.
It's pretty easy.
So the point of it is it's in aniterative development cycles.
These projects pass throughmultiple phases or multiple
times, allowing for gradualrefinement of each cycle or
iteration.
This does incorporate theplanning, the risk assessments,
development, and evaluationsthat are occurring.
(21:22):
Now, risk management is animportant part of all of this,
and it's it's a significantemphasis on risk, which because
each iteration begins with anidentification, analysis, and
mitigation planning for riskspecifically.
And it focuses on this earlyidentification and resolution of
a potential critical issues.
Now, I've never really used thespiral method, I've just looked
(21:43):
at it and read the book on it.
But it makes sense how it works.
I would say it I personallyreally like the agile and devsec
ops methods in the overall plan,but it's mainly because probably
because I've worked with themand I've never really actually
dealt with the spiral model.
So some people must really likeit.
Phases of the spiral.
You have a planning, riskanalysis, engineering, and
(22:04):
evaluation.
Now the planning is helpinghelps to identify objectives, it
gather requirements, planningthe specific goals and
activities for each of thesecycles, each of the little
pinwheel cycles, it gathersthat.
Then the risk analysis assessesthe risk with the objectives for
evaluating alternatives.
And like we mentioned, thespiral method is focused
strongly on risk.
And so you'll be that's a greattime to do that.
(22:26):
It's during that second phase.
Engineering helps develop theproduct incrementally through
implementation, and this couldbe you have different types of
models and so forth built out.
And then evaluation reviews theprocess with the stakeholders
gathering feedback and decidingwhether to move to the next
cycle or adjust the prioritiesas needed.
Now there's a flexibility, andthe feedback are really
(22:47):
important with the spiral model.
This incorporates changes andfeedback at the end of each
cycle, making it adaptable tothe changing requirements or
unforeseen changes andchallenges that occur within
your network.
It's important on projects withevolving requirements and it
allows for the team to pivot oradjust as it's going around the
pinwheel on the valuations atthe end of each spiral.
(23:08):
So you basically have phase one.
You do your littlewhoop-dee-woo, and you come back
and you hit it phase two, phasethree, and so on and so forth.
And each of these times, theseiterations, you will make
modifications to it.
So again, it's very similar,right?
You just you go take a couplesteps, you then reevaluate.
Take some steps, re-evaluate.
Very similar to all of thesedifferent models, except you
(23:29):
just did, like in the waterfall,you can't re-evaluate and
reassess.
You have to go through theentire process.
This one you re-evaluate andreassess before you move on.
Now there's a prototypedevelopment that can occur in
the engineering phase.
Now, this is used to validateideas, functionality, or explore
specific risks that you'refinding.
So the the overall engineering,if you're dealing with a
(23:50):
prototype, it could just be withsome prototype of the
development that you have, yourcode that you've created.
These prototypes providetangible, testable models for
stakeholders to review, andthere would be some level of
user acceptance testing in thisand help them refine the
requirements and reduceambiguity of the earlier life
cycles, of the earlier spinsaround the pinwheel.
And that's the ultimate goal, isjust to help get that kind of
(24:12):
feedback loop from your people.
There's defined entry and exitcriteria.
Each phase with the spiraliteration will have a specific
entry and exit criteria, meaningthe objectives must be met
before moving forward.
You can't move forward unlessyou go, you've met the
objectives that you highlightedat the beginning of this
process.
Because otherwise, then youinstead of having a nice clean
pinwheel, you have a pinwheelthat looks more like my pinwheel
(24:35):
that I have on my graphic.
No, not quite that good.
It's actually pretty prettyimpressive, actually, for a guy
that's my age.
No, I my dementia came in.
Um it's got a clear criteria tohelp ensure the phase is
completed, to set the standard,managing risks at each step, and
avoiding moving forward withunresolved issues.
So that's the ultimate point isyou have defined entry and exit
(24:55):
criteria on the specific modelthat you're working on.
Now there's a cost and scheduleestimization per cycle.
This is an important part aswell, is you're gonna have to
make sure that you have properresources set aside, and you'll
need to make sure you haveestimates on the time and the
amount of money that's gonnatake for these specific reach to
reach these specific andattainable goals.
(25:16):
You have an incrementalestimation approach, allows for
more accurate planning andbudgeting as well.
And then you have a cumulativeprocess.
Each iteration builds on theprogress of the previous cycles,
leading to a development andrefinement of the overall
product itself.
And it allows you to adapt andevolve, moving closer to the
final product, even with thechanges along the way.
(25:37):
Now, the agile method, let's gointo that one.
So we were dealing with theagile method, it was developed
in the 1990s.
In 2001, there was a manifestofor agile software development.
It's a big$10 word to make yousound really smart, but it's
basically a document, right?
Manifesto.
Uh 12 key principles whenworking with this, and it does
work software is primarily themeasure of progress.
(25:59):
A working uh product that youhave at the end is usually the
measure of success when you'redealing with agile.
Well, with all these, theyreally are.
But agile tends to, you it youhave something and then you
start iterating on it.
Now there are many differentvariants of the agile
methodology.
There's Scrum, there's Agile UIUP, which is Unified Processes,
(26:20):
there's Dynamic SystemsDevelopment Model, DSDM, and
then there's Extreme ProgrammingXP, not XP, the Windows XP, but
Extreme Programming XP.
So there's different types ofagile that are available.
And we're not going to go intoall of those.
We'll focus a little bit onScrum because Scrum I've I've
worked with, but you may want tounderstand a little bit more out
of all of those just so that youunderstand how they work and
(26:42):
what's the purpose behind them.
Okay, Agile Scrum.
This is the security integrationof the Agile environment.
So you've got some differenttopics we're going to go over
when relating to the overallScrum process.
But collaboration is a keyfactor.
This allows for continuouscommunication and collaboration
between security, development,and the operations team.
It's a collaborative meeting.
(27:02):
You would have daily stand-ups,and these stand-ups you would
collaborate and talk about whatare some of the changes you need
to make.
There's security end userstories.
So, what are user stories?
It outlines the requirementsfrom the end user's perspective.
It integrates security intothese stories, into each of
these, and it helps ensuresecurity is part of the
development from the onset, suchas security acceptance criteria.
(27:25):
Then you have the definition ofdone.
Done can incorporate securitycriteria, ensuring that all the
tasks meet a specific securityrequirement before they get
marked complete.
So you have to have that donebefore you can actually move on.
If they're not, they don't meetthe criteria, then you don't
move on.
And then you may have to set upanother sprint that deals
specifically with those criteriathat were missed.
(27:48):
Now the sprints for securitytesting, basically the iterative
sprints allow for regularsecurity testing and feedback.
These should be short, theyshould be really quick, no more
than two weeks.
I ideally a week sprint would beawesome, but they kind of tend
to be about a week to two weeksin duration.
This does enable the team toidentify and resolve security
(28:09):
issues as the project progressesrather than once the development
is complete, such as in thewaterfall method.
Now you're going to deal withsome artifacts of dealing with
overall scrum.
You have backlogs, you have yourproduct backlog, sprint backlog,
and then you have the increment.
The product backlog, this iswhere things are added directly
to this backlog, ensuring theyare prioritized and addressed
(28:31):
systematically.
So what does that mean?
So that means you have differentrequirements in your product
backlog that need to be made.
Then these user stories mightinclude tasks such as threat
modeling, pen testing, codereview, all of those aspects
might be within your productbacklog that you need to occur.
And then you will just use amenu and you will pick through
those to decide based on riskand based on what you can
(28:53):
accomplish in that scrum, whatand that sprint, what you can
do, you will then call that intoit.
Now, the sprint backlog, this iswhere tasks are prioritized and
assigned to ensure they'recompleted within the sprints
framework.
So within the time frame youhave.
So you take from the backlog,you put it in the sprint
backlog, which is in this sprintwe're gonna accomplish.
So the backlog's got, let's say,50 different things you have to
(29:13):
get done.
The sprint backlog, the sprintthat you're gonna focus on, this
one week, two-week thing, is gotX amount, right?
So it's got less than theoverall gazillion that are in
the backlog.
But those are prioritized thenon which ones can you do this
sprint.
So if you can get them all done,awesome, that's great.
But if you can't, which ones arethe best prioritized?
And that's the sprint backlog.
(29:34):
Then you increment this eachincrement that delivered or
should be delivered to meet theorganization's security
requirements, such as what isthe definition of done.
This ensures that security isprogressively integrated
throughout the entiredevelopment lifecycle.
So what are some of the rolesand responsibilities of Scrum?
So you have a product owner.
This is responsible, this personis responsible for the
(29:55):
requirements, ensuring thateverything is prioritized,
security related, or userstories are put in place, and
they'll work with the securityteams to understand and
communicate the implications tothe Scrum team.
So if you're the product ownerfor the full-up development, you
will own the overall developmentplan.
If you're the product owner forsecurity, you will then make
sure security is embedded withinthe development piece.
(30:16):
You have your Scrum Master.
This person advocates for bestpractices within the Scrum team,
and they ensure that the securecoding and testing is completed.
They also help identify andremove obstacles to security
tasks, facilitating more secureenvironment.
Then you have your overalldevelopment team.
They are the ones that aredirectly responsible for the
(30:37):
secure coding practices, conductpeer reviews, perform unit
tests, and so forth.
They're the ones that do all thework and they help gain a clear
understanding of what therequirements are.
Now we'll tell you, you're gonnahave to be well invested within
the development team if you wantto incorporate your security
mechanisms into it.
It's an important part that youdo this.
You stay embedded, and in fact,you are working with them
(31:00):
closely.
So you need to be part of theoverall scrum uh that that's
going on.
Now, scrum is part of a, I thinkwhat is it?
What is that football game?
Oh, it's gosh, I can't it'srugby.
It's part of rugby.
So same kind of concept.
You're working together to tryto get the ball down the field.
Kind of like football, butdifferent.
Same but different.
Rugby, actually, football camefrom rugby, from what I
(31:21):
understand.
The American football, yeah, notsoccer.
Um, so the scrum events andsecurity enhancements.
So sprint planning, you havedifferent pieces.
You have your sprint planning.
This was an opportunity toaddress some priority security
tasks for the upcoming sprint toensure that your requirements
are ready for the plan.
And then you have your dailystand-ups.
Done these, oh, so many times.
They're great, they'rewonderful.
(31:43):
Uh, yeah, no, they're they sucka lot of time.
But no, they shouldn't.
They should be very quick, theyshould be like 15 minutes in and
out, nobody gets hurt.
That's the ultimate point ofthem.
Uh, but they are designed for todiscuss any challenges, update,
and encourage culture, and thenif there's any security blockers
that can be flagged andresolved, they'll help with the
overall process in compromisingand fixing that.
(32:05):
There's a sprint review.
This is done by your securityteams, your stakeholders, and
the developers.
They all participate to assesswhether the security standards
have been met and they have metthe deliverables.
You need to allow your securityprofessionals the ability to
give feedback and so forth.
The same with the developers.
Let them give you feedback aswell.
If they say this securitycontrol you want me to put in
place is only for an idiot, donot do it, then you need to
(32:28):
listen to them.
Do not discount what they haveto say.
At the same time, they may saythis kind of security control is
going to add all kinds of dramawith the end user.
Listen to them.
They know in many cases betterthan you do.
And so, therefore, it'simportant that you understand
that.
Uh, the software capabilitymaturity model, okay?
So the CMM or the S C M.
(32:50):
So this came from the SoftwareEngineering Institute at
Carnegie Mellon, SEI.
Uh, and yes, Carnegie Mellon,big brains, very smart people.
So, yes, they came up with somereally neat stuff.
This is the the quality of thesoftware is directly associated
with the quality of thedevelopment.
And their point is that it's aprocess improvement framework,
and this provides organizationswith a structured path to
(33:11):
improve their process, theirsoftware process, versus an ad
hoc chaotic practice tostructured, mature, and reliable
processes.
Now, everything I'm telling youhere, you guys, they're all
structured and reliable, right?
That's the ultimate goal.
You just have to figure outwhich one works best for you and
your overall company.
Now, the primary goal is toimprove the quality and
predictability and control thesoftware development process.
(33:33):
Again, ultimately leading tohigher quality software with
reduced costs and risk.
Now, the applicabilityapplicability, yeah, that big
word.
This is how this works is it'sinitially designed for software
development, right?
But it also can be applied toother areas such as systems
engineering, acquisition, andsecurity practices as well.
So it's it's very applicable.
(33:53):
See, I can't even say that word.
It's too early.
It's 5 30 in the morning.
So yes, it's quite early for me.
Moving on, what are some levelsof the CMM maturity model that
they have?
So we're gonna walk through eachof the different levels so you
understand them.
And there's different keyprocess areas or KPAs that are
associated with this.
So level one is the initial,it's the chaotic, it's the oh
(34:15):
craziness, we don't know whatwe're gonna do.
It's its processes areunpredictable, poorly
controlled, and reactive.
And its success will depend onthe individual effort rather
than an established process.
This is the beginning phases ofit.
Now, the ultimate goal of thisis to move away from the chaotic
process to an established basicprocess discipline.
So when you anytime you getsomething started, a lot of
times there is some chaotic messthat you're trying to figure
(34:37):
out.
The next level is you take it toa repeatable or managed process.
And this is where you haveproject management practices are
established.
The processes are repeatable forsimilar projects, and then they
become reactive, then they thateven though they might still be
a little bit reactive.
Now, this is where the firstsecurity controls are
introduced, and this is whereyou add security-related tasks
such as vulnerabilitymanagement, patching, and all
(34:59):
those are added to it.
Now, the KPAs on this would beit includes requirements
management, project planning,project tracking, configuration
management, and so forth.
So you go from chaotic tomanaged, and then you move into
a defined.
Okay, this is where yourprocesses are documented,
standardized, and integratedinto a unified organizational
process.
Okay, you have structure.
(35:19):
Structure, yes, proactiveapproach for developing
security.
And then the ultimate goal ofthis then is that your practices
are formally integrated intoyour development lifecycle.
And this is where their policiesand standards are created.
That's what the focus of thoseis so that in this space you now
have that ability to documentand have those policies uh
flushed and vetted out.
KPAs will focus on anorganizational-wide standards
(35:41):
and training and an integratedsoftware engineering plan.
It emphasizes a well-defineddevelopment lifecycle.
Then you have level four, yourmanaged quantitatively
controlled piece.
See, my third grade educationjust struggles with these.
It just truly does.
So the characteristics of theseare they're quantitative,
quantitatively measured andcontrolled.
(36:03):
This is where you get metrics.
Metrics are importantincorporated into this, and it
helps identify many areas forimprovement.
You have security enhancementssuch as metrics, and these are
all collected and veryproactive, manage risks.
Then you have KPAs, which dealwith quantitative project
management and processmonitoring, helping
organizations make data-drivendecisions.
That's again, that's the goal,right?
(36:23):
So now you got into managedlevel, a level four.
And then level five, the finalmelon with the levels.
This one focuses on continuousprocess improvement or KPIs,
using the feedback back from theprevious levels to refine and
enhance the process.
Okay, again, so you have thefive levels, you work through
the five levels, and then youbegin to optimize this.
(36:43):
This is where your continuoussecurity improvement is an
important factor, and this iswhere you refine the measures,
adopt the latest securityinnovations, and so forth.
Your KPAs will include changemanagement, defect prevention,
and continuous improvement.
This may be regular threatintelligence if you're dealing
with security, and then youradaptive security measures that
are built into it.
So that's how you optimize it.
(37:04):
This is the levels of the CMmaturity model based on what
Carnegie Mellum came up with.
Now, now the CMM and securityand software development, how
what are some of the benefits ofthis?
Now that's predictable and thereis control.
Again, organizations with matureprocesses, level three and
above, have a very predictableand controlled, repeatable
(37:25):
process.
That's the ultimate goal.
They they have something.
And again, these guys, theseframeworks are just designed to
help you.
You may already figure some ofthis stuff out, but they're
designed to give you somethingto go to, like a touchstone to
come back to.
A framework that you can bringto your people and put it in
front of them so they understandwhat you're trying to
accomplish.
It has improved securityposture, obviously, because the
(37:45):
different levels will do, willlead to a stronger security
measures and the security isformalized and embedded into the
overall development process.
It does enhance compliance,right?
Because there is standarddocumentation.
Now you get to level three andabove, that's where you have
that.
That will be compliance is veryvaluable there because you have
that defined.
And then it can make it a muchmore incident-efficient incident
(38:06):
response process, especiallywhen you're dealing with teams
that have clear processes andmetrics for responding to the
overall threats.
What are some challenges withusing the CMM?
It can be resource intensive.
You do reaching a highermaturity levels, particularly
four and five, can havesignificant investments in
development, training, andtooling.
(38:26):
The people will have to have betrained on how to do all this
stuff.
Um whereas it's it's just moreof a you move from one level to
the next level to the next levelas an organization.
As you get up there, it takesmore and more money and more and
more resources to do so.
There is complexity andresistance to change.
Again, moving from the ad hocprocesses, which is level one,
(38:46):
which most people operate in,and all of these will be very
valuable if you're trying tomove from the ad hoc process to
a managed or optimized level,does require cultural changes.
And it's going to takesignificant cultural uh um
feedback and invaluableinformation from your senior
leaders to help you get to thispotential issue or get you to
(39:06):
where you want to go.
Now, the potential forbureaucracy, obviously, that
various levels lead to excessivedocumentation or processes,
which I'm running into now.
And what ends up happening is itcan slow down development if
it's not balanced properly.
You gotta have it, but you gottamake sure that you don't go and
create documentation for thesake of documentation.
Uh, one of the things when Iworked at Koch Industries,
Charles Koch made a comment uhto some of his leaders, not to
(39:29):
me, obviously, but he made it tothe point of charts for Charles.
People would just make chartsjust for Charles specifically,
and he's like, that's wasteful.
Why are you doing that?
So you don't want to have overover too much over bureaucracy.
It helps cause lots of it'sactually very wasteful.
The ideal model.
So, what is that?
So, the ideal model is a processof improvement model that
(39:50):
provides structure, phasedapproach for implementing
organizational improvements, andit what it stands for is
initiating, diagnosing,establishing, acting, and
learning.
Yes, the ideal.
Is capitalized not just becausesomeone forgot to leave the caps
lock off, it's because itactually stands for something
initiating, diagnosing,establishing acting and
learning.
Now, this was developed by SEIand it's used for software
(40:14):
engineering that can be appliedto cybersecurity and risk
management practices.
It helps organizations implementimproved security practices
systematically.
So, again, another model for youto pull, put in your toolbox,
and determine if it's somethingyou want to use.
Okay, so there are three phaseswithin the ideal model.
We're going to start with numberone is the initiating phase.
This is where you lay thegroundwork for the improvement
(40:36):
process by setting the goals,ensuring you have stakeholder
buy-in, you have sponsorship,and you've established community
uh commitment from yourstakeholders on what they're
going to do.
Now, the key activities thatcome into this is that it's an
improvement initiative, whichincludes strengthening your
security controls.
It needs to have executivesupport, right?
Like all of these really do.
They all do.
(40:56):
And then identify and engageyour key stakeholders, including
IT, security, and your businessleaders.
These are some of the keyactivities that go with it.
Now, diagnosing phase, thisassesses the current state to
identify gaps, weaknesses, andareas for improvement.
Your gap analysis will be doneto identify your current
strength and deficiencies.
And then you'll also perform arisk assessment to identify and
(41:17):
prioritize your security risk.
That's in the diagnosing phase.
And then you'll document thesefindings to provide a baseline
understanding of your currentstate.
So again, you'll create somedocumentation.
Where are we at?
We initiated it, we diagnosedourselves.
Doctor, where are we?
And you are the patient says orthe doctor says the patient will
live.
That is the diagnosing phase.
(41:37):
Established phase.
This develops a detailed actionplan and defines specific goals
for improvement initiative.
You'll develop a roadmap withaction plans and outline steps.
You'll set measurable goals andmilestones to track progress,
and then you'll define yourresource requirements, including
budget, personnel, and tools toensure you happen.
This is an establishing phase.
You'll establish your policiesand procedures and metrics that
(41:59):
align with your industrystandards and regulatory
requirements.
Again, establishing what youneed to have accomplished.
That's the establishing phase.
Now, each of these phases doesnot happen very quickly.
It will take time.
You will take time for you todevelop this.
And as you develop it, again,this takes resources.
But there's a various phases youhave to go through with this
ideal model.
(42:19):
Then you have the acting phase,not acting on the stage as an
actor.
You are no, you're actuallyputting things into place.
So this is the exact execute theaction plan to implement
improvements and achieve thedesired security objectives.
These changes to securityprocesses and policies and
technologies according to theaction plan.
And you'll ensure that youremployees are understanding of
(42:41):
what's going on because you'regoing to have to raise awareness
with them during this phase, theacting phase.
You're going to monitor progressagainst milestones and adjust as
needed, and then you'll develop,test, and validate the security
improvements to ensure they meetthe established requirements.
That's the acting phase.
And then the last phase is thelearning phase.
This is where you evaluate theresults, improved effort, and
(43:03):
identify the lessons learned andrefine your improvement
initiatives.
Now, some key activities in thisarea is that you're going to
obviously analyze theperformance data and understand
what's going on.
You're going to gather feedbackfrom the stakeholders to
determine what worked well andwhat challenges did you run
into.
You'll document your lessonslearned and improve future
initiatives, and then you'llmake adjustments to security
(43:23):
based on your overall insightsgained.
So again, that's that's theideal model.
That's the five levels.
So what are some benefits of theideal model?
Clear structure andaccountability.
It provides a structuredapproach and assigns clear
responsibilities and objectives,helping to ensure accountability
at each step.
It's improved resourcemanagement, right?
(43:44):
The ideal model does help withyour resource management and
ensuring that you have executivesupport.
Now, I will say on all of these,you have to have some level of
executive support.
So you know what?
That's it's kind of one thatblends across all models, but I
would say that in the sprintplanning and so forth, the
different models there, I'vebeen able to develop those
without executive leadershipbuy-in.
(44:05):
The resource model, you're gonnaneed that because you're gonna
end up doing a lot of trainingand you need to have a lot of
people involved in this.
So you'll have to have budgettools and the personnel needed
to make sure that this is donecorrectly.
And then you'll have a long-termsecurity maturity that's gonna
need to be built and ensure thatit's put in place effectively.
All right, that is all I havefor you today.
I hope you guys have a wonderfulday.
(44:26):
Please go to CISSP CyberTraining.
Go check out the products I'vegot there available for you.
As you can tell, there's lots ofchange happening on CISSP Cyber
Training.
There's always new content beingposted in the site.
It's go, it's growing, it's it'samazing because you know what?
I got great people like you allthat listen to the podcast as
well as go to the training andgive me feedback.
Uh go there.
Anything you purchase at CISSPCyber Training goes to our
(44:49):
nonprofit for adoptive kids.
So again, all the money's goingto that.
So that's a great cause, greatway for you to be able to give
back a little bit and get somegreat CISSP training.
It is, it's really good.
And I know all of you areworried about money, it's
understandable, and I get it,totally get it.
Uh, so the the that's why theprice point to get into it is
(45:10):
very, very low.
I mean, it's it really is.
It's like going out for dinnerkind of low.
And the purpose is I want tohave you guys have the ability
to get the training that youneed as quickly as you possibly
can and get at it.
Uh, so again, go to CISSP CyberTraining and I hope you have a
wonderful day, and we will catchyou on the flip side.
See ya.
Welcome to the CISSP Cyber Training Podcast, where we
provide you the training andtools you need to pass the CISSP
exam the first time.
Hi, my name is Sean Gerber, andI'm your host for this
action-packed informativepodcast.
Join me each week as I providethe information you need to pass
the CISSP exam and grow yourcybersecurity knowledge.
(00:21):
Alright, let's get started.
SPEAKER_01 (00:25):
Hey, I'm Sean Gerber with CISSP Cyber Training and
hope you all are having abeautifully blessed day today.
Today is an amazing day.
Yes, we are going to be gettinginto domain eight, and we're
going to be delving deep intothe overall development
methodologies that areassociated in domain eight.
And this comes down to youragile, your waterfall, your
spiral, and so forth.
So, yes, hang on, put yourseatbelt on.
(00:48):
It's going to be an amazingride.
Way more than I could everimagine.
Yeah, make sure your seatbelt ison because you're probably
driving into work.
But that being aside, before weget started, real quick, there
is an article in Wired magazinefrom a Matt Burgess and a Lily
Hay Newman.
And they they talk about acouple different aspects, but
there was one aspect in herethat I thought I just wanted to
(01:10):
bring to your attention.
And the reason is because, asmany of you are listening to
this podcast, you probably comefrom an IT background.
Well, obviously, if you'resitting for the C the CISSP, you
have some level of IT so thatyou can get the prerequisites to
get the exam or thecertification.
But there was uh an article inhere about an individual who
changed the menus at DisneyWorld.
(01:33):
And the point of it came into islike, well, you're like, okay,
so what?
Right?
He changed the menu.
Well, he changed the menu, andhe the reason he did this was
because, well, he wanted parts,he was fired from the company,
but he still had access to thepasswords.
Well, I would have wonder isokay, what else did he have
access to, right?
So he had access to thepasswords, and before he left,
(01:54):
he ended up changing them to theWingdings font, which basically
isn't completely consisted ofsymbols.
So the menus went all tosymbols, and that caused all
kinds of chaos and pandemoniumbecause people could not get
their nachos and cheese withMickey Mouse, right?
So that's a terrible thing tohappen.
But that the point of it is thefact that if you have
(02:14):
individuals within yourorganization, you should, if you
don't already, and that's justpart of the CISP, we bring this
up, is have a great exitstrategy so that when the person
is leaving your organization,they are actually, instead of
just in case of just walked out,their credentials are terminated
and ended at the same time.
Because you know what?
You don't know what they can doafter they leave the
(02:35):
organization, especially ifthey're in IT and they have the
ability to remote back into yourorganization.
So it's interesting how thishappened.
But the federal complaint thatthey set out there was that he
had changed the menu listing sayuh to say that foods with
peanuts in them were safe forpeople with allergies, which
that could have been really bad,right?
Somebody takes that underadvisement and then they end up
(02:58):
eating it and getting very, verysick, or potentially even dying
in some cases.
So that is a huge deal.
Uh, he locked 14 employees outof their accounts trying to log
in with an automated script.
So obviously, he had some ITskills.
And so, therefore, yes, thatwould have been somebody you'd
bid on your radar and watchlist.
And then he also maintained afolder of personal information
(03:19):
about employees that turned upat one person's home.
So, again, this individual issomeone who is a malicious
insider who had plans to dosomething to the organization.
Now, the question if is he knewhow to do scripts?
Did he do a logic bomb?
Did he do any of those differentaspects to your organization
that you now have to go in anddig out, which causes lots of
(03:40):
time, lots of energy, and Iwouldn't put it past him if he's
able to do these things, couldhe have done something else like
that?
So something to consider if youhave employees that have IT
skills in your organization,right?
It's always something toconsider.
All right, so we're gonna moveinto domain eight.
So let's get into it.
Okay, domain eight, eight dotone.
(04:01):
This is how to understand andintegrate security into the
software development lifecycle.
So your SDLC.
So we're gonna get into somedifferent topics, and these are
the ones that I will tell you inmany ways kind of really caused
some consternation with folksjust because of the fact that
it's a lot to put in place, andif you don't deal in the
development world, it can be alittle bit overwhelming.
(04:22):
Okay, development methodologies.
This deals with agile,waterfall, DevOps, and
DevSecOps.
So we're gonna be dealing withthe software development
lifecycle.
Now, if you all have dealt withthe software development
lifecycle, if you have or if youhaven't, something for you to
really get good atunderstanding.
And the reason I say this isbecause in today's world, as you
see, everything has some levelof IT in it, right?
(04:45):
From development standpoints toIT connectivity, you name it,
it's in there.
And so understanding of thissoftware development lifecycle
is an important factor becauseit's highly it's highly likely
you will have developers workingwith you and for you in the
future if you do not already.
So, the one thing around theSDLC is the fact that there's
(05:05):
some key activities you need tounderstand from the conceptual
design, functional requirements,you know, what is the purpose of
it, conceptual design is as whyit's made, uh, the control
specifications, and what arethose requirements specifically
set around the controls, thedesign review, your code review,
and how you're gonna do codereview, and user acceptance
training, and then maintenanceand change management.
(05:26):
These are key activities thatyou'll hear words for.
And you UAT, I actually, when Ifirst started in the development
space and trying to understandit, I didn't quite understand
what UAT was.
But it's a really good topic,obviously.
For users have to accept this,the amount of information that's
coming to them.
They have to test it, they haveto accept it, and then from
there they decide which way theywant to go.
(05:47):
So we'll kind of walk throughthis a little bit and see,
understand how each of thesework.
So, your conceptual design, it'sagreed upon by all of your
stakeholders.
So, what is the overall designfor your development plan?
It's a high-level, clear, andsuccinct point of what you're
trying to accomplish.
The goal is not to make this toocomplicated when you're first
designing it, the conceptualaspects of it.
(06:10):
Because what will happen is whenyou work with your users and
with the stakeholders, they mayhave changes to it.
So you want to avoid making thisway more complicated than it
needs to be.
It needs to be abstract as a oran introduction of how things
are gonna happen.
So, this is like your pitchdesign.
What do you want it to do?
And then it defines your endgoal and the output of what you
want to accomplish with theoverall design itself.
(06:32):
So, what are the functionalrequirements?
There are system functionalrequirements that have to be
defined, and this is where youwould do them.
These would be how they're gonnainteroperate with other systems,
what's going to happen, how dothey communicate with each
other, how are they gonna actfor the user, and so forth.
Now, the stakeholders need to beconnected with the functionality
because they need to know howit's gonna work.
(06:53):
One thing to be considering iswhen you're talking with the
stakeholders, make sure theyunderstand what they are trying
to accomplish with this tool.
If they don't know, so I've beenhad multiple times where the
stakeholders are senior leaders,they have an idea of what they
want, but they don't trulyunderstand how they want it to
work.
Make sure that you bring insomebody else in the
conversation with you thatunderstands it a little bit more
(07:15):
granular so that they can helpconnect the senior leaders with
what the functionality is goingto be.
And then it's referring towhat's during the it's referred
to during their developmentprocess.
That's the functionalrequirements.
When you when you're developingit, you're gonna come back to
the functional piece.
What do you want it to do?
How do you want it to operate?
How do you want it to interact?
Okay, so what are the controlspecifications?
(07:36):
Now, the control specifications,these are additional steps with
functional requirements.
What do they have to havehappen?
It adds security controls to thedesign function when you're
doing the different specificcontrols that you have in place.
You want to make sure thatyou're continually bringing up
security in this conversation.
It's important, it's imperativerealistically.
One, there could be compliancerequirements and legal
(07:57):
requirements for this.
Two, it's just good businesssense that you want to do that.
Now, the one thing you have toavoid, and this can happen, is
if you have a bunch of securitypeople in the room and they're
all secure developers andthey've done it for a while,
they really know it.
And I'm not saying this is bad,I think this is good.
But if you're a stakeholder, youneed to weigh the risk of the
security controls you have inplace with what you're trying to
(08:20):
accomplish, because the securitycontrols can add extra stuff to
your overall plan, which, if itdoes, then can add challenges to
your individuals that are usingthe tool.
So you gotta weigh out the riskversus reward on this piece of
it.
Now you want to incorporateencryption where you can, where
it's appropriate, and then youwant to be proactive in
(08:40):
reevaluating during the majorrevisions.
So what that means is that asyou go back and do a revision,
you want to make sure that youstay proactive with these
controls and that you'reconstantly trying to fix them.
Now, the design review, this iswhere user interface and user
experience are designed, andthen this is where the
stakeholders will review thework and approve the overall
design.
So this is what you have a plan,you have a review, you're gonna
(09:02):
walk through it, the userinterface, how it's gonna play
out, your or the UEI, the userexperience, and how that's gonna
play out, and then you're alsogonna make sure that the
stakeholders are aligned withthe plan.
Once they're aligned with theplan, they sign off on it, then
work can begin.
Now, the code review, this waswhere the developers begin
coding.
Now you want to make sure thatyou connect with your coders on
(09:23):
this to that you have a goodplan and you have to watch them.
And I don't mean that in a badway, but I mean what'll happen
is coders will add moreinformation to it potentially
than what is necessarily needed.
So you need to make sure thatyou have all that under control.
Now, this is where the differentmethodologies come into play the
agile, the waterfall, and soforth.
These will allow updates to itas you go forward, but you need
(09:46):
to make sure that you stayconnected with how the coders
are developing your code.
And this is be a code reviewwalkthrough, and this is where
you have specific milestones setup.
You could have a code reviewwalkthrough once a week.
Uh, it could be part of yoursprint, it could be part of the,
it could be once every twoweeks.
It depends upon your overallplan and how you have it set up,
but it should have milestones inwhat you're trying to accomplish
(10:08):
from a development point ofview.
Now you have a security reviewwalkthrough of the code as well,
and this is where you would haveindividuals look at it from a
security perspective and makesure that it meets the needs
that you're trying to accomplishthat were spoiled out in the
requirements earlier set.
So, again, developers begincoding, you have a code review
walkthrough, and then yoursecurity is tied into the
overall code review.
(10:28):
User acceptance testing, this iscompleted prior to going to
production.
So prior to you pushing andmashing the big green button to
send the thing into production,you want to make sure the users
accept what they have you havecreated.
And it's imperative to do thisbecause the last thing you want
to have go out there is you sendit into production and then the
users go, uh yeah, that's notwhat I wanted.
You don't want that.
(10:49):
Have I had that happen to me?
It's very uncomfortable and it'syeah, it's not good.
So you want to make sure thatthey test it before, or they
they try it, the users try itbefore you actually put it into
production.
You're looking for any obviouserrors that you may come up
with.
You know, the button's supposedto be green, but it was blue,
right?
You want to make sure that it uhopens up the web page and the
(11:11):
fonts are not windings orthey're uh normal cabriolet,
whatever that is, you want tomake sure that they have those
obvious errors that you'retrying to fix.
You're not trying to find allthe errors in it, though.
You want the users to try tounderstand it.
Does it make sense?
Does it flow?
Does it meet their needs?
And this includes where they'retesting every little menu,
going, yep, uh-huh, yep, no, Idon't like that font color.
(11:33):
I don't like that backgroundcolor, those types of things.
Then once it's once complete,the code is then deployed to
production, and then that'swhere the fun begins.
Uh, you have your maintenanceand change management.
This will have this window herethat ensures that maintenance is
built into the planning process.
Vulnerabilities and updated codeare sent out, and then you need
(11:54):
to have a formalized changemanagement process to make
changes to your code.
It's imperative that you do thatas well.
So you gotta have the changemanagement piece.
We've talked about this a lot inthe CISSP training, that you
have to have a good formalizedchange management process.
And the reason isn't just tomake a bureaucratic challenge,
it's to follow, have coursechanges, have documented
(12:14):
changes, you know it'soccurring.
And then when things gosideways, which they always do,
you have a way to be able to goback and look at what happened
and then make modificationsbased on it.
So let's get into the differentlife cycle models.
What are these?
Okay, so we're gonna talk aboutwaterfall, spiral, agile, and
(12:34):
software capability maturitymodel, and then other it's more
of a framework, and then ideal.
Okay, so these are the oneswe're gonna get into, and these
are the ones I pull out of the CI SP Cyber Trade, or not CIP
Cyber Training book, ISC SquaredCyber Training.
Yeah, no, I can't even speak.
The ISC Squared C I SSP book.
This is where we pulled them outof there.
Yeah, there are other lifecyclemodels, but these are the ones
(12:55):
we focused on specificallybecause they're called out in
the ISC Squared book.
So the waterfall model.
So if you're able to video orsee the video on this, you'll
see how the waterfall modelworks.
And it all just kind of flewsdownhill.
That's the ultimate purpose ofit.
And so we'll get into some ofthe positives and the negatives
that roll with this model.
I've dealt with both uh withthis one and with Agile, my two
(13:16):
primary ones that I've focusedon.
Uh the spiral I've dealt with alittle bit, and a couple of the
other ones that are just ontacit kind of activities.
So this one was developed in the1970s, the waterfall model.
It's a series of iterativeactivities, okay?
And these activities arebasically seven different steps.
So you have the systemrequirements, and we'll get into
each of these here in just aminute, but and you have your
(13:38):
software requirements, you haveyour preliminary design, you
have your detailed design, youhave code and debug, you have
testing, and then you haveoperations and maintenance.
So, as you know, we just talkedabout this at the beginning.
We kind of went through the samelevel of steps, different names,
different kinds of terms, butoverall it's a very similar
process than what we justmentioned just a little while
(13:59):
ago.
So, what is the waterfall model?
What does it do?
It provides feedbacks fordefects that are found.
So the goal is that as thisthing goes through each of these
steps, the system requirements,the software requirements, it's
looking for feedback on thedefects and then it goes back up
to the next step.
And we'll kind of get into butit's like your system
requirements.
(14:19):
Okay, you move it, it's uh yougot all the requirements you
need.
Okay, now let's go into thesoftware requirements.
And then if the softwarerequirements there are errors,
it will go back, it'll step backone level.
It'll go back up to systemrequirements.
Now, if errors are discoveredlater down the fall, later down
the steps, such as in the codeand debug area, well, no, you
(14:40):
can't, there's not a whole lotyou can go back to the system
requirement.
You have to follow through withthe fall, unless it's something
that is like, oh my gosh,terribly bad that you have to go
back and fix.
But for the most part, if it's asmall design change or something
that along those lines, it hasto keep on going.
And then you'll come back andreiterate it with a with a new
(15:01):
version.
So the result is verificationand validation process you must
have in place before you move onto the next step.
So, what are some of thestrengths with your waterfall
methodology in your model?
It's predictable and you canhave control.
So the waterfied waterfallstructure does approach the
(15:21):
minimizes the unexpected changesyou may have, providing a more
foundational or more stablefoundation for enforcing
security policies and reducingyour overall risk.
It's predictable.
You have a plan, you follow theplan, and you operate with the
plan.
There's detailed documentationthat goes with this.
So with each of the waterfallprojects, they have a very clear
(15:43):
and very specific audit trail,which is very beneficial when
you're dealing with complianceand regulatory standards.
Now you'll come to find outthere are various regulatory
standards that are going torequire you, especially in the
development space, to have thataudit record in place.
So you need to have that done.
They also have defined testingphases.
These are distinct testingphases that allow for
(16:05):
comprehensive security testingto ensure your requirements are
met before it's actuallydeployed.
So you having this definedtesting phase is an important
part.
And then lastly, because wementioned earlier, change
management.
It does have a really strongchange management policies as
well once the changes arelimited, once your phase is
(16:25):
completed.
So it doesn't allow you to goback.
If you get halfway down theline, you go, oh no, I forgot my
screwdriver.
Well, that's really not anappropriate screwdriver, drinker
screwdriver as your screwdriver.
You forgot your screwdriver atthe top.
Okay, it doesn't even make anysense, but that's okay.
You forgot something reallyimportant to you.
You forgot it.
What did you do?
Oh, I want to go back to thetop.
(16:46):
You cannot.
So the change management processallows you to only go up one
more step, but it for the mostpart, you have to follow
through.
And this does help aid inreducing the likelihood of
introducing new vulnerabilitieslate in the project.
So, what are some limitations inAgile security?
It's inflexible, it does involvewith involving the various
(17:07):
security threats that are inplace.
So let's just sayhypothetically, you are
mid-flight into this waterfallmodel and you realize, oh no, we
have a big security threat.
It doesn't, it doesn't have theflexibility that you may need
for iterative improvement.
And the rigidity can delay theadoption of new security
measures or fixes if a threatpops up.
(17:27):
Now, you'll have to go backthrough the whole process if you
find something that is reallybad.
But at the end of the day, now,granted, I say this, you if you
got halfway through and you wentand realized, oh no, OMG, we
have like the worst hack ever.
Okay, yeah, you're not going tocontinue.
You you'll back it up, right?
But the ultimate goal is thatyou don't back it up for just
(17:48):
normal fixes or for securityvulnerabilities that you find
that may not, you don't reallyknow the effect of them.
You don't know what's going on.
Because to stop a waterfallsprint, lack of a better term,
in midstream is very challengingand it causes a lot of
confusion.
So you really want to follow allthe way through with this
process.
Uh the rigidity can adopt thedelay the adoptive security
(18:11):
measures or fixes, which we kindof talked about.
Now they do have limitedresponse to the change.
So waterfall does notaccommodate iterative updates,
making it challenging to respondwhen you have security
requirements or emergingthreats.
And then for long-term projects,this limitation can require
revisiting earlier phases, whichcan be costly, especially from
(18:34):
opportunity costs, or if you'rehiring contractors from an
actual capital loss cost thatcan add up.
And depending upon theleadership, they may not want to
do it, right?
Because of it, just say, forinstance, this development
process took 18 gazilliondollars, and now they're like,
hey, sir, I need to go and askfor some more money.
And they're gonna go, no, youcan't have any more money.
(18:54):
So, yes, it's one of thosethings that causes some
challenges.
And then delayed securitytesting.
Testing can only occur after theimplementation phase, which can
lead to higher costs as well ifthe vulnerability is discovered
late in the development process.
So it can add a lot of differentthings.
It does it does work very well,though.
The waterfall model works verywell, it allows you to get to a
(19:16):
point, it has milestones.
It's a really good program orproject management type of model
because it's step one, step two,step three, step four.
Step C.
I said step C, step three.
Yes, my wife gets on my case.
I can't speak most days, must behaving like mini strokes or
something.
Okay, so now we're gonna getinto waterfall versus agile and
devsec ops.
(19:36):
So the waterfall is best suitedfor project with the stable
requirements and regulatoryconstraints.
It's a one that you'll want tohave when you're dealing with it
because of the thoroughdocumentation and predefined
security checkpoints that youplace in here, and that's an
important part.
It works well in the highlyregulated industry, such as
government, healthcare, andwhere documentation and
adherence is important.
(19:58):
I'm working in the healthcareindustry right now and Oh yeah,
baby, you gotta have lots ofdocumentation.
It's to the point where you justkind of want to throw up because
it's a lot of stuff.
And you have a lot of reallygreat people working really
hard, but they don't get it veryfar very quickly because of all
the extra stuff that has tohappen.
So it causes a little bit of achallenge.
Agile and DevSecOps.
(20:18):
So now what's the differencewith them?
They're better suited forprojects where security needs to
adapt quickly to evolvingthreats and requirements.
It does allow for continuoustesting and integration, and
they're more suitable fordynamic environments where it
must be continuously tested andthe response to new
vulnerabilities are highlighted.
So that's the difference betweenit.
So you got to kind of thinkabout which way works best for
(20:38):
you depending upon theenvironment that you're trying
to get into versus um waterfallversus agile and devsychops.
Next one we're gonna be gettinginto is the spiral model.
Yes, as you look at thisdiagram, you'll see my beautiful
drawing on the right hand side.
Yes, it's very pretty.
It looks like a second graderused a crayon.
Did not turn out so well.
I didn't know how to make littlecircle thingies with PowerPoint.
(21:01):
So you get what you get.
I think you'll figure it out.
It's pretty easy.
So the point of it is it's in aniterative development cycles.
These projects pass throughmultiple phases or multiple
times, allowing for gradualrefinement of each cycle or
iteration.
This does incorporate theplanning, the risk assessments,
development, and evaluationsthat are occurring.
(21:22):
Now, risk management is animportant part of all of this,
and it's it's a significantemphasis on risk, which because
each iteration begins with anidentification, analysis, and
mitigation planning for riskspecifically.
And it focuses on this earlyidentification and resolution of
a potential critical issues.
Now, I've never really used thespiral method, I've just looked
(21:43):
at it and read the book on it.
But it makes sense how it works.
I would say it I personallyreally like the agile and devsec
ops methods in the overall plan,but it's mainly because probably
because I've worked with themand I've never really actually
dealt with the spiral model.
So some people must really likeit.
Phases of the spiral.
You have a planning, riskanalysis, engineering, and
(22:04):
evaluation.
Now the planning is helpinghelps to identify objectives, it
gather requirements, planningthe specific goals and
activities for each of thesecycles, each of the little
pinwheel cycles, it gathersthat.
Then the risk analysis assessesthe risk with the objectives for
evaluating alternatives.
And like we mentioned, thespiral method is focused
strongly on risk.
And so you'll be that's a greattime to do that.
(22:26):
It's during that second phase.
Engineering helps develop theproduct incrementally through
implementation, and this couldbe you have different types of
models and so forth built out.
And then evaluation reviews theprocess with the stakeholders
gathering feedback and decidingwhether to move to the next
cycle or adjust the prioritiesas needed.
Now there's a flexibility, andthe feedback are really
(22:47):
important with the spiral model.
This incorporates changes andfeedback at the end of each
cycle, making it adaptable tothe changing requirements or
unforeseen changes andchallenges that occur within
your network.
It's important on projects withevolving requirements and it
allows for the team to pivot oradjust as it's going around the
pinwheel on the valuations atthe end of each spiral.
(23:08):
So you basically have phase one.
You do your littlewhoop-dee-woo, and you come back
and you hit it phase two, phasethree, and so on and so forth.
And each of these times, theseiterations, you will make
modifications to it.
So again, it's very similar,right?
You just you go take a couplesteps, you then reevaluate.
Take some steps, re-evaluate.
Very similar to all of thesedifferent models, except you
(23:29):
just did, like in the waterfall,you can't re-evaluate and
reassess.
You have to go through theentire process.
This one you re-evaluate andreassess before you move on.
Now there's a prototypedevelopment that can occur in
the engineering phase.
Now, this is used to validateideas, functionality, or explore
specific risks that you'refinding.
So the the overall engineering,if you're dealing with a
(23:50):
prototype, it could just be withsome prototype of the
development that you have, yourcode that you've created.
These prototypes providetangible, testable models for
stakeholders to review, andthere would be some level of
user acceptance testing in thisand help them refine the
requirements and reduceambiguity of the earlier life
cycles, of the earlier spinsaround the pinwheel.
And that's the ultimate goal, isjust to help get that kind of
(24:12):
feedback loop from your people.
There's defined entry and exitcriteria.
Each phase with the spiraliteration will have a specific
entry and exit criteria, meaningthe objectives must be met
before moving forward.
You can't move forward unlessyou go, you've met the
objectives that you highlightedat the beginning of this
process.
Because otherwise, then youinstead of having a nice clean
pinwheel, you have a pinwheelthat looks more like my pinwheel
(24:35):
that I have on my graphic.
No, not quite that good.
It's actually pretty prettyimpressive, actually, for a guy
that's my age.
No, I my dementia came in.
Um it's got a clear criteria tohelp ensure the phase is
completed, to set the standard,managing risks at each step, and
avoiding moving forward withunresolved issues.
So that's the ultimate point isyou have defined entry and exit
(24:55):
criteria on the specific modelthat you're working on.
Now there's a cost and scheduleestimization per cycle.
This is an important part aswell, is you're gonna have to
make sure that you have properresources set aside, and you'll
need to make sure you haveestimates on the time and the
amount of money that's gonnatake for these specific reach to
reach these specific andattainable goals.
(25:16):
You have an incrementalestimation approach, allows for
more accurate planning andbudgeting as well.
And then you have a cumulativeprocess.
Each iteration builds on theprogress of the previous cycles,
leading to a development andrefinement of the overall
product itself.
And it allows you to adapt andevolve, moving closer to the
final product, even with thechanges along the way.
(25:37):
Now, the agile method, let's gointo that one.
So we were dealing with theagile method, it was developed
in the 1990s.
In 2001, there was a manifestofor agile software development.
It's a big$10 word to make yousound really smart, but it's
basically a document, right?
Manifesto.
Uh 12 key principles whenworking with this, and it does
work software is primarily themeasure of progress.
(25:59):
A working uh product that youhave at the end is usually the
measure of success when you'redealing with agile.
Well, with all these, theyreally are.
But agile tends to, you it youhave something and then you
start iterating on it.
Now there are many differentvariants of the agile
methodology.
There's Scrum, there's Agile UIUP, which is Unified Processes,
(26:20):
there's Dynamic SystemsDevelopment Model, DSDM, and
then there's Extreme ProgrammingXP, not XP, the Windows XP, but
Extreme Programming XP.
So there's different types ofagile that are available.
And we're not going to go intoall of those.
We'll focus a little bit onScrum because Scrum I've I've
worked with, but you may want tounderstand a little bit more out
of all of those just so that youunderstand how they work and
(26:42):
what's the purpose behind them.
Okay, Agile Scrum.
This is the security integrationof the Agile environment.
So you've got some differenttopics we're going to go over
when relating to the overallScrum process.
But collaboration is a keyfactor.
This allows for continuouscommunication and collaboration
between security, development,and the operations team.
It's a collaborative meeting.
(27:02):
You would have daily stand-ups,and these stand-ups you would
collaborate and talk about whatare some of the changes you need
to make.
There's security end userstories.
So, what are user stories?
It outlines the requirementsfrom the end user's perspective.
It integrates security intothese stories, into each of
these, and it helps ensuresecurity is part of the
development from the onset, suchas security acceptance criteria.
(27:25):
Then you have the definition ofdone.
Done can incorporate securitycriteria, ensuring that all the
tasks meet a specific securityrequirement before they get
marked complete.
So you have to have that donebefore you can actually move on.
If they're not, they don't meetthe criteria, then you don't
move on.
And then you may have to set upanother sprint that deals
specifically with those criteriathat were missed.
(27:48):
Now the sprints for securitytesting, basically the iterative
sprints allow for regularsecurity testing and feedback.
These should be short, theyshould be really quick, no more
than two weeks.
I ideally a week sprint would beawesome, but they kind of tend
to be about a week to two weeksin duration.
This does enable the team toidentify and resolve security
(28:09):
issues as the project progressesrather than once the development
is complete, such as in thewaterfall method.
Now you're going to deal withsome artifacts of dealing with
overall scrum.
You have backlogs, you have yourproduct backlog, sprint backlog,
and then you have the increment.
The product backlog, this iswhere things are added directly
to this backlog, ensuring theyare prioritized and addressed
(28:31):
systematically.
So what does that mean?
So that means you have differentrequirements in your product
backlog that need to be made.
Then these user stories mightinclude tasks such as threat
modeling, pen testing, codereview, all of those aspects
might be within your productbacklog that you need to occur.
And then you will just use amenu and you will pick through
those to decide based on riskand based on what you can
(28:53):
accomplish in that scrum, whatand that sprint, what you can
do, you will then call that intoit.
Now, the sprint backlog, this iswhere tasks are prioritized and
assigned to ensure they'recompleted within the sprints
framework.
So within the time frame youhave.
So you take from the backlog,you put it in the sprint
backlog, which is in this sprintwe're gonna accomplish.
So the backlog's got, let's say,50 different things you have to
(29:13):
get done.
The sprint backlog, the sprintthat you're gonna focus on, this
one week, two-week thing, is gotX amount, right?
So it's got less than theoverall gazillion that are in
the backlog.
But those are prioritized thenon which ones can you do this
sprint.
So if you can get them all done,awesome, that's great.
But if you can't, which ones arethe best prioritized?
And that's the sprint backlog.
(29:34):
Then you increment this eachincrement that delivered or
should be delivered to meet theorganization's security
requirements, such as what isthe definition of done.
This ensures that security isprogressively integrated
throughout the entiredevelopment lifecycle.
So what are some of the rolesand responsibilities of Scrum?
So you have a product owner.
This is responsible, this personis responsible for the
(29:55):
requirements, ensuring thateverything is prioritized,
security related, or userstories are put in place, and
they'll work with the securityteams to understand and
communicate the implications tothe Scrum team.
So if you're the product ownerfor the full-up development, you
will own the overall developmentplan.
If you're the product owner forsecurity, you will then make
sure security is embedded withinthe development piece.
(30:16):
You have your Scrum Master.
This person advocates for bestpractices within the Scrum team,
and they ensure that the securecoding and testing is completed.
They also help identify andremove obstacles to security
tasks, facilitating more secureenvironment.
Then you have your overalldevelopment team.
They are the ones that aredirectly responsible for the
(30:37):
secure coding practices, conductpeer reviews, perform unit
tests, and so forth.
They're the ones that do all thework and they help gain a clear
understanding of what therequirements are.
Now we'll tell you, you're gonnahave to be well invested within
the development team if you wantto incorporate your security
mechanisms into it.
It's an important part that youdo this.
You stay embedded, and in fact,you are working with them
(31:00):
closely.
So you need to be part of theoverall scrum uh that that's
going on.
Now, scrum is part of a, I thinkwhat is it?
What is that football game?
Oh, it's gosh, I can't it'srugby.
It's part of rugby.
So same kind of concept.
You're working together to tryto get the ball down the field.
Kind of like football, butdifferent.
Same but different.
Rugby, actually, football camefrom rugby, from what I
(31:21):
understand.
The American football, yeah, notsoccer.
Um, so the scrum events andsecurity enhancements.
So sprint planning, you havedifferent pieces.
You have your sprint planning.
This was an opportunity toaddress some priority security
tasks for the upcoming sprint toensure that your requirements
are ready for the plan.
And then you have your dailystand-ups.
Done these, oh, so many times.
They're great, they'rewonderful.
(31:43):
Uh, yeah, no, they're they sucka lot of time.
But no, they shouldn't.
They should be very quick, theyshould be like 15 minutes in and
out, nobody gets hurt.
That's the ultimate point ofthem.
Uh, but they are designed for todiscuss any challenges, update,
and encourage culture, and thenif there's any security blockers
that can be flagged andresolved, they'll help with the
overall process in compromisingand fixing that.
(32:05):
There's a sprint review.
This is done by your securityteams, your stakeholders, and
the developers.
They all participate to assesswhether the security standards
have been met and they have metthe deliverables.
You need to allow your securityprofessionals the ability to
give feedback and so forth.
The same with the developers.
Let them give you feedback aswell.
If they say this securitycontrol you want me to put in
place is only for an idiot, donot do it, then you need to
(32:28):
listen to them.
Do not discount what they haveto say.
At the same time, they may saythis kind of security control is
going to add all kinds of dramawith the end user.
Listen to them.
They know in many cases betterthan you do.
And so, therefore, it'simportant that you understand
that.
Uh, the software capabilitymaturity model, okay?
So the CMM or the S C M.
(32:50):
So this came from the SoftwareEngineering Institute at
Carnegie Mellon, SEI.
Uh, and yes, Carnegie Mellon,big brains, very smart people.
So, yes, they came up with somereally neat stuff.
This is the the quality of thesoftware is directly associated
with the quality of thedevelopment.
And their point is that it's aprocess improvement framework,
and this provides organizationswith a structured path to
(33:11):
improve their process, theirsoftware process, versus an ad
hoc chaotic practice tostructured, mature, and reliable
processes.
Now, everything I'm telling youhere, you guys, they're all
structured and reliable, right?
That's the ultimate goal.
You just have to figure outwhich one works best for you and
your overall company.
Now, the primary goal is toimprove the quality and
predictability and control thesoftware development process.
(33:33):
Again, ultimately leading tohigher quality software with
reduced costs and risk.
Now, the applicabilityapplicability, yeah, that big
word.
This is how this works is it'sinitially designed for software
development, right?
But it also can be applied toother areas such as systems
engineering, acquisition, andsecurity practices as well.
So it's it's very applicable.
(33:53):
See, I can't even say that word.
It's too early.
It's 5 30 in the morning.
So yes, it's quite early for me.
Moving on, what are some levelsof the CMM maturity model that
they have?
So we're gonna walk through eachof the different levels so you
understand them.
And there's different keyprocess areas or KPAs that are
associated with this.
So level one is the initial,it's the chaotic, it's the oh
(34:15):
craziness, we don't know whatwe're gonna do.
It's its processes areunpredictable, poorly
controlled, and reactive.
And its success will depend onthe individual effort rather
than an established process.
This is the beginning phases ofit.
Now, the ultimate goal of thisis to move away from the chaotic
process to an established basicprocess discipline.
So when you anytime you getsomething started, a lot of
times there is some chaotic messthat you're trying to figure
(34:37):
out.
The next level is you take it toa repeatable or managed process.
And this is where you haveproject management practices are
established.
The processes are repeatable forsimilar projects, and then they
become reactive, then they thateven though they might still be
a little bit reactive.
Now, this is where the firstsecurity controls are
introduced, and this is whereyou add security-related tasks
such as vulnerabilitymanagement, patching, and all
(34:59):
those are added to it.
Now, the KPAs on this would beit includes requirements
management, project planning,project tracking, configuration
management, and so forth.
So you go from chaotic tomanaged, and then you move into
a defined.
Okay, this is where yourprocesses are documented,
standardized, and integratedinto a unified organizational
process.
Okay, you have structure.
(35:19):
Structure, yes, proactiveapproach for developing
security.
And then the ultimate goal ofthis then is that your practices
are formally integrated intoyour development lifecycle.
And this is where their policiesand standards are created.
That's what the focus of thoseis so that in this space you now
have that ability to documentand have those policies uh
flushed and vetted out.
KPAs will focus on anorganizational-wide standards
(35:41):
and training and an integratedsoftware engineering plan.
It emphasizes a well-defineddevelopment lifecycle.
Then you have level four, yourmanaged quantitatively
controlled piece.
See, my third grade educationjust struggles with these.
It just truly does.
So the characteristics of theseare they're quantitative,
quantitatively measured andcontrolled.
(36:03):
This is where you get metrics.
Metrics are importantincorporated into this, and it
helps identify many areas forimprovement.
You have security enhancementssuch as metrics, and these are
all collected and veryproactive, manage risks.
Then you have KPAs, which dealwith quantitative project
management and processmonitoring, helping
organizations make data-drivendecisions.
That's again, that's the goal,right?
(36:23):
So now you got into managedlevel, a level four.
And then level five, the finalmelon with the levels.
This one focuses on continuousprocess improvement or KPIs,
using the feedback back from theprevious levels to refine and
enhance the process.
Okay, again, so you have thefive levels, you work through
the five levels, and then youbegin to optimize this.
(36:43):
This is where your continuoussecurity improvement is an
important factor, and this iswhere you refine the measures,
adopt the latest securityinnovations, and so forth.
Your KPAs will include changemanagement, defect prevention,
and continuous improvement.
This may be regular threatintelligence if you're dealing
with security, and then youradaptive security measures that
are built into it.
So that's how you optimize it.
(37:04):
This is the levels of the CMmaturity model based on what
Carnegie Mellum came up with.
Now, now the CMM and securityand software development, how
what are some of the benefits ofthis?
Now that's predictable and thereis control.
Again, organizations with matureprocesses, level three and
above, have a very predictableand controlled, repeatable
(37:25):
process.
That's the ultimate goal.
They they have something.
And again, these guys, theseframeworks are just designed to
help you.
You may already figure some ofthis stuff out, but they're
designed to give you somethingto go to, like a touchstone to
come back to.
A framework that you can bringto your people and put it in
front of them so they understandwhat you're trying to
accomplish.
It has improved securityposture, obviously, because the
(37:45):
different levels will do, willlead to a stronger security
measures and the security isformalized and embedded into the
overall development process.
It does enhance compliance,right?
Because there is standarddocumentation.
Now you get to level three andabove, that's where you have
that.
That will be compliance is veryvaluable there because you have
that defined.
And then it can make it a muchmore incident-efficient incident
(38:06):
response process, especiallywhen you're dealing with teams
that have clear processes andmetrics for responding to the
overall threats.
What are some challenges withusing the CMM?
It can be resource intensive.
You do reaching a highermaturity levels, particularly
four and five, can havesignificant investments in
development, training, andtooling.
(38:26):
The people will have to have betrained on how to do all this
stuff.
Um whereas it's it's just moreof a you move from one level to
the next level to the next levelas an organization.
As you get up there, it takesmore and more money and more and
more resources to do so.
There is complexity andresistance to change.
Again, moving from the ad hocprocesses, which is level one,
(38:46):
which most people operate in,and all of these will be very
valuable if you're trying tomove from the ad hoc process to
a managed or optimized level,does require cultural changes.
And it's going to takesignificant cultural uh um
feedback and invaluableinformation from your senior
leaders to help you get to thispotential issue or get you to
(39:06):
where you want to go.
Now, the potential forbureaucracy, obviously, that
various levels lead to excessivedocumentation or processes,
which I'm running into now.
And what ends up happening is itcan slow down development if
it's not balanced properly.
You gotta have it, but you gottamake sure that you don't go and
create documentation for thesake of documentation.
Uh, one of the things when Iworked at Koch Industries,
Charles Koch made a comment uhto some of his leaders, not to
(39:29):
me, obviously, but he made it tothe point of charts for Charles.
People would just make chartsjust for Charles specifically,
and he's like, that's wasteful.
Why are you doing that?
So you don't want to have overover too much over bureaucracy.
It helps cause lots of it'sactually very wasteful.
The ideal model.
So, what is that?
So, the ideal model is a processof improvement model that
(39:50):
provides structure, phasedapproach for implementing
organizational improvements, andit what it stands for is
initiating, diagnosing,establishing, acting, and
learning.
Yes, the ideal.
Is capitalized not just becausesomeone forgot to leave the caps
lock off, it's because itactually stands for something
initiating, diagnosing,establishing acting and
learning.
Now, this was developed by SEIand it's used for software
(40:14):
engineering that can be appliedto cybersecurity and risk
management practices.
It helps organizations implementimproved security practices
systematically.
So, again, another model for youto pull, put in your toolbox,
and determine if it's somethingyou want to use.
Okay, so there are three phaseswithin the ideal model.
We're going to start with numberone is the initiating phase.
This is where you lay thegroundwork for the improvement
(40:36):
process by setting the goals,ensuring you have stakeholder
buy-in, you have sponsorship,and you've established community
uh commitment from yourstakeholders on what they're
going to do.
Now, the key activities thatcome into this is that it's an
improvement initiative, whichincludes strengthening your
security controls.
It needs to have executivesupport, right?
Like all of these really do.
They all do.
(40:56):
And then identify and engageyour key stakeholders, including
IT, security, and your businessleaders.
These are some of the keyactivities that go with it.
Now, diagnosing phase, thisassesses the current state to
identify gaps, weaknesses, andareas for improvement.
Your gap analysis will be doneto identify your current
strength and deficiencies.
And then you'll also perform arisk assessment to identify and
(41:17):
prioritize your security risk.
That's in the diagnosing phase.
And then you'll document thesefindings to provide a baseline
understanding of your currentstate.
So again, you'll create somedocumentation.
Where are we at?
We initiated it, we diagnosedourselves.
Doctor, where are we?
And you are the patient says orthe doctor says the patient will
live.
That is the diagnosing phase.
(41:37):
Established phase.
This develops a detailed actionplan and defines specific goals
for improvement initiative.
You'll develop a roadmap withaction plans and outline steps.
You'll set measurable goals andmilestones to track progress,
and then you'll define yourresource requirements, including
budget, personnel, and tools toensure you happen.
This is an establishing phase.
You'll establish your policiesand procedures and metrics that
(41:59):
align with your industrystandards and regulatory
requirements.
Again, establishing what youneed to have accomplished.
That's the establishing phase.
Now, each of these phases doesnot happen very quickly.
It will take time.
You will take time for you todevelop this.
And as you develop it, again,this takes resources.
But there's a various phases youhave to go through with this
ideal model.
(42:19):
Then you have the acting phase,not acting on the stage as an
actor.
You are no, you're actuallyputting things into place.
So this is the exact execute theaction plan to implement
improvements and achieve thedesired security objectives.
These changes to securityprocesses and policies and
technologies according to theaction plan.
And you'll ensure that youremployees are understanding of
(42:41):
what's going on because you'regoing to have to raise awareness
with them during this phase, theacting phase.
You're going to monitor progressagainst milestones and adjust as
needed, and then you'll develop,test, and validate the security
improvements to ensure they meetthe established requirements.
That's the acting phase.
And then the last phase is thelearning phase.
This is where you evaluate theresults, improved effort, and
(43:03):
identify the lessons learned andrefine your improvement
initiatives.
Now, some key activities in thisarea is that you're going to
obviously analyze theperformance data and understand
what's going on.
You're going to gather feedbackfrom the stakeholders to
determine what worked well andwhat challenges did you run
into.
You'll document your lessonslearned and improve future
initiatives, and then you'llmake adjustments to security
(43:23):
based on your overall insightsgained.
So again, that's that's theideal model.
That's the five levels.
So what are some benefits of theideal model?
Clear structure andaccountability.
It provides a structuredapproach and assigns clear
responsibilities and objectives,helping to ensure accountability
at each step.
It's improved resourcemanagement, right?
(43:44):
The ideal model does help withyour resource management and
ensuring that you have executivesupport.
Now, I will say on all of these,you have to have some level of
executive support.
So you know what?
That's it's kind of one thatblends across all models, but I
would say that in the sprintplanning and so forth, the
different models there, I'vebeen able to develop those
without executive leadershipbuy-in.
(44:05):
The resource model, you're gonnaneed that because you're gonna
end up doing a lot of trainingand you need to have a lot of
people involved in this.
So you'll have to have budgettools and the personnel needed
to make sure that this is donecorrectly.
And then you'll have a long-termsecurity maturity that's gonna
need to be built and ensure thatit's put in place effectively.
All right, that is all I havefor you today.
I hope you guys have a wonderfulday.
(44:26):
Please go to CISSP CyberTraining.
Go check out the products I'vegot there available for you.
As you can tell, there's lots ofchange happening on CISSP Cyber
Training.
There's always new content beingposted in the site.
It's go, it's growing, it's it'samazing because you know what?
I got great people like you allthat listen to the podcast as
well as go to the training andgive me feedback.
Uh go there.
Anything you purchase at CISSPCyber Training goes to our
(44:49):
nonprofit for adoptive kids.
So again, all the money's goingto that.
So that's a great cause, greatway for you to be able to give
back a little bit and get somegreat CISSP training.
It is, it's really good.
And I know all of you areworried about money, it's
understandable, and I get it,totally get it.
Uh, so the the that's why theprice point to get into it is
(45:10):
very, very low.
I mean, it's it really is.
It's like going out for dinnerkind of low.
And the purpose is I want tohave you guys have the ability
to get the training that youneed as quickly as you possibly
can and get at it.
Uh, so again, go to CISSP CyberTraining and I hope you have a
wonderful day, and we will catchyou on the flip side.
See ya.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
Two Guys, Five Rings: Matt, Bowen & The Olympics
Two Guys (Bowen Yang and Matt Rogers). Five Rings (you know, from the Olympics logo). One essential podcast for the 2026 Milan-Cortina Winter Olympics. Bowen Yang (SNL, Wicked) and Matt Rogers (Palm Royale, No Good Deed) of Las Culturistas are back for a second season of Two Guys, Five Rings, a collaboration with NBC Sports and iHeartRadio. In this 15-episode event, Bowen and Matt discuss the top storylines, obsess over Italian culture, and find out what really goes on in the Olympic Village.