Camera VLAN Pivots Into OT Management
A manufacturer segments its LAN Edge with a FortiGate 601F and FortiSwitch 448D access switches. VLAN 10 is management (OT servers, hypervisors), VLAN 60 is IP cameras, and VLAN 70 is guest Wi-Fi. The FortiGate has one policy: LAN-to-LAN, source all, destination all, action accept, with no security profiles. A camera vendor installed a new NVR on VLAN 60 with a static 10.60.0.50/24 and enabled a cloud feature. Within a week, the OT team reports SMB scans from 10.60.0.50 to 10.10.0.0/24. The camera VLAN has no switch ACL and no 802.1X; cameras use MAC authentication bypass only on two ports. The customer wants to keep vendor remote support but stop east-west traffic.
1. What immediate containment steps would you take on the FortiGate and switches, and in what order?
Read the worked answer
Contain first, then preserve evidence. On the FortiGate, create address objects for the camera subnet and for the OT management subnet. Insert explicit deny policies above the existing any-any LAN-to-LAN rule for camera-to-management and camera-to-other internal RFC1918 destinations, with logging enabled. Keep only the flows the cameras and NVR actually need, such as NVR-to-camera and camera-to-specific cloud endpoints. Policy order matters: a deny below an accept-all policy will never be evaluated. At the switch, apply an ingress ACL on the camera-facing ports to deny RFC1918 destinations except the approved NVR or gateway, or move those ports into a dedicated isolated VLAN. If the NVR is actively scanning, isolate its port first, then collect logs and packet captures before wiping or rebuilding it. Do not rely only on ARP inspection or DHCP snooping; those do not stop routed east-west traffic.
2. Design a durable segmentation model for cameras, OT management, and guest, including FortiSwitch and FortiGate controls. How would you verify it?
Read the worked answer
Use separate VLANs and FortiGate zones for cameras, OT management, and guest, with a default-deny inter-zone posture. Allow only documented flows: NVR to cameras, vendor support to the NVR through a controlled path, and cameras to specific cloud endpoints if required. Do not allow camera-to-OT or guest-to-any-internal traffic. On the FortiSwitch side, add ingress ACLs on camera ports as defense in depth, enable 802.1X or MAB with dynamic VLAN assignment where practical, enable port security, and use DHCP snooping and dynamic ARP inspection where the platform supports them. Put unmanaged cameras on a dedicated IoT VLAN with no routing to OT.
Verify with policy hit counters and logs, switch ACL counters, packet captures, and an authorized scan from the camera VLAN to the OT subnet. Test both the permitted NVR flow and a denied camera-to-OT flow. Review the FortiGate policy order to ensure no broader rule shadows the denies, and confirm that guest isolation is enforced at both Layer 2 and Layer 3.
3. The vendor needs remote support. How do you provide it without restoring east-west access?
Read the worked answer
Provide a narrow, authenticated path. Use SSL VPN or ZTNA with MFA for vendor accounts, restrict source addresses where possible, and create a firewall policy that allows only the specific management protocols and destinations the vendor needs, such as HTTPS or RDP to the NVR, not the entire camera VLAN or OT subnet. If the vendor requires a site-to-site connection, use a VPN with granular routes and firewall policies rather than a broad tunnel. Use time-limited accounts, approval workflow, and full logging.
For the cloud feature, identify the actual destinations and allow only those FQDNs or IPs from the NVR, with IPS and SSL inspection where appropriate. Do not create a broad port forward or an any-any rule. Verify with a vendor test session, policy logs, and a scan from the vendor path that confirms OT management remains unreachable. Review the vendor access after the support window and disable it when no longer needed.