Industrial control systems: The holy grail of cyberwar RSS Feed

Industrial control systems: The holy grail of cyberwar

Industrial control systems (ICSs) are critical to the operation of a modern society. ICSs were designed to be reliable and safe, rather than cybersecure, and to ensure safe operations within specific known engineered states.

These systems carefully manage transitions to control risk between operational states that are defined to protect against random occurring failures of a component or a few components. However, focused cyberattacks such as Stuxnet or Aurora that can push a system into known dangerous states are not commonly expected in the normal operation of ICSs. This essay identifies a number of very critical issues that threat analysts, policymakers, and critical infrastructure protection personnel need to understand and address. That is, how cyber compromise of ICSs or physical system design features can cause physical damage to hardware and/or physical processes.

Hackers view exploits that can damage physical processes as the holy grail of cyberwarfare. Any device that can cause catastrophic damage through remote operation of cybercomponents could be a target for compromise. The more high risk components that can be compromised in an ICS, the greater the risk to the operator and value to the attacker.

ICSs are not designed to ensure resilience against concerted attacks that intend to place components in dangerous operating states. As ICS systems/components were designed prior to consideration of cyberthreats, securing these systems will be a growing area of cyberwarfare and engineering research.

Cyberincidents have been defined by the Presidential Decision Directive 41 issued in June 2016 to be electronic communications between systems that can impact confidentiality, integrity, and availability. As of July 2016, I have amassed a database of more than 800 actual ICS cyberincidents. Most of the incidents were not malicious and most were not identified as being cyber.

Malicious cyberattacks against ICSs have been relatively rare. One of the first known cases of a cyberattack against ICSs in the critical infrastructure was the cyberattack against the Maroochy wastewater system in Australia in 2000. This attack was by a disgruntled employee, not a nation-state. It demonstrated several key points that were used in later nation-state attacks. It was an attack directly against the control systems not the IT network. It was also done by a knowledgeable insider.” Finally, the attack was not immediately evident as being a cyberattack. Stuxnet and Aurora utilized these attributes.

Arguably the most famous ICS cyberattack was Stuxnet. Stuxnex was a sophisticated, nation-state cyberattack targeting the control systems in industrial infrastructure. Stuxnet bypassed the engineered protective components (control and safety systems) to execute unauthorized commands compromising the integrity of the system into a dangerous operational state. Stuxnet was not malware in the normal sense and therefore would not have been detected by IT defenses. The Stuxnet code consisted of controller-generic software, software specific to Siemens, and software specific to the target centrifuges. Consequently, the underlying infrastructure of Stuxnet can be applied to any industrial process compromising any ICS vendor. The attack damaged more than 1,000 centrifuges in Iran’s Natanz nuclear fuel enrichment plant. It was ongoing for more than a year with the attack being masked before it was identified as being cyber-related. That is, it appeared to be “normal” mechanical failures of the centrifuges not a cyberattack.

The electric engineering community has known for more than 100 years that connecting Alternating Current (AC) equipment out-of-phase with the electric grid can cause damage to the equipment. The Aurora vulnerability is the name for a class of electric system power line attacks that manipulate physical forces to do damage through manipulation of substation protective relays. It is also not malware and therefore would not be detected by IT defenses.

Until the March 2007 test at the Idaho National Laboratory (INL) named Aurora,” most people in industry felt that the out-of-phase condition could only be caused by accident not by malicious attacks. The INL Aurora test was an intentional cyberattack that destroyed a large diesel generator. The Aurora test was not a traditional hack, but a demonstration that cyberconditions could lead to physical equipment damage. In the case of the Aurora demonstration, the relays were opened and closed using cybermeans to exploit the physical gap in protection of the electric grid.

The Aurora vulnerability occurs when the substation protective relay devices (think of your fuses in your home circuit box) are opened and then reclosed out-of-phase (that is, the sine waves do not line-up) with the electric system. This out-of-phase condition results in physical damage to any Alternating Current (AC) rotating equipment such as generators and induction motors and potentially to transformers connected to the substation.

Because of concern about the damage that could be caused by this event, Aurora was initially classified by the Department of Homeland Security (DHS) as being “For Official Use Only.” With the exception of the CNN tape, the Aurora information was classified until July 2014. At that time, DHS mishandled a freedom of information request on Google Aurora (a different event but using the same “Aurora” name) declassifying more than 800 pages of the INL Aurora test. The mistake was important because the only way to prevent an Aurora attack is with specific hardware mitigation devices. However, the North American electric utilities have been very slow to employ the appropriate hardware protection making the DHS disclosure even more disconcerting. Recent studies have demonstrated that many protective relays can be hacked leading to potential Aurora or other significant grid disturbances.

In December 2015, the Ukrainian electric grid was cyberattacked and more than 230,000 customers lost power. The power outage was caused by remotely opening the protective relays – step 1 of Aurora. For reasons only the attackers can provide, the attackers chose not to reclose the relays (as in the Aurora case) which could have caused significant long-term damage to Ukraine’s electric grid and other critical infrastructures. The operation grid was restored within hours because the Ukrainian operators were still used to operating the grid in a manual manner. I don’t believe the same can be said of the North American electric system.

What’s unique about targeted ICS attacks?

The cyberattacker looks at the facility and its ICSs in a holistic way, identifying physical vulnerabilities of the controllers and the process and ways to exploit such vulnerabilities by digital manipulations. There are very few people with the expertise to understand the physical process being controlled, the control system domain with its unique design features, and the exploitation of IT vulnerabilities.

Traditional IT cyberattacks focus on Windows boxes using zero-day vulnerabilities (previously unknown vulnerabilities) or other IT flaws to capture valuable data (data breach) or cause a denial of service (loss of data). Targeted ICS attacks can be built on top of IT attacks but take aim at the physical process. Targeted ICS attacks such as Stuxnet and Aurora exploit the legitimate product or system design features. Additionally, IT is focused on Advanced Persistent Threats (APT) and traditional insider threats. Threats such as Stuxnet and Aurora are persistent design vulnerabilities that exploit features that are inherent in the design of the ICS and systems and cannot be corrected by installing a security patch.

Unfortunately, many ICS devices, including new ones, are still insecure by design and many legacy ICSs cannot implement IT security technologies. Yet the devices won’t be replaced because they still work. The culture gap that exists between the IT organization and the control system organizations exacerbate the physical threats in attempting to secure ICSs. I believe a major part of Stuxnet’s success was it was arguably the only instance where IT, control system, and physical security teams tightly coordinated to make the attack successful.

It is an unfortunate fact that this coordination still doesn’t happen (with very rare exceptions) when trying to protect ICSs.

The cascading effect of a compromised ICS

ICS are generally a system of systems. Consequently, the effect of a compromised ICS due to cyberattack or intrusion is not limited to the zone of equipment that the ICS is responsible to operate. ICSs and logic are designed to coordinate with other ICSs in the overall system operation. This coordination is necessary in order to insure that the ICSs react to the faults that occur in their zone. However, cases occur where other ICSs affect not only their zone of equipment when they operate but other zones of equipment controlled by other ICSs causing cascading effects.

Another aspect of ICSs is their connection to communication equipment that sends and receives information and commands to operate the ICSs. These communication devices are a part of a command operation system known as SCADA (Supervisory Control and Data Acquisition). SCADA equipment usually resides at an operation center where system operators monitor the ICSs and operate them when system conditions warrant it. While the majority of the equipment that comprise a SCADA system resides in the control center network behind firewalls, localized SCADA communication equipment directly connected to the ICSs can be as vulnerable as the ICSs themselves. A digital attack or intrusion on these localized communication systems would have a greater effect on the overall system and allow the attacker access to all ICSs connected to them. This condition would allow the attacker the ability to operate all ICSs causing a broader and more far reaching effect on system operations.

Read full article at Christian Science Monitor