Develop, document, and disseminate to organization-defined personnel or roles:
one or more,Organization-level,Mission/business process-level,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 organization-defined official 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 organization-defined frequency and following organization-defined events; and
Procedures organization-defined frequency and following organization-defined events.
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.
Acquire, develop, and manage the system using organization-defined system development life cycle 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(#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.
Include the following requirements, descriptions, and criteria, explicitly or by reference, using one or more,standardized contract language, organization-defined contract language 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
Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in #sa-2(#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](#e3cc0520-a366-4fc9-abc2-5272db7e3564) 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.
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 organization-defined actions in response; and
Distribute documentation to organization-defined personnel or roles.
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.
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(#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.
Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: organization-defined controls;
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: organization-defined processes, methods, and techniques.
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.
Require the developer of the system, system component, or system service to:
Perform configuration management during system, component, or service one or more,design,development,implementation,operation,disposal;
Document, manage, and control the integrity of changes to organization-defined configuration items under configuration management;
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 organization-defined personnel.
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.
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 one or more,unit,integration,system,regression testing/evaluation organization-defined frequency at organization-defined depth and coverage;
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.
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 organization-defined frequency 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.
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 one or more,in-house support, organization-defined support from external providers .
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.