Fundamentals
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. This Cybrary is,
00:00
of course, I'm your instructor, Brad Rhodes.
00:00
Let's get into the fundamentals.
00:00
We're going to talk about four
00:00
>> areas here in this lesson.
00:00
>> We're going to talk about zero-trust architecture,
00:00
which is a term due to or are these days,
00:00
but it's something you need to understand as an ISSE.
00:00
We're going to talk about the hierarchy of trust.
00:00
Trust me, you are going to
00:00
need to understand that for the ISSEP exam.
00:00
We're going to talk about systems engineering versus
00:00
information system security engineering
00:00
and what that means.
00:00
Then we're going to review the security design principles
00:00
that an ISSE needs to understand.
00:00
There 's a list that I'm going to go through,
00:00
but that list is by no means exhaustive,
00:00
but it's the ones I think are
00:00
probably the most important.
00:00
What is ZTA?
00:00
ZTA is the new hot standard
00:00
on the market published in NIST,
00:00
National Institute of Standards
00:00
and Technology Special Pub
00:00
800 tech 207.
00:00
It covers basically the enforcement
00:00
of access to data and resources.
00:00
The construct of ZTA is that you
00:00
should trust no one and nothing in your environment.
00:00
That's really what it comes down to.
00:00
If you want to give people access or
00:00
systems access to resources in your enterprise,
00:00
then you need to have policies in
00:00
place that you can enforce.
00:00
That's done by the center point there,
00:00
the policy enforcement point.
00:00
Really what I want you to remember about
00:00
ZTA from an ISSE perspective is that ZTA
00:00
is all about the accesses and restrictions
00:00
placed on availability and access to resources.
00:00
Those could be data,
00:00
those could be systems,
00:00
those could be compute resources in the Cloud.
00:00
There's many things that this is tied to,
00:00
but it all starts with the fact that you define
00:00
a policy set and ISSEs do a lot of that work.
00:00
Next up is our hierarchy of trust or probably as
00:00
you've more commonly heard, the common criteria.
00:00
This is our EAL,
00:00
so our evaluation assurance levels,
00:00
and it starts at one and goes to seven as being
00:00
the best secured, if you will.
00:00
EAL 1 is that we functionally
00:00
tested something and that's low assurance.
00:00
This gets into that information assurance discussion.
00:00
Then EAL 7 is formally verified,
00:00
designed, and tested, and so
00:00
that probably costs a lot of money.
00:00
This originally came out of
00:00
standards that if you remember from CISSP studies,
00:00
the orange book, these constructs have
00:00
been transitioned to an international consortium
00:00
of which there's many member nations.
00:00
You see it a lot in North America, you see it in Europe,
00:00
you see it in other places really to try to frame and
00:00
standardize how we trust
00:00
systems from a design perspective.
00:00
It really helps us to assess
00:00
the maturity of systems
00:00
and that's what we're talking about here.
00:00
Now let's compare and
00:00
contrast ISSE versus systems engineer.
00:00
This is a process,
00:00
and you're going to find this in I add a 3.1,
00:00
and we're going to talk about that one later,
00:00
so don't worry about that, we will get there.
00:00
But in general, you
00:00
see that we discover needs first in both,
00:00
we look at requirements,
00:00
we look at architecture,
00:00
we develop the detailed design,
00:00
and then we implement this system.
00:00
Well, obviously on the ISSE side of
00:00
the house is information protection.
00:00
It's the system security requirements,
00:00
the system security architecture,
00:00
and the detailed security design, then finally,
00:00
implementing the system security,
00:00
which is those controls that we've put in
00:00
place to mitigate and manage risk.
00:00
Really what you're talking about here is,
00:00
remember how we showed the diagram where
00:00
systems engineering sits over system
00:00
security engineering and system
00:00
security engineering is simply one of
00:00
the disciplines that feeds into the overarching system.
00:00
Well, that's what we're talking about here.
00:00
It makes sense in this case that
00:00
we see the subsets of things that
00:00
an information system security engineer does in
00:00
support of the entirety of a system's engineering effort.
00:00
What is not shown on this slide is really
00:00
the sixth step of the process,
00:00
which is assessing information protection requirements
00:00
from a success perspective.
00:00
When we do that assessment, we're going to
00:00
talk about that in the SE process.
00:00
That assessment is incredibly important
00:00
because throughout the course of this process,
00:00
and I really see the systems engineering process
00:00
and the ISSE processes here as iterative,
00:00
we can stop at any point.
00:00
It's like if you were in the military,
00:00
and you've ever fired a weapon on a range,
00:00
everybody is arranged safety officer and can
00:00
call a check fire. Well, guess what?
00:00
ISSEs and SEs are very much like that.
00:00
Throughout the design and development of a system,
00:00
they can say, hold on just a second,
00:00
we need to re-look at that requirement
00:00
because it is causing
00:00
undue risk or causing
00:00
a problem from a design perspective.
00:00
You as an ISSE or as an SE,
00:00
are very much an advocate for doing things right
00:00
upfront because that ultimately reduces
00:00
costs versus trying to build insecurity at the backend.
00:00
Security design principles.
00:00
There's a lot to unpack here,
00:00
and I'm not going to hang
00:00
out and spend a lot of time on each one of these.
00:00
But there are three that I want
00:00
you to really think about.
00:00
One is simplest solution.
00:00
As an SE,
00:00
you don't want to walk in with
00:00
the most exotic solution ever to
00:00
solve a problem such as locking the door.
00:00
A simple deadbolt might suffice.
00:00
You probably don't necessarily need to have
00:00
the Internet-connected IoT locking thing
00:00
if all you need to do is lock your door and feel secure.
00:00
Simplest solution is always
00:00
best from a security perspective.
00:00
The more complex we make our systems,
00:00
the more likely there is to be
00:00
a vulnerability that can be exploited by a threat actor.
00:00
Second one I want you to think about is obscurity.
00:00
It is not a method. Please don't
00:00
put systems onto the Internet and
00:00
assign them an IP address and don't do
00:00
DNS mapping and think that you're secure.
00:00
Obscurity is not that method.
00:00
I have worked with organizations
00:00
that believe that was the case,
00:00
and it took me all of ten minutes to
00:00
discover their networks and
00:00
show it to them and have them freak out,
00:00
so obscurity is never a method.
00:00
Then the last one we want to talk
00:00
about real briefly is least privilege.
00:00
We as engineers,
00:00
in many cases, ourselves want to
00:00
have access to everything, so we can do all the things.
00:00
Please don't be one of
00:00
those engineers that thinks you need to have,
00:00
be an admin assistant administrator.
00:00
You don't, nor do your users.
00:00
As you design systems,
00:00
you need to design with
00:00
the ability to support least privilege.
00:00
If you don't, again, same thing,
00:00
you're going to leave yourself
00:00
open to a breach or an exposure.
00:00
If something happens to assist them,
00:00
and they get to in a user account that has
00:00
all the keys to the kingdom that should have
00:00
never had those accesses.
00:00
Least privilege is incredibly important from
00:00
a security design principle.
00:00
What do we look at in this lesson,
00:00
in some of our foundational stuff.
00:00
We've talked about ZTA,
00:00
a zero-trust architecture, and why that's important.
00:00
Trust, nothing. We've talked
00:00
about the hierarchy of trust.
00:00
As you are prepping for the ISSEP exam,
00:00
I highly encourage you to go back and look at the EAL,
00:00
the evaluation assurance levels.
00:00
We compared systems engineering
00:00
and information system security engineering.
00:00
If there's a chart you should memorize in
00:00
this particular lesson, that's it.
00:00
You need to be able to draw that chart
00:00
out at from a standpoint of needs,
00:00
requirements, architecture,
00:00
design, and then implementation,
00:00
then ultimately assessment.
00:00
You need to be able to draw that from
00:00
memory when you sit down and take your exam.
00:00
Last, we reviewed the security design principles.
00:00
Clearly not an exhaustive list,
00:00
but a lot of those that you need to understand
00:00
as an ISSE because they are very important.
00:00
By the way, if you don't do some of those correctly,
00:00
you are leaving yourself up to
00:00
a breach. We'll see you next time.
Up Next
Similar Content
