Imagine a typical morning at a manufacturing plant. The Maintenance Engineer receives an email from the IT security department marked with the highest priority. The subject line: “Critical vulnerability (CVSS 10.0) in X-Series PLCs - immediate update required.” The content includes a link to the manufacturer’s bulletin and an alarming description of the vulnerability, which allows remote code execution. For an IT specialist, the matter is simple: there is a dangerous hole, there is a patch for it, it needs to be installed as soon as possible. For the OT engineer, this e-mail is the beginning of a nightmare.
The X-Series controllers control the most critical production line in the entire factory. They have been operating stably for twelve years on the same proven version of software. The very thought of uploading a new firmware version, untested in this environment, which requires stopping the entire line, is paralyzing. What if the upgrade fails? What if it causes a conflict with the SCADA software? The risk of a multi-day outage seems far greater than the hypothetical risk of a cyberattack.
This scenario perfectly illustrates why the traditional IT approach to vulnerability management is completely unsuited to the realities of operational technology. In the OT world, you can’t just “scan and patch.” A fundamental shift in thinking is required - from a panicked reaction to every new vulnerability, to a calm, risk-based process in which installing a patch is a last resort, not the first instinct.
Shortcuts
- Why is the “scan and patch” model from IT a recipe for disaster in the OT network?
- What are the three main reasons why you can’t just upgrade a PLC?
- How do you go from thinking “I need to patch everything” to “I need to manage real risk”?
- Why is a CVSS assessment not enough, and how to assess the real impact of vulnerability on the physical process?
- What are compensating controls and why are they a major tool in the fight against vulnerabilities in OT?
- How does network segmentation become the first line of defense against an attack on a vulnerable device?
- What is virtual patching with IPS systems and how does it work in practice?
- How can tightening access rules prevent an attacker from reaching a vulnerability?
- How does network monitoring detect attempts to exploit known vulnerabilities in real time?
- What actions can be taken on the device itself if updating is not an option?
- Modern vulnerability management process in OT
- How does the risk-based approach and compensating controls fit into NIS2 requirements?
- How does nFlo help you implement a vulnerability management strategy tailored to your factory?
- Does vulnerability have to mean weakness, or how to live with non-patchable systems?
Why is the “scan and patch” model from IT a recipe for disaster in the OT network?
In the IT world, the cyclical process of “scan and patch” (scan and patch) is the gold standard of cyber security hygiene. It involves regular, automated scanning of all systems for known vulnerabilities, followed by mass deployment of vendor-issued patches (patches). This approach is effective in a corporate environment, where system availability, while important, may be briefly sacrificed in the name of security.
However, trying to transfer this model to the OT world is a recipe for disaster. First, as we already know, active scanning is extremely risky for sensitive industrial equipment and can lead to failure. Second, even if we identify a vulnerability, the process of patching it is fraught with enormous operational risk. In OT, stability and predictability are sacrosanct. Any change in the configuration or software of a critical control system is a potential threat to production continuity.
The “scan and patch” model ignores a fundamental truth about OT: the risk associated with the patching procedure itself is often perceived as greater and more likely than the risk associated with an attacker exploiting a given vulnerability. This is why forcibly imposing this model leads to conflicts between IT and OT teams, and to building a culture of hiding problems instead of openly managing risks.
📚 Read the complete guide: OT/ICS Security: Bezpieczeństwo systemów OT/ICS - różnice z IT, zagrożenia, praktyki
What are the three main reasons why you can’t just upgrade a PLC?
OT engineers’ resistance to updating their systems is not due to ignorance, but to a deep understanding of the specific environment for which they are responsible. There are at least three fundamental reasons why a simple “patch it” is impossible in practice. The first is lack of manufacturer support. Many devices in OT networks are obsolete (legacy) systems that have been in operation for 15-20 years. Their manufacturers have long since ended technical support for them. Security patches for these devices simply do not exist and will never be made.
The second reason is compatibility and stability risks. An industrial control system is a complex ecosystem in which dozens of devices from different manufacturers must work together perfectly. A new version of software for a PLC, even if it patches a security vulnerability, can introduce subtle changes in communication that cause incompatibility with SCADA software or another system component. Testing all these dependencies is extremely difficult and time-consuming.
The third, and often most important, reason is the requirement for business continuity. OT systems must operate 24/7 for months, even years, without interruption. There are no weekly “service windows.” Any stoppage of the production process is a huge financial loss. Installing a patch almost always requires a reboot of the machine, which means downtime. Carrying out such an operation is possible only during rare general plant overhauls, planned months in advance.
How do you go from thinking “I need to patch everything” to “I need to manage real risk”?
Since blind patching is not an option, a paradigm shift is needed. We need to move away from the “vulnerability/patch” binary thinking to a mature risk management process. This means that each identified vulnerability should be evaluated not in isolation, but in the full operational context in which it occurs.
The risk-based approach accepts that the existence of vulnerabilities in a system is a normal state, and our goal is not to achieve the unrealistic ideal of 100 percent patching, but to bring the risks associated with these vulnerabilities down to an acceptable level. Instead of asking the question “Is this controller vulnerable?”, we ask a series of much more important questions.
“How critical to production is this driver? What would be the physical consequences if this particular vulnerability were exploited? What is the likelihood of an attacker getting to this controller at all? Are there other controls in place that already mitigate this risk?” Only by answering these questions can we make an informed decision about whether a vulnerability requires an immediate response, or whether its risk is low enough that we can live with it.
Why is a CVSS assessment not enough, and how to assess the real impact of vulnerability on the physical process?
In the IT world, the standard for assessing the severity of vulnerabilities is the CVSS (Common Vulnerability Scoring System) scale, which assigns each vulnerability a score from 0 to 10. A high CVSS score, especially above 9.0, is an automatic signal in IT for immediate action. However, in the OT world, relying solely on the CVSS score is not only inadequate, but can sometimes be downright misleading.
The CVSS scale assesses the technical characteristics of a vulnerability in isolation: how easy it is to exploit, whether it requires user interaction, what impact it has on the confidentiality, integrity and availability of the system itself. It tells us nothing about what the real, physical impact of its exploitation will be in a specific industrial process. It is this physical impact that is crucial for risk assessment in OT.
A vulnerability with a “critical” CVSS 10.0 rating in a PLC that controls lighting in a parking lot poses much less risk to the company than a vulnerability with a “medium” CVSS 5.0 rating in a controller that manages the safety system in a chemical reactor. Therefore, risk assessment in OT must combine technical CVSS assessment with Process Impact Analysis. We need to understand what a system does, how important it is, and what is the worst that can happen in the physical world if it is compromised.
What are compensating controls and why are they a major tool in the fight against vulnerabilities in OT?
If we can’t eliminate the vulnerability at the source (that is, patch the device itself), we need to apply compensating controls. These are alternative security measures that we deploy around a vulnerable system to reduce the risk of exploiting the vulnerability. Instead of patching the hole in the device itself, we build a multi-layered protective barrier around it.
The concept of compensating controls is absolutely key in OT security management. It allows us to accept the fact that a vulnerability exists, while actively managing the associated risks. Instead of helplessly spreading our hands and saying “nothing can be done because the manufacturer no longer supports it,” we implement a series of measures that make it extremely difficult or even impossible for an attacker to reach and exploit this vulnerability.
The set of possible compensating controls is very broad and should be selected depending on the specifics of the vulnerability and the system being protected. The most effective strategies are based on a combination of several different types of controls, creating a deep, multi-layered defense.
How does network segmentation become the first line of defense against an attack on a vulnerable device?
The most important and effective compensating control is network segmentation. As described in previous articles, it involves placing a vulnerable device in a small, isolated network segment protected by an industrial firewall. Even if our PLC is full of critical, unpatched vulnerabilities, simply placing it behind a firewall drastically reduces the risk.
With segmentation, an attacker, even if he gets into our network, will not have direct access to the vulnerable device. He will first have to force his way through the firewall that protects the segment. This gives us a powerful first line of defense.
Moreover, segmentation allows us to implement further layers of protection. On the firewall, we can define very restrictive rules, limiting communication with a vulnerable device only to an absolute minimum. If we know that a controller needs to communicate with only one SCADA server, we can block all other traffic, effectively cutting off all other routes for potential attackers to reach their target.
What is virtual patching with IPS systems and how does it work in practice?
Virtual patching is one of the most elegant and effective compensating controls. It is implemented using an Intrusion Prevention System (IPS), which is often a module of a modern industrial firewall (NGFW). The IPS acts as an intelligent gatekeeper that analyzes the content of network communications in real time.
When a new, known vulnerability appears, IPS manufacturers create a special “signature” for it - an attack pattern that attempts to exploit this vulnerability. This signature is uploaded to the IPS system. From that point on, the IPS analyzes all traffic directed to the protected, vulnerable device. If it detects a network packet that matches the signature of a known attack, it immediately blocks it before it reaches its target.
As a result, the vulnerability in the device still physically exists, but is “virtually patched” at the network level. An attacker is unable to exploit it because his attempted attack is intercepted and neutralized by the IPS. This is an extremely powerful tool that allows immediate protection against newly discovered threats, giving the company time to plan for a possible physical update in the distant future.
How can tightening access rules prevent an attacker from reaching a vulnerability?
Many vulnerabilities, especially those in industrial protocols, can only be exploited using specific, rarely used functions. A good example is commands used to upload new software (firmware) or change PLC logic. In normal daily operation, these commands are not used at all. They are only used by the engineer during planned maintenance work.
A great compensating control, then, is to tighten the rules on the firewall so that they block these dangerous protocol features by default. We can create a policy that allows communication with the controller in “read-only” mode only, blocking any attempts to write or change the configuration.
When an engineer needs to perform maintenance work, the policy can be temporarily and controllably changed to allow access from his specific workstation. Once the work is completed, the rules are restored to “read-only” mode. Such a simple change in firewall configuration can completely neutralize an entire class of vulnerabilities, preventing an attacker from performing any malicious operations.
How does network monitoring detect attempts to exploit known vulnerabilities in real time?
Even if we can’t actively block traffic (using an IPS, for example), we can still monitor it. Implementing an Intrusion Detection System (IDS) or passive OT network monitoring system allows early detection of attempts to exploit known vulnerabilities. Like IPS, IDS uses signatures to identify malicious traffic, but instead of blocking it, it only generates an alert for the security team.
Such an alert is invaluable information. It lets us know that someone (or something) is actively trying to attack our vulnerable device. Even if the attack is unsuccessful, the mere fact that it was attempted is a signal that our network has probably been compromised and that there is an attacker inside. This allows us to immediately initiate incident response procedures and start looking for the intruder before he or she can find another way to the target.
Network monitoring is thus a form of digital alarm system. It doesn’t stop an intruder, but it immediately alerts us to their presence. In a world where we assume that a breach will eventually happen, early detection is a key element of damage limitation.
What actions can be taken on the device itself if updating is not an option?
While the main burden of defense lies with network controls, there are also some steps that can be taken on the vulnerable device itself to strengthen its protection. This process is called hardening, and involves disabling or limiting all unnecessary features and services to minimize the attack surface.
Many industrial devices have services enabled by default that are not needed for their normal operation, such as a web server for management, an FTP server or Telnet protocol. Each of these services is a potential entry point for an attacker. If they are not absolutely necessary, they should be disabled in the device’s configuration.
Other hardening measures include changing default passwords to strong and unique ones, limiting administrative access to trusted IP addresses only, or enabling built-in event logging mechanisms where possible. While these actions will not remove the software vulnerability itself, they can make it significantly more difficult for an attacker to exploit it.
Modern vulnerability management process in OT
StepActionDescription1. identificationAsset inventory and vulnerability identification.I know what I have and what security vulnerabilities my systems have.2 Risk AssessmentTechnical evaluation (CVSS) combined with physical process impact analysis.I understand what the real, physical consequences of exploiting the loophole would be.3 MitigationImplement appropriate compensating controls.I build protective barriers around the vulnerable system (segmentation, IPS, hardening).4 VerificationTesting the effectiveness of implemented controls.I check that my security features actually work and block attack attempts.5. planningPutting a physical update on the schedule for future work.I treat patching as a last resort and plan it well in advance.
How does the risk-based approach and compensating controls fit into NIS2 requirements?
The NIS2 directive does not mandate blindly patching all systems. Its key requirement is to implement “appropriate and proportionate technical, operational and organizational measures to manage risks.” An approach based on risk assessment and implementation of compensating controls is the ideal answer to this requirement.
Instead of blindly installing a patch that could jeopardize production, the organization conducts a documented risk analysis. In it, it demonstrates that it understands the threat, but instead of risky patching, it has implemented a number of alternative measures that are equally (and sometimes even more) effective, such as segmentation or virtual patching.
Such a documented process demonstrates the maturity of the organization. It demonstrates to auditors and regulators that the company is not ignoring the problem, but is managing it in a way that is informed, systematic and relevant to the specifics of its operating environment. This is the essence of proportionate risk management, the directive says.
How does nFlo help you implement a vulnerability management strategy tailored to your factory?
At nFlo, we understand that there is no one-size-fits-all solution to vulnerabilities in OT. Every production environment is different, and an effective strategy must be precisely tailored to an organization’s specific processes, technologies and risk appetite. That’s why our assistance goes far beyond simply scanning and generating reports with a list of vulnerabilities.
Our experts work with your IT and OT teams to first build a complete picture of your infrastructure. Using secure, passive technologies, we create a detailed asset inventory and communications map. Then, together with your engineers, we conduct a risk analysis workshop where we translate technical vulnerabilities into viable threat scenarios for your production processes.
Based on this analysis, we design and help implement an adequate set of compensating controls. Whether it’s redesigning network architecture, implementing industrial IPS systems, or creating hardening procedures, we provide hands-on expertise and engineering support. Our goal is to build a sustainable internal vulnerability management process for your company that is effective, efficient and acceptable to all stakeholders.
Does vulnerability have to mean weakness, or how to live with non-patchable systems?
The existence of vulnerabilities in a system is a fact, not a failure. In complex industrial environments full of legacy systems, achieving a state of complete absence of vulnerability is an impossible utopia. The key to success, then, is not to strive for an unrealistic ideal, but to redefine strength. Strength is not the absence of vulnerabilities, but the ability to manage the associated risks.
A vulnerability only becomes a viable weakness when it is readily available to an attacker and when its exploitation leads to catastrophic consequences. A mature vulnerability management strategy, based on compensating controls, focuses on breaking this chain. Even if the vulnerability exists, we make it inaccessible through segmentation. Even if it is available, we make its exploitation ineffective through virtual patching.
It is possible and necessary to learn to live safely with non-patchable systems. This requires moving away from the all-or-nothing IT dogma and adopting an engineering, pragmatic approach. Instead of fighting windmills, we are building intelligent, multi-layered defenses that allow us to maintain production continuity in a world where vulnerabilities have been, are and always will be present.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- Network Security — Network security is a set of practices, technologies, and strategies aimed at…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Firewall — A firewall, also known as a network firewall or security barrier, is a security…
- IT Security Management — IT security management is the process of planning, implementing, monitoring,…
Learn More
Explore related articles in our knowledge base:
- Comprehensive Vulnerability Management: Your organization’s proactive shield against cyber attacks
- Modular Structure of baramundi Management Suite – Flexibility and Efficiency
- Cyber Resilience Act (CRA): 3 vulnerability definitions you need to know
- Key Requirements of ISO 27001: The Road to a Certified Information Security Management System
- Privileged Access Management (PAM): 11 problems and solutions for IT security
Explore Our Services
Need cybersecurity support? Check out:
- OT/ICS Penetration Testing - industrial systems security
- OT/ICS Security Audit - industrial environment security assessment
- Vulnerability Management - continuous monitoring and remediation
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- baramundi Management Suite — baramundi
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
