ICS Environments and Patch Management: What to Do If You Can’t Patch

The evolution of the cyber threat landscape highlights the need for organizations to strengthen their ability to identify, analyze, and evaluate cyber risks before they evolve into security incidents. Known unpatched vulnerabilities are often exploited by criminals to penetrate Industrial Control Systems (ICS) environments and disrupt critical operations. Although the terms “patch management” and “vulnerability management” are used as if they are interchangeable, this is not the case. Most are confused because applying patches is one of the many tools available in our arsenal for mitigating cyber risks.

Benefits and Risks of Patching (and Patch Management)

Although patching is a fundamental security practice in both the IT and the OT (Operational Technology) worlds, applying it in OT settings differs substantially from IT systems. In the OT world, assessing the benefits and risks of applying a patch before doing so is essential.

Benefits of patching

The most apparent reason for patching is fixing security flaws or bugs. The IBM Security X-Force Threat Intelligence Index 2023 highlights that cybercriminals can access over 78,000 known exploits, making patch management and prioritization compelling for critical infrastructure businesses.

However, there are other benefits you gain from patching timely and correctly. Many vendors release patches to improve the applications’ stability, which is a strong advantage in the ICS environment because stability and uptime of critical devices are of the utmost importance.

Patching risks in ICS environments

Besides the benefits, patching in ICS environments presents certain risks. This is closely related to how risk is perceived within the OT side. Data compromise is considered a more significant concern than network downtime within the IT domain. On the other hand, systems availability, reliability, and uptime are of greater importance for the OT side. Hence, taking down a critical network or component due to a non-compatible or corrupt patch is a significant risk in ICS environments.

Another factor to consider is the associated cost of testing the released patches. Again, the IT and the OT sides of the business have different cost factors to consider. Both sides must build labs for the patches to be tested against before rolling out on production systems. In the OT world, you have to buy hardware that mimics the real production systems, unlike in the IT world, where you could emulate the production systems using virtual environments. The logistics and the associated costs behind replicating OT production systems outweigh the respective sizes of IT systems.

Furthermore, IT could also utilize automated patch management solutions that will vastly reduce the resources required to test all those patches. Unfortunately, this is not the case with OT. Patches must be tested on each device, and most probably, OT teams would have to rely on the vendor specialist to deliver the updates themselves. This is incurring a much higher cost-to-benefit ratio than on the IT side.

The last thing we need to consider is vendor end-of-life (EOL) product cycles. Some production systems have been around in OT environments for over twenty or more years. In most cases, they have never been upgraded or patched. Asking the OT people to take the risk of patching a system that has been working flawlessly for decades to make it harder to be breached is a hard thing to do.

Over the past few years, critical infrastructure entities and ICS environments have been among the top ten organizations affected by data breaches. A simple look at the IBM Cost of a Data Breach report is enough to persuade OT organizations that the risks and costs associated with “when an attack happens” should be examined in greater detail. The likelihood of an unexpected, uncontrolled system shutdown should be measured against doing a controlled, manual, segmented patching.

CIA Triad: IT vs. OT

It would be helpful to review how these two worlds view the CIA triad to understand the differences in risk perceptions and prioritization between IT and OT.

IT domain: CIA

For the IT side, Confidentiality has the highest priority. Customer or staff personal data compromise could be catastrophic to any organization and entail financial losses, reputational damage, and regulatory penalties for breaching privacy laws.

Integrity is the second highest concern for IT organizations. Branding and customer retention could be massively affected if an organization admits to being breached and any data or intellectual property has been altered without consent.

The last concern is Availability. Organizations would always strive to maintain high availability on customer-facing systems. However, should a system go down, the impact is reduced compared to OT organizations. Rebuilding a system from a virtual backup is much simpler than getting a physical device removed from the production line and replaced with a new one, which usually involves vendor specialists increasing the cost and the downtime.

OT domain: AIC

On the other hand, Availability has the highest priority for OT organizations. This is entirely understandable, as the cost and impact of even a short system downtime could be detrimental to the organization and local societies and economies.OT systems going out of production may hamper other organizations or industries since the interconnections and interdependencies between products and services are very strong.

Integrity has the second highest priority for the same reasons as in the IT domain: branding, loss of revenue, and fines.

Confidentiality is last on the priority list, although it should not be considered a minimal concern because the compromise of intellectual property can have dire consequences.

Despite all these differences, IT and OT share a common ground: safety. But this is not the only similarity they share. With organizations converging OT and IT, it is easy to realize that they overlap in many more areas, such as asset discovery, vulnerability assessment, policy management, change detection, configuration assessment, and log management. Therefore, aligning cybersecurity efforts to reduce overhead and achieve cost and resource savings makes perfect sense.

What Can Be Done If We Can Not Patch?

Considering our analysis, the question remains. If we can’t patch, what else can be done?

It all starts by acknowledging that patch management is a subset of vulnerability management. Vulnerability management is a holistic function that proactively manages identified vulnerabilities in deployed hardware devices and software.

Vulnerability management is more than getting alerts whenever your infrastructure needs a patch. It is about making informed decisions and adequately prioritizing what vulnerabilities to mitigate and how. This is achieved by embedding internal telemetry hooks into all critical systems and external hooks for threat intelligence from all sources.

Based on these considerations, ICS organizations should do the following as a minimum if they cannot patch.

1. Asset analysis or discovery to know what you have in your environment to protect it. This process could raise one fundamental security question: do we need all these assets, or are we spending time trying to secure things that are not required?
2. Perimeter protection to fortify your organization against cyber-physical risks. This could include anything from firewalls to access controls.
3. Network segmentation comes with many benefits when trying both to defend against lateral movements and to contain a security incident so as not to harm the entire organization.
4. Log management is a tool to look for suspicious movement within the organization and detect potential attacks.
5. Vulnerability assessment to determine potential weak points and identify the vulnerability risk posture of each asset. Once the vulnerability scan is complete, a score is attached to each vulnerability based on the skills required to exploit it and the privileges gained upon successful exploitation. The easier the vulnerability is to exploit, and the higher the privilege gained, the higher the risk score will be.
6. File Integrity Monitoring (FIM) to monitor changes within the ICS organization. While the previous steps predominantly cover external threats, FIM looks inside the organization to correlate movement with changes and reduce the noise further before raising the alarm.

How Tripwire Helps

The Tripwire portfolio includes solutions that can work together or be stand-alone, offering customers maximum flexibility.

Tripwire’s File Integrity Manager is a file integrity and configuration assessment solution that identifies an alert on all changes within an organization’s network, providing detailed information, such as who made the change, when the change happened, and what the change was, by providing a side-by-side comparison report.

Tripwire IP360 is a vulnerability solution that discovers assets on the network and scans them against a known vulnerability database of over 130 thousand unique tests. IP360 prioritizes the highest-scoring vulnerabilities to reduce the number of vulnerabilities an organization should focus on and facilitate the patch management strategy.

Tripwire LogCenter is an intelligent historian that provides complete, secure, reliable log collection and highlights events of interest from a sea of data. ICS asset discovery and inventory solutions have been designed to capture, process, and alert on all the same critical elements that Tripwire Enterprise and IP360 do, but from a data packet analysis perspective, i.e., agentless “on the wire” traffic.

Having all the solutions integrated would provide the security measures recommended as an absolute minimum (including patch management) and the processes that could reduce the data required to detect potential threats. Using agent-based and agentless technologies would ensure that organizations monitor all devices within their infrastructure without concern for endpoint stability, warranties, and varieties. If an organization deems a device critical, regardless of the device, it should be monitored and reported on. That’s the philosophy behind patch management.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of Tripwire.