h X^ X u v } ( } u u ~ K E ] } v o K v ] v u } Z ] u ] v ... · Title: Microsoft Word - Cloud Computing Security Authorization_SOP_v2.3.docx Author: YWynn Created Date: 9/24/2019

U.S. Department of Commerce (DOC)

National Oceanic and Atmospheric Administration (NOAA)

OCIO

Cloud Computing Security Testing, Authorization and Continuous Monitoring

Standard Operating Procedure (SOP)

Date

Version 2.3

NOAA OCIO Cloud Computing Security Testing, Authorization and Continuous Monitoring


Version 2.3 i

Revision History

Version Date Edits Author

0.1 06 August 2018 Initial Draft EWSSC

0.2 27 February 2019 Second Draft -Major Revision Ambit

1 16 April 2019 Major Release for Review Ambit/CSD

1.2 05 June 2019 ITSC Review & Comments Ambit/ITSC Members

2 25 June 2019 Major Release Ambit/CSD

2.1 15 July 2019 ECGS - Security Team Review Ambit/ECGS Members

2.1 30 July 2019 CIO Counsel Info Brief & Review Ambit/CSD

2.2 13 September 2019 Final Release for Review Ambit/CSD

2.3 25 September 2019 ITSC Review & Approval CSD

2.3 01 October 2019 Final CIO Counsel Approval CSD



Version 2.3 ii

NOAA OCIO Approvals __________________________________________________________ Project Sponsor, Organization, Title Date



Version 2.3 iii

Preface

This Standard Operating Procedure (SOP) provides an overview of the policies, guidelines, and processes to securely leverage cloud-native applications and services hosting federal data and information systems. This document was written to help guide any user through NOAA’s authorization process and is deliberately comprehensive and explanatory.

NOTE: If the reader is already familiar with background information on FedRAMP and the NOAA authorization process, they may skip forward to the Procedures to find details on the specific steps and documentation needed to complete the authorization process for systems that have been approved for use by the NOAA Enterprise Cloud Governance Subcommittee (NCGS). This section also provides similar details for other phases of the security life cycle.



Version 2.3 iv

Table of Contents 1 Introduction ......................................................................................................................................... 1

2 Background........................................................................................................................................... 1

2.1 Cloud Service Provider (CSP) and Cloud Service Offering (CSO) ................................................... 1

2.2 Cloud Service vs Managed IT Service ............................................................................................ 1

2.3 Cloud Computing, Cloud Deployment Models, and Cloud Services ............................................. 2

2.4 Federal Risk and Authorization Management Program (FedRAMP) ............................................ 3

2.5 NIST Publications, Standards, Guidelines and Process ................................................................. 4

2.6 Information Security Objectives (Federal Information Processing Standards) ............................ 5

2.7 Information Impact Levels ............................................................................................................ 5

2.8 Cloud Service Authorization .......................................................................................................... 7

3 Purpose ................................................................................................................................................ 9

4 Scope and Applicability ........................................................................................................................ 9

5 Responsibility ..................................................................................................................................... 10

5.1 Stakeholders ............................................................................................................................... 10

6 Policy .................................................................................................................................................. 11

7 Procedure ........................................................................................................................................... 12

7.1 Cloud Readiness Assessment Checklist ....................................................................................... 13

7.2 Develop Schedule ........................................................................................................................ 13

7.3 Document .................................................................................................................................... 14

7.3.1 Leverage FedRAMP Security Packages ................................................................................ 14

7.4 Complete Assessment ................................................................................................................. 16

7.5 Authorization .............................................................................................................................. 16

7.6 Continuous Monitoring and ATO Maintenance .......................................................................... 16

7.6.1 Monitoring Cloud Systems .................................................................................................. 17

7.6.2 Maintaining an ATO ............................................................................................................ 17

7.6.3 Revocation of an ATO.......................................................................................................... 17

Appendix A: Cloud System Authorization Workflow – NOAA/FedRAMP Authorized ................................ 18

Appendix B: Cloud System Authorization Workflow – FedRAMP Authorized ............................................ 19

Appendix C: Cloud System Authorization Workflow – New Cloud System Authorization ......................... 20

Appendix D: List of Acronyms ..................................................................................................................... 21



Version 2.3 v

Appendix E: References .............................................................................................................................. 23

E.1 Legislation, Policies, and Directives ............................................................................................ 23

E.2 Guidance ..................................................................................................................................... 23

List of Tables

Table 1: Potential Impact Definitions for Security Objectives ...................................................................... 7

List of Figures

Figure 1: Cloud System Authorization Workflow - NOAA/FedRAMP Authorized ....................................... 18 Figure 2: Cloud System Authorization Workflow - FedRAMP Authorized .................................................. 19 Figure 3: Cloud System Authorization Workflow - New Cloud System Authorization ............................... 20



Version 2.3 1

1 Introduction The National Oceanic and Atmospheric Administration (NOAA), Office of the Chief Information Officer (OCIO) Cyber Security Division (CSD) is working to establish a set of living documents and tools to streamline the process of obtaining authorization for new and existing cloud shared services. These efforts are intended to enable NOAA’s workforce to engage with new technology while also achieving broader goals established in the Federal Cloud Computing Strategy (Cloud First/Cloud Smart)1, Federal Risk and Authorization Management Program (FedRAMP), Modernizing Government Technology Act2, NOAA Information Resource Strategic Plan, and NOAA 2018-2023 IT Workforce Strategic Plan3.

The processes, policies, and procedures in this document are based on reference materials from the Department of Commerce (DOC), the FedRAMP program, and the Department of Defense (DoD), among others, and use best practices to securely leverage publicly hosted cloud services and inform NOAA’s Risk Management Program (RMP). This operating procedure is a living document, designed to provide a framework to standardize and guide the security assessment and authorization of any publicly hosted service used to enable the NOAA workforce in achieving mission objectives.

2 Background This Standard Operating Procedure (SOP) describes the process for completing security assessments, gaining NOAA Chief Information Officer (CIO) approval for, and continuous monitoring of, commercial cloud services. The cloud service authorization processes outlined in this SOP include both FedRAMP Joint Authorization Board Provisional Authority to Operate (JAB P-ATO) and Agency-specific Authority to Operate (ATOs) and non-FedRAMP authorized solutions for Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

