.png)
Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, directs the National Institute of Standards and Technology (NIST) to publish guidance on practices for software supply chain security. EO 14028 Section 4e contains ten (10) subsections, each of which specifies actions or outcomes for software producers, such as Commercial-Off-The-Shelf (COTS) product vendors, Government-Off-The-Shelf (GOTS) software developers, contractors, and other custom software developers.
EO 14028 emphasizes that “the security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions,” and “there is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely and as intended.” Accordingly, Secure Software Development Practices (SSDP) should be integrated throughout software life cycles for three (3) reasons:
To reduce the number of vulnerabilities in released software;
To reduce the potential impact of the exploitation of undetected or unaddressed vulnerabilities; and
To address the root causes of vulnerabilities to prevent recurrences.
NIST SP 800-218, Secure Software Development Framework (SSDF),defines outcome-based SSDP for software producers to follow. The following chart contains a mapping for each Section 4e item to the SSDF practices.
NIST SP 800-218 addresses EO 14028 Section 4e from a software producer viewpoint. The software producers are the ones who implement SSDF practices. EO 14028 Section 4k explains that federal agencies will need to comply with NIST guidelines. In this context, federal agencies are software purchasers, not software producers, so additional guidance from the US Government is needed to address EO 14028 Section 4e from a software purchaser viewpoint. However, when a federal agency (purchaser) acquires software or a product containing software, the agency is required to receive attestation from the software producer that the software’s development complies with US Government-specified secure software development practices.
It is expected that Federal agencies will request artifacts from the software producer that support its attestation of conformity with the SSDP described in EO 14028 Section 4e subsections (i), (iii) and (iv), which are listed here:
(i) secure software development environments, including such actions as:
(A) using administratively separate build environments;
(B) auditing trust relationships;
(C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build and edit software;
(E) employing encryption for data; and
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents;
(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release.
EO 14028 Section 4e uses several terms, including “conformity,” “attestation,” and “artifacts” so it is important to understand the meaning of those terms according to definitions from existing standards and guidance:
Conformity assessment is a “demonstration that specified requirements are fulfilled.” In the context of EO 14028 Section 4e, the requirements are SSDP, so a conformity assessment is a demonstration that the software producer has followed SSDP for its software.
Attestation is the “issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.”
If the software producer self-attests that it conforms to SSDP through a Supplier’s Declaration of Conformity (SDoC):
If the software purchaser attests to the software producer’s conformity with secure software development practices, this is known as second-party attestation.
If an independent third-party attests to the software producer’s conformity with secure software development practices, this is known as third-party attestation or certification.
Artifacts are “a piece of evidence.” [adapted from NISTIR 7692] Evidence is “grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood.” [NIST SP 800-160 Vol. 1] Artifacts provide records of secure software development practices:
Low-level artifacts are generated manually, or by automated means, during software development and are maintained by the software producer. Low-level artifacts include, but are not limited to:
Threat models;
Log entries;
Source code files;
Source code vulnerability scan reports;
Testing results;
Telemetry; and
Risk-based mitigation decisions for a particular piece of software.
High-level artifacts are generated by summarizing SSDP derived from the low-level artifacts. An example of a high-level artifact is a publicly-accessible document describing the methodology, procedures and processes a software producer uses its SSDP.
The following subsections of EO 14028 Section 4e use these terms:
(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;
(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
(ix) attesting to conformity with secure software development practices.
In summary, when a Federal agency (purchaser) acquires software or a product containing software, the agency will likely require attestation from the software producer that the software’s development complies with government-specified SSDP. The Federal agency might also request artifacts from the software producer that support its attestation of conformity with the SSDP described in EO 14028 Section 4e subsections (i), (iii) and (iv).
NIST defined the following minimum recommendations for Federal agencies as they acquire software or a product containing software. These recommendations are intended to assist Federal agencies and software producers in communicating clearly with each other regarding secure software development artifacts, attestation and conformity:
Use the SSDF’s terminology and structure to organize communications about secure software development requirements. This enables all software producers to use the same lexicon when attesting to conformity for federal agencies. Software producers can map their secure development methodology to the SSDF’s secure software development practices or associated informative references.
Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle. With the highly dynamic nature of software today, attesting to how things were and are done on an ongoing basis (processes and procedures) is typically more valuable than attesting to how things were done for a specific software release generated by one instance of those processes. This is especially true for post-release practices such as vulnerability disclosure and response, where processes might not yet have been performed for the latest release.
Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required. First-party attestation is recommended for meeting the EO 14028 requirements. This is consistent with the guidance in NIST SP 800-161 Rev. 1 (Second Draft), which states in Section 3.1.2: “There are a variety of acceptable validation and revalidation methods, such as requisite certifications, site visits, third-party assessment, or self-attestation. The type and rigor of the required methods should be commensurate to the criticality of the service or product being acquired and the corresponding assurance requirements.”
When requesting artifacts of conformance, request high-level artifacts. The software producer should be able to trace the practices summarized in the high-level artifacts to the corresponding low-level artifacts that are generated by those practices. Asking for low-level artifacts for a particular software release is not recommended for meeting the requirements of EO 14028, but may be needed to meet other agency requirements. Reasons for avoiding low-level artifacts include the following:
Low-level artifacts provide a snapshot in time of only a small aspect of secure software development, whereas high-level artifacts can provide a big-picture view of how secure software development is performed.
Artifacts should address the needs of the audience receiving them, thus providing the necessary information in a usable format for that audience. Understanding low-level artifacts requires the agency to expend considerable technical resources and expertise in analyzing them and determining how to consider them within the context of the broader secure software development practices.
Low-level artifacts often contain intellectual property or other proprietary information, or details that attackers could use for hostile purposes, so accepting low-level artifacts gives the agency additional sensitive information to protect. These minimum recommendations apply to attestation for all software within the scope of this guidance procured by federal agencies and they should be part of each agency’s processes. The recommendations are not intended to replace more stringent requirements for secure software development that federal agencies may have.
Bình luận