Vendor-Managed HVAC Controllers Reachable From the Corporate Subnet
Northline Foods runs a 240-employee food plant. An HVAC vendor manages three building controllers sitting on VLAN 40 (10.40.0.0/24) and connects remotely over a site-to-site VPN. The firewall rule for VLAN 40 permits any-to-any traffic between that subnet and the corporate 10.20.0.0/16 range, because the vendor said it needed to pull data. All three controllers share one local account, and the password is rotated every 180 days. Firmware is from 2019 and cannot be upgraded past TLS 1.0. Last week an internal vulnerability scan launched from the corporate subnet reached all three controllers and returned default SNMP community strings. Management asks whether to simply block the vendor VPN. The plant needs HVAC telemetry for its cold-storage compliance log, and stopping a controller during a production run carries an estimated $40,000-per-hour exposure.
1. Rank the three most significant risks in this design. Justify each ranking using likelihood and business impact rather than scanner severity alone.
Read the worked answer
Rank by likelihood x impact, not by CVSS.
Shared single-factor account on remotely reachable controllers. Likelihood is high: one password, no MFA, no per-device accountability. Credential reuse or a phished vendor laptop compromises all three controllers at once. Impact is high because those setpoints govern cold storage, the very asset the compliance log exists to protect. A silent setpoint change is worse than an outage, since spoilage may be detected only after product is released.
The any-to-any rule between VLAN 40 and 10.20.0.0/16. This converts two separate zones into one. Phishing lands on the corporate side constantly, so the rule hands an attacker a path into OT; conversely a compromised controller becomes a pivot into the corporate range. The successful scan and default SNMP strings are proof the path is usable, not theoretical.
Unpatchable 2019 firmware with TLS 1.0. Direct exploitation is less likely than abuse of items 1 and 2, but it removes every remediation option short of replacement, so it multiplies the other two rather than standing alone. Default SNMP strings belong here: read access exposes topology and setpoints, and in some stacks write access allows configuration change.
2. The plant manager wants the vendor VPN blocked today. Evaluate that decision and propose an alternative that preserves telemetry.
Read the worked answer
Blocking the VPN is a partial fix with a real cost. It removes the vendor path but leaves the any-to-any rule intact, so an attacker already inside 10.20.0.0/16 still reaches VLAN 40 directly; the scan you ran proves that path. It also stops telemetry, creating a compliance-log gap and leaving controllers unmonitored, and the first production hour of manual operation costs more than most of the controls proposed below.
A defensible alternative narrows the path instead of removing it:
- Replace any-to-any with an explicit rule permitting only the telemetry ports from one named source, ideally a hardened jump host in a management VLAN, never from the whole /16.
- Terminate vendor access at that jump host with MFA and per-engineer accounts, so the vendor's own laptop is never directly on the plant network.
- Create per-device credentials and remove default SNMP strings; move to SNMPv3 authPriv where the firmware supports it.
- Invert the flow where possible: have a collector poll controllers outbound, so no inbound hole is required for data pull.
- If the vendor only needs business-hours access, time-scope the rule and log every session.
Sequence matters: enable logging and flow visibility on VLAN 40 first, then tighten the rule, because you cannot investigate what you never recorded.
3. What evidence would you require before restoring broad vendor remote access, and how does each item reduce risk?
Read the worked answer
Require evidence that ties to each ranked risk, not a generic attestation letter.
For the credential risk: confirmation that the shared account is retired, a list of named vendor accounts with MFA enrollment, and the vendor's MFA enforcement policy for its own staff, since the weakest link is their endpoint. Ask for their last penetration test or SOC 2 scope statement covering the support team that touches your devices.
For the network risk: a firewall rule review showing only the required ports from the jump host, plus flow logs proving no other source reached VLAN 40 during a trial period. Thirty days of logs is a reasonable ask; a week is the minimum.
For the firmware risk: a written compensating-control statement, because the vendor cannot patch. Acceptable content includes network isolation, read-only data collection where writes are unnecessary, and a replacement roadmap with dates.
Finally, require that you retain logs of vendor sessions in your own SIEM, not theirs. Without that, everything above is unverifiable at the moment it matters, and you would be back to deciding between an outage and an unmonitored hole.