Aurora and the electric industry's lack of adequate response

Aug. 6, 2012

Aurora is a gap in protection of the electric grid. This concern of starting rotating electric equipment out-of-phase has been known for many years - it is a basic tenet of electrical engineering. However, until the Idaho National Laboratory (INL) demonstration test in 2007, it was not expected someone would purposefully create an out-of-synchronous condition via malicious insider attack or cyber attack. It is a physical problem that can be exacerbated by cyber means. It is not a virus or worm and therefore cannot be patched.

Aurora is a gap in protection of the electric grid. This concern of starting rotating electric equipment out-of-phase has been known for many years - it is a basic tenet of electrical engineering. However, until the Idaho National Laboratory (INL) demonstration test in 2007, it was not expected someone would purposefully create an out-of-synchronous condition via malicious insider attack or cyber attack. It is a physical problem that can be exacerbated by cyber means. It is not a virus or worm and therefore cannot be patched. It can be initiated from locations that may or not be under the control of the affected transmission or distribution provider. Aurora can affect rotating equipment used in Alternating Current (AC) operation including generators, motors, transformers, etc. The Aurora vulnerability is not visible to the operator. An attacker can keep "hitting" equipment until there is minimal life left or the equipment actually breaks (e.g., the diesel generator at the INL demonstration). This is effectively the Physical Persistent Vulnerability for cyber-physical systems.

CNN ran a brief news article on Aurora in 2007. Even though some of the information on the CNN tape may be misleading, detailed information is still protected under the For Official Use Only (FOUO) caveat and is not readily available. What is industry to think? Just as questionable is the Department of Energy's (DOE's) absence from the Aurora test and subsequent follow-up activities. Why?

Since Aurora is a physical gap in protection it requires a hardware fix. There are at least two vendors with hardware fixes that have been demonstrated by test and validated by computer modeling. Yet of all the entities surveyed, none have implemented the mitigation (which is reasonably inexpensive). I have been part of a recent joint effort with a utility and DOD to perform an Aurora hardware implementation program. This utility felt it was important to do this project to maintain the reliability of their electric system and protect its customers. DOD is participating because these systems are used in DOD applications. Of all the utility customers I have met, none are aware that their serving utility has protected them from an Aurora event. In fact, most are not even aware that an Aurora event can affect them.

Why should people be concerned about Aurora or the apparent lack of utility industry effort to mitigate it? Beyond the 2007 Aurora demonstration at INL, in December 2009, a power plant in Iran had a catastrophic failure of its turbine and support equipment. From what can be seen, this may have been an Aurora event. Yet, industry continues to be slow to implement hardware mitigation or even specifically address Aurora. The recent NERC Cyber Attack Task Force report excluded Aurora (and for that matter Stuxnet); the NIST Cyber Security Working Group has not addressed Aurora in its Substation automation effort; Aurora was not addressed in last September's INL report on cyber security of transmission and distribution systems; etc.

Consequently, in order to inform the industry about what really happened with the INL test, correct misinformation, and provide a status of the utility hardware implementation program, there will be an Aurora session at the October ICS Cyber Security Conference (www.icscybersecurityconference.com).

Joe Weiss

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.