CSS-FD SIR J-9 FAA Cloud Architecture_DRAFT_v2.0.pdf

Solicitation #

Attachment J-9

Federal Aviation Administration

Common Support Services – Flight Data (CSS-FD)

FAA Cloud Architecture

November 2024

Federal Aviation Administration

800 Independence Avenue, SW

Washington, DC 20591 i

TABLE OF CONTENTS

1 INTRODUCTION

2 FAA SERVICE MIGRATION TO CLOUD ENVIRONMENT

2.1 NAS COMPUTER INFRASTRUCTURE BACKGROUND

3 THE FAA CLOUD NATIONAL TEST BED (CNTB)

3.1 CLOUD ACCESS, TOOLS AND RESOURCES

3.2 CNTB ROLE AND FUNCTION

4 FAA CLOUD CORE SERVICES

4.1 SECURE CLIENT CONNECTIONS

5 FUTURE CNTB, ME-CLOUD AND THE ME-OE ENVIRONMENT

5.1 CNTB CONFIGURATION CONTROL BOARD (CCB)

5.2 ME-CLOUD AND ME-OE

5.3 ME-CLOUD FOR COMPUTE AND PLATFORM INFRASTRUCTURE SERVICES

5.4 NAS MISSION OPERATING ENVIRONMENTS

5.4.1 Service Criticality and Network Segmentation

5.4.2 Mission Essential -Operating Environment

6 VENDOR CONSIDERATIONS FOR CLOUD DEVELOPMENT

6.1 INFRASTRUCTURE AS CODE – BEST PRACTICES FOR DEVELOPMENT

6.1.1 The Complexity of the Cloud

6.2 CSS-FD DEVELOPMENT IN THE CNTB VS VENDOR EXTERNAL ENVIRONMENT

6.2.1 Continuous Development, Integration and Deployment to ME-OE

6.3 FAA-VENDOR CODE TRANSFER

6.4 VENDOR DEVELOPMENT RISK REDUCTION

6.4.1 Other Considerations

APPENDIX A – CNTB & ME-CLOUD DEFAULT TOOLS: DEVSECOPS

APPENDIX B – ACRONYMS AND ABBREVIATIONS

ii

TABLE OF FIGURES

Figure 1: FAA-Envisioned Cloud Architecture Connectivity

Figure 2: High-level Network Connectivity

Figure 3: AWS Global Network and CNTB Organization

Figure 5: Technology Layers and the CNTB

Figure 6: Cloud Core Services

Figure 7: CNTB Configuration Control and Changes Process Flow

Figure 8: ME-Cloud General Architecture

Figure 9: ME-OE Envisioned Architecture

Figure 10: CNTB and ME-OE Lifecycle

Figure 11: Pre-Production Full Development Process

1 INTRODUCTION

This document provides an overview of the Federal Aviation Administration (FAA) Cloud

Architecture and describes how Common Support Service Flight Data (CSS-FD) is envisioned to integrate into the FAA’s cloud platforms. Under AJM-31, a collaborative effort among the

Automation Evolution Strategy (AES) team, National Airspace System (NAS) programs and across FAA lines of business (LOBs), occurred to gather requirements, perform trade analyses, and expand the FAA Program Management Office (PMO) cloud body of knowledge. This effort has culminated in a NAS cloud deployment architecture design and operational concept, leading to building the Cloud National Test Bed (CNTB). The CNTB establishes a cloud environment capable of supporting program pre-production activities, such as development, trade studies, technical investigations, testing, and training, among other use cases, and represents the baseline configuration for the production environment – Mission Essential-Cloud (ME-Cloud). In addition to the CNTB, the FAA is also establishing the ME-Cloud and Mission Essential-

Operating Environment (ME-OE) production environments, which will offer infrastructure, platform, and core services to facilitate rapid deployment of systems like CSS-FD. From a software development standpoint, the CNTB is used for pre-production activities, while the

FAA’s ME-Cloud is the production environment that enables programs to quickly access, acquire, provision and de-provision infrastructure and platform services in the FAA ME-OE.

There are additional requirements, trades, and configuration work to be performed, as well as establishing processes, governance, and defining roles and responsibilities, but there is a clear path to achieving the Mission Essential (ME)-Cloud.

The FAA Cloud Services (FCS) is the contract vehicle that provides the FAA agency with a comprehensive cloud computing and integration solution. While FCS is composed of cloud works led by several contractors, it also includes innovators in the cloud industry such as

Amazon Web Services (AWS) and Microsoft Azure. FCS, in essence, enables the FAA to distribute services across multiple vendors. In October 2022, the PMO approved the National

Cloud Integration Services (NCIS) group to proceed with developing CNTB architecture and by

February 2023, orders for AWS Commercial (Phase 1) and GovCloud (Phase 2) request for service were submitted through the FCS contract. The following sections provide more information and references which provide context for how the FAA enterprise cloud platform will be leveraged as CSS-FD is implemented in the NAS.

2 FAA SERVICE MIGRATION TO CLOUD ENVIRONMENT

