In most growing businesses the network devices are the least maintained equipment in the estate. Servers get patched, laptops get an endpoint agent, and the switches run whatever software was on them when they were installed, with a configuration assembled over several years by several people.
They are also the most privileged devices present. A switch sees every packet on its segments, a router decides where traffic goes, and administrative access to either allows an attacker to redirect, copy or interrupt anything crossing them — silently, from a position most monitoring does not observe.
The reason this gets deferred is that hardening a network device sounds unbounded. Cisco's own hardening guidance solves that by dividing a device into three functional planes, and the division turns one vague task into three short lists.
The three planes
Cisco's hardening guides describe a device as having three planes, each with different functionality and each requiring different protection.
| Plane | Handles | Examples |
|---|---|---|
| Management | Traffic sent to the device to manage it | SSH, SNMP, console, logging |
| Control | Traffic that keeps the network infrastructure functioning | BGP, interior gateway protocols, spanning tree, ARP |
| Data | Traffic forwarded through the device | Everything the users and servers send |
The distinction matters because the failure modes differ. Management plane weakness gives an attacker the device. Control plane weakness lets them redirect traffic without ever logging in. Data plane weakness lets one compromised host attack others through the network itself.
Management plane: who can reach the device, and how
This is where most real findings are, and where the fixes are cheapest.
- 1
Remove Telnet entirely
Telnet transmits credentials in plaintext. Anyone able to observe the segment obtains the enable password. Use SSH, and confirm Telnet is disabled rather than merely unused — an unused-but-enabled service is one configuration mistake from being used.
- 2
Restrict where management access is accepted from
Administrative access should be reachable only from a defined management network or jump host, enforced on the device rather than assumed from network topology. A switch that accepts SSH from any user VLAN is one compromised laptop away from an attacker at the login prompt.
- 3
Move authentication off the device
Local accounts on each device cannot be revoked centrally, so an administrator who leaves retains access to every device nobody remembered to change. Centralised AAA — TACACS+ or RADIUS — gives one place to revoke and one place to audit. Keep exactly one local fallback account for when the AAA server is unreachable, and treat its credential accordingly.
- 4
Fix SNMP
SNMP with a default or guessable community string is an information disclosure at best and a configuration change at worst. Use version 3 with authentication and encryption. If older versions must remain, make the strings unique and restrict them read-only and source-limited.
- 5
Send logs off the device
Device logs are small, overwrite quickly and are lost on reboot. Send them to a central collector with accurate time from NTP, because correlating a network event with a server event requires both clocks to agree.
- 6
Disable the management services nobody uses
HTTP administration, and any legacy discovery or configuration protocol left enabled by default. Every listening service is attack surface that provides no value if nothing uses it.
Control plane: protecting what keeps the network up
The control plane runs the protocols the network depends on to function. Two categories of protection matter for a business network.
The first is authentication on routing and redundancy protocols. Unauthenticated routing adjacencies accept information from anything that speaks the protocol, which allows an attacker on the segment to inject routes and pull traffic through a device they control. The same applies to first-hop redundancy protocols, where an unauthenticated device can claim to be the default gateway.
The second is protecting the device's own processor from being overwhelmed. Traffic destined for the device itself is handled in software, so a flood of it can consume the resources the device needs to keep forwarding. Control plane policing constrains that traffic to a rate the device can absorb, so the network stays up even under a management-plane flood.
- Authenticate routing protocol adjacencies rather than accepting any neighbour that appears.
- Authenticate first-hop redundancy protocols so nothing can claim to be the gateway.
- Apply control plane policing so device-destined traffic cannot starve forwarding.
- Where spanning tree is running, protect the topology — an unexpected device becoming root bridge redirects traffic and is a configuration mistake as often as an attack.
Data plane: limiting what one compromised host can do
The data plane carries user traffic, and the controls here address attacks between hosts on the same network — the lateral movement that endpoint software struggles to see and that a firewall at the perimeter never observes at all.
| Protection | Prevents |
|---|---|
| DHCP snooping | A rogue DHCP server handing out its own address as the gateway |
| Dynamic ARP inspection | ARP spoofing, and the traffic interception it enables |
| Port security | An unauthorised device plugged into a live wall port |
| BPDU guard on access ports | A device changing the spanning tree topology from a user port |
| Source address validation | Spoofed source addresses leaving the network |
| Disabling unused ports | Anything plugged in becoming a connected device |
DHCP snooping and dynamic ARP inspection are the pair worth prioritising, because they are the foundation of the classic on-network interception attack and because dynamic ARP inspection depends on the binding table DHCP snooping builds. Enabling one without the other gives partial protection.
One practical warning: these features drop traffic that fails validation, and a network with a static-addressed server or an unusual configuration can lose connectivity when they are enabled. Introduce them on one access switch first, with the necessary exclusions identified, rather than estate-wide in one change window.
Software maintenance, which is the part that gets skipped
Network device software is patched far less often than server software, for a straightforward reason: upgrading a switch means an outage, and there is rarely an obvious trigger.
The result is estates running software several years old with published, unpatched vulnerabilities in the most privileged devices present. This is worth treating as a scheduled obligation rather than an event.
- Record the current software version of every network device somewhere that is reviewed.
- Subscribe to the vendor's security advisories for the platforms you run.
- Establish which devices can be upgraded without an outage and which cannot, because that determines the window each needs.
- Keep configuration backups outside the device, and know when the last one was taken. Rebuilding a switch configuration from memory during an outage is avoidable.
A realistic order of work
- 1
Inventory the devices and their software versions
Including the small switch in the meeting room that nobody documented. It is on the same network as everything else.
- 2
Eliminate plaintext management and shared credentials
Telnet off, SSH on, centralised AAA, one documented local fallback. This is the highest-value change in this article.
- 3
Restrict management access by source
Management from a defined network only, enforced on the device.
- 4
Get logging and time centralised
Without this, nothing that follows is investigable after the fact.
- 5
Enable data plane protections progressively
DHCP snooping and dynamic ARP inspection together, one switch first, then outward.
- 6
Authenticate control plane protocols and apply policing
Then verify adjacencies still form, because a mismatched key produces an outage that looks like a hardware fault.
- 7
Put device software on the patch schedule
With named windows, the same way servers are treated.
What are the three planes in Cisco's hardening model?
The management plane handles traffic sent to the device in order to manage it, such as SSH and SNMP. The control plane handles the protocol traffic between network devices that keeps the infrastructure functioning, such as routing protocols. The data plane forwards traffic through the device. Each requires different protection, and the division is useful because it converts an open-ended hardening task into three short, checkable lists.
Why is centralised AAA better than local device accounts?
Local accounts exist independently on each device, so access cannot be revoked centrally. When an administrator or contractor leaves, their access persists on every device nobody remembered to change, and there is no single audit record of who did what. Centralised AAA using TACACS+ or RADIUS provides one place to grant, revoke and audit. A single documented local fallback account should remain for when the AAA server is unreachable.
What do DHCP snooping and dynamic ARP inspection protect against?
DHCP snooping prevents a rogue DHCP server from handing out its own address as the default gateway, which would route victim traffic through an attacker. Dynamic ARP inspection prevents ARP spoofing, which achieves interception by a different route. They belong together because dynamic ARP inspection validates against the binding table that DHCP snooping builds, so enabling one alone gives only partial protection.
Is Telnet acceptable on an internal network?
No. Telnet transmits credentials in plaintext, so anyone able to observe the segment — including a compromised workstation on the same VLAN — obtains administrative credentials for the device. Internal networks are exactly where this matters, because that is where an attacker who has gained a foothold is positioned. SSH should replace it, and Telnet should be explicitly disabled rather than merely unused.
How risky is enabling these protections on a live network?
Data plane protections drop traffic that fails validation, so a statically addressed server or an undocumented configuration can lose connectivity when they are enabled. Control plane authentication causes adjacencies to fail if keys are mismatched, which presents like a hardware fault. Both should be introduced on one device or one switch first, with exclusions identified, rather than applied estate-wide in a single change.
Sources and further reading
- Network segmentation for growing businesses— the segment design these device controls enforce
- Firewall strategy for growing businesses— the perimeter, and why it never sees the attacks in the data plane section
- A cybersecurity checklist for growing businesses— control 12, network infrastructure management, in context
- Security auditing: what the words actually mean— how these findings are typically discovered, and what to do with them
- Access control and offboarding— the shared enable password problem, in its wider form
- Secrets management for business systems— where the fallback credential should live
- Cisco: Harden IOS Devices— the three-plane model and per-plane guidance cited above
- Cisco IOS XE Software Hardening Guide— the equivalent guidance for IOS XE platforms
- Cisco NX-OS Software Hardening Guide— the equivalent guidance for Nexus platforms
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.