Although most of the developments in November were directed at U.S. Government agencies, the standards being developed for such agencies could be imposed upon their contractors or otherwise be adopted as industry standards for all organizations that develop or acquire software.

CISA Publishes Cybersecurity Incident Response and Vulnerability Response Playbooks

Section 6(a) of the Cyber EO notes that the cybersecurity vulnerability and incident response procedures currently used by Government agencies to identify, remediate, and recover from vulnerabilities and incidents affecting their systems vary across agencies, hindering the ability of lead agencies to analyze vulnerabilities and incidents more comprehensively across agencies.  In order to achieve “standardized response processes,” Section 6(b) of the EO requires the Cybersecurity and Infrastructure Security Agency (“CISA”) to develop a standard set of operational procedures (playbook) to be used by civilian agencies in planning and conducting a cybersecurity vulnerability or incident response activity respecting their information systems.  On November 16, 2021, CISA issued a document with two separate response playbooks, one for incident response and another for vulnerability response.  These two playbooks are contained within a single document.

Both playbooks apply to all Federal Civilian Executive Branch (“FCEB”) agency information systems used or operated by an FCEB agency, a contractor of such an agency, or another organization on behalf of such an agency.  Although the playbooks do not expressly make provisions applicable to contractors and other non-FCEB organizations, CISA stated unequivocally that “[i]t is the policy of the federal government that information and communications technology (“ICT”) providers who have contracted with FCEB agencies must promptly report incidents to such agencies and to CISA.”

The Incident Response Playbook covers incidents that involve confirmed malicious cyber activity and for which a “major incident” (as defined by the Office of Management and Budget) has been declared or not yet reasonably ruled out.  The Incident Response Playbook provides FCEB agencies with a standard set of procedures to identify, coordinate, remediate, recover, and track mitigations from incidents affecting FCEB systems, data, and networks.  The playbook also includes provisions for FCEB reporting of incidents to CISA and coordination with CISA and other agencies in responding to such incidents.

The Vulnerability Response Playbook applies to any vulnerability “that is observed to be used by adversaries to gain unauthorized entry into computing resources.”  The Vulnerability Response Playbook builds on CISA’s Binding Operational Directive 22-01 and sets forth standard, high-level processes and practices that FCEBs should follow when responding to vulnerabilities that pose significant risk.

In announcing the Incident Response and Vulnerability Response playbooks, CISA stated that “future iterations of these playbooks may be useful for organizations outside of the FCEB to standardize incident response practices.”  Elsewhere in the playbooks, however, the reference to “future operations” was dropped.  For example, CISA states that the playbooks are intended to strengthen cybersecurity response practices and operational procedures “not only for the federal government, also for public and private sector entities.”  It also encourages all critical infrastructure entities and private organizations to review the playbooks “to benchmark their own vulnerability and incident response practices.”  Thus, contractors and other private organizations may want to consider the standards, practices, and processes identified in the playbooks to assess whether any potential gaps may exist within their own internal policies and procedures.

NIST Issues Draft Criteria for Consumer Software Cybersecurity Labeling

Section 4 of the Cyber EO directs various federal government agencies to take certain actions to enhance software supply chain security.  Section 4(s) requires the National Institute of Standards and Technology (NIST) to initiate pilot programs to educate the public on the security capabilities of software development practices and Internet of Things (IoT) devices.  Section 4(t) requires NIST to identify criteria for a consumer labeling program that “shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone, and shall use or be compatible with existing labeling schemes that manufacturers use to inform consumers about the security of their products.”  Pursuant to Sections 4(s) and (t), NIST released draft Criteria for Consumer Software Cybersecurity Labeling on November 1, 2021.  NIST will accept comments on the draft criteria through December 16, 2021, and intends to issue a final version of the criteria by February 6, 2022, as required by Section 4(u) of the Cyber EO.

