Integrate Initial Security Needs and Threat Stipulation into the MNS (a)

AMS Lifecycle Phase:Mission Analysis >>> Service Analysis

Description

The needs determination is the evaluation of the capacity of an organization's assets to satisfy existing and emerging demands. The traditional components of needs determination are establishing a basic system idea, preliminary requirements definition, feasibility assessment, technology assessment, and a formal approval to investigate further. The same holds true for security needs.

The list below provides an example of the perceived threats to the NAS:

• Intrusion or unauthorized access to system resources
• Insertion of malicious code, software/hardware, or database modification
• Exploitation of known software weaknesses
• Corruption by system, system errors, or failures
• User abuse or fraud
• Inadvertent acts of carelessness
• Natural disasters
• Saturation of communications or resources
• Theft, sabotage, vandalism, or physical intrusion
• Physical cable cuts
• Jamming (telecomm)
• Installation errors
• Eavesdropping or shoulder surfing
• Data entry errors or omissions
• Misrepresentation of identity/impersonation
• Environmental conditions
• Improper disposal of sensitive media

Note: During this early phase of the system's development, the security needs determination will give better understanding of the Information Systems Security assurance requirements. The security implications of alternatives should also be considered during the Concept & Requirements Definition (CRD) lifecycle phase. In this stage you must locate your Certification Lead (CL) and Information System Security Officer (ISSO) within your program office. They may assist and guide you through your determination level of efforts on the security activities that result in the overall development of the SCAP document. If there is an SCAP for the existing system then do either an annual update or the re-SCAP. Review the document, ATO - Information Systems Security Program Implementation Guide (SCAPs) and consult with your program office for this activity.

Tasks

• Locate your Program Office CL and ISSO
• Review and become familiar with the Resources listed below
• Review the document ATO - Information Systems Security Program Implementation Guide (SCAPs) for overall information
• Determine the security needs of the program
• Trade studies to find most appropriate possible solutions

Resources

• Homeland Security Presidential Decision Directive - 7, Critical Infrastructure Identification, Prioritization, and Protection
• OMB Circular A-130, Management of Federal Information Systems, Appendix III
• 44 USC 35, Subchapter II, Federal Information Security Management Act (FISMA)
• Federal Information Security Management Act (FISMA), PL 107-347, Title III
• FAA Order 1370.82A, Information Systems Security Program
• NIST Special Publication 800-12, An Introduction to Computer Security - The NIST Handbook
• NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems
• NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems
• NIST Special Publication 800-23, Guidelines to Federal Organizations on Security Assurance and Acquisition - Use of Tested/Evaluated Products
• NIST Special Publication 800-27, Engineering Principles for Information Technology Security (A Baseline For Achieving Security)
• NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems
• NIST Special Publication 800-35, Guide to Information Technology Security Services
• NIST Special Publication 800-36, Guide to Selecting Information Technology Security Products
• NIST Special Publication 800-47, Security Guide for Interconnecting Information Technology Systems
• NIST Special Publication 800-51, Use of the Common Vulnerabilities and Exposures Vulnerability Naming Scheme
• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems
• NIST Special Publication 800-55, Security Metrics for Information Technology Systems
• NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories
• NIST Special Publication 800-61, Computer Security Incident Handling Guide
• NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle
• FIPS Publication 140-2, Security Requirements for Cryptographic Modules
• FIPS Publication 199 - Standards for Security Categorization of Federal Information and Information Systems
• FAA Systems Engineering Manual (SEM)
• FAA Acquisition System Toolset (FAST)
• NAS SR-1000, security section
• ATO - Information Systems Security Program Implementation Guide (SCAPs)
• ATO - Information Systems security Architecture (ISSA). Latest version
• FAAISS Handbook

Begin Service Analysis (SA) for AMS decision point: #1

(Start: Service Analysis activities for the Mission Needs Decision (MND))

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

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • Service Analysis (SA)
  • Mission Need Decision (MND)
  • ISS policy guidance listed in the ATOISS Program Library website.
    • FAA Orders 1370.82A, "Information Systems Security Program"*
  • ISS Engineering
    • AMS Lifecycle Management Process with ISSE related activities

