Example anatomy of a deadly cyber-physical attack
In the interest of demonstrating an attack tree scenario in the CPS domain of the IoT, this section highlights a hypothetical but devastating example of a cyber-physical attack in the transportation domain. No doubt, most readers are familiar with the Stuxnet worm that targeted the Iranian CPS responsible for refining uranium to fissionable levels. Stuxnet, while immensely damaging to Iranian goals, did not result in a safety failure. It resulted in an industrial control process failure that caused uranium refinement rates to come to a standstill. Unfortunately, Stuxnet—while most certainly nation state in origin—is only a prelude of things to come with regard to CPS attacks. Keep in mind, the following attack scenario is not trivial and would typically require the resources of a nation state.
As we mentioned in Chapter 1, A Brave New World, CPSes comprise a variety of networked sensors, controllers, and actuators that collectively make up a standalone or distributed control system. In aviation, a historically safety-driven industry, amazing advances have been made in fault-tolerant engineering approaches; many of the lessons learned came about from root cause analysis investigations of various tragedies. Jet engine reliability, air-frame structural integrity, and avionics resilience, as well as hydraulics and fly-by-wire system reliability are all elements we take for granted in a modern jet aircraft. Aviation software assurance requirements, as specified in the RTCA standard, DO-178B, are a testament to some of the lessons learned. The safety improvements, whether fault-tolerant features of the software, additional redundancies, mechanical or electrical design features, or software assurance improvements have resulted in failure rate targets reaching 1 in 1x10-9, a miracle in the history of modern safety engineering. Safety engineering, however, needs to be distinguished from security engineering in terms of evolutionary paths; safety engineering controls may only offer minor protection against the following attack.
This CPS attack example highlights the convergence of engineering disciplines at play in the planning, execution, and defense against such an attack. While this attack is exceedingly improbable today, it is described here to highlight the complexity of system interactions that can be exploited for malicious purposes. The high-level flow of the attack is as follows:
- Prerequisites:
- The attacker(s) possesses or procures significant aircraft avionics system knowledge (note: there are a number of companies and countries that possess this).
- Following a detailed characterization of the avionics hardware and software/firmware, the attacker develops a customized control system exploit for the aircraft in question. The exploit delivery comprises malware designed to automatically execute on the aircraft's system, once powered and initialized.
- The attacker compromises an airline's ground maintenance network. This network hosts the updated avionics software loads that the airline downloads from the aircraft manufacturer. From the network, maintenance crews stage the avionics patches into the airliner's Integrated Modular Avionics (IMA) system:
- The attacker physically or logically tampers with the aircraft's legitimate software/firmware binary (from the manufacturer) with the chosen exploit delivery mechanism. It is now staged to be loaded into the aircraft avionics hardware by maintenance personnel.
- The software update is uploaded. The malicious code begins to run and delivers the exploit reprogramming the controller. The exploit is a new microcontroller binary that executes logic for the control system's inner loop. Specifically, it contains a rewrite of the controller's notch filtering logic.
- The malicious microcontroller binary overwrites the notch filter code, eliminating the system's pitch mode (up/down) dampening of the aircraft's natural and harmonic structural frequencies (imagine bending the wing, letting go, and observing the jostling motion for a second—that's the natural frequency you normally want dampened). The normal frequency dampening performed by the notch filter no longer works and is instead replaced with an opposite response, namely, an excitation of the wing structure's bending mode (at its natural or harmonic frequency).
- The aircraft begins its flight and hits mild turbulence shortly after takeoff (note, hitting turbulence would probably not be necessary). The turbulence induces the wing's natural vibration modes that are normally dampened by the control system's notch filter. Instead, the oscillation excites the wing's natural structural frequency; the controller's excitation response increases in amplitude (the wing tips vibrate wildly up and down) until the wing experiences a catastrophic structural failure and disintegrates.
- The disintegrated wing structure causes the aircraft to crash. The attacker's end goal is achieved.
Now that we have your attention, we must reiterate that this is an exceedingly improbable, highly sophisticated attack, and that there are much easier ways of bringing down an aircraft. However, CPS attacks may become more attractive over time depending on the attacker(s) motivations and the networking of control systems offers new attack vectors to gain initial footholds. The sad news is that such attacks, whether against transportation systems or smart home appliances, will become more feasible over time unless the cross-discipline safety and security collaborations we have already discussed become standard practice and improve.
There are numerous mitigations that could have thwarted the aircraft control system attack, as described. For example, if all avionics binaries were cryptographically signed by the manufacturer, integrity can be protected end to end. If the avionics manufacturer only applies a Cyclic Redundancy Check (CRC), an attacker may be able to find easy ways of thwarting it (CRCs were designed to detect accidental fault-based integrity errors, not intelligently designed integrity attacks). If the binaries are cryptographically integrity-protected, the attacker will find it much more difficult to modify code without failing the integrity check installation or system power-up. The hacked controller logic will be much more difficult to inject. In the safety world, a CRC is generally sufficient, but not in the security world of CPS where enhanced end-to-end security is preferred when possible. Simply transferring an updated avionics binary over a cryptographically protected network connection (for example, TLS) will not meet the goal of protecting the binary end to end from the manufacturer into the aircraft. The TLS cryptographic connection will not satisfy the end-to-end need of ensuring the binary has not been tampered with in its delivery supply chain. This chain extends from the point of compilation and build (from original sources) at the aircraft manufacturer or its suppliers all the way to the point of avionics software load, power-on, and self-tests.
In practice, some safety controls such as redundant controller and independent data bus design can help mitigate some security threats. The unlikely attack we provided earlier would likely have been thwarted by the aircraft's redundant controllers, the legitimate command input values overriding (out-voting) the rogue one. Redundancies, however, are not sure bets in the security world; therefore, we should be careful not to let technology companies and government agencies dissuade us from healthy skepticism and concern. An intelligent adversary, given time, resources, and motivation, can find a way to maliciously induce what safety engineers call common mode failures. With ingenuity, even the fault-tolerant features of a design meant to prevent failures can be weaponized to induce them.