IF you’ve ever actually read the terms and conditions attendant with a software end-user license agreement before checking the “I agree” box, congratulations on your vigilance!
If you haven’t, you’re like most of us who quickly scroll down (only if we have to), check the box and get down to business. But if you do happen to read more carefully the next time you go to install a piece of industrial automation software, you might be surprised to find a long list of third-party software components—any one of which could go unlicensed or unsupported at any time. You’re also likely to learn that, if you check the box, the solution provider to whom you paid that not insignificant licensing fee assumes no responsibility—even if one of those dozens or hundreds of third-party software components goes belly up to a malware attack.
Welcome to the world of “buyer beware” software, which over the past several years has become increasingly problematic, says Pete Diffley, leader of global partnerships for industrial software provider VTScada by Trihedral. Control caught up with Diffley to learn more about how users can better manage the risks posed by embedded, third-party software components.
Senior Manager, Global Partnerships, Trihedral Engineering
Q: I understand that Trihedral’s VTScada development environment was recently certified to be in compliance with the IEC 62443-4-1 cybersecurity standard for industrial automation and control systems. Congratulations on the achievement—can you speak a bit to the nature and importance of this certification?
A: IEC 62443-4-1 applies specifically to work processes and development practices. Certification to the standard indicates that our practices are conducive to a secure development lifecycle, including security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life.
We cleared the audit pretty quickly in part because we’ve long employed processes designed to ensure the quality and security of our software releases. That means extensive testing to catch any issues before they go out to our users, including design reviews before coding begins, and coding reviews by someone other than the person who developed it.
Since our founding more than three decades ago, we’ve chosen not to take the easy road. For example, we don’t use third-party code, which can be troublesome because it’s not directly under our control. Plus, third-party code is typically not developed with the long lifecycle expectations of OT systems top of mind, nor with an appreciation for the potential impact of cybersecurity vulnerabilities in the critical infrastructure applications that we serve.
Now, we do securely integrate with applications that are outside VTScada’s core functionality, including reporting and analytics systems, and one experience in this realm provides a cautionary tale. It was a third-party application for doing voice-based alarm notifications over the telephone that at one point we looked at integrating into our platform. It had a more pleasant and less robotic voice than most of the alternatives, but suddenly the provider notified us that they’d no longer be licensing it. Soon afterwards, we realized our old voice software was now named Alexa. Now, just imagine if that software had been essential to a core functionality embedded deep within our product?
Q: A suspended licensing agreement is certainly one form of risk from embedded software components, but don’t cybersecurity breaches pose an even greater danger?
A: Certainly, and they’re just getting worse. Early last year, CSO Online reported that cyberattacks on open-source software supply chains, meaning open-source components embedded in commercial offerings—had increased by 430%. And that was before the Log4J vulnerability reported late last year upended IT and OT operations around the world.
Because Log4j is a Java-based library of open-source logging functionality that developers routinely embed within a larger piece of application software, its vulnerability has shined new light on the chronic need to better manage software development supply chains. A piece of application software may include several hundred third-, fourth- or fifth-party components. And just because a component with an identified vulnerability is present, it doesn’t mean that vulnerability is exploitable. Doing nothing may well be the best path forward, but how can you know for sure? It’s a cybersecurity management nightmare.
Q: Are there steps being taken to better manage this situation?
A: For a current product, it’s relatively straightforward to determine if a software application includes a component with an identified vulnerability. But what if your HMI software is even five years old? Most vendors are as blind as the asset owners as to what components are in which legacy applications. There are movements afoot to routinize the use of software bills of material (SBOM), which essentially list all software componentry embedded within a particular application version. It’s an important first step.
Players in the industrial software cybersecurity realm are also working to develop Vulnerability Exploitability eXchange (VEX) documents that complement SBOMs by adding a measure of risk assessment to the unfiltered list of vulnerabilities that the embedded software components represent.
But there's another alternative that sidesteps the issue altogether: choose a software package like Trihedral’s VTScada that doesn’t rely on third-party embedded components and provides mission-critical performance along with truly scalable architecture.
