moving onto domain 14 security assessment. Now, I may have misspoken earlier. I think that I had mentioned one of the earlier,
uh, requirements was the only one toe have no derived security requirements. That actually was wrong. Ah, security assessment also has no derived security requirements. So here we would just look at the basics. So when we talk about security assessment, uh, this goes hand in hand with risk control, right?
Uh, with risk assessment were continuously monitoring
and making sure that our systems are in line with the current risks based on our cost benefit analysis. So we have three basic security requirements. First of all, we're gonna periodically assess the security controls organizational information system to determine if the controls are effective
in their application.
right? Part of what a vulnerability assessment is. Are the proper controls configured? And are they working? Are they sufficient? So periodically? Now, again, this doesn't necessarily lock down and say once per quarter or once per
twice per year, whatever. But ultimately our organization needs to me and they just standard
with which we apply. So we're gonna periodically assess those controls and to make sure that they're working, make sure they're effective.
And then we're going to develop an implement plans of action to correct the deficiencies and also to reduce, or at least eliminate, these vulnerabilities that we were able to detect. So here again, we should already have these plans in place, at least the foundations for them.
So was we determined? Maybe a system. Uh, we're getting ready to certify a system,
and it fails one of the security assessments. Well, there should be a plan of getting this system back on track, correcting the problems that air there. Ah, and making sure that we're able to respond in a more positive fashion for the next series of tests. You know, one of the best ways to incorporate this
is to build security
into the design of a product, one of our later Siri's in mist. We're gonna be talking about, um,
this systems engineering process and how we build security into each stage of the system engineering process, and I think that's gonna be very significant. Ultimately, we're gonna build a system to pass the security assessments because that's, you know, ultimately what we want to do is to build a secure system
rather than to build a functional system that we secure later.
So ultimately, what I was getting at with that is you know, this process is much easier if your system is secured by design,
all right, and then the final basic security requirement we have to monitor, right? So the first bullet point, we're going to assess the security controls, make sure they're effective.
Second point is, we're gonna make corrective action plans in case the controls are not effective. And then the third basic security session dissection or, um, security assessment piece is monitor. Make sure on an ongoing basis. Just because the system passes the test today
doesn't mean it's gonna be resilient or,
um, or trustworthy tomorrow. Right? So we're going to continue to monitor those systems. So this is short session section on security assessment.