Amend 00001 _ J008 _ FY20 FAA Security Authorization Handbook.pdf

U.S. Department of Transportation Federal Aviation Administration

Fiscal Year 2020 (FY20) Security Authorization Handbook

Version 1

October 2019

Federal Aviation Administration 800 Independence Avenue SW, Washington, DC 20591

FY20 Security Authorization Handbook

This Page Intentionally Left Blank

Issued November 2019 III IS&P Security Compliance Division

Change Information Page

Version Date Pages Affected Description Version 1 11/05/2019 All Initial Release

Issued November 2019 IV

This Page Intentionally Left Blank

Issued November 2019 V IS&P Security Compliance Division

Table of Contents

1 INTRODUCTION

1.1 BACKGROUND

1.2 PURPOSE

1.3 APPLICABILITY

1.4 FY 2020 ENHANCEMENTS

1.5 SECURITY HANDBOOK STRUCTURE

1.6 IDENTIFYING ROLES AND RESPONSIBILITIES

1.7 SUMMARY

2 THE NIST RISK MANAGEMENT FRAMEWORK (RMF)

2.1 NIST RMF BACKGROUND

2.2 APPLICABILITY

2.3 KEY DOCUMENTS

3 INITIAL SECURITY AUTHORIZATION PROCESS

3.1 OVERVIEW

3.2 RMF STEP 1: CATEGORIZE INFORMATION SYSTEMS

3.2.1 SYSTEM CHARACTERIZATION DOCUMENT

3.2.1.1 System Type Designation

3.2.1.2 Contractor System Designation

3.2.1.3 Security Categorization

3.2.1.4 Digital Identity (formerly E-Authentication)

3.2.1.5 Identification and Authentication/Personal Identity Verification (PIV)

3.2.1.6 System Authorization Boundary

3.2.1.7 System Interconnections

3.2.2 PRIVACY RISK SUMMARY

3.2.3 PRIVACY PLAN (PRIVACY COMPLIANCE DOCUMENTS)

3.2.3.1.1 Privacy Threshold Assessment (PTA)

3.2.3.1.2 Privacy Impact Assessment (PIA)

3.2.3.1.3 Privacy Continuous Monitoring – Annual Privacy Plan Review (CM)

3.2.1.1.1 System of Records Notice (SORN)

3.2.1.1.2 System Disposal Assessment (SDA)

3.3 RMF STEP 2: SELECT SECURITY CONTROLS

3.3.1 SYSTEM SECURITY PLAN

Issued November 2019 VI IS&P Security Compliance Division

3.3.2 ENTERPRISE COMMON CONTROLS

3.3.2.1 Planned FY20 AIT Common Control Inheritance

3.4 RMF STEP 3: IMPLEMENT SECURITY CONTROLS

3.4.1 REVISED OMB A-130 CONSIDERATIONS

3.4.2 DOT CYBERSECURITY COMPENDIUM CONSIDERATIONS

3.4.3 SECURITY BASELINE CONFIGURATION CHECKLISTS

3.4.4 INFORMATION SYSTEM CONTINGENCY PLAN

3.4.5 INFORMATION SYSTEM CONTINGENCY PLAN TEST PLAN AND RESULTS

REPORT

3.5 RMF STEP 4: ASSESS SECURITY CONTROLS

3.5.1 SECURITY CONTROL ASSESSMENT (SCA)

3.5.2 VULNERABILITY SCANNING

3.5.2.1 Penetration Testing (CA-8)

3.5.2.2 Scan Provisioning Requirements

3.5.2.3 Vulnerability Scan Results

3.5.2.4 False Positive Vulnerability Scan Results

3.5.2.5 Vulnerability Remediation Timeframes

3.5.2.6 Vulnerability Scanning and Remediation POA&M’s

3.5.3 SECURITY ASSESSMENT REPORT (SAR)

3.5.4 SECURITY CONTROL AND VULNERABILITY IDENTIFICATION

3.5.4.1 Threat Identification

3.5.4.2 Vulnerability Likelihood Rating

3.5.4.3 Adverse Impact Analysis

3.5.4.4 Risk Determination

3.5.4.5 Risk Assessment Results Documentation

3.5.5 PLAN OF ACTION AND MILESTONES (POA&M) & RISK ACCEPTANCE

3.5.5.1 Plan of Action & Milestone Workbook - Manual Assessment Only

3.5.5.2 Plan of Action & Milestone Workbook - CSAM Assessment Only

3.5 RMF STEP 5: AUTHORIZE INFORMATION SYSTEMS

3.6.1 SECURITY AUTHORIZATION EXECUTIVE SUMMARY

3.6.2 OBTAIN AUTHORIZATION

3.6.2.1 Signature Process

3.6.2.2 Security Authorization Package Review

4 INFORMATION SYSTEM CONTINUOUS MONITORING

Issued November 2019 VII IS&P Security Compliance Division

4.1 RMF STEP 6: MONITOR SECURITY CONTROLS

4.2 FAA ISCM STRATEGY

4.3 FOCUS AREAS FOR FY20

4.4 INFORMATION SYSTEM AND ENVIRONMENT CHANGES/TECH REFRESH . 66

4.5 SECURITY IMPACT ANALYSIS

4.6 CONFIGURATION MANAGEMENT AND CONTROL

4.7 ONGOING SECURITY CONTROL ASSESSMENTS

4.7.1 CONTINUOUS DIAGNOSTICS AND MITIGATION (CDM) PROGRAM

