Welcome back to CyberRays. This, of course. I'm your instructor, Brad Roads.
Let's get into the fundamentals.
So we're gonna talk about four areas here. In this lesson, we're gonna talk about zero trust architectures,
which is kind of a term du jour these days. But it's something you need to understand. As an ISI, we're gonna talk about the hierarchy of trust. Trust me. You are going to need to understand that for the exam,
we're going to talk about systems, engineering versus information systems, security, engineering on what that means. And then we're gonna review the security design principles that an ISI needs to understand. And there's there's a list that I'm gonna go through. But that list is by no means exhaustive, but it's the ones I think are probably the most important.
So what is Z t? A SOS e T. A. Is the new hot standard on the market, published in NIST National Institute of Standards Technology Special Pub 800 Tack 207 And it covers basically the enforcement of access to data and resource is and so the construct of Z t A.
you should trust no one
and nothing in your environment, that's really what it comes down to. And if you want to give people access or systems access to resource is in your enterprise, then you need to have policies in place that you can enforce. And that's done by the center point there, the policy enforcement point. And so really, what I want you to remember about Z t A from an ISI perspective
is that Zita is all about the accesses
and restrictions placed on availability and access to re sources. And those could be data. Those could be systems. Those could be compute resources in the cloud. There's many, many things that this is tied to, but it all starts with the fact that you define a policy set and issues do a lot of that work.
Next up is our hierarchy of trust, or probably is you more commonly heard it. The common criteria and this is R E A L s R evaluation assurance levels, and it starts at one and goes to seven is being the best, uh, secured, if you will Yayo. One is that we functionally tested something, and that's low assurance.
This gets into that information assurance discussion and then e a L seven is formally designed,
verified, designed and tested, and so that probably cost a lot of money. This was originally came out of standards that if you remember from C. S SP studies three Orange Book has been transitioned. These these constructs have been transition to an international consortium off which there's many member nations, right? And so
you see it a lot in North America. You see it in Europe, you see it in other places,
really, to try to frame and standardize how we trust systems from a design perspective. Um, it really helps us to assess the maturity of systems. And that's what we're talking about here.
Now let's compare and contrast iSi versus systems engineer. So systems engineers and this is a process. And you're gonna find this, uh, in I added 31 and we're gonna talk about that one later. So don't worry about that. We will get there, but in general, you see that we discover needs first in both,
we look at requirements. We look at architecture, er we developed the detailed design and then we implement the system
Well, obviously, on the side of the house is information protection.
It's the system security requirements, the system, security architectures and the detailed security design. And then finally implementing the security, the system security, which is those controls we put in place to mitigate and manage risk. So really, what you're talking about here is remember how we showed the diagram where systems engineering
sits over system security, engineering and system security? Engineering is simply one of the disciplines that feeds into
the overarching system. Well, that's what we're talking about here. And so it makes sense in this case that we see these subsets of things that an information systems security engineer does in support of the entirety of the systems engineering effort.
What is not shown on this slide is really the six
step of the process, which is assessing
information protection requirements from a success perspective. And so when we do that assessment, we're gonna talk about that in the process. That assessment is incredibly important because throughout the course of this process, and I really see the systems engineering process and the process is here as iterative,
we can stop at any point. It's like if you were in the military and you've ever you know, fired a weapon on a range.
Anybody? Everybody's arranged safety officer and can call. Ah, check fire. Well, guess what?
Um yes, es and s Cesaire very much like that throughout the design and development of a system they can say Hold, hold, hold. Hold on just a second. We need to relook that requirement because it is causing undue risk or causing a problem from a design perspective. And so you as an ISI or as an scr, very much an advocate
for doing things right up front
because ultimately reduces costs versus trying to build in security at the back end
security design principles. There's a lot to unpack here, and I'm not going to hang out
on and spend a lot of time on each one of these. But there are three that I want you to really think about.
One is simplest solution.
you don't want to walk in with the most exotic solution ever to solve a problem such as locking a door.
A simple deadbolt might suffice.
Uh, you probably don't necessarily need to have the internet connected I ot locking thing. If all you need to do is lock your door and feel secure. So simple. A solution is always best from a security perspective. The Mawr complex. We make our systems, the more likely there is to be a vulnerability that can be exploited by a threat. Active
second one, I want you to think about his obscurity. It is not a method. Please, please, please don't put systems onto the Internet on assigned them an i p address. And don't dio DNA's mapping and think that you're secure. Obscurity is not that method. I have worked with organizations that believe that was the case, and it took me all of 10 minutes to discover
their networks and show it to them and have them freak out.
So obscurity is never method.
And then the last one we want to talk about real briefly is least privilege, right? We as engineers. Right. Um, in many cases, ourselves want to have access to everything so we could do all the things.
Please don't. Please don't be one of those engineers. The things you need to have being Adminis system administrator. You don't, um, nor do your users, right. Please. As you design systems, you need to design with the ability to support least privilege. If you don't again, same kind of thing. You're going to leave yourself open to a breach or an exposure. If
if something happens to a system and they get two and a user account
that has all the keys to the kingdom that should have never had those kinds of access is so least privileges incredibly important from a security design
So what do we look at in this lesson in some of our foundational stuff? We talked about C t A zero trust architecture and why that's important. Trust nothing. We talked about the hierarchy of trust
Aziz ur prepping for the S IP exam. I highly encourage you to go back and look at the e a l the evaluation assurance levels.
We compared systems, engineering and information systems security engineering. If there's a chart you should memorize in this particular lesson, that's it. You need to be able to
draw that chart out. Uh, from a standpoint of,
you know, needs requirements, architectural design on, then implementation, then ultimately assessment. You need to be able to draw that from memory when you sit down and take your example
and last we reviewed the security design principles. Clearly not an exhaustive list, but, ah, lot of those that you need to understand as an ISI, because they are very important. And, Oh, by the way, if you don't do some of those correctly, you are leaving yourself up to a breach.
We'll see you next time.