What to do with the security flaws inherent in ICS? • The register


The latest research on threat security in operational technology (OT) and industrial systems has identified a slew of issues – 56 to be exact – that criminals could use to launch cyberattacks on critical infrastructure.

But many of them are beyond repair, due to insecure protocols and architectural designs. And that highlights a bigger security issue with devices that control power grids and keep clean water flowing through taps, according to some industrial cybersecurity experts.

“Industrial control systems have these inherent vulnerabilities,” said Ron Fabela, CTO of cybersecurity firm OT SynSaber. The register. “That’s just how they were designed. They don’t have patches in the traditional sense like, oh, Windows has a vulnerability, apply that KB.”

In a study published last week, Forescout’s Vedere Laboratories detailed 56 bugs in devices built by ten vendors and collectively named the security flaws OT:ICEFALL.

As the report’s authors acknowledged, many of these flaws result from the design of OT products without basic security controls. Indeed, Forescout’s analysis comes ten years after that of Digital Bond Project base camp which also reviewed OT devices and protocols and deemed them “not secure by design”.

Hours after Forescout published its research, CISA Posted its own security warnings related to OT:ICEFALL vulnerabilities.

CVE: the problem? Or the fix?

“So far, no CVEs have been generated for these insecure-by-design items, and there’s a reason for that,” Fabela said. “It’s bad for the industry.”

Once a CVE is generated, it triggers a series of actions by industrial system operators, especially in heavily regulated sectors like electric utilities and oil and gas pipelines.

First, they must determine if the environment contains affected products. But unlike enterprise IT, which typically has centralized visibility and control over IT assets, in OT environments, “everything is distributed,” Fabela noted.

If industrial and manufacturing environments have products affected by the vulnerability, this triggers an internal review and regulatory process that involves responding to CISA and developing a plan to improve security.

A SynSaber customer sarcastically described OT:ICEFALL as “the gift that keeps on giving,” Fabela said. “He said, ‘Now I have this on top of all my other, real vulnerabilities,’ which presents a host of other patching issues – like having to wait for a planned maintenance outage that can last months out – if the manufacturer has a patch at all.

OT protocols do not use authentication

For example: The current Modbus protocolwhich is very commonly used in industrial environments, has no authentication.

Forescout’s analysis details nine vulnerabilities related to unauthenticated protocols and challenges the argument against assigning a CVE identifier to a product with an insecure OT protocol.

“Rather, we believe that a CVE is a community-recognized marker that contributes to the visibility and actionability of vulnerabilities by helping vendors resolve issues and asset owners assess risk and enforce fixes,” the authors wrote.

While this makes sense from an IT security perspective, Fabela said it’s unrealistic from an OT perspective and ultimately doesn’t make critical infrastructure more secure.

Modbus, as a protocol that does not use authentication, could generate “thousands” of CVEs that “affect all product lines globally”, he added. “You’re tying up product security teams with OEMs and you’re tying up customers, asset owners with CVE that they can’t do anything about.”

A Basecamp researcher gives his opinion

Reid Wightman is a Principal Vulnerability Researcher on the Threat Intelligence Team at the OT Dragos Security Store. He is also one of the first researchers of the Basecamp project and, more recently, he has worked on the ProConOs and MultiProg software vulnerabilities.

Forescout cited some of its research and dedicated a section of the ICEFALL analysis to security vulnerabilities with the ProConOS runtime in APIs.

In an email to The registerWightman noted that many industrial controllers have the same set of problems that don’t go away: “they allow unauthenticated code to run on the PLC.”

“This means that a single transfer of malicious logic to the PLC can permanently compromise the PLC,” he added, noting that because the control logic is causing the change, it can occur outside of a normal firmware update. “It’s kind of something I’ve insisted on since the days of Basecamp, but maybe worth repeating. Over and over again. Until the sun goes down, probably .”

Lately, one of Wightman’s “big personal concerns” is that some vendors say they can use TLS and client certificates to secure controllers, probably to be avoided. In reality, it would only make traffic harder to inspect, Wightman said.

“If an attacker breaks into the engineered system, they can load a malicious payload using CVE-2022-31800/CVE-2022-31801 (or one of the similar issues that exist in almost every logic executions) in the controller,” he added. . “Only now we have no way of knowing if they did because the traffic is encrypted.”

So how to solve the problem?

“I guess my answer would be: if your engineering system is compromised, throw away any controllers it was allowed to talk to,” Wightman said. “And I doubt most end users reach that level of paranoia.”

Which again highlights the insecure nature of the design of these systems.

“Fortunately, we see no signs of widespread abuse of these protocols or ‘features’ despite some bugs being well known for years,” Wightman added. “I really hope it stays that way.” ®


About Author

Comments are closed.