USA Banner

Official US Government Icon

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure Site Icon

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

United States Department of Transportation United States Department of Transportation

ato

Left Nav - Air Traffic Organization

Begin Solution Implementation (SI) for AMS decision point: #5

(Re-baseline:OMB Exhibit 300, Attachment 1, 2 & 3 for the In-Service Decision (ISD))

Note: The symbol "*" indicates that the FAA firewall access is required to view this link.

Review

Update

Generate

Obtain

  • DAA signature(s) of Certification and Authorization to connect and operate system in the NAS.

Deliverables

  1. SCAP Implementation Guide(Reference: SCAP implementation guide - Section 4.1.1 *)
  2. Baselined OMB Exhibit 300, Attachment 1:
    • ISS section of the Final Requirement Document(fPR).
      • Security Interfaces in the IRD.
  3. Baselined OMB Exhibit 300, Attachment 2, & 3
  4. The security information for SIR, SOW & CDRL.
  5. DAA signature(s) of Certification and Authorization to connect and operate the system in the NAS.

End SI for AMS decision point: #5 & AMS Phase: SI

Integrate Security Requirements with System Requirements (h)

AMS Lifecycle Phase:Solution Implementation

Description

After reviewing and updating the security requirements, they can be integrated with the general system requirements. This integration ensures that security requirements receive the appropriate attention from the product team of that program office developing the system. Determining the security features, assurances, and operational practices may yield significant security information and often voluminous requirements. This information needs to be validated, updated, and organized into the detailed security protection requirements and specifications used by system designers and/or purchasers. Synthesis of trade studies, interface requirements, and other Systems Engineering outputs will lead the integration of security architecture into the system design. System design reviews are the key milestones for insuring the security controls are integrated into the system development.

Processes of integrating security requirements with systems requirements

Tasks

  • Update the security requirements after updating the risk and vulnerability assessment
  • Integrate security requirements with the system requirements
  • Track security requirements as part of the key milestones

Resources

  • NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems
  • FAA's System Engineering Manual

Create Final Security C&A Documents (n)

AMS Lifecycle Phase:Solution Implementation

Description

Certification is an official signed statement by the Information System Security Certifier (ISSC) attesting to Agency management and Congress that the following conditions have been satisfied:

  • The system has been evaluated in accordance with FAA Order 1370.82, and
  • The system, as defined in the accompanying Certification and Authorization (C&A) package, is operating securely, or
  • The system is safe to continue operations pending implementation of the identified risk mitigation activities

Authorization is an official signed statement by the Designate Approving Authority (DAA) attesting to Agency management and Congress that:

  • In accordance with the system Certification, the system is authorized to operate in the National Airspace System (NAS), and
  • The system, as defined in the accompanying C&A package, is operating securely and safely as mitigated with the identified residual risk, or
  • The system is safe to continue operations pending implementation of the identified risk mitigation activities

Review the document, "Information Systems Security Program Implementation Guide (SCAPs)" for overview of the Air Traffic Organization's (ATOs) system Security Certification and Authorization package (SCAP) documentation development process and related processes.

The documentation required for the FAA for final C&A is defined based on the System Certification and Authorization Package (SCAP) prepared for the system. The ATO Information Systems Security Program office provides the templates for producing the documentation required by SCAP level of effort (LOE) currently applied to the FAA systems. The SCAP template may change depending on the ISS program office decisions. Review the document, "Information Systems Security Program Implementation Guide (SCAPs)" for the following lists of the applicable SCAP documents. Go to the ATO Information Systems Security Program website for the latest downloadable SCAP templates.

The SCAPLOE is based on mandated annual assessment or the full assessment. The certain LOE indicates a more complete and effective security program. In general, the LOESCAP required depends on the complexity of the system, operational criticality and the level of impact to the system.

Note that special handling procedures apply to SCAP documentation:

  • Transmission is from FAA to FAA
  • All SCAP documentation is controlled
  • Distributed with document tracking forms
  • Transmitted via hard copy only
  • Not made available via the Web (Internet, Intranet, or Extranet)
  • Distribution beyond the SCPA review/approval chain requires prior approval from the system owner, Directorate Security Program Office and designated ISSM.

Tasks

  • Prepare Plan of Action and Milestones (POA&M), including estimated length of approval cycle
  • Meet with Line of Business (LOB) Information Systems Security Manager (ISSM) to verify level of effort SCAP to be prepared and review POA&M
  • Identify key C&A approval personnel with ISSM
  • Identify required resources, document authors and production schedule
  • Identify test schedule and other supporting milestones