Initiate

• Service Level Mission Need (SLMN) Threat Stipulation and basic security policy.
  • Integrating Initial Security Needs and Threat Stipulation into the SLMN (a)

Deliverable(s)

1. Statement of security policy and threat environment stipulation incorporated into the SLMN.

End SA for AMS decision point: #1

Develop CONOPS and Preliminary Security Requirements (b)

AMS Lifecycle Phase: Mission Analysis >>> Concept & Requirement Definition (CRD)

Description

The system's Concept of Operations (CONOPs) can be used for presenting the results of the needs determination and requirements analysis. As the system's CONOPs become more recognized, improved communication among stakeholders can occur because a more standardized approach is in use. Particularly, communication of security specifications to potential offerors can be greatly enhanced.

Further, a system CONOPs acts as a record of the security analysis performed during the mission analysis phase. It provides a place to record the threats that are being considered, the security objectives that are being pursued, and the actual security specifications as they are created. The CONOPs should be viewed as an "evolving" document that records the security analysis performed during the course of the requirements generation process.

The CONOPS should contain the following:

• A clear statement of the goals and objectives
• The strategies, tactics, policies, and constraints that describe how security will effect the program
• The organizations, activities, and interactions that describe who will participate and what these stakeholders do in that process
• A clear statement of the responsibilities and authority of the roles played in the process
• The specific operational processes, in overview fashion, that provide a process model in terms of when and in what order these operation processes take place, including such things as dependencies and concurrencies
• Processes for initiating the program, developing the products and components, maintenance of the products, and components, and possibly for retirement of the program and its products and components

The CONOPS should relate a narrative of the process to be followed. It must define the roles of the various stakeholders involved in the process. The CONOPS is not intended to be an implementation or transition plan since it does not provide managers with the detailed steps involved in planning for the transition: establishing accountability, managing risk, scheduling, and budgeting. However, it does offer a clear methodology to realize the goals and objectives of the approach to software development/acquisition of core assets and systems.

The security requirements for enterprise systems should address the following issues:

• the system should not create vulnerabilities or unintended interdependencies in other enterprise systems
• the system should not decrease the availability of other enterprise systems
• the system should not decrease the overall security posture of the entire enterprise
• systems connected to external domains must analyze and attempt to counter hostile actions originating from these domains
• security specifications should be appropriate for the given state of the system
• security specifications should be stated clearly to convey the desired functions and assurances to the enterprise system product team and the developers
• implement specifications that sufficiently reduce the risks to the enterprise system and to the enterprise mission that the system supports

There are six steps in the development of security requirements. The process is outlined below:

Note: The security implications of alternatives are considered in this stage. It is based on the requirements need of the NAS system assessed while it was derived from the security section of the NAS SR-1000.

Tasks

• Meet with stakeholders to ascertain the technical and programmatic security requirements
• Develop, evaluate and select from the list of alternatives
• Develop a preliminary list of security requirements based on the MNS and the selected alternative during the CRD

Resources

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

Update Vulnerability and Risk Assessment (f)

AMS Lifecycle Phase:Solution Implementation

Description

The updated vulnerability and risk assessment is a continuation of the preliminary vulnerability and risk assessment activities. At this stage, more details are known about the system, therefore a more accurate vulnerability and risk assessment is performed. The idea at this stage is to review the preliminary vulnerability and risk assessment to determine if new threats and vulnerabilities exist and that previously identified vulnerability-threat pairs are still valid.

At this stage, risk mitigation strategies in the ISSP are also put into place. After the risks have been identified, countermeasures or security controls must be applied to mitigate these risks. These countermeasures or security controls are Management, Operational or Technical controls. For example, the countermeasures or security controls may be either adding and or setting the attributes to the firewalls, filtering routers, virus protection, and or other available countermeasures. Other countermeasures or security controls as listed within the FAA are to be considered for the mitigation. For these risks it is essential to have solid policies and procedures to counter these threats. A determination must be made based on the requirements of a given system as to what countermeasures or security controls must be allocated. These countermeasures will be the basis of the Risk Mitigation/Remediation listed in the plan that is to be included in the SCAP.

