{"id":482235,"date":"2026-06-04T06:43:08","date_gmt":"2026-06-04T06:43:08","guid":{"rendered":"https:\/\/www.newsbeep.com\/ie\/482235\/"},"modified":"2026-06-04T06:43:08","modified_gmt":"2026-06-04T06:43:08","slug":"from-critical-to-controlled-cutting-vulnerabilities-in-a-live-manufacturing-environment","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/ie\/482235\/","title":{"rendered":"From critical to controlled: Cutting vulnerabilities in a live manufacturing environment"},"content":{"rendered":"

A vulnerability scanner flags a critical CVSS 10 vulnerability on an industrial asset. The report lands in the boss\u2019 inbox and now he wants to know why we\u2019re 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\u2019re in OT or dealing with ICS<\/a> in a live manufacturing facility, it\u2019s rarely that simple. <\/p>\n

Here\u2019s framework I use to answer the question \u201cDoes this finding represent an exploitable vulnerability in our environment\u201d: <\/p>\n

1. Confirm the device exists and is in use
2. Verify the vulnerable function installed or enabled
3. Check if it\u2019s 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 <\/p>\n

Start with your inventory<\/p>\n

The first thing you\u2019ll 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. <\/p>\n

Now that you have your inventory<\/a> sorted out, you\u2019ll 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\u2019d network, or is it a flat VLAN where everything is talking to everything? <\/p>\n

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

Verify the vulnerable function is actually present<\/p>\n

Vulnerability scanners will often note \u201cWe have not tested for these issues but instead relied only on the application\u2019s self-reported version number\u201d. This essentially means that the scanner saw an app, looked at the version number, and then saw there was a CVE for that version. <\/p>\n

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\u2019s computer, I couldn\u2019t 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<\/a> which could be several weeks. If you can\u2019t verify the existence of the vulnerable software or component because you\u2019re waiting on downtime, don\u2019t let it stop you from continuing down the path. <\/p>\n

Network reachability and existing mitigations<\/p>\n

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. <\/p>\n

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<\/a>. Take a look at shodan.io and see if your public IP addresses are on there and what shows up. That\u2019ll 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. <\/p>\n

The best mitigations for this context: <\/p>\n

Network segmentation with controlled access: Ideally you\u2019ll 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\u2019t pass the extra layers. <\/p>\n

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

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\u2019re either deactivated or properly credentialed. Passwords need to be a long series of words called a \u201cPassphrase\u201d. Instead of using the simple repeated passwords create one like this: TheGrassIsGreenerOnTheOtherSide. Use a password manager to keep up with them. <\/p>\n

Verify the exploitation path<\/p>\n

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? <\/p>\n

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\u2019t 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. <\/p>\n

For a vulnerability like this, the immediate actions would be: <\/p>\n

Block port 8000 at the firewall for any traffic not explicitly required for the server to function.
\nPatch the software. Try to arrange a maintenance window to patch the software. Note that patching<\/a> in OT environments can be risky if you don\u2019t 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.
\nVerify the server is correctly segmented on the network. It should only be able to talk to the assets it controls or needs information from.
\nVerify all accounts on the computer have the least amount of privileges possible to function.<\/p>\n

If you got these mitigations in place, you should document it and now you have something to show your boss. <\/p>\n

Can you accept the risk until you can fix it?<\/p>\n

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

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<\/a>, 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. <\/p>\n

Putting it all together<\/p>\n

The goal of this isn\u2019t to explain away every finding. The goal is to give you some tools to be able to answer the question \u201cIs this exploitable in my environment with what I have in place\u201d 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<\/a>. <\/p>\n

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\u2019ll be able to create dashboards, executive summaries, and other pieces of information to show the leadership where the gaps are.<\/p>\n","protected":false},"excerpt":{"rendered":"A vulnerability scanner flags a critical CVSS 10 vulnerability on an industrial asset. The report lands in the…\n","protected":false},"author":2,"featured_media":482236,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[122617,207590,3312,61,60,92983,2277,387,11629,80,207591],"class_list":["post-482235","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology","tag-access-controls","tag-asset-discovery","tag-cybersecurity","tag-ie","tag-ireland","tag-manufacturing-sector","tag-network","tag-opinion","tag-patching","tag-technology","tag-vulnerability-management"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/482235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/comments?post=482235"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/482235\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media\/482236"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media?parent=482235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/categories?post=482235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/tags?post=482235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}