Network Security Guide: Architecture, Controls and Monitoring for Modern Networks

Network security is the set of architecture, controls and monitoring that decides which systems can talk to each other, protects that traffic and detects misuse of it, and most networks still trust too much once something is inside. The perimeter has fragmented into cloud VPCs, SaaS, remote users, branch SD-WAN and internet-facing edge devices, while attackers increasingly enter through those edge devices or with valid credentials rather than malware. This page is the NHI Mgmt Group overview of the field: what it covers, the core concepts, the main threats, the controls that matter at each maturity stage, who owns what, and where the standards sit. It is for security architects, network engineers and security leaders who want one map of the subject, and it links every deeper network security guide we publish rather than repeating them.

Key takeaways

• Edge devices are the front door. VPN gateways, firewalls and routers are internet-facing, run privileged code and often lack endpoint monitoring, which makes them a favoured initial access route (ATT&CK T1190, T1133).
• Segmentation limits the blast radius. Most damage happens in east-west traffic after initial access, so internal segmentation matters as much as the perimeter.
• Network location is not identity. NIST SP 800-207 and the NCSC zero trust principles both move access decisions from "which network" to "which verified user, device or service".
• Network devices hold non-human credentials. SNMP community strings, TACACS+ and RADIUS shared secrets, API keys and local admin accounts need inventory, rotation and monitoring like any other NHI.
• You cannot defend what you do not see. Flow logs, DNS logs and selective packet capture are the evidence base for detection, investigation and proving that segmentation works.

What the field covers

Network security spans the design of the network, the enforcement points on it and the telemetry that comes off it. The table sets out its main domains.

Core concepts

Layers, ports and protocols

Defenders reason about networks in the OSI and TCP/IP models: layer 2 (switching, VLANs, ARP), layer 3 (IP routing), layer 4 (TCP and UDP ports) and layer 7 (application protocols). Controls exist at each layer, and attacks target each one: ARP spoofing and VLAN hopping at layer 2, route hijacking at layer 3, exposed services at layer 4, and protocol abuse such as DNS tunnelling at layer 7. Exposed management and file-sharing services such as Telnet (TCP 23), SMB (TCP 445), RDP (TCP 3389) and SNMP (UDP 161) remain the commonest avoidable exposures. See the Network Ports and Protocols Security Guide and the planned OSI and TCP/IP Models Guide.

North-south and east-west

• North-south: traffic between users or the internet and your services. Usually filtered by perimeter firewalls, secure web gateways and WAFs.
• East-west: traffic between internal systems: server to server, workstation to workstation, pod to pod. Attackers spend most of their dwell time here, using network service discovery (T1046) and remote services (T1021).

Core network services

Every other control depends on a few shared services, and attackers know it. They are easy to overlook because they "just work".

• DNS: resolvers can block known-bad domains (protective DNS) and log every query, which makes DNS one of the richest detection sources you have. DNSSEC protects the integrity of answers for zones you sign. Encrypted DNS (DoH, DoT) improves privacy but can bypass corporate resolvers, so decide policy deliberately. See the DNS Security Guide and the planned DNS Hijack Playbook.
• Routing: BGP has no built-in origin validation, so prefixes can be hijacked or leaked. RPKI route origin authorisations and route origin validation reduce that risk for internet-facing address space.
• Addressing: rogue DHCP servers and IPv6 router advertisements can redirect traffic on a local segment. DHCP snooping, RA Guard and DHCPv6 Guard on access switches close that gap, including on networks that believe they do not run IPv6.
• Encryption in transit: TLS for applications, IPsec or WireGuard for site and remote tunnels, and MACsec for links between switches. Encryption protects confidentiality and integrity but also hides threats from inspection, which is the trade-off TLS inspection tries to manage. See the planned VPN Protocols Compared: WireGuard, IPsec, OpenVPN Guide.

Segmentation and zero trust

Segmentation divides the network into zones so that compromise of one does not grant reach into others. Microsegmentation shrinks those zones to an application, a workload or a single host. Zero trust goes further: NIST SP 800-207 says no implicit trust is granted to an asset or account based on its network location, and protection focuses on resources rather than network segments. In practice zero trust uses segmentation as one enforcement mechanism among several. The NCSC principle "trust no network" means treating even internal networks as hostile and encrypting traffic accordingly. See the Network Segmentation Guide.

Enforcement points compared

Choosing between approaches

• VPN or ZTNA: keep VPN where whole-network access is genuinely needed (some admin and OT cases); move user-to-application access to ZTNA, which brokers one application at a time and removes the exposed VPN portal. See the SASE and SSE Guide and the planned Secure Remote Access Beyond VPN Guide.
• Network or host segmentation: network firewalls suit legacy, OT and unmanaged devices that cannot run agents; host-based policy suits dynamic server estates where IP addresses churn.
• Inspect or not: TLS inspection gives visibility into encrypted threats but adds privacy, performance and certificate-trust risk. Exempt sensitive categories and pinned applications. See the TLS Inspection Guide.
• Small or large organisations: a small organisation gets most value from a managed firewall with a default-deny inbound policy, cloud-delivered DNS filtering and MFA on remote access. A large one needs zone architecture, NAC, NDR, central rule review and a dedicated edge device patching process.

Where identity fits

Network infrastructure is full of non-human identities. Firewalls and VPN appliances store service account credentials, API keys, certificates and LDAP bind accounts; routers and switches hold SNMP community strings, TACACS+ and RADIUS shared secrets and SSH keys; SD-WAN and SASE platforms are driven by admin API tokens. Network policy itself increasingly keys on identity: 802.1X device certificates, ZTNA user and device posture, and service mesh workload identities. See the Non-Human Identity (NHI) Guide and the Zero Trust Identity Guide.

Main threats

Common failure patterns

