Flat OT Network in a Mixed-Use Tower
Northgate Properties operates a 14-floor mixed-use tower with roughly 1,900 IoT endpoints: BACnet/IP VAV controllers, Modbus RTU energy meters behind serial gateways, and Zigbee luminaires. A cloud BMS vendor reaches the building through one site-to-site VPN terminating at an on-premises gateway. The OT team has two engineers and no 24/7 coverage. Last month a facilities contractor plugged a personal laptop into a spare access switch port and scanned the flat /16 OT network; the scan reached the cloud gateway, but no alert fired. The CISO wants zero trust for OT within 90 days and has budget for one new control. Tenant comfort systems cannot be taken offline during business hours, and legacy VAV firmware cannot be patched until Q4. The vendor insists on persistent outbound sessions from the gateway for remote support.
1. With budget for only one new control, where should the team enforce its primary control, and what residual risk must be accepted?
Read the worked answer
Start with the demonstrated threat path: unauthenticated physical access to a flat OT network gives an attacker a direct route to building controls and the cloud gateway. With one purchase, fund NAC/802.1X with MAC authentication bypass and deny-all on unused access ports, because it closes that path and creates an OT endpoint inventory. On switches that already support ACLs, add no-cost segmentation: VAVs and luminaires in one VLAN allowed only to the BMS gateway; meters in another; contractor ports in a quarantine VLAN. This is risk-proportionate for 90 days, not full zero trust.
Residual risk remains substantial: a compromised VAV can still send malicious BACnet to its gateway; the vendor tunnel is a separate path; the Q4 firmware gap persists; and without monitoring, the next scan may also be silent. Document those as accepted risks with owners and review dates. Do not claim zero trust is achieved. A second-phase business case should fund OT monitoring or an industrial firewall at the cloud boundary, but the first dollar should go where an adversary already proved access.
2. How should the vendor's persistent outbound sessions be redesigned without breaking support?
Read the worked answer
Persistent outbound sessions are effectively a reverse tunnel: they traverse NAT and firewalls, and if the gateway is compromised, the vendor plane becomes a command-and-control or exfiltration path. Replace standing sessions with brokered, short-lived access. The vendor authenticates with MFA to a jump host or remote-access broker; authorization is per-case and time-bound; sessions are recorded; the gateway initiates only to the broker, not to an arbitrary vendor address. Use an allowlist of vendor source identities and require a ticket ID. Keep an emergency path for 24/7 support, but make it break-glass: noisy, time-limited, and reviewed.
The vendor will resist because scheduled access slows troubleshooting. Mitigate with response-time tiers: routine changes in daily windows; severity-1 incidents get immediate brokered access with on-call approval. Test the path quarterly. Rotate the gateway's tunnel credentials and put the gateway management interface on a separate VLAN. The goal is not to block support; it is to remove standing trust that the building cannot monitor.
3. What is a defensible decision for the unpatched VAV firmware?
Read the worked answer
Separate risk acceptance from neglect. Inventory the VAVs by firmware version, network exposure, tenant criticality, and known exploitability. For each group, apply compensating controls: put VAVs behind an ACL that permits only the BMS gateway; block BACnet WriteProperty from unauthorized sources; disable unused services and ports; monitor for unexpected writes or device restarts. If a VAV controls a critical tenant area and cannot be isolated, move its replacement or patch ahead of Q4.
Then write a time-bound risk acceptance: named owner, affected assets, rationale, compensating controls, Q4 patch date, and a review trigger if a new exploit appears. Do not accept “legacy firmware” as a blanket exception. If the vendor cannot supply a patch, require network isolation as a condition of continued operation and include replacement in the capital plan. The key judgment is that unpatched firmware is tolerable only when exposure is reduced and residual risk is visible to the business, not when the network is flat and unmonitored.