2.1 Cloud Service Provider (CSP) and Cloud Service Offering (CSO)

A Cloud Service Provider (CSP) is an entity that offers one or more cloud services in one or more deployment models. A CSP might leverage or outsource services of other organizations and other CSPs (e.g., placing certain servers or equipment in third party facilities such as data centers, carrier hotels/co-location facilities, and Internet Exchange Points (IXPs)). CSPs offering SaaS may leverage one or more third party CSO’s (i.e., for IaaS or PaaS) to build out a capability or offering.

A Cloud Service Offering (CSO) is the actual IaaS/PaaS/SaaS solution available from a CSP. This distinction is important since a CSP may provide several different CSOs.

2.2 Cloud Service vs Managed IT Service

Captured in the definition above, CSPs are business entities that offer cloud services across various cloud deployment models. In these online environments, compute resources are provided to the customer to

1 https://cloud.cio.gov/strategy/ 2 https://www.whitehouse.gov/wp-content/uploads/2017/11/M-18-12.pdf 3 NOAA Strategic Planning Documents are available upon request



Version 2.3 2

manage application resources and data online. The CSP has no inherent responsibility to provide services outside of agreed upon contract terms.

Managed services are those that would typically be managed internally by an organization that have been outsourced. Examples include network monitoring, helpdesk, end user support, and infrastructure operations and maintenance. Some CSPs offer managed services for both cloud and on-premise systems and applications. Although some CSPs offer managed services under their portfolio, managed service providers are not limited to cloud-based solutions or necessarily bound to one CSP.

2.3 Cloud Computing, Cloud Deployment Models, and Cloud Services

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and used with minimal management effort or service provider interaction.

The definition of cloud computing found in National Institute of Standards and Technologies (NIST) Special Publication (SP) 800-145 is composed of five essential characteristics, four deployment models, and three service models. The essential characteristics are outlined below and are further detailed in SP 800-145.

Essential Characteristics:

● On-demand self-service ● Broad network access ● Resource pooling ● Rapid elasticity ● Measured service

Deployment Models

The descriptions below are taken from SP 800-145. It is important to note that each of the four models include services that may be provided by a non-government entity or third party CSP.

Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination therein, and may exist on or off premises.

Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of users from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination therein, and may exist on or off premises.

Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination therein. It exists on the premises of the cloud provider.



Version 2.3 3

Hybrid cloud. The cloud infrastructure is a combination of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Service Models

While there are dozens of service models emerging in the cloud computing market, the three recognized by NIST are described below. These service models are offered as independent services or can be purchased in any combination from most major CSPs. Each service model described below has a unique implication to the security of the information and systems it accesses, stores, and manages.

Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and potentially limited control of select networking components (e.g., host firewalls).

Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure, consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and potentially configuration settings for the application-hosting environment.

Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user specific application configuration settings.

2.4 Federal Risk and Authorization Management Program (FedRAMP)

The Federal Risk and Authorization Management Program, or FedRAMP, is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by the Federal Government. The use of FedRAMP is mandated for all Federal Agencies by the Office of Management and Budget (OMB) as their systems and applications are migrated to the commercial cloud under the Federal Government’s Cloud-First initiatives. The December 2011 OMB FedRAMP policy memo4 requires federal departments and Agencies to use FedRAMP approved CSPs and share Agency ATOs with the FedRAMP Secure Repository.

FedRAMP uses a “do once, use many times” framework that intends to reduce cost, time, and staff required for security assessments and process monitoring reports. The FedRAMP Joint Authorization Board (JAB) is the primary governance and decision-making body for the FedRAMP program. JAB-

4 https://www.fismacenter.com/fedrampmemo.pdf



Version 2.3 4

approved standards and processes result in the award and maintenance of a provisional authorization to host Federal Government data, systems, and cloud services.

NOAA leverages FedRAMP JAB P-ATOs and non-DoD U.S. Government Federal Agency ATO packages residing in the FedRAMP Secure Repository and encourages the use of Agency ATOs where the cloud service provider or offering was assessed by a FedRAMP-accredited Third Party Assessor Organization (3PAO).

2.5 NIST Publications, Standards, Guidelines and Process

NIST 800-37 Rev. 2 Risk Management Framework (NIST RMF)5. The scope of NIST RMF pertains to federal information systems, which are discrete sets of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information, whether such information is in digital or non-digital form. Information resources include information and related resources, such as personnel, equipment, funds, and information technology.

The tasks and outcomes that are executed in accordance with the RMF provide organization guidance that will be used unilaterally to assess the risk of all federal information systems, including those provided by CSPs. Outputs from each independent cloud system authorization are critical inputs to CSDs for determining NOAA’s organization-wide risk posture and continuous monitoring needs. Risk assessment results, or the results from an impact analysis, may be used to determine if changes to systems or common controls are significant and trigger an authorization action. If an authorization action is initiated, the organization targets only the specific controls affected by the changes and reuses previous assessment results wherever possible.

NIST 800-144, Guidelines on Security and Privacy in Public Cloud Computing6. This publication provides an overview of the security and privacy challenges pertinent to public cloud computing and points out considerations an organization should take when outsourcing data, applications, and infrastructure to a public cloud environment.

NIST 800-53 Rev 4 Security and Privacy Controls for Federal Information Systems and Organization7. This publication provides a catalog of security and privacy controls for federal information systems and organizations. It also provides a process for selecting controls to protect organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile cyber-attacks, natural disasters, structural failures, and human errors (both intentional and unintentional). The security and privacy controls are customizable and implemented as part of an organization-wide process that manages information security and privacy risk. The publication also describes how to develop specialized sets of controls, or overlays, tailored for specific types of missions/business functions, technologies, or environments of operation. Finally, the catalog of security controls addresses security from both a functionality perspective (the strength of security functions and mechanisms provided) and an assurance perspective (the measures of confidence in the implemented security capability). Addressing both security functionality and assurance helps to ensure that information technology

5 https://doi.org/10.6028/NIST.SP.800-37r2 6 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf 7 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdff



Version 2.3 5

