This is the tenth in a series of Covington blogs on implementation of Executive Order 14028, “Improving the Nation’s Cybersecurity,” issued by President Biden on May 12, 2021 (the “Cyber EO”).  The first blog summarized the Cyber EO’s key provisions and timelines, and the second, third, fourth, fifth, sixth, seventh, eighth, and ninth blogs described the actions taken by various Government agencies to implement the EO from June 2021 through January 2022, respectively.

This blog summarizes key actions taken to implement the Cyber EO during February 2022.  As with steps taken during prior months, the actions described below reflect the implementation of the EO within the Government.  However, these activities portend further actions in March 2022 that are likely to impact government contractors, particularly those who provide software products or services to government agencies.

NIST Publishes Guidance to Federal Agencies on Practices to Enhance Supply Chain Security When Procuring Software

Section 4(e) of the Cyber EO requires the National Institute of Standards and Technology (NIST) to publish guidelines on practices for software supply security for use by U.S. Government acquisition and procurement officials.  Section 4(k) of the EO requires the Office of Management and Budget, within 30 days of the publication of this guidance (or March 4, 2022), to “take appropriate steps to require that agencies comply with such guidelines with respect to software procured after the date of the EO.  Section 4(n) of the EO states that within one year of the date of the EO (or May 12, 2023), the Secretary of Homeland Security…shall recommend to the FAR Council contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with, any requirements issued pursuant to subsections (g) through (k) of this section.”

NIST issued the Supply Chain Security Guidance called for by Section 4(e) of the EO on February 4, 2022.  The Supply Chain Security Guidance states that it “provides recommendations to federal agencies on ensuring that the producers of software they procure have been following a risk-based approach for secure software development throughout the software life cycle,” and that “[t]hese recommendations are intended to help federal agencies gather the information they need from software producers in a form they can use to make risk-based decisions about procuring software.”  The scope of the Supply Chain Security Guidance is expressly limited to “federal agency procurement of software, which includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.”  The Guidance further provides that “the location of the implemented software, such as on-premises or cloud-hosted, is irrelevant,” and also excludes open source software and software developed by federal agencies.  However, open-source software that is bundled, integrated, or otherwise used by software purchased by a federal agency is within the scope of the Guidance.

The Supply Chain Security Guidance defines minimum recommendations for federal agencies as they acquire software or a product containing software:

1. Use the Secure Software Development Framework (SSDF) terminology and structure to organize communications about secure software development requirements.
2. Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle.
3. Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.
4. When requesting artifacts of conformance, request high-level artifacts.

The Guidance makes clear that these minimum recommendations apply to all within-scope software procured by federal agencies, including “commercial off-the-shelf (COTS) software product vendors, government off-the shelf (GOTS) software developers, and contractors and other custom software developers.”  However, the Guidance notes that these recommendations ae not intended to replace more stringent requirements for secure software development that agencies may have, and that these minimum practices “may not be sufficient in some cases.”  For example, the Guidance states that an agency “may need greater visibility into the practices for a particular product so that it can better understand how the product would affect the agency’s cybersecurity risk.”  The Guidance acknowledges that agencies requiring greater visibility into practices “may increase costs for software producers, and thus my increase product prices.”

Finally the Guidance includes several FAQs that provide additional information on the Guidance that are instructive to its intended application.  For example, FAQs 5 and 6 stat that agencies can choose to implement the Guidance with respect to software developed by federal agencies and/or open-source software that they freely and directly obtain.  In the same vein, FAQ 9 states that software producers may choose to exceed the Guidance requirements and provides a template that producers may use to identify their greater-than-required secure software development activities or processes.

NIST Issues Criteria for Cybersecurity Labelling of Consumer Software and Consumer Internet-of-Things Products for Pilot Programs

The Consumer Software Cybersecurity Labeling Criteria

On February 4, 2022, NIST issued recommended criteria for a consumer software cybersecurity labelling pilot program (Software Labelling Criteria).  The Software Labeling Criteria identify the key elements for a potential consumer software cybersecurity labeling program that would be established by an organization other than NIST.  The purposes of such a program would be to “aid consumers in their software selection decisions by enabling comparisons among products and educating them about software security considerations,” and potentially also “encourage [software] providers to consider cybersecurity aspects of their software and ways to achieve greater trust and confidence in the software, and, ultimately, to improve the management of related cybersecurity risks.”  The Software Labeling Criteria recommend considerations for three key aspects of a potential consumer software cybersecurity labeling program.  These key aspects are:  (1) Baseline Product Criteria, (2) Labeling, and (3) Conformity Assessments.

