Software cybersecurity labels face practical, cost challenges

As part of his extensive cybersecurity executive order issued in May, President Biden directed the National Institute of Standards and Technology (NIST) to develop two pilot labeling programs on the cybersecurity capabilities of internet-of-things (IoT) consumer devices and software development practices. Although these pilot programs won’t be mandatory for device or software sellers, they could likely raise market expectations. In addition, whatever labels come out of these programs would also carry with them some sense of government authority and might ultimately become part of the government contracting process.

Last week NIST held a two-day workshop on these topics. Of the two pilot programs, the consumer software labeling initiative is the trickier one given the ever-changing nature of software and the absence of any similar existing consumer software labeling initiative.

To help it grasp the more complex task of developing labels for software, NIST solicited one- to two-page labeling position papers from interested parties. In calling for these papers, NIST cited “the challenges and practical approaches to consumer software labeling,” asking` for feedback on the “technical criteria needed to support validation of consumer software security assertions that reflect a baseline level of secure practices.”

Challenges abound

Cost and feasibility are among the top challenges of creating consumer labels for software. Adding to these challenges is the fact that software is continually updated. Moreover, software comes in both open-source and proprietary formats and is created by a global ecosystem of firms that range from mom-and-pop shops all the way up to Silicon Valley software giants.

“It’s way too easy to create requirements that cannot be met in the real world,” David Wheeler, director of open source supply chain security at the Linux Foundation and leader of the Core Infrastructure Initiative Best Practices Badge program, said at the workshop. “A lot of open-source projects allow people to use them at no cost. There’s often no revenue stream. You have to spend a million dollars at an independent lab for an audit. [That] ignores the reality that for many projects, that’s an impractical burden.”

“Getting to something that’s doable is not going to be easy,” Steve B. Lipner, executive director of SAFECode, said during the workshop. “One thing I think is important is to have a crawl, walk, run mentality.”

A workable model

One model that exists today for enterprise customers is Veracode’s Verified Program. “We created something that the software vendors could do, and then be able to show a label to all their enterprise customers,” Veracode founder and CTO Chris Wysopal told the workshop attendees. Veracode’s labels consist of three tiers––standard, team and continuous—that have increasing testing levels and scrutiny on those results. “One of the lessons we learned is that there was actually some competitive pressure when one vendor in a niche category like robotic process automation got a Veracode label. They started using that in their marketing materials and their sales process. Their competitors also wanted to get labels, too, to reach parity.”

This kind of competitive impact of labels could be a critical factor in increasing the overall security posture for the entire software industry. “Even if nobody really uses it for purchasing decisions, the perception that they will use it for purchasing decisions and the transparency and promotion of these labels will drive more secure products,” Brian Glas, co-lead of OWASP’s Top Ten Web Application Security Risks, said at the workshop. “My hope is that the baseline progressively moves up over time as the general industry gets better and better.”

Not one and done

Another critical aspect of creating software labels is to ensure that they don’t reflect static points in time but are instead dynamic, taking into account the fluid nature of software. “It has to encompass the entire software assurance life cycle. It can’t just be that whatever the test results were, we’re one and done,” Glas said. “It’s not just the process, but it is the maturity of a process. I’d argue the only way to consistently produce products with a higher level of assurance is to have mature processes and architecture. Otherwise, whatever you had on a particular cycle of testing may have been an anomaly.”

Tony Rice, principal program manager lead at Microsoft, agreed that maturity levels are essential but warned that they shouldn’t be used to convey negative implications about the software providers. “We need to have a labeling program in place that allows for their various maturity levels without penalizing them,” he said at the workshop.

Another part of the complex challenge is the myriad ways consumers use software. “We need to inform the users of their actions, their configurations, their practices, and what that means within the context that they use it,” Rice said.

Cost is a significant factor

Cost is a significant factor that would likely dictate the failure or success of a software labeling program. “This is the Orange Book,” the Linux Foundation’s Wheeler said, holding up a copy of a now obsolete Department of Defense guide that specified criteria for rating the security of different security systems. “It’s got labels. It’s focused on security. It carefully defines the requirements. It was a massive failure in the end for a variety of reasons, but one of them was really excessive cost compared to the benefit.”

It all boils down to whether the money software providers spend on labels, mainly for third-party assessments or audits to achieve higher ratings, pays off in better marketplace performance, Wysopal tells CSO. “Do the vendor’s customers want to see that [higher] level? Are they going to shy away from the product and go to another product that has [a higher rating]? Because if you’re losing sales, then investing in achieving that level actually makes good business sense. In the long run, you’ll make more money.”

The order gives NIST a deadline of February 6, 2022, to work with the Federal Trade Commission and other government agencies to identify IoT cybersecurity criteria for the consumer labeling pilot program and secure software development practices and criteria for a consumer software labeling pilot program.