The Home of the Security Bloggers Network
Home » Security Bloggers Network »
The federal government has issued rules that will soon affect software producers. Here’s the short version:
Good news: The government wants to protect everyone from supply chain disruption.
Bad news: Deadlines! New requirements, like providing attestations and artifacts.
Good news: That’s only if you sell software to the federal government.
Bad news: OK, but you ought to comply, anyway, since companies that meet the requirements will be more attractive business partners. You’ll either be one of them…or you won’t.
Good news: We are here to help make sense of all this.
Now for the long version.
On September 14, 2022, the Office of Management and Budget (OMB) issued Memorandum M-22-18 (the White House Memo) requiring federal agencies to comply with rules to ensure that third-party software they use meets secure software development practices. While the changes affect federal agencies and the companies providing software to them, industry-wide adoption by all software providers could help prevent the next massive cyberattack to the global supply chain.
The federal government’s efforts began with Executive Order (EO) 14028, Improving the Nation’s Cybersecurity (May 12, 2021). The EO was issued in response to the SolarWinds attack and other serious cyberattacks that affected the software supply chain and served as a reminder of the need to address vulnerabilities in using open source software. One of that EO’s aims: to “improve the security of software by establishing baseline security standards for development of software sold to the government.” The EO directed the National Institute of Standards and Technology (NIST) to issue guidance. The White House Memo now sets out the practices federal agencies must follow to comply with the resulting “NIST Guidance.”
The key requirement under the White House Memo: Federal agencies “must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.” The White House Memo later adds that secure software development practices must have been used “throughout the software development lifecycle.”
The first set of requirements has a deadline that falls on December 13, 2022, or 90 days after the date of the White House Memo.
Software: Software is defined broadly. As a result, many organizations doing business with the federal government will be affected. Software “includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.”
As of when: The White House Memo applies to federal agencies’ use of (a) software developed after September 14, 2022 and (b) existing software that is modified by “major version changes” after September 14, 2022.
Exclusions: The Requirements don’t apply to “agency-developed software,” but agencies must use secure software development practices for agency-developed software.
The White House Memo requires that before a federal agency uses software, the software producer must submit (1) a self-attestation of conforming to NIST Guidance and (2) potentially, “artifacts that demonstrate conformance to secure software development practices.”
Self-attestation, a minimum requirement. Agencies must obtain a self-attestation from the software producer before using all third-party software, including software renewals and major version changes (subject to exceptions). An agency may also require a third-party assessment due to the “criticality of the service or product that is being acquired.”* Self-attestation must include:
Exception—documentation and mitigation. If a software producer cannot attest to one or more of the practices from the NIST Guidance, “the requesting agency shall require the software producer to identify those practices to which they cannot attest, document practices they have in place to mitigate those risks, and require a Plan of Action & Milestones (POA&M) to be developed.” If the agency is satisfied with the documentation, the agency may use the software.
Exception—valid third party assessments. Helpfully—especially where products incorporate open source software—a third-party assessment is acceptable instead of self-attestation, if provided by either a certified FedRAMP Third Party Assessor Organization (3PAO) or one approved by the agency, if the 3PAO uses the NIST Guidance as the assessment baseline.
Reliability of attestations and artifacts. Practices that enhance the security of the software supply chain include “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code,” and “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them.”**
Therefore, an organization that relies on automated, data-powered Compliance is better equipped to make an attestation and provide artifacts. Automated Compliance that provides a constant stream of reliable, real-time data allows faster identification of vulnerabilities, thereby ensuring a more secure software development environment. In addition, such a Compliance system generates credible, trustworthy artifacts to show how software that is part of its product is protected. A judgment call can’t serve as evidence of a secure environment, and a screenshot is easily manipulated. But because an automated system of Compliance is designed to generate artifacts for use as reliable evidence in audits, that same system can yield reliable artifacts that evidence secure software development practices.
Some key deadlines under the White House Memo:
There are also deadlines for OMB, NIST, and the Cybersecurity and Infrastructure Security Agency.
Determining whether a particular organization has a lot of extra work in store depends on whether they use automated Compliance tools. These tools make it easier to attest to, and show evidence of, secure software development practices. Organizations that provide software to government agencies should start closing any gaps that would prevent them from being able to continue.*** But other organizations should also adopt the White House Memo and the NIST Guidance, to better secure their own software development environment and the global software supply chain. The fact that the White House Memo requires attestation and artifacts is a strong argument that these are best practices for any software producer. Following these practices benefits businesses and their potential partners.
*In OMB memorandum M-21-30, NIST defines critical software as “any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:
• is designed to run with elevated privilege or manage privileges;
•has direct or privileged access to networking or computing resources;
• is designed to control access to data or operational technology;
• performs a function critical to trust; or
• operates outside of normal trust boundaries with privileged access.
The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) that is purchased for, or deployed in, information systems and used for operational purposes.”
**https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Section 4(e)(iii) and (iv)).
***Congress is working to codify the requirements of the EO. On September 21, 2022, the Securing Open Source Software Act of 2022, S. 4913, was introduced in the Senate. In part, it would require the Director of the Cybersecurity and Infrastructure Security Agency to assess the risk of open source software components used by federal agencies. The bill awaits approval by the Senate.
*** This is a Security Bloggers Network syndicated blog from anecdotes Blog authored by anecdotes Blog. Read the original post at: https://www.anecdotes.ai/post/the-white-house-memorandum-on-securing-the-software-supply-chain-what-it-means-for-your-organization