5 hours 58 minutes
Welcome back to cyber. Is this? Of course I am your instructor, Brad Roads. So we talked about verification. Now, let's talk about validation
in this lesson. We're gonna define validation. We're gonna talk about what validation should demonstrate, and then we're going to apply it in related to our I. D s example we talked about previously.
So what is validation? Validation is all about fulfillment, not personal fulfillment, but fulfillment in the sense that are we going to meet the business or mission objectives using whatever product we're talking about, right? In the case of our I. D. S example doesn't meet the mission or business objectives. If it does, then
we will likely validate
that system or control. Um, one of the things you want to think about here is that validation also looks at Does these systems or do these systems operate or function correctly in the operational environment for which they were designed to? Sometimes sometimes they don't. And sometimes we find that
there isn't the right level of trustworthiness. So if you remember the
evaluation assurance levels we talked about earlier that maturity construct their when we're looking at the common criteria. If we don't meets a certain trustworthiness levels in terms of our mission or business objectives, right? We might decide not to validate a product, which means we've probably wasted money.
So when we talk about security validation, right, we're looking to see if we're dealing with, uh, disruptions, hazards and threats, Right? In general, we're talking about risk mitigation. Here does the thing. The control, the system, the element, the module, whatever it is, does it
achieve those objectives to do what we said it would do to mitigate that risk?
Right. We look at the context of the operational environment in detail. If we have say, Ah, smartphone. And that smartphone shuts down when it hits zero degrees Celsius, that's, ah, problem, right, Because most people want their smartphone toe operate wherever they are in the world and sometimes on the top of Mount Everest,
Um, and then last right. It is very possible we've talked about this multiple times. So this is probably something you should remember for the use of content is
it's possible that you can verify something, but still not validated
Andi and again potentially have wasted money.
So when we apply validation, we think about our ideas. So let's assume that our ideas, those five requirements that we have all met, they were all completed. They were all good. No problem there. However, when we go and put the system into test,
it won't run 24 7 and our business and mission operations, right? We have a 24 7 shop, and so we can't have downtime except for maybe scheduled maintenance stuff. But this thing is this ideas that we think is going to be the solution to all of our problems. This intrusion detection system,
it's offline more often than it is actually operating.
yeah, it met the requirements
right to do what ideas does. But it certainly does not meet the mission need off 24 7 coverage. Which means that if it was me as the C, I would not validate our ideas that we've talked about in our example.
So in this lesson, we define validation in in in depth. We talked about what validation should demonstrate, which is helping us toe, you know, truly mitigate those risks, and does it actually meet the mission need? And then we talked about the fact that sometimes when we validate a system we might actually validate. We might verify everything. Well, we might not validated.
We have to walk away, and that's not a good place to be.
But hopefully, if you've done good design work out front is an ISI. That won't be a problem.
We'll see you next time.