3.1 Lets Get that ATO!

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

1 hour 45 minutes
Video Transcription
Okay, welcome back to risk management Framework for executive management. This is less than 3.1. Let's get that 80. Oh, let's get authorized.
So are learning objectives in this video? We're going to learn where the authorization step fits into the RMF process. We're going to learn about what tasks are associated with the authorization step,
as well as what executive leadership needs to know before authorizing a system. So this is going to be a really big crucial step to executive management.
So the definition of the authorization step from the Nist SP 837.
The purpose of the authorized step is to provide organizational accountability by requiring a senior management official to determine if the security and privacy risk, including supply chain risk to organizational operations in assets, individuals, other organizations or the nation based on the operation of a system or the use of common controls is acceptable.
So authorization tasks, all these tasks are required to complete the authorization step. There should be an authorization package and we're going to talk a little bit more about that risk, analysis and determination what the response is going to be to that risk
and then our authorization decision and then we're going to report on it. What's our authorization reporting?
So our authorization package, we're going to assemble the full authorization package and submit to R. A. O. For a decision.
So our potential inputs there may be more. There may be less depending on how big your organization is are going to be. The security and privacy plans are assessment reports and again, poems or any other supporting evidence that might help our case
with the expected output of having a full authorization package. So it's going to include our executive summary. So to give highlights about what's our risk, what are we looking at for the system and we can do that using a security management tool. There's several on the market and um, there are a lot out there that you can choose from.
So the primary responsibility is going to follow the system owner
and potentially with the common control provider again, depending on which solution you've chosen in which organization you're with.
So the supporting roles you may need help from security and privacy officers, senior agency, information security officer. So someone who's in your information security branch and even your control assessor might be able to help with this.
So we're talking about analyzing and determining risk. Uh we're going to take that from the operation or use of the system in any common controls
so our potential inputs, we're going to take that authorization package that we took in a first step. Any other supporting evidence that might be important to understanding the risk of the system as well as our risk management strategy and tolerance for risk in our organization
and then the intended intended output is to have that risk determination yet or not? Yes, I'm okay with it or no, I'm not. We need to go back and fix some things.
So the primary responsibility here is gonna fall on the AO. They're really going to have to be the ones to say
yes. This is OK. I accept this risk or no. Let's go back to the drawing board. Let's figure out how we can lower risk a little bit more before I accept this
with supporting roles from some other executives. Risk management executives as well as senior security and privacy officers. Um and maybe a risk committee, we mentioned that in one of the previous lessons that it might be great to have a risk committee that could come in and say,
you know what, this is acceptable risk. You guys are okay based on the system classification or categorization.
So risk response, uh we want to identify and implement a course of action to determine our risk. So we need to figure out what risk are we really talking about and how are we going to respond to it?
So our potential inputs are going to be our authorization package are risk determination and then our risk assessment results. So we're going to be talking about pulling again all of that information from our previous tasks uh into that output, which is our risk response. And there are several different ways that we can respond to risk. We can accept it, we can say, yep, that's fine. Let's move on
avoidance. We can avoid that risk. We can say, you know what, I'm not going with this product or you know what, I'm just I'm not going to do with that transfer. There's a risk insurance, security insurance that we can look at that. You know, maybe we can transfer the risk to them or mitigation. Maybe we need to go back and do another assessment. Maybe we can mitigate some more risk.
So your primary responsibility again is going to be on the A. O. Or someone that they designate uh with your supporting roles. Again being risk management, executive security and privacy officers,
the system owner, they're going to need to be involved. Maybe provide some support
as well as any security and privacy engineers who again might be able to provide some technical expertise
quiz. How many options are there for a risk based decisions?
Uh So there are a lot, there's a lot of different ways that you can go with risk. When we go back here, we're looking at um accepting, avoiding transferring or mitigation.
You know there's more than that. You can um You can really look into risk response and risk mitigation. There's a lot of different ways that you can do this. Uh And there's a lot of different tools that you can use to help. Um And your security team should be able to help provide more support in that to giving you options for how you can respond to this risk.
Okay so now we're going to talk about our authorization decision so we need to determine if the risk from the operation or use of the system
is acceptable.
Uh So are inputs are going to be the risk responses that were determined in our previous task
with our output. So there are several different outputs that you can have. Um You can authorize a system to operate A. T. O. Good to go. I'm happy with it. I accept the risk authorization to use um I've seen this 1 80 you so you can use it. But um you know, we're not quite sure if we're okay to put it into production,
an authorization to test, that's your, you know, we can run pOC we can try it out. Let's see what we think. Um And then if we don't like it, we can just say you know what, we're not going to use it. Or then you could go through and then get your A. T. O.
Or you can deny it. You could say you know what you guys didn't fix enough. I'm not okay with this risk, I'm not using it.
So the primary decision is really going to fall on that day. Oh they're going to be the ones to say ultimately I accept this risk or I do not and I'm not going to sign off on it. I've seen it before where um, you know, it comes to that 80 oh and that a T. O. Package just does not get signed. Things have to be fixed before they're willing to accept that risk.
So supporting roles, you're going to have some of your risk management executives along with your senior privacy and security officers um and any designated representative for the AO, they might help out with uh deciding if this risk is okay.
So quiz who has the ultimate and final decision to allow a system into production or deny it from use?
Again, That's our a, oh, that's our authorizing official. They're the ones that ultimately and as executive management can say yes, I'm okay with this. Let's put the system into production. You know, it's worth the risk or hey, you guys have mitigated enough risk. I'm comfortable with this. Uh, you know, knowing at the end of the day that we can't fix everything, we can't mitigate all risk.
Okay, so now we're coming to authorization reporting.
So we're going to report authorization decision or deficiencies, which represents significant risks to the organization or the system
depending on what you're doing.
So the inputs are going to be that authorization decision
and then you're going to take that output report with your decision for system or your common controls as well as authorization status in the system registry. So you're saying yes, we authorize this or no, we do not. Um, and you're really documenting that.
So your primary responsibility. Again, it's gonna be the A. O or the designated representative,
the authorising official. Obviously the step has the most impact and the, the biggest job here
supporting roles again your system owner, your information owner, your system and security privacy officers as well as um any senior level security privacy officials might help out as well.
Alright, so executive review.
So some of the most important points for executives from the authorization step um authorizing or denying uh these systems can have an impact on budget or projects. So it's really important when you're weighing risk to think about what does this mean to our organization or other ongoing projects, are we going to have to delay other things if we don't authorise this?
Um and that implementing security from the beginning of project can save additional time at the end of a project in budget and resources uh using the RMF steps,
the system can be authorized properly and securely. You know, you really know what you're getting when you're using RMF because you have all that documentation, you have all the people involved communicating throughout this process
and then thinking carefully about who your risk management and executive groups are. You know, having the right people that really understand what it means to accept or deny a system.
So in today's video, we talked about the authorization steps in the RMF process. We talked about all tasks associated with the authorization step.
Who should be involved in each task as well as how can risk be managed for each type of system. So depending on which type of system, if I'm looking at an organization or system level, what's my risk?
Up Next