On February 4, the National Institute of Standards and Technology (NIST) issued several documents and updates that spell out software security guidance and recommended consumer labeling practices for software and IoT device devices. NIST also laid out its approach to consumer cybersecurity labeling projects.
These initiatives were mandated under President Biden’s wide-ranging executive order (EO) issued last May. They aim to tighten the federal government’s security requirements for the software products it purchases, hoping that the benefits will also flow to the private sector. The labeling initiatives aim to provide consumers greater insight into the security of the software and devices they purchase and spur greater transparency by consumer software and IoT device makers.
Software supply chain security guidance and updated SSDF
The first document articulates how to enhance the security of the software supply chain as directed under the EO. This guidance follows a whirlwind of activity by NIST to meet the EO’s deadline, including soliciting position papers from the community, hosting a virtual workshop in June and a second virtual workshop in November, consulting with other federal agencies and reviewing existing federal guidance.
The order asked NIST to produce guidance for federal agency staff who have software procurement-related responsibilities and is intended to help federal agency staff know what information to request from software producers regarding their secure software development practices. The new NIST document spells out minimum recommendations for federal agencies to follow as they acquire software or a product containing software.
The order also directed NIST to define actions or outcomes for software producers, such as commercial-off-the-shelf (COTS) product vendors, government-off-the-shelf software developers, contractors, and other custom software developers. To accomplish this task, NIST updated its pre-existing Secure Software Development Framework (SSDF), which already contemplated most of the relevant assignments contained in the EO.
NIST notes that its guidance is limited to federal agency procurement of software, which includes firmware, operating systems, applications, and application services (such as cloud-based software), as well as products containing software. Software developed by federal agencies is out of scope, as is open-source software freely and directly obtained by federal agencies. Open-source software that is bundled, integrated, or otherwise used by software purchased by a federal agency is in scope.
According to the EO’s timeline, by March 6, the Office of Management and Budget (OMB) must take appropriate steps to require that agencies comply with such guidelines concerning software procured after the date of this order. By May 12, 2023, the secretary of homeland security, in consultation with the secretary of defense, the attorney general, the director of OMB, and the administrator of the Office of Electronic Government within OMB, will recommend to the Federal Acquisition Regulatory (FAR) Council, which coordinates government-wide procurement, contract language requiring suppliers of software available for purchase by agencies to comply with, and attest to complying with, any requirements issued under these guidelines.
Cybersecurity labeling of consumer software
Another document NIST released last week is Recommended Criteria for Cybersecurity Labeling of Consumer Software. The EO directed NIST, in coordination with the Federal Trade Commission (FTC) and other agencies, to initiate pilot programs for cybersecurity labeling. These labeling programs are intended to educate the public on the security capabilities of software development practices.
The document NIST issued makes recommendations on the role of a scheme owner in a labeling program, baseline technical criteria that can inform a label, labeling presentation criteria, and conformity assessment criteria. This document also explores consumer education and usability for software labels.
The goal of this document is to guide software providers on how to convey to consumers that “good practices for secure software development were employed during the lifecycle of the software and that security-related software architecture, functionality, and other attributes follow baseline technical criteria.”
Cybersecurity labeling of consumer IoT products
The EO asked NIST to develop criteria for a consumer labeling program for internet-of-things (IoT) products. According to the EO, the “criteria shall consider whether such a consumer labeling program may be operated in conjunction with or modeled after any similar existing government programs consistent with applicable law.”
Drawing on its existing work on IoT product cybersecurity and recent public news stories about compromised IoT products and their vulnerabilities, NIST issued draft versions of the criteria on August 31 and December 3, 2021. The documents were available for community feedback at workshops on September 14 and December 9, 2021, and in writing.
Based on this activity, NIST decided that the product criteria should be expressed as outcomes rather than specific statements about how to achieve them. In addition, NIST concluded that no single conformity assessment approach is appropriate given the variety of ways those baseline criteria could apply to a wide range of products. Finally, NIST determined that a single binary label, such as a seal of approval, indicating a product has met a baseline standard, is likely most appropriate, coupled with a layered approach that leads interested consumers to additional detail online.
Consumer cybersecurity labeling pilots: Approach and feedback
Finally, NIST released its thoughts on how it will conduct pilot projects on both software and IoT labels, given the criteria it has spelled out. The EO directed NIST “to conduct pilots based on the published criteria, and within one year of the date of the order conduct a review of the pilot programs, consult with the private sector and relevant agencies to assess the effectiveness of the programs, determine what improvements can be made going forward, and submit a summary report.”
NIST has determined it won’t design a particular label as part of the pilot. Instead, the pilot will consist of NIST seeking contributions from stakeholders regarding current or potential future labeling efforts for consumer IoT products and consumer software and how those efforts align with the NIST recommendations.
To this end, NIST is asking for contributions to the pilot and seeks information on whether existing labeling schemes align with the NIST recommendations and whether organizations that do not currently operate labeling schemes would be interested in establishing new programs based on the NIST recommendations, among other topics. Contributions to the pilot must be submitted by March 15, 2022.
It’s ‘very deep’ stuff
Chris Wysopal, co-founder and CTO at app security company Veracode, praises NIST for its agility in summarizing a lot of dense information in this spate of documents. “I think they’ve done a good job of summarizing, but it’s very deep,” he tells CSO. “People are going to have to read a lot to understand what’s going to be asked of them as a vendor.”
He particularly praises NIST’s update of the SSDF for considering both the builders and users of the software. “It’s not just purely vendor-oriented. It makes sense because when you talk about security, there’s someone who’s selling technology, and then there’s someone who’s operating it. Both parts of that equation need to understand what the other side did and what the expectations are. Builders and operators both working from the same framework makes a lot of sense.”
Wysopal’s one critique relates to how software developers attest to conforming with secure software practices. “The thing that I didn’t quite like about it was they seem to think that a lot of these attestations can be done sort of at the product line level or the company level and not at the very specific product you’re purchasing.”
“A lot of times when a new product is launched, or a small vendor is acquired, and it gets rebranded and included in that company’s products, those products don’t have nearly the rigor of the more mature products. I think that we don’t want to mix those two things.”
Copyright © 2022 IDG Communications, Inc.
