Protecting industrial control systems needs a proactive approach to firmware security
Article By : Ang Cui
When we harden one ICS layer, attackers simply shift over to other tactics and targets, and embedded devices like sensors will be a key target in the next shift.
2022 has delivered abundant new evidence that industrial control systems are in the cross hairs of cyber attackers. Researchers investigating Indestroyer2 and Pipedream/Incontroller have confirmed that both attack toolsets were designed to be launched from the control room and travel down to PLCs and other embedded devices, with the potential to disrupt or harm the physical process through various methods.
These attacks demonstrate the ongoing need to secure the networks and protocols that integrate the industrial control system (ICS) layers, a task which will take years but is underway.
However, there are new threats emerging simultaneously. Persistent on-device intrusions likely will be instrumental in long-term cyber breaches, as they provide attackers with the ability to modify embedded device behavior without being detected by engineering tools and most intrusion detection systems once they’re resident on the device.
So, while we’ve seen progress, systems still require extensive additional protection, particularly at the device level. Because history instructs us that when we harden one ICS layer, attackers simply shift over to other tactics and targets. We have to anticipate that embedded devices — those such as PLCs, sensors, HMIs, and traffic aggregators that reside adjacent to or just above physical processes — will be a key objective in the next shift.
If we wait to build security into the devices operating systems and firmware at these levels, we will be giving more time to skilled bad actors through our lack of preparation and foresight.
Several factors support the argument for starting the inclusion of OS and firmware security in project management today, not years down the line. It’s worth discussing each in more detail.
Factor 1: Bad actors can leverage insecure designs or exploit a device vulnerability to get to the kernel
Embedded devices such as PLCs and the devices from which they receive inputs and communicate with are implementing access controls and security on user accessible functions. But even flagship devices with the most modern security posture can be compromised by abusing user functions, protocols, and ladder logic to access the OS and exploit device vulnerabilities.
These more advanced devices have begun hardening the kernel and OS, but it will take time to refine security controls at this level, and years before they are universally applied. In the meantime, attacks that reach a device’s kernel or OS could enable the remote execution of undetectable shellcode without triggering any security alerts on the device. From there, RAM and even encrypted firmware can be read (enabling device analysis) and written to (which has the potential to change the device behavior).
Factor 2: Attackers gain persistence and time with OS-level attacks
On-device residence could support an objective similar to those of Pipedream and Indestroyer 1 and 2 (to modify the process), with an important difference. Once on a device deep enough in the stack, an attacker’s activity could remain undetected and persistent, even if user logic/configuration and firmware are redownloaded.
In this scenario, the attacker could choose when and how to exercise control of I/O, and thereby own the physical process.
Factor 3: Waiting to act will create an exploitable security gap
A large manufacturing plant may contain hundreds or thousands of PLCs, and tens thousands of actuators, sensors, and other devices connected to them. Updating all of these devices with modern security controls will require considerable expense — and time.
Regulatory and advisory bodies perceive this issue. For example, CISA recommends the replacement or upgrade of devices that cannot support measures such as end-to-end encryption. While this is a worthwhile recommendation, most new devices installed today will still lack strong OS and firmware level security which is difficult to apply via upgrade in the field. OTA firmware updates have helped address this difficulty, but at the expense of opening up another vector that attacks can exploit.
As these devices will then be resident in the system for 5-10 years (as opposed to 10-25 years in the past, which in itself is an improvement), we are creating a delay before an appropriate level of security can be deployed.
New devices either need to include, or be upgradable to include robust security features such as address space layout randomization (ASLR), no-execute areas, application whitelisting, data protection, firewalls, on-device monitoring and protection, and more secure firmware updates processes. Flagship devices by leading manufacturers now incorporate some or all of these protections, which is a welcome development over a “security through obscurity” posture. However, most devices in the field, and most being produced currently, lack a sufficient compliment of security features.
Additionally, device roots of trust and secure boot functions are becoming more robust, but they are not infallible; research also has demonstrated the feasibility of cold boot attacks, attacks on firmware update signing, and ones that leverage FPGAs connected to secure enclaves.
Factor 4: Improvements take years, and on-device security can’t wait
From a risk management perspective, the time and expense of building in this level of on-device security may not seem justifiable. But this is a limited and short-sighted perspective in terms of project management.
That said, how can we justify spending more for better protected devices today? The probability of a successful, on-device attack is still low. Given this reality and the sheer volume of work required to make user accessible functions and protocols on these devices more robust, is on-device security premature?
Unfortunately, it’s not. While the risk of such attacks may be low, the potential severity of a successful one provides ample incentive to undertake this investment now.
Also, every year of delay gives ambitious, well-funded attackers more time to hone their methods. Furthermore, building and deploying enhancements to the firmware and OS protections is challenging, due to long production schedules, resistance to change and security expenditures, and coordination.
Attacks will evolve: Defenders must evolve faster
It took years to achieve general acceptance acknowledgement among ICS architects (although not cybersecurity thought leaders) that the cyber threat OT systems and networks was serious, and still more years for measurable progress to be made towards securing those higher system levels. There is still a considerable amount of work to be done to push the security improvements into many systems and devices, as the overall rise in OT-focused attacks has demonstrated.
Without forethought and active planning, system operators and device manufacturers can expect a not-so-distant future in which user functions and protocols are mostly secured, putting device firmware and backend architecture on the front line of cyber aggression. And we will live with an unnecessarily elevated risk of damaging attacks before this next level is secured.
So, from a project management perspective, on-device security investments make sense today. While the risk to embedded systems from attacks to the firmware and kernel is still low, it is growing, and the attacks that do access this layer carry potential for the most severe, long-term consequences.
Factor in the time required and device architecture changes needed to deploy this type of technology, and then to deploy new devices, and it’s clear the time to start is now.
Our most mission-critical systems and industries require a more proactive approach. There has been good progress in securing ICS network and controls rooms, and we are beginning to tackle embedded device user functions. But unless we take a proactive approach to OS and firmware security, we can expect to reckon with yet another security gap in the years to come.
This article was originally published on Embedded.
Dr. Ang Cui is the Founder and CEO of Red Balloon Security, a leading cybersecurity provider and research firm that specializes in the protection of embedded devices across all industries. In addition to publishing innovative research, he frequently provides commentary and thought leadership on the most pressing challenges in cybersecurity today. Dr. Cui earned a Ph.D. in computer science from Columbia University, where he worked extensively in the Intrusion Detection Systems Lab.