Welcome back to the D. O D Risk management framework. Siris on Mike Redman Walking you through step by step, Your successful implementation of the list risk management framework. We've made a two step number five
authorized throughout this section. We're going to ensure that you can't support the creation
and completion of the Plan of action in milestones or poem in accordance with the arm F role, as well as describe the contents of the security authorization package. Authorized or support authorization of the information system itself. State the level of acceptable risk for your information system
and it here to the correct procedures when a system is authorized to operate,
given an interim authorization or not authorized at all. If you are studying for the I s C squared cap examination, the authorization step of the arm F process is the focus of many cap exam questions.
So when it comes to system authorization, it really all is about the assurance case. You need to build an effective assurance case to assure the authorising official off the system's posture. You do this by compiling and presenting evidence of the system security posture,
the basis for determining effectiveness of those controls
the product of the assessment, as well as any system assessments that have done outside of the official assessment process and a final risk determination from the validator in the authorization step. There are four key elements. The plan of action in milestones or poem,
the security authorization package itself,
the ultimate risk determination and the risk acceptance. Starting with the poem. This is the document that describes the re mediation tasks. Associate ID allocates resource is to those tasks
and sets the milestones and schedule for those tasks to be completed. The primary task owner of the poem is the information system owner and the common control provider. So, really, when it comes to creating and managing a poem, there's only a few simple rules.
You'll identify the type of weakness for the information system,
the office or organization responsible for correcting that weakness, the amount of money needed to correct the weakness itself, scheduled completeness, dates as well as key milestones and the completion dates of those milestones. Any milestone changes if you miss a milestone, it needs to be updated and corrected.
The source identifying the potential weakness itself and the ongoing status met not met or implement it. Here's a look at a simple sample poem. You see all the required fields weakness. The POC required resource is scheduled completion dates all the way through
to the current status of on going.
For most all components, the authorization package itself is automated. It will come out of a Mass or archer. However, the task owner for the completion of the authorization package is this system owner and becoming controls provider. Inside the authorization package, you will include the system security plan,
the security Assessment report
and the completed Plan, a faction in milestones.
So just to recap here, the System security plan or the SSP is a general overview of the security requirements for the system, the description of the agreed upon security controls and the others supporting security related documents and artifacts like policies and procedures that
make up these complete security posture of the machine. The security assessment report has the results and recommended corrective action
for any control, weakness or deficiencies, and then the plan of action in milestone, which we've just spoken about. It's there to add accountability and measure the planned to correct the weaknesses or deficiencies and to reduce or eliminate identified vulnerabilities.
That brings us to the risk determination itself.
This is the identification of the current state of the system, any recommendations for addressing residual risk and the threats, vulnerabilities and potential impacts identified within this security assessment report itself. This is a task that is owned by the authorising official
or their designated representative.
When it comes to a solid risk management strategy, it really is just four or five basic questions. How is the risk identified? How is the risk evaluated? How is the risk addressed, accepted and monitored?
Finally, that brings us to the risk acceptance.
This is the authorizing officials official authorization decision. Any terms or conditions that they may attach to it and the authorization termination date. There are several flavors of authorization, beginning with an a t o. An authorization to operate.
Remembering the utopian state of the risk management framework
is a concept of ongoing authorization. It's maintaining the knowledge of the current security state of each information system, re executing the arm F steps when necessary and maximize the use of status reports. This is designed to prevent the occurrence of the every two and 1/2 months
before the assessors come. Since you're continuously monitoring each control, there should be no need for a large validation event.
Next, you can receive a special interim authorization. Generally, this is termed as an interim authorization to test specifically designed as with di cap four systems that have gone as far as they can. Without the presence of live data,
it needs to be connected to a live network
to continue its development, each I t t will have a specific time period and set conditions for instance, a 90 day active period at the end of that active period. The AO is notified that the period has expired
and the system is to be disconnected. So within each authorization, there are certain classes that we deal with.
For instance, after O and B, you have major applications and general support systems under the arm for duty. You have the system or a site, or possibly a type a platform, I T system or an enclave. The core definition for a major application
is an application that requires special attention
to the security due to the risks of magnitude of harm resulting from the loss, misuse or unauthorized access to the information in the application itself,
whereas the definition for regional support system would be interconnected. Set of information resource is under the same direct management control, which shares the common functionality for D. O D systems. For instance, a system authorization can't be given for both a major application
or a general support system,
whereas a sight authorization would be used to evaluate the applications and systems at a specific self contained location
that separates from a type authorization, which evaluates an application or system that is intended for distribution. It is a one too many. A sight authorization has a core focus
on one location or facility with all the components and parts of the system there. At one location,
they generally will be under one command or facility, one common set of security policies and a common environment. However, a type authorization
allows for a single package to have identical copies. Type authorizations generally include, for instance, a set of installation guides,
configuration requirements and operational security needs that are included with shipping. Thes guys are intended to ensure the hosting location understands their requirements to the security of the system as a whole. Next in enclave authorization
would consist of a collection of computing environments under the control of a single authority,
like a land or a backbone network, perhaps a data center or a ship. The D O D enclaves always assumed the highest security level being supported. Next, we have pits or platform I T authorizations.
The pit systems are usually special purpose systems, like special purpose hardware
or special purpose software. They provide a service to dedicated to or essential in real time toe emissions. Performance, like calibration equipment would be considered platform I t. Now here is somewhat of a new wrinkle within the risk management framework.
It's called the Outsource Authorization.
This is usually supported by private sector systems. There are typically two flavors dedicated to the D. O D. And shared with the D, O. D and private users, for instance, a possible cloud implementation.
But they are required a deal. The assessment and authorization
four deal the users and data again. The goal here is ongoing authorization, attempting to eliminate the need for a 36 month cyclical cycle of authorisation. Again, with continuous monitoring in place, there should be no need for a 36 month cycle.
And finally, we have a denial of authorization to operate or a d a t e.
And I think the definition is pretty self evident. Turn it off. Generally, D a t o zo reserved for either a system that is highly vulnerable and miss configured or possibly a system that is being decommissioned. Whatever the authorization decision
that will be documented in a formal procedure and document,
that document will include the authorization decision itself. Any terms and conditions for that authorization, the authorization termination date and the risk executive functions. Input if they provided it next, we will look at the final step in the Risk management framework monitor.