The FAA’s vision for an info-centric NAS includes the move toward an agile infrastructure through the evolution of system-wide information management and adoption of cloud-based enterprise architecture. The successful implementation of this plan aims to save time and resources while exploring new ways to improve air traffic management. The plan involves transitioning selected Air Traffic Organization (ATO) systems from traditional on-premise data centers to a cloud infrastructure that leverages commercially available services from U.S. Cloud

Service Providers (CSP). However, cloud technologies present new challenges to program implementation, network security, and resource scheduling. Thus, the availability of a cloud testbed has become an essential requirement for testing and evaluating FAA cloud-based applications before they are ready to enter operational environments for final testing and security assessment and authorization.

2.1 NAS COMPUTER INFRASTRUCTURE BACKGROUND

Today, the FAA uses several types of FAA NAS Computer Infrastructure that include the facility-based, data center, and the cloud. All are within a single enclave/domain/operating environment under the FAA.GOV domain and with internet protocol addresses assigned by the

FAA Communications, Information and Network Programs (CINP) group.

Systems that use facility-based infrastructure are those that have an integrated hardware and software stack. The application, platform, and compute resources are all integrated and typically provided by vendors; there is no sharing of compute resources or software platform by other systems. In addition, all monitoring and management of the deployed systems is conducted by the FAA.

Currently, there are two forms of common infrastructure data centers: the centralized data center and the decentralized data center. The common infrastructure centralized data center environment has virtualized computing resources located at a limited number of NAS enterprise service facilities (e.g., Atlanta NAS Enterprise Management [NEMS] Center). For this common infrastructure common compute resource, NAS internal or “on-network” connectivity is used, and the infrastructure (virtual computing/storage and platform software layer) and its management is all provided by the FAA. The decentralized data center environment has virtualized computing resources located at NAS operational facilities (e.g., Air Route Traffic

Control Centers [ARTCCs] and Terminal Radar Approach Control Facilities [TRACONs]).

Computing resources and common software platform layer resources are deployed at NAS operational facilities and managed both remotely and locally by the FAA.

In the cloud-based environment, the computing resources are implemented at CSP locations, and the FAA must have a direct connect setup with the CSPs to extend its enterprise. Specifically, the CSP operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates and inherits the physical and environment controls “of” the Cloud. These controls include patching and fixing flaws, configuration management, maintaining infrastructure and software, compute, storage, database, networking, hardware of the Cloud. The FAA assumes responsibility and management of the guest operating system (including updates and security patches), platform, applications, identity/access management, network and firewall configuration, encryption, file system and/or data, networking traffic protection, configures, manages, operates, and monitors applications, infrastructure, platform service, service and communications protection or zone security (route or zone data within security environments) “in” the CSP for compliance with Service Level Agreements (SLAs). As such the instance of the cloud described becomes part of the FAA ATO, similar to other NAS Compute Infrastructure.

The CINP group, through the NCIS function, is collaborating with various FAA organizations, including AIT (Office of Information Technology), AIS (Office of Information Systems

Security), ACG (Office of Chief Counsel), and AJW (Office of Technical Operations) to enable the implementation of cloud and related enterprise solutions to satisfy FAA program modernization requirements. The NCIS group focuses on streamlining cloud modernization development and acquisition lifecycles and improving efficiency in development cost and deployment. Consistent with this objective, NCIS started the development of the Cloud National

Testbed (CNTB). Figure 1 depicts a high-level diagram of the envisioned operational FAA

Cloud services connection with FAA on-premise environments. For more information about

FAA operational environments and SWIM data message distribution, please refer to Sections 5 and 6.

Figure 1: FAA-Envisioned Cloud Architecture Connectivity

3 THE FAA CLOUD NATIONAL TEST BED (CNTB)

The FAA is establishing the CNTB and the Mission Essential Cloud (ME-Cloud) environments within the Amazon Web Service (AWS) Federal Information Security Modernization Act

(FISMA) GovCloud to enable development, testing, and production deployment of NAS programs. At its core, the CNTB is an enterprise-level cloud hosting environment managed and controlled by the FAA, in which programs can conduct pre-production activities using AWS services and FAA-provided DevSecOps tools. The environment will also establish a framework for FAA ATO programs to leverage a repeatable, standardized authorization model and an inherited security control acceptance for this environment. As such, the CNTB supports and facilitates the FAA's Zero Trust framework to connect users, Operating Environments (OEs) and external network services (e.g. FAA Enterprise Network Services [FENS]), to provide highly available, secure communications, information services, and networking capabilities required to support NAS operations and agency administration functions.

3.1 CLOUD ACCESS, TOOLS AND RESOURCES

Currently, the CNTB v1.0 release includes access to services from tenant AWS accounts within an off-premises AWS GovCloud. Amazon Workspaces, an AWS virtual desktop, will provide access into the CNTB accounts for tenant programs and vendors. CNTB tools and services include a mix of AWS native services and third-party enterprise service capabilities and also provides additional access into CNTB through Direct Connect ports, which will be available to

FAA William J. Hughes Technical Center (WJHTC) Lab facilities in Atlantic City, N.J. In addition, the AWS Direct Connect feature connects to the GovCloud and WJHTC (i.e., operational environments). This environment uses the AWS Landing Zone Accelerator (LZA) to apply best practices, AWS environment governance and follow AWS Security Reference