• Patching the appliance but not the secrets on it: in the Ivanti Connect Secure exploitation, chained CVE-2023-46805 and CVE-2024-21887 gave unauthenticated command execution, and attackers harvested VPN user passwords plus service account credentials, API keys and certificates from the device configuration. CISA's supplemental direction to federal agencies required resetting stored API keys and service account passwords and reissuing certificates before reconnecting. Treat every secret on a compromised edge device as stolen.
• Network device credentials nobody rotates: Cisco Talos found that the Salt Typhoon intrusions into US telecoms mostly used valid stolen credentials, and that SNMP community strings, weakly encrypted local passwords and TACACS and RADIUS shared secrets were taken from configurations and traffic, with access kept for more than three years. See the Salt Typhoon telecom intrusions.
• Management interfaces on the internet: admin portals, SSH and SNMP left reachable from anywhere turn every new appliance vulnerability into an emergency.
• Flat internal networks: a single compromised workstation can reach domain controllers, backup servers and hypervisors because nothing filters east-west traffic.
• Rule sprawl: firewall rule bases grow for years with "any" services and expired temporary rules that nobody owns. See the Firewall Rule Review Checklist.
• Visibility gaps: no flow or DNS logs from cloud VPCs or remote users, so an investigation cannot show what an attacker reached.

Key controls by maturity

A phased programme

1. Map: inventory internet-facing assets, network devices, cloud VPCs and the flows between critical systems. Start with what attackers see from outside.
2. Reduce exposure: close unneeded inbound services, move management interfaces to a dedicated admin network or bastion, and set an emergency patching SLA for edge devices.
3. Secure device credentials: centralise device admin through TACACS+ or RADIUS with MFA, move to SNMPv3, remove weak local password types, vault and rotate API keys and shared secrets.
4. Segment in monitor mode first: deploy segmentation policy in logging or alert-only mode, compare against observed flows for two to four weeks, then enforce one zone at a time. Keep the previous rule set ready to restore as the rollback path.
5. Add detection: collect flow and DNS logs, deploy IDS or NDR at key boundaries, and write detections for lateral movement and C2 patterns.
6. Validate: test segmentation from each zone, run firewall rule reviews at least annually, and exercise edge device compromise in incident response tabletop exercises.

Detection and measurement

Monitor: new or changed firewall rules, admin logins to network devices (especially from new sources), new local accounts or SSH keys on devices, AAA server configuration changes, unusual east-west connections on SMB, RDP and WinRM, DNS queries to newly registered domains, and long-lived low-volume outbound sessions. Flow records (NetFlow, IPFIX, cloud VPC flow logs) answer "who talked to whom" cheaply and should be kept for months; full packet capture answers "what was said" but is expensive, so keep it short and targeted at key boundaries. Open source sensors such as Zeek turn traffic into structured protocol logs; see the planned Zeek Network Monitoring Guide. Metrics that show progress:

• Number of internet-exposed management interfaces (target zero).
• Median days to patch critical vulnerabilities on edge devices.
• Percentage of firewall rules with a named owner and review date, and rules unused for 90 days.
• Percentage of critical assets in an enforced segment.
• Percentage of network segments and cloud VPCs sending flow and DNS logs.
• Percentage of network devices using centralised, MFA-protected administration.

Roles and ownership

The failure to avoid is the gap between network and security teams: rules owned by neither, edge devices patched by a team that does not see threat intelligence, and cloud networks outside both. Name an owner for each enforcement point and each rule set.

Standards and frameworks

Sector rules add specifics, such as PCI DSS segmentation testing for cardholder data environments. For how the major frameworks relate, see the planned Cybersecurity Frameworks Compared Guide.

Where to go next

New to Network Security? These are the foundational guides to read first.

Start here

• Network Segmentation Guide: zones, microsegmentation and enforcement options.
• Top 10 Network Security Misconfigurations: the commonest avoidable network weaknesses.
• DNS Security Guide: protective DNS, DNSSEC and DoH.
• Firewall Management Guide: rules, reviews and policy hygiene.
• Edge Device Security Guide: hardening and monitoring internet-facing appliances.
• VPN Security Guide: VPN vulnerabilities, hardening and replacement.
• DDoS Protection Guide: mitigation architectures and runbooks.
• Network Access Control (NAC) Guide: device admission and posture.
• Wi-Fi Security Guide: WPA3, 802.1X and rogue access points.
• SASE and SSE Guide: converged network and security services.
• IDS and IPS Guide: detection methods, placement and tuning.
• NDR Guide: behavioural network detection.

Browse all Network Security guides

Practitioner checklist

• Inventory every internet-facing service and network device, and remove management interfaces from the internet.
• Set and track an emergency patching SLA for VPN gateways, firewalls and other edge devices.
• After any edge device compromise, rotate every credential, key and certificate stored on it.
• Centralise network device administration through TACACS+ or RADIUS with MFA, and move to SNMPv3.
• Separate user, server, management and OT networks, then ring critical systems with enforced policy.
• Deploy segmentation in monitor mode, validate against observed flows, then enforce zone by zone.
• Review firewall rules at least annually and remove unused or unowned rules.
• Collect flow and DNS logs from data centre, cloud and remote access, and alert on lateral movement and device configuration changes.
• Move user-to-application access from VPN to ZTNA where the application allows it.

Standards and references

• NIST: SP 800-207, Zero Trust Architecture
• NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NCSC: Zero trust architecture design principles
• CISA: Zero Trust Maturity Model
• CIS: Critical Security Controls v8.1
• MITRE ATT&CK: Exploit Public-Facing Application

Related NHI Mgmt Group resources: Network Segmentation Guide · Edge Device Security Guide · Firewall Management Guide · Zero Trust Identity Guide · Non-Human Identity (NHI) Guide