Quality & Acceptance
Chapter 10 — Core Switch Security Hardening Design Guide
Quality assurance and formal acceptance testing are the final gates that verify a core switch security hardening deployment meets its design objectives before the device is placed into production service. The acceptance process is structured in three phases: pre-deployment verification (hardware and software checks before installation), post-deployment functional testing (verifying that all hardening controls are active and correctly configured), and ongoing quality monitoring (continuous verification that hardening controls remain effective over time). A hardening deployment that passes all acceptance criteria provides documented evidence that the security posture meets the organization's requirements and applicable compliance frameworks.
10.1 Quality Comparison: Before vs. After Hardening
The quality comparison image below illustrates the measurable difference between an unhardened core switch deployment and a fully hardened deployment. The left side represents a typical pre-hardening state characterized by disorganized cable management, red alert indicators, security vulnerabilities, and lack of physical access controls. The right side shows the same environment after systematic hardening: organized color-coded cabling, green status indicators, port blockers on all unused ports, tamper-evident seals, and documented quality metrics demonstrating 99.999% uptime, an A+ security score, 70% reduction in mean time to recovery, and zero unauthorized access events.
10.2 Pre-Deployment Verification Checklist
Pre-deployment verification must be completed before the switch is physically installed in the production rack. This phase covers hardware integrity verification, software version validation, and baseline configuration review. All items must be checked and signed off by the deployment engineer and reviewed by the security team lead.
| # | Verification Item | Method | Pass Criteria | Responsible |
|---|---|---|---|---|
| 1 | Hardware serial number verification | Physical inspection; compare to purchase order | Serial number matches PO; no physical damage | Deployment Engineer |
| 2 | Software version verification | Boot to CLI; show version | Approved software version per change record | Deployment Engineer |
| 3 | Software image integrity check | Verify MD5/SHA hash against vendor published hash | Hash matches vendor published value | Security Team |
| 4 | Baseline hardening configuration loaded | Compare running config to approved baseline template | All required hardening controls present; no deviations | Security Team |
| 5 | No default credentials present | Attempt login with known default credentials | All default credentials changed; login fails | Security Team |
| 6 | Telnet and HTTP disabled | Attempt Telnet and HTTP connection | Connection refused; only SSH and HTTPS accepted | Deployment Engineer |
| 7 | Unused services disabled | Review running config; check service status | All services not required by design are disabled | Security Team |
| 8 | AAA server connectivity verified | Test authentication against primary and secondary AAA | Authentication succeeds via both servers | Deployment Engineer |
| 9 | NTP synchronization verified | Check NTP status; verify time accuracy | NTP synchronized; time accurate to ±1 second | Deployment Engineer |
| 10 | Syslog connectivity verified | Generate test log event; verify receipt at SIEM | Test event received at SIEM within 30 seconds | Security Team |
10.3 Post-Deployment Security Control Acceptance Tests
Post-deployment acceptance tests verify that each security hardening control is functioning correctly in the production environment. These tests must be performed after the switch is installed and connected, but before traffic is migrated to the new switch. Each test must be documented with the actual result and compared against the pass criteria.
| Test ID | Control Tested | Test Procedure | Pass Criteria | Result |
|---|---|---|---|---|
| AT-01 | SSH access control (allowlist) | Attempt SSH from authorized IP; attempt from unauthorized IP | Authorized IP: login prompt; Unauthorized IP: connection refused | [ ] Pass / [ ] Fail |
| AT-02 | AAA authentication | Login with valid TACACS+ credentials; login with invalid credentials | Valid: login succeeds; Invalid: login fails after 3 attempts; lockout applied | [ ] Pass / [ ] Fail |
| AT-03 | Command authorization | Attempt privileged commands with read-only account | Privileged commands denied; authorization failure logged to SIEM | [ ] Pass / [ ] Fail |
| AT-04 | CoPP rate limiting | Generate high-rate ICMP flood toward switch management IP | CoPP drops excess ICMP; switch CPU remains below 50%; forwarding unaffected | [ ] Pass / [ ] Fail |
| AT-05 | BGP authentication | Attempt BGP session without MD5/SHA key; with incorrect key | BGP session without key: rejected; incorrect key: rejected; correct key: session established | [ ] Pass / [ ] Fail |
| AT-06 | OSPF authentication | Attempt OSPF adjacency without authentication key | Unauthenticated OSPF adjacency rejected; authenticated adjacency established | [ ] Pass / [ ] Fail |
| AT-07 | BPDU Guard | Connect unauthorized switch to access port; send BPDU | Port enters err-disabled state within 1 second; alert sent to SIEM | [ ] Pass / [ ] Fail |
| AT-08 | DHCP Snooping | Connect rogue DHCP server to untrusted port | DHCP offers from untrusted port dropped; legitimate DHCP from trusted port passes | [ ] Pass / [ ] Fail |
| AT-09 | Configuration change logging | Make a test configuration change; verify logging | Change logged to SIEM with timestamp, username, and command detail within 60 seconds | [ ] Pass / [ ] Fail |
| AT-10 | HA failover security continuity | Initiate supervisor failover; verify security controls post-failover | Failover completes in <30 seconds; all ACLs, CoPP, and routing auth remain active | [ ] Pass / [ ] Fail |
10.4 Acceptance Scoring and Sign-Off Criteria
The acceptance scoring framework defines the minimum pass threshold for each test category and the overall deployment acceptance decision. A deployment that fails any critical test must be remediated before it can be accepted into production service. The sign-off process requires approval from both the deployment engineer and the security team lead, with documentation retained for audit purposes.
| Test Category | Tests | Minimum Pass Rate | Failure Action |
|---|---|---|---|
| Pre-Deployment Verification | 10 items | 100% — all items must pass | Halt deployment; remediate before proceeding |
| Management Plane Controls | AT-01, AT-02, AT-03 | 100% — all must pass | Halt deployment; management plane must be secure |
| Control Plane Controls | AT-04, AT-05, AT-06 | 100% — all must pass | Halt deployment; control plane must be secure |
| Data Plane / L2 Controls | AT-07, AT-08 | 100% — all must pass | Halt deployment; L2 security must be active |
| Logging and HA Controls | AT-09, AT-10 | 100% — all must pass | Halt deployment; logging and HA security must be verified |
| Overall Acceptance Decision | All 20 items | 100% pass rate required | Any failure: deployment rejected; remediation required |