Resources

  • NIST Special Publication (SP) 800-53 Rev.1, Recommended Security Controls for Federal Information Systems
  • NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems
  • NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems
  • FAAISSA Handbook
  • ATO — Information Systems Security Program Implementation Guide (SCAPs)

Develop User's Guides, Training, and Contingency Plans (l)

AMS Lifecycle Phase:Solution Implementation

Description

The Computer Security Act requires federal agencies to provide for the mandatory periodic training in computer security awareness and accepted computer security practices for all employees who are involved with the management, use, or operation of a federal computer system within or under the supervision of a federal agency. This includes contractors as well as FAA employees. Each user must be versed in acceptable rules of behavior for the application before being allowed to access the system. The training program should also inform the user on how to get help when having difficulty using the system and procedures for reporting security incidents.

A system user's guide should be developed that clearly explains how to use the system. All users should be required to review the document and sign a statement that they have read and understand the guide. The guide explains how the software/hardware is to be used and formalizes security and operational procedures specific to the system. The guide should include a description of the hardware and software, as well as descriptions of user and operator procedures.

An example of the security awareness training program requirement that the FAA meets are accomplished this through the use of two tools the CSAT and SAVI.

The contingency/disaster recovery planning (C/DRP) should ensure that interfacing systems are identified and coordinated. Review the document "Information Systems Security Program Implementation Guide (SCAP)" to see what should be addressed in the C/DRP. Procedures are required that will permit the FAA to continue its essential functions if an individual system is interrupted. These procedures should include with plans for the backup, contingency, and recovery of any support systems including networks used by the application. The Product Teams must describe the procedures and coordination of to what would be followed in the event where the system is no longer operational.

Tasks

  • Develop the user's guide for the system and make it available to all users
  • Ensure that all users (including contractors) take the periodic security awareness training available on the FAA's intranet
  • Develop a contingency and disaster recovery plan for the system
  • Coordinate all contingency plans with the sites and CSIRC

Resources

  • OMB Circular A-130, Appendix III
  • Computer Security Act of 1987
  • NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems
  • NIST's Computer Security Resource Center's Incident and Emergency Response References Table
  • FAA's Computer Security Awareness Tool (CSAT)
  • Security Awareness Virtual Instruction (SAVI)
  • FAA's ISS Handbook
  • Information Systems Security Program Implementation Guide (SCAP)

Conduct Security Testing (m)

AMS Lifecycle Phase:Solution Implementation

Description

Product Teams should conduct routine tests of their systems and verify that their systems are properly configured with the appropriate security mechanisms and policies. These routine tests help prevent many types of incidents from happening in the first place. Security testing is the best way to determine if the system configured to the correct security controls and policies.

The Operational Test and Evaluation (OT&E) demonstrates that the system is operationally effective and operationally suitable for use in the NAS. This includes its ability to protect itself and the NAS from security incidents. Integrating security testing with OT&E is a step toward ascertaining whether the system is operated according to its security requirements (both operational and technical controls). The test focuses on demonstrating that operational requirements, including security, have been met and that all critical operational issues have been resolved. This test is typically conducted at the Technical Center, before the system is placed in the field. The objectives of this test are to uncover design, implementation, and operational flaws that could allow the violation of the Basic Security Policy, determine the adequacy of security mechanisms, assurances and other properties to enforce the security policy, assess the degree of consistency between the system documentation and its implementation.

Testing the security controls during Site Acceptance Testing (SAT) allows the product team to evaluate how those security controls work at the site and make any adjustments for "real-world" situations that may not have been present during testing in a lab. This testing includes both the actions of people who operate or use the system and the functioning of the technical controls. This testing should also be conducted after the system has undergone major upgrades to be sure it is still configured to the appropriate security mechanisms and security policies.

The results of the security testing should be documented and submitted as part of the SCAP. OT&E security test report should document that testing that took place and any vulnerability that were discovered. This can be used to develop a mitigation schedule and plan. Security test results should be made available for staff as a reference point for defining mitigation activities, and to assess the implementation status of system security requirements. The results can also enhance risk assessments and performance improvement efforts, as well a benchmark for tracing an organization's progress in meeting the security requirements.

Tasks

  • Review the Information Systems Security Program Implementation Guide for latest SCAP template
  • Develop Security Test Plan
  • Develop Security Test Procedures
  • Run test along with SAT and OT&E
  • Develop Security Test Report
  • Develop Mitigation Plan and Schedule for completion of mitigation tasks

