"Three may keep a secret, if two of them are dead" Benjamin Franklin

Author: Fred Steinhauser, OMICRON electronics GmbH, Austria

"Three may keep a secret, if two of them are dead" Benjamin Franklin

Behaving with extreme secrecy may not only protect crucial information, but also hide deficiencies. Keeping issues confidential may be a tactic to protect against possible embarrassments, but it keeps us from learning from each other.

At the beginning of the 2000s I attended a presentation about a protection incident at an IEEE PSRC meeting.
A protection malfunction had occurred that was caused by a design flaw. The flaw could possibly be considered as being silly and at that time I wondered why the presenter was disclosing these embarrassing facts.
At the 3rd Canadian Protection Symposium in December 2018, James Merlo from NERC talked about increasing the reliability of the grid. He also employed the example of how the airline industry has managed to improve safety, impressively bringing down the number of fatal accidents over the past decades, although the volume of air traffic has been growing strongly.

But there is an essential difference to what we experience in our industry: the investigation of air traffic incidents is conducted with great openness, so that everybody is able to learn from others' mistakes, and hopefylly prevent it from ever happening again. Investigators consider it as counterproductive when responsible persons are threatened with legal charges, because they may not tell the entire truth just to protect themselves.
Actually, the person presenting so openly at the PRSC meeting did us a great favor. We could learn from what he discovered and use this to avoid similar problems in the future. He shared the knowledge and others could improve their practice.

But I got the impression that it more often works the other way around in our field. It is so common to be told that essential information cannot be revealed, because it may be a risk to do so. This argument is even used in situations where access to relevant information is necessary to clarify an issue. When you are a provider of equipment you may be sometimes confronted with a complaint about an alleged deficiency of your product. Of course, you would like to trace this claim down by analyzing any evidence, but very often there are no substantial data provided.
In some cases, the claim collapses into a "I don't know" as soon you ask for further details, but just as often you may hear "I am not allowed to provide you this information." Might this just be a camouflaged form of "I don't know"? Anyway, you then end up with pointless guessing, just wasting time.

Making a secret out of too many issues became particularly common since we have the cyber security issue on the plate. There is no argument peculiar enough not to be used in this context.

One current paranoia is about revealing IP addresses. This may be dangerous!?
The addresses must be erased from drawings, blurred in photos, and of course you cannot get a configuration file containing them. Is it really a threat? Only if you assume that one can intrude into the network. But if you could do so, it would take little effort to find out about the addressing anyway.

And in many cases, you could just make an educated guess. The addresses will be most likely from the private ranges, not leaving too many choices to scan. But not getting the SCD file because of the confidential IP addresses in it leaves you little chance to analyze an IEC 61850 system properly. Seeing a threat in revealing IP addresses more shows a lack of confidence in the ability to prevent intrusions.
A system is secure because it is hardened against threats, obfuscation is not an accepted security strategy.

We need to exchange experiences and information to build best practices and to avoid everyone having to make the same mistakes and experiences all over again by themselves. This is a key factor for efficient work.
It is about sharing knowledge and learning from each other, not about blaming somebody.


Fred Steinhauser studied Electrical Engineering at the Vienna University of Technology, where he obtained his diploma in 1986 and received a Dr. of Technical Sciences in 1991.

In 1998 he joined OMICRON, where he worked on several aspects of testing power system protection. Since 2000 he worked as a product manager with a focus on power utility communication. Since 2014 he is responsible for Power Utility Communication business of OMICRON.

Fred Steinhauser is a member of WG10 in the TC57 of the IEC and contributes the standard IEC 61850. He is one of the main authors of the UCA Implementation Guideline for Sampled Values (9-2LE). As a member of CIGRÉ he is active within the scope of SC D2 and SC B5. He also contributed to the synchrophasor standards IEEE C37.118.1 and IEEE C37.118.