Module Summary
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
5 hours 58 minutes
Difficulty
Intermediate
CEU/CPE
6
Video Transcription
00:00
>> Welcome back to Cybrary,
00:00
is of course, I'm your instructor, Brad Rhodes.
00:00
Well, we have made it
00:00
to the end of Module 7 because you processed.
00:00
Hopefully, you see or saw how the ISO
00:00
domain support across the SE process,
00:00
and that's what we were going for in this module.
00:00
In this lesson, we're going to
00:00
review the SE process real quick,
00:00
and then we're going to revisit
00:00
those three key principles,
00:00
and I think you'll probably remember what they are.
00:00
In our discussion here in Module 7,
00:00
we looked at information protection needs and
00:00
that's focused on what is the customer really want,
00:00
what does their information protection needs.
00:00
Again, these are the areas that
00:00
are under the systems engineering process.
00:00
Think of those as the subset
00:00
focused on security engineering.
00:00
Then we defined security requirements.
00:00
Again, those are narrowly focused
00:00
more on things like security controls,
00:00
functions, services, capabilities that are needed.
00:00
We then define the
00:00
architecture and that's where we take all of
00:00
those requirements and we bend them functionally so that
00:00
we can more easily handle
00:00
them as we're getting into the next step,
00:00
which is our detailed security design.
00:00
Once we understand our functions,
00:00
then we're going to actually put together
00:00
the pieces of that puzzle,
00:00
if you will, that we need to actually build a system.
00:00
Then we get to implementation.
00:00
With implementation, that's what we
00:00
actually build the system and put it into Ops.
00:00
Remember, other operation on maintaining
00:00
a secure operations part of the subdomains.
00:00
Then we across the board assess
00:00
information protection effectiveness.
00:00
We do that in each of the areas.
00:00
We do it after needs, we do it after requirements,
00:00
we do it after architecture,
00:00
we do it after a design,
00:00
and we do it after implementation.
00:00
If you remember anything,
00:00
remember these five terms;
00:00
needs, requirements, architecture,
00:00
design, implement, and then
00:00
draw a circle of assess around them,
00:00
and then you'll be good to go.
00:00
Do that as part of your brained
00:00
up when do you get to the exam.
00:00
There are three principles that I really want you to
00:00
remember from this particular lesson.
00:00
We've talked about it upfront.
00:00
One, you've got to keep
00:00
problem and solution spaces separate.
00:00
If you blend them or bleed those together,
00:00
you're going to have this major problem that's
00:00
called scope creep or,
00:00
as I like to call it in
00:00
many circles, the good idea fairly.
00:00
The good idea of fairylands gives a good idea.
00:00
Everybody thinks it's great, it should be added,
00:00
and it changes the entire requirements that the
00:00
two are working to and you have to go
00:00
back to square 1 in some cases,
00:00
so keep those separate.
00:00
I want you to remember that the problem is the customers.
00:00
Then that's based on
00:00
their mission or their business needs.
00:00
If the customer is, say,
00:00
a manufacturers circuit boards,
00:00
and they walk in the door and say, "Well,
00:00
we want to go ahead and retool and start to
00:00
sell custom sodas, the drink."
00:00
You're probably going to go,
00:00
"But that's outside of your mission.
00:00
That's outside of your business.
00:00
That's not your core thing.
00:00
Why are you going down that road?"
00:00
Another brand, maybe they've
00:00
got a great reason for that.
00:00
But always be wary as an SE
00:00
of requests for things that are really,
00:00
truly outside of
00:00
the customer's mission or business needs.
00:00
Then the last one that I want you to remember
00:00
is the solution space.
00:00
Not the problem space, but the solution space belongs to
00:00
the systems engineer and
00:00
the information system security engineer.
00:00
It's driven by the problem space.
00:00
Same thing where you'd be wary of a customer
00:00
that thinks they need to do something that's
00:00
completely outside of their mission or business area.
00:00
Because maybe it's the soup do shore of the day.
00:00
We want to make sure that you're
00:00
not solving a problem, that A,
00:00
does not exist or solving
00:00
a problem that is outside of the solution space.
00:00
If the engineer or if
00:00
the customer walks into you and says, hey,
00:00
I need a server upgrade and you propel it and you
00:00
come back and propose
00:00
an entire redesign and moving everything to the Cloud,
00:00
you're probably going to get laughed out of
00:00
the building because that's not the way this works.
00:00
Systems engineers and information
00:00
system security engineers
00:00
define their solutions based on the problem.
00:00
But back to the first one,
00:00
you got to separate those.
00:00
Many customers, many folks that are stakeholders,
00:00
they have a tendency to try to get
00:00
into solution space because
00:00
maybe they have something preferred.
00:00
But as an SE,
00:00
you got to stand your ground and say, nope, we got this.
00:00
We're going to solve your problem in
00:00
our solution space based
00:00
on the problem that you have given us,
00:00
and we're going to negotiate,
00:00
we're going to coordinate and collaborate as to what
00:00
the final end result is
00:00
going to look like, so remember that.
00:00
These are the three key principles that if you take
00:00
anything away from this particular lesson,
00:00
remember these.
00:00
In this lesson, we reviewed
00:00
the SE processes we covered here in
00:00
Module 7 and we talked
00:00
about the three key principles you should remember.
00:00
Well, we've wrapped up Module 7, the SE process.
00:00
We're moving on to Module 8,
00:00
the system development lifecycle. We'll see you there.
Up Next
Similar Content
