Objectives and Generic Systems Engineering (SE)

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 58 minutes
Video Transcription
Welcome back to cyber is of course I'm your instructor. Bread roads.
Let's jump into module seven of 10 information systems, security engineering process.
So where are we on the ISS Ip journey? Well, we are more than halfway through, and we have made it to module seven. And this is what we're gonna talk about? What it means to be an ISI and work through the process is that it sees do on. Then we'll move on to modulate and talk about the soft, the system development life cycle, not the software development life cycle.
Eso Let's jump on in.
We're going to cover our module objectives and generic systems engineering in this particular lesson. And then we're gonna look at why is he and why is he's air so very important today when we think about the complexity of systems that we see out in the product space?
So here's our module objectives. We're going to review systems engineering. We're going to compare the systems engineering efforts to the information systems, security, engineering efforts.
And then we're gonna investigate the six steps in the ISI process. And these six steps are framed in something called the I at if we're gonna talk about that in a little bit, because it's very important that you know that document for the ESOP content and the exam itself.
So here is a view of generic systems engineering. It's pretty straightforward. It is a linear process with a little bit of circular effort to it. You can do some revisits, depending on how you decide to do your development model. If you're doing obviously agile or spiral, you're going to see this Mauricio richer than not
so in generic systems engineering. We start by discovering the needs what's needed. What are we? What are we supposed to do? Um, then we take those needs and we define system requirements system requirements, then bleed us into the system architecture itself. We have to design that that we develop a detailed design implementation,
and most importantly, we then
assess effectiveness. And if you see the arrows that come out of each of these, we can assess effectiveness throughout the course of each of these steps in the generic systems engineering process.
So here's another view of this of systems engineering, and this is from Department of Defense, 5000 dot to ours. A little bit older reference, but it comes out of the I add of which we'll talk about, um and really, what we're talking about here is what happens in all of our systems engineering processes. We taking input from the customer. We do requirements, analysis. We do
allocation and functional analysis. We do synthesis, which is
taking the architecture and actually determining either the preferred products or building them the external and external interfaces
on. Then we do that outputs process where we say, Hey, here's what we decided What were the decisions we made? And so this is another way to look at systems engineering from a top level. But you're going to see things and you've seen things we've talked about before. Tradeoff risk management configuration management. All of those things that we talked about in the
Issa domains leading up to this are
here in that generic systems engineering process.
we've come up to a really important question as we have progressed through the ESOP domains and now we're talking about the SC process here in module seven. Why do we do information systems, security, engineering? While there's four main reasons one
we're dealing today with incredibly complex systems and the Mork complexities systems get the.
But more important is to do that system security engineering upfront. Ondo. By the way, these these networks and systems and applications and in machines they're not getting any less complex. They're getting more complex. We're adding more and more functionality throughout the process.
Um, it early integration. If we are not integrating our
our security processes and security controls that it sees build out and design and develop early in our system, we're gonna add a lot more expensive. It is a whole heck of a lot more expensive to add or bolt on. Security is a Band Aid after you've deployed a system than it is to do it up front in our design.
Um, if he's air focused on the customer, we don't do systems engineering or information systems, security engineering without a customer or focus on them if we do. If we don't do that, we're not doing it right.
And then last, is Cesaire super important for risk management? We have to identify that risk as a continuous process throughout the information system security engineering process to ensure that we aren't creating problems that's down the road that we didn't think about. And this is why it's so important to do is see through out and do this process through
out our systems engineering and information systems,
security, engineering work.
So in this lesson, we talked about our module objectives. We've got a lot to cover here in module seven. We talked about generic systems engineering to views of that. And then we talked about why you Cesaire so very important
We'll see you next time.
Up Next