it's been less than 2.7. We're gonna talk about system security plan mentioned a couple times. SSP. You're probably seeing it through organization. This is where all the controls are implemented. That's where you document everything. And it's getting a little bit closer to the data into where you actually see the description of the control implementation.
So in this lesson, you'll learn how to list SSP control components. The different parts of it explain the reason why we need an SSP and differentiate Ness's P and risk assessment.
So for documenting the controls in the security plan. These are These are the parts that important that you need to have in there. You have to have a responsible role for the requirement or with the control requirement. Same,
Implementation status. So we did, they say. Is it in place? We plan on doing it. Are we not going to do it?
Any of the organization to find variables like we saw you define them here in the actual control and say what they what they mean so that when you implement that year that you understand what's what's being done
and some of the actual implementation details are defined in the security plan, and then any of the Hansen said, are important or required for your security categorization. Those need to be in there as well.
One of the obvious things may not be obvious is asked the organization you're working for for a template or if you have a new organization, get the template. You may have a great template that you've used everywhere. Everybody loves it, but you get to the new place,
and it may be sufficient or may work for what they need. But the authorising official isn't used to seeing the data laid out that way. The assessors may not be used to seeing it that way. It just makes life easier. If you're using a common template that everybody orange eyes and everybody accepts again, you may
I have some information that you think is important. They may not think it's important you may be missing something that
the organization really wants.
Here's an example in a lot of tax, but I got all I kind of lied through. Each one of the areas actually got this from fed ramp. This is a template. You are elder. If you want to take a look at. I changed a little bit just to beat, for for this lesson, but it's fundamentally what you need to understand.
So for in the security plan that that hop the same thing, you would say This is I A to user identification and authentication information system uniquely identifies, authenticates organization users or processes acting on behalf of them. You have to do the basic description there,
and then in the first tab or the first section there where the arrow is,
you say, the responsible person or roll. So this would be the Windows administrator is implementing it. The Isis. So maybe performing a continuous monitoring function and verifying that control
the next he would have the implementation status. So this is options mentioned. Is it implemented? Yet? It's partially implemented. Is it planned? If it's not implemented and there's any of those other ones, you're probably going explain why it's in that state. And if you have any plans or what the plans are to do further
control origination, this is you see here is we're starting to pull all these ideas together. So this is where you would say this is a common control. This is a system this is a hybrid and then explain any additional information. If it's a common, here's what's down here. A description at the bottom.
Here's what's provided by the cop by the organization. Here's what I implemented, but the system's implemented,
and then here at the bottom is this is where all the text goes. This is where you is, where the meat of it goes. So
just example of this one. It's authenticator management. I would say the system leverages Windows, native user authentication and access, control all users and given unique user accounts to access the system and no group account. So used
account and password expirations provide additional controls to verify only active users are able to access the system
tryto compass as much as I can there to explain how we implement to control, and if it's already were already using some technology, it's like I said, Windows here explained that you probably need a little bit more in your security plan, but it is good enough to give you an example, for
I understand the control.
The risk assessment is later on in the risk management process, but you didn't need to understand because you're implemented niceness controls and you're explaining how you implement to them. And then what becomes of that? You have somebody that's gonna come by and gonna actually look at these controls and say, Have you implemented them correctly?
we got the box up there that says that weakness was identified. What do I do with it? Now? I am I gonna
acknowledge and say yes, it wasn't done right. We're gonna change the control, retest it and then go back and start over the process. Or you can actually go in the SSP like you saw and say It's a plan, control. Maybe you thought it was our implemented. It wasn't done correctly. So we're now we're gonna create a plan to fix that Delta, or you get to say it's it's open, and we're gonna accept the risk or there some
And this is where the they risk assessor made map a weakness to a control. So they may find something through some automated security scanning tool, anything like that, and map it too. And this control.
And then when you compare the weakness to the SSP control as I mentioned and see if there is some deficiency
and then you associate that risk to that. That weakness and that gets documented in the plan of action and milestones for the poem.