As the pace of technology innovation races ever faster ahead, the notion of control system longevity is under pressure like never before.
Virtualization has in some cases helped to liberate users from the short lifecycles of the general-purpose computer hardware and operating systems upon which they run, allowing the application software—and the intellectual property investment it represents—to be carried forward. But sometimes, it’s the application software itself that proves vulnerable to the ravages of time. To learn more about the code-based risk factors that can shorten a control systems’ effective life, we sat down Trihedral Engineering.
Q: End users and machine builders spend a lot of money and effort tailoring what start out as relatively generic control system components, both hardware and software, into a system that fits their specific application requirements—and understandably, they want those investments to last. What sorts of things can go wrong?
A: Many risks to control system longevity can be traced back to early development decisions that prove to be unsupportable over the longer term. For example, choosing an automation platform that appears to offer unlimited flexibility may actually turn into a problem in later years. Don’t be seduced by claims that a software package “can do anything you dream of.” What that really means is a lot of custom-coding by you or your integrator to make things work as desired.
So, what happens when that code breaks down and the developer—your employee or your system integrator’s—left town six months ago to pursue a new opportunity? One thing you can be sure of is the documentation that goes along with that custom code will be lacking—if it exists at all. All that custom code should also give you pause before considering a release upgrade of the software or operating system, because that new release was developed with no consideration for your custom code. The upgrade will likely break it. So, you’re stuck limping along with the old version of the software, and can’t take advantage of any new features that come with that latest update or, for that matter, security fixes, leaving your system extremely vulnerable.
Choose automation software that has the functionality you need with a strong look towards the future, as well as established and tested drivers for the devices to which you’ll need to connect. In all cases, prioritize configuration over coding. Follow these guidelines, and when a responsible control system provider issues a new release of that software, the upgrade should be relatively uneventful.
Q: Doesn’t this sort of mindset limit one’s ability to take advantage of innovative new technologies, such as those represented by the IoT or Industrial IoT?
A: I think the answer to that question really goes back to a focus on functionality. If you’re talking about a SCADA, or supervisory control and data acquisition, software package, then you should expect focused, functional performance around reliably acquiring data, visualizing data and historicizing data. The providers of systems that are being used in critical infrastructure tend to have a continuous improvement mindset, and pack extremely useful, often highly innovative features in their solutions that provide an excellent level of flexibility.
This doesn’t preclude well defined interfaces with other innovative applications such as for advanced analytics—locally or in the cloud. But we’re talking about SCADA software, not predictive diagnostics. Sure, you should be able to make that data available to these sorts of systems, but rely on interoperable interfaces that can be readily maintained over time.
Q: Are there other things that users should be aware of when it comes to creating a control system that will stand the test of time?
A: In addition to the hazards of third-party custom code that I described earlier, there are little-understood hazards presented by third-party code that’s often embedded in the software that you’re purchasing. As software packages have become more complex, they often include open-source or licensed code from other developers.
This can be risky from several perspectives. First, embedded code may not have been submitted to the same level of testing and scrutiny that a responsible developer would apply to its own code. And when the supplier of your software has internal, third-party dependencies, they have no control over that ecosystem of software subsystems. What happens when that code goes south? Or its developer goes out of business?
Even scarier are the potential cybersecurity risks, such as were borne out in the Sunburst malware attack discovered late last year. In an attack attributed to Russian operatives, the malware was snuck into a third-party, embedded piece of software that was used by network management software provider SolarWinds. Then, using a signed software update to the company’s Orion network management software as its Trojan horse, the malware was welcomed into some 18,000 government and corporate clients’ networks. It had most of the year to make itself at home before it was first identified in December 2020 by cybersecurity firm FireEye, upon investigating suspicious activity around its own network’s two-factor authentication process.
The attack was particularly diabolical for a couple of reasons. First, by being inserted into a legitimate, digitally signed software upgrade, it easily cleared organizations’ defenses. Second, since it effectively became part-and-parcel of the network management software package, it could “hide in plain sight,” while probing all the various connected devices that the network management software was credentialed to manage. This meant it could—and likely has—spread laterally, establishing footholds in those connected assets and applications.
Q: Is there anything that users can do to protect themselves from this sort of development?
A: The clearest path to understanding how much third-party code is embedded in a piece of application software is to carefully read the license agreement before you blindly check the “I agree” box. Some packages include a lengthy list of software components from other providers and the licensing agreement essentially waives any responsibility for how these components behave, and whether they continue to be supported or not.
A control system that promises a long and useful life will be based on core software that is tightly controlled by a responsible provider. At Trihedral Engineering, for example, the code upon which our VTScada software is based is our own. Along with thorough, automated testing, multiple pairs of eyes scrutinize it before release. That’s why our customers’ applications developed even decades ago will always run on the latest version of our software. We call this ‘forward compatible for life.’ Reducing or eliminating third-party software code dependencies is the best way to minimize exposure to these sorts of risks.
Originally published in Control Global: https://www.controlglobal.com/articles/2021/how-to-keep-your-control-system-young