The Vendor Split-Tunnel Request
A storage vendor needs remote access to 14 Windows servers in a segmented OT-support VLAN for a six-week firmware project. They propose an IPsec VPN with split tunnelling enabled, because their management agent streams telemetry to their own SaaS and 'the tunnel breaks it.' Your concentrator enforces MFA with push notifications; last quarter produced three push-fatigue incidents, one of which a help-desk analyst approved. The 14 servers currently have no internet egress at all and no logging beyond Windows Security events. A change freeze starts in ten days, and the firmware fixes a remotely exploitable flaw in a device already reachable from the shop floor.
1. Approve, deny, or modify the split-tunnel request? Justify against the actual risk the tunnel is meant to mitigate.
Read the worked answer
Deny split tunnelling on the vendor's endpoint as proposed; restructure rather than refuse.
Split tunnelling means only corporate-bound traffic enters the tunnel, so the vendor laptop's internet traffic (and any compromise on it) never passes your inspection, while that same laptop still holds a route into your OT-adjacent segment. That is the worst combination: uncontrolled endpoint, controlled path inward.
Why the stated reason doesn't require split tunnelling The agent needs outbound 443 to the vendor SaaS, not a full-tunnel bypass. That is an egress requirement, which is solved at your perimeter, not by weakening the tunnel.
Better architecture, in order of preference
- Broker the access: vendor connects to a VDI/jump host you own inside the segment; no vendor device is on your network at all, and their SaaS traffic originates from your controlled egress.
- If VDI is not feasible for the firmware tooling, terminate the vendor in a dedicated, monitored enclave with full-tunnel VPN plus a restricting firewall rule set limited to the 14 hosts and the required ports.
Judgement The firmware flaw is a real, time-boxed exposure, so 'no access' is not a free option - but the compensating control is a broker, not a weaker tunnel. Six weeks is long enough to stand up a jump host.
2. Given the push-fatigue history, what identity and access controls would you require before any vendor access goes live?
Read the worked answer
The control failure to fix is human approval of prompts, not prompt strength.
- Number matching + geo/ASN context on the push. Pure 'Approve/Deny' pushes are what get fatigued; showing the request origin and requiring a code match breaks blind approval.
- Phishing-resistant credentials (FIDO2) for vendor accounts, issued to named individuals, not a shared vendor account. Shared accounts make the 'one approved push' problem unattributable.
- Conditional access: vendor identities may authenticate only from the vendor's published egress ranges and only during an agreed window; anything else is blocked outright rather than challenged.
- Just-in-time entitlement: accounts disabled by default, enabled per approved maintenance window, auto-expired. This shrinks the fatigue window to a few hours instead of six weeks.
- Session controls: recorded, time-limited sessions through the broker, with commands logged.
Judgement MFA fatigue only works when a human is asked to approve something they cannot verify. Every control above either removes the human judgement (block by source) or gives them something verifiable (number matching, origin). Also alert on repeated denied pushes - three incidents last quarter means the pattern is live, and denial storms are the precursor to the one that gets approved.
3. How do you satisfy the vendor's outbound 443 requirement without giving the 14 servers general internet egress?
Read the worked answer
Split the requirement into destination, direction, and inspection.
- Destination, not 'internet'. Get the vendor's published FQDN list and IP ranges in writing. If they cannot supply them, that is a finding about the vendor, not a reason to open egress.
- Egress only from the broker/enclave, never from the servers. Keep the 14 servers with zero egress; the collection point is the jump host or an internal relay that forwards to the vendor SaaS. This preserves the segmentation you already have.
- Allow-list at the firewall with SNI/FQDN enforcement and logging on the broker's path. Deny-all default, per-destination rules, byte counts reviewed daily for the first week.
- Log the path. You currently have no egress telemetry from that VLAN; add flow export from the broker so you can answer 'what left and when' later.
Judgement The right move is a one-way, destination-limited exception on a host you control, rather than bidirectional internet on 14 servers. Also note the change-freeze deadline: standing up the broker and the allow-list rule is a change, so raise it now - if the freeze blocks it, the fallback is to mitigate the shop-floor exposure by other means (segmentation of the device) until the vendor window opens.