4.8 CORE CONTROLS

4.9 THREE-YEAR ASSESSMENT CYCLE

4.10 ANNUAL SECURITY CONTROL ASSESSMENT PROCESS

4.11 SECURITY STATUS REPORTING

4.12 ONGOING RISK DETERMINATION AND ACCEPTANCE

4.13.1 RISK RESPONSE AND ONGOING REMEDIATION ACTIONS

4.14 FISMA INVENTORY UPDATES

4.14.1 NEW SYSTEMS

4.14.2 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING

4.14.3 SYSTEM MERGERS

5 CSAM GUIDANCE

1.1. CSAM USEFUL REFERENCES

1.2. REQUESTING CSAM ACCOUNT

1.3. CSAM SECURITY AUTHORIZATION AREA

1.4. STATUS AND ARCHIVES AREA

1.5. CSAM SECURITY ASSESSMENT PROCESS CONSIDERATIONS

6. CLOUD SECURITY AND FEDRAMP GUIDANCE

6.1. Cloud Service Models

6.1.1. Software as a Service (SaaS)

6.1.2. Platform as a Service (PaaS)

6.1.3. Infrastructure as a Service (IaaS)

6.2. Shared Responsibilities of CSP and Customer

6.3. FedRamp Authorization Process

6.4. Leveraging vs. FedRAMP Agency ATO

6.5. Activities and Considerations for Sponsoring or Leveraging a FedRAMP ATO

Issued November 2019 VIII IS&P Security Compliance Division

6.6. FAA Cloud Services (FCS) and Application Authorization

APPENDIX A Applicable Laws, Standards and Guidelines .......................................... A-1

APPENDIX B Glossary ....................................................................................................... B-1

APPENDIX C Acronyms ................................................................................................... C-1

APPENDIX D Roles and Responsibilities ........................................................................ D-1

Issued November 2019 IX IS&P Security Compliance Division

List of Figures Figure 2-1: NIST Risk Management Framework (RMF) and Relationships to NIST Documents Figure 2-2: Key Sections of the Authorization Package Figure 2-3: FAA Document Process flow for Security Authorization Figure 3-1: C-I-A Triad Figure 6-1: Responsibilities: FAA vs. Cloud Service Provider

List of Tables Table 3-1: Document List Table 3-2: SCD Tasks Table 3-3: Privacy Compliance Documentation Tasks Table 3-4: SSSP Tasks Table 3-5: ISCP Documents Table 3-6: ISCP Test Plan and Results Tasks Table 3-7: ISCP TT&E Activities Table 3-8: SAR Tasks Table 3-9: Scanning Frequency Requirements Table 3-10: Vulnerability Remediation Timeframe Table 3-11: ATO NAS Vulnerability Remediation Timeframe Table 3-12: Common Threat Areas Definitions for Threat Identification and Analysis Table 3-13: Likelihood Rating Matrix Table 3-14: Level of Risk Example Table 3-15: Executive Summary Tasks Table 3-16: Signature Tasks Table 4-1: Readiness Requirements for Entering the Continuous Monitoring Phase Table 4-2: FAA Core Controls Table 6-1: Leveraging Existing FedRAMP ATO Table 6-2: Sponsoring FedRAMP Agency ATO

Issued November 2019 X

This page intentionally left blank

Issued November 2019 11 IS&P Security Compliance Division

1 INTRODUCTION

1.1 BACKGROUND

Security authorization (SA) is the official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls. The Authorizing Official (AO) accepts security responsibility for the operation of an assessed system and officially declares that it is authorized to operate.

Security authorization involves comprehensive testing and evaluation of security features (also known as security controls) of an information system. It addresses software and hardware security safeguards; considers procedural, physical, and personnel security measures; and establishes the extent to which a particular design (or architecture), configuration, and implementation meets a specified set of security requirements throughout the life cycle of the information system. It also considers procedural, physical, and personnel security measures employed to enforce information security policy.

An information system must be granted an Authority to Operate (ATO) before it becomes operational, and must be re-authorized at least every three (3) years, or whenever changes are made or events occur that affect the potential risk level of operating the system. Following the initial ATO, the system will be assessed annually. Unless a re-baseline, and subsequent complete assessment is required due to system changes, or vulnerability/threat-related events, the annual assessment will be a partial assessment, i.e. at least one-third of the security controls assessed, and the Year 3 assessment will be considered the system reauthorization. The ATO includes the AO formally acknowledging that the information system is being managed by an ongoing authorization process, and accepting the responsibility for performing all necessary activities associated with that process. NOTE: “Operational” is generally defined as whenever an information system begins processing real or live data.

A system is defined as any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions1. Systems also include specialized systems such as industrial/process controls systems, telephone switching and private branch exchange (PBX) systems, and environmental control systems. It can also be a combination of interacting elements organized to achieve one or more stated purposes. As further clarification, examples of systems may include: general and special-purpose information systems; command, control, and communication systems; crypto modules; central processing unit and graphics processor boards; industrial/process control systems; flight control systems; weapons, targeting, and fire control systems; medical devices and treatment systems; financial, banking, and merchandising transaction systems; and social networking systems.

NOTE: The interacting elements in the definition of system include hardware, software, data, humans, processes, facilities, materials, and naturally occurring physical entities.

The process for conducting a re-authorization is the same used to conduct the initial Security Authorization. The primary difference is that an initial Security Authorization should be started early in the development process while re-authorization will usually begin four (4) to six (6) months

