welcome back to CyberRays. It's of course I'm your instructor, Brad Roads. So let's look at the next step in the process. And that is define system security requirements.
So in this lesson, we're gonna talk about the SC toss tasks. We're gonna talk about source documents again, we're gonna talk about the output to the requirements to come out of this particular step.
So getting out of buyout of 31 their art
five tasks that in ISI does when they're defining system security requirements.
One they're gonna coordinate with customer should go without saying
to they're gonna work with the systems engineer. Okay, So again, remember that information systems security engineering is a subset apart of systems engineering for a much more complex system, right? We're gonna do requirements analysis here, So that means we're gonna gather all these requirements in the questioner coordination peace, And we're going to
and analyze what we've done in developing the systems requirements related to our information systems. Security
controls, everything that we're going to do as far as information security for a system, we have to, you know, develop those requirements in coordination with customer. We have toe analyze those requirements and then probably, I would say, one of the most important or the very. The most important step here is requirements tracing right. We have to trace those requirements from,
you know, the systems engineering
requirement that they came down from the systems engineering element they came down to into our information systems security,
engineering requirements. And then we have to track them all the way down through functional analysis to those product things that we're gonna be developing. We have to be able to trace requirements because that's how we're going to test them, ultimately, to see if they are actually been met in terms of what we've developed.
So source documents here. Well, one is the system context. So we've talked about context before, Um, in terms of in terms of information systems, security, engineering, right, that's the boundaries and interfaces. We know that if we're going to connect a system to the Internet, there's gonna be external boundaries.
Those connection points out, there's gonna be internal boundaries between different say modules within the system so we can understand that next we need a user perspective, right? And that comes from what it comes from. The concept of operations document or other online documentation. You might have gathered about an organization if you're not dealing with a government entity,
and then the last right is this system requires the system requirements themselves. Remember SC's work in that subset of system security engineering? And so the system Requirements document probably has some great things that we should look at two in terms of understanding. What
is the system supposed to do at a top level, so that when we build the security requirements for
we're not building something that doesn't work for the entirety of the system
additional eso? Here's the outputs of our requirements. So when we're talking about the information systems security requirements here for our system, right, developing those right, we've got the outputs right. We've got the requirements themselves. What's the system or the components of the modules or whatever supposed to do?
We have two kinds of requirements that you need to remember. We have minimum. We have. We have minimum and stretches, so we have what we call threshold requirements. That's the bare minimum that a system has to do, or or a module or whatever,
and then we have these objective requirements That's like a stretch like e can get there. That would be great. So a minimum requirement might be that a system operates 24 7
3, 65. And an objective requirement might be that the system has 9999 So five nines availability and Onley goes down for scheduled maintenance. Right? So that sounds like an awesome objective requirement. But at a minimum, the system's gonna operate 24 7. OK,
then we look a functional requirements, and that's quantity
quality coverage time that isn't availability. Right? So when we think about functional requirements here we're talking about what is the system actually going to be made up of, right? I need eight widgets, right? Um and those eight widgets can be manufactured overseas or that can be manufactured in the United States. Right.
What timelines do I need? When is the thing When when when is the system and the functionality and the modules supposed to be a field?
Another output of requirements. Here is the traceability. We have toe link all of our requirements back to the main system, right. We are building incredibly complex systems, and those incredibly complex systems mean we need to map everything from our information systems security requirements all the way back up to where they track into the system itself.
And then we need to look at constraints and constraints or one of those things that
we have zero control over. Um, and constraints come from what
they come from cost schedule in scope. Right? So if we're told you could spend $10 on that widget,
we can't go beyond that. And so what does that do to our widget? That means our widget might not be the best. This greatest widget ever that we wanted to buy It may be the widget that we need because that's what we can afford, right? We might be told we need to You're not gonna developed. I think you're gonna buy it because we needed online in a week. Well, guess what? That's a constraint,
right? From from a scope,
perspective and a schedule perspective. So keep those in mind that these air the outputs of requirements.
So here's my my little anecdotal story for you. If you don't take the times Thio, get your requirements right,
tree swing, right? And this is a famous systems engineering, uh, diagram or chart. It has been shown in probably every systems engineering book since the since the early two thousands.
Right? Customers come in and say, I want a tires one
right? The client says. I want, you know, a tire swing that's got a pillow and yada yada. The engineer designs to do a certain thing because they didn't clearly hear what the customer wanted, and then the manufacturer built it based on the requirements that they were given. And so it's kind of funny and kind of cheeky, this particular chart. But
I have seen systems in real life where the customer said, I want
a notebook that Aiken right on with the pencil on what they got was a tablet that cost, you know, a digital tablet that cost $100,000
right? That that's like an extreme example. But that happens all the time. And so good requirements, right? Solid requirements, well understood requirements in this area, right? Help you to save not only your organization money, but your organization time and get this scope right so that you build
the right product or service or capability out of the gate, as opposed to having to go back
and redo it multiple times.
So in defining system security requirements, um, we're going to develop the system security con ups and the baseline system security requirements. That's what we're doing here, right? So we're taking all of those things those needs and we're allocating them functionally into the sets of requirements that we're going to build. Two were eventually built Thio.
So in this lesson, what do we cover? We looked at ISI tasks. We talked about source documents. We talked about this specific outputs and requirements. And then we talked about a brief example of you know, if you're gonna build a tire swing, make sure you build a tire swing and not something that doesn't look like a tire swing.
We'll see you next time.