President Biden’s wide-ranging cybersecurity executive order (EO) issued in May aims to improve software security through a series of guidelines. As the EO directed, the National Institute of Standards and Technology (NIST) has produced a definition of what constitutes “critical software,” published guidance on security measures for EO-critical software use, and released guidelines on vendors’ source-code testing. On November 8, NIST published preliminary guidelines for enhancing software supply chain security.
NIST recently held a workshop to discuss the guidelines’ provisions, which are due in final form by February 6, 2022. The EO asks NIST to produce its software supply chain security guidelines according to ten criteria, including secure software development environments; the generation of “artifacts,” which can contain a host of information about how the software was developed; the provenance or origin of software code and components; software bills of materials (SBOMs); vulnerability disclosure programs; and attestation to conformity with secure software development practices.
The workshop gathered experts to share their insights on some of the components currently contemplated for the final supply chain security guidelines.
Secure software development should be flexible and customizable
NIST has updated a white paper regarding its Secure Software Development Framework in a new document, SP 800-218. This new document contains “a core set of high-level secure software development practices that can be integrated into each SDLC [software development lifecycle] implementation.”
This document aims to provide “something that’s flexible, customizable and selective” that can be used by anybody, Karen Scarfone of Scarfone Cybersecurity told the attendees. NIST designed SP 800-218 to give developers structure across four practice groups:
- Preparing the organization
- Protecting the software from tampering and unauthorized access
- Producing well-secured software
- Responding to vulnerabilities
Artifacts should end the “find and fix” security mindset
Warren Merkel, chief of standards services at NIST, walked through the attestation requirement of the EO, noting that attestations tell customers, the marketplace, or any interested organization whether specific software performance or conformity assessment requirements have been completed. Several standards are available for these conformity assessments from the International Organization for Standardization’s Committee on Conformity Assessment (CASCO).
Regarding software artifacts, Rohit Sethi, CEO of Security Compass, said that organizations should aim for artifacts to end the “find and fix” security mindset when it comes to vulnerabilities. Moreover, artifacts “need to be understood by non-experts. We need non-security experts to look at something and be able to know whether or not there is adequate security coverage in the thing that they are buying.”
The definition of artifacts varies widely, but Matt Fussa, trust strategy officer at Cisco, offered his version: Artifacts are evidence that demonstrates an organization is following a documented process or meeting a requirement. They should be gathered and archived throughout the system development lifecycle and used as evidence in internal or external audits and assessments.
“If you think of the basics, it’s about having the right process, policies, procedures and technology in place to create that secure build environment and then develop, for the purpose of delivering assurance, all the artifacts that can show a customer, any vendor or any the software developer is doing the right things to create that secure environment around the development process,” Fussa said.
A software supply chain is a journey
When it comes to code provenance, the goal is to provide cryptographically verifiable information for every step in the supply chain, “going from an artifact all the way back to the keyboard the code was written on and the machines the code was built on,” Dan Lorenc, co-founder, and CEO of Chainguard said.
Kurt Samuelson, principal, group program manager at Microsoft, walked through the Supply Chain Integrity Model that Microsoft developed, which deals with provenance, SBOMs and attestations. Microsoft’s model serves two primary purposes: policy enforcement through the supply chain and collecting evidence of this enforcement throughout the pipeline.
“Supply chain is a journey,” Samuelson said. “It’s not something that you do once and you’re done. As we continue to find new supply chain vulnerabilities, we will add new capabilities. The build system for us is something that produces changes or manages the chain of custody for the official bits that get sent to a customer or get put into production.”
Vulnerability disclosure starts with security engineering
Katie Moussouris, founder and CEO of Luta Security and the author of two vulnerability disclosure processes, ISO 29147 and 30111, explained that while penetration testing and bug bounties are terms that are often used interchangeably with vulnerability disclosure, all three practices are different. Moreover, pen testing and bug bounty programs are the least important part of vulnerability disclosure.
“The bulk of software security processes should be in security engineering processes and where the bulk of all software security assurance processes should be in terms of resources,” Moussouris said. “Ideally, we are not trying to fix the same vulnerabilities in the same classes over and over again. Instead, you are incorporating every single vulnerability that you missed as part of your secure development lifecycle. Every vulnerability that comes through a vuln disclosure program is one that you missed in your earlier engineering efforts. Those are opportunities for learning and improving your software engineering security processes.”
Treat the federal government as a big corporation for vulnerability disclosure
Kim Schaffer, IT infosec specialist at NIST, recapped the recommendations from NIST for applying its initial draft of its vulnerability disclosure guidelines (SP 800-216) over to the federal government. NIST developed those guidelines following the enactment of the IoT Cybersecurity Improvement Act of 2020, which applies Moussouris’s ISO 29147 and 30111 to the federal government. These guidelines are slated to become final in June 2022
“The federal government can be looked at basically as a large corporation. There are all kinds of business enterprises going on,” Schaffer said. “I would hazard a guess that the Department of Defense has all kinds of different reporting structures going on from the Department of Commerce.”
Like any large corporation, the government still needs central reporting requirements. So NIST has identified two bodies that will be central for getting vulnerability reports, handling them, and giving feedback to the users as they need it. The first is the more centralized Federal Coordination Body (FCB). The second is the Vulnerability Disclosure Program Office (VPDO), more closely tied to the relevant service security office and agency.
Copyright © 2021 IDG Communications, Inc.