Architecture. Sufficient port density is provided to extend connections from the Direct Connect service to any lab within the Technical Center.

From Amazon Workspaces, access to the AWS Console is permitted through AWS Identity

Center Single Sign-on (SSO) via internal Keycloak IDP integrated with a managed active directory. Access to additional CNTB resources such as GitLab, OpenShift, Terraform, Vault, etc., is achieved through internal Keycloak IDP and the managed active directory. The use of

Amazon Workspaces ensures no direct connection between internet and CNTB environments, preventing internal CNTB Uniform Resource Locator (URL’s) or endpoints exposure to the internet. For the virtual desktop user on FAA Mission Support, CNTB applies a Service Control

Policy (SCP) that allows only FAA IP addresses. See Figures 2 and 3 for high-level references to

CNTB network connectivity. For reference, the NCIS CNTB Service Catalog document also provides additional information on general services, tools, FAA Cloud support personnel contacts and workspace services.

Figure 2: High-level Network Connectivity

Figure 3: AWS Global Network and CNTB Organization

To facilitate FAA and vendor implementation objectives, the CNTB offers development, testing, and pre-production of FAA system/applications. This environment is used for sustainment, programmatic, and operation technology support for the ME-OE. As such, the CNTB affords the

FAA the opportunity to conduct use cases of all systems migrating to the ME-Cloud (i.e., Off-

Prem, On-Prem, and Hybrid). Please see Section 5 for more information on the ME-Cloud

(production environment) and the ME-OE (NAS operational environment).

Figure 4: FAA CNTB General Features and Capabilities

3.2 CNTB ROLE AND FUNCTION

The FAA envisions the CNTB to serve as an environment for collaborative development and engagement between the various FAA organizations and vendors involved with the transition of selected ATO applications services to cloud infrastructure. As such, the CNTB will function as a collaborative space that facilitates stakeholder goals by:

• Providing preparatory development for implementation in the ME-Cloud. CNTB is a solution development and testing environment designed to help FAA programs meet

FAA ME-OE production requirements, including:

o Evaluating interfaces for proper data exchange between FAA systems.

o Conducting security vulnerability and compliance scanning and penetration testing.

o Identifying risks that may impact mission capability and sustainment goals.

o Resolve coding issues

• Providing an environment for enabling FAA Infrastructure and Platform Services. CNTB infrastructure and platform services feature a common enterprise approach to shared tools, capabilities, and services for all programs. CNTB can assist in developing the FAA enterprise DevSecOps toolchain (in concert with AIS and ANG [Office of NextGen

Concepts]).

• Providing a model for FAA Cloud Operations Management. CNTB provides the critical tools necessary for effective operations management. Tenants can monitor their cloud environments' security, performance, and resource capacity with state-of-the-art analytics tools from various CNTB service providers.

• Providing an environment for developing, testing, and validating a secure connectivity interface between Cloud and FAA NAS Operational Environments and External Partner

Programs.

• Providing a security pattern for a Repeatable Common Authorization Model. CNTB supports the development of repeatable, scalable, and auditable access controls

• Implementing an environment consistent with the FAA Automation Evolution Strategy

(AES). CNTB is a services-based architecture that supports the AES to quicken new capabilities' development, integration, and deployment.

• Providing a platform for the collaborative development of best practices through lessons learned. CNTB tenants have a unique opportunity to document lessons learned while developing cloud technologies, including:

o Implementing Trusted Internet Connections (TIC) 3.0.

o Enterprise-level API lifecycle management and governance.

o Performing security monitoring and control.

o Creating architecture for Mission Essential-OE environments.

o Developing policy for FAA administrative, mission-critical, and research & development.

o Building authorization models for repeatable, scalable, and auditable access controls.

o Implementing FAA Zero Trust strategies for connectivity between OEs and outside entities

4 FAA CLOUD CORE SERVICES

FAA tenant programs in the CNTB will require access to compute layer resources (IaaS, or infrastructure services) and the platform layer (PaaS, or platform services) resources. There are, however, a core set of essential networking and cloud management tools which tenants require to access Cloud Services. Tenants will require these foundational “Cloud Core Services”, enabling connectivity, access and control over Cloud Services to ensure operations and security compliance.

Figure 4: Technology Layers and the CNTB

In essence, Cloud Core Services are the minimal set of services required for any single tenant program to use cloud technology. These Core Services, offered as Enterprise Services, are required by all tenants to ensure infrastructure management and monitoring is available for compliance with operations policies. Cloud Core Services represent an initial set of fixed costs that include software licenses for tools, computing infrastructure to run these services, and labor for managing and maintaining these tools. Cloud Core Services are generally grouped as follows:

• Foundational Cloud Services: These services enable programs to physically connect to the cloud services (e.g., compute, platform, and common mission services). These services include: (1) Network functions comprised of physical connectivity, domain name service, network timing, IP address management, dynamic host configuration services, among other network related services; and (2) Cloud management functions made up of cloud provisioning, elemental system development tools, user level consumption tracking (cost reporting), dynamic capacity management, resource scaling