1 NISTIR 7298, Revision 2, Glossary of Key Information Security Terms;

Issued November 2019 12 IS&P Security Compliance Division before the current ATO expires. The four (4) to six (6) month timeframe assumes that resources are available to start the security authorization process. Additional lead time may be needed for contracting or otherwise obtaining resources needed to conduct the security authorization. The process for conducting ongoing authorizations, i.e. continuous monitoring, is discussed later within this handbook.

Per NIST SP 800-37 Rev 2, Risk Management Framework for Information Systems and Organizations, a “type” authorization is an official authorization decision to employ identical copies of an information system or subsystem (including hardware, software, firmware, and/or applications) in specified environments of operation. A type authorization allows a single authorization package to be developed for an common version of an information system that is deployed to multiple locations, along with a set of installation and configuration requirements or operational security needs, Examples of type authorizations include: (i) an authorization of the hardware and software applications for a standard financial system deployed in several locations around the world; or (ii) an authorization of a common workstation or operating environment (i.e., hardware, operating system, middleware, and applications) deployed to all operating units within an organization.

The Department of Transportation (DOT) Office of the Chief Information Officer (OCIO) issued the DOT Department Cybersecurity Policy, Order 1351.37, as amended and the DOT Departmental Cybersecurity Compendium, as amended. These policies adopt the National Institute of Technology (NIST) Risk Management Framework (RMF) as the standard for the Department or supporting security authorization and continuous monitoring of security controls. FAA Order 1370.121, FAA Information Security and Privacy Program Policy, as amended, defines the FAA Information Security and Privacy Program and Policy. The order augments the DOT Compendium other DOT policy documents, and Federal Risk and Authorization Management Program (FedRAMP).

This FAA Security Authorization Handbook incorporates Office of Management and Budget (OMB), NIST, Federal Risk and Authorization Management Program (FedRAMP), DOT, and FAA requirements into the FAA authorization process. The security authorization process applies the RMF from NIST Special Publication (SP) 800-37, Risk Management Framework for Information Systems and Organizations, A System Life Cycle Approach for Security and Privacy, as amended.

1.2 PURPOSE

The purpose of this document is to facilitate implementation of the RMF and security authorization processes within the FAA. The Handbook is updated annually, in accordance with the Office of Management and Budget (OMB) Circular A-130 July 2016, FISMA, associated NIST Special Publications (SP), FAA, and DOT Cybersecurity Policy. The FAA Office of Information Systems Security and Privacy Service (IS&P) maintains the FAA Security Authorization Handbook document, hereafter referred to as the “Handbook.”

NOTE: All NIST documentation referenced in this document is available on the NIST Computer Security Division's Computer Security Resource Center Publication web page at http://csrc.nist.gov/publications/index.html.

1.3 APPLICABILITY

This Handbook applies to all FAA systems. It is required to be followed throughout a system’s lifecycle, including the system’s initial authorization (i.e. prior to the system going into production).

Continuous monitoring guidance, included in this handbook, applies to systems after completing their initial security authorization and meeting the criteria outlined in this handbook.

http://csrc.nist.gov/publications/index.html

Issued November 2019 13

1.4 FY 2020 ENHANCEMENTS

The FY20 version of the Handbook provides the following key enhancements:

• Incorporated requirements from FAA Order 1370.121, as appropriate;

• Please note that in FY20, the FAA will continue using the NIST SP 800-53 Rev. 4 Low, Moderate, and High Baselines, pending signed update of NIST SP 800-53 Rev 5, NIST SP 800-53B, and NIST SP 800-53A Rev. 5. There is no projected date at this time for release of the “final public draft”. LOB/SOs should begin planning processes to implement the identified security and privacy controls as incorporated into 1370.121. A memorandum is in place that define the phase-in timeline and related activities.

• Expanded Section 6 Cloud Security and FedRAMP Guidance to better differentiate and define cloud leverage and sponsor activities.

• Expanded Section 6.1: FAA Cloud Service (FCS) section to address requirements for applications moving to FCS.

• Updated Section 3.3.2 Enterprise Common Controls to identify Enterprise common control Catalog development.

• Updated Section 3.5.2:Vulnerability Scanning to further clarify scanning guidance; and

• Updated Section 3.5.2: Vulnerability Scanning to update Plan of Action and Milestones (POA&Ms).

• Updated Section 4.8: Core Controls to include additional enhancements for base controls which were previously identified as “core controls,” e.g. AU-6 (1) (3) both added as “core controls” for the Moderate-baseline. All “core controls” identified here map to the FY20 FAA Three Year Assessment Cycle Tracking Form with Cloud Template.

• Added Section 4.7.1: Continuous Diagnostics And Mitigation (CDM) Program, and sub-sequent sub-sections based on input from Security & Privacy Risk Management, AIS-020.

• Re-titled Section 3.2.2: Privacy Risk Summary, and updated based on input from the AIS- 230 FAA Privacy Team and the FAA Chief Privacy Officer (CPO).

o Subsequent changes to this section include re-organization of sub-sections, and addition of sub-section 3.2.3.1.3: Privacy Continuous Monitoring – Annual Privacy Plan Review (CM). This new sub-section describes the requirements of a continuous monitoring review (annually) of applicable privacy documentation.

