Not inherently!

Cyber Security of ANY Ethernet based system is a crucial requirement.

The question of course is what do we have to secure against and how to provide practical measures.

CIGRE references:  http://www.e-cigre.org/

• Technical Brochure 419 "Treatment of Information Security for Electric Power Utilities (EPUs)" - published 2010
• Technical Brochure 427 "The Impact of Implementing Cyber Security Requirements using IEC 61850" - published 2010
• WG B5.46 "Application and management of cyber security measures for Protection & Control systems" - started 2012

Other information below:

Is a GOOSE hackable/spoofable?

Yes.

Certainly what should be done as a consequence is the responsibility of the IED supplier and/or the Systems Integrator but some decision has to be made.

What would a hack/spoofed GOOSE look like?

The hacker though wanting to remain undetected would have to make sure they deal with providing both the StNum and SqNum as the right values – in any case, no more than 1 second later the non-spoofed GOOSE would arrive and so whatever the hacker has done with StNum and SqNum would result in the real GOOSE being seen as out of sequence and again a decision has to be made – admittedly a CB could well have been tripped within that 1 second gap when 8 spoofed PTRC.Tr values could have been received by XCBR but at least you’d know something was amiss from the logs.

If there was a successful hack and a spoofed GOOSE inserted into the LAN, what would the subscribing IED see?

StNum=7654, SqNum=654342

StNum=7654, SqNum=654343

StNum=7654, SqNum=654344

then the hacker would need to pick the right instant to send

StNum=7655, SqNum=0

StNum=7655, SqNum=1

Etc

Yes, in principle the receiving IED would have no option but to treat this GOOSE as valid if the hacker had got both values right.

Then eventually the real GOOSE arrives with

StNum=7654, SqNum=654345

Clearly though, ‘something’ is amiss and can at least be logged.

Can a GOOSE spoof be targeted for a critical change?

If the network can be hacked, the hacker can listen in on all the messages.  The hacker can easily recognise as a GOOSE frame and identify the Dataset.

The Dataset may have a 'payload' frame of “110001010100100101”

If the hacker wanted to trip the CB, which one of those bits is PTRC.Tr status, indeed if any?

The hacker might be able to work out which IED is the protection IED as the source but it may be sending several different GOOSE with different content, so which GOOSE has PTRC.Tr?
Ed2 now provides for the subscribing IEDs to be identified in the engineering process but this is a configuration of the IED, not a particular piece of information in the GOOSE itself so they have no knowledge of which IED is subscribing to which GOOSE.

The hacker could take a blind approach and just invert every one of the bits in every GOOSE but since one of those bits is the PTRC.Tr.q, the receiving XCBR would (hopefully in a good IED and/or Systems Integration) ignore the indication of a protection trip being sent as PTRC.Tr=1, perhaps even raise an alarm that the PTRC.Tr.q is no longer valid.
Further PTRC.Tr.q would be valid again (with PTRC.Tr=0) when the next real GOOSE arrives, then invalid at the next spoofed, then valid again at the next real GOOSE ….

Applying IEC 62351-6 is not the answer.

IEC 62351-6 was not written to apply to IEC 61850 GOOSE as far as inside the substation is concerned.

IEC 62351 cl 4.1 : "For applications using GOOSE and IEC 61850-9-2 and requiring 4 ms response times, multicast configurations and low CPU overhead, encryption is not recommended. Instead, the communication path selection process (e.g. the fact that GOOSE and SV are supposed to be restricted to a logical substation LAN shall be used to provide confidentiality for information exchanges."

It is impossible to apply IEC 62351 - 6 since it specifically is not intended to apply.

IEC 61850 90-1 does establish a new means to use GOOSE outside of the substation fence but clearly this was not part of the scope of consideration of development of IEC 62351-6 so that would be an incorrect application of IEC 62351-6 so I wouldn't be surprised if it didn't work - it is not the right solution in as much as using a vacuum cleaner to blow the leaves off your lawn – you might get some benefit but not all that you should using a leaf-blower to blow the problem onto the hated neighbour’s lawn ..

If a hacker is attempting to insert a false GOOSE into the substation LAN via the telecommunications bearer, the arrival of any GOOSE and SV via the substation external comms channel can in itself be a mechanism that can be used to detect cyber security threat.

If a GOOSE is intended between an IED WITHIN the substation and another IED WITHIN the substation, that GOOSE ID should NEVER arrive from the outside comms network - fairly obvious I would assume!! So the Systems Integrator can plan for that and provide security measures against it.

That leaves the GOOSE and SV that are intended to pass between two substations to be secured in another way so that they can less likely be tampered with in between.

So hacking and spoofing a GOOSE to do something nasty is not all that easy to start with, not impossible, but needs some knowledge.

Certainly the Systems Integrator has several mechanisms and opportunities to ENGINEER IN what is happening in the system.

As I said many times before – the SAS is a SYSTEM that should be specified and engineered AS A SYSTEM!

Extra Notes: