Flat Network, Flat Arguments

Sequence by risk reduction per unit of disruption, and by dependency.

1. Segmentation around OT first - delivered by the NGFW, but the firewall is the tool, not the goal. Define zones: plant floor/OT, engineering, corporate, DMZ. The first iteration is monitoring-only: policy that logs what would have been blocked, with no inline enforcement. This directly answers the pen test - four hops to an HMI should become zero without a conduit rule - and gives the plant the visibility it lacks.
2. SSO plus MFA for the BI platform. Low blast radius, high value: it centralizes identity and creates an audit trail for a system that will hold plant and financial data. Requirements: signed SAML assertions, MFA for all users, conditional access for administrators, and a documented exception process for service accounts.
3. TLS decryption last, and selectively. This is the item most likely to cause an outage and most likely to trigger a privacy conversation. Certificate-pinned applications, the HMI vendor's support tunnel, and the new BI app will break. Scope it with a bypass list, exclude health and finance categories, and run it in monitor mode first.

The firewall refresh should be staged so segmentation policy exists before the old edge is decommissioned - otherwise you replace a box without changing the architecture.

It changes the target from 'enforce now' to 'observe now, enforce at the window.'

• Passive visibility first. SPAN ports or a TAP on the OT switches feeding an OT-aware monitoring tool. No inline device, no changed traffic path, no window required.
• Build policy from observed traffic. Three to four weeks of data produces the real conduit matrix - which engineering workstation talks to which PLC on which port. That becomes the rule set proposed at the window, pre-agreed with the plant and with a rollback plan.
• Enforce what does not touch the line. Blocking corporate-to-OT, restricting internet egress from the plant VLAN, and locking down the admin plane can often be done without affecting production traffic. Verify with the plant engineer rather than assuming.
• Compensating controls in the meantime: restrict RDP and SMB into the OT segment to jump hosts, tightly ACL or disable the vendor support tunnel between sessions, enable EDR on engineering workstations, and alert on new devices appearing on the OT VLAN.
• Negotiate an emergency window for any genuinely critical finding. A five-month gap is an accepted risk and should be documented with the plant manager's name on it, not absorbed silently by the security team.

The design principle: never let a change-management constraint push you toward an untested big-bang cutover at the window.

Option 1 - Broker the transfer. The HMI writes to a local directory on the OT side; a one-way agent or scheduled task pushes to a hardened file server in a DMZ. The HMI never speaks SMB to corporate. Requires a small change to the batch-record process, which the vendor may resist.

Option 2 - Narrow the pipe. Allow SMB only from that specific HMI to a single dedicated file server, SMB 3.1.1 with signing and encryption, least-privilege share and NTFS ACLs with no inheritance from corporate, and a firewall rule pinning both endpoints and ports. Log every connection.

Option 3 - Replace the mechanism. Vendor-supported SFTP drop or an API. Cleanest long-term; needs a vendor change request and lead time.

Recommendation: Option 2 immediately, Option 1 as the target state, Option 3 on the roadmap.

Reasoning: Option 2 is achievable at the firewall and file server without touching the HMI or the vendor's supported configuration, so it fits the five-month window constraint. But it still leaves a writable SMB path from a compromise-prone HMI into corporate - exactly the lateral path the pen test demonstrated. So treat Option 2 as interim, give it an expiry date tied to the next maintenance window, and start the vendor conversation for Option 1 now rather than after the next incident.