component products and the information systems built from those products are using sound system and security engineering principles and are sufficiently trustworthy.

NIST SP 800-161 Supply Chain Risk Management (SCRM) Practices for Federal Information Systems and Organizations8. Supply Chain Risk Management (SCRM) is the process of identifying, assessing, and mitigating the risks associated with the global and distributed nature of product and service supply chains. Supply Chain Risk Assessments (SCRA) have been integrated into the overall organization risk assessment processes. NOAA’s integration of SCRA in the authorization process strengthens supplier quality and performance across NOAA. The NOAA SCRM process follows guidelines and procedures outlined within the Federal law, Department Policy Requirements, the NIST 800 Publication Series, and best practices.

Guided by DOCITSBP Annex C-9: Pre-Acquisition Supply Chain Risk Assessment and the DOC’s SCRM best practices, NOAA CSD is developing a complementary SOP for SCRM. This guidance applies to all employees (federal and contractor), guest researchers, collaborators, and others who are completing an IT acquisition or operating on a National Security Systems (NSS) and/or Federal Information Processing Standard (FIPS) 199 high-impact or moderate impact information system, equipment, or software to be used in, on, or to support an existing NSS or FIPS 199 high-impact or moderate impact information system.

2.6 Information Security Objectives (Federal Information Processing Standards)

To elevate the importance of taking action to protect federal information and federal information systems, Federal Information Security Management Act (FISMA) directed the promulgation of federal standards for: (i) the security categorization of federal information and information systems based on the objectives of providing appropriate levels of information security according to a range of risk levels; and (ii) minimum security requirements for information and information systems in each such category. FIPS Publication 199 – Standards for Security Categorization of Federal Information and Information Systems9, approved by the Secretary of Commerce in February 2004, is the first of two mandatory security standards required by the FISMA legislation. FIPS Publication 200: Minimum Security Requirements for Federal Information and Information Systems10, the second of the mandatory security standards, specifies minimum security requirements for information and information systems supporting the executive agencies of the Federal Government and a risk-based process for selecting the security controls necessary to satisfy the minimum security requirements. This standard promotes the development, implementation, and operation of more secure information systems within the Federal Government by establishing minimum levels of due diligence for information security. It also facilitates a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems that meet minimum security requirements.

2.7 Information Impact Levels

Cloud security information impact levels are defined by the combination of: 1) the sensitivity or confidentiality level of information (e.g., public, private, classified, etc.) to be stored and processed in

8 https://csrc.nist.gov/publications/detail/sp/800-161/final 9 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf 10 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf



Version 2.3 6

the CSP environment; and 2) the potential impact of an event that results in the loss of confidentiality, integrity, or availability of that information. NOAA Line Offices and OCIO Service Divisions must categorize mission information systems in accordance with NIST SP 800-6011, which provides guidance on mapping security impact levels to types of: (i) information (e.g., privacy, medical, proprietary, financial, contractor sensitive, trade secret, investigation); and (ii) information systems (e.g., mission critical, mission support, administrative) to then identify the Cloud Information Impact level that most closely aligns with the defined categorization and information sensitivity.

Information Impact Levels consider the potential impact should the confidentiality or integrity of the information be compromised. According to FIPS 199, confidentiality is “preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…” [44 United States Code (U.S.C.), Sec. 3542][11]. A loss of confidentiality is the unauthorized disclosure of information. Integrity is defined as “Guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity…” [44 U.S.C., Sec. 3542]. A loss of integrity is the unauthorized modification or destruction of information. It is important to note that the unauthorized destruction of information will result in the loss of availability of that information. For additional information on Confidentiality, Integrity, and Availability please reference Table 1 below.

The Potential Impact Definitions for Security Objectives table below, from the FIPS 199 publication, summarizes the impact definitions for each security objective. It uses three levels: low, moderate, and high to designate the impact of a loss of confidentiality, integrity, or availability.

11 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf



Version 2.3 7

Table 1: Potential Impact Definitions for Security Objectives

As a part of the assessment procedure for authorization, the system owner working with other security resources on their respective team, will provide details on how the CSP and associated services meet the minimum security control baseline for the appropriate information system category. To aid in this process FedRAMP provides baseline templates for each impact level on their website, https://www.fedramp.gov/templates/. FedRAMP has also released a tailored, low baseline template available for SaaS applications. The template can be found here https://tailored.fedramp.gov/, and at the link provided in the Reference Section, labeled FedRAMP System Security Packages (SSP) Low Baseline Template.

2.8 Cloud Service Authorization



Version 2.3 8

This SOP is based on existing NOAA and FedRAMP processes and is tailored to appropriately balance mission and security concerns. As a rule, NOAA strives to use the FedRAMP processes outlined above, but recognizes the existence of legacy cloud services already supporting mission requirements and has a process to authorize those systems to operate. For cloud services in use prior to the signed completion of this procedure, Line Offices and Staff Offices will be expected to follow this SOP at the time of system reassessment.

The process workflows for cloud service authorizations are included in Appendix A-C. These diagrams provide a high-level view of the authorization process from start to finish. The diagrams capture three different potential scenarios: 1) SOP for implementing/expanding existing NOAA/FedRAMP Authorized Cloud Services, 2) SOP for implementing/expanding existing FedRAMP Authorized Cloud Services, and 3) SOP for implementing new cloud services that have not been previously authorized by NOAA, the JAB, or other Agencies listed in the FedRAMP Marketplace. Section 7 of this document, Procedures, details the requirements, documentation, and approvals for authorization. The section that follows provides a summary of NOAA’s three paths for obtaining approval to use cloud systems and services and the resulting authorizations.

FedRAMP Authorization Paths for Cloud Services

Agencies have the option to complete an independent assessment of a cloud service to grant the ATO. In these cases, each Agency is responsible for an independent assessment of the system to review what the system owner and Information System Security Officer (ISSO) have completed. When Federal Agencies grant security authorizations using the FedRAMP Security Assessment Framework (SAF), they must use existing authorizations (granted and approved by the JAB) as a starting point in applying the FedRAMP SAF. Once an Agency grants an authorization that follows the FedRAMP SAF, then they must submit that security authorization package to the FedRAMP Program Management Office (PMO) for verification of meeting the FedRAMP requirements (if not already in the repository). Additionally, the Federal Agency must have an “Authority to Operate” (ATO) letter on file with the FedRAMP PMO.

