Changing the Model for OT Cybersecurity
The recent discovery of a vulnerability in Siemens programmable logic controllers (PLCs) has sparked concerns about the security of these systems. Siemens PLCs, a cornerstone in industrial automation and critical infrastructure, have been widely used for years, supporting the operations of power plants, manufacturing facilities, and other crucial systems.
Many Siemens PLCs are now exposed to cybersecurity threats due to a vulnerability (CVE-2022-38465). This flaw could potentially lead to the extraction and exposure of the global private encryption keys for certain industrial devices. Security researchers identified this vulnerability in Siemens' SIMATIC S7-1500 PLCs, demonstrating attacks that could compromise protected communications and configurations. This vulnerability allows attackers to execute commands on physical devices or manipulate sensor readings.
Furthermore, architectural vulnerabilities within the same PLCs were discovered through Red Balloon Security (CVE-2022-38773). This revelation uncovered over 100 models of the S7-1500 PLCs with a design flaw that poses significant security risks.
While Siemens has diligently worked to address these security concerns, the design of the devices poses challenges, and in 2023, Siemens announced that the only viable solution is full instrument replacement due to the inherent design flaws.
This article aims to shed light on not only Siemens but also similar issues faced by other prominent players in the IIoT and OT product space, such as Rockwell and Philips. It encourages a discussion on strategies to address "uncorrectable" vulnerabilities and explores potential architectural changes to OT networks to render such vulnerabilities irrelevant.
Fitting a New Model in an Old World
Traditional cybersecurity approaches prove inadequate when applied to Operational Technology (OT). The longevity of these systems, running for a decade or more, highlights the need for a different approach. Attempting to overlay IT controls on OT technology leads to disruptions, friction, and outages. The prevalent vulnerabilities in the wild emphasize the urgency for a creative rethink on OT network security.
The analogy of an architect building a house illustrates the importance of considering the environment. While architects can use the same floor plans, the choice of materials, methods, risks, and countermeasures depends on whether the home is in a desert or a jungle. OT engineers face similar decisions, selecting building materials that resist specific environmental threats. This necessitates a different approach to OT requirements, considering the unique operational demands, materials, and environmental threats that differ from traditional IT networks.
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 platforms 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.?
To learn more about how to leverage the Purdue Model to support Identity & Access Control in OT to IT environments, read our white paper here .