SA - System and Services Acquisition
- Controls Count: 21
- Controls IDs: SA-1, SA-2, SA-3, SA-4, SA-4 (1), SA-4 (2), SA-4 (5), SA-4 (9), SA-4 (10), SA-5, SA-8, SA-9, SA-9 (2), SA-10, SA-11, SA-15, SA-15 (3), SA-16, SA-17, SA-21, SA-22
Controls
SA-1: Policy and Procedures
Develop, document, and disseminate to organization-defined personnel or roles:
organization-level, mission/business process-level, and/or system-level system and services acquisition policy that:
Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;
Designate an an official to manage the system and services acquisition policy and procedures is defined; to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and
Review and update the current system and services acquisition:
Policy the frequency at which the current system and services acquisition policy is reviewed and updated is defined; and following events that would require the current system and services acquisition policy to be reviewed and updated are defined; ; and
Procedures the frequency at which the current system and services acquisition procedures are reviewed and updated is defined; and following events that would require the system and services acquisition procedures to be reviewed and updated are defined;.
System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.
a system and services acquisition policy is developed and documented;
the system and services acquisition policy is disseminated to personnel or roles to whom the system and services acquisition policy is to be disseminated is/are defined;;
system and services acquisition procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls are developed and documented;
the system and services acquisition procedures are disseminated to personnel or roles to whom the system and services acquisition procedures are to be disseminated is/are defined;;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses purpose;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses scope;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses roles;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses responsibilities;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses management commitment;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses coordination among organizational entities;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy addresses compliance;
the organization-level, mission/business process-level, and/or system-level system and services acquisition policy is consistent with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines;
the an official to manage the system and services acquisition policy and procedures is defined; is designated to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures;
the system and services acquisition policy is reviewed and updated the frequency at which the current system and services acquisition policy is reviewed and updated is defined;;
the current system and services acquisition policy is reviewed and updated following events that would require the current system and services acquisition policy to be reviewed and updated are defined;;
the current system and services acquisition procedures are reviewed and updated the frequency at which the current system and services acquisition procedures are reviewed and updated is defined;;
the current system and services acquisition procedures are reviewed and updated following events that would require the system and services acquisition procedures to be reviewed and updated are defined;.
System and services acquisition policy
system and services acquisition procedures
supply chain risk management policy
supply chain risk management procedures
supply chain risk management plan
system security plan
privacy plan
other relevant documents or records
Organizational personnel with system and services acquisition responsibilities
organizational personnel with information security and privacy responsibilities
organizational personnel with supply chain risk management responsibilities
SA-2: Allocation of Resources
Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.
Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle.
the high-level information security requirements for the system or system service are determined in mission and business process planning;
the high-level privacy requirements for the system or system service are determined in mission and business process planning;
the resources required to protect the system or system service are determined and documented as part of the organizational capital planning and investment control process;
the resources required to protect the system or system service are allocated as part of the organizational capital planning and investment control process;
a discrete line item for information security is established in organizational programming and budgeting documentation;
a discrete line item for privacy is established in organizational programming and budgeting documentation.
System and services acquisition policy
system and services acquisition procedures
system and services acquisition strategy and plans
procedures addressing the allocation of resources to information security and privacy requirements
procedures addressing capital planning and investment control
organizational programming and budgeting documentation
system security plan
privacy plan
supply chain risk management policy
other relevant documents or records
Organizational personnel with capital planning, investment control, organizational programming, and budgeting responsibilities
organizational personnel with information security and privacy responsibilities
organizational personnel with supply chain risk management responsibilities
Organizational processes for determining information security and privacy requirements
organizational processes for capital planning, programming, and budgeting
mechanisms supporting and/or implementing organizational capital planning, programming, and budgeting
SA-3: System Development Life Cycle
Acquire, develop, and manage the system using system development life cycle is defined; that incorporates information security and privacy considerations;
Define and document information security and privacy roles and responsibilities throughout the system development life cycle;
Identify individuals having information security and privacy roles and responsibilities; and
Integrate the organizational information security and privacy risk management process into system development life cycle activities.
A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in SA-8 help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.
The effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle.
the system is acquired, developed, and managed using system development life cycle is defined; that incorporates information security considerations;
the system is acquired, developed, and managed using system development life cycle is defined; that incorporates privacy considerations;
information security roles and responsibilities are defined and documented throughout the system development life cycle;
privacy roles and responsibilities are defined and documented throughout the system development life cycle;
individuals with information security roles and responsibilities are identified;
individuals with privacy roles and responsibilities are identified;
organizational information security risk management processes are integrated into system development life cycle activities;
organizational privacy risk management processes are integrated into system development life cycle activities.
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of information security and privacy and supply chain risk management into the system development life cycle process
system development life cycle documentation
organizational risk management strategy
information security and privacy risk management strategy documentation
system security plan
privacy plan
privacy program plan
enterprise architecture documentation
role-based security and privacy training program documentation
data mapping documentation
other relevant documents or records
Organizational personnel with information security and privacy responsibilities
organizational personnel with system life cycle development responsibilities
organizational personnel with supply chain risk management responsibilities
Organizational processes for defining and documenting the system development life cycle
organizational processes for identifying system development life cycle roles and responsibilities
organizational processes for integrating information security and privacy and supply chain risk management into the system development life cycle
mechanisms supporting and/or implementing the system development life cycle
SA-4: Acquisition Process
Include the following requirements, descriptions, and criteria, explicitly or by reference, using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service:
Security and privacy functional requirements;
Strength of mechanism requirements;
Security and privacy assurance requirements;
Controls needed to satisfy the security and privacy requirements.
Security and privacy documentation requirements;
Requirements for protecting security and privacy documentation;
Description of the system development environment and environment in which the system is intended to operate;
Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
Acceptance criteria.
Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in SA-2 . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. SP 800-160-1 describes the process of requirements engineering as part of the system development life cycle.
Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.
Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement.
security functional requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
privacy functional requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
strength of mechanism requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
security assurance requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
privacy assurance requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
controls needed to satisfy the security requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
controls needed to satisfy the privacy requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
security documentation requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
privacy documentation requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
requirements for protecting security documentation, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
requirements for protecting privacy documentation, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
the description of the system development environment and environment in which the system is intended to operate, requirements, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
the allocation of responsibility or identification of parties responsible for information security requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service;
the allocation of responsibility or identification of parties responsible for privacy requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected);;
the allocation of responsibility or identification of parties responsible for supply chain risk management requirements, descriptions, and criteria are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected);;
acceptance criteria requirements and descriptions are included explicitly or by reference using standardized contract languageand/or contract language is defined (if selected); in the acquisition contract for the system, system component, or system service.
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of information security and privacy and supply chain risk management into the acquisition process
configuration management plan
acquisition contracts for the system, system component, or system service
system design documentation
system security plan
supply chain risk management plan
privacy plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
system/network administrators
organizational personnel with supply chain risk management responsibilities
Organizational processes for determining system security and privacy functional, strength, and assurance requirements
organizational processes for developing acquisition contracts
mechanisms supporting and/or implementing acquisitions and the inclusion of security and privacy requirements in contracts
SA-4 (1): Functional Properties of Controls
Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.
Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls.
the developer of the system, system component, or system service is required to provide a description of the functional properties of the controls to be implemented.
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of security and privacy requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system component, or system services
system security plan
privacy plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
system developers
Organizational processes for determining system security functional requirements
organizational processes for developing acquisition contracts
mechanisms supporting and/or implementing acquisitions and the inclusion of security and privacy requirements in contracts
SA-4 (2): Design and Implementation Information for Controls
Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: security-relevant external system interfaces, high-level design, low-level design, source code or hardware schematics, and/or design and implementation information is defined (if selected); at level of detail is defined;.
Organizations may require different levels of detail in the documentation for the design and implementation of controls in organizational systems, system components, or system services based on mission and business requirements, requirements for resiliency and trustworthiness, and requirements for analysis and testing. Systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules and the interfaces between modules providing security-relevant functionality. Design and implementation documentation can include manufacturer, version, serial number, verification hash signature, software libraries used, date of purchase or download, and the vendor or download source. Source code and hardware schematics are referred to as the implementation representation of the system.
the developer of the system, system component, or system service is required to provide design and implementation information for the controls that includes using security-relevant external system interfaces, high-level design, low-level design, source code or hardware schematics, and/or design and implementation information is defined (if selected); at level of detail is defined;.
System and services acquisition policy
system and services acquisition procedures
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system components, or system services
design and implementation information for controls employed in the system, system component, or system service
system security plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility to determine system security requirements
system developers or service provider
organizational personnel with information security responsibilities
Organizational processes for determining the level of detail for system design and controls
organizational processes for developing acquisition contracts
mechanisms supporting and/or implementing the development of system design details
SA-4 (5): System, Component, and Service Configurations
Require the developer of the system, system component, or system service to:
Deliver the system, component, or service with security configurations for the system, component, or service are defined; implemented; and
Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.
Examples of security configurations include the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), and any limitations on functions, ports, protocols, and services. Security characteristics can include requiring that default passwords have been changed.
the developer of the system, system component, or system service is required to deliver the system, component, or service with security configurations for the system, component, or service are defined; implemented;
the configurations are used as the default for any subsequent system, component, or service reinstallation or upgrade.
System and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documents
acquisition documentation
acquisition contracts for the system, system component, or system service
security configurations to be implemented by the developer of the system, system component, or system service
service level agreements
system security plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility to determine system security requirements
system developers or service provider
organizational personnel with information security responsibilities
Mechanisms used to verify that the configuration of the system, component, or service is delivered as specified
SA-4 (9): Functions, Ports, Protocols, and Services in Use
Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.
The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design stages) allows organizations to influence the design of the system, system component, or system service. This early involvement in the system development life cycle helps organizations avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services or requiring system service providers to do so. Early identification of functions, ports, protocols, and services avoids costly retrofitting of controls after the system, component, or system service has been implemented. SA-9 describes the requirements for external system services. Organizations identify which functions, ports, protocols, and services are provided from external sources.
the developer of the system, system component, or system service is required to identify the functions intended for organizational use;
the developer of the system, system component, or system service is required to identify the ports intended for organizational use;
the developer of the system, system component, or system service is required to identify the protocols intended for organizational use;
the developer of the system, system component, or system service is required to identify the services intended for organizational use.
System and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
system design documentation
system documentation, including functions, ports, protocols, and services intended for organizational use
acquisition contracts for systems or services
acquisition documentation
solicitation documentation
service level agreements
organizational security requirements, descriptions, and criteria for developers of systems, system components, and system services
system security plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility for determining system security requirements
system/network administrators
organizational personnel operating, using, and/or maintaining the system
system developers
organizational personnel with information security responsibilities
SA-4 (10): Use of Approved PIV Products
Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.
Products on the FIPS 201-approved products list meet NIST requirements for Personal Identity Verification (PIV) of Federal Employees and Contractors. PIV cards are used for multi-factor authentication in systems and organizations.
only information technology products on the FIPS 201-approved products list for the Personal Identity Verification (PIV) capability implemented within organizational systems are employed.
Supply chain risk management plan
system and services acquisition policy
procedures addressing the integration of security requirements, descriptions, and criteria into the acquisition process
solicitation documentation
acquisition documentation
acquisition contracts for the system, system component, or system service
service level agreements
FIPS 201 approved products list
system security plan
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with the responsibility for determining system security requirements
organizational personnel with the responsibility for ensuring that only FIPS 201- approved products are implemented
organizational personnel with information security responsibilities
Organizational processes for selecting and employing FIPS 201-approved products
SA-5: System Documentation
Obtain or develop administrator documentation for the system, system component, or system service that describes:
Secure configuration, installation, and operation of the system, component, or service;
Effective use and maintenance of security and privacy functions and mechanisms; and
Known vulnerabilities regarding configuration and use of administrative or privileged functions;
Obtain or develop user documentation for the system, system component, or system service that describes:
User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;
Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and
User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;
Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take actions to take when system, system component, or system service documentation is either unavailable or nonexistent are defined; in response; and
Distribute documentation to personnel or roles to distribute system documentation to is/are defined;.
System documentation helps personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to support the management of supply chain risk, incident response, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation.
administrator documentation for the system, system component, or system service that describes the secure configuration of the system, component, or service is obtained or developed;
administrator documentation for the system, system component, or system service that describes the secure installation of the system, component, or service is obtained or developed;
administrator documentation for the system, system component, or system service that describes the secure operation of the system, component, or service is obtained or developed;
administrator documentation for the system, system component, or system service that describes the effective use of security functions and mechanisms is obtained or developed;
administrator documentation for the system, system component, or system service that describes the effective maintenance of security functions and mechanisms is obtained or developed;
administrator documentation for the system, system component, or system service that describes the effective use of privacy functions and mechanisms is obtained or developed;
administrator documentation for the system, system component, or system service that describes the effective maintenance of privacy functions and mechanisms is obtained or developed;
administrator documentation for the system, system component, or system service that describes known vulnerabilities regarding the configuration of administrative or privileged functions is obtained or developed;
administrator documentation for the system, system component, or system service that describes known vulnerabilities regarding the use of administrative or privileged functions is obtained or developed;
user documentation for the system, system component, or system service that describes user-accessible security functions and mechanisms is obtained or developed;
user documentation for the system, system component, or system service that describes how to effectively use those (user-accessible security) functions and mechanisms is obtained or developed;
user documentation for the system, system component, or system service that describes user-accessible privacy functions and mechanisms is obtained or developed;
user documentation for the system, system component, or system service that describes how to effectively use those (user-accessible privacy) functions and mechanisms is obtained or developed;
user documentation for the system, system component, or system service that describes methods for user interaction, which enable individuals to use the system, component, or service in a more secure manner is obtained or developed;
user documentation for the system, system component, or system service that describes methods for user interaction, which enable individuals to use the system, component, or service to protect individual privacy is obtained or developed;
user documentation for the system, system component, or system service that describes user responsibilities for maintaining the security of the system, component, or service is obtained or developed;
user documentation for the system, system component, or system service that describes user responsibilities for maintaining the privacy of individuals is obtained or developed;
attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent is documented;
after attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent, actions to take when system, system component, or system service documentation is either unavailable or nonexistent are defined; are taken in response;
documentation is distributed to personnel or roles to distribute system documentation to is/are defined;.
System and services acquisition policy
system and services acquisition procedures
procedures addressing system documentation
system documentation, including administrator and user guides
system design documentation
records documenting attempts to obtain unavailable or nonexistent system documentation
list of actions to be taken in response to documented attempts to obtain system, system component, or system service documentation
risk management strategy documentation
system security plan
privacy plan
privacy impact assessment
privacy risk assessment documentation
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
system administrators
organizational personnel responsible for operating, using, and/or maintaining the system
system developers
Organizational processes for obtaining, protecting, and distributing system administrator and user documentation
SA-8: Security and Privacy Engineering Principles
Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: organization-defined systems security and privacy engineering principles.
Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see SA-3 ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems.
The application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk.
Organizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design.
systems security engineering principles are defined; are applied in the specification of the system and system components;
systems security engineering principles are defined; are applied in the design of the system and system components;
systems security engineering principles are defined; are applied in the development of the system and system components;
systems security engineering principles are defined; are applied in the implementation of the system and system components;
systems security engineering principles are defined; are applied in the modification of the system and system components;
privacy engineering principles are defined; are applied in the specification of the system and system components;
privacy engineering principles are defined; are applied in the design of the system and system components;
privacy engineering principles are defined; are applied in the development of the system and system components;
privacy engineering principles are defined; are applied in the implementation of the system and system components;
privacy engineering principles are defined; are applied in the modification of the system and system components.
System and services acquisition policy
system and services acquisition procedures
assessment and authorization procedures
procedures addressing security and privacy engineering principles used in the specification, design, development, implementation, and modification of the system
system design documentation
security and privacy requirements and specifications for the system
system security plan
privacy plan
privacy impact assessment
privacy risk assessment documentation
other relevant documents or records
Organizational personnel with acquisition/contracting responsibilities
organizational personnel with information security and privacy responsibilities
organizational personnel with system specification, design, development, implementation, and modification responsibilities
system developers
Organizational processes for applying security and privacy engineering principles in system specification, design, development, implementation, and modification
mechanisms supporting the application of security and privacy engineering principles in system specification, design, development, implementation, and modification
SA-9: External System Services
Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: controls to be employed by external system service providers are defined;;
Define and document organizational oversight and user roles and responsibilities with regard to external system services; and
Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: processes, methods, and techniques employed to monitor control compliance by external service providers are defined;.
External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance.
providers of external system services comply with organizational security requirements;
providers of external system services comply with organizational privacy requirements;
providers of external system services employ controls to be employed by external system service providers are defined;;
organizational oversight with regard to external system services are defined and documented;
user roles and responsibilities with regard to external system services are defined and documented;
processes, methods, and techniques employed to monitor control compliance by external service providers are defined; are employed to monitor control compliance by external service providers on an ongoing basis.
System and services acquisition policy
system and services acquisition procedures
procedures addressing methods and techniques for monitoring control compliance by external service providers of system services
acquisition documentation
contracts
service level agreements
interagency agreements
licensing agreements
list of organizational security and privacy requirements for external provider services
control assessment results or reports from external providers of system services
system security plan
privacy plan
supply chain risk management plan
other relevant documents or records
Organizational personnel with acquisition responsibilities
external providers of system services
organizational personnel with information security and privacy responsibilities
organizational personnel with supply chain risk management responsibilities
Organizational processes for monitoring security and privacy control compliance by external service providers on an ongoing basis
mechanisms for monitoring security and privacy control compliance by external service providers on an ongoing basis
SA-9 (2): Identification of Functions, Ports, Protocols, and Services
Require providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: external system services that require the identification of functions, ports, protocols, and other services are defined;.
Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be useful when the need arises to understand the trade-offs involved in restricting certain functions and services or blocking certain ports and protocols.
providers of external system services that require the identification of functions, ports, protocols, and other services are defined; are required to identify the functions, ports, protocols, and other services required for the use of such services.
System and services acquisition policy
supply chain risk management policy and procedures
procedures addressing external system services
acquisition contracts for the system, system component, or system service
acquisition documentation
solicitation documentation
service level agreements
organizational security requirements and security specifications for external service providers
list of required functions, ports, protocols, and other services
system security plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
system/network administrators
external providers of system services
SA-10: Developer Configuration Management
Require the developer of the system, system component, or system service to:
Perform configuration management during system, component, or service design, development, implementation, operation, and/or disposal;
Document, manage, and control the integrity of changes to configuration items under configuration management are defined;;
Implement only organization-approved changes to the system, component, or service;
Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and
Track security flaws and flaw resolution within the system, component, or service and report findings to personnel to whom security flaws and flaw resolutions within the system, component, or service are reported is/are defined;.
Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.
The configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle.
the developer of the system, system component, or system service is required to perform configuration management during system, component, or service design, development, implementation, operation, and/or disposal;
the developer of the system, system component, or system service is required to document the integrity of changes to configuration items under configuration management are defined;;
the developer of the system, system component, or system service is required to manage the integrity of changes to configuration items under configuration management are defined;;
the developer of the system, system component, or system service is required to control the integrity of changes to configuration items under configuration management are defined;;
the developer of the system, system component, or system service is required to implement only organization-approved changes to the system, component, or service;
the developer of the system, system component, or system service is required to document approved changes to the system, component, or service;
the developer of the system, system component, or system service is required to document the potential security impacts of approved changes;
the developer of the system, system component, or system service is required to document the potential privacy impacts of approved changes;
the developer of the system, system component, or system service is required to track security flaws within the system, component, or service;
the developer of the system, system component, or system service is required to track security flaw resolutions within the system, component, or service;
the developer of the system, system component, or system service is required to report findings to personnel to whom security flaws and flaw resolutions within the system, component, or service are reported is/are defined;.
System and services acquisition policy
procedures addressing system developer configuration management
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
system developer configuration management plan
security flaw and flaw resolution tracking records
system change authorization records
change control records
configuration management records
system security plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
organizational personnel with configuration management responsibilities
system developers
Organizational processes for monitoring developer configuration management
mechanisms supporting and/or implementing the monitoring of developer configuration management
SA-11: Developer Testing and Evaluation
Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:
Develop and implement a plan for ongoing security and privacy control assessments;
Perform unit, integration, system, and/or regression testing/evaluation frequency at which to conduct unit, integration, system, and/or regression testing/evaluation is defined; at depth and coverage of unit, integration, system, and/or regression testing/evaluation is defined;;
Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
Implement a verifiable flaw remediation process; and
Correct flaws identified during testing and evaluation.
Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes—including upgrading or replacing applications, operating systems, and firmware—may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches.
Developers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation.
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to develop a plan for ongoing security assessments;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing security assessments;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to develop a plan for privacy assessments;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing privacy assessments;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to perform unit, integration, system, and/or regression testing/evaluation frequency at which to conduct unit, integration, system, and/or regression testing/evaluation is defined; at depth and coverage of unit, integration, system, and/or regression testing/evaluation is defined;;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to produce evidence of the execution of the assessment plan;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to produce the results of the testing and evaluation;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a verifiable flaw remediation process;
the developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to correct flaws identified during testing and evaluation.
System and services acquisition policy
system and services acquisition procedures
procedures addressing system developer security and privacy testing
procedures addressing flaw remediation
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
security and privacy architecture
system design documentation
system developer security and privacy assessment plans
results of developer security and privacy assessments for the system, system component, or system service
security and privacy flaw and remediation tracking records
system security plan
privacy plan
privacy impact assessment
privacy risk assessment documentation
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security and privacy responsibilities
organizational personnel with developer security and privacy testing responsibilities
system developers
Organizational processes for monitoring developer security testing and evaluation
mechanisms supporting and/or implementing the monitoring of developer security and privacy testing and evaluation
SA-15: Development Process, Standards, and Tools
Require the developer of the system, system component, or system service to follow a documented development process that:
Explicitly addresses security and privacy requirements;
Identifies the standards and tools used in the development process;
Documents the specific tool options and tool configurations used in the development process; and
Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and
Review the development process, standards, tools, tool options, and tool configurations frequency at which to review the development process, standards, tools, tool options, and tool configurations is defined; to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: organization-defined security and privacy requirements.
Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.
the developer of the system, system component, or system service is required to follow a documented development process that explicitly addresses security requirements;
the developer of the system, system component, or system service is required to follow a documented development process that explicitly addresses privacy requirements;
the developer of the system, system component, or system service is required to follow a documented development process that identifies the standards used in the development process;
the developer of the system, system component, or system service is required to follow a documented development process that identifies the tools used in the development process;
the developer of the system, system component, or system service is required to follow a documented development process that documents the specific tool used in the development process;
the developer of the system, system component, or system service is required to follow a documented development process that documents the specific tool configurations used in the development process;
the developer of the system, system component, or system service is required to follow a documented development process that documents, manages, and ensures the integrity of changes to the process and/or tools used in development;
the developer of the system, system component, or system service is required to follow a documented development process in which the development process, standards, tools, tool options, and tool configurations are reviewed frequency at which to review the development process, standards, tools, tool options, and tool configurations is defined; to determine that the process, standards, tools, tool options, and tool configurations selected and employed satisfy security requirements to be satisfied by the process, standards, tools, tool options, and tool configurations are defined;;
the developer of the system, system component, or system service is required to follow a documented development process in which the development process, standards, tools, tool options, and tool configurations are reviewed frequency at which to review the development process, standards, tools, tool options, and tool configurations is defined; to determine that the process, standards, tools, tool options, and tool configurations selected and employed satisfy privacy requirements to be satisfied by the process, standards, tools, tool options, and tool configurations are defined;.
System and services acquisition policy
system and services acquisition procedures
procedures addressing development process, standards, and tools
procedures addressing the integration of security and privacy requirements during the development process
solicitation documentation
acquisition documentation
critical component inventory documentation
service level agreements
acquisition contracts for the system, system component, or system service
system developer documentation listing tool options/configuration guides
configuration management policy
configuration management records
documentation of development process reviews using maturity models
change control records
configuration control records
documented reviews of the development process, standards, tools, and tool options/configurations
system security plan
privacy plan
privacy impact assessment
privacy risk assessment documentation
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security and privacy responsibilities
system developer
SA-15 (3): Criticality Analysis
Require the developer of the system, system component, or system service to perform a criticality analysis:
At the following decision points in the system development life cycle: decision points in the system development life cycle are defined; ; and
At the following level of rigor: organization-defined breadth and depth of criticality analysis.
Criticality analysis performed by the developer provides input to the criticality analysis performed by organizations. Developer input is essential to organizational criticality analysis because organizations may not have access to detailed design documentation for system components that are developed as commercial off-the-shelf products. Such design documentation includes functional specifications, high-level designs, low-level designs, source code, and hardware schematics. Criticality analysis is important for organizational systems that are designated as high value assets. High value assets can be moderate- or high-impact systems due to heightened adversarial interest or potential adverse effects on the federal enterprise. Developer input is especially important when organizations conduct supply chain criticality analyses.
the developer of the system, system component, or system service is required to perform a criticality analysis at decision points in the system development life cycle are defined; in the system development life cycle;
the developer of the system, system component, or system service is required to perform a criticality analysis at the following rigor level: the breadth of criticality analysis is defined;;
the developer of the system, system component, or system service is required to perform a criticality analysis at the following rigor level: the depth of criticality analysis is defined; .
Supply chain risk management plan
system and services acquisition policy
procedures addressing development process, standards, and tools
procedures addressing criticality analysis requirements for the system, system component, or system service
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
criticality analysis documentation
business impact analysis documentation
software development life cycle documentation
system security plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
organizational personnel responsible for performing criticality analysis
system developer
organizational personnel with supply chain risk management responsibilities
Organizational processes for performing criticality analysis
mechanisms supporting and/or implementing criticality analysis
SA-16: Developer-provided Training
Require the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms: training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms provided by the developer of the system, system component, or system service is defined;.
Developer-provided training applies to external and internal (in-house) developers. Training personnel is essential to ensuring the effectiveness of the controls implemented within organizational systems. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Organizations can also request training materials from developers to conduct in-house training or offer self-training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security and privacy functions, controls, and mechanisms.
the developer of the system, system component, or system service is required to provide training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms provided by the developer of the system, system component, or system service is defined; on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms.
System and services acquisition policy
system and services acquisition procedures
procedures addressing developer-provided training
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
organizational security and privacy training policy
developer-provided training materials
training records
system security plan
privacy plan
privacy impact assessment
privacy risk assessment documentation
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security and privacy responsibilities
system developer
external or internal (in-house) developers with training responsibilities for the system, system component, or information system service
SA-17: Developer Security and Privacy Architecture and Design
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:
Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;
Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and
Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.
Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, PL-8 is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and PL-8 is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. ISO 15408-2, ISO 15408-3 , and SP 800-160-1 provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.
the developer of the system, system component, or system service is required to produce a design specification and security architecture that are consistent with the organization’s security architecture, which is an integral part the organization’s enterprise architecture;
the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that are consistent with the organization’s privacy architecture, which is an integral part the organization’s enterprise architecture;
the developer of the system, system component, or system service is required to produce a design specification and security architecture that accurately and completely describe the required security functionality and the allocation of controls among physical and logical components;
the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that accurately and completely describe the required privacy functionality and the allocation of controls among physical and logical components;
the developer of the system, system component, or system service is required to produce a design specification and security architecture that express how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection;
the developer of the system, system component, or system service is required to produce a design specification and privacy architecture that express how individual privacy functions, mechanisms, and services work together to provide required privacy capabilities and a unified approach to protection.
System and services acquisition policy
system and services acquisition procedures
enterprise architecture policy
enterprise architecture documentation
procedures addressing developer security and privacy architecture and design specifications for the system
solicitation documentation
acquisition documentation
service level agreements
acquisition contracts for the system, system component, or system service
system design documentation
information system configuration settings and associated documentation
system security plan
privacy plan
other relevant documents or records
Organizational personnel with acquisition responsibilities
organizational personnel with information security and privacy responsibilities
system developer
SA-21: Developer Screening
Require that the developer of the system, systems component, or system service that the developer has access to is/are defined;:
Has appropriate access authorizations as determined by assigned official government duties assigned to the developer are defined; ; and
Satisfies the following additional personnel screening criteria: additional personnel screening criteria for the developer are defined;.
Developer screening is directed at external developers. Internal developer screening is addressed by PS-3 . Because the system, system component, or system service may be used in critical activities essential to the national or economic security interests of the United States, organizations have a strong interest in ensuring that developers are trustworthy. The degree of trust required of developers may need to be consistent with that of the individuals who access the systems, system components, or system services once deployed. Authorization and personnel screening criteria include clearances, background checks, citizenship, and nationality. Developer trustworthiness may also include a review and analysis of company ownership and relationships that the company has with entities that may potentially affect the quality and reliability of the systems, components, or services being developed. Satisfying the required access authorizations and personnel screening criteria includes providing a list of all individuals who are authorized to perform development activities on the selected system, system component, or system service so that organizations can validate that the developer has satisfied the authorization and screening requirements.
the developer of the system, systems component, or system service that the developer has access to is/are defined; is required to have appropriate access authorizations as determined by assigned official government duties assigned to the developer are defined;;
the developer of the system, systems component, or system service that the developer has access to is/are defined; is required to satisfy additional personnel screening criteria for the developer are defined;.
System and services acquisition policy
personnel security policy and procedures
procedures addressing personnel screening
system design documentation
acquisition documentation
service level agreements
acquisition contracts for developer services
system configuration settings and associated documentation
list of appropriate access authorizations required by the developers of the system
personnel screening criteria and associated documentation
system security plan
supply chain risk management plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
organizational personnel responsible for developer screening
Organizational processes for developer screening
mechanisms supporting developer screening
SA-22: Unsupported System Components
Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
Provide the following options for alternative sources for continued support for unsupported components in-house supportand/or support from external providers is defined (if selected);.
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.
Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation.
system components are replaced when support for the components is no longer available from the developer, vendor, or manufacturer;
in-house supportand/or support from external providers is defined (if selected); provide options for alternative sources for continued support for unsupported components.
System and services acquisition policy
procedures addressing the replacement or continued use of unsupported system components
documented evidence of replacing unsupported system components
documented approvals (including justification) for the continued use of unsupported system components
system security plan
supply chain risk management plan
other relevant documents or records
Organizational personnel with system and service acquisition responsibilities
organizational personnel with information security responsibilities
organizational personnel with the responsibility for the system development life cycle
organizational personnel responsible for component replacement
Organizational processes for replacing unsupported system components
mechanisms supporting and/or implementing the replacement of unsupported system components