Solution Implementation

The Information Systems Security (ISS) engineering activities during the earlier phases provide the basis for the updating, monitoring, and controlling system security risks and the respective mitigation measures or controls that are implemented during this phase of the system development. A summary of ISS engineering activities for this phase includes the following:

• Revise the security related statement in the CONOPS and security requirements based on functional analysis performed during early stages of the Solution Implementation phase.
• Analyze the physical/system architecture, resulting in an allocation of the securityfeatures to be implemented in the system under development. Security trade studies may be needed to identify the appropriate security controls to be implemented that balance system and security requirements.
• Integrate the security features into the security architecture to balance them with the system architecture and design. Security trade studies, interface securityrequirements, and other Systems Engineering (SE) outputs contribute to successful integration of security architecture into system design. System design reviews are key milestones for ensuring that security controls are integrated into system development.
• Update the ISSP, one of the SCAP documents based on the expected ISS functional and assurance controls derived from the system architecture and design. Refine the system test planning and procedures to ensure that all security requirements and controls are addressed. The ISSP supports Validation (SEM Section: 4.12, subsection 4.12.1) and Synthesis (SEM Section: 4.5) to assess controls and assurance as being cost effective and meeting the ISS requirements. Use Risk Management (SEM Section: 4.10) and Requirements Management (SEM Section: 4.3) to mitigate security risk to acceptable levels. The criticality/sensitivity of the system and its information assets guides the type and level of controls and testing.
• Develop a user's guide, training plans, and Contingency/Disaster Recovery Plans (C/DRP). Security procedures, rules, training, and planning for C/DRP operations may be integrated into the integrated logistics support and lifecycle planning for systems.
• Conduct security testing. Security controls and mechanisms may be testedincrementally and as a part of system development testing. For mission-criticalsystems, a third party shall conduct independent testing of system vulnerabilities.
• Create final the Security Certification and Authorization Package (SCAP) documents. The results of ISSE activities-including relevant results from related SE elements such as Integrated Technical Planning (SEM Section: 4.2), Synthesis (SEM Section: 4.5), Validation and Verification (SEM Section: 4.12), and Lifecycle Engineering (SEM Section: 4.13)-shall be considered as final SCAP documents. The Air Traffic Organization provides templates for collecting and presenting the SCAP documentation.

Investment Analysis

Integrating the Information Systems Security (ISS) engineering process with the SE elements is essential. During the Initial Investment Analysis (IIA), ISSE develops and documents the need for security in the CONOPS and the initial security requirements for the Preliminary Requirements document (pPR). The Investment Analysis (IA) team uses the system program CONOPS and the security requirements to evaluate the system alternatives. The security engineers in the product team conduct a preliminary vulnerability and security risk assessment using updated threat and vulnerability data to determine the specific risks that must be controlled or mitigated. The security trade studies are performed to evaluate the system alternatives and to assess the security risk controls/mitigation measures related to the system alternatives. Also, the security trade studies identify the native, existing system, and/or network features that reduces the likelihood of the system threats successfully exploiting a vulnerability. These trade studies compare the costs and benefits of the system features/security controls in terms of risk reduction. Trade studies may evaluate the cost-effectiveness of different controls for a given risk or set of risks. Also, system alternatives may require different types of controls to balance the system performance and security requirements against the security risks/costs of the different alternatives. The different system alternatives may have significantly different physical and/or system architectures that would require different security controls that may lead to different security costs and effectiveness.

During the final stage of the IA phase, the ISS engineering refines and updates the preliminary vulnerability and security risk assessment. Updated threat and vulnerability data is applied, analyzing the costs and effectiveness of system features and security controls that are associated with each of the final system alternatives. ISS engineering provides the final security requirements for the final Program Requirements document (fPR) and the system specification, as well as special requirements for the Solicitation Information Request (SIR) and contract Statement of Work (SOW). In developing the final system requirements, ISS engineering analyzes and establishes the appropriate assurance level to be proven during system implementation. The assurance in this context addresses the required level of confidence in the security function, performance and ensures that the security controls function in an integrated fashion. The assurance can be gained through many techniques, including conformance testing, independent verification testing, and employing diverse and/or redundant capability.

