Securing the Federal Software Supply Chain
This article, prepared in conjunction with AFCEA’s Technology Committee, is the first in a series of three articles addressing supply chain considerations of software and hardware. The second article in the series will explore securing the hardware supply chain.
Cyber best practices tend to remain just interesting until they become mandates. Recently, there has been a lot of publicity about the federal government's increasing awareness of 'it takes a village' and the interdependence between itself and its supply chains. This is especially important for its technology ecosystem, including vendor and contractor-produced government off-the-shelf and commercial off-the-shelf software. Recognition of the importance of protecting its software supply chain became especially acute after hacks as its vendors introduced high-profile vulnerabilities into government networks.
Most notable of these was the widely publicized incident involving SolarWinds. However, the current thrust to protect the government's supply chain was not a reaction to these recent incidents, but had developed over the last dozen years. And we are on the cusp of new mandates.
One might look back at the Federal Information Security Management ACT of 2002 as the beginning of supply chain security. But let's start with a more recent government action as a starting point. In 2010, President Barack Obama signed Executive Order 13556, which pulled together all the disparate markings for unclassified data under the singular definition of Controlled Unclassified Information, or CUI. You might ask: How does CUI have anything to do with a secure supply chain? Well, two things. First, the CUI definition included, for the first time, information not in the government's direct control. This included health records, tax holder data and other data necessary to protect citizens' and the government's interests. More importantly, this executive order directly led to the publication of the National Institute of Standards and Technology (NIST) standard 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.
NIST 800-171 is a seminal secure supply chain document that lays out the security requirements for protecting CUI data for industry. As the title implies, 800-171 stipulates the rules contractors must abide by to house, process and transmit CUI data. Since 2017, federal contractors have been required to self-access and report their cyber readiness against the standards detailed in NIST's 800-171 publication. The U.S. Department of Defense detailed self-attestation shortcomings in a 2019 interim rule authorizing the inclusion of Cybersecurity Maturity Model Certification (CMMC). CMMC essentially adds requirements for cyber hygiene maturity to the NIST 800-171 requirements, together with third-party certification for organizations handling CUI. CMMC is now in its second revision and will go into effect later this year. Although NIST 800-171 and CMMC primarily targeted the protection of data, both laid the groundwork for future efforts by the federal government to secure its software supply chains.
Fast forward to today. While the foundation for protecting its supply chain is the result of previous initiatives, much of the current guidance—and soon-to-be mandates—are a direct result stemming from President Joe Biden’s Executive Orders 14017 and 14028 in 2021, respectfully called America’s Supply Chains and Improving the Nation’s Cybersecurity. Executive Order 14028 is more specific to the software supply chain and should be considered an expansive cyber order addressing a broad range of issues. It addresses three audiences: software developers, suppliers and customers. The order’s premise is that "protecting our nation from malicious cyber actors requires the federal government to partner with the private sector."
Furthermore, Executive Order 14028 states: "Incremental improvements will not give us the security we need; instead, the federal government needs to make bold changes and significant investments in order to defend the vital institutions that underpin the American way of life." Moreover, it specifies that the security of software directly impacts the federal government's ability to perform its critical functions.
I find it impossible to overstate the profound change that Executive Order 14028 has had beyond creating the requirement for a software bill of materials. Similar to how the 2010 order segmented data for protection, this policy has done the same for software, as it distinguishes the concept of critical software.
Not to be confused with necessary or expensive software, critical software is defined in Executive Order 14028 as "software that performs functions critical to trust." The order also directs the secretary of commerce, acting through the director of NIST, in consultation with the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA) , the Office of Management and Budget (OMB) and the Director of National Intelligence (DNI) to publish a definition of critical software.
They have defined critical software as software that:
- 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
- Operates outside of normal trust boundaries with privileged access
Why is all the discussion about critical software necessary? Because the federal government will secure the supply chain for critical software very differently from all other software.
I find it impossible to overstate the profound change that Executive Order 14028 has had beyond creating the requirement for software bill of materials. ... [T]his policy has done the same for software, as it distinguishes the concept of critical software.
I can report that since Executive Order 14028 was signed, government stakeholders have taken concrete steps, including:
- NIST 800-53 Version 5, Security and Privacy Controls for Information Systems and Organizations, replaces 800-53 Version 4 and includes a whole new section of 12 controls for securing the supply chain. To highlight its importance, "supply chain" is referenced more than 200 times in Version 5.
- NIST 800-218, Secure Software Development Framework, published in February 2022, addresses a detailed framework for creating and maintaining a secure development environment.
- NIST 800-161, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, published in May 2022, describes Cybersecurity Supply Chain Risk Management (C-SCRM), the systematic processes for managing cybersecurity supply chain risks, and the appropriate strategies and responses.
- Securing the Software Supply Chain, Recommended Practices Guide for Developers published jointly in August 2022 by the NSA, the Office of the DNI and CISA presents best practices around securing the software supply chain. The development of this document was mandated by Executive Order 14028.
- OMB Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices, was published in September 2022. It directs agencies and department heads on the timeframes and processes for implementing secure software supply chain practices. It addresses software, firmware and cloud, while mandating wide-ranging procurement processes and procedures.
How do these policies affect the software ecosystem? Mandates requiring the attestation by developers of their secure development and cyber hygiene practices are just around the corner. These mandates dramatically will affect vendors and contractors developing software as well as government organizations acquiring and implementing software.
Brian Hajost is founder and chief operating officer of SteelCloud.