Welcome back to cyber is it's of course I'm your instructor, Brad Roads. So let's compare systems engineering SC and ISI information systems, security, engineering activities.
So in this lesson, pretty straightforward. We're going to compare SC and ISI activities. We're gonna talk about key documents for each because those are important because we talk about those key documents for several reasons. One, um, you will ultimately right some of those as an ISI, but to you'll probably see them throughout the use of content. And then finally, we're gonna talk about are really important thing,
So there's a couple of charts here that we're gonna talk about when we talk about S C versus SC. So on the left hand side is S E on the right hand side is s e so and discover needs the systems engineer in a a new information management or information security product is gonna be focused on the information management model. The
ISI is going to be focused on the i. P. The information protection policy,
both right, Akane ops. But obviously the ISI is con ups is focused on the security side of things.
We then look at the architecture design, whereas the SCS do that system security architectures and they're looking at the different potential mechanisms that might be used from a security perspective.
Next, we have the next six things we have the detailed design. And obviously the detailed design for an ISI is focused on security on figuring out what are the trade offs components designed, life cycle support, all that stuff lifecycle support. We've touched on that previously, please, is an ISI know that you've got to do life cycle management. Were we struggle with this in the
the cyber security and information security industries in terms of
when should we get rid of systems? And we talked about disposal previously on Decommissioning you gotta factor that in. Um, the next thing we do in both sides of the houses we implement, we're gonna implement that system security. And this is where we're gonna get to that authority to operate or what we used to term certification and accreditation C and A.
And then finally, we're gonna assess. We're gonna assess along the way the information protection, effectiveness, you know, eyes, the system, meeting the CIA, triad, confidentiality, integrity, availability. Are we doing the I triple A identification, authentication, authorization and auditing. Are we doing non repudiation All of those things, right?
Are we doing all of the
information processing that we need to meet mission success for either? It's a system controls, whatever it is, that's all part of what the U. C does there in assessing information. Perfect, perfect protection, effectiveness.
So here's the key documents. This is another one of those charts you probably should memorize for the ESOP exam. You need to know needs. You know, you've got I n N I m m and Mission statements vs I p p You got con apps, you've got
the functional analysis. You've got the requirements, traceability and design and the interface specs, which is the same for both
except obviously, the SCS focus on security. You need to understand that implementation is about test planning and for the SCS risk management framework, we're gonna talk about later, and then finally, an assessment. It's the stakeholder reports that go out from the sea or from the S E. And then for the easy. It's the inner authority to operate the authority to operate that
terminology that we used to call certification and accreditation.
Got to know these documents for the use of content.
So let's talk real briefly about the concept of problem space. This is one of those things you need to know.
principle number one in problem space one. We want to keep the problem space and the solution space separate. Remember, that's super important.
Problem Number two is the customer. Guess what the customer does. They get to tell you what the problem spaces they get to tell you that because they define the mission or business need, that's what they do that's like their role in problem space.
Next principle is the solution space. Who does that? The S E for the entirety of the system and the ISI for the security portions of the system. So
guess who shouldn't be driving
should not be driving the product of the solution space the customer. And that's hard, right? Obviously, especially in like a development model like agile, where you have, you know, customers involved a lot, right. They really want to get involved and get, you know, roll up their sleeves and get their hands dirty and say this is how we want the problem solved. But guess what?
That's not their domain.
They need to be spot on and defining that that mission on business need that problem space. And they need to stay out
of the solution space where you're gonna have problems and then the last one. And this is one that I add is collaboration, Right? So we really need to work hand in glove with the customer, right? So that
no matter what development model we're doing that the customer doesn't think they need to get into micromanage, right? Need to resist the need or the feeling that they gotta jump in and fix stuff that the engineers aren't doing right? Right, that that's a real challenge In complex systems, customers wanna wanna be involved. They wanna
drive the train, so to speak and say the agile model
on those actually strains. But when we allow them to do that right, it muddies the waters. That's where we see scope, creep. That's where we see additional requirements that have nothing to do with the functionality of the system. Get added. And we wonder why we don't meet schedule and cost and scope.
So in this video we compared systems engineering and ISI activities.
We looked at the key documents that you need to know as an S e and S E. And you need to memorize those documents at least for the easy stuff. Then we talked about the concept of problem space and the fact that we that that the the problem space eyes, the domain of the customer and the solution space is the domain of the engineers.
We'll see you next time.