It all depends on to whom you listen. I have discussed the security issue quite often. Hope that some people have listened to me. ;-)
These days you can see a lot of intensified discussions related to the use of DNP3 and especially the application at the control center (or master) side of the communication channel. One IED talks usually to one master station – but: One master station may talk to many many IEDs. DNP3 master stations are centralized components in SCADA systems used in many industries: power, gas, oil, water, waste water, … in general automation.
One of the crucial issues is that it seems quite easy to send a specific message from a control center (master) to the substation to put the slave (RTU) into a infinite loop condition (blocking further information sharing) or a spontaneous message from a substation to the control center to put the master into infinite a loop condition (blocking further information sharing). In both cases the devices must be shut down and restarted.
Click HERE to read one of the latest discussions.
I experienced recently the following: an IEC 61850 Server sent a report message with a value derived from a DataSet member of type FCDA to a client (in a gateway for a big control system, DCS). The client (client application) stopped working properly … just did not react anymore. As a result the client did not only “refuse” to work with this server – it also stopped communicating with other servers it was connected to.
Hm, by reporting just a value from a FCDA member (LN XX FC=ST DO=Pos DA=stVal) instead from a FCD member (LN XX FC=ST DO=Pos with three DA components: stVal, q and t) the client (client application) gives up to work … what a surprise. I was really surprised!
One solution to overcome this situation could be to require more conformance tests of clients (and servers!). That would help a lot.
BUT at the end of the day you may run into similar issues even if the client has been successfully conformance tested and certified: The clients and servers implementing IEC 61850 will support a subset of the features the standard defines. Independent of a certificate it would be more important to get a document that lists all the restrictions and specialties of a client or a server. If you know that a client crashes when you report a value from a FCDA member of a DataSet, then you could (at least) work around that problem by just configuring FCD members!
Figuring out that the use of a FCDA member causes a gateway to crash may take days of analysis and discussions … and is produces a lot of frustration before, during and after such a process.
Lesson learned: Clients, Server, Publisher and Subscriber have to come not only with a certificate but also with comprehensive documentation.
Dear Utility user: ask for sufficient documentation! We could help you to analyze the documentation to figure out …
1 comment:
Karlheinz,
You are absolutely correct. Fuzzing can find the kind of reliability bug you encounter as well.
Negative testing plays vital role in quality assurance, yet most ICS vendors are behind the times...
-Adam Crain
Post a Comment