...

A&A Introduction

Welcome to the NCI Information System Security Assessment System Assessment and Authorization (SAA&A) information and guidance page. The information provided here is intended to supplement guidance provided by the National Institute of Standards and Technology (NIST) and NIH to provide best practices for managing the Security Assessment and Authorization (SAthe A&A ) process (SAA&A was formerly called security assessment and authorization (SA&A) and certification & accreditation(C&A) before that).

Government project officers are responsible for ensuring their contractor-hosted or cloud-hosted applications are authorized to operate (ATO) in accordance with FISMA. This includes all planning, testing, and continuous monitoring activities associated with the system’s life cycle.  Most importantly, this means that you are responsible for securing the resources to conduct required security testing, which for moderate impact systems means using an independent third party assessor qualified to conduct FISMA/FedRAMP audits.  NCI CBIIT does not develop required FISMA/FedRAMP security documentation (except for assisting with the FIPS-199, e-Authentication, and Privacy Impact Assessment), or conduct any of the security testing for applications that are operated exclusively at contractor locations or hosted in the cloud. The extent of CBIIT’s support for exclusively contractor- and cloud-hosted systems is advisory only.

SAA&A is the methodology by which an organization establishes and then demonstrates sound, risk-based security posture for a specific system. We hope that the information provided on the following pages is useful to a variety of users including NCI information system owners, project officers and mangers, contracting officers, software developers, security officers, and security practitioners. It is intended to help you better understand, plan for, and execute the SAA&A process as it applies to your situation (i.e., based on your system's operating location), along with the requirements and expectations for completing the SAA&A. We have also tried to provide you with the tools, templates, and guidance to facilitate the SAA&A process.

Who is this information intended for?

The following pages are intended for individuals associated with the design, development, implementation, operation, maintenance, and disposition of NCI systems hosted by a third party (e.g., hosting contractor, university, hospital, cloud service provider, etc.). This typically includes, but is not limited to: System owners, business owners, program and project managers, procurement officials, IT contractors (hosting providers), system developers, and security practitioners.

What is a "Federal Information System" (and what isn't)?

Before getting into specific SAA&A process and guidance, it is first helpful to review exactly what constitutes a "Federal Information System" so that you have a better understanding of when FISMA applies and when it may notknow when FISMA or, perhaps, another federal security assessment frameworks (e.g. FedRAMP, CUI) may apply. The following definitions and clarification clarifications are based on guidance provided by the Office of Management and Budget (OMB) as well as internal from subsequent interpretations by OMB on the matter that have been published since 2001 when FISMA became law.

OMB initially defined an information system in 2001 a Federal Information System as:  A discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual. (defined in OMB circular A-130, (6)(q)). OMB also later clarified that Federal Information Systems are those that are used or operated by an agency or by a contractor of an agency, or other organization on behalf of an agency (44. U.S.C. § 3544(a)(1)(A)).

Since these definitions can be somewhat vague or misinterpretedconfusing, many people often assume that a federal information system only includes those that are physically housed and/or operated within a federally-owned or federally-operated facility (i.e., government-owned/government-operated (GOCO)), and that any other information system that is housed elsewhere (i.e., at a contractor's location, at a hosting provider's location, or by a in the cloud service provider) are not federal information systems. This is not necessarily the case. In fact, a better determination of federal system vs. non-federal can be made by examining accountability for and control of a system's information and who is directing , and whether the government directed the establishment or operation of the system. For example, if an agency of the federal government has directed or mandated (ie.eg., through a contractual arrangement or through other means of federal funding – sometimes to include grants) support), the creation or operation of an information system, or if the government owns will have access to the system or will likely take possession of the data that is used in the system, then FISMA would apply to that it is probably a federal information system. Contracting with a non-federal organization to host or operate your system does not exclude the system from FISMA federal regulations. If you are uncertain about whether yours is a federal information system, please contact the the NCI ISSO's office for clarification.

...

*Please note that even if yours is not an IT system, federal privacy and OMB regulations may still apply, especially if you are collecting information from private citizens or contractors, including, for example, through online or paper surveys, via clinical trials, etc. You should always consult the OMB clearance office and the NCI Privacy Coordinator for additional guidance.

Overview of FISMA and

...

A&A

The Federal Information Security Modernization Act (FISMA) of 2014 mandates that all federal information systems — including all NCI information systems — must be formally assessed and authorized to operate (ATO) using the National Institute of Standards and Technology's (NIST) Risk Management Framework (RMF). The RMF is the model used to conduct federal system security assessment and authorizations (SAA&A), so the terms RMF and SAA&A may be used interchangeably. NIST documented the RMF in Special Publication 800-37 rev. 2, Risk Management Framework for Federal Information Systems and Organizations: A Security System Life Cycle Approach for Security and Privacy. The RMF is also supported by several additional NIST special publications (SP) guides that are designed to work in conjunction with 800-37 rev. 2. To further help system owners implement the RMF, NIH and NCI have also developed agency-specific SAA&A guidance, templates, and sample materials, which are discussed in the following SAA&A process guidance pages.

NIST Risk Management Framework

NIST's Risk Management Framework (RMF) is the security risk assessment model that all federal agencies (with a few exceptions) follow to ensure they comply with FISMA. The RMF is formally documented in NIST's special publication 800-37 (SP 800-37) and describes a model for continuous security assessment and improvement throughout a system's life cycle. The RMF comprises six (6) steps as outlined below.

...