Tasks

• Refine the security requirements checklist
• Review the POAMS and the information from the Department of Transportation (DOT) Enterprise Security Portal (ESP)
• Gather more detailed information on the system's processing environment
• Review industry sources to identify application and hardware specific vulnerabilities
• Review the previously identified threats to and vulnerabilities in the information system to ensure they are still valid
• Identify any new threats and vulnerabilities that have developed
• Identify the potential impact or magnitude of harm that a loss of confidentiality, integrity, or availability would have on the assets
• Identify and analyze the security controls for the information system

Resources

• NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems
• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems
• NIST National Vulnerability Database
• Department of Transportation (DOT) Enterprise Security Portal (ESP)
• ATO Information Systems Security Program Implementation Guide (SCAPs)
• ATO Information Systems security Architecture (ISSA). Latest version
• FAA's ISS Handbook

Begin Initial Investment Analysis (IIA) for AMS decision point: #3

(Start:OMB Exhibit 300 Attachment 2 for the Initial Investment Decision (IID))

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website
  • Investment Analysis (IA)
  • Investment Decision (ID)
• FAAFASTISS Flow Chart of the IIA section
• Security engineering activities
  • FAA Information Systems Security (ISS) Engineering Process

Update

• CONOPS of system.
• ISS section of the Preliminary Requirements. (pPR document).
  • Apply 800-53.
    • Tailor 800-53 security requirements to your acquisitions.

Generate

• Basis of Estimates (BOE) on security cost estimates for alternatives.
• SCAP with your Service Unit/Service Area Certification Team Lead.
• The preliminary Information System Security Plan, (ISSP).
  • "Develop the Preliminary ISSP (Including Basic Security Policy)" (c)
    • NISTSP 800-18, "Guide for Developing Security plans for Federal Information Systems" (February 2006)
• Preliminary System Characterization/Categorization.
  • Develop Systems Characterization/Categorization (d)
  • FIPS-199
  • 800-53 controls.
• Preliminary vulnerability and risk assessment.
  • Developing Preliminary Vulnerability and Risk Assessment (e)
    • NISTSP 800-30, "Risk Management Guide for Information Technology Systems"

Deliverable(s)

1. BOE on security cost estimates for alternatives.
2. OMB Exhibit 300, Attachment 2: Business Case Analysis Report (BCAR)
3. Updated OMB Exhibit 300, Attachment 1: (pPR)
   • Requirements for the ISS section of the (pPR) to include the 800-53 controls.
4. Preliminary vulnerability and risk assessment.
5. Preliminary SCAPs document
   • Preliminary ISSP with security policy statement.
   • Preliminary System Characterization/Categorization.

End IIA for AMS decision point: #3

Develop Preliminary Vulnerability and Risk Assessment (e)

AMS Lifecycle Phase:Investment Analysis >>> Initial Investment Analysis

Description

Vulnerabilities are weaknesses in the physical layout, organization, procedures, personnel, management, administration, hardware, or software that may be exploited to cause harm to system. The goal of the preliminary vulnerability assessment is to develop a list of system vulnerabilities (flaws or weaknesses) that could be exploited by a potential threat. For new systems, the search for vulnerabilities should focus on security policies, planned procedures, system requirements definitions, and security product analysis. For operational systems, analyze technical and procedural security features and controls used to protect the system. Vulnerability analysis encompasses the following five security control areas:

• Technical - hardware, software, system architecture, and modes of communication
• Operational - procedures that people perform with respect to an information system
• Administrative - weak countermeasures in the administrative procedures that affect information systems
• Physical - weak countermeasures in the physical layout of, and access to, facilities and enclosures where automated information systems are housed
• Personnel - weak countermeasures in policy, process, and procedures used for security screening of staff having access to the system

