welcome back to CyberRays is. Of course, I'm your instructor, Brad Rose.
Let's jump into verification.
So in this video, we're gonna look at the definition of verification. We're gonna talk about the system security outcomes as related, and then we're gonna apply verification.
So when we look at verification and we've talked about verification before,
let's specifically define it here. It is all about requirements and evidence. So we create a Siris of requirements as disease.
We have to verify that those requirements are met, right? And then we have to have the evidence that shows their Met. So in the case of, say, untrue shin detection system, thean evidence might be the readout of the logs that shows all of the rules that were matched, right. That might be a how we verify the system works. Or
in the case of a piece of hard work,
perhaps it's How long does that hardware operates? A like a smartphone. Uh, you know, we we want that smartphone to operate 24 73 65. So maybe we test the battery that way to see if it means that we're verifying the requirements are satisfied.
So when we think about systems security, engineering outcomes related to this. There's three things I want you to remember. One is. It's not just the systems it Selves, right? We in in Izzy's. We tend to work with enabling systems, and so we have to look at that as well, because the enabling systems make or break sometimes
our security systems.
So we have to look at that from a verification perspective. Very important, right? The second piece I want you to remember is traceability. Um, we have toe have traceable requirements. So earlier in a previous lesson, we talked about a requirements traceability matrix, and the fact that every requirement
needs to be trans means to be traceable from beginning to end
all the way up from the baseline. Bottom things to that systems engineering, uh, starting requirement. Right. So that traceability is very important.
And then last we touched on this the previously but I want to hit her again. Is evidence. Right? Um, I trust, but verify. So if you tell me, something works and you can't show me how it works or why it worked or what work from a requirement perspective. As an ISI, I don't believe it. and so systems engineers and information systems security engineers.
We need to see the evidence incredibly important for us.
verification to an idea system. So, in this case here, we have five requirements this system needs to meet.
Okay, those requirements are not defined here as threshold, minimum or objective. You know, nice toe. Have sort of longer down the road, things we want to have. So we're just gonna assume that all of these are threshold or minimum requirements? Well,
obviously it can do what it needs to do in detecting multiple s is, um it works on all sorts of platforms, which is great. Um, it can detect
those denial of service attacks. But here's the problem. We get down to requirement number four, and it doesn't mean it.
that, you know, content based information. Problematic. Right? Because we're talking about an intrusion detection system that's supposed to be, you know, next Gen 21st century. All that stuff, right? It's not working, right? So one of our requirements has not been verified. And so, in this case here, we might send
if we built this system, we send it back to the drawing board. We send it back to the
previous step to get things fixed, or
or alternatively, if we're buying this, this may be the system that we decide not to buy because it can't meet one of our five requirements we specified as necessary for the system. And that's an application of verification.
So in this lesson, we defined verification. We talked about related system security outcomes you should be aware of, it said, You see, and then we applied. Verification sort of is a practical example. We'll see you next time.