• Added sub-section 3.5.5.2: Plan of Action & Milestone Workbook (CSAM Assessment), to address the POA&M workbook for assessments completed utilizing CSAM. The POAM workbook for CSAM is different than that of the POA&M workbook used for assessments performed manually, outside of CSAM.

• Updated Section 5: CSAM Guidance, and sub-sequent sub-sections, as needed, to address FAA’s CSAM Modernization activities and planning.

• Updated Section 5.6.1: Security Authorization Area and 5.6.2: Status and Archives Area to include updated and/or new instructions on uploading artifact documents into CSAM.

Issued November 2019 14 IS&P Security Compliance Division

Updates to the FY20 Authorization Templates referenced within this handbook include minor editorial modifications and formatting updates throughout, to include updating guidance/instructions. Key updates to take note of include:

• Executive Summary (ES) template updates include:

Developed the FY20 CSAM Executive Summary template which is to be completed when an assessment was preformed using the CSAM tool.

The following changes were made to the standard FY20 Executive Summary template, i.e. the ES template used for assessments performed manually using the SSP Workbook template.

• Additional scenarios were added to the sub-sections of section 2.1:

Vulnerability Scan Results Summary, i.e. additional sample language to use for various scenarios that could occur during the assessment process in regards to vulnerability scanning.

• Significant updates made to Section 2.5: Authorization Recommendation. This section now includes a table which identifies vulnerabilities with high significance that should be prioritized for remediation.

• System Characterization Document (SCD) template updates include:

Updated language for multiple scenarios addressed in Sections 2.3.1: Privacy

Threshold Assessment (PTA), and 2.3.2: Privacy Impact Assessment (PIA).

Language ensures that the continuous monitoring review (annually) of privacy documents is accurately documented. NOTE: This change carries over into the ES as well.

• System Security Plan (SSP) Workbook Updated Instructions worksheet to include important instructions/guidance on using the FAA Common Control Catalog. The FAA Common Control Catalog can be used to identify possible controls from which applications can inherit from a General Support System (GSS) or other system/application.

NIST 800-83 control baselines and FedRAMP baselines were separated into two (2) separate worksheets.

• Updated NIST 800-53 SSP worksheet to include Common Control Provider (CCP) for inheritable controls.

• Three Year Assessment Cycle Tracking Form updates include:

o Added controls and/or control enhancements as “core controls,” to align with section

4.8: Core Controls, within this handbook.

Added CA-8. NOTE: This control is only required for High-impact systems/applications.

Added the following control enhancements for base controls that were previously, and still remain, “core controls.” See Section 4.8: Core Controls in this handbook to review which baselines the following enhancements are

Issued November 2019 15 IS&P Security Compliance Division applicable.

• AU-6(3)

• AU-6(5)

• CP-2(4) (5) (8)

Added the following control enhancements on Cloud Leverage worksheet

(FedRAMP) as “Core Controls,” for applicable baselines.

• AU-6 (3) (4) (5) (6) (7) (10)

• CP-2 (4) (5) (8)

1.5 SECURITY HANDBOOK STRUCTURE

The Handbook is divided into itemized sections describing the security authorization process, the initial and reauthorization process, and the monitoring process. Embedded within each section are links to updated worksheets and templates to guide the System Owner (SO) or appropriate security official, in developing the respective Security Authorization Package.

Yellow highlights and [brackets] in each template indicate areas requiring particular attention and/or modification, e.g. areas needing input from (instructions for) assessment team, SO, ISSO, etc., and/or notes of importance.

The Handbook contains reference material in the appendices including a list of laws and references, common definitions, acronyms, and applicable roles and responsibilities.

1.6 IDENTIFYING ROLES AND RESPONSIBILITIES

In order to properly assign roles to personnel within the organization and to effectively implement FISMA and the RMF, NIST defines roles and associated responsibilities. The DOT Department Cybersecurity Policy, Order 1351.37, as amended, specifies these roles in the context of the DOT.

Information to aid in selecting personnel to perform these roles is provided in the DOT Departmental Cybersecurity Compendium, the DOT Security Authorization & Continuous Monitoring Performance Guide (Introduction), and also included in NIST special publications of 800-37 Revision 2, 800-39, 800-34, and 800-61. The responsible party for each task of the security authorization process is defined in the appropriate section(s) of the Handbook. More detailed information on roles and responsibilities can also be found in APPENDIX D of this handbook, and in FAA Order 1370.121, FAA Information Security and Privacy Program Policy, as amended.

1.7 SUMMARY

This FY20 Handbook provides procedures, processes, and guidance based on the current NIST publications, DOT policies, FAA policies, audit results, lessons learned, and individual organizational recommendations to meet the requirements for initial security authorization, annual assessment, and continuous monitoring. It is designed to be used as an aid in reducing the development and maintenance activities of FAA organizations through the streamlining of information systems security documentation. The security authorization process includes conducting the activities of security categorization, security control selection and implementation, security control assessment, information system authorization, and security control monitoring. The products produced from these activities will support compliance with identified policies and guidance.

Issued November 2019 16 IS&P Security Compliance Division

This handbook is structured in a way that describes the FAA security authorization process based on the most current policies and guidance. The front matter of this handbook provides the background and purpose for the Handbook’s creation, its use, an explanation of the FY20 enhancements, and reference information for individuals involved in the security authorization process. The remainder of this handbook will address the NIST RMF and specifically define the six

(6) phases of the NIST RMF; identify the FAA documents involved within each phase; and, provide an illustration of their interrelationships throughout the System Development Life Cycle (SDLC).