NOTE: The NOAA/FedRAMP Authorization Workflow (Appendix A) reflects a Line Office/Services Office (LO/SO) taking advantage of systems and services that are already NOAA & FedRAMP Authorized. The workflow depicts the process for using services under an existing ATO and is the most strongly encouraged.

Of the two paths for using existing authorization packages, this path takes advantage of the JAB P-ATO or another Agency's ATOs and is the most common. The JAB members are the CIOs from the Department of Homeland Security (DHS), General Services Administration (GSA), and Department of Defense (DoD). The JAB defines and establishes the FedRAMP baseline system security controls and works closely with the FedRAMP PMO to ensure that FedRAMP baseline security controls are incorporated into consistent and repeatable processes for security assessment and authorization of CSPs, through this FedRAMP SAF which it uses to issue a P-ATO for cloud services it believes will be leveraged the most, Government-wide. For those P-ATOs, the JAB also ensures those systems maintain an acceptable risk posture through continuous monitoring.

*While NOAA does not accept P-ATOs in lieu of NOAA ATO’s, the FedRAMP Authorization Workflow in Appendix B depicts the process for leveraging existing SSPs for these authorized services. In such cases it is encouraged that the completed package be submitted to FedRAMP for NOAA/FedRAMP authorization and inclusion in FedRAMP Marketplace.



Version 2.3 9

NOAA Authorization Path for Cloud Services

For cloud services required to support the NOAA mission that are either in-process with FedRAMP or are not pursuing FedRAMP authorization, NOAA will execute its own authorization as outlined in the fourth swim-lane of each workflow diagram. This alternative approval does not alter the assessment process or required documentation but does provide the opportunity, at the discretion of the CIO and Deputy CIO (DCIO) as the Authorizing Officials (AOs), to evaluate a system or service and accept the risk of using that service after reviewing the provided SSP and Privacy Impact Assessment (PIA). While not the preferred approach for new cloud service acquisitions, this approach may be used at the discretion of the NOAA CIO in the event that mission requirements cannot be met with a FedRAMP authorized cloud service. This process will be tailored to the type of cloud service (e.g., SaaS, PaaS, IaaS) and will use all available vendor security documentation to assess risk. The AO will use the Security Authorization Report (SAR) and any resulting Plan of Action & Milestones (POA&Ms) to make an authorization decision. Once an authorization has been granted, systems will enter into the continuous monitoring phase described in this document.

NOTE: System authorization is granted on a system-by-system basis, and AO acceptance of risk may require detailed mitigation and remediation plans. Authorization is time-limited, and dependent on the timely execution of any related POA&Ms.

3 Purpose The purpose of this SOP is to help guide NOAA consumers of cloud services with the processes, policies and support needed to properly manage risks inherent to cloud computing. This document will also assist in meeting the security compliance standards, best practices, and recommendations provided by NOAA CSD, DOC, DoD, and NIST to achieve authorization for use of cloud-based IaaS, PaaS, and SaaS.

4 Scope and Applicability The policies and procedures in this document, and its appendices, apply to all current and future state NOAA information resources and information systems hosted by CSPs. NOAA information includes data that is owned, sent, received, or processed by NOAA or third parties on behalf of NOAA and includes information in either physical or digital form. NOAA information systems include any combination of IaaS, PaaS, SaaS that handle NOAA information.

Any NOAA LO or SO that intends to develop, operate, or maintain NOAA applications or data in any CSPs environment must comply with the authorization processes detailed in this document in accordance with NOAA and FedRAMP policies.

Approval to acquire cloud services, and the selection of associated system owners and system boundaries are outside of the scope of this document. The authorization boundary establishes the scope of protection for an information system (i.e., what the organization agrees to protect under its direct management or within the scope of its responsibilities) and is established as a task in the RMF. The authorization boundary includes people, processes, and information technologies (i.e., system elements) that are part of each system supporting the organization’s missions and business functions. Establishing meaningful authorization boundaries for systems and common controls is one of the most important



Version 2.3 10

risk management activities. The process of working with system owners and selecting the appropriate system boundaries is conducted prior to the authorization process.

5 Responsibility The intended audience of this document are system planners, program managers, technologists, and others adopting cloud computing as consumers or providers of cloud services. As such the roles and responsibilities for each are detailed in the section below and also depicted in the FedRAMP Agency Authorization Playbook 12.

The responsibilities of both the organization and the cloud provider vary depending on the service model. Organizations consuming cloud services must understand the delineation of responsibilities over the computing environment and the implications for security and privacy. Assurances furnished by the cloud provider to support security or privacy claims, or by a certification and compliance review entity paid by the cloud provider, should be verified whenever possible through independent assessment by the consuming organization. For example, some of the more mature service providers such as Amazon Web Services (AWS) have developed shared security models that delineate responsibilities of the vendor and the customer.13

Understanding the policies, procedures, and technical controls used by a cloud provider is a prerequisite to assessing the security and privacy risks involved. It is also important to comprehend the technologies used to provision services and the implications for security and privacy of the system. Details about the system architecture of a cloud can be analyzed and used to formulate a complete picture of the protection afforded by the security and privacy controls, which improves the ability of the organization to assess and manage risk accurately, including mitigating risk by employing appropriate techniques and procedures for the continuous monitoring of the security state of the system.

5.1 Stakeholders

CSD’s Risk Management Office is responsible for ensuring NOAA compliance with the NIST 800-37 RMF that was written in response to FISMA Public Law (PL) 107-347. This Division’s policies inform the CSD Concept of Operations (CONOPS) and other cybersecurity related operating procedures.

The IT Security Officer (ITSO) will be the LO’s or OCIO’s primary point of contact and initial authorizing resource for cloud services. Supporting the system owner requesting cloud services, the ISSO will help design, implement, and maintain IT system security controls and a continuous monitoring program consistent with DOC/NOAA, and government-wide laws, regulations, policies, procedures, and standards.

