Distressing disclosures of device and application vulnerabilities are a near-daily occurrence in ICS/OT. Most of the warnings focus on holes in applications developed by the vendor or located within built-in OEM functionality, with a disturbing share of these vulnerabilities open to misuse by unsophisticated attackers.
They may sound terrifying. But depending on an organization’s function – and with the right balance of security investment, risk management, and security hygiene – asset owners can wring out advisory anxiety and take a calmer, more straight-forward approach to ICS/OT risk response and remediation.
Late last month, ICS-CERT warned of a remotely exploitable vulnerability in Rockwell Automation Logix controllers and associated Studio 5000 Logix Designer/RSLogix 5000 software. The advisory, ICSA-21-056-03, detailed insufficiently protected and hard-coded credentials in Rockwell PLCs and software and carried a maximum severity score of 10.0. That level of criticality suggests significant risk regardless of compensating controls.
ICS-CERT warned that the vulnerability could allow an unauthenticated attacker with either physical or network access “to bypass the verification mechanism and connect with Logix controllers.” The issue also could “enable an unauthorized third-party tool to alter the controller’s configuration and/or application code,” ICS-CERT cautioned.
It’s important to remember that daunting advisories like these signal discovery of a risk organizations should certainly heed. They are, however, neither complete nor transparent; the asset owner remains the ultimate decision-maker.
With or without the holes described in ICS-21-056-03, a low-skill attacker with unfettered access to networked devices and control applications – either by getting themselves “plugged in,” or by compromising the Windows system hosting the engineering software – can often launch any number of attacks with minimal difficulty.
Most such attacks are opportunistic and can be prevented by keeping malicious parties from stumbling into the environment and causing chaos in the first place.
An organization with solid security architecture and a robust OT security program is much better positioned to handle any threat — from commodity to critical — and avoid costly process interruptions and production delays that threaten the organization’s bottom line.
Industry best practices, such as those noted in ISA 62443 (e.g., zones, conduits, security target levels, etc.), along with secured engineering workstations, stringent user policies, and lateral traffic limits drastically push the risk to the organization below the published CVSS score. With actual, residual risk reduced, risk assessors gain the luxury of time to accurately understand, transfer, remediate, or terminate the threat.
OT cyber security doesn’t require advanced, silver-bullet solutions, but rather a series of well-executed capabilities that allow an organization to engineer out potential risks by understanding its assets in detail, applying compensating controls and security measures, and respecting the inherent demands of an OT environment.
In the case of the Rockwell vulnerability, exploitation is born in two places: over the network, and from a privileged location. It will not be magically executed by itself. To mitigate the associated risk, asset owners should:
- Know the landscape. If the environment is largely static or steady-state, understanding assets and how they communicate gives defenders an advantage. Things change slowly in OT. That’s both a blessing and a curse.
- Segregate critical workstations from commodity assets. Systems running commodity operating systems benefit from strict security controls. Attackers are far more likely to understand or be present on, these types of systems.
- Restrict connectivity and lateral movement. A malicious actor would most likely exploit the Rockwell vulnerability over a network via EtherNet/IP (also known as CIP), a protocol with native routing permissions. When a device is not properly segmented, it can be used as a delivery mechanism. Other OEM-provided products such as NAT routers with CIP-aware functionality can also be misused as they’re designed for extending connectivity, not security.
- Prevent EtherNet/IP routing over backplanes. This means that the vulnerability is not limited to devices accessible over an IP network, but through embedded ICS/OT devices themselves.
- Apply compensating controls. Measures such as user access controls, account hardening, group policy protections, and application whitelisting help prevent systems from being accessed remotely or haphazardly.
- Consider the purpose. An asset’s function, risk exposure, impact, and the organization’s overall risk tolerance all play a role in pragmatic defense. If the affected products pose a risk to health, safety, or environment, secure them accordingly and engineer out the risk to an appropriate level.
- Leverage OEM security features. Toggling devices to RUN mode and/or secure CIP (where possible) are among the built-in protections at the defender’s disposal.
Securing OT assets and embedded devices differs greatly from asset management in enterprise IT environments, but safeguarding ICS/OT environments is feasible. Researchers will continue to find security flaws and OT solutions will still have bugs, but proactive efforts to gain visibility on asset risk, to provide remediation paths, and to manage incidents can flip the odds in favor of the defenders.