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 secondthirdfourthfifthsixthseventheighth, 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.

 

 

 

Robert Huffman

Bob Huffman represents defense, health care, and other companies in contract matters and in disputes with the federal government and other contractors. He focuses his practice on False Claims Act qui tam investigations and litigation, cybersecurity and supply chain security counseling and compliance…

Bob Huffman represents defense, health care, and other companies in contract matters and in disputes with the federal government and other contractors. He focuses his practice on False Claims Act qui tam investigations and litigation, cybersecurity and supply chain security counseling and compliance, contract claims and disputes, and intellectual property (IP) matters related to U.S. government contracts.

Bob has leading expertise advising companies that are defending against investigations, prosecutions, and civil suits alleging procurement fraud and false claims. He has represented clients in more than a dozen False Claims Act qui tam suits. He also represents clients in connection with parallel criminal proceedings and suspension and debarment.

Bob also regularly counsels clients on government contracting supply chain compliance issues, including cybersecurity, the Buy American Act/Trade Agreements Act (BAA/TAA), and counterfeit parts requirements. He also has extensive experience litigating contract and related issues before the Court of Federal Claims, the Armed Services Board of Contract Appeals, federal district courts, the Federal Circuit, and other federal appellate courts.

In addition, Bob advises government contractors on rules relating to IP, including government patent rights, technical data rights, rights in computer software, and the rules applicable to IP in the acquisition of commercial items and services. He handles IP matters involving government contracts, grants, Cooperative Research and Development Agreements (CRADAs), and Other Transaction Agreements (OTAs).

Susan B. Cassidy

Ms. Cassidy represents clients in the defense, intelligence, and information technologies sectors.  She works with clients to navigate the complex rules and regulations that govern federal procurement and her practice includes both counseling and litigation components.  Ms. Cassidy conducts internal investigations for government…

Ms. Cassidy represents clients in the defense, intelligence, and information technologies sectors.  She works with clients to navigate the complex rules and regulations that govern federal procurement and her practice includes both counseling and litigation components.  Ms. Cassidy conducts internal investigations for government contractors and represents her clients before the Defense Contract Audit Agency (DCAA), Inspectors General (IG), and the Department of Justice with regard to those investigations.  From 2008 to 2012, Ms. Cassidy served as in-house counsel at Northrop Grumman Corporation, one of the world’s largest defense contractors, supporting both defense and intelligence programs. Previously, Ms. Cassidy held an in-house position with Motorola Inc., leading a team of lawyers supporting sales of commercial communications products and services to US government defense and civilian agencies. Prior to going in-house, Ms. Cassidy was a litigation and government contracts partner in an international law firm headquartered in Washington, DC.

Photo of Michael Wagner Michael Wagner

Mike Wagner helps government contractors navigate high-stakes enforcement matters and complex regulatory regimes.

Combining deep regulatory knowledge with extensive investigations experience, Mr. Wagner works closely with contractors across a range of industries to achieve the efficient resolution of regulatory enforcement actions and government…

Mike Wagner helps government contractors navigate high-stakes enforcement matters and complex regulatory regimes.

Combining deep regulatory knowledge with extensive investigations experience, Mr. Wagner works closely with contractors across a range of industries to achieve the efficient resolution of regulatory enforcement actions and government investigations, including False Claims Act cases. He has particular expertise representing individuals and companies in suspension and debarment proceedings, and he has successfully resolved numerous such matters at both the agency and district court level. He also routinely conducts internal investigations of potential compliance issues and advises clients on voluntary and mandatory disclosures to federal agencies.

In his contract disputes and advisory work, Mr. Wagner helps government contractors resolve complex issues arising at all stages of the public procurement process. As lead counsel, he has successfully litigated disputes at the Armed Services Board of Contract Appeals, and he regularly assists contractors in preparing and pursuing contract claims. In his counseling practice, Mr. Wagner advises clients on best practices for managing a host of compliance obligations, including domestic sourcing requirements under the Buy American Act and Trade Agreements Act, safeguarding and reporting requirements under cybersecurity regulations, and pricing obligations under the GSA Schedules program. And he routinely assists contractors in navigating issues and disputes that arise during negotiations over teaming agreements and subcontracts.

Photo of Ryan Burnette Ryan Burnette

Ryan Burnette advises clients on a range of issues related to government contracting. Mr. Burnette has particular experience with helping companies navigate mergers and acquisitions, FAR and DFARS compliance issues, public policy matters, government investigations, and issues involving government cost accounting and the…

Ryan Burnette advises clients on a range of issues related to government contracting. Mr. Burnette has particular experience with helping companies navigate mergers and acquisitions, FAR and DFARS compliance issues, public policy matters, government investigations, and issues involving government cost accounting and the Cost Accounting Standards.  Prior to joining Covington, Mr. Burnette served in the Office of Federal Procurement Policy in the Executive Office of the President, where he worked on government-wide contracting regulations and administrative actions affecting more than $400 billion dollars’ worth of goods and services each year.