welcome back to CyberRays. Yes, of course. I'm your instructor, Brad Roads. Well, we have made it to the end of module seven, the ISI process, and hopefully you see, or saw how the sip domain support across the process on that, that's what we were going for in this module.
So in this lesson, we're gonna review the process real quick, and then we're gonna revisit those three key principles, and I think you probably remember what they are.
in our discussion here in module seven, we looked at information protection needs, and that's focused on what is the customer really want? What is their information protection needs?
Um, and again, these are the areas that are under the systems engineering process. Think of those. Is the subset focused on security engineering.
Then we defined security requirements. And again, those air narrowly focused mawr on things like security controls, function services, capabilities that are needed.
We then define the architecture, and that's where we take all of those requirements. And we've been them functionally s so that we can more easily handle them as we're getting into the next step, which is our detailed security to design once we understand our functions that we're gonna actually put together the pieces of that puzzle, if you will, that we need to actually build a system.
Then we get to implementation
with implementation. That's what we actually build the system and put it into ops. Remember of the operation and maintaining secure operations, part of the use of domains.
Um, and then we across the board assess information Perfect protection, effectiveness. And we do that in each of the areas. We do it after needs. We do it after requirements. We do it after architecture. We do it after design when we do it after implementation. Um, if you remember anything, remember these five terms needs requirements, architectural design, implement
and then draw a circle of assess around them
on. Then you'll be good to go and do. That is part of your brain Depp when you get to the exam.
So there's three principles that I really want you to remember from this particular lesson, and we talked about it up front.
One. You've got to keep problem and solution spaces separate. If you blend them or bleed those together, you're going to have this major problem. It's called scope creep, Um, or as I like to call it in, many in many circles. The good idea fairy.
Um, the good idea fairy lands gives a good idea. Everybody thinks it's great. It should be at it. And it changes the entire requirements that that you were working too. And you have to go back to square one in some cases. So keep those separate.
I want you to remember that the problem is the customers, right then that's based on their mission or their business needs.
Okay, if the customer is, ah, say manufacturers, uh,
circuit boards, right? And they walk in the door and say, Well, we wanna we wanna We want to go ahead and retool and start Thio sell sodas, custom custom sodas like the drink. Um, you're probably gonna go.
But that's outside of your mission. That that's that outside of your business, that's not your core thing. Why are you going down the road? And now, granted, Maybe they've got a great reason for that, right? But always be wary as an ISI of requests for things that are really truly outside of the customers missions, mission or business needs
aan den, the last one that I want you to remember is the problem. Is the solution space,
not the problem space, but the solution. Space belongs to the systems engineer and the information systems security engineer.
Um, it's driven by the problem space, right? So same kind of thing where if you be wary of a customer that thinks they need to do something that's completely outside of their mission or business area because, you know, maybe it's the soup du jour of the day. Um, you we want to make sure that you're not solving a problem that a doesn't exist
right or solving a problem that is outside of the solution space.
So if the engineer or if the customer walks into you and says, Hey, I need a server upgrade on you propel and you come back and propose an entire redesign and moving everything to the cloud,
you're probably going to get laughed out of the building because that's not the way this works, right? So systems engineers and information systems security engineers to find their solutions based on the problem. But
back to the first one, you've got to separate those right so many, many customers. Many many folks that are stakeholders, right? They have a tendency to try to get into solution space because maybe they have something preferred. But as an ISI, you've got to stand your ground and say, Nope, We got this. We're gonna We're gonna solve your problem
in our solution space.
Based on the problem that you have given us and we're gonna negotiate, we're going to coordinate and collaborate as to what the final and result is going to look like. So remember that these were the three cancer key principles that if you take anything away from this particular lesson, remember these.
So in this lesson, we reviewed the SC processes we covered here in module seven on. We talked about the three key principles you should remember.
Well, we've wrapped up Module seven. The ISI process. We're moving on to module Ate the system development lifecycle. We'll see you there.