Resources

  • NIST Special Publication 800-42, Guidelines on Network Security Testing
  • NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle
  • FAA's ISS Handbook

Begin Final Investment Analysis (FIA) for AMS decision point: #4

(Start:OMB Exhibit 300 Attachment 3 for the Final Investment Decision (FID))

Review

Update

  • SCAP with your Service Unit/Service Area Certification Team Lead.
  • CONOPS of system.
  • ISS section of the Preliminary Requirements for the Final Requirement Document (fPR).
    • Security Interfaces document for inclusion in Interface Requirement Document (IRD).
  • The ISSP.
  • System characterization/categorization.(FIPS-199)
  • Vulnerability and risk assessment.

Generate

  • Initial Security Test Plan & Report.
  • Support for system addition to the ATO Five Year SCAP Plan with your Service Unit/Service Area Certification Team Lead and ISSO.
    • Proposed schedule, security characterization/categorization (FIPS-199) and planned sites where a system would be fielded to the ISSM
  • Security Information for Solicitation Information Request (SIR), Contract Statement of Work (SOW) and Contract Data Requirement List (CDRL).

Obtain

  • Stakeholders’ buy-ins and signing of the final security documents.

Deliverable(s)

  1. Updated OMB Exhibit 300, Attachment 1:
    • (pPR) transformed into Final Requirement Document (fPR).
  2. OMB Exhibit 300, Attachment 2:Business Case Analysis Report (BCAR)
  3. OMB Exhibit 300, Attachment 3:Implementation Strategy/Planning (ISP)
  4. Final security vulnerability and risk assessment.
  5. SCAP documents
    • ISSP with security policy statement.
    • System characterization/categorization.
    • Security Test Plan & Report (See note above.)
  6. Proposal of schedule, FIPS-199, and plan toward ATO Five Year SCAP Plan for your added system.
  7. The security information for SIR, SOW & CDRL.
  8. Stakeholders’ signatures on all finalized security documents

End FIA for AMS decision point: #4 & Phase: IA

Develop Security Test Plans and Procedures (k)

AMS Lifecycle Phase:Solution Implementation

Description

The security controls developed for a new information system must be tested and evaluated prior to deployment to ensure that the controls are working properly and are effective. Some types of security controls (primarily those controls of a non-technical nature) cannot be tested and evaluated until the information system is deployed - these are typically management, technical and operation level controls. For these security controls that can be assessed prior to deployment, a security test plan and test result report is developed. This plan guides the security testing and evaluation of the security controls for that system.

Security testing should confirm that the assumptions in the system security requirements have been implemented as assumed and that the total set of security controls are adequate to reduce the residual risks to an acceptable level.

If possible, an independent third-party should be involved in the testing of the security controls on the system. This test should give an unbiased view of the system and find vulnerabilities that may have been overlooked previously.

Tasks

  • Develop Security Test Plan and Test Results Report document
  • Develop Security Test procedures
  • Review the latest Security Controls for that system
  • Test the system
  • Bring in an independent third party to perform additional testing
  • Update the Security Test Plan and Test Result Report based on results of the tests

Resources

  • NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle
  • NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems
  • FAA's ISS Handbook
  • ATO - Information Systems Security Program Implementation Guide (SCAP)

Update the ISSP (j)

Wednesday, November 27, 2024

AMS Lifecycle Phase:Solution Implementation

Description

Why do we need the Information Systems Security Plan (ISSP):

FISMA requires the FAA to have ISSP for the information security programs to assure the adequate information security for networks, facilities, information systems or groups of information systems, as appropriate. The ISSP is required for every FAANAS or non-NAS system. The preparation of ISSP for an information system ensures that the required security controls (planned or in place) are fully documented. The key attachments may include the references to documents supporting the FAA's information security program within the System Certification and Authorizations Package (SCAP).

What does the ISSP do:

The ISSP identifies the information system components; operational environment; sensitivity and risks; and detailed, cost-effective measures to protect a system or group of systems. The ISSP objective is to fulfill one of the final components of the SCAP document required within the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, Appendix III, and by the Computer Security Act of 1987 (Public Law 100-235). The existence of, and adherence to, an ISSP is one of the fundamental requirements for the SCAP.

What is the content of the ISSP:

The following FAA documents, Systems Engineering Manual (SEM) Section 4.8, ISS Handbook, and Information Systems Security Program Implementation Guide to review the detailed information toward the preparation of ISSP. Also check for latest updates of what the contents should include. The structure is based on the National Institute of Standards and Technology (NIST) Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems.

Consider including these following information to the ISSP:

  • System Identification
  • System Environment
  • Sensitivity of Information Handled
  • Management Controls (Risk Assessment, Review of Security Controls, Rules of Behavior, Life Cycle Security Planning, Accreditation/Authorization)
  • Operational Controls (Personnel, Physical, Hardware and Software Maintenance Controls, Integrity Controls, Documentation, Security Awareness and Training, Incident Response Capability)
  • Technical Controls

ISSP Maintenance requirements:

The ISSP must be maintained throughout the entire system life cycle. It is considered complete when the selected controls are tested and the designated authorized FAA official signs the final SCAP. The ISSP is routinely updated on annual or every three years as part of the SCAP process or earlier to reflect significant changes that may impact the system's security posture. A recertification of the SCAP documents may be required depending on the level of impact to the FAANAS or non-NAS systems.

Tasks

  • Finalize the determination of whether it is for the NAS or non-NAS system
  • Determine the update requirements based on the level of impact to the NAS or non-NAS system; annual, once every three years or recertification

Resources

  • OMB Circular A-130, Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources
  • 44 USC 35, Subchapter II, Federal Information Security Management Act (FISMA)
  • Public Law 106-398, Government Information Security Reform Act of 2000 (GISRA)
  • NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle
  • NIST Special Publication 800-27, Engineering Principles for IT Security
  • NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems
  • NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems
  • FAA's ISS Handbook
  • FAA — Systems Engineering Manual (SEM)
  • ATO — Information Systems Security Program Implementation Guide (SCAPs)

Integrate Security Architecture and Design (i)

Wednesday, November 27, 2024

AMS Lifecycle Phase:Solution Implementation

Description

The security architecture and design have a significant impact on the system's vulnerabilities and testing. A good design includes the testability as criteria. Having the proper security architecture provides a framework for cost-effective development of the security services by reducing the security impact of developing systems and services with unknown security properties. Security architecture and design should include techniques (encapsulation and isolation) and mechanisms (DMZs, and firewalls) to mitigate the vulnerabilities and risks and the cost of ST&E.

Security architectures that integrate countermeasures or controls should be considered. These countermeasures or controls include point solutions for individual networks (firewalls and intrusion detection systems [IDS]), security information management (SIM) systems, and SIM integration with a secure network management (SNM) system.

Tasks

  • Configure the operating system and applications with proper allocated security controls or policies
  • Provide physical and personnel security to support the access controls to the systems
  • Develop Management, Operational and/or Technical controls to mitigate the listed security risks

Resources

  • FAA Order 1370.82A, Information Systems Security Program
  • FAAs Systems Engineering Manual (SEM)
  • ATO — Information Systems security Architecture (ISSA). Latest version

Update CONOPS and Security Requirements (g)

Wednesday, November 27, 2024

AMS Lifecycle Phase:Solution Implementation

Description

After the risk and vulnerability assessment has been updated, it is time to update the CONOPS and more specifically define the security requirements. There is no such single security CONOPS document. The CONOPS document is written to communicate the overall quantitative and qualitative system characteristics to the stakeholders (user, buyer, developer, and other organizational elements). Therefore, as new risks and vulnerabilities are defined for the system, the CONOPS needs to be updated so all of the stakeholders are aware of the new issues. The CONOPS aids in the requirements capturing and communicates the need to the developing program office. Since the high level requirements (including security) are also part of the CONOPS, the security requirements needs to be updated to reflect the issues addressed in the updated Risk and Vulnerability Assessment.

The CONOPS describes the user's operational needs without delving into technical details. It provides a mechanism for expressing ideas and concerns on possible solution strategies and builds consensus among user groups, acquisition organizations, and developers.

The CONOPS describes the user's operational needs without delving into technical details. It provides a mechanism for expressing ideas and concerns on possible solution strategies and builds consensus among user groups, acquisition organizations, and developers.

The CONOPS document is a means of bringing together people, policy, and technology.

Tasks

  • Review the updated Risk and Vulnerability Assessment report in the SCAP
  • Ensure that the CONOPS and Security Requirements reflect the results of the Risk and Vulnerability Assessment
  • Update the CONOPS and Security Requirements and forward the updates to the requirements team

Resources

  • NIST Special Publication 800-64, Security Considerations in the Information System Development Lifecycle
  • FAA System Engineering Manual
  • NAS SR-1000, security section