The ISS engineering shall support a documented agreement among the FAA stakeholders regarding the necessity and sufficiency of the security requirements. It should clearly document the agreement to the security requirements before the investment decision becomes the foundation for the Security Certification and Authorization Package (SCAP), which shall be completed before the In-Service Decision (ISD). During the IA, ISS engineering identifies the technically qualified, senior FAA official who shall certify that the system security controls meet the minimum FAA/NASISS requirements (see DAA discussion in SEM section: 4.8.6). The ISSP, which was based on the NISTSP 800-18 and was a conceptual draft during the Mission Analysis of the AMS phase, is updated to become an initial draft.

The ISS engineering products from this phase include the updated preliminary and vulnerability security risk assessment, final security program requirements, security trade studies to support cost-benefit/investment analysis of security controls, and input to the SIR, SOW, system specification, and Contract Data Requirements List (CDRL) for systems to be acquired. These products support the AMS milestone decision for transition into the Solution Implementation phase.

In-Service Management

Activities during this phase include the following:

• Follow and conform to the final SCAP template as required for the final SCAP documents.
• Obtain the security Certification and Authorization (C&A). Stakeholder C&A review shall ensure that the DAA is in a position to certify and authorize the system as meeting the security requirements and as presenting an acceptable risk to the FAA mission and NAS operations.
• Conduct the performance measurement, monitoring, and reporting of the security controls and incidents. Ensure that the monitoring of ISS performance and assurance for the respective NAS service/capability has not degraded and that the new vulnerabilities have not been introduced to the operational system.
• Update the SCAP to reflect any major configuration changes at least every 3 years, assessing the changes in the environment and system for previously unforeseen risks from new threats and vulnerabilities. Plan and take corrective action as necessary.
• For disposal of the system, the following types of activities may be addressed in the Information System Security Plan, and conducted at the appropriate stage of the System Development Lifecycle
  • Archive Information - Retain information as necessary, keeping in mindlegal requirements and future technology changes that render the retrievalmethod obsolete.
  • Sanitize Media - Ensure data is deleted, erased, or written over asnecessary.
  • Dispose of Hardware and Software - Dispose of the hardware and software in accordance with ISS policy.

Data Management

It is the FAA's intent to terminate point to point (local) connections between FAA NAS systems and outside entities as soon as possible and to replace them with connections made via secure gateway. The FAA will work with aviation partners to accomplish their transition within a reasonable period of time, consistent with each aviation partner's particular situation. The FAA is willing to meet with aviation partners collectively or individually to discuss surveillance technologies available.

What is the definition of a "secure gateway"?
A secure gateway blocks or filters access between two networks, often between a private network and a larger, more public network such as the Internet; allowing internal users to connect to external networks while protecting internal systems from compromise (NIST Special Publication 800-14, 1996). The National Airspace System (NAS) Enterprise Security Gateway (NESG) infrastructure provides a framework for compliance with boundary protection service requirements between NAS and non-NAS systems/networks in accordance with FAA Order 1370.114. The NESG infrastructure includes a layered security scheme to facilitate defense in depth security controls and provides a buffer between the NAS and external systems/networks to ensure no direct service connections to NAS systems. This follows the National Institute of Standards' approach to network security, which is mandatory for all agencies.

How will the FAA achieve NESG redundancy and ensure data feed availability?
NAS data feed redundancy will be achieved through duplication of NAS data service collections points behind the NESGs and dynamic data rerouting to the available gateway location. The FAA recommends NAS data consumers connect to multiple NESG physical locations by the following methods: Use of internet-based virtual private network (VPN), user-provided dedicated transmission service (DTS), or user-provided local Ethernet connection. However, the FAA does not guarantee or warrant NAS data feed availability to any external user.

