From critical to controlled: Cutting vulnerabilities in a live manufacturing environment

A vulnerability scanner flags a critical CVSS 10 vulnerability on an industrial asset. The report lands in the boss’ inbox and now he wants to know why we’re sitting on a critical vulnerability. In a normal IT environment, you patch it then close the ticket and call it a day. If, however, you’re in OT or dealing with ICS in a live manufacturing facility, it’s rarely that simple.

Here’s framework I use to answer the question “Does this finding represent an exploitable vulnerability in our environment”:

1. Confirm the device exists and is in use
2. Verify the vulnerable function installed or enabled
3. Check if it’s reachable on the network
4. Take note of the virtual and technical mitigations already in place
5. Trace the exploitation path and feasibility
6. Determine if risk acceptance is an option
7. If the finding is valid and exploitable, remediate it

Start with your inventory

The first thing you’ll need before you even get started is an accurate and up-to-date inventory. Small facilities can usually manage this with a spreadsheet or a simple asset management tool. Larger facilities with thousands of PLCs, hundreds of SCADA computers, HMIs, and who knows how many switches and firewalls, manually keeping track is difficult and clumsy. I prefer using something that automatically scans your entire footprint and network for this rather than relying on a person to record a change or addition.

Now that you have your inventory sorted out, you’ll be able to look up the device with the critical finding and see all the info about it. Does this device exist at the IP and location the finding says it does? ICS is notorious for changing networks, going off the network, or simply being changed without notifying anyone. Check how long the device has been there, when it was patched last, and what network segment it is on. Is it on the PLC network, is it on a NAT’d network, or is it a flat VLAN where everything is talking to everything?

If the device is where your vulnerability scanner says it is and it’s reachable from IT equipment or especially if it’s accessible from the internet, you have a problem. There’s a lot of times when I’ve found an asset is presented as vulnerable but it’s not accessible even by local machines due to firewall rules or some other mitigation. If there are mitigations or it’s isolated, that’s the first evidence this might be non-exploitable.

Verify the vulnerable function is actually present

Vulnerability scanners will often note “We have not tested for these issues but instead relied only on the application’s self-reported version number”. This essentially means that the scanner saw an app, looked at the version number, and then saw there was a CVE for that version.

I ran into an example of this recently when a report showed seven different versions of Adobe and all of them had some vulnerability. When I looked at the user’s computer, I couldn’t find evidence of the older versions. I rebooted then retested and those findings disappeared. In an OT environment verifying this by hand could mean waiting for a scheduled outage or some downtime which could be several weeks. If you can’t verify the existence of the vulnerable software or component because you’re waiting on downtime, don’t let it stop you from continuing down the path.

Network reachability and existing mitigations

This section will help you determine whether it can be exploited or not. Can you reach the asset from your IT or Office network? If so, that is a viable path to exploitation. The issue with manufacturing is you have the OT network set up to reach internet resources or you have it set up for vendors to be able to remote in and help with resolving issues.

This introduces an entirely new element to the equation. Your asset is reachable from the internet which means anyone with an internet connection can reach it. How do you mitigate that? You need very specific firewall rules and access control. Take a look at shodan.io and see if your public IP addresses are on there and what shows up. That’ll give you a better idea about your exploitability. Best way to mitigate external exploitation is to make sure the asset is not able to connect to external resources and prevent inbound access from unauthorized sources.

The best mitigations for this context:

Network segmentation with controlled access: Ideally you’ll have a DMZ with a jump box or jump server in between the IT and the OT networks. Properly configured, this adds layers of authentication meaning any vulnerability that is unauthenticated can’t pass the extra layers.

Access control at the firewall and on the asset: A lot of OT networks were cobbled together and it’s difficult to find them with proper DMZ and jump servers. In this case, it’s best to use the firewall ACL and possibly the asset has a firewall you can configure as well. It’s usually simple to block a specific port or IP address using these methods.

Strong and unique passwords: Default accounts, admin accounts with no sign in, vendor accounts, etc. These are usually left alone or not checked. Check these to make sure they’re either deactivated or properly credentialed. Passwords need to be a long series of words called a “Passphrase”. Instead of using the simple repeated passwords create one like this: TheGrassIsGreenerOnTheOtherSide. Use a password manager to keep up with them.

Verify the exploitation path

This can be difficult because not every vulnerability has a straightforward path for exploitation. Work through how this particular CVE is exploited. Check the write-ups for attach paths. Does it require a specific port? A specific service or software to be running?

Take this CVE for example. CVE-2025-27495 which is a CVSS 9.8. Attack path is pretty straightforward for this one. Port 8000 is open by default and an attacker doesn’t need anything other than the ability to send something over that port from the internet to the server to gain control, wipe the server, or pivot into the OT network.

For a vulnerability like this, the immediate actions would be:

• Block port 8000 at the firewall for any traffic not explicitly required for the server to function.
• Patch the software. Try to arrange a maintenance window to patch the software. Note that patching in OT environments can be risky if you don’t have a test or dev environment to test patches. Make sure you have a recent backup of the server so you can restore if the patch breaks it.
• Verify the server is correctly segmented on the network. It should only be able to talk to the assets it controls or needs information from.
• Verify all accounts on the computer have the least amount of privileges possible to function.

If you got these mitigations in place, you should document it and now you have something to show your boss.

Can you accept the risk until you can fix it?

Sometimes the asset is vulnerable, it’s exploitable, and you aren’t going to be able to mitigate or remediate it for a while. If it’s a PLC, you won’t get any time to patch it especially on short notice. If it’s a Windows XP computer or HMI there’s no patch available for it. What do you do in this case? In these cases, you’re not choosing between doing nothing and remediation.

Risk acceptance is a formal process involving IT and OT leadership, operations, and legal. There should be a written record of the risk acceptance that includes what the risk is, what compensating controls are in place (examples: enhanced monitoring, extra checks on logs and traffic, add an extra layer of protection), who is responsible for the controls, and a hard date for re-evaluation.

Putting it all together

The goal of this isn’t to explain away every finding. The goal is to give you some tools to be able to answer the question “Is this exploitable in my environment with what I have in place” and to give you the starting points to resolve the issue or mitigate it if it is exploitable. A CVSS 10 buried three networks deep being two firewalls with proper ACLs in place is completely different than a CVSS 10 on a flat network accessible by anyone on the internet and a default password.

Documentation will be your friend. Work through each piece of the puzzle and document what you have in place: Inventory, accounts, passwords, and so on. You’ll be able to create dashboards, executive summaries, and other pieces of information to show the leadership where the gaps are.