AUTHORIZATION DECISIONS
- TOC
Authorization decisions are based on the content of the authorization package. There are four types of authorization decisions that can be rendered by authorizing officials:
- Authorization to operate;
- Common control authorization;
- Authorization to use; and
- Denial of authorization.
Authorization to Operate
If the authorizing official, after reviewing the authorization package, determines that the risk to organizational operations, organizational assets, individuals, other organizations, and the Nation is acceptable, an authorization to operate is issued for the information system. The system is authorized to operate for a specified period in accordance with the terms and conditions established by the authorizing official. An authorization termination date is established by the authorizing official as a condition of the authorization. The authorization termination date can be adjusted at any time by the authorizing official to reflect an increased level of concern regarding the security and privacy posture of the system. For example, the authorizing official may choose to authorize the system to operate only for a short period of time if it is necessary to test a system in the operational environment before all controls are fully in place, (i.e., the authorization to operate is limited to the time needed to complete the testing objectives).137 The authorizing official may choose to include operating restrictions such as limiting logical and physical access to a minimum number of users; restricting system use time periods; employing enhanced or increased audit logging, scanning, and monitoring; or restricting the system functionality to include only the functions that require live testing. The authorizing official considers results from the assessment of controls that are fully or partially implemented since if the system is ready to be tested in a live environment, many of the controls should already be in place. If the system is under ongoing authorization, a time-driven authorization frequency is specified. Additionally, an adverse event could occur that triggers the need to review the authorization to operate.138
Common Control Authorization
A common control authorization is similar to an authorization to operate for systems. If the authorizing official, after reviewing the authorization package submitted by the common control provider, determines that the risk to organizational operations and assets, individuals, other organizations, and the Nation is acceptable, a common control authorization is issued. It is the responsibility of common control providers to indicate that the common controls selected by the organization have been implemented, assessed, and authorized and are available for inheritance by organizational systems. Common control providers are also responsible for ensuring that the system owners inheriting the controls have access to appropriate documentation and tools.
Common controls are authorized for a specific time period in accordance with the terms and conditions established by the authorizing official and the organization. An authorization termination date is established by the authorizing official as a condition of the initial common control authorization. The termination date can be adjusted at any time to reflect the level of concern by the authorizing official regarding the security and privacy posture of the common controls that are available for inheritance. If the controls are under ongoing authorization, a time-driven authorization frequency is specified. Within any authorization type, an adverse event could trigger the need to review the common control authorization. Common controls that are implemented in a system do not require a separate common control authorization because the controls receive an authorization to operate as part of the system authorization to operate.139
Authorization to Use
An authorization to use is employed when an organization (hereafter referred to as the customer organization) chooses to accept the information in an existing authorization package produced by another organization (either federal or nonfederal) for an information system that is authorized to operate by a federal entity (referred to as the provider organization).140 The authorization to use is a mechanism to promote reciprocity for systems under the purview of different authorizing officials. An authorization to use is issued by an authorizing official from the customer organization instead of an authorization to operate. The official issuing an authorization to use has the same level of responsibility and authority for risk management as an authorizing official issuing an authorization to operate or a common control authorization.141
The acceptance of the information in the authorization package from the provider organization is a form of reciprocity and is based on a need to use shared systems, services, or applications. A customer organization can issue an authorization to use only after a valid authorization to operate has been issued by another federal entity (i.e., the provider organization).142 The authorization to operate by the provider organization is a statement of acceptance of risk for the system, service, or application being provided. The authorization to use by the customer organization is a statement of the acceptance of risk in using the system, service, or application with respect to the customer’s information. An authorization to use provides opportunities for significant cost savings and avoids a potentially costly and time-consuming authorization process by the customer organization.
An authorization to use requires the customer organization to review the authorization package from the provider organization as the fundamental basis for determining risk.143 When reviewing the authorization package, the customer organization considers various risk factors such as the time elapsed since the authorization results were produced; the environment of operation (if different from the environment reflected in the authorization package); the impact level of the information to be processed, stored, or transmitted; and the overall risk tolerance of the customer organization. If the customer organization plans to integrate the shared system, application, or service with one or more of its systems, the customer organization considers the risk in doing so.
If the customer organization determines that there is insufficient information in the provider authorization package or inadequate controls in place for establishing an acceptable level of risk, the organization may negotiate with the provider organization and request additional controls or security, privacy, or supply chain information. Requests for additional controls may include for example, supplementing controls for risk reduction; implementing compensating controls; conducting additional or more rigorous assessments; or establishing constraints on the use of the system, application, or service provided. Requests for additional information may include, for example, information the provider organization produced or discovered in the use of the system that is not reflected in the authorization package. When the provider organization does not provide the requested controls, the customer organization may choose to implement additional controls to reduce risk to an acceptable level. The additional controls, along with any other controls for which the customer organization is responsible, are documented, implemented, assessed, authorized, and monitored.
Once the customer organization is satisfied with the security and privacy posture of the shared or cloud system, application, or service (as reflected in the current authorization package) and the risk of using the shared or cloud system, application, or service has been sufficiently mitigated, the customer organization issues an authorization to use in which the customer organization explicitly understands and accepts the security or privacy risk incurred by using the shared system, service, or application.144 Ultimately, the customer organization is responsible and accountable for the risks that may impact the customer organization’s operations and assets, individuals, other organizations, or the Nation.
The authorization to use does not require a termination date but remains in effect if the customer organization continues to accept the security and privacy risk of using the shared or cloud system, application, or service and the authorization to operate issued by the provider organization meets the requirements established by federal and organizational policies. It is incumbent on the customer organization to ensure that information from the monitoring activities conducted by the provider organization is shared on an ongoing basis and that the provider organization notifies the customer organization when there are significant changes to the system, application, or service that may affect the security and privacy posture of the provider. If desired, the authorization to use decision may specify time- or even-driven triggers for review of the security and privacy posture of the provider organization system, service, or application being used by the customer organization. The provider organization to notifies the customer organization if there is a significant event that compromises or adversely affects the customer organization’s information.145
Figure F-1 illustrates the types of authorization decisions that can be applied to organizational systems and common controls and the risk management roles in the authorization process.
Denial of Authorization
If the authorizing official, after reviewing the authorization package, including any inputs provided by the senior accountable official for risk management or risk executive (function), determines that the risk to organizational operations, organizational assets, individuals, other organizations, and the Nation is unacceptable and immediate steps cannot be taken to reduce the risk to an acceptable level, the authorization is not granted. A denial of authorization means that the information system is not authorized to operate and not placed into operation; common controls are not authorized to be provided to systems; or that the provider’s system is not authorized for use by the customer organization. If the system is currently in operation, all activity is halted. Failure to receive an authorization means that there are significant deficiencies in the controls.
The authorizing official or designated representative works with the system owner or the common control provider to revise the plan of action and milestones to help ensure that measures are taken to correct the deficiencies. A special case of authorization denial is an authorization rescission. Authorizing officials can rescind a previous authorization decision when there is a violation of federal or organizational policies, directives, regulations, standards, or guidance; or a violation of the terms and conditions of the authorization. For example, failure to maintain an effective continuous monitoring program may be grounds for rescinding an authorization decision. ***
137 Formerly referred to as an interim authority to test.
138 Additional information on event-driven triggers is provided below.
139 In certain situations, system owners may choose to inherit controls from other organizational systems that may not be designated officially as common controls. System owners inheriting controls from other than approved common control providers ensure that the systems providing such controls have valid authorizations to operate. The authorizing official of the system inheriting the controls is also made aware of the inheritance.
140 The term provider organization refers to the federal agency or subordinate organization that provides a shared system, service, or application and/or owns and maintains the authorization package (i.e., has granted an Authorization to Operate for the shared system, service, or application). The shared system, service, or application may not be owned by the organization that owns the authorization package, for example, in situations where the shared system, service, or application is provided by an external provider.
141 Risk-based decisions related to control selection and baseline tailoring actions by organizations providing cloud or shared systems, services, or applications should consider the protection needs of the customer organizations that may be using those cloud or shared systems, services, or applications. Thus, organizations hosting cloud or shared systems, services, or applications should consider the shared risk of operating in those types of environments.
142 A provisional authorization (to operate) issued by the General Services Administration (GSA) as part of the Federal Risk and Authorization Management Program (FedRAMP) is considered a valid authorization to operate for customer organizations desiring to issue an authorization to use for cloud-based systems, services, or applications.
143 The sharing of the authorization package (including security and privacy plans, security and privacy assessment reports, plans of action and milestones, and the authorization decision document) is accomplished under terms and conditions agreed upon by all parties (i.e., the customer organization and the service provider organization).
144 In accordance with [FISMA], the head of each agency is responsible for providing information security protections commensurate with the risk resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information collected or maintained by or on behalf of the agency; and information systems used or operated by an agency or by a contractor of an agency. [OMB A-130] describes organizational responsibilities for accepting security and privacy risk.
145 The customer organization may develop memoranda of agreement/understanding, contracts, or other types of agreements with the provider organization to help ensure security posture information about the provided system is shared appropriately.