Cyber security for electrical asset owners

Cyber security is a growing area of interest in the power industry - utilities and other MV/HV asset owners are all impacted.

Maroochydore, Stuxnet and Aurora are great examples of the issues involved.

A recent question about what the device vendors are doing to prevent "Aurora incidents" prompts me to collate various rants I have had about such things as below.

The first point is that in the "real world", an Aurora attack of a computer rapidly opening and closing the circuit breaker is is not as simple as just sending a bunch of commands.

In the case of generators, a synchronism check relay specifically only allows the CB close signal to get to the CB close coil if

1. The phase-to-neutral voltage magnitude is within tolerance of each other on each side of the open CB contact; and
2. The phase angle between the two voltages is less than the allowable variant; and
3. The slip frequency (i.e. the difference between the frequency on one side and the other) is less than the maximum allowable.

If those three conditions are met for the required duration of time, the close signal is connected to the CB close coil and the CB will close.
If they are not met, then the generator is out of synch with the grid and the CB is not allowed to close because the check sync contact in series with the CB close coil remains open… even if you hold the close button down manually or by repetitive computer command! 
That is the purpose of the sync check relay.

Sometimes an auto synchroniser is used to control the generator to adjust the three conditions to enable the closure … but that is not the same thing as a check synch relay which blocks the closure if the conditions are not met.

Especially on larger machines you would use both an auto synchroniser (instead of manual controls) and a sync check relay.  But a sync check is always the “right thing to have” on any size machine to prevent computer or operator error blowing up the generator.

Perhaps Wikipedia doesn’t describe things “accurately” but https://en.wikipedia.org/wiki/Aurora_Generator_Test says 
"The experiment used a computer program to rapidly open and close a diesel generator's circuit breakers out of phase from the rest of the grid and cause it to explode"

So something must have been done to override the block from the synch check relay, or there was no synch check relay at all, in order for closure “out of phase” even once.  (I also know of real-world generator explosion where the generator had been rewound with crossed phases but the only "control" on manual closing was the simple synchronising lights .. no synch check relay!)

However back to the vendor role in preventing "Aurora type incidenst ... or even Stuxnet, Maroochydore and others ....

In the "good old days" the Aurora cyber attack would not be possible because the sync check relays (e.g. the GEC SKE) had no comms so it could not be bypassed/adjusted/overridden from outside the substation.

SEL have a reference document which provides a variety of aspects about managing similar system cyber security.  In particular it indicates that with communicating IEDs, if someone has hacked in to the substation LAN, they may have got access to the relays so any sort of setting change (with or without hacker having “power system knowledge”) could have serious “Aurora consequences”, i.e. even if there is a sync check relay, it could be hacked too and made to "not work sufficiently correctly".

So could the under/overvoltage functions, under/overfrequency, or even the trip/close control devices be hacked? and settings changed? … just refer to Stuxnet.

So what can the IED vendor provide to at least help prevent Aurora type incidents …. regardless of type of relay function for generator, motor, transformer, busbar, reactive plant, overcurrent, earth fault, frequency, voltage, or even SCADA, condition monitoring, metering ….. or even the LAN devices themselves

Well, the first is obviously password protection … from the very first relays with menu based settings, e.g. GEC MiDOS K series in the late 1980’s, even though they initially had very basic comms over RS485 ("K-bus" protocol),  passwords have been available but I don’t think you needed a password over the comms (someone correct me?)
Great!
But that then requires the asset owner to set the password on every device to a non-default value and manage that password “knowledge” by some other secure means than a note on the back of the substation toilet door … ☺
That is a big impost on the asset owner.  Changing passwords on every new device (and repainting the toilet door  )

So even in those early days of communicating relays, many scoffed at the concept of passwords as it was very rare to have remote comms to the actual relay so to even be able to enter a password on the device you had to

1. jump the substation fence,
2. unlock the control room door (intruder alarm probably goes off at this point),
3. open one of the several relay cabinets doors,
4. unscrew the relay cover …

