Configuration Review
Configuration Review of Network Devices
Switches and routers are configured during installation and then left alone for a decade. They run management protocols nobody remembers enabling, hold credentials in configurations that get emailed during support calls, and enforce a VLAN design that stopped matching the organisation three restructures ago. The review covers the device, the protocols and the segmentation it is supposed to deliver.
Methodology
- 01
Configuration collection
Running configuration exported from every device in scope, with firmware versions, VLAN databases, routing tables and trunk configuration.
- 02
Management plane review
Administrative access methods, authentication source, protocol versions, source restrictions, banner and session controls assessed against the benchmark.
- 03
Protocol hardening review
Discovery, spanning tree, routing and redundancy protocols reviewed for authentication, and legacy protocols identified for removal.
- 04
VLAN and segmentation review
VLAN assignment, trunk configuration, native VLAN handling and access port security assessed against the intended network design.
- 05
Wireless review
Where in scope: authentication method, encryption, guest isolation, rogue detection and the PSK networks that remain from earlier deployments.
- 06
Firmware and lifecycle review
Versions correlated against vendor advisories, with end-of-support devices identified.
- 07
Reporting and retest
Technical report and executive summary together, with a change list sequenced by outage risk, then a retest confirming closure.
Approach to testing
- Offline analysis of exported configuration. Nothing is sent to the device, so the review carries no risk to a live network.
- Findings are assessed against the intended design, which frequently has to be reconstructed because no current diagram exists. Where that is the case, it is the primary finding.
- Every recommendation states outage risk. Changing native VLAN or spanning tree configuration on a production core switch is not a routine change.
- Legacy protocol removal is sequenced, not recommended wholesale, because something is always still using it and finding out during a change window is expensive.
- Where several vendors are present, findings are normalised so they are comparable rather than reported in three dialects.
Types of assessment
Configuration review (default)
Offline analysis of exported device configuration. No interaction, no risk.
Segmentation validation
Configuration review paired with active testing confirming the VLAN design behaves as written.
Wireless assessment
Controller configuration plus on-site survey: rogue detection, guest isolation and signal bleed beyond the premises.
Continuous configuration monitoring
Scheduled export and re-analysis so drift and emergency changes are caught rather than discovered annually.
Frameworks and standards
- CIS Benchmarks
- Cisco IOS, NX-OS, Juniper and Aruba baselines as applicable.
- Vendor hardening guides
- Manufacturer guidance, generally stricter and more current than the benchmark.
- NIST SP 800-53
- Control mapping where a compliance obligation applies.
- PCI DSS Requirements 1 and 2
- Where in scope, network segmentation and default configuration are assessed directly.
- IEC 62443
- Where the devices form part of an OT network's zone and conduit structure.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
Nipper
Automated device configuration audit against CIS and vendor baselines.
RANCID / Oxidized
Configuration collection and change tracking across the estate.
Custom configuration parsers
Normalising multi-vendor configuration into a comparable model.
Nmap / Yersinia
Active validation of segmentation and layer 2 controls, where authorised.
Aircrack-ng suite
Wireless assessment where a survey is in scope.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Management plane
- Telnet, HTTP and SNMPv1/v2c disabled
- SSH version and cipher configuration
- Management access restricted by source address
- Centralised authentication with fallback, and the fallback credential's strength
- Idle timeout, login banner and failed login handling
- Configuration archive and change tracking
Protocol hardening
- CDP and LLDP on untrusted ports
- Spanning tree: BPDU guard, root guard and loop guard
- Routing protocol authentication
- First-hop redundancy protocol authentication
- DHCP snooping, dynamic ARP inspection and IP source guard
- IPv6 present and unmanaged
VLAN and port security
- Native VLAN not VLAN 1 and not used for data
- Unused ports shut and in an unused VLAN
- Trunk ports explicitly configured rather than negotiated
- Port security and 802.1X coverage on access ports
- Voice and data VLAN separation
- Private VLAN usage where isolation is required
Wireless
- Authentication method and whether PSK networks remain
- Encryption standard and legacy cipher support
- Guest network isolation from corporate
- Rogue access point detection and response
- Management frame protection
- Signal coverage beyond the physical premises
Lifecycle
- Firmware version against vendor advisories
- End-of-support devices still deployed
- Configuration backup and restoration testing
- Logging destination, retention and time synchronisation
- Documented current network design
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Cross-device consistency is the finding that manual review misses: one switch of forty with a different native VLAN, or one with port security disabled. Exhaustive comparison across the estate finds the outlier.
Reconstructing the effective VLAN and trunk topology from configuration across dozens of devices is a graph problem rather than a reading problem.
Firmware-to-advisory correlation across many devices and thousands of advisories is lookup work that sampling gets wrong.
Unused port identification requires correlating configuration with interface state and last-input counters across every port in the estate.
Every agent finding is validated by a human reviewer, and each recommendation carries a stated outage risk. The swarm analyses exported configuration and never connects to a device.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
Outage risk stated for every change
Network change breaks things. Each recommendation carries an explicit risk and window requirement, which is what makes the report actionable rather than aspirational.
Estate-wide consistency, not device-by-device
Most reviews audit each device in isolation. The interesting finding is usually the one device configured differently from the other thirty-nine.
Both reports, always
Technical report and executive summary together, plus a change list the network team can work from.
Fixation, not a backlog
CSS works the change sequence with the network team through maintenance windows and retests to evidence closure.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Scope: devices, models, firmware versions and configuration export date
- Findings against CIS and vendor baselines with control references, per device
- Estate-wide consistency analysis identifying outlier devices
- Reconstructed VLAN and trunk topology against the intended design
- Firmware correlation with vendor advisories and end-of-support devices
- Change list sequenced by outage risk and window requirement
- Retest results appended against each original finding
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- Whether the network enforces the segmentation the organisation believes it does
- Devices out of support, and what replacing them would involve
- The three changes that most reduce exposure, with outage risk stated
- Compliance position where PCI DSS or an ISMS applies
- Remediation timeline and retest date
- One page
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
A hospital group with 62 switches across four sites.
- Finding
- Estate-wide comparison found 58 devices consistently configured and four — all in one recently refurbished wing — still running the vendor default with Telnet enabled, SNMP community strings of public and private, and no management source restriction.
- Recommendation
- Bring the four devices onto the standard template, and add a post-installation verification step to the refurbishment process so a device cannot enter service on defaults.
- Outcome
- Devices corrected within a week. The verification step has since caught two more during a subsequent project.
A manufacturer where corporate and plant networks were believed to be separated.
- Finding
- Reconstructing the topology from configuration showed VLAN 1 was the native VLAN on trunks between the corporate core and the plant distribution switch, and was carrying data. A device on VLAN 1 in the office could reach plant equipment without crossing any firewall.
- Recommendation
- Move the native VLAN to an unused, pruned VLAN, remove VLAN 1 from all trunks, and validate segmentation by testing rather than by configuration review alone.
- Outcome
- Implemented across two maintenance windows. Segmentation testing afterwards confirmed the path was closed, which configuration review alone could not have proven.
A retail chain with wireless across 90 stores.
- Finding
- Guest wireless used a WPA2-PSK key that had not changed since deployment in 2019, was printed on a card at every till, and the guest VLAN had a route to the store back-office network for a payment terminal integration that had been decommissioned.
- Recommendation
- Move guest to a captive portal with rotating credentials, and remove the guest-to-back-office route entirely.
- Outcome
- Route removed immediately across all stores. The captive portal rolled out over a quarter as part of a scheduled wireless refresh.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.