On May 12, 2021 the Biden Administration issued an “Executive Order on Improving the Nation’s Cybersecurity” (EO). Among other things, the EO sets out a list of deliverables from a variety of government entities. A number of these deliverables were due in June, including a definition of “critical software,” the minimum requirements for a software bill of materials, and certain internal actions imposed on various federal agencies.
Developments Affecting Enhancement of Software Supply Chain Security
Definition of Critical Software. Section 4 of the EO stated that the “development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.” The EO cites a “pressing need” for mechanisms to ensure the “security and integrity” of “critical software.” The EO broadly defines critical software as “software that performs functions critical to trust” and tasks the Secretary of Commerce, through the National Institute of Standards and Technology (NIST) to develop a definition of critical software that could be used in forthcoming regulations and guidance – including guidance required by the EO on identifying practices that enhance the security of the software supply chain.
On June 25, 2021, NIST issued a white paper providing a definition of critical software. The white paper followed a workshop that NIST held on June 2-3, 2021 with over 1400 participants and 150 position papers submitted for NIST’s consideration. In addition to private industry, NIST solicited input from the public as well as reportedly from several government agencies – including the Cybersecurity and Infrastructure Security Agency, the Office of Management and Budget (OMB), the Office of the Director of National Intelligence (ODNI) and the National Security Agency – to help define what critical software means.
NIST’s definition is broad and 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:
- Software that is designed to run with elevated privilege or manage privileges;
- Software that has direct or privileged access to networking or computing resources;
- Software that is designed to control access to data or operational technology;
- Software that performs a function critical to trust; or operates outside of normal trust boundaries with privileged access.
According to NIST, this definition preliminarily includes operating systems, web browsers, hypervisors, endpoint security tools, identity and access management applications, network monitoring tools, backup, recovery, and remote storage tools, and other categories of software.
In explaining the definition, NIST expressed its view that the EO’s implementation “must take into consideration how the software industry functions, including product development, procurement, and deployment.” Further, NIST explained that the term “critical” as used in the EO is not based not on the context of use, “but instead focuses on critical functions that address underlying infrastructure for cyber operations and security.” Some limited use cases – such as software solely used for research or testing that is not deployed in production systems – are outside of the scope of this definition.
Finally, although the definition applies to all forms of software, NIST recommends that the initial EO implementation phase focus on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised. NIST indicated that later implementation of the EO could expand to other forms of software such as software that controls access to data, cloud-based and firmware to name a few.
Other Developments
Software Bill of Materials Minimum Requirements. Section 4(f) of the EO requires the National Telecommunications and Information Administration (NTIA) to publish the minimum elements of a Software Bill of Materials (SBOM), which the EO defines as “a formal record containing the details and supply chain relationships of various components used in building [the] software.” In preparing to meet the July 11, 2021 deadline for publishing the minimum elements for SBOMs, NTIA issued a request for public comment on the minimum elements for SBOMs and the factors that should be considered in requesting, producing, distributing, and consuming such items.
NTIA’s request notes that an SBOM is similar to a “list of ingredients” and thereby promotes transparency in the software supply chain. NTIA proposed a definition of the minimum elements of an SBOM that encompasses three broad, inter-related features: (1) required data fields; (2) operational considerations; and (3) support for automation. Data fields suggested include “supplier name,” “component name,” and “cryptograph hash of the component,” among others. Operational considerations include a set of operational and business decisions and actions that establish the practice of requesting, generating, sharing, and consuming SBOMs, including “frequency,” “depth,” and “delivery.” Automation support relates to whether the SBOM can be automatically generated and is machine-readable, which is “[a] key element for SBOM to scale across the software ecosystem.”
Over 86 written comments were submitted in response to NTIA’s request by the June 17, 2021 deadline for such comments.
Other Upcoming EO Deadlines. The EO imposes other deadlines in June 2021 that may have been met, but for which there is no public access to the results. These include –
- Section 2(g)(i) of the EO requires the Department of Homeland Security (DHS), in consultation with the Department of Defense (DoD), the Attorney General, and OMB, to recommend to the FAR Council contract language regarding the reporting of cyber incidents. The EO requires such contract language to identify (1) the nature of the cyber incidents that require reporting; (2) the types of information that must be reported; (3) appropriate and effective protections for privacy and civil liberties; (4) the time periods within which contractors must report cyber incidents based on a graduated scale of severity (with reporting of the most severe cyber incidents not to exceed 3 days from initial detection); (5) National Security Systems (NSS) reporting requirements; and (6) the types of contractors and associated service providers to be covered by the proposed contract language. We have not yet been able to confirm whether DHS submitted any recommended contract language to the FAR Council or whether, if it did, what such language says.
- Section 7(c) of the EO requires DHS to provide OMB with recommendations on options for implementing an Endpoint Detection Response initiative to support proactive detection of cyber incidents. A senior Biden Administration official publicly confirmed that DHS had provided such recommendations to OMB, but declined to state what those recommendations are.
- Section 7(g) of the EO requires NSA to recommend to DOD, ODNI, and the Committee on NSS by June 26, 2021, appropriate actions for improving detection of cyber incidents affecting NSS. Whether those recommendations have been issued has not been publicly disclosed.
