1 hour 45 minutes
Hi and welcome back to the risk management framework for executive management were on less than 2.2 implementing the proper controls.
So are learning objectives for this is going to be where the implementation step fits into RMF and discussing what it means,
what tasks are associated with the implementation step
and what executive leadership can do to support successful implementation of those controls.
So when we're talking about implementation, we're going to go through the definition from the Nist sp 837.
The purpose of the implement step,
the purpose of the implement step is to implement the controls and the security and privacy plans for the system and for the organization and to document in a baseline configuration, the specific details of the control implementation. And then we're gonna go through some of the tasks as well. So why is this important?
Well, if we don't implement implement the controls,
then we've selected them. We haven't actually done anything with them. So we need to make sure we're implementing the controls, but we need to make sure we're implementing them properly. That word is going to come up a lot too.
Making sure that the controls are implemented in a way that we're securing our our environment in our systems.
So our implementation tasks that's going to include control implementation as well as update implementation information. So when we're looking at our control implementation, these are going to be specified uh from the previous step and then we're going to implement them.
So we're gonna use engineering methodologies to implement these controls.
And when we're talking about updating the implementation information, any changes that might occur to your system, so any time a group policy has changed, anytime you're adding new software, anytime you're changing registry keys. Uh This is a good time to make sure that we're documenting those properly.
And at the same time our security and privacy plans would be updated as well.
Control implementation. So some of your potential inputs, you may have more. You may have less depending on how big your organization is, but this is going to include approved security and privacy plans. Any system design documents
your security, architecture and inventory. I can't stress enough how important it is to have a really solid inventory knowing which systems you have, what hardware, software, all of that in an inventory,
your list of security and privacy requirements as well as organization and system level risk assessments. Those are all going to go into all those inputs are going to go into successful implementation of controls.
Um so obviously are expected output is we're actually gonna put the controls in place. We're actually going to apply them to our systems, whether it's with group policy, local security settings. However, we're going to do that, we're actually going to implement those controls.
So the primary responsibility really is going to be on the system owner, but they're going to have some supporting uh supporting roles with the security and privacy architects as well as privacy officers. Any engineers or administrators. They're really going to be the ones that are implementing these controls are going to be adding the settings to group policy or
making sure that those systems have their local policies changed.
Um, so some real world examples for control implementation, there's a lot of really great best practice guys out there from Microsoft, Citrix, Sysco, any applications or software that you might be adding your hardware. Uh There's a lot of really great best practice guides you're also going to have, depending on which organization you're using, you might have um,
laws and regulations that you need to follow,
but there's great places to start when you're implementing controls, um and if you have support with them, you can always use them to um to figure out if you're implementing the controls properly.
Uh So common controls were talking about that. We're thinking about group policy at the domain level or ou level. So for your organizational unit, if you're using A D um and then local security policies added to baseline images,
you know, I bring this up because uh it's great to have a baseline image, you know, something that, you know, is secure and when you're adding things on afterwards, you know, that you have a secure base line and you can add from there.
Um so you may not have the option to implement controls if you're using SAS software as a service. So that's going to need to be evaluated differently. And again, as you'll see as we go through this, the framework is really meant to be tailored to whatever size system you have or whatever size organization you have,
um and you may need to consider supplementary or compensating controls if implementation does not go well. Uh you know, we'd love to live in a world where implementation goes well and everything goes great, but things do happen sometimes we have to tailor those controls that we've implemented and make sure that
we didn't break anything and if we did, let's roll it back, let's figure out what happened.
Uh So it might be important to consider some other control if one of them doesn't work out
So what should my inputs be for the control implementation?
What should my inputs be for the control implementation task.
So we're gonna go back here, we want to make sure
that we have really the whole architecture, again bringing up that inventory, security and privacy plans. We really want to get a whole sense of the organization, what's going on? How many systems do we have?
Everything so we can take all of that and figure out how to implement the controls properly.
Okay, so now we're going to update the, update the control information information.
So when we're talking about potential inputs for this, we're gonna be talking about security and privacy planes again, as well as any information from the implementation steps. So if there was any documentation or anything is found along the way, we'll be adding them into this update control information
with the expected output. That security and privacy plans will be updated
um should be used by any assessors when they're assessing the system uh that we're going to talk about later um in any system baselines that should really be where we we've implemented these uh we've implemented our controls, we have our baselines. Now, let's make sure that's documented and that we can use that going forward.
So the primary responsibility for updating this control information is really going to be on the system owner
with support from any systems engineers, security and privacy architects, uh Systems administrator, anyone who's technical and maybe hands on, but probably going to be helping to update that documentation or make sure that they're giving the proper information to update that documentation.
So when we're talking about updating the control information,
it's important to know that when you're implementing controls,
it doesn't always go to plan and that's okay. And especially as an executive management, you know, they're going to be time when projects are project managers come up and say,
um you know, I we tried to implement this, we couldn't but we're going to try to do this instead. You know, things change. We've got to always evolve as projects are evolving uh and security and privacy plans should be living documents, so they should be updated constantly, always having eyes on. And as our environment changes, we add new
servers or applications or software that we should be updating those plans,
planned inputs should have expected behavior and outputs. So making sure that we plan and prepare, that's going to help us having the expected desire and outputs for these tasks
as implemented is essential that it's really important because that will determine what changes are made and how they're made.
Um Changes must be authorized. System owners should always be involved when things are changing or if the system after the system is authorized.
You know, we got to make sure that we're making what we're implementing those steps that they are implemented properly.
Uh and we need to determine the potential impact of any changes. So if we tried to implement those controls the first time and it didn't work out if we're changing route and we're going to implement something else, let's figure out what impact that has on our system. Are we increasing risk if we are, how do we lower that
Uh So what should be my outputs for the update control task?
So we're gonna go here are expected outputs we really want to have, I'll harp on the system baseline because that's really going to help us figure out where we're starting from. We can always update and add things later. But knowing where we're coming from and understanding the risk of the base will help us address risk and understand risk as we go along.
So some of the main takeaways for executives be adaptable things are gonna change. Project managers, System owners, see IO may come and say, hey, we had to change some things, you know, at risk level is a little different than we thought it was.
It's going to change. But we may also be able to add compensating or supplementary controls to address those.
Some risk assessments may point out controls which are not applicable to a certain Western type of device. So this is where we may get false positives or something that's not really applicable. It's like, oh, I've got this control, but it's really for this device or this type of firmware. Maybe it's not for this update. So it's just understanding that we need to adapt and try to figure out if it makes sense for our baseline,
seek advice from security professionals. You know, it's always um,
if there's a certain level of risk that you're not comfortable with or certain control maybe you're not sure about, you don't understand what risk it really poses to the system. It's always good to get that advice. Um and a security liaison can make this process easier, so having someone that can work with between security and I. T. Infrastructure,
uh they could give a better idea of what's going on and what those controls mean,
um and how to implement them properly or how to move in a different way.
So in today's video we talked about what the implementation step in RMF means. We talked about which tasks are associated with the implementation step.
Um I also talked about some real world examples of how controls are implemented and how we might need to adapt as we go along and then why this is important for executives to know