authority-to-operate

Authority To Operate - (draft) explainer

Status of this document

This is a working document of the EEA’s Authority to Operate Working Group, made available for public comment as is. It is inappropriate to cite this document except as work in progress. The document may be modified or superseded at any time. This document has not been reviewed or approved by the EEA, its board, or its general membership.

What is an ATO?

Per the Risk Management Framework (RMF), an Authorization To Operate (ATO) is defined as: “The official management decision given by a senior Federal official or officials to authorize operation of an information system and to explicitly accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security and privacy controls.”

Under the requirements of the Federal Information Security Management Act (FISMA), all US federal agencies are required to follow the Risk Management Framework. More concretely, this means that each information system used at the federal level must receive an ATO. This is also the case for commercial/custom solutions developed and sold by private entities to the federal government, regardless of the underlying technology used; in such cases, private entities are expected to work with agency officials to determine if their solutions comply with RMF guidelines, and, if not, determine potential modifications to make them compliant.

Note: Depending on their scope and complexity, information systems may need to satisfy hundreds of security controls in order to receive an ATO. Hence, for blockchain-based systems, expect every functional and technical property of the solution to be assessed : network configuration and governance, cryptographic modules, smart contract management, account and key management, system maintenance… (list not exhaustive)

Note that the RMF provides guidance on how to conduct an ATO (see next section), even though each federal agency may interpret these guidelines differently, resulting in slightly different ATO processes. Moreover, an ATO granted by a federal agency is only valid for that given agency; this implies that, for a system to be authorized in a multi-agency setting, several distinct ATOs may be required. An ATO process may typically last for 3 to 6 months.

Key ATO Steps

The Risk Management Framework describes the different steps that should be followed in order to successfully receive an ATO. The ATO is typically granted after completion of the 5th step ‘Authorize the system’. See steps below:

Step 0: Prepare the system: conduct preparatory activities (e.g., identify mission functions, authorization boundary, types of information to be processed, risk management roles, risk and privacy requirements, and produce a system-level risk assessment) before applying next steps in the RMF. See SP 800-18, SP 800-30, SP 800-160 Vol.1. Main outputs: Documented authorization boundary; List of information types; Security and privacy assessment reports (SAR/PAR); Documented security and privacy requirements.
Step 1: Categorize the system: determine the impact level of each information type and security objective (confidentiality, integrity, availability), before determining the overall security impact level of the system (low-impact, moderate-impact or high-impact). See FIPS-199, SP 800-60. Main outputs: Documented system description; Security categorization of the system.
Step 2: Select security controls: determine which controls need to be implemented. See FIPS-200, SP 800-53, SP 800-53B, and SP 800-18. Main outputs: List of tailored controls for the system and environment of operation; System security and privacy plans (SSP/SPP); Continuous monitoring strategy for the system.
Step 3: Implement security controls: implement the controls identified in Step 2 and document them in a baseline configuration. See SP 800-70. Main outputs: Implemented controls; Updated SSP/SPP.
Step 4: Assess the security controls: determine if the controls are implemented correctly, operating as intended, and producing the desired outcomes with respect to satisfying the security and privacy requirements. The results of the assessment are documented in a security assessment report. See SP 800-53A and SP 800-30. Main outputs: Security and privacy assessment reports (SAR/PAR) by the assessor findings; Updated SAR/PAR (assessor) and updated SSP/SPP reflecting control implementation changes; Plan of action and milestones (POAM).
Step 5: Authorize the system: an authorization package is assembled and submitted to the authorization official; this package may include: security and privacy plans, security assessment report, plan of action and milestones, supporting assessment evidence or other documentation. The authorization official then submits her decision; if approved, an authorization termination date is also provided (unless operating under an ongoing authorization regime). See SP 800-37. Main outputs: Authorization package; Authorization to operate.
Step 6: Monitor the system: maintain an ongoing situational awareness about the security and privacy posture of the information system. Once authorized and operating, the system must still be assessed at regular intervalles and/or when a change to the system occurs. This implies the update of security and privacy plans, security and privacy assessment reports, and plans of action and milestones on an ongoing basis. See SP 800-37, SP 800-137 and SP 800-53A. Main outputs: Updated SSP/SPP; Updated POAM; Updated SAR/PAR; Security and privacy posture reports; Disposal strategy.

Categories of Authorization decisions

With regards to the authorization step (Step 5), five main categories of authorization decisions are defined: authorization to operate, type authorization, authorization to use, common control authorization, and facility authorization.

Authorization to operate (ATO)

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. 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. 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.
Type authorization

A type authorization is a sub-category of ATO, that allows for a single authorization package to be developed for an archetype (i.e., common) version of a system. This includes, for example hardware, software, or firmware components that are deployed to multiple locations for use in specified environments of operation. A type authorization is appropriate when the system is deployed in a defined environment and is comprised of identical instances of system architecture, software, identical information types, functionally identical hardware, information that is processed in the same way, identical control implementations, or identical configurations. A type authorization is issued by the authorizing official responsible for the development of the system; at the site or facility where the system is deployed, the authorizing official who is responsible for the system at the site or facility accepts the risk of deploying the system and issues an authorization to use (see below).
Authorization to use

An authorization to use is employed when an organization chooses to accept the information in an existing authorization package produced by another organization (either federal or nonfederal). 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). 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. 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 system. 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.

Approaches for conducting an ATO

Organizations can choose between two different collaboration approaches when conducting an authorization: traditional vs joint authorization. In a traditional authorization, a single authorizing official is responsible and accountable for authorizing the system. In a joint authorization, multiple organizational officials either from the same organization or different organizations work on authorizing the system. Organizations choosing a joint authorization approach are expected to work together on the planning and the execution of RMF tasks (e.g., security categorization, control selection and tailoring, plan for assessing controls to determine effectiveness, plan of action and milestones, system-level continuous monitoring strategy) and to document their agreement and progress in implementing the tasks. The joint authorization remains in effect only while there is agreement among authorizing officials and the authorization meets the specific requirements established by federal and organizational policies.

For systems where a continuous monitoring plan is deployed, an ongoing authorization process may be followed. In this approach, the authorizing official maintains sufficient knowledge of the current security and privacy posture of the system to determine whether continued operation is acceptable based on ongoing risk determinations.

Finally, a system may receive several authorizations during its lifecycle. The first ATO received by a system is known as initial authorization, while subsequent authorizations are referred to as reauthorizations. Reauthorizations occur at the discretion of the authorizing official and can be either time-driven (e.g., following a determined authorization frequency) or event-driven basis (e.g., until organizational-defined trigger events occur). Under ongoing authorization, a reauthorization may be necessary if an event occurs that produces risk above the acceptable organizational risk tolerance, such as: new threat or vulnerability, increased security and/or privacy deficiencies found by the continuous monitoring program, changes in risk assessment findings, changes to the system and its operation environment (e.g., deployment location, policy rules). Reauthorizations differ from the initial authorization because the authorizing official can choose to initiate a complete new review of the system or to initiate a targeted review based on the type of event that triggered the reauthorization.