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.