Baseline Product Criteria

The Software Labeling Criteria provides technical baselines for a series of labeling “claims” about the software.  These claims fall into two categories:  (1) “Descriptive Claims,” and (2) “Secure Software Development.”  Descriptive claims encompass both claims about the organization making the claims about the organization making the claims on the label and what the label is describing.  Secure Software Development Claims describe how the software provider claims to adhere to accepted secure software development practices throughout the software development lifecycle.  Several of these claims reference the final version of the Secure Software Development Framework that NIST published on February 4, 2022.

The Software Labeling Criteria identify the following Descriptive Claims:  Claimant, Label Scope, Software Identifiers, Claim Date, Security Update Status, Minimum Duration of Security Update Support, and Security Update Method.  The Criteria identify the following Secure Software Development Claims:  Implements a Secure Software Development Process, Practices Secure Design and Vulnerability Remediation, Practices Responsible Vulnerability Reporting Disclosure, Uses Multifactor Authentication (if applicable), Free From Hard Coded Secrets, Uses Strong Cryptography (if applicable), and User Data is identified and Secured.  For each of these claims, the Software Labeling Criteria provides a statement about what information the claim should capture (“Description”), the outcome and/or reasoning for including the claim in the label focusing on how this benefits the user of the label (“Desired Outcome”), and factual statements made by the claimant that are conveyed with the claim (“Assertions”).  Thus, when referenced by the label, the consumer is informed about these outcome-based assertions and associated information.

Labeling

The Software Labeling Criteria identifies two recommended approaches to cybersecurity labeling.  The first is a “Binary label.”  Under this approach, “the product has a single, consumer-tested label  indicating that the software has met the criteria required to receive the label.”  The second is “Layered Approach.”  Under this approach, the label “provides a means for consumers to access additional information about the labeling program as well as declaration of conformity information for the software.”  The Criteria recommends that the binary label be coupled with a layered approach in which one of the following is included on the label to lead consumers to additional details online:

• a URL (g., as included in Singapore’s cybersecurity label [SINGAPORE], not a shortened URL, which is not easily attributable to the source domain; or
• a scannable code (g., a QR code).

The Software Labeling Criteria also recommends that labels be available to consumers before and at the time and place of software selection (in-store or on-line) as well as after selection, that digital labels (e-labels) be available for all products, and that a robust consumer education program be developed to establish and increase consumer label recognition.

Conformity Assessment

The Software Labeling Criteria defines “conformity assessment” as a “term that describes the formalized process for demonstrating that specified requirements are fulfilled.”  A conformity assessment scheme consists of a set of rules and procedures that–

• describes the objects of conformity assessment (e.g., a consumer software);
• identifies the specified requirements (e.g., the recommended technical baseline criteria);
• identifies the activity for performing conformity assessment (e.g., testing, inspection, certification, self-declaration, of conformity, etc.); and
• defines roles and the types of organizations performing each role (e.g., first, second, or third parties).

The Software Labeling Criteria notes that, given the range of consumer software and associated risks, “no single assessment approach is appropriate,” and that NIST therefore was not recommending a particular set of conformity assessment requirements.  Rather, NIST suggests that the labeling scheme owner “tailor the recommended criteria, define conformity assessment requirements, develop the label and associated information, and conduct related consumer outreach and education.”  However, NIST notes that “there are several conformity assessment activities that could be leveraged in consumer software scheme to demonstrate conformity to the recommended criterial,” including –

• Supplier’s declaration of conformity (self-attestation) where the declaration of conformity is performed by the organization that provides the software;
• Third-party testing or inspection where there is determination or examination of the consumer software based on defined criteria; or
• Third-party certification of the consumer software.

The Consumer IoT Products Cybersecurity Labelling Criteria

On February 4, 2022, NIST published its Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products (“IoT Criteria”).  The IoT Criteria make recommendations for cybersecurity labeling for consumer IoT products, in other words, for IoT products intended for personal, family, or household use.  A detailed discussion of this publication is available on Covington’s Inside Privacy blog.