Why ISA-99/IEC 62443 is in Trouble

Before I reveal this e-mail I sent to the ISA-99 list, one should understand the discussion leading up to my rant.

The ISA-99 list had been trying to frame its discussion in terms of existing security standards. In my opinion, they’re making an enormous mistake.

Industrial control system security should not be pigeonholed in to the confines of a data-oriented standard. This is not about the data. This is about maintaining control in adverse circumstances. And yet most of the ISO/IEC frameworks are from the office IT side of the fence. What good can come by aligning Control Systems Security Standards in to that framework? NOTHING. Yet the presence of a standards alignment like this gives the office security people a false sense of authority and “understanding” so that they march on to a plant and promptly violate half a dozen carefully engineered systems because by golly they’re going to secure everything from everyone.

And so, here is my rant:

I am a potential end-user of this standard. In effect, I am the customer.

From my perspective, it does not matter who came up with what
framework. What matters is whether that framework has any reasonable
applicability to the problem at hand. Legalities and politics must be
secondary to preserving life. If you are not thinking in those terms
STOP. You have a moral duty to the public to get this right, and leave
the legalities and politics for others. Legislatures, and Courts of
Law should not design control systems. That is our job.

As such, this conversation is going about the standard exactly
backwards. Taking a top-down approach to security by selecting a
framework and then forcing the framework to fit on the problem is poor
practice. It will spawn numerous bad assumptions and paper chases that
serve no useful purpose. If this standard is not financially
practical, very few will use it --and the committee will have wasted
everyone's time while the safety of the industry and the public
remains at risk.

Above all, the world needs a security standard that does not get in
the way of availability. The goal for a security standard is to
improve availability and recovery time after an incident, not to be an
end in itself. I recommend that the participants in this conversation
reconsider their perspective: In other words are these frameworks a
reasonable, economical answer for most organizations? The ensuing
discussion should be about how well each framework matches the needs
of the industrial community, and leave the who invented what
discussion alone.

I apologize to anyone whose blood pressure went up while reading this.
Please do not take it personally.

Jacob Brodsky, PE

What are those bad assumptions? Well, one says that the system is ISO 27000 framework compliant, what will that Office Security manager think? He was “trained” in ISO 27000, so by golly he must understand these things, right? Would he know enough to handle an M2M link between PLC equipment? It’s just data. It can be backed up, right?

This is how bad things get started. Dear ISA-99: You started as a bottom-up approach. It was a good start. Now you’re going top down with people who I feel lack sufficient experience under a hard-hat.  The best outcome that could happen from that top-down approach is that hard-hat folk will see this standard and discard it because it doesn’t fix anything. What scares me more is if someone adopts it, implements it, and gets hurt. The setback from a failure like that will cause harm and continue causing difficulty getting real security in to control systems.

Security starts from the process and the people who manage it. It propagates up from there. It can not be imposed from the outside. We’ve been there and tried it. It doesn’t work. Instead the “experts” should help the people in hard-hats help themselves. (I put the term in quotes because this problem is so large that I don’t think anyone can truly say they understand the whole picture right now) As such, worrying about what frameworks to use for the standard is like trying to figure out what font to use for naming the Titanic. It doesn’t help all that much.


With more than 30 years experience at a large water/wastewater utility and extensive experience with control systems, substation design, SCADA, RF and microwave telecommunications, and work with various standards committees, Jake still feels like one of those proverbial blind men discovering an elephant. Jake is a Registered Professional Engineer of Control Systems in the State of Maryland.