When an OT engineer or plant manager brings a firewall assessment report to my desk, there is usually a moment of silence followed by a specific question: “Did we catch the bad stuff?” The assumption is that if the perimeter holds, the asset inventory is complete, and the access control lists (ACLs) are active, the network is safe. In IT, this logic often holds water because the attack surface is relatively standardized. In Operational Technology, however, this assumption is dangerous.
OT networks are not just data pipes; they are the nervous system of physical processes. A firewall rule that looks benign in a packet capture can trigger a catastrophic chain reaction when it interacts with legacy PLCs, SCADA historians, or proprietary protocols like Modbus TCP and DNP3.
At Red Trident, we do not just look at whether traffic is allowed or denied. We look at the intent behind the rule and the context of the industrial process. In our recent engagements, we have found that even when organizations invest heavily in next-generation firewalls and intrusion prevention systems (IPS), they frequently miss the subtle configuration gaps that leave critical control systems exposed.
The Invisible Gaps in Windows Audit Policies
One of the most surprising findings in our recent endpoint assessments is not related to the firewall rules themselves, but to the visibility gap on the endpoints connected to the OT network. You cannot protect what you cannot see, and you cannot monitor traffic if your endpoints are silently discarding the logs that tell you who did what.
In 2 of 2 endpoint assessments from the same industrial organization, we found that at least seven high-value audit subcategories were explicitly set to “No Auditing” on critical engineering workstations and operator interfaces. These categories included Process Creation, Process Termination, Credential Validation, Kerberos Service Ticket Operations, Kerberos Authentication Service, Detailed File Share, and Removable Storage.
Why does this matter for firewall audits? Because firewalls monitor network traffic, but they do not monitor local execution. If an attacker bypasses the perimeter firewall via a compromised remote access session or a malicious USB drive, the firewall sees nothing after that point. Without detailed Windows audit policies enabled on the endpoint, you lose visibility into process creation and credential validation. This creates a blind spot where lateral movement can occur without triggering any network-based alerts.
Our assessment records explicitly noted that this audit policy left major gaps in process, credential, Kerberos, file-share, and removable-media visibility. When we reviewed the firewall logs alongside these endpoints, we found that the lack of endpoint telemetry made it impossible to correlate network connections with actual malicious activity. The firewall showed a connection was allowed; the endpoint showed no record of the process that initiated it.
Protocol-Level Blind Spots in Industrial Traffic
The second major area where firewall audits fail is the assumption that “allowed traffic” equals “safe traffic.” Many industrial networks rely on legacy protocols like Modbus TCP and DNP3, which were designed for reliability, not security. These protocols lack native authentication or encryption mechanisms.
When auditing firewalls in OT environments, we often find that teams configure rules to allow “any” source to “any” destination on specific port ranges (e.g., TCP 502 for Modbus). While this may be necessary for initial commissioning, it rarely reflects the actual business need. In one engagement, we identified a firewall rule that allowed unrestricted Modbus write commands from the corporate IT network to the manufacturing execution system (MES) historian. This violated the fundamental principle of industrial segmentation outlined in IEC 62443, which mandates strict isolation between enterprise and control zones.
The risk here is not just unauthorized access; it is protocol abuse. Even if the traffic is “allowed,” a firewall that does not inspect the payload is blind to malicious commands. For example, an attacker could send a valid Modbus write request to a PLC, but with parameters that cause a pump to run at full speed or a valve to close unexpectedly. Without deep packet inspection (DPI) tailored to industrial protocols, the firewall treats this as legitimate business traffic.
We also frequently find issues with OPC UA configuration. While OPC UA is designed with security in mind, it is often deployed with default settings that prioritize ease of use over security. Firewalls must be configured to allow the specific TCP ports used by OPC UA servers and clients, but they must also ensure that the underlying TLS encryption is functioning correctly. If the firewall allows traffic on port 4840 without verifying the certificate chain, it may be permitting unencrypted communication that exposes sensitive process data.
The Remote Access Paradox
3
Secure remote access is the most overlooked exposure in industrial networks. As noted in recent research by Forescout and Vedere Labs, insecure remote access configurations are a leading cause of unauthorized access in industrial control systems. Over 70% of industrial networks lack multi-factor authentication (MFA) for remote access, according to their research.
In our firewall audits, we consistently find that the rules allowing vendor remote access are overly permissive. We see rules that allow SSH or RDP from any IP address on the internet to a specific engineering workstation, with no time-based restrictions or source IP whitelisting. This creates a massive attack surface for ransomware and other threats.
The problem is not just the rule itself, but the lack of compensating controls. If a firewall allows direct remote access to an OT asset, it must be accompanied by strong identity verification, session recording, and network segmentation. We often find that organizations rely on VPNs as the sole control, which is insufficient in today’s threat landscape. A firewall audit should explicitly review these remote access rules against NIST SP 800-82 guidelines for securing OT networks.
We also see a recurring issue with vendor support sessions. Vendors often require temporary firewall openings to troubleshoot issues, but these rules are rarely closed after the session ends. This “rule rot” leaves permanent backdoors in the network that attackers can exploit months or years later. A robust firewall audit must include a review of all temporary rules and their closure status.
Asset Inventory Drift and Rule Decay
The third critical finding is the disconnect between the asset inventory and the firewall policies. In OT environments, assets are constantly changing. New sensors are added, legacy systems are decommissioned, and temporary devices are brought in for maintenance. If the firewall rules are not updated to reflect these changes, the network becomes a patchwork of outdated permissions.
We have seen cases where firewall rules were created for a specific Siemens PLC model, but that model was replaced with a newer version that uses different communication ports. The old rule remained active, creating a false sense of security. Similarly, we find rules that allow traffic to IP addresses that no longer exist in the network, cluttering the policy database and making it difficult to identify genuine threats.
To address this, we recommend a continuous asset discovery process that integrates with the firewall management system. This ensures that rules are only applied to known, authorized assets. It also helps identify “shadow IT” devices that have connected to the network without authorization. In one engagement, we found a rogue wireless access point connected to the OT network that was not documented in the asset inventory. The firewall did not block it because it was operating on an unmonitored VLAN.
Validating Remediation Without Disrupting Production
The final challenge is validating these improvements without disrupting production. In industrial environments, downtime is not just an inconvenience; it is a financial loss and a safety risk. Therefore, any remediation strategy must be carefully planned and executed.
We recommend a phased approach to firewall rule optimization. Start by analyzing the traffic logs to identify allowed but unused rules. Move these rules to a “disabled” state rather than deleting them immediately. Monitor the network for several weeks to ensure that no critical processes are affected. Once confirmed, these rules can be safely removed.
For protocol-specific rules, work with the OT engineering team to define the exact requirements. Instead of allowing “any” Modbus write, restrict it to specific function codes and register ranges. Use application-layer gateways or industrial firewalls that can inspect and filter traffic at the protocol level.
Finally, establish a regular review cycle for firewall policies. This should include a quarterly review of remote access rules, a semi-annual review of asset inventory alignment, and an annual comprehensive assessment of the entire OT network architecture. This ensures that the security posture evolves with the business needs and the threat landscape.
Conclusion
Firewall audits in OT environments require more than just a checklist of allowed ports. They demand a deep understanding of industrial protocols, asset behavior, and operational priorities. By focusing on audit policy visibility, protocol-level inspection, secure remote access, and dynamic asset management, organizations can significantly reduce their risk exposure.
At Red Trident, we help industrial operators identify these hidden gaps and implement practical, effective security controls. If you are unsure whether your OT firewall policies are truly protecting your critical infrastructure, we invite you to schedule a free consultation with our team of OT cybersecurity experts.