After analyzing the technical, operational, administrative, physical, and personnel controls on the system, the vulnerabilities are paired with specific threats to create a set of vulnerability-threat pairs. The next step is to analyze vulnerability-threat pairs and to identify and determine which existing system countermeasures reduce or mitigate specific vulnerabilities. This is the beginning of the risk assessment process.

Risk can be thought of as the combination of the severity of vulnerability and the likelihood that the vulnerability will be exploited.

R = L * I

Where R is the Risk, L is the Likelihood of a vulnerability being exploited and I is the Impact (or severity) of exploiting the vulnerability. The result of this combination is a risk rating. Risks can then be mitigated based on the overall risk rating. The table below is used when determining whether a risk is low, medium, or high. All high-level risks should be mitigated before medium or low level risks. Once all high risks have been mitigated, additional risks can be mitigated, based on schedule, funds, and ability of mitigation to mediate the risk(s).

The preliminary risk assessment should result in a brief initial description of the basic security needs of the system. In practice, the need for information security protection is expressed in terms of the need for integrity, availability, and confidentiality and other security needs that may be applicable (accountability, non-repudiation). Integrity can be examined from several perspectives. From a user's or application owner's perspective, integrity is the quality of data that is based on attributes such as accuracy and completeness. From a system's or operation's perspective, integrity is the quality of data that it is only changed in an authorized manner or that the system/software/process does what it is supposed to do and nothing more. Like integrity, availability also has a multipart definition. Availability is the state when data or a system is in the place needed by the user, at the time the user needs it, and in the form needed by the user. Confidentiality is the privacy, secrecy, or nondisclosure of information except to authorized individuals.

A preliminary risk assessment should define the threat environment in which the product or system will operate. This assessment is followed by an initial identification of required security controls that must be met to protect the product/system in the intended operational environment. The risk-based approach to information security is defined in NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems.

The risk assessment should be done before the approval of design specifications. The preliminary risk assessment may not be a large and complex document; however, it should take into account existing controls and their effectiveness. The risk assessment should identify any deficiencies in t eh analysis of integrity, confidentiality, and availability requirements or the security assurance requirements analysis by demonstrating the logical conclusion of the analyses.

The preliminary vulnerability and risk assessments should be combined into one final document that addresses the systems vulnerabilities and risks. At the completion of this step, the Product Team will have a general understanding of the security issues facing the system. As more details are known about the system, an updated vulnerability and risk assessment can be completed to uncover new areas of risk to the system.

Tasks

• Gather information on the system's processing environment
• Review the POAMS and the information from the Department of Transportation (DOT) Enterprise Security Portal (ESP)
• Review industry sources to identify application and hardware specific vulnerabilities
• Identify the threats to and vulnerabilities in the information system
• Identify the potential impact or magnitude of harm that a loss of confidentiality, integrity, or availability would have on assets
• Identify and analyze the security controls for the information system

Resources

• NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems
• NIST National Vulnerability Database
• Department of Transportation (DOT) Enterprise Security Portal (ESP)
• FAA's ISS Handbook

Develop Systems Characterization/Categorization (d)

AMS Lifecycle Phase:Investment Analysis >>> Initial Investment Analysis

Description

After needs have been determined, the list of alternative(s) in CRD was determined and the system should be categorized as to what level of potential impact a security breach would have. Security categorization assists the product teams in making the appropriate selection of security controls for the program.

The system characterization is the central document in the SCAP. Developed by the System Owner, its purpose is to provide a single document that contains relevant system description information, including system architecture, interfaces, data/information types, and the general system operations and maintenance environment in sufficient detail for the reviewer to gain a reasonable understanding of the system and its operating environment. It is important that logical network diagrams be included to provide an opportunity to view the conceptual composition of the system/network. By using logical diagrams in conjunction with the design description, reviewers will be provided with a comprehensive understanding of the system/network design, requirements, goals, and plan for projected growth.

FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, guides the determination of the potential magnitude of harm resulting from a NAS security incident. FIPS 199 categorizes "High," "Moderate," and "Low" impacts of losses of availability, integrity or confidentiality. The assessed categorization provides the impact variable used as a multiplier of likelihood in the ISS Program Handbook risk assessment model:

Note: During this phase of the system's development, the security needs determination and categorization should result in a high-level description of the security controls (800-53) in the proposed system to meet the assurance requirements. NISTSP 800-53 is separated into management, operational and technical control that ensures the confidentiality, integrity and availability (CIA) of the system. Check into the latest version of the NIST 800-53 and ISSA for security controls for methodologies on selection and allocation.

Tasks

• Define the security categorization of the program
• Determine the system and its boundaries
• Develop a high level description of the security controls

Resources

• NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle
• NIST FIPS199, Standards for Security Categorization of Federal Information and Information Systems
• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems
• Federal Information Security Management Act (FISMA), PL 107-347, Title III
• FAA Order 1370.82A, Information Systems Security Program
• OMB Circular A-130, Management of Federal Information Systems, Appendix III
• ATO Information Systems Security Program Implementation Guide (SCAPs)
• ISSA latest version

Develop Preliminary ISSP (Including Basic Security Policy) (c)

AMS Lifecycle Phase:Investment Analysis >>> Initial Investment Analysis

Description

The Information System Security Plan (ISSP) must fully identify and describe the controls currently in place or planned for the system and should include a list of rules or behavior. The existence of, and adherence to, an ISSP is a fundamental requirement in system security certification. The purpose of the ISSP is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements and delineates responsibilities and expected behavior of all individuals who access the system. Once completed, an ISSP will contain technical information about the system, its security requirements, and controls implemented to provide protection against it risks and vulnerabilities.

Further, a system's ISSP acts as a record of the security analysis performed during the mission analysis phase. It provides a place to record the threats that are being considered, the security objectives that are being pursued, and the actual security specifications as they are created. The ISSP should be viewed as an "evolving" document that records the security analysis performed during the course of the requirements generation process. Specific information regarding developing an ISSP can be found in NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems.

The security requirements for enterprise systems should address the following issues:

• the system should not create vulnerabilities or unintended interdependencies in other enterprise systems
• the system should not decrease the availability of other enterprise systems
• the system should not decrease the overall security posture of the entire enterprise
• Systems connected to external domains must analyze and attempt to counter hostile actions originating from these domains
• Security specifications should be appropriate for the given state of the system
• Security specifications should be stated clearly to convey the desired functions and assurances to the enterprise system product team and the developers
• Implement specifications that sufficiently reduce the risks to the enterprise system and to the enterprise mission that the system supports

The Basic Security Policy is the foundation for all security decisions made by the IPTs. The Basic Security Policy provides an overview of the security requirements of the system, and delineates responsibilities and expected behaviors of all individuals who access the system. The Security Policy should reflect inputs from information owners, system operators, and the system security manager.

Management acceptance of the policy should be based on an assessment of management, operational, and technical controls. Since the Security Policy establishes and documents the security framework for the system, it should form the basis for management's authorization.

Note on relationship between ISSP and 800-53 security controls:
The ISSP also outlines the management controls that protect their information system resources. Technical and operational controls, in turn, support the management controls. To be effective, these controls must interrelate.

Management Controls

Are in place or planned measures intended to meet the protection requirement of the information system resources. Management controls focus on the management of the information system and the management of risk for a system. The types of control measures are consistent with the need for protection of the information system resources.

System training and awareness requirements must be identified in the appropriate section as indicated in the template instructions. It is critical to identify the required training / awareness, the frequency it is to be delivered, the personnel who will be required to take it, and the responsible party for training record maintenance.

Operational controls

Are mechanisms that are implemented and executed primarily by people (as opposed to systems). These controls are put in place to improve the security of a particular system (or group of systems). They often require technical or specialized expertise - and often rely upon management activities as well as technical controls.

Technical controls

Focuses on those security controls executed by the computer system. The controls can provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data. The implementation of technical controls, however, always requires significant operational considerations and should be consistent with the management of security with the organization.

