Documentation · 05

Annex D - Firewall config register

Annex D: firewall configuration register, conduit-by-conduit rules, change control.

Annex D — Mutual Firewall Configuration Register

Referenced by MSA § 4.6 and § 8.3. Both sides disclose firewall configuration; each side administers its own. This annex is the shared register of what each side has agreed to enforce. Changes require pre-commit notification under § 8.3.


Two firewalls, not one

A common misreading is that the “IT/Manufacturing Operations firewall” is one device with two interfaces. It is not. Per MSA § 4.2 and § 4.6:

  • Manufacturing Operations Firewall — administered by MO, lives between the One Big Switch and the IT layer-3 switch on the MO side of the boundary.
  • IT Firewall — administered by IT, lives on the IT layer-3 switch facing MO downlinks.

Each side configures its own. Neither side touches the other’s. The register below records what each side has committed to enforce, so the other side can plan against it.


Baseline ruleset — Manufacturing Operations Firewall (per MO network)

Inbound from IT side, default deny. Explicit allows only:

#DirectionSourceDestinationProtocolPortPurpose
1IT → MOIT services-gateway addressMO services server .2TCP53, 443DNS pull (authorized records), schedule pull
2IT → MOIT services-gateway addressMO services server .2TCP1883, 8883MQTT subscribe (authorized topics only)
3IT → MOIT services-gateway addressMO services server .2TCP514, 6514Syslog pull
4IT → MOIT NTP sourceMO services server .2UDP123Time sync (MO is authoritative for its network)
5IT → MOIT monitoring hostMO services server .2ICMPReachability check (MO grants this; reverse is also required)

Outbound from MO to IT — these are the testability and publication paths MO needs:

#DirectionSourceDestinationProtocolPortPurpose
6MO → ITMO services server .2IT layer-3 switch downlinkICMPReachability test (per § 3.5)
7MO → ITMO services server .2IT layer-3 switch downlinkUDP/TCP33434–33534Traceroute (per § 3.5)
8MO → ITMO services server .2IT publication endpointTCP443Asset inventory push / link-quality pull
9MO → ITMO controller subnetPeer MO controller subnet via ITUDP(interlock-specific)Long-distance interlock traffic per Annex B

Hard denies — MO Firewall blocks unconditionally:

#DirectionSourceDestinationProtocolPortReason
D1IT → MO*MO controller subnetUDP67, 68Block DHCP from IT side (MSA § 3.8)
D2IT → MO*MO controller subnet** (broadcast)Block IT broadcast traffic into MO
D3IT → MO*MO IO subnets 192.168.x.x**IO subnets are never reachable from IT
D4IT → MO*Any MO host except services server .2**All inbound terminates at services server; no direct controller access from IT
D5IT → MO*MO DHCP serverUDP67, 68Even queries are denied; per § 3.8
D6IT → MO*MO services server .2TCP22No SSH from IT side. MO admin is from inside MO only

Inbound from MO side, default permit-with-policy (the IT side is the “carrier,” MO is the customer):

#DirectionSourceDestinationProtocolPortPurpose
1MO → ITMO services server .2IT services-gatewayTCP443Asset publish, link-quality pull
2MO → ITMO services server .2IT layer-3 switchICMPTestability (IT must allow per § 3.5)
3MO → ITMO services server .2IT layer-3 switchUDP/TCP33434–33534Traceroute (IT must allow per § 3.5)
4MO → IT (transit)MO controller subnetPeer MO controller subnetUDP(interlock-specific)Long-distance interlock — IT transits, does not inspect payload
5MO → IT (transit)MO services server .2Peer MO services server .2TCP/UDPvariousCross-MO published services per § 6

Priority enforcement on IT side (per MSA § 3.2):

ClassMatchPriorityBehavior
CS-HIGHAnnex B-registered interlock 5-tuplesHighestReserved bandwidth, never shed
CS-NORMALMO cross-boundary published servicesHighBest-effort with bias
IT-NORMALAll other IT backbone trafficNormalStandard QoS

Hard denies — IT Firewall blocks unconditionally:

#DirectionSourceDestinationProtocolPortReason
D1IT → MOIT side host (any)MO controller subnet** (except permitted in MO inbound rules)IT side does not initiate to MO except via MO inbound allowlist
D2IT → MO*MO IO subnets 192.168.x.x**IO subnets never advertised, never routed
D3IT (transit)*Any** (broadcast/multicast from IT)No IT-originated broadcast/multicast enters any MO downlink

Per-network overrides

If a Manufacturing Operations network needs an exception (e.g., a vendor remote-support session for a specific PLC), it goes in this section as a time-bounded exception with explicit start/end timestamps, scope, and approver from both sides.

Active exceptions

(none — fill as registered)

Recently expired exceptions

(none — fill as expired)


Disclosure cadence

  • At commit time: Either side proposing a rule change posts the diff to the joint register 14 days before commit (per § 8.3 and § 3.7 where applicable).
  • At quarterly review: Full rule tables for both sides are re-reviewed at § 8.1 joint review. Drift between this annex and the actual running config is itself a § 7 Minor Incident.
  • At incident: After any § 7 Major Incident, the affected firewall configuration is snapshotted and attached to the incident record.

What this register deliberately does not contain

  • Vendor-specific syntax. This is policy intent, not config files. Each side translates these rules into their own firewall vendor’s language. The intent is what’s binding.
  • Encryption keys, certs, or credentials. Those live in the respective domain’s secret store, never in this register.
  • The DMZ. Per MSA § 1.3 and § 8.4 — the DMZ is an IT-internal construction protecting IT-from-IT. It has no role here and no rules in this annex.

Open items

  • IT-side QoS implementation. § 3.2 priority enforcement requires per-interlock 5-tuple matching on the IT backbone. Many IT shops do not have this baseline. Joint review to identify what IT needs to upgrade.
  • Symmetric path enforcement. Currently nothing in this register prevents asymmetric routing of interlock traffic on the IT side. Annex C § 1.4 flags this as a traceroute check; it should ideally be enforced rather than detected.
  • Exception process formal SLA. Time-bounded exceptions are described above but the approval/rollback workflow is not yet defined. Add at first real exception request.