path-to-authorization.md

Path to Authorization

Impact Level 5 (H-H-X), FedRAMP High & FedRAMP Moderate

Created Date:

Last Modified:

Google POC(s): stellar-engine@google.com

Version: 1.0

Purpose: The purpose of this document is to discuss the path to authorization through the use of the Risk Management Framework along with Stellar Engine and ATO-Ready Deployment Blueprints.

Background: The Risk Management Framework (RMF) provides a comprehensive, flexible, and repeatable seven-step process designed to help organizations manage their specific information security and privacy risks. All seven steps are essential for the successful implementation of the RMF.

Stellar Engine accelerates Google Cloud deployments for Public Sector customers by providing reusable Infrastructure as Code (IaC) and cybersecurity documentation. This enables both customers and Independent Software Vendors (ISVs) to deploy solutions more quickly and achieve Authorization to Operate (ATO) on Google Cloud with greater efficiency.

By leveraging the RMF alongside Stellar Engine’s tools, organizations can streamline their security and compliance efforts, ensuring faster, more secure deployments in the cloud.

RMF & Stellar Engine:

The source document used color to distinguish major ATO submission artifacts from Authorizing Official (AO) actions. This Markdown version uses explicit section labels, linked artifact names, and AO wording instead of color-only cues.

Step 0; Prepare: Essential activities to prepare the organization to manage security and privacy risks

• Designate an individual, or individuals, who will be assigned the task of executing the Risk Management Framework.
  • Roles and responsibilities may be assigned to personnel internal or external to your organization.
• Create a risk management strategy for the organization that articulates your organizational risk tolerance.
  • Understand and document specific assumptions, constraints, risk tolerances, priorities, and trade-offs.
  • Make strategic-level decisions on how to manage cybersecurity and privacy risk.
  • There is no “correct level” of risk tolerance. The degree of risk tolerance is generally based on organizational culture, could be different for different types of losses or compromises, and can be influenced by risk tolerance of executives.
• Implement a continuous monitoring strategy for your organization to monitor security and privacy risk posture.
  • The strategy articulates frequency of control monitoring and how monitoring is to be conducted.
• Determine the scope of protection for the system and what falls into that scope.
  • Authorization boundaries establish the scope of systems to be protected, managed, and authorized for operation or use.
  • Impact Level 5 Authorization Boundary
  • FedRAMP High & Moderate Authorization Boundary
• Regularly assess the security and privacy risks at the organization level and system level. Update risk assessment results on an on-going basis.

Step 1; Categorize: Categorize the system and information processed, stored, and transmitted based on the impact analysis

• Categorize each system based on the impact to the organization if the confidentiality, availability, or integrity were to become compromised.
  • Categorization References
  • System Security Plan Templates

Step 2; Select: Select the set of NIST SP 800-53 controls to protect the system based on risk assessment(s)

• Now that you have categorized the systems and assets, select the appropriate controls needed for protection.
  • The control baseline is a set of controls you can implement to meet strategic, legal, regulatory, or contractual security and privacy requirements and manage risk.
  • What security and privacy controls are needed to satisfy the organization’s security and privacy requirements and to adequately manage risk?
  • For our initial selection of controls, should we use a baseline (pre-defined) control selection approach, or should we select our own controls?
• After selecting an appropriate control baseline, tailor the controls to address the specific security and privacy requirements for the organization.
• Develop and implement a system-level strategy for monitoring control effectiveness.
  • This strategy defines how changes to the system and environment of operation are to be monitored, how risk assessments are conducted, and the reporting requirements.
  • How effective are the controls we have implemented? What is the frequency in which the controls are monitored?
  • Security Control Traceability Matrix (SCTM) Templates (IL5 H-H-X, FedRAMP High, and FedRAMP Moderate Baselines)
  • Policies and Procedures Templates (IL5 HHX, FedRAMP High, and FedRAMP Moderate Baselines)

Step 3; Implement: **Implement **the controls and document how controls are deployed

• Now that you have categorized systems by their risks and have selected appropriate controls, now is the time to implement the controls.
  • Have the security and privacy controls been implemented or is there an implementation plan in place?
• Update security and privacy plans to document necessary changes.
  • It’s not always feasible to implement controls as planned. Document necessary revisions that reflect how the control is implemented.