The LO ISSO also serves as a principal advisor to the Security Officer (SO) on all matters, technical and otherwise, involving the security of an information system. In close coordination with the SO, the ISSO often plays an active role in the monitoring of a system and its environment of operation to include developing and updating the security plan, managing and controlling changes to the system, and assessing the security impact of those changes. The ITSO and ISSO are responsible for the validation and

12 https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook.pdf 13 https://aws.amazon.com/compliance/shared-responsibility-model



Version 2.3 11

initial approval of the IaaS, PaaS, or SaaS system. Based on the evaluation and recommendations for authorization assessment from the LO ITSO and ISSO, CSD will conduct a full assessment of the authorization package.

The OCIO CSD is responsible for the assessment of all cloud systems that have been approved by a LO’s Security Officer. CSD’s role throughout the security assessment and authorization process are captured in Appendix A – C workflows and detailed in internal policies. The monitoring process and additional information on cloud security operations for NOAA Cloud services are included in the Enterprise Cloud CONOPS.

CSD Operations is responsible for the monitoring of on-premise and cloud systems. The operations team has processes in place to use current Network and Security Operations Center services to provide logging and system monitoring capabilities for cloud systems and services. Additionally, CSD's Operations Team will implement and maintain cloud access security broker (CASB) functions for NOAA Cloud services. The CASB tools and processes are under development. Links to the approved documentation regarding CASB and the process of integrating new cloud systems into operations will be updated in this SOP when available.

In summary, CSD’s responsibility is to provide consistent, repeatable processes and assist in the secure incorporation and monitoring of cloud services into NOAA’s operating environment. As such, CSD has the responsibility of evaluating all risks and their impacts to NOAA employees, mission, information, and information systems. CSD’s recommendations will be aligned to the authorization paths identified in Section 2.8: Authorization for Cloud Services and may include denial of authorization if the cloud system poses risks that cannot be sufficiently remediated or accepted in the absence of known remediation.

NOAA specific roles and functions such as the ITSO, Risk Executive Function, Risk Management Officer, and Line Office Senior Agency Information Security Officer are integral to the enforcement and mitigation of risk provided by this operating procedure. Additional details on roles and responsibilities can be found in the NOAA IT Security Manual.

6 Policy NOAA CSD Policies

A. NOAA OCIO and CSD will be guided by the NOAA RMP, an integrated enterprise-wide decision structure for cybersecurity risk management and the Information Technology Security Manual to govern the overall Cloud Authorization process prescribed in this operating procedure

B. The cybersecurity requirements for NOAA information types and information technology systems will be managed through the RMF consistent with the principles established in NIST SP 800-37.

a. The RMF must satisfy the requirements of subchapter III of chapter 35 of Title 44, U.S.C., also known and referred to in this procedure as the “Federal Information Security Management Act (FISMA) of 2002”.

C. NOAA must meet the standards required by the OMB and the Secretary of Commerce, pursuant to FISMA and section 11331 of Title 40, U.S.C.



Version 2.3 12

D. NOAA OCIO and Line Office cloud and on-premise systems must be categorized in accordance with FIPS 199 for non-NSS or in accordance with Committee on National Security Systems Instruction (CNSSI) 1253 (Reference (e)) for NSS systems, implement a corresponding set of security controls from NIST SP 800-53, use assessment procedures from NIST SP 800-53A (Reference (g)), and overlay implementation guidance, and assessment procedures found in this operating procedure. Specifics on the categorization of systems and data are provided in Section 7: Procedure.

E. Each system must have an AO, ITSO, and ISSO responsible for authorizing the system’s operation based on achieving and maintaining an acceptable risk posture.

F. Each system must have a valid ATO signed by the AO and re-assessed based on continuous monitoring guidance.

G. The evaluation and acceptance of existing JAB P-ATO and non-NOAA FedRAMP system authorizations will be implemented to the maximum extent possible. Refusals must be timely, documented, and reported to the responsible ITSO and senior information Security Officer.

H. A POA&M must be developed and maintained to address known vulnerabilities in the cloud system.

I. Continuous monitoring capabilities will be implemented to the greatest extent possible. J. The RMF process will inform acquisition processes for all NOAA IT, including requirements

development, procurement, development and operations.

Additional Department of Commerce Policies

DOCITSBP, Annex C-10, FedRAMP Applicability This policy established criteria and guidelines to assist the DOC bureaus in identifying DOC cloud services requiring FedRAMP compliance. These requirements apply to all unclassified low and moderate information systems, Trusted Internet Connections (TIC) and layer 2 services owned by or operated on behalf of DOC where the department has legal and/or contractual authority to dictate requirements.

DOCITSBP, Annex C-5, Risk Management Framework (RMF) The purpose of this policy is to establish requirements for implementation of the RMF as defined by NIST SP 800-37.

7 Procedure Cloud computing presents unique requirements compared to the traditional IT contracts and by understanding these unique requirements and following the proposed recommendations, LOs can implement cloud computing contracts that deliver better outcomes at a lower cost. In acquiring a cloud service, LOs should begin by defining their mission needs and specific requirements for cloud services. Where applicable, the LO should align their cloud acquisition approach to broader departmental cloud adoption/migration strategies.

To help NOAA systems owners through the authorization process, high-level workflow diagrams are included in this document in Appendix A – C and can be found on the NOAA Cloud site under the security artifacts. The workflows depict the tasks and activities for each of the three authorization paths aligned to the responsible stakeholder for each activity. The supporting reference documents,



Version 2.3 13

templates, and activities are detailed in this section, and in the appendices, to assist in completing either FedRAMP or NOAA authorization.

The tasks for authorization detailed in the subsections that follow are:

1. Receive approval from the NOAA Enterprise Cloud Governance Subcommittee (NCGS) to proceed with security assessment

2. Review NOAA Service Catalog and FedRAMP Marketplace for any existing authorization (links provided in Appendix E)

3. Begin authorization process for NOAA/FedRAMP, FedRAMP, or New Cloud Systems 4. Develop schedule with planned date for authorization approval 5. Collect/Develop system security documents 6. Implement and test controls where applicable 7. ITSO/ISSO review and approval of authorization package 8. CSD review and approval of authorization package 9. Executive (Authorizing Official(s)) Briefing and approval/sign off 10. Certified Software Asset Manager (CSAM) and configuration management database updates 11. Begin continuous monitoring

