Government-mandated SBOMs to shed light on software supply chain security

0

President Biden’s Cyber ​​Security Executive Order (EO), released on May 12, is a sprawling and comprehensive document that aims to address weaknesses in the digital security ecosystem. It is dotted with nearly 50 actions the federal government must take under extraordinarily tight deadlines, signaling the urgency of the cybersecurity crisis facing the country.

Several parts of the OE seek to strengthen software security. This obscure and long-neglected topic has taken on new urgency in the wake of hacks in the SolarWinds and Microsoft Exchange software supply chain.

The first deadline for software security in OE, attributed primarily to the National Institute of Standards and Technology (NIST) of the Department of Commerce, is to publish a definition of what constitutes “critical software”, which in its turn. turn will trigger actions by other government agencies. The NIST deadline for producing this definition is June 26, which is why the agency organized a workshop June 2 and 3 in the presence of a thousand interested people.

Fifteen days after the release of NIST’s definition of critical software, another branch of the Commerce Department, the National Telecommunications and Information Administration (NTIA), will release “minimum elements” of something that has evolved over the past few years in the field of cybersecurity. , a software nomenclature or SBOM.

What is an SBOM?

An SBOM is “a rack of dependencies,” Allan Friedman, head of government SBOM activities and director of cybersecurity initiatives at NTIA, told the NIST workshop. “Basically, it’s not that complicated. It’s like, ‘Hey, this software that I have. What’s in it and what’s in it. [the components that make up the software]? ‘”

An SBOM is actually a nested ingredient list or inventory, a “formal record containing the details and supply chain relationships of the various components used in building software,” the OE says. The EO requires the NTIA to produce three proposed minimum elements that should go into any SBOM:

  • Data fields (such as vendor name, component name, component version, etc.)
  • Operational considerations (such as frequency of SBOM generation, depth of dependency tree, access to SBOM data, etc.)
  • Support for automation (ensuring that data can be produced at scale and consumed at scale using three different data formats already standardized, including three major file formats known as SPDX, CycloneDX and SWID).

The NTIA is also examining several related issues, such as how SaaS (software as a service) or cloud data can differ from on-premises software and how to think about more sophisticated supply chain threat models.

SBOM as software disinfectant

Security veteran Joshua Corman, a big supporter of SBOM and currently a visiting scholar at the Cybersecurity and Infrastructure Security Agency (CISA) of the Department of Homeland Security, Speak clearly at least three SBOM use cases before the House Oversight and Government Reform Committee subcommittee in October 2017.

  • A buyer could distinguish between good and bad software products at the time of purchase, which could ultimately and cumulatively drive potentially dangerous software products from the market if the “sunlight is the best disinfectant” theory holds.
  • When a new vulnerability is known, security professionals would be able to quickly determine if they are affected and where they are affected.
  • Businesses would be able to track the expiration of product support for software, as SBOM might be the only way to know that security updates for the product will no longer arrive.

For some security professionals, the SBOMs of a private sector organization could be a sign of the overall caliber of the organization. “This is a litmus test to figure out for myself what I’m getting myself into,” Sounil Yu, former chief security scientist at Bank of America and now CISO and head of research at JupiterOne, told CSO. . “Am I going into a situation where there is complete chaos and disorganization, or a completely archaic tech stack that would create dangers for me as an CISO that I’m going to have to face because the tech stack and the maturity of the organization is bad? “

Transparency could lead to greater trust

More fundamentally, SBOM experts say it’s about transparency, which leads to greater trust. “You don’t need trust if you have transparency,” Yu said. “You need trust because you don’t have transparency. If I can produce an SBOM for you, keep it updated regularly. , I am transparent, which further reduces your need to trust me. “

The transparency delivered by SBOM aligns with the repeated reference to “zero confidence” throughout the decree. “We take the concept of zero trust and apply it to suppliers,” Yu says. “It means if we start with zero trust, we have to offset that zero trust with transparency and that transparency comes from things like SBOM.”

The nomenclatures are not new

Although this is a relatively new concept in cybersecurity, BOMs have been a requirement of other industries for decades. American engineer, innovator and management specialist Edward Demings pioneered the BOM concept at Toyota in the 1940s. Lately, the medical industry has been building resilient technological supply chains using SBOM, with Philips Medical and Siemens Healthineers put SBOM theory into practice during the last years.

“Bills of material are the norm in all other industries,” Jennings Aske, senior vice president and CISO at New York-Presbyterian Hospital, told CSO. “Why not software? “

Simply exposing software ingredients would improve the safety and security of software products, although many organizations are likely to object to such exposure. “I compare it to car safety,” says Aske. “When Ralph Nader was pushing for seat belts, people thought, ‘well, they’re not necessary’, or ‘this is government overbreadth’ or ‘customers aren’t going to like it.’ And then companies like Volvo realized that it could actually be something they could use to sell their products, they could charge more.

“I think we should take SBOM as a concept, take things in the decree, make them national in all sectors of the industry and give people time to come into compliance with the possibility of creating SBOMs.” , Aske said.

NIST will take the minimum SBOM elements that NTIA produces and include them in preliminary baseline security guidelines for commercial software sold to the federal government around November 8. Within one year of the date of the order, the Federal Acquisition Regulation (FAR) Council will incorporate the guidelines into the contract language of all federal contractors.

What ripple effect will SBOM have?

The question then becomes: will the massive purchasing power of the federal government spill over into the creation of secure software products for the private sector? Private sector companies are likely to purchase many, if not most, of the same products as the federal government.

“There are only a limited number of companies that do business directly with the federal government, and they will obviously be directly affected,” Yu said. “The second-order effect, those companies that sell to these companies that sell to the federal government, is much more important. ” The third-order impact is probably close to 100%, Yu believes.

Aske says, “There’s going to be a ripple effect. It is not a training; it’s a workout. I can guarantee that we have suppliers that the government does not use. We have over 1,400 device manufacturers supplying our devices. There is going to be an overlap, but it will not be complete. “

Copyright © 2021 IDG Communications, Inc.

Share.

Leave A Reply