well, suffice to say as that is all getting a bit “silly” for the asset owners to consider as a credible threat needing to be urgently mitigated .. just increase the types and level of fence security.
Consequently I could almost guarantee that even today if I walked into most substations in most countries, I could enter the default  “AAAA” password into those type of relays and have access to change settings.

But along came IEEE 1686 2007  “IEEE Standard for Substation Intelligent Electronic Devices (IEDs) Cyber Security Capabilities”
(note LONG before Stuxnet and three years after IEC 61850)
This is basically all about Role Based Access Control
I believe it is currently being updated

Section 5.1:  
All electronic access to the IED, whether locally through a control panel, locally through a communication/diagnostic port with a test set or personal computer, or remotely through communications media, shall be protected by unique user ID and password combinations. It shall not be possible to gain access to the device without a proper ID/password combination that has been generated by the user.

Note the word “SHALL”
Also note it applies to operators standing in front of the relay and pressing the keypad or needing access via the comms port(s)
It then goes on to state

• there shall be no undisclosed means to defeat the password e.g. a master password (don’t lose passwords or you might have to buy a new device) … but if it is disclosed, others who shouldn’t have it could find it …!!
• There are a minimum of 10 unique User/password combinations
• Rules about the password form
• There are seven role based actions
• Time outs
• …. And much more

Great!
I wonder how many asset owners specifications for systems and/or device procurement (directly or via the system contractors) demand IEEE 1686 compliance ... or is it just "assumed"
But that then also requires the asset owner to

• set the password on every device to a non-default value,
• have a Role Based policy and
• manage that user/password “knowledge” … especially when Users come and go

Gasp!

But lest go back to IEC 61850 - perhaps the most significant change to the engineering process ... EVER!!  The Standard is a vendor-agnostic engineering process to configure IEDs to communicate using combinations of three different protocols. 
You may be surprised to learn that IEC 61850 has no command process to set/change a password nor even enter a password to gain access.
User access control is outside of the remit of IEC 61850.
That does not mean that IEEE 1686 is not need or should not be used .. quite the opposite as it basically implies IEEE 1686 and other access controls need to be chosen.