(known as “elasticity” that enables programs to acquire additional cloud services on-demand to satisfy surges in capacity, short-term requirements, then release those resources after surge demand is satisfied), and consumption-based tracking (for cost reporting). These capabilities are required for both off-prem and on-prem cloud services.

Tenant programs require system monitoring and notification capabilities for fault, performance and security events and alerting capabilities to comply with FAA operations and maintenance orders and policies. Cloud infrastructure (IaaS) and platform (PaaS) services include security controls that will be configured to enable enterprise level security control compliance across all cloud hosted programs.

• Operations Management: These are cloud hosted tools offering monitoring and control services for system fault and performance (e.g., fault and performance monitoring;

trouble ticketing; event logging; system backups; inventory, system patches and configuration management; etc.). These services are configured in compliance with required FAA orders and policies and forward alerts and notifications to relevant stakeholders (e.g., NASEO (National Airspace Security and Enterprise Operations), program staff, SLE, etc.), ensuring systems are operating without incident

• Security Management: These are cloud hosted tools offering monitoring and control services for system security (e.g., security incident & event management, SIEM;

vulnerability monitoring; boundary protection; endpoint, certificate, and password management; etc.). These services are configured to comply with all required security controls, FAA policies and orders, and to forward notifications to relevant stakeholders for escalating security events.

With Cloud Core Services in place, tenants can access and provision IaaS and PaaS Cloud

Services, inheriting security controls as they pursue system level security authorization. Note that the CNTB Cloud Core Services are essential to establishing tenant programs and operating the production ME-Cloud. For reference, expected CNTB services include:

• Deployment, Security, Operations

(DevSecOps) C/M (OpenShift)

• DevSecOps (GitLab)

• Identity and Access Management

(RH SSO)

• Service Mesh (Consul, RH Istio)

Figure 5: Cloud Core Services

• Secrets Manager (Vault)

• Cloud Service Provider (CSP) Native

Platform as a Service (PaaS)

• Code/containers repositories

• Application Performance Monitoring

• Logging and Monitoring

• Privilege Access Management

• Security Information and Event

Management (SIEM)

• Vulnerability Scanning

• Operations Management

• Governance, Billing

• Service Desk, Ticketing

• Inventory/patch/config management

Appendix A of this document provides a general list of the CNTB initial toolset. CNTB tenant can access these tools from within a virtual desktop client Amazon WorkSpaces. For more information, the CNTB Tenant User Guide and CNTB Service Catalog documents provide step-by-step instructions for installing the WorkSpaces desktop client, completing the identity verification process, and accessing the CNTB.

4.1 SECURE CLIENT CONNECTIONS

In addition, to supporting fast, secure and reliable tenant/user connections, the FAA is in the process of implementing Zscaler to the CNTB environment. Zscaler is a lightweight agent for user endpoints, enabling hybrid work through access to CNTB applications over networks.

Tenants and vendors alike will be permitted to use Zscaler as a VPN instance into the CNTB.

Currently, the FAA is targeting September 2024 for Zscaler to be piloted in the CNTB to allow for remote access for GFE or non-GFE users. Further expansion of Zscaler use cases for the cloud environments and enclaves is actively being researched.

5 FUTURE CNTB, ME-CLOUD AND THE ME-OE ENVIRONMENT

5.1 CNTB CONFIGURATION CONTROL BOARD (CCB)

Key CNTB stakeholders and partners are in the process of creating the ATO Cloud Infrastructure

Configuration Control Board (CCB) process to capture, approve or deny action requests from tenant programs operating in the cloud environment. The ATO Cloud Infrastructure CCB membership, chaired by the NCIS Program, includes many FAA stakeholders with varying roles and responsibilities. The main function of the board is to serve as an advisory, referral and coordination body among FAA ATO Cloud Enterprise and tenant stakeholders. Application support and tenant requests for new software or feature inclusion into the DevSecOps toolchain will be socialized through CCB engagement. See Figure 7 below for a general overview of the

CNTB CCB process approving new changes to the CNTB environment.

Figure 6: CNTB Configuration Control and Changes Process Flow

In addition, the Enterprise Software Board (ESB) is the cloud steering group that provides approval for tenant external software requests (e.g. vendor-recommended tools). Tenant programs, and the vendors that support tenant development in the CNTB, that wish to include external tools to facilitate development or testing activities must consider the costs and benefits to justify its new inclusion. In general, the ESB will permit the introduction of new tools that ensure alignment with the AES strategy. For more information on the FAA AES Strategy, please refer to Attachment J-8, AES Technical Architecture.

Vendors may also introduce new tools directly to the CNTB environment, provided that the impacts to CNTB maintenance, tool benefits delivery and vendor administration are clearly defined and justified. Depending on the scope of the introduced tool, the tool could be installed/hosted in one tenant account or as a CNTB enterprise tool.

5.2 ME-CLOUD AND ME-OE

The FAA is in the process of migrating to an enterprise-based infrastructure model through a scalable, FISMA High, Off-Prem Cloud Computing Environment. Currently, the AWS