7.1 Cloud Readiness Assessment Checklist

The Preliminary Cloud Readiness Assessment Checklist provided by the Enterprise Cloud Governance Subcommittee (ECGS) is a helpful set of questions intended to help navigate the process of deploying cloud services and decrease the time to complete the authorization process by identifying the path of greatest success based on the availability of data about the system in review. The checklist presents common questions that the system owner will need to work the CSP answer as a pre-evaluation activity to determine if the proposed service is the right fit for both the business need and Agency’s security requirements. It is suggested that the Cloud Readiness Assessment checklist be reviewed prior to the submission of any cloud service to ECGS. CSD is not authorized to support the assessment of any cloud applications or services without approval.

7.2 Develop Schedule

Whether assessing existing cloud services or planning in advance for the acquisition of new cloud services, developing a schedule for completing each of the major tasks above is an imperative. The process of receiving the ATO cloud services requires collaboration and coordination between various teams across OCIO, LOs, and 3PAOs. CSD will provide Service Level Agreements (SLAs), anticipated completion dates, and online progress tracking for each system’s review based on the complexity of the system and prioritization of activities that may be driven by guidance from the NCGS or AO. *The FedRAMP PMO is also available to provide feedback on a preliminary schedule. 14

14 https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook.pdf



Version 2.3 14

7.3 Document

The authorization process begins with a kick-off discussion among all stakeholders. Following kick-off, the CSP and assessor begin progressing through one of the following process workflows: (1) NOAA FedRAMP authorized; (2) FedRAMP authorized; or (3) new cloud services. Throughout development of the FIPS 199, collecting artifacts, populating FedRAMP templates, and the assessment process, the objective is to use (to the extent possible) lessons learned from authorizations of similar applications and services and consolidate security documentation within the security authorization package identifying any risks that may require additional evaluation.

7.3.1 Leverage FedRAMP Security Packages

One of the primary benefits of FedRAMP is the ability for Agencies to reuse authorization packages and to leverage the work that has already been completed “do once, use many times” framework. NOAA LO/SO should review the list of Agencies’ available security packages before attempting to acquire services from a CSP that is not in the FedRAMP Marketplace.

FedRAMP maintains a Secure Repository of FedRAMP security packages and templates for Agencies to review when making procurement decisions. FedRAMP provides a ‘Package Access Request Form’ on the site for each authorized service in the FedRAMP Marketplace.

In addition to SSP templates, the FedRAMP website provides standard risk and controls templates for assessing baseline controls for High, Moderate, and Low impact categories. These templates are designed to help to drive consistency in annual assessment testing. The templates have been completed by CSPs listed as authorized in the FedRAMP Marketplace and are maintained by the FedRAMP PMO and supporting organizations for public access. The templated control worksheets combined with any inherited controls from the determined system boundary can be used to test selected baseline controls per required test procedures and document any control deficiencies and findings. There are also templates to guide continuous monitoring requirements and activities. Click here or copy the link from the footnote below15 to access the most current list of FedRAMP templates hosted on the fedramp.gov site.

High-Impact Level. While the majority of cloud services are categorized as low or moderate impact, a significant portion of IT budgets throughout the government are dedicated to protecting against unauthorized access to high-impact systems and data. To address this vulnerability for cloud systems, FedRAMP added controls based on NIST SP 800-53 R4 to the moderate impact control baseline to create the high baseline. The JAB also provided guidance on how to address the additional requirements and enhancements in concert with the CSP for high systems. *Moderate and low impact systems can be included in high-impact enclaves and inherit the same controls, but the reverse is not an acceptable practice.

Moderate Impact Level. The majority of cloud applications used by the government are categorized as moderate, meaning the loss of confidentiality, integrity, and availability would result in serious adverse effects on an Agency’s operations, assets, or individuals. Serious adverse effects could include significant operational damage to Agency assets, financial loss, or individual harm that is not loss of life or physical. With over 300 controls included in the moderate impact baseline, it is strongly encouraged to model

15 https://www.fedramp.gov/templates/



Version 2.3 15

new SSPs after similar authorized systems starting with the controls that we selected for the similar system, augmenting the controls where necessary.

Low Impact Level. Low Impact is most appropriate for cloud services where the loss of confidentiality, integrity, and availability would result in limited adverse effects on an Agency’s operations, assets, or individuals. FedRAMP currently has two baselines for systems with Low Impact data: (1) LI-SaaS Baseline and (2) Low Baseline. Required security documentation is consolidated and the requisite number of security controls needing testing and verification are lowered relative to a standard Low Baseline authorization.

Tailored Low Impact Level (Designated for SaaS applications). The FedRAMP Tailored Low baseline (LL-SaaS) provides a minimum set of security control requirements to determine the risks associated with authorizing specific low impact cloud applications (e.g., small scale cloud applications that assist the government in doing business, but that do not directly impact the government’s mission needs). This designation does not apply to any system that stores Personally identifiable information (PII). As required by law, Authorizing Officials have the ultimate responsibility of determining if additional security controls are required to remain in compliance with Agency-specific policies, procedures, and their own risk tolerance. However, we believe the FedRAMP program, including our goals for Tailored, is a key part of issuing an informed, risk-based ATO. Additional information on requirements for the LI-SaaS baseline can be found on the FedRAMP Tailored website.

The System Owner and supporting ISSO has ownership of the following activities and documents:

● Maintain open communication with the CSP to provide clarity and answer questions regarding NOAA’s SOP and compliance requirements

● Coordinate the approval and communication with the governance board throughout the authorization process

● (For all systems and services not currently authorized by NOAA) Prepare cloud service security authorization package at the appropriate impact level which includes the preparation, documentation, implementation, testing and reporting of the items listed below. It is recommended that the assessment starts with concurrently beginning the Privacy Threshold Assessment (PTA), Supply Chain Risk Assessment (SCRA) and SSP. By conducting the PTA and SCRA early in the assessment processes the System Owner can avoid unnecessary modifications, POA&Ms, and delays downstream. The full list of required documents and assessments required for the authorization package are detailed below: ○ Privacy Threshold Assessment (PTA) determined whether or not a system has privacy

