Every article in this series has quietly depended on a switch behaving correctly. Passive asset discovery assumed the mirror port copied the traffic you needed. Segmentation testing assumed VLANs separated what they claimed to separate. Detection assumed the sensor saw every packet worth alerting on. If any of those assumptions is wrong, the work built on top of it is wrong too, and wrong in a way that is almost impossible to notice from the analysis side.
Industrial switches also tend to be the least examined devices on an OT network. They were commissioned by a systems integrator, they have run without complaint for eight years, and nobody has logged into one since. That combination – critical to everything, reviewed by nobody – is worth an audit on its own merits, before considering that the management interface is frequently reachable from places the firewall rules never contemplated.
This uses the environment from How to Build a Safe OT Cybersecurity Lab. If your lab is still fully virtual, most of this applies to a virtual switch; the port-level sections need physical or emulated hardware, and a second-hand managed switch is inexpensive and worth having.
Safety classification: Amber. This work involves authenticated access to network infrastructure carrying live traffic. Everything described is read-only, but read-only on a switch still means a login session on a device that, if disrupted, takes the process network with it. On a production site this needs authorisation, a window, and agreement that no configuration change will be made. Never save, commit or reload during an audit.
Why the switch is a security device
Ask what protects an OT network and the answer is usually the firewall. The switch is treated as plumbing. That framing is wrong in three specific ways, and each corresponds to a section of the audit.
The switch enforces segmentation below the firewall. VLANs separate traffic that never reaches a firewall at all. Two devices on the same switch in the same VLAN communicate directly, with no inspection, no logging and no possibility of a firewall rule affecting them. A great deal of OT traffic never crosses a routed boundary, which means the switch is the only thing separating it.
The switch is the source of your visibility. A SPAN or mirror session is the input to every passive technique in this series. A mirror configured for the wrong VLAN, one direction only, or a port that has since been repatched will silently degrade detection to the point of uselessness, and the sensor will keep running and reporting nothing wrong.
The switch has a management plane, and that plane is a path. A management VLAN reachable from the corporate network, on a switch that also carries the control VLAN, is a route around every firewall rule you tested. It is also routinely excluded from assessment scope, on the grounds that it is infrastructure rather than OT.
Start with the configuration, offline
The most productive part of a switch audit needs no access to the switch at all. Get a configuration export and read it away from the device.
Ask for the running configuration rather than the startup configuration, and get both if you can – the difference between them tells you whether somebody made a change that has not been saved, which will vanish at the next power cycle. On a Cisco IE-series device:
show running-config
show startup-configOn Hirschmann, Westermo, Moxa and similar, the equivalents vary but every managed switch has one. Where the site has a configuration backup system, take the archived version and diff it against the live one; unexplained differences are findings before you have read a single line.
Read the configuration for six things.
Management access. Which protocols are enabled? Telnet, HTTP and SNMPv1 or v2c transmit credentials and data in cleartext, and all three remain common on industrial switches because they were the defaults when the device shipped. SSH, HTTPS and SNMPv3 are the replacements. Note also whether management access is restricted by source address – an access list limiting management to a specific subnet is the control that matters most, and its absence is more significant than the protocol choice.
Credentials. Default and shared accounts are the norm rather than the exception. Look for the default username the vendor ships, accounts with no password ageing, and evidence that one credential is used across every switch on site. Check whether authentication is local only or backed by a directory, and if there is a directory, what happens when it is unreachable.
SNMP communities. Public and private survive in industrial environments to a degree that surprises people who have only worked in IT. A read-only community exposes the full device configuration and interface state. A writeable community is equivalent to administrative access.
Logging. Is syslog configured, and does it point somewhere real? A switch logging only to its own volatile buffer retains nothing across a reboot, which is precisely when you most want the logs. Check the buffer size and the configured severity level too – a switch logging only emergencies will not record an interface going up.
Time. Without NTP, timestamps on any log the switch produces are worthless for correlation. Check that NTP is configured, that the source is reachable from the switch’s VLAN, and that the time zone is recorded so that logs can be aligned with the historian and the firewall.
Unused services. Discovery protocols, HTTP servers, and vendor management agents left enabled from commissioning. CDP and LLDP are worth a specific note: they are genuinely useful for the asset discovery work earlier in this series, and they also broadcast device model and firmware to anything on the segment. That is a judgement call rather than a finding, but it should be a deliberate one.
Verify what the ports are actually doing
Configuration review tells you the intent. Port state tells you the reality, and the two diverge more than anyone expects.
Start with the interface summary and compare it against the site’s documentation:
show interfaces status
show interfaces trunk
show vlan briefThe first question is which ports are up. An enabled port with nothing plugged in is an open network jack, and industrial cabinets are not always locked. The second question is which ports are up that documentation says should be down, and the third is the reverse – a port the drawing says carries a device, showing no link, means either equipment is missing or the drawing is stale.
Then check what each access port is permitted to carry. A port assigned to the control VLAN that is also configured as a trunk carrying every VLAN is a segmentation failure hiding in plain sight, and it happens when somebody troubleshoots a problem by trunking a port and never reverts it.
The MAC address table is the strongest evidence available on a switch, because it records what has actually been connected:
show mac address-tableCross-reference every entry against the asset inventory from the passive discovery work. Addresses in the table that never appeared in your capture are devices that transmit rarely or that sit on a segment your mirror does not cover – either way, they are inventory gaps you would not otherwise have found. Count the entries per port too: a single access port showing multiple MAC addresses means something is bridging behind it, whether that is an unmanaged switch somebody added, a virtualisation host, or a laptop sharing its connection.
Check the port security configuration if any exists, and be honest in the report about how rarely it does. Sticky MAC learning with a violation action is a strong control on an industrial access port, where the connected device genuinely never changes. It is also almost never configured.
Validate the mirror session properly
This is the section that will change how you treat every capture you take afterwards.
Read the mirror configuration first:
show monitor session allThree things go wrong routinely. The session may be capturing the wrong source – a specific port rather than the VLAN, so you see one device’s traffic and believe you are seeing the segment. It may be capturing one direction, receive or transmit only, which halves every conversation and makes request-response analysis impossible. Or the destination port may have been repatched to something else entirely since the session was configured, in which case the sensor is receiving nothing and nobody has noticed.
Then validate it empirically rather than trusting the configuration. Generate known traffic between two devices on the mirrored segment and confirm you see both halves of it at the sensor:
# On the sensor, watching the mirror destination
sudo tcpdump -i eth1 -nn host 192.168.30.10 and host 192.168.30.20You should see requests and responses. Seeing only one direction is the single most common mirror defect, and it is invisible until you look for it.
Check for drops as well. A mirror session copying several ports onto one destination port can exceed that port’s capacity, and the switch discards the excess silently. Compare the packet counters on the source ports against what the sensor received over the same interval. Sustained loss means the mirror needs narrowing or the sensor needs a faster link, and it also means every baseline built from that capture is incomplete.
While you are there, confirm the sensor’s capture interface is still silent – no IP address, IPv6 disabled – using the check from the passive discovery article. A monitoring host that starts transmitting onto a mirror destination port is a problem that surfaces at the worst moment.
The management plane is part of the segmentation
Treat the switch’s management interface as a host in your reachability matrix, because that is what it is.
Establish which VLAN carries management traffic and whether it is separate from the data VLANs. In-band management on the same VLAN as the control network means anything on that network can reach the switch’s login prompt. Out-of-band management on a dedicated VLAN or physical port is better, but only if that VLAN is genuinely isolated rather than nominally separate and routed everywhere.
Then test reachability from each zone, using the approach from Can the IT Network Reach the PLC? Testing OT Segmentation Safely:
nc -vz -w 3 192.168.30.2 22
nc -vz -w 3 192.168.30.2 443
nc -vz -w 3 192.168.30.2 23Management reachable from the IT network is a finding regardless of how well the data VLANs are separated, because an administrator session on a switch can reconfigure the VLANs themselves. This is the path around the segmentation rather than through it, and it deserves the same weight in a report as a direct route to a controller.
Check the firmware version as well, and check it against the vendor’s advisories rather than assuming currency. Industrial switch firmware is updated rarely – the device is doing its job, an update means an outage, and the outage needs a window. That reasoning is understandable and it results in devices running firmware with published, unpatched vulnerabilities for years. Record the version, the current release, and the advisories affecting the gap, and let the site make an informed decision rather than an implicit one.
Spanning tree, and the failure mode nobody plans for
Spanning tree is not usually thought of as a security control, but its misconfiguration produces outages that look exactly like attacks, and industrial networks are unusually exposed to it.
Check where the root bridge is:
show spanning-treeThe root should be a deliberate choice, usually a core switch, set by priority. Where priorities were left at default, the root is whichever device has the lowest MAC address, which is to say an arbitrary one – frequently an access switch in a remote cabinet. A network whose spanning tree topology was decided by accident will reconverge in ways nobody predicted when a link fails.
Look for BPDU guard on access ports. Without it, anything plugged into an industrial cabinet that speaks spanning tree can influence the topology, and a cheap unmanaged switch added by a contractor to gain a few extra ports can trigger a reconvergence that drops control traffic for several seconds. On a process network, several seconds is an event.
Many industrial networks use vendor-specific ring protocols instead – MRP, HIPER-Ring, Turbo Ring and others – because they reconverge far faster than standard spanning tree. Where one is in use, the audit question is the same: is the ring configuration deliberate, documented, and does the redundancy actually work? A ring with a broken redundant path is a single point of failure that reports itself as healthy.
Writing it up
Separate what you found into three categories, because they need different responses.
Configuration weaknesses – cleartext management, default credentials, missing logging – are straightforward to remediate and belong in a prioritised list with the specific commands or settings involved.
Architectural findings – management reachable from IT, a trunk port where an access port belongs, a mirror that has never worked – require change control and probably a window. These are the ones that need to be expressed in operational terms to get funded: not “SPAN session 1 has a misconfigured source” but “the monitoring system has been blind to sixty percent of control traffic since installation”.
Documentation gaps are the third category and the easiest to dismiss. A MAC table entry with no corresponding device on the drawing, a port that is up with nothing documented on it, a firmware version nobody could confirm – each is a small thing that indicates the site’s picture of its own network has drifted from reality. Collected together, they usually make a stronger argument for an asset management programme than any individual technical finding.
Include what you did not examine. A switch audit bounded to the devices you were given access to, during the window you were given, is a legitimate result provided the boundary is stated.
What comes next
This completes the lab series: the environment, passive discovery, the protocol, segmentation testing, baselining, detection, and now the infrastructure underneath all of it.
The thread running through every one of those articles has been the path nobody documented – the vendor appliance, the dual-homed workstation, the management VLAN with a route it should not have. That is the natural subject to take up next: remote access into OT environments, how it is actually implemented at most sites, and how to assess it.
When did somebody last log into your industrial switches?
Managed switches enforce segmentation, feed monitoring systems and hold a management path into the control network. At most sites they were configured once, at commissioning, by somebody who has since moved on.
CyberLabs OT security assessments examine network infrastructure alongside segmentation, remote-access pathways, industrial device exposure and monitoring controls, while accounting for operational availability and recovery requirements.