GovCloud will serve as the CSP for the ME-Cloud architecture. The ME-Cloud enables tenants like CSS-FD to quickly access and platform services in the ME-OE – reducing the timeline for programs to deliver services to the NAS. Please note that the CNTB, ME-Cloud and ME-OE are environments with distinctly different purposes and functions:

1. The CNTB is the pre-production off-premises cloud computing operating environment.

2. The ME-Cloud is the production off-premises cloud computing operating environment that includes the functions of DevOps Toolchains required to receive software from

Operational Testing and puts the software into production. The ME-Cloud environment encompasses the CNTB pre-production environment and also enables programs to quickly access, acquire, provision and de-provision infrastructure and platform services in the ME-OE.

3. The ME-OE is a networking and computing environment in which system assets perform

NAS Mission Essential requirements as defined in the NAS RD 2022 “NAS

Requirements Document” (or as updated) operate. The ME-OE environment encompasses the ME-Cloud environment and on-premises NAS environments.

5.3 ME-CLOUD FOR COMPUTE AND PLATFORM INFRASTRUCTURE SERVICES

The Cloud Core Services enables an environment where tenants can execute all pre-deployment activities associated with the software lifecycle development process. This includes performing initial engineering activities, such as, technical investigations, trade off analysis, proof of-concept development, and the more intense activities associated with software development, test, training, specialized certifications, etc. This environment is equipped with the compute layer capabilities (e.g., compute, memory, and storage) and platform layer services (e.g., DevSecOps toolchains, relational database service, identify access management, etc.) that tenants require to execute their respective software development scope of work. Once a tenant is developed, tested and approved for operation - both through Operational Test and Evaluation, and security ATO -the software is deployed and delivered for operations.

The Production ME-Cloud is the operational environment where users interact with the software developed and deployed by tenants. As a hybrid cloud architecture, the ME-Cloud includes both the off-premises and on-premises cloud capabilities. Underlying these two environments are the

Cloud Core Services that form the foundational services enabling FAA access to cloud infrastructure, as described in Section 4. Cloud Core Services will also have to be extended to support the on-prem cloud. This on-prem portion fully implements ME-Cloud as a hybrid architecture, addressing AES requirements for on-prem centralized and decentralized infrastructure. Figure 8 provides a high-level architectural boundary overview for the ME-Cloud environment.

Figure 7: ME-Cloud General Architecture

5.4 NAS MISSION OPERATING ENVIRONMENTS

As part of the Zero Trust compliant security paradigm, the FAA is currently transitioning from domain-based security operations (with two operational domains, NAS and Administrative) to security controls and criticality level Operating Environments (OEs). The FAA maintains several main Operating Environments (OE), which include: (1) NAS Mission Critical (MC-OE); (2)

NAS Mission Essential (ME-OE); and (3) Administrative (A-OE). The Research and

Development (RD-OE) also is being considered, but not addressed in this document. A draft

Joint Order 1370 (as of 2022), Information Security Requirements for FAA Telecommunications

Services in the Mission Critical and Mission Essential Operating Environments or FAA Order

1370.121 “FAA Information Security and Privacy Program and Policy”, and FAA Operating

Environment Security Framework: Technical Description & Responsibilities, Version 1.2, outlines what is required for FAA ATO entities to obtain and maintain secure telecommunications, networking, and interface gateway services that comply with Federal regulations and policies.

In general, there must be an effort to map FAA system types (system instances) to the OEs, based on various attributes including but not limited to:

• National Airspace System Requirements Document, NAS-RD-2022, dated

February 2022, which identified criticality ratings

• FIPS 199 Security Categorization Level

• Current legacy domain (NAS, NAS on MS, Non-NAS)

• Tier Exposure Level (from the SCD Template)

While noting that specifics of the mapping from domains to OEs are still being assessed may change and leaving room for exceptions, it is envisioned that:

• NAS Safety-Critical systems will be allocated to the MC-OE

• Most NAS Efficiency-Critical systems will be allocated to MC-OE

• Some NAS Efficiency-Critical systems may be allocated to the ME-OE. [The

CSS-FD tenant falls under this category]

• NAS Essential systems will be allocated to the ME-OE

• NAS Routine systems will be allocated to the ME-OE

• Administrative systems will be allocated to the A-OE

5.4.1 Service Criticality and Network Segmentation

It is important to note the distinction between a system’s criticality level and the criticality level of the service threads it supports. System criticality level assignments define performance requirements for functional system capabilities and are drivers to the overall system architecture and its associated infrastructure. While it is generally true that system criticality levels are derived from the most critical NAS service threads it supports, not all service threads of a system are assigned the same criticality level. That is, a Safety-Critical System may support a host of

Safety-Critical service threads along with Efficiency-Critical, Essential and Routine service threads. These service threads may require interactions with other systems allocated to either the same or different criticality levels.

Network segmentation is an architecture that divides a network into smaller sections or subnets.

Each network segment acts as its own network, which provides security teams with increased control over the traffic that flows into their systems. In the construct and Zero Trust approach to

Operating Environments--it is key. The OEs segment the network and infrastructure assets regardless of their location and whether they are on-premises or on multiple cloud environments.

The FAA can then monitor the trust level based on criticality and adapt its security policies accordingly. In addition, critical IT assets are isolated to ensure that any threats are quickly detected and risks are prevented using methods such as analytics and automation.

Currently the FAA has a single domain call (FAA.GOV) and IP addressing that needs to be divided for the OEs, and many systems will be required to be re-IPed. JO 1370.117, National

Airspace System (NAS) Internet Protocol (IP) Addressing Policy, January 21, 2014, formalizes the management and assignment of NAS IP addresses for all device connections within the protected domain of the NAS. This is critical to the success of all systems within each OE. The

ME-Cloud system owners must use approved NAS IP addresses from the FAA pool as assigned by the CINP group (includes public, private, and multicast IP addresses). Each NAS system device must use a unique NAS IP address from the assigned subnet(s) at the device location. In addition, the FAA.GOV domain name system (DNS) resides in FAA Mission Support, which will be A-OE. As such, this will require accessibility from each operating environment, and the

FAA will accommodate a cross OE data sharing for this purpose.

5.4.2 Mission Essential -Operating Environment

While the ME-OE currently does not yet exist, it represents a “greenfield” for the development and deployment of FAA Zero Trust Architecture (ZTA). The deployment of NAS and NAS related services to the ME-OE will also use a mission and risk-based approach. The general deployment strategy is to have NAS services adopt zero trust principles and capabilities as a condition to transition from ME-Cloud boundary to the ME-OE boundary. Current Mission

Support services that do not support NAS operations will not be deployed in the ME-OE operating environment. FAA mission services that will be deployed in this operating environment are limited to National Airspace Efficiency Critical, Essential, and Routine services required to support National Airspace System (NAS) operations. ME-OE supports limited IT user activities, multifactor authentication for all functions and system, system internet access is limited to authorized system users and allowed locations, restoration time of less than 6 seconds and modified NAS maintenance policies accommodating IT.

The ME-OE will be deployed as infrastructure components in an on-premises non-cloud environment and an IaaS cloud environment. As a condition of being moved to the ME-OE, existing NAS services and MS services must support NAS operations. As the network segmentation becomes possible and operating environments are implemented, current and new mission systems and mission support systems within the NAS Domain will be assessed for assignment to operating environments. For the purposes of this document, Figure 9 depicts a high-level diagram of the ME-OE, as envisioned. As this is an ongoing effort, the FAA will continue the necessary collaboration for shaping the future of OE assignment and implementation.

Figure 8: ME-OE Envisioned Architecture

6 VENDOR CONSIDERATIONS FOR CLOUD DEVELOPMENT

The current referenced CNTB Architecture reflects certain selections and preferences on the part of the FAA. However, as discussed in Section 5.1, this architecture also leaves room for vendors to recommend alternatives or additional software elements to support CSS-FD development and acceptance. Consequently, the platform is expected to evolve over time reflecting new technologies and best practices. Generally as part of the recommendation for new tools, the FAA prefers tools and technologies that have the following characteristics:

• Open source

• Well-established

• Industry standard in their field

• Supported by multiple vendors

• Zero or low lifetime license costs

6.1 INFRASTRUCTURE AS CODE – BEST PRACTICES FOR DEVELOPMENT

Developing infrastructure as code (IaC) in a cloud environment involves using tools and scripts to automate the provisioning and management of infrastructure resources such as virtual machines, networks, storage, and services. The primary drivers for IaC adoption have been the increase in the number of deployments, the rising complexity of cloud services and architecture, and the need for cloud systems to scale up and down according to the load. Regarding repeatability of deployments – today, teams have gone from a few deployments every month to hundreds of deployments every day. At this pace, it is crucial to have a reliable and automated infrastructure management system. IaC provides a stable, tested, and collaborative framework for deploying and managing infra at scale and at pace.

6.1.1 The Complexity of the Cloud

All major cloud providers have between 150-200 tools and services they offer. This, in addition to the FAA complex hybrid cloud architectures, requires a global solution that can be quickly deployed and also adheres to the FAA security standards. By following these best practices, vendors effectively leverage infrastructure as code to provision, manage, and scale cloud infrastructure in a reliable and efficient manner. This has been done in the CNTB to support the release to the NAS.

1. The choice of IaC Tools. Select a tool such as Terraform, AWS CloudFormation, Azure

Resource Manager (ARM) templates, or Google Cloud Deployment Manager.

2. Define Infrastructure: Write code (declarative or imperative) to define the desired state of your infrastructure, including servers, networking, security policies, and more.

3. Version Control: Store IaC code in a version control system like Git to track changes and collaborate with team members.

4. Testing: Implement testing frameworks to validate infrastructure code, ensuring it meets requirements and functions as expected.

5. Continuous Integration/Continuous Deployment (CI/CD): Integrate IaC into the CI/CD pipeline to automate testing, building, and deploying infrastructure changes.

6. Infrastructure Orchestration: Orchestrate the deployment and configuration of resources across multiple cloud providers or regions using vendor chosen IaC tool.

7. Modularity and Reusability: Organize IaC code into reusable modules and templates to promote consistency and scalability.