implications that necessitate additional privacy compliance documentation such as the PIA. NOAA’s existing PTA document will be used for the assessment in accordance with the Annual Review of Privacy Threshold Analysis for NOAA FISMA System memorandum released 31 October 2012.

○ Systems Security Plan (SSP) detailing the CSP’s system security environment including controls that are shared or exclusively NOAA’s responsibility.

○ Security Assessment Plan (SAP) detailing the independent assessor's approach for vulnerability testing of implemented controls included in the cloud system.

○ Security Assessment Report (SAR) detailing the independent assessor’s findings and recommendations pursuant to performance of the SAP.



Version 2.3 16

○ Plan of Action and Milestones (POA&M) detailing the CSP's and independent assessor’s approach to addressing or identifying system vulnerabilities as well as the approach to continuous monitoring of the system. POA&M reporting is a critical component in the evaluation of systems for NOAA Authorization.

○ Supply Chain Risk Assessment (SCRA) request detailing the system under evaluation and requisite information for approval for third party SCRA.

As a part of the documentation process the ISSO and ITSO perform the final review of a security authorization package before submitting to CSD. While the majority of the documentation efforts are initiated by the system owner, the Cloud Governance Committee also serves as a pool of resources to support system owners in resolving issues, refining controls, and sharing ideas to improve the overall authorization procedure for NOAA.

7.4 Complete Assessment

OCIO CSD will lead the evaluation of the cloud system’s full accreditation package once notified by the system owner that the full package is ready for review and the ITSO has signed off on the completeness of the security package and awareness of risk(s) given the preliminary findings. The request will be added to CSD compliance review backlog and resources will be assigned to lead the evaluation and coordinate with the system owner.

The evaluation will focus on determining the overall risk that NOAA will assume with the authorization of the identified information system or service. The SAR, SSP, PTA, and SCRA findings will be reviewed against the documented POA&Ms and against precedent set by applications and services previously authorized by NOAA. Feedback from the evaluation will be provided in the documents and in a summary report.

7.5 Authorization

Once the analysis of risks, evaluation of submitted reports, and resolution of any points of concern are completed, CSD with the system owner will present a consolidated briefing to the NCGS with recommendations for next steps. The recommendation will be one of the following:

● Submit full package to FedRAMP for Agency ATO16 ● Submit full package to FedRAMP for JAB review and FedRAMP ATO ● Submit full package to CIO for NOAA Authorization ● Establish timeline to address POA&Ms and reevaluate for authorization

Once recommendations have been reviewed by the NCGS, a final decision on authorization and acceptance of risk is made by the NOAA AO and all artifacts are updated in CSAM using the provided naming conventions and guidelines.

7.6 Continuous Monitoring and ATO Maintenance

16 https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook.pdf



Version 2.3 17

7.6.1 Monitoring Cloud Systems

An effective monitoring program can significantly reduce the overall cost and level of effort of authorization actions. Most changes to a system, or its environment of operation, can be handled through the continuous monitoring program and ongoing authorization. As a part of the FedRAMP requirements, NOAA must implement a continuous monitoring program for any deployed cloud system and assume responsibility for the continuous monitoring and ongoing authorization of the systems that are in use. Although the first Agency to grant an ATO for a cloud service is responsible for ensuring that the CSP fulfills its responsibilities to perform continuous monitoring, it is the responsibility of all leveraging Agencies to review continuous monitoring deliverables and artifacts from CSPs. NOAA also includes the evaluation and resolution of POA&Ms as a key component of continuous monitoring. The timely resolution of POA&Ms improves the Agency’s risk posture and demonstrates continuous improvement in efforts to modernize NOAAs IT platform. Guidance and timelines for milestone review and resolutions are provided in the NOAA POA&M Management document.

7.6.2 Maintaining an ATO

Led by the system owner and ISSO, evidentiary information must be provided to the AO quarterly, or on an as-needed frequency, after authorization is granted per NOAA guidelines for review of the SSP. In addition, annual assessments will be conducted on shared and NOAA system specific security controls. Additionally, FedRAMP approved 3PAO must be used for annual assessments of authorized cloud system(s) and to evaluate the impact of changes a CSP makes to its cloud system. Every third year of operation system owners are also responsible for conducting a PTA and subsequent PIA if substantive changes are evident in the handling of PII.

7.6.3 Revocation of an ATO

When a CSP fails to maintain adequate continuous monitoring as mandated, FedRAMP initiates an escalation for one of the following: ● Detailed Finding Review ● Corrective Action Plan (CAP) ● Suspension ● Revocation When ATO is suspended or revoked, FedRAMP will notify each known leveraging Agency and require the CSP to ensure that the known leveraging agencies match the CSP’s customer list for the impacted system. However, ATO revocation does not automatically result in revocation of each leveraging Agency’s ATO. FedRAMP updates the system’s status on the FedRAMP Marketplace to reflect the status of any escalation. Each leveraging Agency’s AO must review the circumstances of revocation and determine the status of the ATO. For NOAA authorized systems, ECGS and AO have the authority to revoke the Agency-specific authorization for the reasons provided above. The evaluation and authorization of a cloud application or service following a suspension or revocation is also at the discretion of CSD, the AO, and governance board.



Version 2.3 18

Appendix A: Cloud System Authorization Workflow – NOAA/FedRAMP Authorized

Figure 1: Cloud System Authorization Workflow - NOAA/FedRAMP Authorized



Version 2.3 19

Appendix B: Cloud System Authorization Workflow – FedRAMP Authorized

Figure 2: Cloud System Authorization Workflow - FedRAMP Authorized



Version 2.3 20

Appendix C: Cloud System Authorization Workflow – New Cloud System Authorization

Figure 3: Cloud System Authorization Workflow - New Cloud System Authorization



Version 2.3 21

Appendix D: List of Acronyms AO Authorizing Officials

ATO Authority to Operate

AWS Amazon Web Services

CASB Cloud access security broker

CIO Chief Information Officers

CONOPS Concept of Operations

CSAM Certified Software Asset Manager

CSD Cyber Security Division

CSO Cloud Service Offering

