What Is To Be Done?

We keep hearing from security researchers that software companies in the commercial, enterprise and automation spaces are venal and incompetent coders, who literally have to be whipped into complying with good software practices by humiliation—that is by publishing the vulnerabilities in their software.  We keep hearing from end users that this practice makes them even more vulnerable, and that’s demonstrably true too.

We also know that the software vendors often do not have the appropriate processes to handle bugs and vulnerabilities as quickly and proficiently as they should, or sometimes even as they would like. Especially in the process industries, DCS and SCADA vendors are accustomed to hearing from their users, not from outsiders who have found and documented a vulnerability, and these “outsider” messages come as a shock.

The security researchers have a point too when they deride “security by obscurity.” The very bad people who will try to attack critical infrastructure will likely already know the vulnerability and have exploited it by the time the vendor has created a patch. “Full disclosure is always good,” says Netragard LLC’s chief technology officer, Adriel T. Desautels, and he is not wrong.

The problem comes back to the end users. As Washington Suburban Sanitary District’s Jake Brodsky has pointed out, it takes many times longer to properly apply a patch in the field than it does to find the vulnerability or to create the patch. And sometimes, the patch doesn’t work even then. “What we have here, is a failure to communicate,” as the late, great Paul Newman grunted in the film, Cool Hand Luke.

The real object of all process control system security research is to protect the users of those software solutions and the general public from bugs and vulnerabilities that can be used to attack critical infrastructure and systems.
We’ve seen for years a round robin of finger-pointing between the cyber researchers, software vendors and system integrators, with the end users trapped in between. This cannot be allowed to go on.

So what are we to do?

First, we have to acknowledge that the security requirements of critical-infrastructure industries are different from those of the office, commercial and enterprise software space. We can learn from the way security vulnerabilities have been handled elsewhere, but we need to handle them in a slightly different way. Every implementation of DCS or SCADA software is different in a way no office software suite is.

Next we have to acknowledge that the national Computer Emergency Response Teams (CERTs) aren’t set up to handle the requirements of the critical infrastructure industries. There are just too many ways to slip up and not get the information to the people who need it most. Up to now, governmental involvement has meant secrecy too.

What we need is a global (and, therefore, non-governmental) CERT for the critical infrastructure industries, where vulnerability reporting is centralized, where end users and vendors alike can find assistance in identifying vulnerabilities and determining the size and status of the problem, and where patch testing can be done on systems before the end users have to take the risk of installing those patches and having systems go down. This organization should be funded by vendors, end users and governments, but we need to emphasize openness and public scrutiny, not secrecy, and no one group should have full control over the organization.

So who’s going to step up and create this Global Infrastructure Computer Emergency Response Team?