Issued November 2019 17 IS&P Security Compliance Division

2 THE NIST RISK MANAGEMENT FRAMEWORK (RMF)

2.1 NIST RMF BACKGROUND

The NIST RMF is a collection of guidance documents organized into a framework. NIST devised the RMF as a standard way for federal organizations to select, assess and monitor the appropriate security controls for information systems and subsequently to identify any risks to the information and the organization. Through implementation of the NIST RMF across DOT, DOT personnel with the responsibility for determining acceptable levels of risk are provided the critical information necessary to aid in making risk-based decisions.

The Security Authorization process is based on the NIST RMF and guidance provided in NIST SP 800-37, as amended. There are seven steps in the RMF; a preparatory step to ensure that organizations are ready to execute the process and six main steps. All seven steps are essential for the successful execution of the RMF.

1) Prepare to execute the RMF from an organization- and a system-level perspective by establishing a context and priorities for managing security and privacy risk

2) Categorize the information system

3) Select security controls

4) Implement security controls

5) Assess security controls

6) Authorize information system

7) Monitor security controls (continuous monitoring)

Figure 2-1, NIST Risk Management Framework (RMF) is extracted from NIST SP 800-37, Revision 2, and depicts the process in phases consisting of a set of required tasks to be carried out by the System Owner (SO) and appropriate security officials. The diagram also includes a mapping of key NIST documents associated with each step of the RMF. A strong working knowledge of these relationships is essential as the agency moves forward with implementing the RMF and continuous monitoring.

Issued November 2019 18

Figure 2-1: NIST Risk Management Framework (RMF) and Relationships to NIST Documents

As noted in the DOT Security Authorization and Continuous Monitoring Guide, the RMF describes a disciplined and structured process that integrates information security and risk management activities into the SDLC. Continuous monitoring is a critical part of the risk management process that is addressed in Section 4: INFORMATION SYSTEM CONTINUOUS MONITORING.

Per NIST 800-37, Revision 2, the following are types of security authorizations:

• Initial authorization is defined as the initial (start-up) risk determination and risk acceptance decision based on a complete, zero-based review of the system or of common controls. The zero-based review of the system includes an assessment of all implemented system-level controls (including the system-level portion of the hybrid controls) and a review of the security status of inherited common controls as specified in security and privacy plans.126 The zero-based review of common controls (other than common controls that are system-based) includes an assessment of applicable controls (e.g., policies, operating procedures, implementation information) that contribute to the provision of a common control or set of common controls.

• Ongoing authorization is defined as the subsequent (follow-on) risk determinations and risk acceptance decisions taken at agreed-upon and documented frequencies in accordance with the organization’s mission/business requirements and organizational risk tolerance. Ongoing

Issued November 2019 19 IS&P Security Compliance Division authorization is a time-driven or event-driven authorization process. The authorizing official is provided with the necessary information regarding the near real-time security and privacy posture of the system to determine whether the mission/business risk of continued system operation or the provision of common controls is acceptable. Ongoing authorization is fundamentally related to the ongoing understanding and ongoing acceptance of security and privacy risk and is dependent on a robust continuous monitoring program.

• Reauthorization is defined as the static, single point-in-time risk determination and risk acceptance decision that occurs after initial authorization. In general, reauthorization actions may be time-driven or event-driven. However, under ongoing authorization, reauthorization is in most instances, an event-driven action initiated by the authorizing official or directed by the senior accountable official for risk management or risk executive (function) in response to an event that results in security and privacy risk above the level of risk previously accepted by the authorizing official. Reauthorization consists of a review of the system or the common controls similar to the review carried out during the initial authorization. The reauthorization differs from the initial authorization because the authorizing official can choose to initiate a complete zero-based review of the system or of the common controls or to initiate a targeted review based on the type of event that triggered the reauthorization. Reauthorization is a separate activity from the ongoing authorization process. However, security and privacy information generated from the continuous monitoring program may be leveraged to support reauthorization. The reauthorization actions may necessitate a review of and changes to the organization’s information security and privacy continuous monitoring strategies which may in turn affect ongoing authorization.

The FAA has adopted a robust assessment process that incorporates each aspect of the processes defined in NIST SP 800-53A, Revision 4. Once a system has completed a system security assessment and authorization in accordance with DOT/FAA policies and guidelines, the system enters the Monitoring/ISCM Phase of the NIST RMF described in NIST Special Publication SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations.

Systems can remain in this phase until they are decommissioned or a significant change occurs to the system or system environment to warrant a reauthorization of the system.

NOTE: As noted in the Ongoing Authorization text in Section 4: INFORMATION SYSTEM CONTINUOUS MONITORING, based on the lack of a mature continuous monitoring program, the FAA, as an organization, is not yet ready to declare its systems ready for ongoing authorization.

However, progress is being made in the implementation of its ISCM program, and the implementation of CDM will be a key element of that.

2.2 APPLICABILITY

The RMF process is applicable to all Federal information systems and must be integrated into the organization’s SDLC. For new information systems (or major upgrades to information systems), the security authorization tasks begin during the initiation, development, and acquisition phases of the SDLC; and are important in shaping/influencing the security capabilities of the system.

For legacy operational systems, the RMF tasks begin later in the SDLC; during the operations and maintenance phase. Either situation requires all of the RMF tasks to be cycled through on an ongoing basis.

An important part of the SDLC includes building security into the system applications. FAA Order