8. Security and Compliance: Implement security best practices and compliance standards within IaC code to ensure a secure and compliant infrastructure.

9. Documentation: Document infrastructure code to facilitate understanding and maintenance by other team members.

10. Monitoring and Logging: Integrate monitoring and logging solutions to track the performance, health, and changes to infrastructure.

6.2 CSS-FD DEVELOPMENT IN THE CNTB VS VENDOR EXTERNAL ENVIRONMENT

The FAA recognizes that there may be different “development paths” to consider for code development for NAS operations. These paths include (1) having vendors participate in CNTB from Day 1 in the development environment, (2) vendors duplicating the CNTB in their environment (lift and shift) or (3) rehosting the vendor code from their environment in the CNTB

(lift and reshape). As such, the tenant program evaluates these path options from a programmatic schedule perspective. Selecting the most optimal development approach becomes a comparative analysis in the time and cost-factor for vendor re-platforming, rehosting and refactoring code builds in the target environment (see Section 6.1 for more details).

6.2.1 Continuous Development, Integration and Deployment to ME-OE

The FAA promotes users and tenants of the CNTB environment to utilize the Continuous

Integration/Continuous Delivery pipeline approach to automate the software delivery process.

The pipeline builds code, runs tests (CI), and safely deploys a new version of the application

(CD). A CI/CD (Continuous Integration/Continuous Deployment) pipeline is a set of practices and tools used to automate the software development process, from code integration to deployment. This approach enables tenants to deliver software more frequently, reliably, and with fewer errors.

Figure 10 below depicts the development lifecycle in the CNTB/ME-OE environment. Note that regardless of the tenant-vendor development path chosen, vendor development must be executed, at some level, in the CNTB – whether it be full or partial lifecycle development. For reference, the CNTB supports two deployment modalities: (1) full lifecycle from source to delivery and deployment, and (2) partial lifecycle from deployment artifacts to delivery and deployment.

Stages 1 through 5, depicted in Figure 10 are generally defined as follows:

• Stage 1: Developers create source code and other build artifacts and place them in the project repositories. Artifacts include application programming code and Infrastructure as code (IaC). Throughout the pipeline lifecycle, the artifacts build the required applications and infrastructure.

• Stage 2: During the Cd stage, quality checks are run, and if they pass, a Cd review is required to merge the code. The merge triggers the pipeline’s CI stage.

• Stage 3: The code is built and tested during the CI stage and artifacts are created and published.

• Stage 4 and 5: During the CD stage, the artifacts are deployed to a staging/UAT environments and undergo acceptance tests before released to production (5).

Figure 9: CNTB and ME-OE Lifecycle

Vendor recommendation for entry in the CNTB at stage 2 (e.g. partial lifecycle) must be validated against the tenant program cost and time constraints. Currently, CNTB components and service catalog work together to establish an automated and streamlined CI/CD pipeline, enabling tenants to deliver software rapidly, efficiently, and with improved quality. Vendor preference to build their code in another environment and rehost in CNTB should consider any cost schedule delays and additional money incurred by the government. Generally, tenant program schedule, code ownership/handoff and funding risks may be mitigated altogether via earlier vendor entry or Day 1 development in the CNTB. As such, the CSS-FD tenant will require the contractor to provide a cost benefit analysis as part of their bid that their environment will be more cost effective than building code in the CNTB.

6.3 FAA-VENDOR CODE TRANSFER

As previously mentioned in Section 6.1.1, the tenant program can take one of several positions in accepting code from the vendor: (1) Development in the CNTB from Day 1, (2) Re-platform, (3)

Rehosting. When engaging in a business relationship involving cloud services and vendor code, there are typically contractual agreements between the parties involved. These contracts outline the rights, responsibilities, terms, and conditions governing the relationship. Below highlights the approaches for code development and transfer:

• CNTB for Development: If the vendor decides to begin to develop code into CNTB, the contract needs to specify CNTB service (catalog), onboarding requirements, security requirements and specification, reporting and troubleshoot, hours of operations, etc.

• Re-platforming: When re-platforming vendor code to a different cloud environment, there could be contracts governing the use of the vendor's software, licensing terms, service-level agreements (SLAs), data protection requirements, and liability provisions in case of service interruptions or breaches. This scenario is the development of code with indifference to the cloud environment.

• Rehosting: In a rehosting scenario where the vendor's code is simply lifted and shifted to the cloud without significant modifications, there might still be contracts in place dictating the terms of use, support arrangements, maintenance obligations, and termination clauses. This scenario lends itself to the vendor recreating CNTB environment (tools and simply lifting vendor code to shifting it)

Figure 11 depicts a high-level summary of the full development process stages/zones shown in

Figure 10. This requires support to sustain and manage the operation of the pipeline in the ME-

Cloud, as well as all the necessary connections, system integrations, specifically within the

CNTB so the CSS-FD tenant can develop, integrate, test, and prepare our release for ME-Cloud.

Figure 10: Pre-Production Full Development Process

Re-platform

6.4 VENDOR DEVELOPMENT RISK REDUCTION