Tasks

• Develop ISSP based on security requirements
• Determine security requirements for the system
• Determine the 800-53 control for the system assessed
• Define and describe the scope of the system and its boundaries
• Determine who will be the POC for security of the system
• Identify the Security Team and the LOBs involved and ensure commitment

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-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
• ATO - Information Systems Security Program Implementation Guide (SCAPs)
• FAA's ISS Handbook

Begin Concept and Requirement Definition (CRD) for AMS decision point: #2

(Start:OMB Exhibit 300 Attachment 1 for the Investment Analysis Readiness Decision (IARD))

Review

• The CONOPs of the system.
• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • Concept & Requirements Definition (CRD)
  • Investment Analysis Readiness Decision (IARD)
• FAAFASTISS Flow Chart of the CRD section
• Security engineering activities.
  • AMS Lifecycle Management Process with ISSE related activities
• The NAS-SR1000 security requirements section.
  • To obtain the document please contact Linda Suppan (Acting Manager).

Coordinate

• Service Unit/Service Area Certification Team Lead to determine plans and strategy for SCAP activities including determining the level of effort and security activities.
  • ATO Information System Security Manager (ISSM)
  • ATO Designated Approving Authority (DAA), Information System Security Certifier (ISSC), and Information System Security Manager (ISSM)
  • ATO Service Unit/Service Area Certification Team Lead
  • ATO Service Unit/Service Area ISSO.
    • The individual is responsible for all the security functions for the program and is designated by the Program Manager.

Generate

• “Developing CONOPS and Preliminary Security Requirements (b)”
  • CONOPS of system.
  • ISS section of the Preliminary Requirements. (pPR document).
    • For assistance in developing security requirements contact Kenneth Kepchar, ATO-PISS Chief Scientist System Engineer.
  • The 800-53 controls.

Deliverable(s)

1. OMB Exhibit 300, Attachment 1: Preliminary Program Requirements (pPR)
   • ISS Section of the Preliminary requirements. (pPR)

End CRD for AMS decision point: #2 & AMS Phase Mission Analysis (MA)

AMS Information Systems & Security Checklist

Note:

• This is the complete checklist throughout your ISS Engineering activities during the AMS Lifecycle phases.
• The symbol "*" indicates that the FAA firewall access is required to view this link.

Initiate

FAA Information Systems Security (ISS) Activities Process:

1. If any questions, please contact 9-ATOP-HQ-ISSE-Info@faa.gov, ATO-P Information Systems Security Chief Scientist Engineer.
2. Go to the last page of this checklist to review:
   • Appendix 1: "AMS Logo Map - FAA Lifecycle Management Process".
     • Use the map to follow the numbered AMS decision points in the process with this checklist.
   • Appendix 2: "Security Activities during AMS Phases"
     • It is a quick overview of deliverable security related products for each AMS Phases.
3. Use this checklist to map the security activities along with your appendix 1 & 2.
4. Review the lettered content of the "FAA Information Systems Security (ISS) Engineering Process".

Resources

1. The ATOISS related websites:
   • FAAFASTAMS - Security Section
   • FAANAS Enterprise Architecture (NASEA) - Security View (TBA - Still in the maturation process.)
   • FAA Systems Engineering Manual (SEM)
     • Section 4.8.6, Information Security Engineering
   • ATOISS Program Library website
     • An authoritative source indicating governance of SCAP process*
   • ISS related policies*
2. SCAP Templates and FAQs

Quick Links

• Service Analysis (SA)
• Concept & Requirement Definition (CRD)
• Investment Analysis (IA)
• Final Investment Analysis (FIA)
• Solution Implementation (SI)
• In-Service Management (ISM)

Begin Service Analysis (SA) - AMS decision point: #1

(Start: Service Analysis activities for the Mission Needs Decision (MND))

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

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • Service Analysis (SA)
  • Mission Need Decision (MND)
  • ISS policy guidance listed in the ATOISS Program Library website.
    • FAA Orders 1370.82A, "Information Systems Security Program"*
  • ISS Engineering
    • AMS Lifecycle Management Process with ISSE related activities