The draft issued by NIST has three primary goals: (1) establishing baseline technical criteria for a consumer cybersecurity label; (2) providing criteria for the form of the label, including how the label can represent cybersecurity-related risks and attributes, how the label can be tested for effectiveness, and how the public can be educated about the label and its meaning; and (3) describing how organizations attesting to the label determine their conformity with the label.  The draft emphasizes that the criteria are not intended to describe how a cybersecurity label should be explicitly represented, and that NIST is not establishing its own labeling program for consumer software.  “Rather, these criteria set out desired outcomes, allowing and enabling the marketplace of providers and consumers to make informed choices.”

The draft describes the baseline technical criteria as a series of attestations, i.e., claims made about the software associated with the label.  It organizes these attestations into the following categories: (1) Descriptive Attestations, such as who is making the claims in the label, what the label applies to, and how consumers can obtain other supporting information; (2) Secure Software Development Attestations, such as how the software provider adheres to accepted secure software development practices throughout the software development cycle; (3) Critical Cybersecurity Attributes and Capability Attestations, and (4) Data Inventory and Protection Attestations, including declarations concerning the data that is processed, stored, or transmitted by the software.  The draft identifies specific attestations included in each of these categories.  For example, the draft identifies the following five attestations within the Critical Cybersecurity Attributes and Capability Attestation category: (1) Free From Known Vulnerabilities; (2) Software Integrity and Provenance; (3) Multifactor Authentication (if applicable); (4) Free From Hard Coded Secrets; and (5) Strong Cryptography (if applicable).

Regarding the criteria for the form of the label itself, the draft identifies four different  approaches: Descriptive; Binary; Graded; and Layered.

  • A descriptive label provides information about the properties or features of the product without any grading or evaluation.
  • A binary label (sometimes called “seal of approval”) is a single, consumer-tested label indicating that the software has met the baseline standard.
  • A graded (or “tiered”) label identifies the degree to which the product satisfies the standard, often by use of colors (e.g., red-green-yellow) or number of icons.
  • A layered label provides the consumer with the means to access additional information about the labeling program and the software’s declaration of conformity.

In the draft, NIST proposes a binary label, which may be coupled with a layered approach in which a short URL (as included in Singapore’s cybersecurity label) or scannable code (e.g., a QR code) on the binary label leads consumers to additional details online.

Finally, the draft defines the conformity assessment criteria for consumer software cybersecurity labeling based on the concept of a Supplier’s Declaration of Conformity (SDOC). The draft includes a detailed discussion of what should be included in the SDOC and any supporting documentation.

NIST Publishes Security Guidance for Internet of Things Devices

NIST additionally published two guidance documents relating to IoT devices in November: (1) guidance relating to Establishing IoT Device Cybersecurity Requirements (NIST Special Publication (SP) 800-213) and (2) a revised IOT Device Cybersecurity Requirements Catalog (NIST SP 800-213A).  The publications are targeted to information security professionals, system administrators, and others in organizations tasked with assessing, applying, and maintaining security on a system.

NIST SP 800-213 overviews areas of consideration for organizations when determining the applicable cybersecurity requirements for an IoT device.  This includes considerations to help organizations:

  • understand IoT device use case and cybersecurity characteristics (including use case and benefits, data implications, interactions with other system elements, and manufacturer practices);
  • assess risk of IoT device impacts to systems (including by reviewing threat source, vulnerability, likelihood, and impact effects); and
  • determine require IoT device cybersecurity characteristics (including selection of requirements from other resources, such as NIST SP 800-53 and the NIST Cybersecurity Framework).

NIST SP 800-213A serves as a companion document to NIST SP 800-213, and is referenced in the section of NIST SP 800-213 that addresses the determination of IoT device cybersecurity characteristics.  It is organized in a similar way to other documents that contractors may be familiar with, such as NIST SP 800-171 and NIST SP 800-53, and contains controls that can be selected in the following categories:

  • Device Identification;
  • Device Configuration;
  • Data Protection;
  • Logical Access to Interfaces;
  • Software Update;
  • Cybersecurity State Awareness; and
  • Device Security.

