more on Wurldtech and exida...what does it mean?

March 17, 2009

I said yesterday that I'd blog further on why this agreement between Wurldtech and exida is important.

I said yesterday that I'd blog further on why this agreement between Wurldtech and exida is important.

Both functional safety and what I've taken to calling "functional security" have been developed separately and essentially in their own vacuums. What Wurldtech and exida have done is to break down the silos and enforce synergy. This is important. What is yet missing is the part about culture change and training and work practices that have to change to create a culture of functional safety and functional security. Only then will we have safe and secure manufacturing plants and infrastructure.

Here's a large excerpt from my upcoming April editorial that tries to explain what I'm talking about.

How Safe is Safe? How Secure is Secure?

This is a six-sided tale. Safety. Security. Compliance. Engineering. Finance. Legal.

As I said we would be, in my keynote speech last year at the TÜV Rheinland Safety Symposium, we’re beginning to see a convergence between the disciplines of functional safety and control system cybersecurity. It isn’t hard to see why. Both disciplines focus on the behavior of complex systems. Both disciplines are based on risk management. Both disciplines require continuing engineering analysis and management.

Since both disciplines are about managing risk to acceptable levels we can easily see that ultimate safety isn’t a viable goal. Nor is ultimate security a viable goal. We need as much safety as we must have to eliminate or dramatically reduce the incidence of accidents in the plant. We need as much security as we must have to eliminate or dramatically reduce the incidence of cyber intrusion into the control and SCADA systems we operate. But we don’t want to be hampered in operating the plant by either safety or security regulations and enforcement. So, we want just enough, but not too much of either safety or security.

There’s the engineering side of risk management, and then there’s the financial side. The financial side says, we can have less safety and security than the engineers want by insuring against accidents and intrusions. That way, company profits stay protected, but company personnel and assets sometimes do not.
 
When, as is beginning to happen now, governments begin making regulations about either safety or cybersecurity, we find the legal side of risk management rearing its head.

While the engineers want enough safety and security to prevent accidents but not hamper production, and the beancounters want as little safety and security as they have to pay for, the lawyers want none of those things. Their job is to keep the company from being sued, and the way they do that is by instituting a risk management vehicle called compliance.

As far as the lawyers are concerned, the company only has to do as little as possible toward functional safety or cybersecurity as they can, and be in compliance with the regulations.

In the power industry in the US, we have the NERC CIPs…and people insisting that their cyber security practices which are manifestly unsafe to the engineers, and way too costly already to the beancounters, are just fine because they are in compliance.

We are seeing this attitude spread to the water and wastewater utilities, and to some extent to the transportation sector and some of the chemical, pharmaceutical and food industries, because they are used to regulation, and compliance to regulations.

None of this, however, is making our infrastructure any safer or more cyber secure.
We must continue to focus on the idea that safety is about preserving safely people and processes and assets, not hedging with insurance policies to cover drastically unsafe practices. We must continue to focus on the idea that security is about the ability of our systems to withstand assaults from without, disaffected employees from within, and simple accidents.

I can just hear the CEO trying to explain to the Sarbanes-Oxley folks, “Well, we were in compliance. It isn’t our fault that the terrorists’ cyber attack killed our functional safety system and blew up our plant. We were in compliance!”

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.