2 hours 11 minutes
Okay, so for less than 2.8, we're gonna talk about control assessment and really looking at how to map weaknesses to the MS controls.
So when in this lesson you learned how to state how weaknesses discovered, explain the benefits of the security benchmarks. We've talked about this before. I'll try to go a little bit more in depth what they actually mean,
Examine some of the compliance scans, there's a chance to actually look at the output from them and critique some of the automated tool reports and then map actually map from the weakness found to 853. Control.
Let's just take a quick refresh your hair. Just remember where we are. We're in Step two of the RMF. Step three and four is where we're kind of going now. So step three is was implemented to control and then actually documenting it. And the security plan. Step four is where it's being assessed to make sure you actually did to control correctly or it's doing exactly what you thought it would.
There's an additional 801 60 control volumes for this. For the additional steps uh Set four is 853. A. You'll see it has that same nomenclature is 5353. But it's a test plan. So that miss provided a large document explaining how you can actually providing you test for seizures and how you can actually test the control implementation.
Um One of our other practitioner notes here is make sure you verify the vulnerability applicability. So if you find a weakness, you map it to control.
Don't report it right? I mean, don't put it in the final assessment, put it in to make sure you go and verify that that baseline that are that security categorization and the baseline applies to that control. You mapped it to.
It's not a big issue, but when you're presenting this and you wanna be as professional as possible and you want everybody to believe you, the less risk are the less false positive you get, the less false information, the more you'll be trusted and the easier the process goes.
So it's kind of a rough timeline. Not exactly of what continuous monitoring or the discovery of a vulnerability or weakness is. So you may have that yet. So you have the monitoring process where you have maybe automated tests, manual tests, interviews, review some type of
something happened and somebody realized that we have a delta here, we have some control that says it was implemented. It wasn't actually as we expected it to be.
So the analyst reviews that weakness and then maps it to *** control,
then it gets reported to the ISIS. So whoever is that liaison between the system owner and the security staff.
And then if it is a risk or actual weakness, it would get documented in the poem, which we'll talk about a little bit later and you map to your mapping that risk and then assigning resources to it. And then possibly you may need to update the security plan. So you see this is the life cycle of a weakness, all the tool and actual risk.
So here's an example of a weakness is it's an example. It's it's a failure to properly implement 853 control as we mentioned, and weaknesses are not only technical vulnerabilities. We we think of this a lot of times, as you know, you get automated tool, somebody's missing a patch,
some some Softwares out there very technical but it can also be configuration setting or inadequate procedures, even inadequate policy that
that that our weakness that that they are not properly implementing a control.
And as I mentioned, the weaknesses can be identified through interview document review. These automated tools that are part of continuous monitoring. It may not it could be part of your initial assessment to before you want to begin to your authorization to operate.
Um or maybe it's a continuous monitoring or somebody just finds a control or sorry, a weakness at some point
does someone think despite everybody is familiar with now is vulnerability scans. Where we have these automated tools that run and checks against patches. Mis configurations, They're somewhat related to the operating systems. They bleed over a little bit into the applications are being able to test applications for vulnerabilities,
but there's web app scanners that can do a lot more of the internal controls, like password authorization authorization,
Patches of 3rd Party software, cross site scripting any type of these weaknesses that are then mapped to a miss control. So this would be the way a weakness is found.
Another one is compliance scan mapping. Uh So the organization would define the benchmark. So this isn't, it's not a perfect matching tunis, but it's an addition. It's almost like an overlay like we talked about is maybe you have the like the sTIG or the C. I. S. Or P C I. D. S. S if you're doing credit card processing and you say, you know, here's the control, here's the baseline and then this benchmark, you must follow it and these benchmarks are published, Everybody can see them and you know how to implement them.
And we have these this this escap tools which have the automated ability to go through test them and produce a report.
So, on the next slide here again, this is another slide. This is gonna be a lot of data, a lot of content to look at. Uh But but the reason for it is when you if you ever looked at these automated reports, they are just pages and pages and there's a lot of data you just need to get used to understanding what they look like.
So I got the pencil there so you can reference the material. So this is the this one is a windows compliance mapping or the actually the escap you look I have a sample report of many pages but this is um this is one of of this, is there one that's mapped for CM 112.
See this one is specific to installation options for applications are typically controlled by administrators so they're saying
some non administrator had the ability to install software.
Again, this one was helpful because it has its own
that's the I. D. There. But they provided the mapping and they were good enough to provide 100 53 give the rev number and the cm 11 and enhancement to.
So what I did was go pull out from the 853 the actual control for CM 11. So you can see how this tent maps. So you can see this one's called user installed software. So we see how that mapping of a non administrator was installing software. So this looks good that this mapping is seems to be correct so far.
And then down at the it was enhancement to which says user in salt software prohibited installation without privileged status. So this this one seems like a good match. So we would say they failed this control. And here's how it maps to the actual miss control.
Here's another example. This one is uh uh Lennox escap. So this one is about disabling the automatic bug reporting tool. So you can see this
if you didn't if there's more information about it. But what this says is there's a bug reporting tool, something happens. Some information gets sent off somewhere to the the author of the software someplace and your organization may not want this data going out that you don't know what it is.
And so you can see again the complexity here, this control has been mapped to lots of different, lots of different controls. Most of them are not missed, but I highlighted in right there in the box that we can see those are obviousness control. So it's saying this applies to a C 17 enhancement eight and CM seven.
And when I go back to the Nist document 18 53 I look at a C 17 where I'm pointing to right here, A C 17 enhancement eight and you see at the bottom it says withdrawn incorporated into CM 11.
So this is what I was saying, it's very important to verify control mapping. Don't just put it out there. This one's probably it's not exactly incorrect but it's been withdrawn
But I would I would just map this two, CM seven. I wouldn't say both of those when they actually report the control.
So here is the CM seven from 853
and this is about least functionality. It's just configure, it configures the information system, divide only essential capabilities. This seems to make sense. It's generic enough but it but it has the specific information that that we need, that there's some software running that's not needed.