Although NIST SP 800-213A draws on other publications, it explicitly notes that “Controls are considered independent of their inclusion in SP 800-53B, Control Baselines for Information Systems and Organizations [800-53B], and so some controls included in the related controls list may not be in the low-, moderate-, and/or high-impact baseline.”

NIST Holds Workshop on Proposed Artifacts of Secure Software Development That Software Providers Can Use in Self-Declarations and Attestations

Section 4(e) of the Cyber EO requires NIST to issue guidance identifying practices that enhance the security of the software supply chain, including standards, practices, or criteria regarding secure software development environments and providing “artifacts” that demonstrate conformance to such standards, processes, or criteria.  Pursuant to section 4(e), NIST issued a draft Secure Software Development Framework (Draft SSDF) at the end of September 2021.

NIST conducted a public workshop on the Draft SSDF on November 8, 2021.  The purpose of the workshop was to “solicit input about the types of meaningful artifacts of secure software development that software producers can share publicly with software acquirers,” including insights on “attesting to following specific secure software development practices.” The workshop included a panel on “Self-Declaration and Attestation” that included Warren Merkel, Chief of Standards Services for NIST.  Mr. Merkel identified four steps of conformity assessment: (1) identifying the requirement; (2) determining conformity to the requirement; (3) attestation of conformity; and (4) surveillance.  Mr. Merkel then identified several different approaches to attestation, including self-attestation, third-party certification, and assessment by an entity approved by an accredited body.  According to Mr. Merkel, the Draft SSDF does not require a particular form of attestation.

NIST plans to consider the input it received at the workshop, along with the comments submitted on the Draft SSDF and other sources, in developing the final SSDF, which will be part of the software supply chain security guidance that NIST is required to issue by February 8, 2022.

NTIA Issues Guidance Related to Software Bills of Materials

In November 2021, the National Telecommunications Information Administration (“NTIA”) released two documents related to its ongoing efforts to establish standards for  Software Bills of Materials (“SBOM”).  The first of these documents is a two-page analysis entitled “SBOM Myths vs. Facts.”  NTIA states that this document is intended to help dispel “common, often sincere myths” about SBOM.  The second document issued by NTIA identifies various initiatives, guidance, models frameworks, and reports that expressly or implicitly highlight the value of SBOM.  NTIA states that this is not an exhaustive list, and that it is not endorsed by the NTIA working group that assembled the document.

 

 

 

 

 

Print:
EmailTweetLikeLinkedIn
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 Ashden Fein Ashden Fein

Ashden Fein advises clients on cybersecurity and national security matters, including crisis management and incident response, risk management and governance, government and internal investigations, and regulatory compliance.

For cybersecurity matters, Mr. Fein counsels clients on preparing for and responding to cyber-based attacks, assessing…

Ashden Fein advises clients on cybersecurity and national security matters, including crisis management and incident response, risk management and governance, government and internal investigations, and regulatory compliance.

For cybersecurity matters, Mr. Fein counsels clients on preparing for and responding to cyber-based attacks, assessing security controls and practices for the protection of data and systems, developing and implementing cybersecurity risk management and governance programs, and complying with federal and state regulatory requirements. Mr. Fein frequently supports clients as the lead investigator and crisis manager for global cyber and data security incidents, including data breaches involving personal data, advanced persistent threats targeting intellectual property across industries, state-sponsored theft of sensitive U.S. government information, and destructive attacks.

Additionally, Mr. Fein assists clients from across industries with leading internal investigations and responding to government inquiries related to the U.S. national security. He also advises aerospace, defense, and intelligence contractors on security compliance under U.S. national security laws and regulations including, among others, the National Industrial Security Program (NISPOM), U.S. government cybersecurity regulations, and requirements related to supply chain security.

Before joining Covington, Mr. Fein served on active duty in the U.S. Army as a Military Intelligence officer and prosecutor specializing in cybercrime and national security investigations and prosecutions — to include serving as the lead trial lawyer in the prosecution of Private Chelsea (Bradley) Manning for the unlawful disclosure of classified information to Wikileaks.

Mr. Fein currently serves as a Judge Advocate in the U.S. Army Reserve.

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.