Network security is the architecture and operating discipline that controls who and what can communicate, protects management paths, reduces lateral movement, makes critical traffic observable, and gives responders enough evidence to contain failures. This guide focuses on durable controls rather than product brands or perimeter-only thinking.
This recertification incorporates NIST SP 800-207 zero-trust architecture, NIST SP 800-81 Rev. 3 for DNS security, NIST SP 800-52 Rev. 2 for TLS configuration, and CISA/partner hardening guidance for network infrastructure. NIST SP 800-52 Rev. 2 is currently under review, so its status is noted rather than overstated.
A modern enterprise network spans offices, data centers, cloud platforms, remote users, SaaS services, operational technology, wireless networks, managed devices, unmanaged devices, partner connections, and internet-facing systems. Treat network location as context rather than proof of trust. NIST SP 800-207 explicitly rejects implicit trust based solely on physical or network location and instead focuses access decisions on subjects, devices, resources, and policy.
That does not make segmentation obsolete. Segmentation remains valuable because it limits reachability, reduces blast radius, creates enforceable choke points, and simplifies monitoring. The important distinction is that a VLAN or private subnet should not itself grant broad application trust. Use network boundaries to constrain possible paths while identity, device, workload, and application controls decide whether an allowed path should result in access.
For each critical service, identify the users and workloads that need it, the protocols and ports required, the direction of initiation, the data sensitivity, the authentication mechanism, the administrative path, external dependencies, expected traffic pattern, and recovery requirements. This produces a communication model that can be enforced and reviewed instead of a growing collection of firewall rules whose original purpose has been forgotten.
Every persistent allow rule should answer a business or technical need. Record source and destination scope, protocol, port, application or service where available, owner, purpose, approval, creation date, review trigger, and expiration when temporary. Avoid using large address ranges simply because they are easier to configure. A rule that allows more systems than the service requires expands the paths an attacker can use after compromising any one of those systems.
Separate inbound, outbound, east-west, and management flows during design. Inbound controls reduce exposure from external or lower-trust networks. Outbound controls restrict command-and-control, data exfiltration, unwanted software retrieval, and accidental access to prohibited services. East-west controls contain lateral movement. Management controls protect the devices that enforce all the other controls. Treat those categories differently because the consequence and expected behavior of each are different.
Review flow data before removing or tightening a rule, but do not treat observed traffic as automatic evidence that the traffic is legitimate. Logs tell you what happened; architecture and ownership tell you what should happen. Compare observed connections against declared service requirements and investigate both directions of drift: documented flows that are never used and recurring traffic that has no approved requirement.
Useful boundaries often separate internet-facing services, user workstations, servers, privileged administration, identity systems, backups, security tooling, development, production, IoT, guest wireless, and regulated or mission-critical workloads. The exact zones depend on the organization; the principle is to prevent a compromise in a lower-consequence population from creating unnecessary reachability to higher-consequence resources.
VLANs provide logical grouping, but the security control exists where traffic between groups is evaluated. Use router ACLs, stateful firewalls, host controls, cloud security policy, service-mesh policy, or equivalent enforcement so that crossing a boundary requires an explicit decision. CISA’s infrastructure hardening guidance recommends strong segmentation with ACLs, stateful inspection, firewall capabilities, and DMZ constructs as part of defense in depth.
Backups, directory services, certificate services, virtualization management, endpoint-management platforms, security consoles, and privileged access systems can become force multipliers during an intrusion. Put them behind dedicated policy boundaries and administration paths. Where practical, restrict access to named management devices and privileged identities, prohibit direct internet administration, require strong authentication, and log both successful and denied management attempts.
At internet and partner boundaries, default-deny inbound exposure and publish only services that have a current owner and requirement. Place public-facing services in architectures that limit direct reachability to internal resources, and restrict their outbound and backend communication to the exact dependencies they need. Remove unused services and management listeners, keep device software current, and validate that configuration backups can be restored.
Firewall policy should be reviewable as code or structured configuration where tooling allows. Test rule ordering, address objects, NAT behavior, application identification, and routing together because a correct-looking rule can still have an unintended effective path. Log denied traffic at important boundaries, but tune collection and retention so the organization can distinguish useful security evidence from high-volume noise.
Treat changes to edge devices as production changes with rollback. Require attributable administrator actions, out-of-band or otherwise protected recovery options, configuration-version history, and time synchronization. CISA’s December 2024 hardening guidance was written for communications infrastructure but notes that many practices also apply to enterprise on-premises equipment; its emphasis on visibility, secure administration, segmentation, and device hardening is broadly useful.
Routers, switches, firewalls, wireless controllers, VPN gateways, DNS infrastructure, load balancers, and management appliances should not be administered from arbitrary user networks or directly from the internet. Use dedicated management networks or equivalent restricted paths, limit source devices, require named administrator identities, and use phishing-resistant multifactor authentication where the platform supports it. Disable legacy and insecure management protocols rather than relying on staff to avoid them.
Separate everyday productivity accounts from privileged network administration. A compromised email or browser session should not automatically provide credentials capable of changing routes, firewall policy, DNS, or device firmware. Use privileged access workstations or strongly controlled administration endpoints for high-consequence environments, and keep break-glass access tightly governed, monitored, and tested.
Back up device configuration after approved changes and protect those backups from the same credentials used to administer production. A configuration archive is valuable for recovery and investigation only if responders can trust its integrity and access it during an incident. Periodically compare running configurations against approved baselines to find unauthorized changes, vendor defaults, disabled logging, unexpected local accounts, or re-enabled services.
NIST finalized SP 800-81 Rev. 3 in March 2026, replacing the much older Revision 2. The new guide treats authoritative DNS, recursive DNS, DNSSEC, encrypted DNS, protective DNS, logging, and DNS’s role in zero-trust and defense-in-depth architectures as distinct security considerations. That makes DNS more than a name-resolution utility: compromise, misuse, or loss of visibility can affect the entire enterprise.
Separate authoritative and recursive roles where architecture permits, restrict zone transfers and administrative changes, protect registrar and DNS-provider accounts, and use DNSSEC when integrity and authenticity requirements justify it. For recursive DNS, define which resolvers enterprise devices are allowed to use and decide how encrypted DNS is handled so privacy improvements do not silently eliminate security controls or incident visibility.
Use DNS logs as one signal in detection. Newly observed domains, algorithmically generated names, unusual query volume, unexpected resolver use, repeated failures, and lookups from systems that normally make few external requests can all be useful when combined with endpoint, identity, and network context. Protective DNS can block known malicious destinations, but it should complement—not replace—endpoint controls, egress policy, secure browsing, and investigation capability.
Traditional remote-access VPNs can create a large trusted path after a user authenticates. Reduce that exposure by assigning access based on identity, device posture, role, resource sensitivity, and current need. Where legacy VPN architecture remains necessary, use strong authentication, narrow network scopes, endpoint health controls where reliable, short idle lifetimes, clear split-tunneling policy, and monitoring that identifies the user and device behind each connection.
Vendor access should be time-bounded and attributable. Avoid permanent shared vendor accounts and broad site-to-site paths that exist only for convenience. Require a named service owner, approved access window, source restriction where practical, least-privilege destination scope, logging, and a rapid disable mechanism. Revalidate access after contract, personnel, or support-model changes rather than waiting for an annual review.
Machine-to-machine remote connectivity needs the same lifecycle discipline. Rotate certificates and credentials, constrain peer identity, document expected flows, and make ownership visible. An old tunnel or partner connection with no current business owner is a liability even if it has never generated an alert.
No single telemetry source describes network activity completely. Combine firewall and gateway logs, DNS, DHCP or address-assignment context, identity events, endpoint telemetry, cloud flow logs, proxy or secure web gateway data, VPN or remote-access logs, wireless authentication, and selected packet capture where risk and capacity justify it. Correlating identity, device, address, service, and time is more useful than collecting enormous volumes of unconnected network events.
Prioritize visibility at high-consequence boundaries: internet ingress and egress, identity and management networks, critical server zones, partner connections, remote access, and paths into sensitive data or recovery systems. Retain enough context to investigate delayed discoveries. Validate time synchronization and device identity because logs that cannot be ordered or attributed become much less useful during an incident.
Detection engineering should be based on expected behavior and plausible attack paths. Useful network-oriented detections include unexpected administrative protocols, new external exposure, unusual east-west scanning, repeated denied connections across many destinations, communications between zones with no declared dependency, new resolvers, beacon-like egress, large or unusual transfers, disabled logging, and configuration changes on enforcement devices. Test detections using controlled simulations and confirm that alerts reach an owner who can act.
NIST SP 800-207 focuses zero trust on protecting resources and removing implicit trust based solely on location. In practical network design, that means a connection from the corporate LAN should not automatically receive broad access. Evaluate the subject, device or workload, requested resource, policy, and relevant context before access is established, and keep authorization narrow enough that compromise of one session does not create unnecessary reach.
Network controls remain part of that architecture. Segmentation constrains which resources can even be attempted; identity-aware access determines who can reach them; endpoint or workload controls measure device state; application authorization decides what the session can do; telemetry verifies the resulting behavior. Strong designs layer these controls so a failure in one does not instantly remove every boundary.
Adopt zero trust incrementally around important use cases instead of attempting a universal technology replacement. Start with privileged administration, remote access, high-value applications, third parties, and critical service-to-service communication. Define the current trust assumption, the desired decision inputs, the enforcement point, the evidence generated, and the recovery path. Measure reduced reachability and improved attribution rather than counting products labeled “zero trust.”
NIST SP 800-52 Rev. 2 remains the current final NIST TLS configuration publication as of this review, and NIST notes that the publication is presently under review. It requires federal TLS servers and clients to support TLS 1.2 with appropriate FIPS-based suites and required TLS 1.3 support by January 1, 2024. Outside federal scope, the durable lesson is still useful: remove obsolete protocol versions and weak cryptography, manage certificates deliberately, and test actual negotiated configurations instead of relying on intended settings.
Encryption reduces passive exposure and protects integrity in transit, but it also changes visibility. Decide where TLS termination occurs, who can administer certificates and private keys, what metadata remains available to detection systems, and whether inspection is lawful and appropriate for the data and environment. Do not weaken TLS simply to make monitoring easier; design telemetry at endpoints, gateways, applications, and identity layers to preserve useful evidence.
Use change triggers in addition to calendar reviews. Acquisitions, new sites, major cloud migrations, identity-platform changes, new remote-access models, critical incidents, network redesigns, and newly exposed services can invalidate a baseline immediately. Record the last substantive review, evidence used, important exceptions, owner, and next review trigger so the network architecture does not become an undocumented historical artifact.
Inventory internet exposure, network devices, management interfaces, remote connections, DNS roles, critical zones, and owners. Identify unsupported devices and paths with no accountable owner.
Build flow maps for the highest-value services, compare them with effective firewall and routing policy, and remove or time-bound unnecessary reachability.
Harden management paths, privileged identities, configuration backups, DNS, logging, remote access, and vendor connectivity. Validate that denied traffic and configuration changes are observable.
Run a controlled lateral-movement and network-device-compromise exercise. Confirm detections, containment paths, configuration recovery, ownership, and incident evidence, then convert findings into tracked remediation.
This guide is an implementation aid, not a universal configuration standard. Apply sector, contractual, regulatory, architecture, and risk requirements to the systems in scope.
Follow the next implementation topic without returning to search.
Design useful security logging, resilient collection, detection engineering, investigation context, retention, and evidence
Continue readingGovern identity lifecycle, authentication, federation, privileged access, service identities, access review, and identity evidence
Continue readingTranslate zero-trust principles into an implementation program
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.