App nutrition labels? Hackers disagree on software bill of materials
LAS VEGAS—Imagine if software came with a complete list of ingredients. And instead of revealing whether an app contains a digital equivalent of gluten or peanuts, this list would indicate whether it’s vulnerable to hackers. Call it a software bill of materials.
Like complex dishes, modern apps, programs, and firmware heavily rely on a variety of ingredients, or pieces of software known as libraries potentially used for many purposes. Hundreds, and sometimes thousands, of smaller software components are joined together in a single package. And these ingredients can be combined in different ways to create completely different (and fully functioning) programs.
Security experts believe that a published, verifiable list of an app’s components and their known vulnerabilities could help organizations from private businesses to public hospitals stay safe from hackers.
At the Black Hat cybersecurity conference, which starts here Wednesday, a software bill of materials is expected to be a hot topic. Allan Friedman, director of cybersecurity initiatives at the U.S. Department of Commerce’s National Telecommunications and Information Administration, will be trying to get hackers to concoct a good recipe for a government-designed SBOM.
“What I would like to see is a practice or set of practices that organizations feel comfortable asking for, and we feel comfortable providing. Not a new regulation, but a norm that grows from specific corners of the marketplace,” Friedman told The Parallax at the BSides Las Vegas conference the day before Black Hat. “And as it becomes easier and more common, it will become more widely practiced.”
READ MORE ON SECURITY AND REGULATION
Hackers call for federal funding, regulation of software security
IoT regulation is coming, regardless of what Washington does
Time for a Department of the Internet of Things?
Why GDPR is good for security and the economy (opinion)
How updated privacy policies could make GDPR the global standard
On doctors’ orders, Israel plans a health care CERT
On July 19, at the first NTIA stakeholder-planning meeting for software component transparency, the U.S. government took its first major step toward creating SBOM standards. Cybersecurity experts from across the country gathered at the American Institute of Architects in Washington, D.C., to discuss the practical concerns: Which problems should SBOM standards tackle? How would generated data be shared? How could SBOM standards change current software vulnerability disclosure standards?
The answers could have a wide-ranging impact on all manner of Internet of Things devices, from consumer gadgets to industrial machines, including critical infrastructure. They might even help prevent (or at least mitigate the spread of) widespread digital disasters like WannaCry.
Although software vendors are not currently required by U.S. law to disclose vulnerabilities, many readily let their customers know which vulnerabilities they are patching when pushing out updates. But the design, testing, delivery, and installation of security patches is no simple task—and it’s especially complicated for medical or critical-infrastructure hardware.
Even when a patch has been made available by the software vendor, service contracts or device limitations may prevent it from being installed.
Hackers are divided on the prospects of SBOM standards. Some say they could reduce many patching obstacles. Others worry that they could do more harm than good.
Without clear parameters, limitations, and pathways for implementing recommended changes, SBOM standards could wind up being just another regulation without teeth, argues Katie Moussouris, CEO and founder of Luta Security, and a software vulnerability expert.
At the NTIA meeting in July, Moussouris said only with careful nuance in their application could SBOM standards help address the exposure of known vulnerabilities and adequately pressure vendors to make security patches available. Without appropriate measures, they could lead consumers to believe that a device is secure when it isn’t, she said.
At the BSides conference, she added that without prioritization, a list of vulnerabilities could overwhelm vendors too.
“What this will become is not just a list of known vulnerable [software] versions, but known mitigations, and this very quickly grows beyond the point of organizations to keep track of it,” she said. “We have wormable issues for vulnerabilities that came out in the last Patch Tuesday. It’s hard enough keeping up with the current Patch Jones.”
Research supports those concerns. A report from security company CA Veracode shows that about 30 percent of publicly known security vulnerabilities have yet to make it into the National Vulnerability Database, a repository for known cybersecurity vulnerabilities—but also have no known way to be exploited by hackers. And it can take almost three years from when a vulnerability is introduced into open-source software to when it becomes publicly known, security company Snyk reported in 2017.
That’s a major concern, as open-source software now makes up the majority of components that go into commercial software.
Listing the handful of commercial-software licenses—one potential way of creating SBOM standards—is vastly different from listing the 100,000 or more software components (and version numbers) that can go into open-source software, argues Parallax contributor Rob Graham, CEO of Errata Security. And it doesn’t address issues regarding devices running on software that is no longer supported, either.
“This sort of information is far too granular to even get close to being trackable with SWIDs [software ID tags],” he said at the July meeting, citing the Shellshock vulnerability as an example of a major security vulnerability in software that may escape SBOM exposure. “No amount of SBOMs would tell you whether you are vulnerable to the [Shellshock] bug or not, because that information was never tracked at a level that you are talking about,” Graham told the task force.
“We have wormable issues for vulnerabilities that came out in the last Patch Tuesday. It’s hard enough keeping up with the current Patch Jones.”—Katie Moussouris, CEO, Luta Security
Friedman’s effort at the NTIA is part of a larger regulatory movement within organizations and the U.S. government. In a November 2017 letter, House Energy and Commerce Committee Chairman Greg Walden (R-Ore.) asked the Department of Health and Human Services to create SBOM standards for medical technology, citing ongoing cyberattacks including WannaCry, NotPetya, and other ransomware attacks against hospitals.
“Stakeholders do not know, and often have no way of knowing, exactly what software or hardware exist within the technologies on which they rely to provide vital medical care,” Walden wrote. “This lack of visibility directly affects the ability of these stakeholders to assess their levels of risk and adjust their strategies appropriately.”
Many organizations already use private SBOMs, Josh Corman, chief security officer at global software company PTC and co-founder of the software standards organization I Am the Cavalry, said at the July meeting.
Corman noted that as the CSO for PTC, he already has to provide SBOMs for PTC’s clients in medicine, fuel, and critical infrastructure—and he’s not the only one. Standardizing and publishing SBOMs could streamline tasks for people like him.
An ingredients list is “on all the food we eat; it’s in every car you buy. This is a common practice for manufacturing,” he said, though adopting a common practice wouldn’t necessarily be easy for anyone, including him. “I have to eat my own dog food here.”
Despite the voiced concerns and challenges, support seems to be growing for standardized SBOMs. Representatives of Siemens Healthineers, Bank of America, NewYork-Presbyterian Hospital, and HHS itself are speaking in favor of SBOMs.
“We really see SBOM as an important patient safety matter,” Jennings Aske, vice president and chief information security officer of NewYork-Presbyterian, told the NTIA task force. “In looking at my organization’s security posture, where I see the greatest risk right now is with software.”
Others, including Oracle, support a more measured approach.
“There are some legitimate challenge areas, but many of the provably false objections distract from them… I wish the intellect and energy in the debate were focused on solving those real, but tractable, challenges.”—Josh Corman, CSO, PTC
“If we cause people to patch too frequently because they see daily fixes going out, what we will find out is that those groups will stop applying fixes, and will pick and choose, and they never do a good job at picking and choosing,” Bruce Lowenthal, senior director of Oracle Security Alerts Group, told the task force.
Ultimately, Corman says, the already growing adoption of software bills of materials proves a point that he made in his opening remarks at the task force: Opposition is geared toward spreading fear, uncertainty, and doubt.
“There are some legitimate challenge areas, but many of the provably false objections distract from them,” Corman told The Parallax at BSides. “I wish the intellect and energy in the debate were focused on solving those real, but tractable, challenges.”
Following the July 19 meeting, Friedman says, the NTIA Software Transparency Group has created four working groups to respectively focus on determining the goals of SBOM standards and their implementation; identifying current and future use cases; determining which standards are reasonable to adopt and mandate for software vendors; and creating a proof-of-concept based around medical security that relies on input from health care groups and medical-device manufacturers.
The task force is scheduled to tackle which ingredients should go into the software bill of materials again in September.