Issued November 2019 20 IS&P Security Compliance Division

1370.121 App. 31 Software Development, provides software development requirements defined as part of the software development life cycle; includes best practices in software development and code scan requirements are included in this appendix. The FAA recommends the use of the DOD Application Security and Development Security Technical Implementation Guide (STIG) guidance for implementing secure coding standards and other aspects of software. The Defense Information Security Agency (DISA) STIG is available online at: https://iase.disa.mil/stigs/Pages/a-z.aspx.

NIST SP 800-64 Revision 2, provides guidance on required roles and tasks for system development activities. All FAA information system project teams must follow these standards.

2.3 KEY DOCUMENTS

Key documents to be completed and included in the information system security authorization package are listed in Figure 2-2: Key Sections of the Authorization Package. The AO utilizes the information contained in these documents to make a risk-based decision regarding whether to authorize (or reauthorize) the system to operate.

FY20 Security Authorization Templates and other security documents can be retrieved at the following link: FY20 FAA Security Templates. NOTE: Templates that make up the authorization package are included in the Security Authorization Templates folder.

Figure 2-2: Key Sections of the Authorization Package

Figure 2-3: FAA Document Process flow for Security Authorization illustrates the agency process flow for security authorization at the FAA, required FAA documents, and their interrelationships.

Authorization requirements for cloud based systems fall under FedRAMP guidance, which will be further discussed in section 6 of this document.

https://iase.disa.mil/stigs/Pages/a-z.aspx https://ksn2.faa.gov/aio/home/AIS230/FY20%20Security%20Authorization%20Handbook%20and%20Templates/Forms/AllItems.aspx?RootFolder=%2Faio%2Fhome%2FAIS230%2FFY20%20Security%20Authorization%20Handbook%20and%20Templates%2FSecurity%20Authorization%20Templates&FolderCTID=0x0120007EC0343845F9D94484464261193B05DC&View=%7B6A95E04A%2D57A1%2D46E1%2DBCC7%2DD99AA25538B4%7D https://ksn2.faa.gov/aio/home/AIS230/FY18%20FAA%20Security%20Authorization%20Templates%20and%20Docu/Forms/AllItems.aspx?RootFolder=%2Faio%2Fhome%2FAIS230%2FFY18%20FAA%20Security%20Authorization%20Templates%20and%20Docu%2FSecurity%20Authorization%20Templates&FolderCTID=0x012000F7D844FFC2F7814BA11590630E85A793&View=%7B0AFBACD3%2DACF4%2D4760%2DB437%2DDAF100B98EE8%7D

Issued November 2019 21

Figure 2-3: FAA Document Process flow for Security Authorization

Initial Security Authorization

System Characterization Document (SCD)

Privacy Threshold Assessment (PTA)

Privacy Impact Assessment (PIA), if applicable

System Security Plan (SSP)

Information System Contingency Plan (ISCP)

ISCP Test Plan and Results

Security Control Assessment / Security

Assessment Report (SAR)

Plan of Action and Milestones (POA&M)

Executive Summary

Signature Pages

Monitoring (Continuous Monitoring

Assessment)

System Characterization Document (SCD)

Privacy Threshold Assessment (PTA)

Privacy Impact Assessment (PIA), if applicable

System Security Plan (SSP)

Information System Contingency Plan (ISCP)

ISCP Test Plan and Results

Security Control Assessment / Security

Assessment Report (SAR)

Plan of Action and Milestones (POA&M)

Executive Summary

Signature Pages

Issued November 2019 22 IS&P Security Compliance Division

3 INITIAL SECURITY AUTHORIZATION PROCESS

3.1 OVERVIEW

Federal IT systems must receive Authorization to Operate (ATO) prior to being placed in an operational environment, i.e. production environment. This determination of authorization is based on the results of the security authorization process. This section will address the initial authorization of a system.

The Initial Security Authorization of a system involves a number of security activities under steps 1-5 of the NIST RMF. The outputs lead to the creation or update of the security documents listed below, individually addressed in the suggested order for completion:

Table 3-1: Document List

Document Initial Authorization

System Characterization Document (SCD) Create Document

Privacy Threshold Assessment (PTA) Create Document / Obtain adjudication from the DOT Privacy Office

Privacy Impact Assessment (PIA), as required Create Document / Obtain adjudication from the DOT Privacy Office

System of Records Notice (SORN), if required Identify existing or Create new SORN /Obtain adjudication from the DOT Privacy Office

System Security Plan (SSP) Create Document

Information System Contingency Plan (ISCP) Create Document

ISCP Test Plan and Results Create Document Security Assessment Report (SAR) Create Document Executive Summary/ Plan of Action and Milestones (POA&M) Create Document

Signature Pages Obtain Signatures

Once authorization has been achieved, the system moves into the ISCM phase. If there is a security breach, the AO determines whether the breach is serious enough to warrant a system reauthorization. The reauthorization of a system includes all of the steps of the initial security authorization. While most of the documents in the initial security authorization submission require only a review or update, it is necessary to conduct a new risk assessment to validate the current system’s security posture and system security configuration. Since the system’s vulnerabilities have likely been exploited, a more in depth risk assessment is required in order to thoroughly evaluate known vulnerabilities and to identify previously unidentified vulnerabilities. The risk assessment is likely to reveal that additional security controls, system modifications, and procedures will require implementation or modification to reduce the risk of future breaches, and all applicable system security authorization documentation must be updated accordingly.

