Safety Instrumented Systems

Functional Security–Walking the Walk

When It Comes to Functional Security, How Do You Handle Security Updates?

Walt BoyesBy Walt Boyes, Editor in chief

Kent Mitchell's letter (See Listen to Software Vendors; Nuclear energy Is "Inhuman"?) talks about a practical issue in what I've taken to calling "functional security." That is, how do you handle security updates?  In the IT space, updates are pushed to devices automatically, usually in the evenings or weekends. If an update fails, come the next day or after the weekend on Monday, the IT department gets a plaintive call from an end user.

Now, let's look at the plant-floor space. Jake Brodsky, of the Washington Suburban Water Commission, tells several update horror stories, including the one where the HMI failed several months after the update, and the cause was traced to a bug in that update.

If automatic updates are pushed to all the devices on the plant floor, when do you do it? Most plants, especially process plants, operate 24/7. If you do updates and they fail, what are the consequences? Rebooting a controller or HMI in the middle of a production run might do some bad things. Really bad things.

This is only one example of the difference between IT security and functional security on the plant floor.
Mitchell asks Microsoft and the process control vendors to come up with a solution to the problem. But really, that's only one of the many solutions needed for real functional security.

If management doesn't enforce buy-in, the plant can have state-of-the-art technology, and it won't be any safer or more secure.

At bottom, functional safety and functional security are "lifestyle choices" for the plant. If the plant, and the enterprise management above it, don't buy into and enforce buy-in from everyone on the importance of safety and security, then the plant can have state-of-the-art safety integrated systems, alarm management and security installations, both network and physical, and it won't be any safer or more secure.

Then, too, there's the difference between compliance and security. Plant and enterprise management are big on compliance. See, for example, what the electrical utilities are trying to do for the NERC CIPS. However, compliance does not equal security—or added safety. Compliance simply means that management's lawyers have told it that it only has to do thus and so, and it will comply with the rules. So we have utilities re-classifying control centers as "control rooms," and saying that they aren't critical infrastructure—because it's just a room, right? Or, we have utilities saying that they have NO critical assets, because they have more than one plant or control system.

I'm not picking on the electric utilities because the same sort of thing goes on in nearly every industry unless management is sincere in its devotion to safety and security. It's just more obvious and blatant in the utility space right now.

And then there's the silo effect. A new white paper in our library by Federal Signal (Planning and Developing Effective Emergency Mass Notification Strategies for Hazardous Industrial Applications in the Post 9/11 Era.)talks about the need and benefit of interconnecting alarm, mustering, public notification and control systems during a disaster.

There's also a training and experience component. If the operators on duty have never seen a problem before, then, even if they've simulated it, it isn't likely that they'll come up with the right solution out of the box. "Ninety days on the night shift" with some simulator training thrown in isn't enough to make up for years of operator experience.

So functional safety and functional security are all interactive with process operation, alarm management, operator training and lots of other components.

Fundamentally, the issue is how to make all these things actually work. From upgrades to monitoring the fence line, we have to make this stuff is as automatic as streetlights, or we won't be any safer or any more secure.