On May 12, 2021, the Biden Administration issued an Executive Order on Improving the Nation’s Cybersecurity (the “EO”). The EO sets out a list of deliverables due from a number of governmental entities in June 2021 and successive months. Our overall summary of the EO and its deliverables can be found here, and our discussion of the EO deliverables that were due in June 2021 can be found here. This blog addresses the EO deliverables in July 2021.
Developments Affecting Enhancement of Software Supply Chain Security
NIST Publishes Guidance on Security Measures for Critical Software Use
On June 25, 2021, the National Institute of Standards and Technology (“NIST”) published a white paper containing a definition of “critical software” for purposes of Section 4 of the EO, “Enhancement of Software Supply Chain Security.” Section 4(i) of the EO requires NIST, in consultation with the Cybersecurity & Infrastructure Security Agency (“CISA”) and the Office of Management and Budget (“OMB”), to publish guidance by July 11 outlining security measures for critical software as defined by NIST, “including applying practices of least privilege, network segmentation, and proper configuration.” On July 9, 2021, NIST published the guidance called for by Section 4(i).
NIST’s guidance is aimed at federal agency use of “EO-critical software” – i.e., software defined by NIST as critical software under Section 4(g) of the EO by federal agencies in their operational environments.[1] Although the EO was not explicit as to whether the guidance would extend beyond the government and its contractors, the guidance that was issued does not purport to cover development or acquisition of EO-critical software, nor does it purport to cover use of EO-critical software by non-governmental organizations.
The substance of the guidance consists of two main components: (a) Security Measure objectives, and (b) the Security Measures themselves. The guidance explicitly makes these objectives and security measures applicable to both EO-critical software and to EO-critical software platforms, which it defines as the platforms on which EO-critical software runs, including endpoints, servers, and cloud resources. Thus, it would be a mistake to view the objectives and security measures set forth in the guidance as limited to software only. The guidance defines the Objectives as:
- Protect EO-critical software and EO-critical software platforms (the platforms on which EO-critical software runs, such as endpoints, servers, and cloud resources) from unauthorized access and usage.
- Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms.
- Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation.
- Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms.
- Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms.
Each of these objectives has several security measures associated with it. For example, to protect EO-critical software and EO-critical software platforms from unauthorized access and usage under Objective 1, one of the security measures is to “[u]se multi-factor authentication that is verifier impersonation-resistant for all users and administrators of EO-critical software and EO-critical software platforms.” The FAQs indicate that “an example of a verifier impersonation-resistant protocol is client-authenticated Transport Layer Security (TLS).” Implementation of these security measures could represent a significant effort for agencies, depending on the nature and scale of the systems that they operate.
The security measures are largely sourced from other publications, including NIST SP 800-53 and NIST’s cybersecurity framework. Although the measures are intended to apply to agencies, NIST indicated in the response to a separate FAQ that “[t]he security measures for using EO-critical software could be applied to cloud-based environments by cloud service providers.”
NIST Publishes Guidelines Recommending Minimum Standards for Vendor Verification of Their Software Source Codes
EO Section (4r) requires NIST to publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing) by July 11, 2021. On July 9, NIST published these guidelines. NIST indicated that “[w]hile the EO uses the term ‘vendors’ testing,’ the intent is much broader and includes developers as well.” Given the broad scope of the potential application of the guidance and its application to vendors and software developers, it is possible that federal contractors could see these requirements imposed by certain agencies as part of their contracts with those agencies.
NIST’s recommended minimum verification standards consist of Technique Classes, Techniques, and Descriptions and References to Recommended Minimums Documents. The Technique Classes are: (1) Threat Modeling; (2) Automated Testing; (3) Code-Based (Static) Analysis; (4) Dynamic Analysis; (5) Check Included Software; and (6) Fix Bugs. Each of these Technique Classes includes one or more specific techniques. For example, the Code-Based (Static) Analysis technique class includes the “Use a code scanner to look for top bugs” technique and the “Review for hardcoded secrets” technique. The guidelines provide descriptions and references for these and all other techniques specified.
The FAQs included in the guidelines explain why the guidelines refer to source code “verification” rather than “testing,” which is the term used in the EO. The response to FAQ #4 asserts that the term “testing” is often used to describe dynamic analysis only, and that the term “verification” is more technically accurate given “the myriad types of software testing referred to in the EO.” It further states that use of the term verification “ensures that the goal of the EO is met.” FAQ #3 explains why NIST extended the minimum standards to both vendor and developer verification even though the EO refers only to vendors. The response to FAQ #3 notes that the software vendor and developer are not always the same, and that “verification should be done as early in the software development life cycle (SDLC) as possible, which will be by the developer,” while a vendor who is not also the software’s developer “should also perform verification but will not have the opportunity to be involved early in the process.”
Finally, FAQ #1 makes clear that the source code minimum verification standards “are guidelines and remain voluntary.” However, section (4e) of the EO requires NIST to develop guidance for “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at minimum prior to product, version, or update release….” FAQ #1 states that NIST anticipates that the guidance it develops under section (4e) will reference the software source code verification guidelines.
Recommendations Regarding FAR and DFARS Contract Language
Recommendations Regarding Agency-Specific Cybersecurity Requirements
Section 2(i) of the EO directs CISA, in consultation with the National Security Agency (“NSA”), the OMB Director, and the General Services Administration (“GSA”) Administrator, to review agency-specific cybersecurity requirements that currently exist as a matter of law, policy, or contract, and to recommend to the Federal Acquisition Regulation (“FAR”) Council by July 11, 2021 “standardized contract language for appropriate cybersecurity requirements.” The section states that CISA’s recommendations “shall include consideration of the scope of contractors and associated service providers to be covered by the proposed contract language.” This language is likely to be of great interest to the federal contractor community, as any recommended requirements could become a condition for certain contract awards.
It is unclear at this time whether CISA submitted any recommended standardized contract language for cybersecurity requirements to the FAR Council pursuant to section 2(i). CISA’s website notes that pursuant to the EO, it “will work with OMB to recommend contract language that makes sharing critical data easier….” Even if CISA has recommended language, we understand that it is CISA’s policy not to publicly disclose its recommended language until the FAR Council proposes standardized contract language for public notice and comment, which it is required by EO section 2(j) to do within 60 days of receiving recommended language from CISA.
Recommendations Regarding FAR and DFARS Contract Requirements and Language for IT and OT Service Providers
Section 2(b) of the EO requires OMB, in consultation with the Secretary of Defense, the Attorney General, the secretary of Homeland Security, and the Office of the Director of National Intelligence, to review the FAR and Defense Federal Acquisition Regulation Supplement (“DFARS”) contract requirements and language for contracting with information technology (“IT”) and operational technology (“OT”) service providers and to recommend updates to such requirements and language to the FAR Council and other appropriate agencies by July 11, 2021. The section further requires that the recommended contract language shall include descriptions of contractors to be covered by the language, and shall be designed to ensure, among other things, that such service providers collect, report, and preserve data relevant to cyber incidents or potential cyber incidents on all information systems over which they have control, including systems operated on behalf of agencies.
It is unclear at this time whether OMB has completed its review of the relevant FAR and DFARS provisions or submitted any recommended contract language to the FAR Council for IT and OT service providers pursuant to section 2(b) of the EO.
Federal Network Infrastructure Modernization, Including Cloud Services
Section 3(b) of the EO requires the head of each federal agency, by July 11, 2021, to (a) update existing agency plans to prioritize resources for the adoption and use of cloud technology as outlined in relevant OMB guidance, (b) develop a plan to implement Zero Trust Architecture, including migration steps that NIST has outlined in guidance and standards, and (c) provide a report to OMB discussing the agency’s cloud technology and Zero Trust Architecture plans. Section 3(c)(iii) of the EO requires CISA, also by July 11, to develop and issue a cloud service governance framework for federal civilian agencies. It is unclear at this time whether either of these deadlines were met.
National Security Systems Requirements
Section 9(a) of the EO requires the NSA, in coordination with the Director of National Intelligence and the Committee on National Security Systems, to adopt requirements for National Security Systems (“NSSs”) by July 11, 2021, that are equivalent to or exceed the cybersecurity requirements set forth in the EO that are not otherwise applicable to NSSs. In general, an NSS is an unclassified information system that involves intelligence activities, cryptologic activities related to national security; command and control of military forces; equipment that is an integral part of a weapon or weapons system; or is critical to the direct fulfillment of military or intelligence missions. Under the EO, any such requirements shall be codified in a National Security Memorandum (“NSM”), but until such time as that NSM is issued, no programs, standards, or requirements established pursuant to the EO shall apply with respect to NSSs.
[1] As discussed in our prior post, NIST defined EO-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.