Security is a very crucial issue in the power management and automation. There are standards and other specifications that help to “close” the automations, information and communication systems. Several blog posts discuss these issues.
In a discussion recently the problem with semantic names like “CircuitBreakerMainStreet” for process information (signals) was understood as crucial. Would such names make it easier for somebody to attack a system? Why should the problem be in the Name? If you keep the doors to your device or engineering system wide open – you should not be surprised if your system will be hacked and the infrastructure be damaged.
Is there really a difference (from a security point of view) if the identification is “CircuitBreakerMainStreet” or “Staus1829” or just “1829”? There would be an issue if somebody could retrieve the name from the device by a “too open” communication protocol. Even with IEC 61850 it should be prevented that everybody could just retrieve the self-description. Keep the door to the model closed … allow only the configuration engineer to access it. This would require to implement IEC 62351-8 (Role based access) or something similar.
The easiest access to the model (SCL file or any other configuration Excel Sheet) is likely hacking the engineering computer and download the corresponding configuration files – or to work at the engineering company and copy the files ... It does not matter what is communicated later at run-time, if you get the signal designation and the used identifiers in the protocol you can understand the bits on the wire. This applies to all protocols! DNP3, IEC 60870-5-104, Modbus, IEC 61850, CIM, … Profibus, ProfiNet, …
We have to keep an eye on the whole chain – not just look at the protocol and how signals are designated:
The main objective of the IEC 61850 based engineering process resulting in a comprehensive model description like a SCD File (System Configuration Description according to IEC 61850-6, SCL) is to get a system document that is consistent, has less errors and less omissions! Part of the SCD content can be retrieved by self description service of IEC 61850-8-1 – not.
Let’s now look at two persons that use such a comprehensive system document: first person is authorized person using the document and second person is UN-authorized person using the document. Let’s look at two use cases:
Case A: Provide and use “open”, comprehensive SCD File.
Case B: Use proprietary system configuration description.
… and discuss the situation:
| authorized person | UN-authorized person |
Case A | Can properly monitor and control the system because the operation is using a consistent and well documented system configuration. Needs to be maintained. | In the (hopeful very unlikely) event of gaining access to the system configuration it may harm the system. |
Case B | E.g., especially after some years in operation and after operators have been replaced by new staff, then it may be possible that the operators are not able to properly operate the system! | It is unlikely that the UN-authorized person can do a lot of harm. |
I believe that Case A is the preferred one that should be implemented: the possibility to properly operate the system by an authorized person outweighs the potential harm that can be done by an UN-authorized person.
One thing is for sure: Protect the system!! Don’t allow anybody to get on your network or systems, implement authentication, and many more …
What do you think? What is your experience? Are you aware of any analysis on this?
I would appreciate receiving your feedback – or you may just post a comment online.
Finally: One more detail on names:
Just a reminder: The IEC 61850 reporting messages and the GOOSE messages do not need to exchange these names like “CircuitBreakerMainStreet”. The content of these messages is specified by the corresponding DataSets. For Reporting see this blog post.
We have to focus on the WHOLE System!