What No Security Standard Addresses

In Dale Peterson’s recent blog, he notes that FISMA/NIST 800 aren’t very effective.

It got me thinking what good these standards actually do here in the US, and in Britan (where they’ve had the CPNI standards for a while). I am beginning to get the feeling that this effort is very much like those notorious ISO 9000 series of standards for quality.

If you understand what good quality is, you do not need a standard to tell you how to do it.  If you do not understand or care to build quality in to your product, ISO-9000 is not going to help.  Following the ISO-9000 standards will probably result in making consistent products. If they were good quality widgets to begin with, congratulations, you have just documented how to make a good widget.  If those widgets were garbage they will be consistent, well documented  garbage.

Security is a lot like that.  To make matters worse there are already so many standards that I do not know where I will find the patience to read them all.  With the new standards emerging in Europe I am quite overwhelmed  (hat tip Dale Peterson, Ragnar Schierholz, and Ralph Langner). Overwhelming end users  is not good. Everyone needs to know why the security standards are there and why they matter.  Once they know that they’re responsible for a certain level of security, they need to take them seriously.  I get the impression that very few organizations have taken security to that level.

I think the problem is a certain check-box mentality.  It starts with the procurement guidelines. People check the boxes that specify security features in a SCADA system and they may even get a secure-able product. They may do security assessments. However, once they realize their vulnerabilities, many may decide to remove the need for the security instead of addressing the vulnerability.  The classic example of this is where electric utilities removed black start capabilities from their generation facilities so that they wouldn’t be rated “critical.” And when these systems finally see use in the field, the security attitude is so poor that this is all a wasted effort.

The check-box mentality is something encouraged by lawyers and accountants of large organizations. What those people realize is that although the standards define performance and features, they do not confer responsibility. Basically, since everyone is responsible for security, nobody is. That is why I have doubts that Mike Assante’s letter I cited above was effective. That is why these security efforts will continue to fall flat on the floor for some time to come.

What is needed is vigilance on behalf of regulations and governance to assign responsibility for the safety and security of a company with the executives who run it.  The next time a widespread power outage occurs, we need governments demanding hard answers from utility executives as to why and how their measures didn’t work.

Today, SCADA and control systems are capable of recording data with surprising detail and improved integrity. Just to be certain of the quality of the data, we ought to legislate a certain degree of self integrity monitoring for a SCADA system of a given size.  This would be similar to defining the performance and backup systems for ships at sea (for example, bilge water handling, how many lifeboats, etc) or the “black box” data recorders in airliners.  The goal is to have an authoritative record of what happened so that we can assign responsibility to certain key individuals in the industry.

The captain of a ship is responsible for the ship, cargo, passengers, and crew, no matter what happens.  Some ship captains are celebrated, some are reviled.  However, we recognize the mantle of responsibility.  No similar mantle of responsibility exists for industry.

It should.

Safe Creative #1007086770321

Leave a Reply

You must be logged in to post a comment.