What are the "no cost" NAS surveillance data feeds and where are they located?
No-cost FAA data sources available through the NESG include Aircraft Situational Display to Industry (ASDI) and Airport Surveillance Detection Equipment, Model X (ASDE-X) data. ASDI provides NAS air surveillance data, while ASDE-X provides NAS ground surveillance data for 28 of the 35 ASDE-X-equipped airports. Both data feeds are available through the NESG at the FAA Technical Center, Atlantic City, NJ (Primary) and the FAA Aeronautical Center, Oklahoma City, OK (Backup).

Where will ARTS data be available after transition to a secure gateway?
ARTS data is presently available within the ASDI feed through the NESG.

Will secure gateway data feeds retain the same data sets and the level of data fidelity as local connections?
NAS data feeds provided through a secured gateway will generally retain the same level of fidelity as previously experienced with a local connection, but may not contain all data sets previously available. As noted above, the FAA does not warrant or guarantee the availability of NAS data feeds.

Why do vendors charge for access to surveillance products when the data is provided by the FAA at no-cost?
NAS surveillance data is made available at no cost to aviation partners. Commercial vendors charge to recover their investment during the collection and distribution of NAS data, including any conversion to commercial information products.

How will the FAA treat Memoranda of Agreement (MOA) for local connections that have not expired?
The FAA will attempt to honor existing MOAs for local connections, assuming efforts are being made to transition to a secured gateway before MOA expiration. Each situation is different and will be evaluated as such.

Should aviation partners work directly with the FAA Service Area representatives to develop their transition plans?
The FAA highly recommends collaboration with Service Area representatives for transition plan development guidance and procedures for removal of equipment from TRACONs.

When does the FAA expect to receive transition plans?
As previously discussed, the FAA has requested submission of transition plans to the Service Areas before December 15, 2012. The objective is to complete aviation partner transition to secure gateway by the end of Fiscal Year 2013.

If an aviation partner's Memorandum of Agreement (MOA) for local connection expires before their transition to a secure gateway, will the aviation partner be required to submit a new MOA for the local connection?
The FAA will require submission of a new FAA Form 1200-5 and MOA. The FAA Form 1200-5 must indicate the aviation partner's intent to transfer to a secure gateway by the date specified in their transition plan.

After transition to secure gateway, will a MOA between the FAA and aviation partners be required?
In the end state, the MOAs between the FAA and aviation partners will not be required, but replaced by an "on-line terms of use." The FAA is attempting to coordinate a transition to secure gateway connections and a revised "agreements" process. The transition to secure gateway connections has greater priority. FAA SysOps will continue to monitor the transition.

VGLS - Light Emitting Diode (LED) Initiative

The Energy Independence and Security Act (EISA) of 2007 requires FAA to transition incandescent lamps to LED technology. LED technology uses far less energy with much higher reliability, which provides significant cost and efficiency benefits. Current lighting systems use PAR- 38 and -56 lamps that will need to transition to LED lamps. To meet future requirements the FAA has determined the most economical approach to replace incandescent lamps is to use the existing infrastructure of 950 MALSRs. Commercial LED lamps do not meet this requirement, the FAA needed to develop a special LED lamp. The LED lights color and intensity must be suitable for pilots to use without degradation. Replacement lamps must be qualified to ensure pilots can use the light safely before a replacement program can proceed. 

NAS Defense Programs

Mission:

Execute the DOT commitment to support national security by minimizing the vulnerability of the National Airspace System (NAS) to disruption, damage, or exploitation through crime or terrorism by providing sensitive and classified flight data, surveillance, and communications services to the DoD, DHS, and Federal law enforcement agencies in support of military activities, homeland security, POTUS movements, and national security events.

Strategy:

Utilize external funding and existing federal infrastructure and human resources to expand voice, flight data, and surveillance services to meet external requirements. Evaluate current and planned federal assets, plans, policies and procedures for application in developing and sustaining National Air Security capability.

NDP Roles & Responsibilities