Initiate

• Service Level Mission Need (SLMN) Threat Stipulation and basic security policy.
  • Integrating Initial Security Needs and Threat Stipulation into the SLMN (a)

Deliverable(s)

1. Statement of security policy and threat environment stipulation incorporated into the SLMN.

End SA for AMS decision point: #1

Begin Concept and Requirement Definition (CRD) - AMS decision point: #2

(Start:OMB Exhibit 300 Attachment 1 for the Investment Analysis Readiness Decision (IARD))

Review

• The CONOPs of the system.
• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • Concept & Requirements Definition (CRD)
  • Investment Analysis Readiness Decision (IARD)
• FAAFASTISS Flow Chart of the CRD section
• Security engineering activities.
  • AMS Lifecycle Management Process with ISSE related activities
• The NAS-SR1000 security requirements section.
  • To obtain the document please contact Linda Suppan (Acting Manager).

Coordinate

• Service Unit/Service Area Certification Team Lead to determine plans and strategy for SCAP activities including determining the level of effort and security activities.
  • ATO Information System Security Manager (ISSM)
  • ATO Designated Approving Authority (DAA), Information System Security Certifier (ISSC), and Information System Security Manager (ISSM)
  • ATO Service Unit/Service Area Certification Team Lead
  • ATO Service Unit/Service Area ISSO.
    • The individual is responsible for all the security functions for the program and is designated by the Program Manager.

Generate

• “Developing CONOPS and Preliminary Security Requirements (b)”
  • CONOPS of system.
  • ISS section of the Preliminary Requirements. (pPR document).
    • For assistance in developing security requirements contact Kenneth Kepchar, ATO-PISS Chief Scientist System Engineer.
  • The 800-53 controls.

Deliverable(s)

1. OMB Exhibit 300, Attachment 1: Preliminary Program Requirements (pPR)
   • ISS Section of the Preliminary requirements. (pPR)

End CRD for AMS decision point: #2 & AMS Phase Mission Analysis (MA)

Begin Initial Investment Analysis (IIA) - AMS decision point: #3

(Start:OMB Exhibit 300 Attachment 2 for the Initial Investment Decision (IID))

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website
  • Investment Analysis (IA)
  • Investment Decision (ID)
• FAAFASTISS Flow Chart of the IIA section
• Security engineering activities
  • FAA Information Systems Security (ISS) Engineering Process

Update

• CONOPS of system.
• ISS section of the Preliminary Requirements. (pPR document).
  • Apply 800-53.
    • Tailor 800-53 security requirements to your acquisitions.

Generate

• Basis of Estimates (BOE) on security cost estimates for alternatives.
• SCAP with your Service Unit/Service Area Certification Team Lead.
• The preliminary Information System Security Plan, (ISSP).
  • "Develop the Preliminary ISSP (Including Basic Security Policy)" (c)
    • NISTSP 800-18, "Guide for Developing Security plans for Federal Information Systems" (February 2006)
• Preliminary System Characterization/Categorization.
  • Develop Systems Characterization/Categorization (d)
  • FIPS-199
  • 800-53 controls.
• Preliminary vulnerability and risk assessment.
  • Developing Preliminary Vulnerability and Risk Assessment (e)
    • NISTSP 800-30, "Risk Management Guide for Information Technology Systems"

Deliverable(s)

1. BOE on security cost estimates for alternatives.
2. OMB Exhibit 300, Attachment 2: Business Case Analysis Report (BCAR)
3. Updated OMB Exhibit 300, Attachment 1: (pPR)
   • Requirements for the ISS section of the (pPR) to include the 800-53 controls.
4. Preliminary vulnerability and risk assessment.
5. Preliminary SCAPs document
   • Preliminary ISSP with security policy statement.
   • Preliminary System Characterization/Categorization.

End IIA for AMS decision point: #3

BEGIN Final Investment Analysis (FIA) - AMS decision point: #4

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

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • Investment Analysis (IA)
  • Investment Decision (ID)
