Any-any firewall rules in OT

An any-any rule allows traffic from any zone to any zone, for any application. It is the broadest allow a firewall can hold. On a boundary between IT and OT, one enabled any-any allow means the boundary allows everything the rules above it do not catch, so the segmentation exists on paper only.

How any-any rules get there

Few are designed. Most are left behind:

• Cutover leftovers. A rule added to keep production running during a migration, marked for deletion and still enabled months later.
• Troubleshooting. An allow added to rule out the firewall while chasing a fault, then forgotten.
• “Temporary” vendor access. A broad rule so a vendor can connect during commissioning.
• Copied templates. A default policy carried from an IT firewall to an OT one.

Rules with an any source, an any destination or an any application on their own are related problems. They are narrower than any-any, but each one still allows more than the conduit needs.

Why any-any fails an OT firewall review

IEC 62443-3-3 SR 5.2 (zone boundary protection) asks for communication at zone boundaries to be monitored and controlled, and its first requirement enhancement, deny by default and allow by exception, applies from SL 2 upward. An any-any allow is the opposite: allow by default. SR 5.1 (network segmentation) asks for control system networks to be segmented from other networks, which a rule that joins every zone to every other undoes. The IEC 62443 guide covers both requirements.

NIST SP 800-82r3 section 5.2.3.1 recommends segmenting and isolating IT and OT devices. In the SP 800-53 controls of its OT overlay, an any-any allow works against SC-7 Boundary Protection and AC-4 Information Flow Enforcement. The NIST SP 800-82r3 guide has the section-by-section view.

The Purdue model is a reference model rather than a standard, but it makes the problem easy to see: a firewall cannot keep traffic between adjacent levels if one rule names no zones, hosts or applications.

Does it carry traffic?

The rulebase alone cannot answer this, and the answer changes the risk.

• With live hits, production may depend on the rule. Removing it outright can stop a line. The traffic log shows which flows use it, so each can be kept with a named rule or cut on purpose.
• With no hits in a log window long enough to cover batch, maintenance and outage traffic, it is standing exposure: nothing uses it yet, and it allows anything that tries. It can usually be retired.

Logging matters here. An any-any rule with logging off hides what it carries. Turn logging on for the rule and collect a log window before deciding.

Replace it without breaking production

1. List what the rule carries. From the traffic log: sources, destinations, applications and ports, per site.
2. Decide each flow. Keep the flows production needs, through the right path (a jump host or a historian replica in the IDMZ, for example). Cut the rest.
3. Check what sits below it. Unused allow rules lower in the rulebase may have no hits only because the any-any matches first. If the any-any is narrowed first, those rules become the live path. Disable them before or with the change.
4. Add the named rules, then retire the any-any. Do it in a change window with a rollback ready. Name zones, hosts and applications, and end the rule set with a logged deny.
5. Verify with the next log. Confirm the kept flows still pass and nothing new matches the logged deny unexpectedly.

How SegAudit reports any-any rules

SegAudit flags an enabled any-any allow that matches traffic as a critical finding, with the sessions, sources, destinations and applications behind it, the sites whose device groups carry the rule, and the controls it relates to: IEC 62443-3-3 SR 5.2 and NIST SP 800-82r3 section 5.2.3.1 (SC-7, AC-4). Unused rules that would inherit the traffic are flagged as a priority trap on the same finding.

In the Northline sample (a made-up three-site company that ships with SegAudit), the rule “allow-any-temp”, described as a cutover leftover with logging off, matches traffic at all three sites. The finding lists 26 sessions in the log window, including TeamViewer sessions from site hosts to an internet address. The finding’s recommendation reads: “Replace any/any with named zones, address groups, and application-default. Keep a logged deny at the bottom of the device-group.” It also names four unused rules, among them allow-telnet-legacy and allow-ftp-recipes, that would inherit the traffic if the any-any were changed first. The change package handles it as one change across the three sites (“Replace allow-any-temp at 3 sites with parent rules”), with the order of steps, the commands, and the rollback.

To see what SegAudit catches in one of your own exports, run the free Quick check. The sample deliverable shows the full report.

Common questions

Is an any-any deny rule a problem? No. A deny at the bottom of the rule set, with logging on, is what deny by default looks like. The problem is an any-any allow.

Can an any-any allow stay if a risk owner accepts it? That is the asset owner’s decision. If they accept it, record who decided, why, and until when, and keep the rule’s logging on. SegAudit can exclude a rule that carries an accepted-risk tag from the score and the change package, and the report shows it as accepted.

Is a rule with any application but named zones fine? It is narrower, but still broader than the conduit needs. A review should list the applications the traffic log shows on that conduit and name them in the rule.