The time and expense of frequent patches are hitting every industry, but the process control industry has some interesting twists to the problem. For a long time many SCADA and DCS vendors did not support the current versions of the OS. It was common to identify workstations and servers running old, unpatched OS with known vulnerabilities because the process control application was incompatible with the current system. This problem still exists for some of the older legacy systems.

Another issue is the time it takes for a SCADA/DCS vendor to test the new patch with a wide variety of applications and customized deployments. The vendors are doing much better and providing a quick first opinion in days followed by a more thorough test in a week. The vendor testing is followed by end user testing. We are looking at a couple of weeks and some real expense to deal with a single patch.

We heard over and over that systems cannot be brought down for patching or rebooting - - they need to run 24×7 for years at a time. Well, there is a major flaw in this thinking. If a system is that critical and requires that level of availability, it should have redundancy. In many cases either the availability requirement is overstated or the required redundancy is not deployed because of the cost.

We see true 24×7 requirements all the time with SCADA control servers running in a failover or cluster mode, sometimes even with a backup control center. So it is possible to bring one system down; patch it; and reboot it if necessary. The system can then be switched over and repeated once the solution is considered stable.

I don’t want to pretend that frequent patching is acceptable, painless, or free. It is unfortunately a fact of life and requires a solution.