CSP Cloud Service Provider

DCIO Deputy Chief Information Officer

DHS Department of Homeland Security

DOC Department of Commerce

DoD Department of Defense

ECGS Enterprise Cloud Governance Subcommittee

FedRAMP Federal Risk and Authorization Management Program

FIPS Federal Information Processing Standard

FISMA Federal Information Security Management

GSA General Services Administration

IaaS Infrastructure as a Service

ISSO Information System Security Officer

IT Information Technology

ITSO IT Security Officer

JAB Joint Authorization Board

LO Line Office/Services Office

NCGS NOAA Enterprise Cloud Governance Subcommittee

NIST National Institute of Standards and Technologies

NOAA National Oceanic and Atmospheric Administration

NSS National Security Systems

OCIO Office of the Chief Information Officer



Version 2.3 22

OMB Office of Management and Budget

PaaS Platform as a Service

PIA Privacy Impact Assessment

PII Personally Identifiable Information

PL Public Law

PMO Program Management Office

POA&M Plan of Action & Milestones

PTA Privacy Threshold Assessment

RMF Risk Management Framework

RMP Risk Management Program

SaaS Software as a Service

SAF Security Assessment Framework

SAP Security Assessment Plan

SAR Security Authorization Report

SCRA Supply Chain Risk Assessment

SCRM Supply Chain Risk Management

SO Security Officer

SOP Standard Operating Procedure

SP Special Publication

SSP System Security Packages

TIC Trusted Internet Connections



Version 2.3 23

Appendix E: References

E.1 Legislation, Policies, and Directives

● Federal Information Security Management Act (FISMA) of 2002 [Title III, PL 107-347] ● Federal Information Security Modernization Act of 2014 [Public Law No: 113-283]

(12/18/2014)Freedom of Information Act As Amended in 2002 [PL 104-232, 5 U.S.C. 552] ● Homeland Security Presidential Directive-7, Critical Infrastructure Identification, Prioritization and

Protection [HSPD-7] ● Internal Control Systems [OMB Circular A-123] ● Management of Federal Information Resources [OMB Circular A-130] ● Management’s Responsibility for Internal Control [OMB Circular A-123, Revised 12/21/2004] ● Privacy Act of 1974 as amended [5 U.S.C. 552a] ● Protection of Sensitive Agency Information [OMB M-06-16] ● Records Management by Federal Agencies [44 U.S.C. 31] ● Responsibilities for the Maintenance of Records About Individuals by Federal Agencies [OMB

Circular A-108, as amended] ● Security of Federal Automated Information Systems [OMB Circular A-130, Appendix III] ● DOC ITSBP, Annex C-2 Remote Access, September 2009. ● DOC ITSBP, Annex B-5 Security Configuration Checklist Program January 2012. ● DOC ITSBP, Annex C-5 Risk Management Framework (RMF) 2012. ● DOC ITSBP, Annex C-10 FedRAMP Applicability, March 29, 2016. ● DOC ITSBP, Annex C-11 Incident Response Policy, April 2017. ● CIRCULAR NO. A-130 TO THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES SUBJECT:

Managing Information as a Strategic Resource https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf

● Security Authorization of Information Systems in Cloud Computing Environments https://www.fismacenter.com/fedrampmemo.pdf

● H.J.Res.31 - Consolidated Appropriations Act, 2019, Division C, Title V, SEC. 514 (formerly Consolidated Appropriations Act, 2018, SEC. 514)

● https://www.congress.gov/bill/116th-congress/house-joint-resolution/31/text

E.2 Guidance

● NOAA Cybersecurity Division Concept of Operations (CONOPS FINAL_08-10-2018) ● OMB M-02-01: Guidance for Preparing and Submitting Security Plans of Action and Milestones,

October 2001. ● OMB M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of

2002



Version 2.3 24

● OMB M-01-05: Guidance on Inter-Agency Sharing of Personal Data – Protecting Personal Privacy ● NIST Special Publication 800-145 The NIST Definition of Cloud Computing ● https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf ● NIST SP 800-30 Rev. 1 Guide for Conducting Risk Assessments ● https://doi.org/10.6028/NIST.SP.800-30r1 ● NIST 800-37 Rev. 2 Risk Management Framework (NIST RMF) https://doi.org/10.6028/NIST.SP.800-

37r2 ● NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information

Systems and Organizations ● https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf ● ● FedRAMP Security Assessment Framework Version 2.4 November 15, 2017 ● https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Assessment_Framewo

rk.pdf ● FedRAMP Annual Assessment Guidance ● https://www.fedramp.gov/assets/resources/documents/CSP_Annual_Assessment_Guidance.pdf ● Guide for Developing Security Plans for Federal Information Systems [NIST SP 800-18] ● Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life

Cycle Approach [NIST SP 800-37, Revision 1] ● Guide for Mapping Types of Information and Information Systems to Security Categories [NIST SP

800-60, Revision 1] ● Information Security Continuous Monitoring for Federal Information Systems and Organizations

[NIST SP 800-137] ● Managing Information Security Risk: Organization, Mission, and Information System View [NIST SP

800-39] ● Minimum Security Requirements for Federal Information and Information Systems [FIPS Publication

200] ● Department of Interior Cloud Program: Foundation Cloud hosting Services

https://www.doi.gov/cloud ● Department of Defense Instructions Number 8510.01 Risk Management Framework (RMF) for DoD

Information Technology (IT) https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001_2014.pdf

● FedRAMP Controls Baseline by Impact Level https://www.fedramp.gov/assets/resources/documents/FedRAMP_Moderate_Security_Controls.xlsx

● DOC Supply Chain Risk Management (SCRM) Best Practices https://connection.commerce.gov/reference-and-other-resources/sop-supply-chain-risk-management-best-practice



Version 2.3 25

● DOC ITSBP, Annex C-9: Pre-Acquisition Supply Chain Risk Assessment https://connection.commerce.gov/sites/connection.commerce.gov/files/media/files/2015/citr-023_pre_acquisition_scr_assessment.pdf

Useful Links:

FedRAMP Marketplace: https://marketplace.fedramp.gov/#/products?sort=productName

NOAA IT Service Catalog: