NOC Security Guide: Securing the Network Operations Centre and Working with the SOC

The network operations centre holds the keys to every router, switch, firewall and monitoring platform in the estate, yet it is often run as an availability function with weaker security controls than the systems it manages. State-sponsored groups have spent years living inside carrier and enterprise network devices, changing access lists, mirroring traffic and capturing administrator logins, and much of that activity looks like routine NOC work to anyone not watching closely. This guide covers two linked problems: securing the NOC itself (its people, accounts, tools and management plane) and making the NOC and the security operations centre (SOC) work as one team when a network change or outage might be an attack. It is written for NOC managers, network engineers, SOC leads and the security architects who sit between them.

Key takeaways

• The NOC is a privileged access tier. NOC engineers, their monitoring servers and their automation accounts can change routing, access lists and AAA settings across the estate, so they deserve the same controls as domain administrators.
• The management plane must be separate. Put SSH, HTTPS, SNMP and TACACS+ or RADIUS in an out-of-band network or management VRF, and block egress from it except to approved collectors and AAA servers.
• Configuration drift is a security signal. An unexplained ACL entry, tunnel, SPAN session or AAA server change is how network device compromises show up, so compare running configs to approved baselines continuously.
• The SOC needs NOC data, and the NOC needs SOC context. Feed device syslog, AAA command accounting and change records to the SOC, and agree in writing who decides when an outage might be an incident.
• Network management tools are high-value targets. A compromised monitoring or configuration platform reaches every device it manages, as the SolarWinds supply chain compromise showed.

Why the NOC is a security problem

A NOC exists to keep the network up. Its metrics are availability, mean time to repair and change success, and its culture rewards speed. That culture produces predictable security gaps: shared device accounts so any engineer on shift can fix a fault, monitoring servers with read-write SNMP communities to every device, jump hosts reachable from the corporate network, and change records that describe what was done but are never compared with what the device now holds.

Attackers have noticed. The joint cybersecurity advisory published on 27 August 2025 by the FBI, NSA, CISA and international partners, Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System, describes actors adding their own IP addresses to access lists, enabling SSH on high, non-standard ports, building GRE and IPsec tunnels, configuring SPAN and ERSPAN mirroring, capturing TACACS+ traffic on TCP port 49 to harvest administrator credentials, and repointing routers at attacker-controlled TACACS+ servers. Every one of those actions is a normal NOC task when an authorised engineer performs it. See the Salt Typhoon Threat Actor Profile.

The result is that the NOC is often the first team to see the evidence of a network intrusion (an unexpected reload, a new tunnel, a capacity spike on a mirrored port) and the team least likely to treat it as one.

What a NOC holds and how it is attacked

Securing the management plane

The NCSC's secure system administration guidance sets the principles: gain trust in the devices used for administration, protect administration interfaces, tier administration by impact, use privileged access management, and log and audit administration. For network devices the 2025 joint advisory turns those into specific settings.

• Separate the management network: place SSH, HTTPS, SNMP, TACACS+ or RADIUS and SCP or SFTP in a dedicated out-of-band network or management VRF, and block all egress from it except to approved AAA, syslog and telemetry collectors. See the Out-of-Band Management Network Design Guide.
• Restrict and encrypt admin protocols: SSHv2 only, Telnet and plain HTTP disabled, web interfaces bound to the management VRF with AAA required, and default-deny allow lists plus control plane policing on management protocols.
• Fix SNMP: SNMPv3 with authPriv, v1 and v2c disabled, default community strings such as "public" and "private" removed, and write access restricted through VACM views. See the SNMP Security Guide.
• Stop devices being used as stepping stones: set transport output none on VTY lines so a compromised device cannot be used to SSH onwards, and treat router-to-router logons as abnormal.
• Store secrets properly: on Cisco IOS family devices use Type 8 for local passwords and Type 6 for stored secrets, never Type 5 or Type 7.
• Disable what is not needed: Smart Install, Guest Shell and unused services, with tight control over who can re-enable them.
• Admin from trusted devices only: the NCSC recommends that only trusted devices such as dedicated privileged access workstations reach administration interfaces, and warns against "browsing up" from less trusted devices.

Platform-specific hardening is covered in the Cisco IOS XE Hardening Guide.

Where identity fits

NOC identity is mostly non-human and shared, which is why it fails audits. Typical findings are a single local "admin" account per device type known to every engineer, monitoring servers holding SNMP write communities and SSH keys for the whole estate, configuration backup jobs running under an account with full privilege, and vendor support accounts that never expire.

• Human engineers: named accounts authenticated through TACACS+ or RADIUS, MFA enforced at the VPN, jump host or privileged access proxy, and per-role command authorisation (read-only for first-line, configure for senior engineers).
• Break-glass local accounts: one per device, unique or vaulted password, used only when AAA is unreachable, with an alert on every use. The NCSC advises protecting break-glass access differently and raising alarms when it is used.
• Automation and monitoring accounts: separate accounts per tool, read-only where the tool only polls, SSH keys or certificates held in a vault, rotation after staff changes. See the Privileged Access Management Guide.
• Vendors and carriers: brokered, time-limited sessions with recording, not standing VPN accounts. See the Vendor Privileged Access Management (VPAM) Guide.

NOC and SOC: dividing the work

NOC and SOC watch the same estate with different questions. The NOC asks "is it working?"; the SOC asks "is it legitimate?". Many incidents start as NOC tickets: a link saturates, a device reboots unexpectedly, a configuration backup fails. The question is who decides when that becomes a security incident, and how fast.

Operating models

• Separate NOC and SOC with integration: most common in larger organisations. Works when there is a shared ticketing queue, an agreed escalation matrix and a named SOC contact on every NOC shift.
• Combined NOC/SOC (sometimes called a fusion centre): common in smaller organisations and managed service providers. Saves cost and speeds handover, but security work tends to lose out to outages. Protect a fixed share of analyst time for security monitoring.
• Outsourced NOC, in-house or outsourced SOC: the provider's engineers then hold privileged access to your network. Contract for named accounts, session logging and log export to your SOC. See the Co-Managed SOC and SOC-as-a-Service Guide.

Whichever model you run, write down three things: which NOC events trigger a security escalation, who can declare an incident, and which network changes the NOC may make during an incident without the normal change board. NIST SP 800-61 Rev. 3 frames incident response as part of the whole Cybersecurity Framework 2.0 programme rather than a separate team activity, which supports treating the NOC as a participant, not a bystander.

Detection: what the SOC should receive from the NOC

The NCSC's guidance on logging administration says to record who, when, where and what for every admin action, define what normal administration looks like so deviations stand out, and test monitoring with blue team exercises at least annually. For small organisations it suggests something as simple as an email alert on every administrator login, with someone checking it was legitimate. For collection architecture see the Network Monitoring and Packet Capture Guide.

Metrics that show it is working

• Configuration drift without a change record: count per month, target zero unexplained items after investigation.
• Log source coverage: percentage of network devices forwarding syslog and AAA accounting to the SIEM, with alerting on silent sources.
• Shared and local account use: number of logins with non-named accounts per month, trending to break-glass only.
• Management plane exposure: number of device management interfaces reachable from user networks or the internet, target zero.
• Escalation time: median time from a qualifying NOC event to SOC acknowledgement.
• SNMP posture: percentage of devices on SNMPv3 authPriv with v1 and v2c disabled.

Implementing it: a phased approach

1. Inventory (weeks 1 to 4): list every device, management interface, AAA server, monitoring and configuration tool, and every account (human, local, automation, vendor) that can log in to a network device.
2. Agree the joint operating rules: escalation triggers, incident authority and pre-approved emergency changes, signed off by both NOC and SOC leads.
3. Turn on visibility before restriction: enable AAA command accounting, central syslog over an authenticated channel, and baseline capture. Watch for a month to learn what normal looks like.
4. Move management traffic: migrate device management into the management VRF or out-of-band network one site or device class at a time, keeping the old path open until the new one is proven, then remove it.
5. Replace shared accounts: named AAA accounts first, then vault the local accounts as break-glass, then cut tool accounts to least privilege. Test that AAA failure still allows break-glass login before removing anything.
6. Automate drift detection: scheduled config pulls compared with the golden baseline and the change calendar, alerting the SOC on unmatched differences.
7. Exercise: run a tabletop where a NOC engineer finds an unexplained tunnel, and test that the device is not reimaged before evidence is captured.

Rollback is simple when changes are staged: keep the previous ACL and AAA configuration archived per device, and apply management plane changes during maintenance windows with console or out-of-band access available.

Small versus large organisations

A small team may have one network engineer and an MSP. The priorities there are named accounts with MFA on the remote access path, SNMPv3, central logging to a service someone actually reviews, and contractual log access from the provider. Large and carrier-scale organisations need the full management VRF design, a dedicated network detection capability inside the SOC, and firmware integrity checking as part of incident response.

Responding when a network device may be compromised

• Do not reboot or reimage first: the 2025 advisory advises scoping the full compromise before containment, because partial action can alert actors and let them keep access, and capturing live artefacts such as process lists, bound sockets and on-box files before eradication.
• Check integrity: Cisco's integrity assurance guidance covers image hash and signature verification (verify, show software authenticity running), reviewing the last reload reason and configuration register, ROMMON variables, and command accounting records. It warns that clean results do not guarantee a device is uncompromised.
• Treat AAA as compromised: if TACACS+ traffic was captured or redirected, rotate every credential that crossed it, including automation accounts.
• Check the tools: confirm the monitoring and configuration platforms were not the entry point before trusting them to push the clean configuration.

Common failure patterns

• Monitoring platform as a single point of compromise: network management software with credentials for every device is a supply chain target, as the SolarWinds supply chain compromise showed when trojanised updates reached thousands of customers.
• Remote access appliances left unpatched: the VPN gateway that NOC engineers use is often the softest entry, as in the Ivanti Connect Secure exploitation, where VPN zero-days exposed credentials and sessions.
• Drift treated as housekeeping: unexplained ACL entries or tunnels are tidied up by the NOC without telling the SOC, destroying the evidence and the chance to scope the intrusion.
• Shared device accounts: nobody can tell which engineer made a change, so a malicious change cannot be told apart from a mistake.
• Logs that stop silently: a device stops forwarding syslog and nobody notices for months because the SIEM has no rule for missing sources.
• Restore before investigate: an unexpected reload is fixed by reloading a known-good config, while modified firmware persists.

Framework mapping

See the CIS Control 13 Network Monitoring and Defense Guide.

Practitioner checklist

• Inventory every account that can log in to a network device, including monitoring, backup and vendor accounts.
• Move all device management into a management VRF or out-of-band network with egress restricted to AAA, syslog and telemetry.
• Enforce SSHv2, SNMPv3 authPriv and HTTPS only; disable Telnet, HTTP, SNMP v1 and v2c, and unused services.
• Replace shared logins with named AAA accounts and MFA on the access path; vault local accounts as break-glass with alerts.
• Enable AAA command accounting and forward it, with device syslog, to the SOC over an authenticated channel.
• Compare running configurations against approved baselines and the change calendar at least daily on critical devices.
• Alert on capture or mirroring configuration, new tunnels, non-standard management ports and TACACS+ flows to unapproved addresses.
• Write and sign a NOC and SOC escalation matrix, including a rule that no suspected device is reimaged before SOC sign-off.
• Treat network monitoring and configuration platforms as critical systems with least-privilege service accounts.
• Run a joint NOC and SOC exercise on a network device compromise at least once a year.

Standards and references

• FBI, NSA, CISA and partners: Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System
• NCSC: Secure System Administration
• NCSC: Protect Your Administration Interfaces
• NCSC: Log and Audit Administration Activities
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-53 Rev. 5
• CIS: Control 12 Network Infrastructure Management
• Cisco: Cisco IOS Software Integrity Assurance

Related NHI Mgmt Group resources: SOC Guide · Out-of-Band Management Network Design Guide · Network Monitoring and Packet Capture Guide · Salt Typhoon Threat Actor Profile · Privileged Access Management Guide