The CNTB environment is intended to provide the foundation for all CSS-FD component and software, whether the code is developed initially in the CNTB or in the vendor environment prior to CNTB migration. Performing a cost-benefit analysis for rehosting vendor applications to the cloud involves evaluating the financial implications and potential returns of the migration. Below are acceptable metrics that the tenant program would consider for validating a rehosting approach:

• Migration Costs: The expenses associated with lifting and shifting the vendor's applications to the cloud, including migration tools, professional services, and any temporary infrastructure needed during the transition period.

• Infrastructure Costs: The ongoing costs of cloud resources (e.g., compute instances, storage, networking) required to host the applications in the cloud.

• Operational Costs: The additional expenses for managing and maintaining the applications in the cloud, such as monitoring, security, backups, and support.

• Training Costs: Costs of training staff on cloud technologies and best practices for managing cloud-based applications.

• Potential Downtime Costs: Potential impact of downtime during the migration process and any associated costs, such as lost revenue or productivity.

• Security: Integration and how protected the vendor’s environment is over the FAAs

6.4.1 Other Considerations

• Scalability: Determine the potential cost savings from leveraging cloud scalability to adjust resources based on demand, avoiding over-provisioning or under-utilization of infrastructure.

• Flexibility: Evaluate the benefits of greater agility and flexibility in deploying and scaling applications in CNTB.

• Performance: Consider the potential improvements in application performance and integration times resulting from hosting in CNTB, such as faster deployment times.

• Opportunity Costs: Consider any additional revenue-generating opportunities or competitive advantages enabled by migrating earlier into CNTB. Once you have identified and quantified the costs and benefits, you can conduct a thorough analysis to determine whether rehosting the vendor applications to the cloud is financially advantageous. This analysis can help stakeholders make informed decisions and prioritize investments based on their potential return on investment (ROI) and alignment with business objectives

APPENDIX A – CNTB & ME-CLOUD DEFAULT TOOLS: DEVSECOPS

Purpose / Description CNTB DevSecOps Tools

Traffic management, routing rules, service access

OpenShift (NGINX operator, or HAProxy Ingress controller (native), K8s native)

Distributed version control manager (Git) GitLab

Artifact management GitLab, OpenShift

Infrastructure as code tool, provisioning Terraform (HashiCorp)

CI/CD pipelines, version control, deployment patterns OpenShift (Tekton)

Declarative continuous delivery OpenShift (Argo CD)

Build pack provider/Software Bill of

Materials (SBOM) GitLab (Cloud Native Buildpacks)

Role based namespace security context inheritance manager OpenShift

Infrastructure resource request management OpenShift, GitLab (Auto Deploy)

Policy engine OpenShift (Kyverno)

Cluster elasticity manager OpenShift (Kubernetes)

Service mesh Consul (Hashicorp), OpenShift (Apigee)

Automated unit test GitLab

Automated runtime function test GitLab (Selenium)

Static code quality and vulnerability scan GitLab CodeQuality, SonarQube plugin

Dynamic/runtime vulnerability scanner GitLab (SAS, DAST, and Dependency container

Scanning)

Cloud native (containers) realtime vulnerability scanning

GitLab (SAS, DAST, and Dependency container

Scanning), Aqua plugin

Capture and export performance metrics OpenShift (Prometheus), many other plugins (ELK, Datadog)

Cluster performance monitoring, notifications and alerts

Dynatrace (OpenShift plugin), and many other

OpenShift plugins

Log retention, monitoring, notifications and alerts

Splunk (OpenShift plugin), and many other OpenShift plugins

Real-time visibility into cloud costs OpenShift (OCM)

Certificate management controller OpenShift (cert-manager, Vault plugin)

Secrets manager Vault (HashiCorp)

Purpose / Description CNTB DevSecOps Tools

User authentication, role based access control

(RBAC), separation of duties, least privilege

AWS Identity Center. via Red Hat SSO (Keycloak)

Identity and Access Management (IAM) HA with potential for MyAccess FA AD Federation

APPENDIX B – ACRONYMS AND ABBREVIATIONS

Acronym/Abbreviation Definition

AES Automation Evolution Strategy

API Application Programming Interface

ATO Air Traffic Organization

AWS Amazon Web Service

CI/CD Continuous Integration / Continuous Delivery

CSP Cloud Service Provider

CSS-FD Common Support Services – Flight Data

CNTB Cloud National Test Bed

DevSecOps Deployment, Security, Operations

ESIF Enterprise Services Infrastructure Framework

FAA Federal Aviation Administration

FENS FAA Enterprise Network Services

FISMA Federal Information Security Modernization Act

IaaS Infrastructure as a Service

IAM Identity and Access Management

LZA AWS Landing Zone Accelerator

ME-Cloud Mission Essential Cloud

ME-OE Mission Essential Operating Environment

NAS National Airspace System

PaaS Platform as a Service

PPS Ports, Protocols and Services

PRD Program Requirements Document

REST Representational State Transfer

RH SSO Identity and Access Management

SSO Single Sign-On

SWIM System Wide Information Management

SIEM Security Information and Event Management

URL Uniform Resource Locator

WJHTC William J. Hughes Technical Center