US Cybersecurity Strategy Shifts Liability Issues to Vendors

See Also: OnDemand | Navigating the Difficulties of Patching OT

The Biden administration’s National Cybersecurity Strategy released Thursday calls for shifting liability for software products and services to promote secure development practices. The liability is designed to shift to large companies that assemble software products and license them to the federal government. It will not affect developers of open-source applications, which are commonly used to build new software products.

“We can’t have them devolving that responsibility down to a two-person open-source project that hasn’t received any funding in the last five years,” according to a senior administration official. “That’s not going to get us the outcome that we want.”

In announcing the new strategy, officials said the liability shift will be a “long-term process,” potentially taking a decade to fully implement.

But cybersecurity industry insiders fear passing legislation that sets liability for software manufacturers will make them far less likely to share information with the U.S. government if one of their products has a highly exploited vulnerability (see: White House Unveils Biden’s National Cybersecurity Strategy).

“The threat of liability will always discourage transparency,” Proofpoint Executive Vice President of Cybersecurity Strategy Ryan Kalember tells Information Security Media Group. “I don’t think that there is a simple, straightforward, easy compromise here.”

Creating a Sturdy Liability Shield

The administration envisions that it will roll out more stringent software development practices, work with vendors to implement them in the software development process and then work with industry and Congress to establish a liability shield for companies that adopt those practices. That process will take well over a year, the senior administration official predicts.

Veracode founder and Chief Technology Officer Chris Wysopal says drawing from the NIST Secure Software Development Framework for the safe harbor law is more aspirational than realistic since the liability shield must consider a company’s maturity and security posture. Kalember says no current institutions are well positioned to assess compliance with NIST or assign blame after a security incident.

“We need a few different levels of what building safe software means,” Wysopal tells ISMG. “The SSDF is a good starting point, but I think it does need to be more practical and more basic.”

The safe harbor must both set high expectations for entrenched, incumbent software manufacturers while not inhibiting the ability of new startups to compete and get to market quickly with a new product, Wysopal says. He wants to see liability established for all software rather than just critical infrastructure software since attackers can strike critical targets through general-purpose software.

“We need to worry about lifting the bottom up a little bit to get to a reasonable level rather than just focusing on the software running in the water treatment facility,” Wysopal says.

What Belongs in a Safe Harbor?

Software development best practices have shifted over the past two to three years from being focused almost entirely around code security to broadly incorporating development processes and infrastructure, says Nurit Bielorai, Aqua Security’s go-to-market manager for software supply chain security. The NIST SSDF has gotten organizations to look beyond code and consider the integrity and provenance of their software.

“Organizations should pay a price for making their cloud services or their software less secure. But right now, they’re not paying that price.”


– Ryan Kalember, executive vice president of cybersecurity strategy, Proofpoint

As part of the safe harbor, Bielorai says organizations should have to validate at the end of the software development process that the output is what the company intended. He also says firms should have to provide a full security history of all components in their software regardless of whether those components were developed by the organization in question or taken from elsewhere.

“If I see that your product has gone through the right security process, I’m much more likely to pick this product than to pick a product that has a ton of vulnerabilities,” Bielorai tells ISMG. “It’s about allowing the software consumer to understand what they’re about to consume.”

Although Wysopal says universal adherence to NIST SSDF isn’t realistic, he believes basic application security testing and management of open-source risk should be part of any safe harbor. Automated static and dynamic testing of applications can uncover the most commonly exploited flaws, such as buffer overflows, remote command injection and SQL injection, according to Wysopal.

He also says organizations seeking a liability shield must understand what third-party libraries and versions of open-source software they use so they can react quickly if new vulnerabilities are found. Nearly every commercial software manufacturer does some degree of application security testing, but older products with declining customer bases are often neglected when it comes to security.

“Everyone’s doing a little bit of this somewhere,” Wysopal says. “But is it being done consistently throughout all the products from a particular vendor? Someone who’s buying a 10-year-old product, paying money for it and installing it, shouldn’t be put at huge risk just because the vendor thinks, ‘Oh, well, we didn’t secure it 10 years ago. It’s too expensive to try to secure it now.'”

Alternatives to Making Manufacturers Liable

Although Proofpoint’s Kalember isn’t overly optimistic about finding a way to establish liability for commercial manufacturers without harming information sharing, he does believe software makers need more incentive to produce secure products since the market hasn’t really punished companies such as Fortinet, VMware and Microsoft for their vulnerabilities that were exploited on a massive scale.

“Organizations should pay a price for making their cloud services or their software less secure,” Kalember says. “But right now, they’re not paying that price. Until they’re incentivized to do that, you’re not going to get inarguably useful controls enabled by default.”

Kalember supports the Biden administration’s effort to stop vendors from disclaiming liability through an end-user licensing agreement that no one actually reads. He also says software manufacturers should have economic incentives to implement by default strong security features such as multifactor authentication, turned-off federation features, and basic checks for malware when hosting files.

“We should be able to agree on all of these – even if they do introduce a little bit of cost – as the price of being on the internet and being a software company that’s able to sell to the world’s biggest market,” Kalember says. “The market power that we have in the U.S. might actually be used to do some good here.”