A Critical Step: NIST Defines "Critical Software" Subject to Biden's Cybersecurity Order
Litigation Alert
On June 25, 2021, the National Institute of Standards and Technology (NIST) published a definition of "critical software," the first of several steps the Biden administration is taking to enhance the cybersecurity of America's software supply chain under the recent Executive Order on Improving the Nation's Cybersecurity (the Order or E.O.). In addition to providing this crucial definition, the NIST publication includes a preliminary list of "software and software products" that may qualify as "critical" under the Order and responses to a series of Frequently Asked Questions (FAQs).
The NIST publication is significant for federal contractors and other companies that offer and sell software for use by the U.S. government because under the Order, "critical software" will soon be subject to heightened development and transparency standards and eventually will be banned from use by federal agencies if the software does not meet those standards. Below we discuss the key elements of the NIST publication and what the software industry can expect next.
The Biden Cybersecurity Order
The Biden administration issued the Order on May 12, 2021, promising to make sweeping changes to the way the federal government approaches cybersecurity. The magnitude of those potential changes is perhaps most evident in Section 4, which aims to improve the "security and integrity of critical software — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources)," according to the Order. The president directed the Secretary of Commerce, acting through NIST, to develop and publish a definition of "critical software" based on input from government agencies, the private sector, academia, and other interested parties.
Defining critical software is a crucial first step to implementing Section 4 of the Order because it eventually will lead to the creation of uniform software development standards that will be enforced via the Federal Acquisition Regulation (FAR). Following the creation of these standards, the Department of Homeland Security (DHS) will recommend contract language to the FAR Council, which in turn will amend the FAR to codify the new software development standards and require federal agencies to:
- Remove all "non-compliant software" from existing contracting vehicles, including Indefinite Delivery, Indefinite Quantity contracts, Federal Supply Schedules, Federal Government-wide Acquisition Contracts, Blanket Purchase Agreements, and Multiple Award Contracts.
- Mandate providers of "legacy software" update their practices to meet the new development standards.
Once implemented, these new rules could produce seismic changes in the federal marketplace for commercial software. Contractors that can offer the government more secure software will gain an even greater competitive advantage, whereas companies that are slow to adapt their products may eventually find themselves on the outside looking in.
The NIST Publication: Critical Software
There are many existing definitions and uses of the term "critical," according to the NIST publication. To implement the Order, NIST developed a tailored definition of critical software, termed "E.O.-critical software," which focuses on the cybersecurity attributes and functions of a given piece of software. Specifically, E.O.-critical software is defined 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) purchased for, or deployed in, production systems and used for operational purposes. Key terms within the definition are explained in the FAQs, including "direct software dependencies" and "critical to trust." See FAQ 2 ("For a given component or product, [by direct software dependencies], we mean other software components (e.g., libraries, packages, modules) that are directly integrated into, and necessary for operation of, the software instance in question. This is not a systems definition of dependencies and does not include the interfaces and services of what are otherwise independent products.") and FAQ 3 ("Critical to trust" covers categories of software used for security functions such as network control, endpoint security, and network protection.").
NIST recommends a phased implementation of Section 4 of the Order, focusing first on standalone, on-premises software that has security-critical functions or poses similar significant potential for harm if compromised. Subsequent phases may address other software categories, such as:
- Software that controls access to data
- Cloud-based and hybrid software
- Software development tools, such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software
- Software components in boot-level firmware
- Software components in operational technology (OT)
The publication includes a preliminary list of software categories considered by NIST to be E.O.-critical. This list is not authoritative. The final list of E.O.-critical software will be developed by the Cybersecurity & Infrastructure Security Agency (CISA) within 30 days of the NIST publication (i.e., on or before July 25, 2021). NIST's unofficial list identifies the following software categories as E.O.-critical:
|
Category of Software |
Description |
Product Examples |
Rationale for Inclusion |
|---|---|---|---|
| Identity, credential, and access management (ICAM) | Software that centrally identifies, authenticates, manages access rights for, or enforces access decisions for organizational users, systems, and devices |
|
Foundational for ensuring that only authorized users, systems, and devices can obtain access to sensitive information and functions |
| Operating systems, hypervisors, and container environments | Software that establishes or manages access and control of hardware resources (bare metal or virtualized/containerized) and provides common services such as access control, memory management, and runtime execution environments to software applications and/or interactive users |
|
Highly privileged software with direct access and control of underlying hardware resources and that provides the most basic and critical trust and security functions |
| Web browsers | Software that processes content delivered by web servers over a network and is often used as the user interface to device and service configuration functions | Standalone and embedded browsers |
|
| Endpoint security | Software installed on an endpoint, usually with elevated privileges which enable or contribute to the secure operation of the endpoint or enable the detailed collection of information about the endpoint |
|
|
| Network control | Software that implements protocols, algorithms, and functions to configure, control, monitor, and secure the flow of data across a network |
|
|
| Network protection | Products that prevent malicious network traffic from entering or leaving a network segment or system boundary |
|
Provides a function critical to trust, often with elevated privileges |
| Network monitoring and configuration | Network-based monitoring and management software with the ability to change the state of — or with installed agents or special privileges on — a wide range of systems |
|
Capable of monitoring and/or configuring enterprise IT systems using elevated privileges and/or remote installed agents |
| Operational monitoring and analysis | Software deployed to report operational status and security information about remote systems and the software used to process, analyze, and respond to that information | Security information and event management (SIEM) systems |
|
| Remote scanning | Software that determines the state of endpoints on a network by performing network scanning of exposed services | Vulnerability detection and management software | Typically has privileged access to network services and collects sensitive information about the vulnerabilities of other systems |
| Remote access and configuration management | Software for remote system administration and configuration of endpoints or remote control of other systems |
|
Operates with significant access and elevated privileges, usually with little visibility or control for the endpoint user |
| Backup/recovery and remote storage | Software deployed to create copies and transfer data stored on endpoints or other networked devices |
|
|
Contractors and other entities that provide software for use by the federal government should carefully examine this preliminary list to determine if their offerings may be covered. Though the list is unofficial, it seems likely that the final CISA list will closely track the NIST recommendations. Moreover, in NIST's opinion, individual departments and agencies can ask software vendors to attest that their products meet E.O.-critical security measures set forth in Section 4 of the Order, even if those software products are not included in CISA's final list of E.O.-critical software. See FAQ 15 ("If I am using a software product that is not included in the E.O.-critical list, but it is critical for me, can I ask the vendor to provide attestation? Yes, departments and agencies can leverage the E.O.-critical security measures defined in Section 4(e) as part of a procurement."). Therefore, all software providers should keep a close watch on developments in this area, regardless if their products are officially included in the initial implementation phase.
If you have questions about the administration's cybersecurity executive order or its implementation, please contact us:
Alex L. Sarria, asarria@milchev.com, 202-626-5822
Jason N. Workmaster, jworkmaster@milchev.com, 202-626-5893
The information contained in this communication is not intended as legal advice or as an opinion on specific facts. This information is not intended to create, and receipt of it does not constitute, a lawyer-client relationship. For more information, please contact one of the senders or your existing Miller & Chevalier lawyer contact. The invitation to contact the firm and its lawyers is not to be construed as a solicitation for legal work. Any new lawyer-client relationship will be confirmed in writing.
This, and related communications, are protected by copyright laws and treaties. You may make a single copy for personal use. You may make copies for others, but not for commercial purposes. If you give a copy to anyone else, it must be in its original, unmodified form, and must include all attributions of authorship, copyright notices, and republication notices. Except as described above, it is unlawful to copy, republish, redistribute, and/or alter this presentation without prior written consent of the copyright holder.