In fact CIGRE Electra Magazine ELT_229_3 Dec 2006 ( https://e-cigre.org/ ) states:
7 Conclusions and Future Developments
The level of security of the older and most current SCADA systems is not enough for the present cyber situation.
To make things worse the new IEC-61850 standard has no provisions for security yet.
Because of its open network type communication, it also opens the system for cyber attacks.
This new communication standard is really dangerous if used in a network with a poor security design.
Because the protocol does no longer compartment the communication, it may loose control over the whole grid.
All older communication standards do not address security [either].

That CIGRE article would make every asset owner avoid IEC 61850 like the plague ...
What it is really saying is that cyber security is outside the remit of IEC 61850 (or any other IED coms protocol) and you have to "do your own thing to be secure"

IEC 61850-3 Edition 1 Ann A said
The SAS should implement security features that counter, within appropriate user and cost constraints, the following threats

• Denial of service -– this threat attempts to deliberately impede legitimate access. Therefore, appropriate counters should be determined on a system by system basis and are not subject to standardisation within the scope of this standard.
• Illegitimate use - –the attacker attempts to make use of the SAS system in an unauthorised way. The SAS system implementation should provide protections against illegitimate use. Access to the SAS system should be restricted by authorisation validation during association establishment at a minimum. This validation should occur at the application level of the SAS communication profile and should support the concept of association access privileges.

(sadly that Annex does not appear in Edition 2)

However IEC 61850  does have some mechanisms to identify when changes are made to the device either by the front keypad, via comms commands or even loading new config files - refer

• IEC 61850-7-4 Ed 2 Table B.1 – Relationship between Loc/Rem data objects and control authority
• IEC 61850-7-3 Ed 2 Anenx C - Tracking of configuration revisions

But they require the asset owner to specify that any change to those values is reported over the comms system, and the system integrator implement it and the control room operators knowing what they should do when that alarm is raised

... Gasp!

CIGRE does provide a bunch of Technical Brochures discussing cyber security (available for free to anyone after three years ), and more in preparation
https://e-cigre.org/
Select Type = “Brochure”,
Select Year and click the “In” radio button

• 317 (2007) “Security For Information Systems And Intranets In Electric Power Systems”
• 419 (2010) “Treatment of Information Security for Electric Power Utilities (EPUs)”
• 427 (2010) “The Impact of Implementing Cyber Security Requirements using IEC 61850”
• 603 (2014) “Application and Management of Cybersecurity Measures for Protection and Control”
• 615 (2015) “Security architecture principles for digital systems in Electric Power Utilities”
• New WGs in prep
• 2017: WG B5.66 “Cyber Security requirements for PACS and the Resilience of PAC Architectures”
• 2017: WG D2.46 “Cybersecurity future threats and impact on Electric Power Utility”

Enter the U.S. NERC CIP
Arguably a huge office "paper warfare" ....
But, in my humble opinion, the MOST onerous operational requirement is in these sections

• NERC CIP -003-3  R5 Identify Individuals who can authorise access ... arguably just a spreadsheet somewhere, but some controls about adding people to that list etc ... and issuing access information
• NERC CIP -003-3 R6, R6 requires a process of change control and config management for all vendor related changes to hardware and software as well as changes to IED configurations (by anyone)
• NERC CIP-004-6 Table R5 – Access Revocation ... Know who has access to what and be able to REVOKE THE INDIVIDUAL'S ACCESS WITHIN 24 HOURs!!!!

To note that these requirements applies to both operators standing in front of the device and using the keypad and any access via a comms port
Perhaps NERC CIP (go to gaol for non-compliance) does not fully apply as equivalents in your country (yet) ... but in a Court, you know it will be cited as "world's best practice" if a cyber incident occurs ... so don't ignore the principles!!!!

........ Gasp!!

So this is where solutions such as Siemens Rugegdcom Crossbow solution comes into its own (sorry to the other vendors who haven't bothered to tell me about theirs)
But that requires the asset owner to

1. buy a system to suit their IED asset base (a dx utility in AU identified that by 2025 they will have >0.8 MILLION IEDs on their network) as well as the total number of Users that need to have individual accounts in order to access a device
2. implement resilience options for when the remote coms links are failed as well as central server fail overs
3. establish RBAC policy
4. manage staff additions and removals

... that last one is significant itself as it is a department management and HR issue

I once did a straw poll of some 18 utilities at an industry meeting ... only one changed passwords at all, but even they had no procedure to identify the need to let alone change passwords/access when someone left the company ... and the Maroochydore incident in 2000 is a great example of what a lack of such process can lead to .  However theer are subsequent incident seven in the waste water and clean weater industry even 15 years later than Maroochydore!!!  Will asset owners ever learn???

........... Gasp!!!

Final consideration here is the physical system implementation

What remote comms paths are provided?  Leased telephone/broadband service lines? Private microwave radio? Private fibres?

Do assets now have some sort of wifi management tool? A heard of a story about a utility "showing a vendor the door" when they vendor was "chest beating" about their wifi access from his smart phone to pole top devices  ...

................... Gasp!!!!

Are you out of breath yet???

To summarise the answer to the original question about device vendor features to prevent Aurora type attacks ...

1. Vendors have a role to play in providing various measures within their devices.  I dare say most do.
2. However Asset Owners have a much bigger responsibility to specify all the necessary mechanisms to suit their systems .... and even more importantly ensure their Systems Integrators implement them and the Asset Owner manages the system, configurations, RBAC, User revocation and responds to the alarms !!!!!!!!

Contact Me

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

   Mobile + 61 419 845 253

Extra Notes: