In the landscape of Operational Technology (OT), confronting vulnerabilities often leads to the reflex of firmware updates or software patches. While this practice is foundational for maintaining the security of OT controllers and devices, certain vulnerabilities defy the simplicity of this approach.
Ensuring that OT controllers and devices are running the latest firmware and software versions is good practice, but it won't address vulnerabilities like CVE-2022-38773. Updating a PLC carries a huge risk for a manufacturing company, it may require production downtime and the site may not have a secondary unit to use in its place.
In the case of this PLC vulnerability, patching won't resolve this issue because the dedicated cryptography chip used on the PLCs, ATECC108A, is not patchable via software – the encryption key is burned into the chips themselves. A simple update is not adequate to prevent exploitation here.
Going forward, we must build a layered defense with compensating controls to mitigate these risks. The tool that has been used to do this, the Purdue model (Chart 1), was not created to add a security layer, regardless of being used as just that for many years. The Purdue model was created to provide a network isolation layer/s and traffic monitoring and control. However, it only completes these goals if the model is followed perfectly, which rarely happens, due to complexity and operational impacts. The only way to truly add a security layer without huge, untenable modification is to add an in-line tool with the existing devices. There are only a handful of devices on the market that provide this. Corsha is one of them.
In other parts of technology, we verify all communication between endpoints through a closed system that evaluates each communication and ensures it is both in order and allowed to transit the network. While this may seem extreme, it is normal to architect modern cloud systems using proxies and endpoints. This practice even promotes simplified substructures and very lean network communication allowances. This is how large cloud providers build out portions of their control planes, which demand segmentation and security. To create a more secure process in OT networks, Corsha is taking this known, proven best practice and implementing it in a way that fits our environment, by adding multi-factor authentication (MFA) for non-person entities.
This conversation launches the perfect opportunity to move security forward and implement MFA for non-person entities. Trying to approach the solution through credential rotation, setting up network-based authentication or segmentation is a common solution, but we know through multiple real-world failures that this doesn't always work, it needs the extra layer of rotation.
MFA does not require human interaction. Services and devices can hold their own factors to prove trust. Newer designs in MFA are changing from the "thing I have" or "the thing I know" to a credibility test of “the Thing i am”. In other words, the token that a human would have and read is changed to a process that evaluates the veracity of the device. This third party process is able to constantly judge and control the ability to authenticate requests between one device and another, while still allowing API tokens and/or authentication to occur. This moves the device to different trust criteria without weakening other factors. The authentication moves to a communication-based rotation of credentials and management of locations. This ultimately provides resistance to casual and professional attacks.
Conclusion
Segmentation, separation, and delineation for OT systems is necessary, and the Purdue model does not provide for these necessities. We must redesign our OT networks to add multi-layered defenses into our OT systems that are designed for monitoring and response. Technology to partition traffic at the port, protocol, or device address level has existed for decades. We need to insist on it as we replace aging network infrastructure. Adding MFA for a defense-in-depth strategy, especially for the non-person entity, will be necessary with the level of current attacks.
This Siemens vulnerability and others should serve as a wake-up call for organizations relying on industrial control systems. In the ever-evolving landscape of cybersecurity threats, it's imperative to be proactive and vigilant in securing critical infrastructure. By following the mitigation strategies outlined above, we move from the traditional and risky current model of IT cybersecurity to an OT-aware approach. Organizations can significantly reduce their risk and ensure the continued reliability and safety of their systems.
A point should be raised at the close of this post, Siemens, did actually try to implement security in their PLC. It was less than perfectly successful, but It is still head and shoulders above many others that still use no authentication or basic authentication for all management and user activities. So in part we should applaud Siemens for work done and not throw out that achievement because the implemented security control also had a vulnerability. There are after all architectural solutions for this vulnerability.
We must stop building desert homes in a jungle, wondering why the materials we selected aren’t protecting us from the environment where we live.
References
https://www.zscaler.com/resources/2023-threatlabz-enterprise-iot-ot-threat-report
https://www.darkreading.com/ics-ot/critical-rce-vulnerability-rockwell-automation-plc-industrial