• FAAFASTISS Flow Chart of the FIA section.

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.
  • Documentation should be produced only if test documents are being developed early based on approved system prototype, prior to Solution Implementation phase.
    • “Develop Security Test Plans and Procedures”(k)
• 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

BEGIN Solution Implementation (SI) - 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

• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
• Solution Implementation (SI)
• In-Service Decision (ISD)
• FAAFASTISS Flow Chart of the SI section
• OMB Exhibit 300, Attachment 1, 2, & 3.

Update

• Security information for Solicitation Information Request (SIR), Contract Statement of Work (SOW) and Contract Data Requirement List (CDRL).
• Vulnerability and risk assessment for the Security Risk Assessment (SRA).
  • This is to be performed independent of the Integrated Product Team (IPT).
  • “Update Vulnerability and Risk Assessment” (f)
• CONOPS of system.
  • “Update the CONOPS and Security Requirements” (g)
  • To include ISS section to the CONOPS depending on level of impact of the NAS system.
• ISS section for the Final Requirement Document (fPR).
  • Security Interfaces document for inclusion in Interface Requirement Document (IRD).
  • “Integrate Security Requirements with System Requirements” (h)
  • “Integrate Security Architecture and Design” (i)
• The ISSP.
  • “Update the ISSP” (j)
• SCAP to reflect actual fielded systems with your Service Unit/Service Area Certification Team Lead and ISSO. Must complete the SCAP documents before operating the system.
  • Locate the “ATOISS Implementation Guide * ” and follow the link “SCAP” for the SCAP guidance document.
  • “Create Final Security C&A Documents” (n)

Generate

• Security testing on system baseline and refine solution as needed for ISD/commissioning.
  • This is to be performed independent of the IPT.
  • “Develop Security Test Plans and Procedures” (k)
• Users guide, training plans, and contingency/disaster recovery plans.
  • “Develop User’s Guides, Training, and Contingency Plans” (l)
  • “Conduct Security Testing” (m)

Obtain

• DAA signature(s) of Certification and Authorization to connect and operate system in the NAS.
  • “Obtain Security Authorization and Accreditation” (o)
    • ATO Designated Approving Authority (DAA), Information System Security Certifier (ISSC), and Information System Security Manager (ISSM).

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

BEGIN In-Service Management (ISM) – Systems Engineering Milestones: Technology Refresh Assessment (TRA)

(Determine: To continue, update (Tech refresh, P3I) or end the Systems Development Lifecycle needs for the (ISM))

Review

• FAAFASTAMS Lifecycle Phases and Decisions guidance website:
  • In-Service Management (ISM)
• FAAFASTISS Flow Chart of the ISM section.
• The ISSP for the system assessed.
• OMB Exhibit 300, Attachment 1, 2, & 3.

Update

• ISS section of the Final Requirement Document (fPR).
• Vulnerability and risk assessment for the Security Risk Assessment (SRA).
• SCAP with your Service Unit/Service Area Certification Team Lead.
  • Verify if recertification is required.

Generate

• Technology refresh and/or upgrade of the system assessed.
  • Prepare for Technology Refresh and Upgrade Planning (p)
  • NISTSP 800-64, “Security Considerations in the Information System Development Life Cycle”
• For disposal of the system.
  1. Follow ISSP
  2. Archive information
  3. Sanitize media
  4. Dispose of hardware and software.

Obtain

• DAA signature(s) of Certification and Authorization package (SCAP).
  • Service Unit/Service Area Certification Team Lead and ISSO.
  • ATO Designated Approving Authority (DAA), Information System Security Certifier (ISSC), and Information System Security Manager (ISSM).

Deliverables

1. Updated OMB Exhibit 300, Attachment 1, 2, & 3
   • ISS section of the Final Requirement Document (fPR).
2. Updated Security vulnerability and threat assessment for the SRA.
3. Updated SCAP documents.
4. DAA signature(s) of the SCAP documents.

End ISM for Systems Engineering Milestones: TRA & AMS Phase: ISM