• Immediate Response to National Security and Disaster Assistance Requests
• National coordination of operational issues and restoration activities with Operational Control Centers (OCC's)
• Serves as the agency focal point for NAS Defense policy and procedures
• Develops, consolidates, and services inter-agency and international agreements
• Integrates new external services and equipment into the NAS operational and support architecture
• Supports FAA intra-organization/inter-agency coordination of National Security activities
• Life-Cycle Management of NAS Defense Services & Equipment
• ATO Technical Operations Preventive and Corrective Maintenance of NAS Defense Equipment
• Logistical support via FAA Logistics Center of all NAS Defense Equipment
• Provides dedicated FAA program staffing and resources to support internal and external customer requirements
• Promotes continuous external customer feedback for product and service improvement
• Management of FAA Order 6000.198 "FAA Maintenance of NAS Defense Facilities and Services"

POC for more information about NAS Defense Programs (NDP) contact Tom Sylvia or call 202-409-0515

Navigation Programs - GNSS Outreach & Public Relations

Satellite Navigation - NAS Implementation

NAS Implementation - Procedures - RNAV (RNP) IAPs

Required Navigation Performance (RNP) is similar to Area Navigation (RNAV); but, RNP requires on-board navigation performance monitoring and alerting capability to ensure that the aircraft stays within a specific containment area.

There are several different levels of RNP. Examples of RNP levels used for approach include RNP 0.1, RNP 0.3, and RNP 1.0 (There are also RNP 4.0 and RNP 10.0 levels that apply in the en route environment). "A performance value of RNP 0.3, for example, assures that the aircraft has the capability of remaining within 0.3 of a nautical mile to the right or left side of the centerline 95 percent of the time." (FAA Instrument Procedures Handbook, p. 5-12)

Two typical applications of RNP for approach are shown in the table below. These are:

• RNP Authorization Required (AR) Approach Segments
• RNP Approach Segments

RNP Authorization Required (AR) Approach IAPs

RNP Authorization Required (AR) Approach IAPs require authorization analogous to the Special Aircraft Authorization Required (SAAR) for Category II or III Instrument Landing System (ILS) procedures.

Authorization Required (AR) procedures may only be conducted by aircrews meeting special training requirements in aircraft that meet the specified performance and functional requirements.

The minima line will include a performance value, RNP 0.30 for example. GPS with WAAS can support RNP 0.3 and above.

Example: RNAV (RNP) Z RWY 24 at Carlsbad/McClellan-Palomar (CRQ)

RNP Approach IAPs

At present, there are no RNP Approach IAPs that are not of type AR. This may change in the future.

More information about RNAV (RNP) IAPs can be found the AIM.

« Back to NAS Implementation - Procedures

Satellite Navigation - NAS Implementation

NAS Implementation - Procedures - RNAV (GPS)

Area Navigation (RNAV) a method of navigation that permits aircraft operation on any desired flight path within the coverage of ground or space based navigation aids or within the limits of the capability of self-contained aids, or a combination of these. (AIM, section 1-2-1)

Reliance on RNAV systems for instrument operations is becoming more commonplace with the use of systems such as GPS and augmented GPS, such as WAAS and GBAS. (For more information, see the AIM, section 5-4-5)

For RNAV (GPS) IAPs, there can be up to four lines of minima for pilots to consider depending upon aircraft equipage, certification, and pilot training.

These lines of minimum include:

• LPV
• LNAV/VNAV
• LP
• LNAV

More information can be found in the RNAV (GPS) Approaches fact sheet(PDF).

Also, for a current list of LPVs, LNAV/VNAVs, LPs, and LNAVs; please visit our GPS/WAAS Approaches page.

« Back to NAS Implementation - Procedures

Satellite Navigation - NAS Implementation

NAS Implementation - Procedures - Localizer Performance (LP)

Localizer Performance (LP) approaches are non-precision approaches with Wide Area Augmentation System (WAAS) lateral guidance. They are added in locations where terrain or obstructions do not allow publication of vertically-guided LPV procedures.

Both LP and LNAV lines of minima are Minimum Descent Altitudes (MDA) rather than DAs. It is possible to have LP and LNAV lines of minima published on the same approach chart. An LP is published if it provides lower minima than the LNAV. See AIM 1-1-20.

Example: RNAV (GPS) RWY 18 at Independence Municipal, Iowa (IIB)

« Back to NAS Implementation - Procedures