During any reauthorization, the process will be most efficient when all documentation has been kept current, as the security control assessor can then focus on items that have changed since the initial security authorization.

Issued November 2019 23 IS&P Security Compliance Division

3.2 RMF STEP 1: CATEGORIZE INFORMATION SYSTEMS

The first step in the initial authorization process is to categorize the information system and complete the necessary documentation.

System Owner(s) must document information about a system using the System Characterization Document (SCD) template. In parallel, the security categorization process should take place to determine the required level of security controls; the FAA FY20 System Security Categorization Framework Checklist should be used to determine the proper categorization of the system/application. This process should begin during the development phase of the SDLC.

In addition, privacy documentation should be completed in parallel to the above as it may have an impact on the security categorization of the system. Privacy risks are discussed in this handbook in Section 3.2.2: PRIVACY RISK SUMMARY, and subsequent sub-sections.

3.2.1 SYSTEM CHARACTERIZATION DOCUMENT

Table 3-2: SCD Tasks

System Characterization Document (SCD) Create Document

FY20 System Characterization Document Template

The purpose of the SCD is to provide all system security related information in one (1) document including:

• Identification of any future changes to the system

• Functional description of the system and its mission (including system architecture)

• Hardware and software/firmware assets

• Internal and external interfaces

• User identification, interface(s) and authentication

• Security authorization boundary

• Security categorization analysis (Data types and FIPS199 impact)

• e-Authentication determination

• Confidentiality Impact Analysis and Privacy summary

The SCD is a living document and should be updated whenever a change occurs to the system.

System information provided in the SCD is used repeatedly throughout the security authorization process and is frequently referenced in the key documents of the security authorization package.

The System Owner(s) (SO) oversees and is responsible for the development of the initial SCD, as well as its maintenance throughout the life cycle of the system. The SCD is typically coordinated with, and receives input from, the System Owner, Information Steward (IS), Information Systems Security Officer (ISSO), Information Systems Security Manager (ISSM) and/or Authorizing Official Designated Representative (AODR), as well as responsible parties from the hosting data centers, as applicable, for the individual Line of Business (LOB) or Staff Office organization.

https://ksn2.faa.gov/aio/home/AIS230/FY20%20Security%20Authorization%20Handbook%20and%20Templates/Forms/AllItems.aspx?RootFolder=%2Faio%2Fhome%2FAIS230%2FFY20%20Security%20Authorization%20Handbook%20and%20Templates%2FSecurity%20Authorization%20Templates%2FSystem%20Characterization%20Document%20%28SCD%29&FolderCTID=0x0120007EC0343845F9D94484464261193B05DC&View=%7B6A95E04A%2D57A1%2D46E1%2DBCC7%2DD99AA25538B4%7D

Issued November 2019 24 IS&P Security Compliance Division

For guidance on developing an SCD, refer to the instructions and content contained in the link to the template.

3.2.1.1 System Type Designation

‘”Information system” means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information (44 U.S.C. § 3502). Listed below are clarifications to the OMB Circular A- 130, App. III definitions to help in the determination of whether or not the system should be classified as a GSS or Major Application

(MA).

Major Application (MA): An application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. NOTE: All Federal applications require some level of protection.

Certain applications, because of the information in them, however, require special management oversight and should be treated as major. Adequate security for other applications should be provided by security of the systems in which they operate.

General Support System (GSS): an interconnected set of information resources under the same direct management control which shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people.

A MA may include the software applications and their associated servers. A GSS normally includes hardware, software, information, data, applications, a communications component, and people. A GSS can be, for example, a local area network (LAN) including smart terminals that supports a branch office, an agency-wide backbone, a communications network, a departmental data processing center including its operating system and utilities, a UHF/VHF radio network, or a shared information processing service organization.

Many of the National Airspace System (NAS) systems operate in an Industrial Control System (ICS) type of environment, rather than a typical IT environment, for which tailoring guidance is provided in NIST SP 800-82 Rev 2, Guide to Industrial Control Systems (ICS) Security.

An information system is defined as a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

The following are not considered standalone FISMA reportable systems:

• Office Suites (MS Office products)

• Adobe Acrobat

• Web Browsers

• Workstation Databases (MS Access, local flat file databases)

• Operating Systems (to include but not limited to MS Windows/Server, Linux/Unix, and Embedded system / Real-time Operating systems)

• System Utilities and Peripherals (Keyboards, Mouse, Video Screens, Printers/Print Services/Utilities, Document Scanners/Scanning Services)

3.2.1.2 Contractor System Designation

To aid in the determination of whether or not the system should be classified as a contractor system, the DOT Cybersecurity Compendium and DOT Order 1351.18 Privacy Risk Management defines a

Issued November 2019 25 IS&P Security Compliance Division contractor system as, “Any system fully or partially provided or managed, under contract, by another agency, contractor, or other source.” The FAA is finalizing the development of a criteria and methodology for identifying contractor- owned and operated systems, thereby establishing consistent language regarding contractor- owned systems and ensuring compliance with the appropriate provisions of FISMA, OMB Circular A-130, and NIST 800-53, Rev 4. Guidance for identifying contractor-owned systems is being developed by the AIS Audit & Reporting Branch (AIS-240). Documented guidance is in the process of development, with an estimated completion date by the end of FY20. To receive more information regarding this guidance, contact AIS-240.

3.2.1.3 Security Categorization

The Security Categorization process is based on Federal Information Processing Standards (FIPS) Publication (PUB) 199 (FIPS 199), Standards for Security Categorization of Federal Information and Information Systems, February 2004, and establishes security categories for both information and information systems. Information is categorized according to its information type. An information type is a specific category of information (e.g., privacy, medical, proprietary, financial, investigative, security management) defined by an organization or, in some instances, by a specific law, executive order, policy, or regulation.

In the context of security objectives from FISMA: Confidentiality is unauthorized disclosure of information; Integrity is unauthorized modification/destruction of the information in the system;

and Availability is the disruption of access to/use of information.

The three (3) impact levels are defined as:

Low – loss would have a limited adverse impact Moderate – loss would have a serious adverse impact High – loss would have a catastrophic or severe adverse impact.

The Security Categorization process provides the basis for identifying the initial high, moderate and low baseline set of security controls per FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006. A Security Categorization Framework based on NIST SP 800- 60 is provided below to assist in the Security Categorization process. NIST SP 800-60, Revision 1, Volume 1 provides categorization guidance and Volume 2 provides a catalog of information types and provisional categorizations (impact levels) of Low, Moderate, and High. The Standard for impact levels is FIPS-199. The appropriateness of the particular impact level(s) is reviewed and agreed to by the system stakeholders prior to it being including in the SCD.

Section 4 in NIST SP 800-60, Revision 1, Volume 1, provides step-by-step guidance, along with examples for selecting, reviewing, and adjusting impact values.

Not all of the information processed by a system may be identified in NIST SP 800-60. In that case the closest information type should be identified and then describe the actual information that is processed by the system. Sections 4.2.1 through 4.2.3 of NIST SP 800-60 Revision 1 Volume 1 provide assistance in assigning provisional and FIPS199 impact levels to security categories for agency-identified information types and information systems. Additionally, NIST SP 800-60 provides a Management and Support sub function, General Information Type, which can be used as a means to identify and categorize information not identified in NIST SP 800-60. A complete description of the actual information must be included in the General Information Type description and documentation supporting the security categorization process.

It should be noted that the “probable” worst case aspect comes in to play when considering

Issued November 2019 26 IS&P Security Compliance Division likelihood during a risk assessment. The categorization/impact is based on the potential worst case scenario in regards to loss of confidentiality, integrity, and availability of the NIST 800-60 information type(s) and also from FIPS 199. As an example, an argument can be made that allows for lowering a high availability system to a moderate if the information can be retrieved from alternate sources. Although the alternate information source is considered to be a strong mitigation technique that certainly reduced the risk of the loss of Availability, the availability of alternate resources should not change the potential worse case impact for the loss of availability of all information types that are processed, stored, or transmitted.

Furthermore, a Personally Identifiable Information (PII) Confidentiality Impact Analysis (CIA) is required to be conducted for those systems that collect PII. The PII CIA is conducted in accordance with NIST SP 800-122 Guide to Protecting Personally Identifiable Information (PII). It should specifically identify the PII components that are collected by the system and the factors determining the Confidentiality impact levels in accordance with guidance in NIST SP 800-122 section 3.2 and document it accordingly in section 2.2 of the SCD. Once the PII confidentiality impact level is selected, it is used to supplement the provisional/FIPS199 confidentiality impact level and is included in the documentation of the security categorization process.

The rationale for all FIPS 199 impact levels must be documented in the SCD. Most notably, any adjustments to the FIPS 199 provisional impact level(s) (as identified in NIST SP 800 60, Rev 1, volumes I and II) must be thoroughly documented.

3.2.1.4 Digital Identity (formerly E-Authentication)

NIST SP 800-63-3, Digital Identity Guidelines, was released in June 2017 and it supersedes OMB Memo 04-04. It does not recognize the four Levels of Assurance model previously used by federal agencies and described in OMB M-04-04, instead requiring agencies to individually select levels corresponding to each function being performed. Identity proofing establishes that a subject is who they claim to be. Digital authentication establishes that a subject attempting to access a digital service is in control of one or more valid authenticators associated with that subject’s digital identity. These technical guidelines supersede NIST SP 800-63-2.

Agencies use these guidelines as part of the risk assessment and implementation of their digital service(s). These guidelines provide mitigations of an authentication error’s negative impacts by separating the individual elements of identity assurance into discrete, component parts. For non-federated systems, agencies will select two components, referred to as Identity Assurance Level (IAL) and Authenticator Assurance Level (AAL). For federated systems, agencies will select a third component, Federation Assurance Level (FAL).

The components of identity assurance detailed in the NIST SP 800-63-3 guidelines are as follows:

• IAL refers to the identity proofing process.

• AAL refers to the authentication process.

• FAL refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information (if applicable) to a relying party (RP).

The assurance level determination is only based on transactions that are part of a digital system. An online transaction may not be equivalent to a complete business process that requires offline processing, or online processing in a completely segmented system. In selecting the appropriate assurance levels, the agency should assess the risk associated with online transactions they are offering via the digital service, not the entire business process associated with the provided benefit

Issued November 2019 27 IS&P Security Compliance Division or service. For example, in an online survey, personal information may be collected, but it is never made available online to the submitter after the information is saved. In this instance, it is important for the information to be carefully protected in backend systems, but there is no reason to identity proof or even authenticate the user providing the information for the purposes of their own access to the system or its associated benefits. The online transaction is solely a submission of the data.