Why Do We Need IEC 61850 (SCL) Based System Configuration Descriptions?

IEC 61850 has been developed in the late 1990's mainly by protocol experts and protection engineers - results are well done and applied all-over. Later IEC 61850-6 (SCL - Substation System Configuration Language) was in the focus. Now, 30 years later the industry has learned that the System Configuration Description goes far beyond information models and communication networks and services - AND PROTOCOLS. The crucial aspect is about a COMPLETE description of the WHOLE system ... from device independent descriptions of Functions and Function Models applying a Top-Down-Modeling-Approach. Work towards this approach is going on in several projects, e.g., IEC 61850-90-30 (IEC 61850 90-30 – IEC 61850 Function Modeling in SCL). A nice description from Jörg Reuter (Helinks) can be found HERE from the pacworld magazine. IEC 61850 based aspects is - of course - just one (crucial) aspect of a system. There are more aspects ... like Hardware, Software, Cybersecurity, Operation, ...

In addition to getting a complete system specification based on SCL to get a running IEC 61850 based system that does the job you want to have ... there is another crucial aspect: Engineers may be happy to use a complete SCD file to configure everything and then forget the SCD file ... don't forget it BUT keep it up-to-date and NEVER EVER make any change in the system without updating the SCL based System Description! 

You may need the complete and updated SCD file to help you "protecting" yourself in case there is a damage or an accident ... when "a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after ..." may arrive immediately after ... as Jake Brodsky (a well known engineer) just published in an article about "Industrial Cybersecurity “Gatekeeping”" ... worth to read.

Here is one excerpt from his article: "Take the time to find out where the important documents are such as the Standard Operating Procedures, the chemical Safety Data Sheets, and especially the Control System Narrative documents are located. If you can’t find the control system narrative documents, stop. Get someone to agree to write them with you. This is effectively your contract with the engineers, technicians, and operators that indicates in plain language what is supposed to happen normally and in most upset conditions. If you’re operating without that living document you will all be fodder for a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after an accident."

What could be done to get and maintain such complete descriptions of various aspects of a system? Do we need more lawyers, politicians, engineers, ... ? 

I am kidding (just a bit): "Hire a lawyer to escort you when you have an interview for a new position as a responsible engineer in a utility or ... in order to figure out (by the right questions of the lawyer) that the company applies with what Jake Brodsky recommends!"

What we really need is more engineers ... gray-hair experts that know a lot about the systems ... that could write down what the systems do and how they work ... and that could train the young people ... BUT: it isn't easy to convince the management to let the engineers learn from the experienced, gray-hair experts ... gray-hair engineers could lead the horses to the water - but they cannot make to drink it. 

What do you think? Let me know!

The Cassandra Coefficient and ICS Cyper - Some Thoughts

Do you have a idea what "The Cassandra Coefficient" is all about and how it relates to ICS cyber security? Joe Weiss discusses the issues in a recent publication:

Cassandra coefficient and ICS cyber – is this why the system is broken

Brief extract from the publication:
Joe Weiss writes: " ... What I have found is that each time another IT cyber event occurs more attention goes to the IT at the expense of ICS cyber security. The other common theme is “wait until something big happens or something happens to me, then we can take action”. Because there are minimal ICS cyber forensics and appropriate training at the control system layer (not just the network), there are very few publicly documented ICS cyber cases. However, I have been able to document more than 950 actual cases resulting in more than 1,000 deaths and more than $50 Billion in direct damages. I was recently at a major end-user where I was to give a seminar. The evening before I had dinner with their OT cyber security expert who mentioned he had been involved in an actual malicious ICS cyber security event that affected their facilities. For various reasons the event was not documented. Consequently, everyone from the end-user, other that the OT cyber expert involved, were unaware of a major ICS cyber event that occurred in their own company. So much for information sharing."

My personal experience in this and in many other areas is: People tend to hide information instead of sharing information. I found many times that SCADA experts do not really talk to RTU people, substation automation or protection engineers ... and not at all to the people that are responsible for the communication infrastructure. Most engineers likely tend to focus on their (restricted) tasks and not looking at the SYSTEM and its lifetime. Am I contributing to solve the challenges to build a quite secure system - or am I part of the problem?

I repeat what I have said many times: Teamwork makes the dream work! Become a team player!

Click HERE for the publication.

This publication is worth to read ... some definition of what Cassandra Coefficient is could be found HERE.