Step 4; Assess: Assess to determine if the controls are in place, operating as intended, and producing the desired results

• Select an individual or team responsible for conducting a control assessment.
  • Organizations can conduct self-assessments of controls or obtain the services of an independent assessor.
• Develop, review, and approve plans to assess implemented controls.
• Once plans are approved, conduct control assessments using the assessment plans.
• Prepare an assessment report documenting the findings and recommendations, such as plans for correcting deficiencies.
• Prepare the plan of action and milestones, which details remediation plans based on the findings and recommendations of the assessment report.

Step 5; Authorize: Senior official makes a risk-based decision to authorize the system (to operate). Authorizing Officials (AOs) are executive-level leaders with demanding schedules, which is why they typically rely on a team for information system security. Each AO has a unique perspective on risk tolerance and while they are not always technical subject matter experts, they are experts in the business or mission area. To engage effectively, it’s important to translate security controls in a way that aligns with and supports the success of their mission.

• Assemble the authorization package and submit it to the authorizing official for an authorization decision.
  • If security and privacy controls are being implemented by an external provider, ensure the provider makes available the information needed for your organization to make risk-based decisions.
• The authorizing official analyzes the information in the authorization package and finalizes the determination of risk to the organization.
• The authorizing official issues an authorization decision for the information system, indicating whether the system is authorized to operate or not.

Step 6; Monitor: Continuously monitor control implementation and risks to the system

• Monitor the system and environment of operation for changes that impact security and privacy.
• Using the results of the ongoing monitoring activities, risk assessments, and outstanding items in plans of action and milestones, determine the appropriate risk response and implement.
• Maintain ongoing communication with organizational leadership to convey the current security and privacy posture of the organization.

Additional Artifacts for an ATO:

• Privacy Impact Assessment (PIA)
• PII Confidentiality Impact Level (PCIL)
• System of Records Notice (SORN)
• Hardware List
• Software List
• Ports, Protocols, and Services Management (PPSM)

Things to Consider:

• Team members should be U.S. Citizens.
• In addition to documentation, you may be required to ensure compliance with STIGs and ACAS scans.
• ATOs are for a set time frame with a max of 3 years, but that does not mean the work stops; packages will need to be maintained throughout the lifecycle of the ATO. Without continuous updates, there will be a herculean effort to make updates to address major changes, security requirement updates, or CVEs.
• An ATO with one agency/program does not necessarily transfer to another agency program. ATOs are agency specific, however, there is potential for reciprocity. Many AOs will accept reciprocity if the application, system, or component of the system was authorized by another government official, especially within the same agency or within DoD.

Example Work Breakdown Structure (WBS) for ATO:

WBS #:	Action:
1.0	Conduct kick-off meetings with stakeholders, including the Authorizing Official and their team.
1.1	Roadmap with schedule , milestones, and responsibilities for the process
1.2	Obtain access to system accounts (networks, eMASS, etc.).
1.3	Build ATO Deliverables
1.3.1	Build Initial Artifacts: Architecture Diagram; HW/SW List; System Security Plan
1.3.2	Determine categorization per FIPS 199
1.3.3	Select controls based upon NIST SP 800-53 rev 4 or rev 5
1.3.4	Assist team with implementation of controls
1.3.5	Write policies and procedures (Configuration Management, Incident Response Plan, Continuous Monitoring Strategy, etc.)
1.3.6	Perform self-assessment, draft POA&M
1.3.7	Submit package to AO, answer questions, and provide support as needed
1.4	AO awards ATO

References

• NIST SP 800-37 rev 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
  • Describes the RMF and provides guidelines for apply the RMF to information systems and organizations
• Federal Information Processing Standards (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems
  • Standard for categorizing information systems according to concerns for confidentiality, integrity, and availability. Used with SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories
• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems
  • Provides a risk-based process for selecting the security controls necessary to satisfy the minimum requirements for information and an information system
• NIST SP 800-53 rev 4 and rev 5, Security and Privacy Controls for Federal Information Systems and Organizations
  • Catalog of security and privacy controls for information systems and organizations to protect against a diverse set of threats and risks.
• Stellar Engine Technical Design Document