Discovery of 56 OT Device Flaws Blamed on Lackluster Security Culture

Culture of ‘insecure-by-design’ security is cited in discovery of bug-riddled operational technology devices.

Researchers discovered 56 vulnerabilities affecting devices from 10 operational technology (OT) vendors, most of which they’ve attributed to inherent design flaws in equipment and a lax approach to security and risk management that have been plaguing the industry for decades, they said.

The vulnerabilities–found in devices by reputed vendors Honeywell, Emerson, Motorola, Siemens, JTEKT, Bentley Nevada, Phoenix Contact, Omron, Yogogawa as well as an unnamed manufacturer–vary in terms of their characteristics and what they allow threat actors to do, according to the research from Forescout’s Vedere Labs.

However, overall the “impact of each vulnerability is high dependent on the functionality each device offers,” according to a blog post about the flaws published Tuesday.

Researchers broke down the type of flaw that they found in each of the products into four basic categories: insecure engineering protocols; weak cryptography or broken authentication schemes; insecure firmware updates; or remote code execution via native functionality.

Among the activities that threat actors can engage in by exploiting the flaws on an affected device include: remote code execution (RCE), with code executed in different specialized processors and different contexts within a processor; denial of service (DoS) that can take a device completely offline or block access to a certain function; file/firmware/configuration manipulation that allows an attacker to change important aspects of a device; credential compromise allowing access to device functions; or authentication bypass that allows an attacker to invoke desired functionality on the target device, researchers said.

****Systemic Problem****

That the flaws—which researchers collectively dubbed OT:ICEFALL in a reference to Mount Everest and the mountain device makers need to climb in terms of security–exist in key devices in networks that control critical infrastructure in and of itself is bad enough.

However, what’s worse is that the flaws could have been avoided, as 74 percent of the product families affected by the vulnerabilities have some sort of security certification and thus were verified before being sent to market, researchers found. Moreover, most of them should have been discovered “relatively quickly during in-depth vulnerability discovery,” they noted.

This free pass OT vendors have been giving to vulnerable products demonstrates a persistent lackluster effort by the industry as a whole when it comes to security and risk management, something researchers hope to change by shining a light on the problem, they said.

“These issues range from persistent insecure-by-design practices in security-certified products to subpar attempts to move away from them,” researchers wrote in the post. “The goal [of our research] is to illustrate how the opaque and proprietary nature of these systems, the suboptimal vulnerability management surrounding them and the often-false sense of security offered by certifications significantly complicate OT risk management efforts.”

****Security Paradox****

Indeed, security professionals also noted the paradox of the lax security strategy of vendors in a field that produces the systems running critical infrastructure, attacks on which can be catastrophic not just for the networks on which the products exist but for the world at large.

“One may incorrectly assume that the industrial control and operational technology devices that perform some of the most vital and sensitive tasks in critical infrastructure environments would be among the most heavily secured systems in the world, yet the reality is often the exact opposite,” noted Chris Clements, vice president of solutions architecture for Cerberus Sentinel, in an email to Threatpost.

Indeed, as evidenced by the research, “too many devices in these roles have security controls that are frighteningly easy for attackers to defeat or bypass to take complete control of the devices,” he said.

The findings of researchers are yet another signal that the OT industry “is experiencing a long overdue cybersecurity reckoning” that vendors must address first and foremost by integrating security at the most basic level of production before proceeding further, Clements observed.

“Manufacturers of sensitive operational technology devices must adopt a culture of cybersecurity that starts at the very beginning of the design process but continues through to validating the resulting implementation in the final product,” he said.

****Challenges to Risk Management****

Researchers outlined some of the reasons for the inherent issues with security design and risk management in OT devices that they suggest manufacturers remedy in swift fashion.

One is the lack of uniformity in terms of functionality across devices, which means that their inherent lack of security also varies widely and makes troubleshooting complicated, they said. For example, in investigating three main pathways to gaining RCE on level 1 devices via native functionality–logic downloads, firmware updates and memory read/write operations—researchers found that individual technology handled these pathways differently.

None of the systems analyzed support logic signing and more than 50 percent compiled their logic to native machine code, they found. Moreover, 62 percent of the systems accept firmware downloads via Ethernet, while only 51 percent have authentication for this functionality.

Meanwhile, sometimes the inherent security of the device wasn’t directly the fault of the manufacturer but that of “insecure-by-design” components in the supply chain, which further complicates how manufacturers manage risk, researchers found.

“Vulnerabilities in OT supply chain components tend to not be reported by every affected manufacturer, which contributes to the difficulties of risk management,” they said.

****Long Road Ahead****

Indeed, managing risk management in OT and IT devices and systems alike requires “a common language of risk,” something that’s difficult to achieve with so many inconsistencies across vendors and their security and production strategies in an industry, noted Nick Sanna, CEO of RiskLens.

To remedy this, he suggested vendors quantify risk in financial terms, which can enable risk managers and plant operators to prioritize decision-making on “responding to vulnerabilities – patching, adding controls, increasing insurance — all based on a clear understanding of loss exposure for both IT and operational assets.”

However, even if vendors begin to address the fundamental challenges that have created the OT:ICEFALL scenario, they face a very long road ahead to mitigate the security problem comprehensively, Forescout researchers said.

“Complete protection against OT:ICEFALL requires that vendors address these fundamental issues with changes in device firmware and supported protocols and that asset owners apply the changes (patches) in their own networks,” they wrote. “Realistically, that process will take a very long time.”