Network Security Training — Secure In Security

Secure In Security — Network Security Training Program Cybersecurity & Information Security

Secure In Security

Network Security
Architecture & Operations

Cybersecurity & Information Security Training Program · 2026

Introduction to Network Security

What Is Network Security?

Network security is the practice of protecting organizational networks and the data traversing them from unauthorized access, misuse, modification, or denial. It encompasses the policies, procedures, hardware, and software controls that defend the network infrastructure — routers, switches, firewalls, servers, wireless access points, and the protocols connecting them.

Network security operates at the intersection of three information security properties: it must prevent unauthorized parties from viewing network data in transit (Confidentiality), ensure data arrives unmodified (Integrity), and keep network services operational for authorized users (Availability). Modern network attacks can violate all three simultaneously.

The OSI Model and Security Relevance

The OSI (Open Systems Interconnection) model provides a framework for understanding where network attacks occur and where security controls must be applied. Every network security control maps to one or more OSI layers:

Layer	Name	Function	Security Controls & Threats
7	Application	HTTP, DNS, SMTP, FTP, API protocols — user-facing services	WAF, API gateway, application proxies, DMARC/SPF; Threats: web app attacks, phishing, DNS hijacking, API abuse
6	Presentation	Data encoding, encryption, compression (SSL/TLS operates here)	TLS/SSL certificates, encryption enforcement; Threats: downgrade attacks, certificate spoofing, weak cipher exploitation
5	Session	Session establishment, maintenance, and termination	Session token protection, timeout enforcement; Threats: session hijacking, replay attacks, session fixation
4	Transport	TCP/UDP port-based communication, reliability, flow control	Firewall port rules, TCP inspection, TLS; Threats: port scanning, SYN flood, TCP session attacks
3	Network	IP addressing, routing, packet forwarding (IP protocol)	Router ACLs, firewalls, IPS, IPsec; Threats: IP spoofing, routing attacks (BGP hijack), ICMP attacks, VLAN hopping
2	Data Link	MAC addressing, switching, VLAN segmentation, ARP	802.1X NAC, DHCP snooping, Dynamic ARP Inspection; Threats: ARP spoofing, MAC flooding, VLAN hopping, rogue DHCP
1	Physical	Cables, fiber, wireless signals, hardware infrastructure	Physical access controls, cable protection, tamper detection; Threats: wiretapping, jamming, hardware tampering

Network Security Key Terminology

Term	Definition
Attack Surface	The totality of network entry points an attacker can target — every open port, accessible service, exposed protocol, and network connection increases the attack surface
Threat Vector	The specific pathway or method an attacker uses to reach and exploit a target — e.g., internet-facing RDP, unencrypted Wi-Fi, vulnerable BGP configuration, or phishing email link
Lateral Movement	An attacker’s progression through the internal network from initial compromise point to high-value targets — the primary threat that internal network segmentation prevents
East-West Traffic	Network traffic that flows between systems within the same security zone (internal server-to-server traffic) — often inspected less rigorously than North-South traffic
North-South Traffic	Network traffic that flows between the internet (external) and the internal network — the traditional focus of perimeter security controls
Network Segmentation	The division of a network into isolated zones with controlled traffic between them — limits an attacker’s ability to move laterally after initial compromise
Micro-Segmentation	Fine-grained network segmentation that isolates individual workloads or applications — enforced at the workload level rather than network perimeter level
ACL	Access Control List — Ordered list of permit/deny rules applied to network traffic; applied to router interfaces, firewall policies, cloud security groups, and switch ports
VLAN	Virtual LAN — Logical network segmentation implemented at Layer 2; separates broadcast domains and provides traffic isolation between different user groups or security zones
DMZ	Demilitarized Zone — A network zone positioned between the internet and the internal network; hosts public-facing services with limited trust in both directions
Zero Trust	Security model that assumes no implicit trust based on network location — every access request must be authenticated, authorized, and continuously validated regardless of origin
Defense in Depth	Layering multiple security controls so that the failure of any single control does not result in a complete security compromise — the foundational principle of network security architecture

Common Network Attack Categories

Attack Category	Description	Primary Defense
Reconnaissance	Passive and active information gathering about network topology, open ports, services, and vulnerabilities before launching an attack	Limit publicly visible information; honeypots; network monitoring for scan activity; rate limiting on banner information
Man-in-the-Middle (MitM)	Attacker intercepts communication between two parties — can read, modify, or inject traffic without detection if communications are unencrypted or authentication is weak	TLS/HTTPS enforcement; certificate pinning; HSTS; mutual TLS (mTLS); 802.1X on wired networks; DNSSEC
Denial of Service (DoS/DDoS)	Overwhelming a network resource with traffic to exhaust capacity and deny service to legitimate users — volumetric, protocol, or application layer attacks	DDoS mitigation service; rate limiting; traffic scrubbing; BGP blackholing; anycast routing; capacity overprovisioning
Spoofing	Forging source addresses (IP, MAC, DNS, email) to impersonate trusted systems — enables MitM attacks and bypasses IP-based access controls	Ingress/egress filtering; BCP38; DNSSEC; DMARC/SPF/DKIM; ARP inspection; uRPF (unicast reverse path forwarding)
Protocol Exploitation	Exploiting weaknesses in network protocols (BGP, DNS, ARP, DHCP, ICMP) to redirect traffic, poison caches, or disrupt routing	DNSSEC; BGP security (RPKI, route filtering); DHCP snooping; Dynamic ARP Inspection; protocol anomaly detection via IDS/IPS
Unauthorized Access	Gaining access to network segments, devices, or services that should be inaccessible — through credential theft, protocol exploits, or misconfiguration	Network access control; strong authentication; segmentation; least-privilege network policy; regular firewall rule reviews
Malware / C2 Communication	Malicious software communicating with attacker-controlled infrastructure over the network — ransomware beaconing, data exfiltration, command receipt	DNS filtering; proxy inspection; TLS inspection; behavioral anomaly detection; egress filtering; threat intelligence integration

Network Security Architecture

Secure network architecture is the disciplined design of network topology, segmentation, and traffic flows to minimize attack surface, contain breaches, and enforce least-privilege connectivity. Security architecture decisions made at design time are vastly cheaper to implement correctly than retrofitted controls added after deployment.

Network Segmentation Principles

Network segmentation divides the network into isolated zones with controlled traffic flows between them. Proper segmentation is the single most effective control for limiting the blast radius of a network compromise and slowing or stopping lateral movement:

Segmentation Tier	Design Principle	Implementation Mechanism
Internet / Untrusted Zone	Complete distrust — all traffic from the internet is presumed hostile until authenticated and validated; no direct access to internal systems	ISP border router with ingress/egress ACLs; scrubbing center for DDoS; only approved ports reach the perimeter firewall
DMZ / Perimeter Zone	Limited trust — public-facing services hosted here; inbound connections from internet permitted on specific ports; no direct connections to internal network	Dedicated firewall zone between internet and internal network; servers accessible from internet and limited internal access only for management and data retrieval
Internal Network Zones	Trust but verify — multiple internal zones based on data sensitivity and function; traffic between zones requires explicit firewall policy; no unrestricted east-west traffic	VLANs with inter-VLAN routing through firewall or NGFW; separate zones for servers, workstations, OT/ICS, guest, management, and development
Management / Out-of-Band Network	Strict isolation — only authorized administrators from authorized jump hosts can access management interfaces; no production traffic on management network	Separate VLAN or physical network for management interfaces (OOB management); access only from dedicated jump servers with PAM integration; no routing from production zones
OT / ICS Network	Maximum isolation — operational technology networks must be separated from corporate IT networks; no bidirectional connectivity except through approved unidirectional data diodes or tightly controlled jump servers	Physical separation preferred; if connected, data diodes or industrial firewalls with OT protocol inspection; no corporate credentials in OT environment

DMZ Architecture Models

DMZ Model	Architecture Description	Security Tradeoffs
Single Firewall (Three-Legged)	One firewall with three interfaces: Internet, DMZ, and Internal. DMZ is a separate interface on the perimeter firewall. Common in small-to-medium organizations.	Lower cost; simpler management. RISK: compromise of the single firewall provides access to both DMZ and internal network simultaneously. Not recommended for high-security environments.
Dual Firewall (Two-Tier)	Separate outer firewall (Internet → DMZ) and inner firewall (DMZ → Internal). Different vendors preferred to eliminate shared vulnerability. The gold standard DMZ design.	Higher cost and complexity; two distinct attack points an attacker must defeat. Different firewall vendors reduce risk of a single zero-day compromising both boundaries. Recommended for all organizations with significant internet-facing services.
Screened Subnet	Router with ACLs defines outer boundary; firewall defines inner boundary; DMZ hosts sit between router and firewall. Older model but still found in legacy environments.	Moderate cost; outer boundary is router (less inspection capability); inner boundary is full firewall. Migration path: replace outer router with NGFW to create dual-firewall architecture.
Parallel DMZ (Multiple Zones)	Multiple DMZ segments for different service types — separate DMZs for web servers, email gateways, DNS, partner extranet — each with its own firewall policy.	Maximum isolation between service types; a compromised web server cannot reach email gateway directly. Higher complexity and cost but best-practice for large organizations with diverse internet-facing services.

Architecture Principle

The guiding principle for DMZ design: internet-facing systems should never be able to directly initiate connections to internal systems. All connections from DMZ to internal network should be initiated by the internal network (e.g., internal database server pulls data from DMZ queue). A compromised DMZ server that cannot initiate connections inward cannot attack internal systems directly.

Zero Trust Network Architecture

Zero Trust Network Architecture (ZTNA) replaces the traditional ‘castle and moat’ perimeter model with a framework that verifies every access request regardless of network location. The fundamental shift: being ‘on the network’ grants no implicit trust.

Zero Trust Principle	Network Security Implementation
Verify Explicitly	Every network access request requires authentication and authorization verification — identity (who), device health (what device), location context (where from), and behavioral risk signals all evaluated before access is granted
Least Privileged Network Access	Replace broad network access with application-specific connectivity — users access applications, not networks. Software-Defined Perimeter (SDP) / ZTNA solutions establish per-session encrypted tunnels to specific applications only
Assume Breach / Micro-Segmentation	Design network assuming attackers are already inside — micro-segmentation prevents lateral movement; every workload boundary requires authentication; no flat internal network where any host can reach any other host
Continuous Verification	Session risk continuously evaluated — access can be revoked mid-session if risk signals change (impossible travel, anomalous data transfer, behavioral deviation)
Encrypted All Traffic	All network communication encrypted regardless of network location — no assumption that internal traffic is safe to transmit in cleartext; East-West encryption via mTLS or IPsec between services

Network Security Zone Design

Network Zone	Typical Residents	Key Security Requirements
Internet / External	Internet users, partner systems, external DNS, external email	All traffic treated as hostile; DDoS protection at ingress; perimeter firewall first line of inspection
DMZ / Perimeter	Web servers, email gateways (MTA), public DNS, WAF, load balancers, CDN PoPs, partner VPN termination	Minimal trust; web servers cannot initiate connections to internal DB directly; all management via jump server; WAF in front of all web applications
Server Zone	Internal application servers, API servers, internal databases, file servers, internal DNS/AD	Access from workstation zone via authenticated, port-restricted firewall policy; no direct internet access; all admin via PAM jump server
Workstation Zone	Employee computers, managed laptops, desktop clients	Access to server zone on application-specific ports only; EDR deployed; 802.1X authentication for network access; no server-to-workstation initiated connections
Guest / BYOD Zone	Personal devices, visitor networks, unmanaged IoT devices	Internet access only via web proxy; zero access to internal network; VLAN isolated; rate limiting; DNS filtering for malware protection
OT / ICS Zone	PLCs, SCADA systems, industrial control devices, building management systems	Maximum isolation; inbound connections from corporate: none or via dedicated unidirectional gateway only; dedicated OT security monitoring
Management Zone	Jump servers, PAM systems, network management systems, SIEM, vulnerability scanners	Access only from authorized administrator workstations; strict authentication; no internet access; all privileged device management exclusively through this zone

Perimeter Security Controls

Firewall Technology Evolution

Generation	Technology	Security Capability
1st Gen — Packet Filter	Inspects individual packets; permit/deny based on source IP, destination IP, and port number only; no state awareness	Basic IP/port access control; cannot detect attacks within permitted connections; easily evaded by using permitted ports; largely obsolete
2nd Gen — Stateful Inspection	Tracks the state of network connections; understands established/related sessions; maintains connection table for bidirectional traffic	Prevents unsolicited inbound connections; significantly reduces attack surface; still blind to application-layer content within permitted sessions
3rd Gen — NGFW (Application-Aware)	Inspects traffic at Layer 7; identifies applications regardless of port; integrates IPS, URL filtering, SSL inspection, threat intelligence, and user identity	Can block specific applications; detect and prevent attacks within HTTPS traffic; user-based policy; integrated threat prevention; the current enterprise standard
4th Gen — AI/ML-Enhanced	Adds behavioral analytics, AI-driven threat detection, automated response, and cloud-native management; integrates with broader XDR platform	Detects zero-day and novel attacks; automated policy tuning; microsecond response to new threat intelligence; cloud-scale visibility across all firewalls

Firewall Rule Design Principles

Firewall rules translate network security policy into technical enforcement. Poorly designed rules are one of the most common sources of network security vulnerabilities. Core design principles:

Default-Deny (Implicit Deny): The last rule in every firewall policy must be a deny-all. Only explicitly permitted traffic should pass. Any traffic not matching an allow rule should be dropped and logged.
Least Privilege Connectivity: Every rule should permit the minimum required traffic. ‘Allow TCP from 10.1.0.0/24 to 10.2.0.5 on port 443’ is better than ‘Allow all from 10.1.0.0/24 to 10.2.0.0/24’.
Specificity Over Generality: More specific rules should precede more general rules. Rules permitting specific hosts should come before rules permitting subnets. ‘Any’ source or destination should be rare and explicitly justified.
Business Justification Required: Every rule must have a documented owner, creation date, and business purpose. Rules without justification cannot be validated as authorized and should be disabled pending review.
Time-Limited Rules: Temporary rules (for testing, vendor access, or emergency situations) must have explicit expiration dates. Permanent rules should require periodic recertification.
Stealth Mode: Firewall interfaces should not respond to pings or port probes from untrusted networks — reduce information available to attackers during reconnaissance.

Intrusion Detection & Prevention Systems (IDS/IPS)

IDS/IPS systems inspect network traffic for signatures of known attacks and behavioral anomalies. IDS passively detects and alerts; IPS actively drops malicious traffic inline. Modern NGFWs incorporate IPS functionality, but dedicated sensors provide higher throughput and deeper protocol analysis:

Detection Method	How It Works	Strengths & Limitations
Signature-Based Detection	Compares traffic against a database of known attack signatures — exact pattern matching against known malware, exploits, and attack tools	STRENGTH: high accuracy for known threats; low false positives on well-tuned signatures. LIMITATION: blind to zero-days and novel attacks not yet in signature database; requires continuous signature updates
Anomaly-Based Detection	Establishes a statistical baseline of normal traffic behavior; alerts on deviations from baseline — unusual volume, port usage, protocol behavior	STRENGTH: can detect novel attacks that lack signatures; adaptive to environment. LIMITATION: high false positive rate until baseline is established; seasonal/business variation must be accounted for
Protocol Analysis	Deep inspection of protocol compliance — alerts on traffic that violates protocol specifications, which may indicate exploitation attempts or obfuscation	STRENGTH: detects evasion techniques that exploit protocol edge cases; catches malformed packet exploits. LIMITATION: computationally intensive; encrypted traffic limits analysis
Behavioral Heuristics	Identifies attack patterns without exact signatures — port scanning patterns, connection establishment anomalies, data staging behavior	STRENGTH: catches attack patterns even when specific tools or payloads are unknown. LIMITATION: tuning required to reduce false positives; may miss sophisticated low-and-slow attacks

IPS Tuning Is Critical

An untuned IPS is often worse than no IPS. Default IPS signature sets generate thousands of alerts in most enterprise environments — the vast majority false positives. Implement IPS in detection-only mode first; tune to eliminate false positives before enabling blocking mode. A single false positive blocking legitimate business traffic will result in emergency rule disablement and loss of protection. Tune, validate, then block.

Web Application Firewall (WAF)

A Web Application Firewall protects web applications and APIs by inspecting HTTP/HTTPS traffic and filtering malicious requests. WAF is a required control for any internet-facing web application — it is explicitly mandated by PCI DSS Requirement 6.4 for applications in the cardholder data environment.

WAF Deployment Model	Architecture & Use Case
Reverse Proxy (Inline)	WAF sits in the traffic path between clients and web servers; all requests pass through WAF before reaching application. Enables full inspection, blocking, and traffic manipulation. Most common deployment model. Best for: all internet-facing applications; highest protection level.
Cloud-Delivered WAF	Managed WAF service (Cloudflare, AWS WAF, Azure Application Gateway WAF, Akamai Kona); traffic routed through cloud scrubbing infrastructure before reaching origin. DDoS protection included. Best for: organizations without on-premises WAF expertise; rapid deployment; globally distributed protection.
Network-Inline WAF	Hardware WAF appliance deployed inline at network boundary; processes all web traffic destined for DMZ web servers. High throughput for large traffic volumes. Best for: very high-traffic environments; data-residency requirements preventing cloud routing.
Out-of-Band WAF (SPAN/TAP)	WAF monitors traffic via network tap or SPAN port; detects attacks but cannot block inline. Detection-only mode. Best for: non-disruptive initial deployment; auditing purposes. NOT sufficient for compliance requirements mandating blocking capability.

Network Access Control

Network Access Control (NAC) enforces security policy on devices attempting to connect to the network. Before a device is granted access, NAC verifies its identity, health posture, and compliance with security requirements. NAC prevents unauthorized devices — unmanaged personal devices, rogue systems, and compromised endpoints — from connecting to the corporate network.

IEEE 802.1X — Port-Based Authentication

IEEE 802.1X is the foundation of wired NAC. It requires authentication before a device can use a switch port. Until authentication succeeds, the port is in an unauthorized state and blocks all traffic except the authentication protocol:

802.1X Component	Role and Function
Supplicant	The device (laptop, desktop, server, IP phone) requesting network access; must have 802.1X client software installed (built into Windows, macOS, and Linux); presents credentials to authenticator
Authenticator (Network Switch/AP)	The network device (switch port or wireless access point) that enforces the authentication requirement; blocks or permits traffic based on authentication result from authentication server
Authentication Server (RADIUS)	The backend server (typically FreeRADIUS or Microsoft NPS) that validates credentials; communicates with authenticator via RADIUS protocol; returns Access-Accept or Access-Reject; can return VLAN assignments
EAP Methods	PEAP-MSCHAPv2 (most common — username/password with certificate); EAP-TLS (strongest — mutual certificate authentication; no password); EAP-TTLS (flexible inner authentication within TLS tunnel)

802.1X Security Benefits

Prevents unauthorized physical access — even with a network cable, a device cannot communicate without authenticating
Enables dynamic VLAN assignment — authenticated users are placed into the correct VLAN based on identity/role rather than physical port location
Supports MAC Authentication Bypass (MAB) for devices that cannot run 802.1X supplicants (printers, IP cameras, IoT) — authenticate by MAC address with compensating controls
Integration with endpoint compliance — modern NAC solutions can combine 802.1X with endpoint health checking, placing non-compliant devices into a remediation VLAN

NAC Enforcement Mechanisms

Enforcement Type	How It Works	Deployment Considerations
Pre-Admission NAC	Device is evaluated BEFORE network access is granted — checks OS patch level, antivirus currency, certificate presence, disk encryption status; only compliant devices get full access	Most secure approach; requires agent on endpoint (for deep health checks) or agentless profiling; VLAN redirect for non-compliant devices to remediation portal
Post-Admission NAC	Device is evaluated AFTER connecting to assess ongoing compliance; non-compliant devices are quarantined or disconnected during their session	Less disruptive for initial deployment; enables continuous compliance monitoring; SNMP-based quarantine or VLAN reassignment for non-compliant devices
VLAN-Based Quarantine	Non-compliant or unauthenticated devices placed in restricted VLAN with access only to remediation resources and internet; cannot reach production systems	Standard remediation mechanism; VLAN assignments returned by RADIUS server based on compliance posture; guest VLAN for unmanaged devices
Dynamic ACL (dACL)	RADIUS server returns per-session access control list applied to the specific switch port or wireless session — granular per-device access control without VLAN changes	More granular than VLAN assignment; per-device policy; good for environments with complex access requirements; requires switch support for downloadable ACLs

Device Profiling and Identity

Modern NAC solutions go beyond authentication to profile devices — identifying device type, operating system, manufacturer, and compliance status to enforce identity-aware network policy:

Device ProfilingFingerprinting of connected devices using DHCP options, HTTP user-agents, MAC OUI (manufacturer prefix), SNMP, and TCP/IP stack behavior — identifies device type without requiring an agent
Managed vs. UnmanagedCorporate-managed devices with domain membership, certificates, and EDR agents receive full network access; unmanaged devices (personal devices, guests) are restricted to internet-only access
IoT / OT Device ManagementPrinters, IP cameras, building systems, and medical devices cannot run traditional NAC agents — profiling-based policies place these devices into appropriate restricted VLANs automatically
Rogue Device DetectionNAC continuously monitors connected devices for unauthorized connections; new devices generate alerts for investigation before receiving any network access

VPN and Secure Remote Access

Secure remote access allows authorized users to connect to organizational networks and resources from external locations while maintaining the same security posture as on-premises access. The evolution from traditional full-tunnel VPN to Zero Trust Network Access (ZTNA) reflects the shift from network-centric to identity-centric security models.

VPN Technology Types

VPN Type	Technology & Architecture	Security Considerations
IPsec Site-to-Site VPN	Encrypted tunnel between two network gateways — connects entire networks (branch office to HQ, cloud to on-premises). Uses IKE for key exchange; ESP for encryption.	Strong cryptographic security; widely supported; requires dedicated gateway on both ends; must enforce AES-256/SHA-256 minimum; IKEv2 preferred over IKEv1; disable DH Group 1/2/5 (weak)
SSL/TLS Remote Access VPN	Client-initiated encrypted tunnel over HTTPS (port 443); used for remote worker access. Client software establishes tunnel to VPN concentrator; traffic routed through corporate network.	Traverses most firewalls (port 443); split-tunnel vs. full-tunnel policy critical; TLS 1.2 minimum, TLS 1.3 preferred; certificate-based authentication preferred over password; MFA mandatory
Always-On VPN	VPN connection established automatically before user logon; all traffic tunneled through corporate network regardless of user action; enforced by MDM policy.	Ensures consistent security policy for all corporate traffic; prevents users from disabling VPN; critical for endpoint compliance and monitoring; performance impact must be managed via split-tunnel policy
ZTNA / SDP	Application-specific access without network-level access; client authenticates to broker; broker establishes encrypted micro-tunnel to specific application only; user never has network access	The evolution beyond traditional VPN; eliminates lateral movement risk (user can only reach specific authorized applications, not the whole network); best for cloud-first and hybrid environments

VPN Security Configuration Requirements

Configuration Requirement	Specification & Rationale
Minimum Encryption: AES-256	AES-128 is acceptable but AES-256 is preferred for high-security environments; 3DES must be disabled (known weaknesses); DES must be disabled (broken since 1999)
Minimum Key Exchange: IKEv2 / TLS 1.2+	IKEv1 has known vulnerabilities and should be disabled; IKEv2 provides stronger authentication and faster re-key. For SSL VPN: TLS 1.2 minimum; TLS 1.3 preferred; disable TLS 1.0 and 1.1 explicitly
Diffie-Hellman Groups: 14 or higher	DH Groups 1, 2, and 5 are considered weak (768/1024/1536-bit); minimum DH Group 14 (2048-bit); Group 19/20/21 (ECDH) preferred for modern implementations
Mandatory MFA for Remote Access	Password-only VPN authentication is insufficient; all remote access must require MFA; phishing-resistant MFA (FIDO2) preferred for privileged remote access; certificate + MFA for highest assurance
Split Tunnel Policy	Full-tunnel routes all user traffic through corporate network (higher security, higher latency); split-tunnel routes only corporate-destined traffic through VPN (better performance, reduced visibility). If split-tunnel: implement DNS-based security for non-corporate traffic
Session Timeout	Idle sessions should time out within 15-30 minutes; maximum session length should be set (8-12 hours); re-authentication required after timeout; long sessions increase exposure window if device is compromised
Certificate Validation	VPN clients must validate server certificate against trusted CA chain; certificate pinning recommended for corporate VPN clients; revocation checking (OCSP or CRL) must be enabled to detect revoked certificates

ZTNA vs. Traditional VPN

Dimension	Traditional Full-Tunnel VPN	Zero Trust Network Access (ZTNA / SDP)
Access Model	User gets full network access to the segment the VPN is connected to — all hosts in the network are reachable	User gets access ONLY to specific authorized applications — no network-level access; lateral movement is impossible
Lateral Movement Risk	HIGH — compromised VPN endpoint can attack all network-accessible systems	MINIMAL — compromised endpoint can only reach the specific applications explicitly authorized for that user/device
Authentication	Typically: username/password + MFA at VPN gateway	Continuous: identity verification + device health + behavioral signals evaluated per-request; access can be revoked during a session
Internet-Facing Exposure	VPN concentrator must be internet-accessible — a publicly known attack target (VPN exploits are extremely common in ransomware attack chains)	Broker infrastructure is dark to the internet; only authenticated clients know where to connect; dramatically reduced attack surface
Performance	Full-tunnel: significant latency; split-tunnel: better but routing complexity	Application-specific tunnels; modern implementations with cloud PoPs provide low latency; better user experience than full-tunnel VPN
Cloud Compatibility	VPN backhauling cloud traffic through corporate network is inefficient	Native cloud integration; users connect directly to cloud applications via ZTNA broker; no backhaul required

Wireless Network Security

Wireless networks extend the network boundary into physical space — any device within radio range can potentially attempt network access, making wireless security fundamentally different from wired network security. Wireless attacks are common, difficult to detect, and frequently used as initial access vectors for organizational breaches.

Wireless Security Protocol Evolution

Protocol	Year	Security Status	Current Disposition
WEP	1997	BROKEN — RC4 implementation flaws; crackable in minutes with widely available tools	FORBIDDEN — any network still using WEP should be considered fully compromised; immediate migration required; finding in any audit = Critical
WPA (TKIP)	2003	DEPRECATED — TKIP has known vulnerabilities; multiple practical attacks demonstrated	FORBIDDEN — disable TKIP support on all access points; WPA-TKIP must not be available on any corporate SSID
WPA2-Personal (PSK)	2004	WEAK for enterprise — shared key; offline brute-force attacks against captured handshake (PMKID attack); no individual user accountability	ACCEPTABLE only for home/small office; not acceptable for enterprise environments; if used, require long random passphrase (20+ characters); change regularly
WPA2-Enterprise (802.1X)	2004	STRONG — individual credentials per user; no shared key; RADIUS backend authentication; widely deployed	REQUIRED for corporate SSIDs; individual user/device authentication; integrates with AD; enables per-user VLAN assignment; PEAP-MSCHAPv2 or EAP-TLS
WPA3-Personal (SAE)	2018	STRONG — Simultaneous Authentication of Equals; resistant to offline dictionary attacks; forward secrecy	PREFERRED for non-enterprise environments; deploy on all new access points; WPA3-SAE eliminates offline PMKID attack vectors
WPA3-Enterprise	2018	STRONGEST — 192-bit mode available; Management Frame Protection (MFP) mandatory; eliminates WPA2 vulnerabilities	RECOMMENDED for high-security enterprise deployments; healthcare, finance, and government should transition to WPA3-Enterprise; backward compatible with WPA2-Enterprise clients

Wireless Attack Types and Defenses

Attack Type	Description	Defense
Evil Twin / Rogue AP	Attacker sets up a wireless AP with the same SSID as the legitimate corporate network; clients connect to the attacker’s AP and transmit credentials or data	802.1X with server certificate validation (clients reject APs without valid certificate); WIDS to detect duplicate SSIDs; client-side certificate pinning for corporate SSID
PMKID Attack (WPA2-PSK)	Offline attack capturing PMKID from beacon frames (no client required); then brute-forcing the PSK using hashcat at billions of guesses per second	Use WPA3-SAE (resistant by design) or WPA2-Enterprise (no shared PSK to attack); if WPA2-PSK is required, passphrase must be 20+ random characters
Deauthentication Attack	Sends spoofed 802.11 deauthentication frames forcing clients off the network — denial of service; can force clients to reconnect to evil twin	Management Frame Protection (MFP/PMF) — 802.11w; prevents spoofed deauthentication frames; required in WPA3; should be enabled on all WPA2-Enterprise networks
Karma / MANA Attack	Rogue AP responds to client probe requests for any SSID, impersonating networks the client previously connected to	Minimize probe request exposure (disable automatic reconnection); WPA3 eliminates legacy probe behaviors; 802.1X prevents credential exposure even if client connects to rogue AP
Wireless MitM (via Rogue AP)	Client connects to rogue AP; attacker forwards traffic to real AP; client’s traffic is intercepted and potentially modified	TLS/HTTPS for all sensitive traffic; HSTS; VPN required for all traffic when not on corporate network; WIDS to detect rogue APs
Password Spraying via Wi-Fi	Using wireless access to attempt credential stuffing attacks against RADIUS/AD without generating alerts from a specific wired location	Account lockout policy; RADIUS log monitoring for multiple authentication failures from same client; geo/time-based anomaly detection on RADIUS

Enterprise Wireless Security Architecture

SSID Segregation: Separate SSIDs for corporate devices (WPA2/3-Enterprise), IoT devices, and guests — each mapped to an appropriate VLAN with appropriate firewall policy
Corporate SSID: WPA2/3-Enterprise with 802.1X authentication; RADIUS backend with Active Directory integration; certificate-based validation of RADIUS server by clients; Management Frame Protection enabled
Guest SSID: WPA3-Personal or WPA2-Personal with a unique passphrase changed regularly; VLAN isolated to internet access only; rate limited; DNS filtering enabled; no access to internal corporate resources
IoT / Device SSID: Separate VLAN for IoT devices; highly restricted firewall policy; no lateral movement capability; profiling-based NAC to identify and categorize devices
Wireless IDS/IPS (WIDS): Continuously monitors for rogue access points, deauthentication attacks, ad-hoc networks, and other wireless threats; integrated with main SIEM for alerting
AP Management Security: All wireless access points managed via encrypted controller (on-premises or cloud); strong authentication to management interface; regular firmware updates; physical security of AP hardware

DNS Security

The Domain Name System (DNS) is the internet’s phone book — translating human-readable domain names into IP addresses. DNS is also one of the most exploited protocols in modern cyberattacks. Attackers use DNS for initial access (phishing via typosquatting), command-and-control (DNS tunneling), exfiltration (data encoded in DNS queries), and to bypass other security controls (DNS over HTTPS).

DNS Is Everywhere

DNS traffic is one of the most reliable attack channels because it is almost never blocked. Organizations that block HTTP/HTTPS to suspicious domains frequently leave DNS unrestricted, allowing attackers to establish C2 channels, exfiltrate data, and receive commands entirely through DNS queries to attacker-controlled nameservers. Monitoring and filtering DNS is as important as filtering web traffic.

DNS Attack Types

Attack Type	Mechanism	Defense
DNS Cache Poisoning	Attacker injects forged DNS responses into a resolver’s cache; all clients using that resolver are directed to attacker-controlled IP addresses for the poisoned domain	DNSSEC (signs DNS records; clients validate signatures); randomize source port and query ID; DANE (DNS-based Authentication of Named Entities)
DNS Hijacking	Attacker modifies DNS settings on a router, resolver, or domain registrar account — redirects queries to malicious resolver that returns false results	Registrar lock and multi-factor authentication for domain registrar accounts; DNSSEC; registry lock for critical domains; monitoring for unauthorized DNS record changes
DNS Tunneling (Data Exfiltration)	Data encoded in DNS query subdomains and exfiltrated through legitimate-looking DNS traffic; C2 commands returned in DNS responses; bypasses many security controls	DNS traffic inspection (analyze query rate, subdomain entropy, query length); block direct client-to-internet DNS (force all DNS through controlled resolver); DNS RPZ (Response Policy Zones)
DNS-Based C2 Communication	Malware communicates with C2 infrastructure exclusively through DNS queries — extremely difficult to block without disrupting all DNS; used by advanced persistent threats	Behavioral DNS monitoring (high-volume queries to single domain, NXDomain storms, DGA domain queries); threat intelligence feed integration with DNS resolver; DNS firewall (RPZ)
Domain Generation Algorithm (DGA)	Malware generates thousands of pseudo-random domain names daily; only attacker knows which domain is ‘live’ today; nearly impossible to block by domain name alone	Machine learning-based DGA detection (query pattern, domain entropy analysis); SIEM correlation of NXDomain responses; threat intelligence blocking known DGA families
Subdomain Takeover	Attacker claims an abandoned subdomain that still has a DNS CNAME record pointing to a deprovisioned cloud resource (S3 bucket, Azure endpoint, Heroku app)	Regular DNS record audit; scan for unresolvable CNAME targets; monitoring for DNS records pointing to deprovisioned resources; decommissioning checklist includes DNS record removal

DNS Security Controls

Control	Description & Implementation
DNSSEC	Digitally signs DNS records using public-key cryptography; resolvers validate signatures to detect tampering or cache poisoning. Requires signing of zones and validation in resolvers. Mandatory for .gov TLDs; strongly recommended for all authoritative DNS zones.
DNS RPZ (Response Policy Zones)	DNS firewall that returns custom responses for malicious domains — blocks resolution of known C2 domains, phishing sites, and malware distribution points by returning NXDOMAIN, NODATA, or custom IP. Integrates with threat intelligence feeds.
Protective DNS (DNS-Based Filtering)	Cloud-based or on-premises DNS resolver that incorporates threat intelligence — blocks resolution of malicious domains automatically. Cisco Umbrella, Cloudflare Gateway, Quad9, and NSA PDNS all provide this capability.
Internal DNS Segregation	Separate internal DNS servers for internal resource resolution and external DNS resolvers for internet queries. Prevents internal DNS information from being accessible externally; prevents DNS rebinding attacks.
DNS Logging and Monitoring	Log all DNS queries with client IP, queried domain, response code, and timestamp; forward to SIEM for analysis. Required evidence source for incident response — DNS logs often reveal C2 communication and exfiltration that other controls miss.
Block Direct External DNS	Force all client DNS traffic through corporate DNS resolvers using firewall rules intercepting or blocking DNS to external resolvers. Prevents bypassing of DNS security controls by clients configured with public DNS (8.8.8.8, 1.1.1.1).
DoH/DoT Policy	DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic — beneficial for end users but bypasses enterprise DNS security controls. Enterprise policy: block DoH/DoT to external providers at firewall; use enterprise-controlled DoH/DoT resolver.

Network Protocol Security

Network protocols were largely designed for reliability and functionality, not security. Many foundational protocols — ARP, DHCP, ICMP, SMTP, BGP, SNMP — have inherent security weaknesses that attackers routinely exploit. Understanding protocol-level vulnerabilities is essential for designing effective network defenses.

Layer 2 Protocol Threats and Defenses

Protocol / Attack	Vulnerability & Attack Mechanism	Defense Controls
ARP Spoofing / Poisoning	ARP has no authentication — any host can send a gratuitous ARP claiming any IP address. Attacker responds to ARP requests with their own MAC, redirecting traffic through their system for MitM interception.	Dynamic ARP Inspection (DAI) on switches — validates ARP packets against DHCP snooping binding table; blocks spoofed ARP responses; static ARP entries for critical servers in small environments
DHCP Spoofing / Starvation	Rogue DHCP server responds to client requests with attacker-controlled DNS and gateway — redirects all traffic through attacker. DHCP starvation exhausts IP pool to deny addresses.	DHCP Snooping on switches — designates trusted DHCP server ports; drops DHCP server messages on untrusted ports; builds binding table for DAI; rate-limits DHCP traffic per port
MAC Flooding / CAM Table Overflow	Flooding switch with thousands of fake source MAC addresses exhausts CAM table; switch falls back to hub behavior (flooding all ports) — attacker on any port sees all traffic.	Port security on switches — limit MAC addresses per port (typically 1-3); violation action: restrict or shutdown; 802.1X provides better enterprise-scale solution
VLAN Hopping (Switch Spoofing)	Attacker’s host negotiates as a trunk port using DTP (Dynamic Trunking Protocol); gains access to traffic from all VLANs on the trunk.	Disable auto-trunking (DTP) on all access ports: `switchport nonegotiate`; set all non-trunk ports to access mode explicitly; use dedicated VLANs (not VLAN 1) for production traffic
VLAN Hopping (Double Tagging)	Attacker sends double-tagged 802.1Q frames; outer tag stripped by first switch; inner tag processed by second switch as if from native VLAN — allows traffic injection into other VLANs.	Change native VLAN from VLAN 1 to an unused, non-routed VLAN on all trunk ports; never place user traffic on the native VLAN; use 802.1Q tag tagging on trunk ports

Routing Protocol Security

Protocol	Security Risk	Defense
BGP (Border Gateway Protocol)	BGP has no built-in authentication — any AS can announce routes for any IP prefix. BGP hijacking redirects internet traffic through attacker-controlled ASes. Responsible for major internet outages and traffic interception events.	RPKI (Resource Public Key Infrastructure) — cryptographically validates route origin authorization; BGP prefix filtering; BGPSEC; peer authentication using MD5 (legacy) or TCP-AO (preferred); route filtering policies at IXPs
OSPF (Open Shortest Path First)	OSPF messages can be injected if authentication is not configured; attacker can manipulate routing tables in the internal network to redirect traffic.	Enable OSPF authentication on all interfaces: SHA-HMAC authentication preferred; never rely on MD5 OSPF authentication in high-security environments; redistribute routes with care between routing domains
RIP (Routing Information Protocol)	RIPv1 has no authentication and limited scalability; RIPv2 supports MD5 authentication but still broadcast-based; susceptible to route injection attacks.	Migrate to OSPF or EIGRP in all enterprise environments; if RIP must be used, enable MD5 authentication; filter routes accepted from untrusted peers; RIPv1 must not be used in any environment

Email Protocol Security (SMTP, DMARC, DKIM, SPF)

Email protocols are critical attack vectors for phishing, business email compromise, and malware delivery. Three complementary email authentication standards work together to prevent email spoofing:

Standard	What It Does	Implementation Requirement
SPF (Sender Policy Framework)	DNS TXT record listing servers authorized to send email for a domain; receiving server checks whether sending server IP is authorized	Publish SPF record for ALL domains (including non-sending domains with ‘~all’ or ‘-all’); policy should be ‘-all’ (hard fail) for domains not used for email sending
DKIM (DomainKeys Identified Mail)	Cryptographic signature applied to email headers and body; receiving server validates signature using public key in DNS; proves message integrity and sender domain	Generate 2048-bit RSA key pair (or stronger); publish public key in DNS; sign all outbound email; rotate keys annually; also sign transactional and marketing email subdomains
DMARC	Policy specifying what to do with email failing SPF/DKIM checks; three policies: p=none (monitor), p=quarantine (spam), p=reject (block). Provides aggregate reporting.	Start with p=none to monitor without impact; analyze reports to fix legitimate sources; advance to p=quarantine; then p=reject. Goal: p=reject policy on all organizational domains. BIMI requires DMARC enforcement.
STARTTLS / Opportunistic TLS	Encrypts SMTP connections between mail servers; prevents interception of email in transit between mail servers; opportunistic (will fall back to cleartext if peer doesn’t support)	Enforce TLS for SMTP connections where possible; configure MTA-STS (Mail Transfer Agent Strict Transport Security) to prevent downgrade attacks and require TLS for all email delivery

ICMP and Network Scanning Defenses

Block ICMP echo requests (ping) from the internet to internal systems — reduces reconnaissance capability; allow only from specific monitoring hosts internally
Permit ICMP unreachable and time-exceeded — required for proper TCP path MTU discovery and traceroute functionality; blocking these breaks many legitimate network operations
Block ICMP redirects inbound from internet — ICMP redirects can be used to manipulate routing; no legitimate inbound ICMP redirect from internet should occur
Rate-limit ICMP at the perimeter — prevents ICMP-based DoS and covert channel communication by limiting bandwidth available to ICMP traffic
Monitor for ICMP tunneling — unusually large ICMP payloads (normal ping = 32-64 bytes; tunneling tools use 1000+ bytes); detect with SIEM correlation rules

Network Monitoring and Detection

Network monitoring provides visibility into traffic flows, enables detection of threats that evade endpoint controls, and creates the forensic record needed for incident investigation. Effective network monitoring requires a layered approach combining flow analysis, full packet capture, DNS logging, and behavioral analytics.

Network Monitoring Architecture

Monitoring Layer	Technology	What It Detects
Flow-Based (NetFlow/IPFIX/sFlow)	Routers and switches export metadata about traffic flows — source/destination IP, port, protocol, bytes, duration. No payload inspection. Centrally collected in a flow collector.	Unusual traffic volumes; new communication paths; lateral movement patterns; large data transfers; scanning activity; beaconing patterns; communication with known-malicious IPs
Full Packet Capture (PCAP)	Network TAP or SPAN port collects complete packet-level data; stored for forensic analysis; requires significant storage; typically deployed at critical network chokepoints only.	Complete session reconstruction; payload analysis; protocol anomalies; encrypted traffic metadata (JA3/JA3S fingerprinting even without decryption); definitive incident investigation
DNS Log Analysis	All DNS queries and responses logged with client IP, queried domain, response code, and TTL; forwarded to SIEM for analysis and threat intelligence correlation.	C2 communication via DNS; DNS tunneling (high entropy subdomains, high query volume); DGA domain patterns; malware infection indicators; data exfiltration via DNS
NDR (Network Detection & Response)	Combines multiple data sources (flow, packets, DNS) with ML-based behavioral analytics; detects known and novel threats; integrates with SIEM/SOAR for automated response.	Advanced persistent threats; insider threats; lateral movement; novel attack patterns without signatures; encrypted C2 detection via traffic fingerprinting; user/entity behavior anomalies
NetFlow / Traffic Anomaly Baselining	Establishes normal traffic patterns for each network segment; alerts on deviations — new connections, unusual volumes, off-hours activity, new external communication patterns.	Zero-day attacks and novel techniques; insider threat data staging; unauthorized cloud uploads; anomalous east-west traffic between segments that should not communicate

Network Security Monitoring — Key Log Sources

Log Source	Critical Fields to Capture & Retention Requirement
Perimeter Firewall	Source IP, destination IP, destination port, protocol, action (permit/deny), bytes, rule number, timestamp. Minimum 12-month retention. Essential for: attack origin tracing, lateral movement detection, policy compliance verification
DNS Server Logs	Client IP, queried domain, query type, response code, response IP, timestamp. Minimum 12-month retention. Essential for: C2 detection, exfiltration detection, malware infection indicator
DHCP Lease Logs	MAC address, assigned IP, lease start/end, hostname. Minimum 12-month retention. Essential for: correlating IP addresses to device identities during incident investigation; required for forensic timeline construction
VPN Access Logs	Username, client IP, assigned VPN IP, connection duration, bytes transferred, geographic location, MFA result, timestamp. Minimum 12-month retention. Essential for: detecting credential compromise, anomalous access, unauthorized location access
Network IDS/IPS Logs	Signature fired, source/destination IP, protocol, severity, action taken, timestamp. Minimum 12-month retention. Essential for: documenting attack activity, IPS blocking evidence for compliance
NetFlow / Traffic Flow Data	Source/destination IP+port, protocol, bytes, packets, duration, direction. Minimum 90-day retention for full flows; aggregate retention longer. Essential for: bandwidth baseline, lateral movement, C2 beaconing patterns
Proxy / Web Gateway Logs	Client IP, URL, category, action (allow/block), user agent, bytes, timestamp, MIME type. Minimum 12-month retention. Essential for: web-based threat detection, exfiltration via HTTP, user activity monitoring

Network Threat Hunting

Threat hunting is the proactive search for threats that have bypassed automated detection controls. Network threat hunting uses traffic data to search for indicators of compromise that SIEM rules alone would not surface:

Hunt Hypothesis	Data Sources & Investigation Approach
Beaconing C2 traffic is present	Analyze NetFlow for regular, periodic connections to external IPs — exact intervals suggest automated beaconing vs. human browsing (which is irregular). Look for: low-byte regular connections (heartbeat), unusual ports, connections during off-hours, new external destinations for established hosts
Lateral movement in progress	Query firewall/flow logs for unusual east-west traffic patterns — connections between segments that should not communicate; SMB connections from workstations to servers not normally accessed; scanning patterns from a single internal source to multiple internal destinations
Data staging for exfiltration	Look for large file transfers to cloud storage services or unusual external destinations; DNS queries with anomalously large payloads; HTTPS uploads with high byte counts to newly-seen destinations; database queries accessing large numbers of records
Compromised credentials used for lateral movement	Query VPN logs for impossible travel (two logins from geographically distant locations within impossible timeframe); authentication to internal resources from VPN IP without expected prior authentication patterns; admin tool usage from non-admin accounts
Living-off-the-land attack using legitimate tools	Hunt for PowerShell, WMI, or administrative tool activity from systems that do not normally use these tools; WMIC or PsExec lateral movement; scheduled task creation from unusual sources; network connections from Windows Management tools to other hosts

DDoS Protection

Distributed Denial of Service (DDoS) attacks attempt to exhaust network capacity, system resources, or application processing capability to deny service to legitimate users. Modern DDoS attacks can be measured in terabits per second — beyond the capacity of any single organization to absorb without purpose-built mitigation. DDoS protection requires a multi-layer strategy: upstream scrubbing, on-premises rate limiting, and application resilience.

DDoS Attack Taxonomy

Attack Category	Mechanism	Mitigation Approach
Volumetric — UDP Flood	Floods target with massive volumes of UDP packets; exhausts bandwidth; no spoofing required but often uses spoofed sources; amplification via UDP-based protocols (DNS, NTP, SSDP, memcached) can multiply attack traffic 10-100×	Upstream scrubbing center; BGP blackholing; ISP traffic filtering; anycast routing to distribute attack across global PoPs; rate-limit UDP to specific ports only where required
Volumetric — DNS Amplification	Attacker sends small DNS queries with spoofed source IP (victim IP) to open DNS resolvers; resolvers send large DNS responses to victim. 100 bytes request → 4000 bytes response (40× amplification factor)	Block DNS queries from outside organization to internal resolvers; deploy DNSSEC to prevent resolver abuse; ISP-level source address validation (BCP38); anycast DNS distribution
Protocol — SYN Flood	Floods target with TCP SYN packets without completing the 3-way handshake; server allocates resources for half-open connections; connection table fills; legitimate connections denied	SYN cookies on servers/firewalls (no resource allocation until handshake complete); rate limiting SYN packets per source IP; connection table size tuning; upstream scrubbing detects and drops SYN floods
Protocol — Fragmentation Attack	Sends malformed, fragmented IP packets designed to exhaust reassembly buffers or crash network stacks; Teardrop, Ping of Death attacks use invalid fragmentation	Modern OS patch for fragmentation vulnerabilities; firewall inspection of fragmented packets; rate-limit fragmented traffic; block fragments on protocols that should not be fragmented
Application Layer — HTTP Flood	Sends massive numbers of seemingly legitimate HTTP GET/POST requests; exhausts web server thread pool and database connections without generating abnormal traffic patterns at network level	Rate limiting per source IP; CAPTCHA challenges; bot management (behavioral analysis); CDN/WAF with Layer 7 DDoS protection; resource-intensive request limiting
Application Layer — Slowloris	Opens many HTTP connections and sends partial headers very slowly; keeps connections open indefinitely; server’s connection pool fills with slow connections; legitimate users denied	Reduce connection timeout; increase max connections; WAF with Slowloris detection; HAProxy/nginx request timeout tuning; client connection limits per IP

DDoS Mitigation Architecture

Mitigation Layer	Technology & Implementation
BGP Blackholing (RTBH)	Route to Null — null-route the attacked destination IP at the ISP or internet exchange; drops all traffic destined for that IP at the network edge. Fast but destroys availability for the targeted IP during attack — surgical option when a specific IP is under attack while other services must remain available.
Upstream Scrubbing Center	Traffic redirected (via BGP or DNS) to scrubbing center operated by CDN/DDoS provider (Cloudflare, AWS Shield, Akamai, Radware); malicious traffic filtered; clean traffic forwarded to origin. Most comprehensive protection — handles terabit-scale volumetric attacks. Monthly cost typically $5K-$50K+ depending on capacity.
Anycast Routing	Distribute the same IP prefix from multiple geographically distributed PoPs; DDoS traffic is distributed across all PoPs rather than concentrating at single destination; each PoP handles a fraction of total attack volume. Used by Cloudflare, Akamai, and other CDN providers.
On-Premises Anti-DDoS Hardware	Dedicated DDoS mitigation appliances (Radware DefensePro, Netscout Arbor) deployed at network edge; behavioral baselines; automated mitigation of known attack patterns; effective for smaller-scale attacks; ineffective against volumetric attacks that exceed uplink capacity.
Rate Limiting at Perimeter	Firewall and router rate-limiting rules restrict traffic volumes per source IP, per protocol, or per destination; prevents connection table exhaustion; reduces impact of sub-volumetric floods. First line of on-premises defense; configured in conjunction with upstream scrubbing.
CDN for Static Content	Distributing static content (CSS, JS, images) via CDN reduces origin server load; CDN handles most client requests without touching origin; dramatically reduces DDoS exposure for web applications; Cloudflare, Fastly, and Akamai provide integrated DDoS protection.

Network Encryption

Network encryption protects data in transit from interception and modification. Three complementary encryption technologies operate at different network layers to provide comprehensive protection: TLS at the application layer, IPsec at the network layer, and MACsec at the data link layer.

TLS (Transport Layer Security)

TLS is the primary encryption protocol for internet communications — it secures HTTPS, SMTPS, IMAPS, LDAPS, and thousands of other application protocols. Understanding TLS configuration is essential for both implementing and auditing network security:

TLS Version	Security Status	Action Required
SSL 2.0 / 3.0	BROKEN — multiple critical vulnerabilities (POODLE, DROWN); completely insecure	DISABLE IMMEDIATELY — must not exist on any system; finding = Critical in all compliance frameworks
TLS 1.0	DEPRECATED — BEAST, POODLE, and other attacks; PCI DSS explicitly prohibits	DISABLE — PCI DSS 3.2.1+ requires disabling TLS 1.0 on all cardholder data systems; NIST recommends against; disable on all systems
TLS 1.1	DEPRECATED — No longer considered secure; removed from major browsers in 2021	DISABLE — should not be supported on any new or existing system; browser support removed; IETF deprecated in RFC 8996
TLS 1.2	ACCEPTABLE — Secure with proper cipher suite selection; widely supported	MAINTAIN with strong cipher suites only; disable weak ciphers (3DES, RC4, export ciphers, NULL); use forward-secret cipher suites (ECDHE)
TLS 1.3	BEST — Removed all weak cipher suites; mandates forward secrecy; faster handshake (1-RTT vs 2-RTT); eliminated known vulnerabilities	PREFER on all new deployments; require for internal service communication; legacy client compatibility may require maintaining TLS 1.2 as fallback

TLS Configuration Requirements

Cipher Suites: Enable only cipher suites with ECDHE key exchange (forward secrecy); AES-128-GCM or AES-256-GCM (authenticated encryption); SHA-256 or SHA-384 MAC. Disable: RC4, 3DES, DES, NULL ciphers, export-grade ciphers, anonymous (aNULL) ciphers.
Certificate Requirements: 2048-bit RSA minimum (4096-bit for long-lived certificates); ECDSA P-256 or P-384 as efficient alternative; SHA-256 minimum for certificate digest; 1-year maximum validity per CA/Browser Forum Baseline Requirements.
HSTS (HTTP Strict Transport Security): Requires browsers to only connect via HTTPS; preload list entry prevents even first-visit HTTP connection; must include subdomains; min-age of 1 year for mature deployments.
Certificate Transparency: All publicly-trusted certificates must be logged in CT logs; enables monitoring for unauthorized certificates issued for your domain; configure ct.watch or crt.sh monitoring.

IPsec

IPsec provides network-layer encryption and authentication for IP packets. Used for site-to-site VPN, remote access VPN, and host-to-host encryption within enterprise networks:

IPsec Component	Function	Security Configuration
IKE Phase 1 (ISAKMP SA)	Establishes a secure channel for IKE negotiations; authenticates peers; negotiates encryption algorithm for the IKE channel itself. IKEv2 preferred over IKEv1.	AES-256-CBC or AES-128-CBC encryption; SHA-256 or SHA-384 integrity; DH Group 14 minimum (2048-bit) — Groups 19, 20, 21 preferred; certificate-based authentication preferred over PSK
IKE Phase 2 (IPsec SA)	Negotiates the actual IPsec tunnel parameters — encryption algorithm, integrity algorithm, PFS setting, and lifetime for the data encryption SA.	AES-256-GCM or AES-128-GCM preferred (authenticated encryption); Perfect Forward Secrecy (PFS) MUST be enabled — re-keys DH after each tunnel establishment; SA lifetime: 1 hour or 4GB maximum
ESP (Encapsulating Security Payload)	Provides encryption, integrity, and anti-replay protection for IP packets. The primary IPsec data protection protocol.	Always use ESP — never AH alone (AH provides authentication but no encryption); use AEAD cipher modes (GCM) that provide both encryption and authentication in one pass
AH (Authentication Header)	Provides authentication and integrity for IP headers — no encryption. Rarely used alone; incompatible with NAT (modifies IP headers).	Do not use AH without ESP; AH alone provides no confidentiality protection; if authentication without encryption is required, use ESP with NULL encryption (not recommended)

TLS Inspection (SSL Decryption)

TLS inspection (also called SSL decryption or man-in-the-middle inspection) allows security devices to decrypt, inspect, and re-encrypt HTTPS traffic — necessary to detect threats hiding in encrypted channels:

Technical ImplementationFirewall or proxy presents its own certificate (signed by internal CA) to clients; decrypts traffic; performs security inspection; re-encrypts using original server certificate information. Clients must trust the inspection device’s CA certificate.
Business Justification80%+ of internet traffic is now HTTPS; without TLS inspection, organizations are blind to malware C2, data exfiltration, and web-based attacks delivered via HTTPS. Threat actors deliberately use HTTPS for C2 specifically because many organizations do not inspect encrypted traffic.
Privacy ConsiderationsTLS inspection should not apply to categories with legal or ethical sensitivity — banking sites, healthcare portals, attorney-client communication, HR portals, and personal email. Configure bypass policies for these categories.
Performance ConsiderationsTLS inspection is computationally intensive; dedicated hardware acceleration (SSL offload cards) required for high-throughput environments; capacity planning must account for inspection overhead.
Certificate DeploymentInternal CA certificate used for inspection must be distributed to all managed devices via GPO or MDM; ensure certificate rotation procedures are in place; inspection certificates should have a maximum 1-year validity.

Cloud Network Security

Cloud network security requires adapting traditional network security principles to a software-defined environment where infrastructure is provisioned via API, segmentation is implemented through virtual networks and security groups, and the shared responsibility model determines what the cloud provider secures versus what the customer must configure. The most common cause of cloud security breaches is misconfiguration — not exploitation of vulnerabilities.

Cloud Network Segmentation

Cloud Construct	Security Purpose	Key Configuration Requirements
VPC / VNet (Virtual Private Cloud)	Isolated virtual network within cloud provider; logically separate from other customers’ networks; foundation of cloud network segmentation	Separate VPCs for production, development, and staging; CIDR range planning to avoid overlaps; enable VPC Flow Logs from day one; tag all VPCs with owner, environment, and cost center
Subnets (Public / Private)	Subdivide VPC into public subnets (internet-routable) and private subnets (no direct internet access); resources requiring internet access in public; databases and application servers in private	Public subnet: resources with internet-facing roles only (NAT gateway, load balancer, bastion host); Private subnet: all application servers, databases, and sensitive workloads; no direct internet gateway route in private subnets
Security Groups (AWS / Azure NSG)	Virtual firewall at the resource/instance level; stateful; default-deny inbound; allow specific ports from specific sources; applied per EC2 instance, RDS database, or Lambda function	Principle of least privilege — specific source CIDRs or security group IDs, not 0.0.0.0/0; group resources by function (web tier, app tier, DB tier) with explicit inter-tier rules; review for 0.0.0.0/0 inbound rules quarterly
Network ACLs (AWS NACL / Azure NSG-Subnet)	Stateless subnet-level firewall; applied to all resources in subnet regardless of security group; provides defense-in-depth within the VPC; evaluated before security group rules	Use as additional defense layer for subnet boundaries; deny known malicious IP ranges; explicit block rules for services that should never be internet-accessible from that subnet
Private Endpoints / PrivateLink	Access cloud services (S3, RDS, Azure Storage) via private IP within VPC rather than over internet; traffic stays within cloud provider’s network; eliminates internet exposure for data-plane traffic	Mandatory for all PII/PHI/PCI data stores; eliminates public internet as attack path for storage bucket access; reduces egress costs in many scenarios; configure endpoint policies to restrict which resources can be accessed

Cloud Network Security — Misconfigurations to Detect

Misconfiguration	Risk	Detection & Remediation
Security group allowing 0.0.0.0/0 on SSH (22) or RDP (3389)	Direct internet access to remote management ports — the primary initial access vector for cloud breaches; brute force, credential stuffing, and zero-day exploits all directly applicable	CSPM tools (Wiz, Prisma Cloud, Defender for Cloud) flag this automatically; remediate by restricting to specific management IPs or VPN gateway IP; use Systems Manager Session Manager instead of SSH where possible
Publicly accessible storage bucket with sensitive data	PII, financial records, or configuration files accessible without authentication to anyone on the internet — no attacker sophistication required; just knowing the URL	AWS Config rule: s3-bucket-public-read-prohibited; CSPM continuous scanning; require Block Public Access settings on all buckets as organization-level policy; use bucket policies with explicit allow and audit with S3 Server Access Logs
No VPC Flow Logs enabled	No network-level forensic capability — if an incident occurs, impossible to reconstruct what network paths were used, what data was accessed, or how an attacker moved laterally	Enable VPC Flow Logs for ALL VPCs from the moment they are created (make it part of the IaC template); store in separate account or S3 with object lock; minimum 12-month retention
Overly broad CIDR range in security group (e.g., /8)	Even if not 0.0.0.0/0, a /8 rule allows 16 million IP addresses to reach the port — nearly as dangerous as open access if the CIDR includes untrusted networks	CSPM rules detecting rules more permissive than /24 on sensitive ports; quarterly security group review; replace broad CIDRs with specific source security group IDs for internal traffic
Default VPC in use with default security group	Default VPCs allow all inbound traffic from other resources in the same security group — default security group rules permit all inbound traffic from itself; default VPC has internet gateway attached	Delete or deprovision default VPC in all regions; prohibit use of default VPC for production resources; audit with AWS Config rule: vpc-default-security-group-closed

Cloud Network Security Architecture — Best Practices

Hub-and-Spoke VPC Architecture: Central ‘hub’ VPC containing shared services (inspection, logging, DNS, NAT); spoke VPCs for individual workloads connected via Transit Gateway or VPC peering; all internet-bound traffic routes through centralized inspection in hub
Centralized Egress Inspection: Route all outbound internet traffic through a centralized security inspection layer (NGFW, proxy, or AWS Network Firewall) — prevents individual workloads from directly accessing the internet; enables consistent policy enforcement and logging
East-West Inspection in Cloud: Use cloud-native firewall solutions (AWS Network Firewall, Azure Firewall, Palo Alto VM-Series) for inspection of traffic between VPCs and between subnets — applies the same defense-in-depth principles as on-premises microsegmentation
AWS GuardDuty / Azure Defender for Network: Enable cloud-native threat detection that analyzes VPC Flow Logs, DNS logs, and CloudTrail for network-level threats — detects C2 communication, cryptomining, port scanning, and data exfiltration patterns
Service Control Policies (SCPs): Organization-level guardrails preventing creation of overly permissive network configurations — SCPs can prevent creation of internet-facing security group rules, unencrypted public endpoints, and disabling of required logging services

Network Security Operations

Network security operations is the ongoing practice of maintaining, monitoring, and improving the security of the network. It bridges network engineering (building and operating the network) with cybersecurity (protecting it). Effective network security operations require defined processes, clear ownership, and integrated tooling.

Firewall Operations — Change Management

Firewall rule changes are one of the most common causes of security incidents and outages. Structured change management for network security devices prevents unauthorized changes, ensures business justification, and maintains rule base quality:

Change Request SubmissionSubmitter documents: source/destination/port/protocol; business justification; risk assessment; testing requirements; rollback plan. Submitted through ITSM ticketing system.
Security ReviewSecurity team reviews proposed rule for compliance with network security policy; identifies alternatives (can existing rules be extended? can access be achieved through application controls?); flags potentially high-risk rules for elevated approval.
ApprovalStandard changes approved by Network Security Lead; high-risk changes or those enabling internet access require CISO approval or CAB review. Temporary rules require explicit expiration date.
Staging / TestingFor major changes, test in lab environment or pre-production; validate that change achieves intended access without unintended permissiveness.
ImplementationChange implemented during approved maintenance window; implementation documented with before/after state in ticket; technician identity recorded; change correlation with firewall management system.
ValidationSubmitter confirms intended access now works; security team verifies no unintended access was created; firewall log spot-check for unexpected traffic via new rule.
Documentation UpdateRule documented in firewall management system with: owner, purpose, creation date, review date; associated change ticket number; risk classification.

Rule Review Cycle

Firewall rules must be reviewed on a scheduled basis — at minimum annually. Review identifies: rules with no traffic in 90+ days (candidate for removal); rules with expired owners (no longer with the organization); rules that granted temporary access that was never revoked; rules that are shadowed by broader rules (never reached); rules that conflict with current security policy. Use firewall analytics tools (AlgoSec, Tufin, FireMon) to automate rule analysis at scale.

Network Security Metrics & KPIs

Metric	Measurement	Target	Escalate If
Firewall rule review currency	% of rules reviewed within 12 months	100%	Any rules older than 18 months without review
Unauthorized firewall changes detected	Changes with no matching approved ticket	0 per quarter	Any unauthorized change in production
IPS false positive rate	% of IPS alerts that are false positives	< 15%	> 25% indicates tuning required urgently
DDoS incidents per quarter	Count of DDoS events requiring mitigation activation	Trend decreasing	Any DDoS event causing > 30 min availability impact
VPN authentication failure rate	% of VPN auth attempts that fail	< 2%	> 5% may indicate credential stuffing attack
Patch currency — network devices	% of network devices current on security patches	≥ 95% within 30 days of release	< 85% or any Critical CVE > 15 days unpatched
Log source health — network devices	% of network devices actively sending logs to SIEM	100%	Any device not logging for > 24 hours
External attack surface (internet-facing ports)	Count of internet-accessible services (quarterly scan)	Decreasing trend	Any unexpected new internet-facing service discovered

Network Incident Response

Network-specific incident response procedures handle threats that originate in or travel through the network. Key network IR actions:

Network-Level ContainmentBlock attacker’s source IP at perimeter firewall; isolate compromised VLAN or subnet; revoke dynamic routing; implement firewall deny rule for attacker’s known IP ranges
Traffic CaptureInitiate PCAP capture on affected segments immediately — volatile evidence; configure centralized capture at chokepoints covering attack traffic; confirm capture is occurring before taking any action that might route attacker traffic differently
Flow AnalysisPull NetFlow/IPFIX data for affected systems during incident window; identify all systems the compromised host communicated with (lateral movement scope); identify data volumes transferred (exfiltration scope)
DNS InvestigationPull DNS logs for compromised hosts; identify C2 domains contacted; block at DNS resolver and perimeter firewall; search for other hosts querying same C2 domains
Firewall Log AnalysisPull firewall logs for affected IP addresses; identify all permitted connections during compromise window; identify permitted connections to external destinations (exfiltration evidence)
VPN InvestigationIf attacker used VPN for initial access, identify all sessions from compromised credentials; determine geographic anomalies; revoke active sessions; identify all systems accessed during VPN session

Compliance Requirements for Network Security

Framework	Sector	Key Network Security Requirements	Audit Evidence Required
PCI DSS v4.0	Payment Card	Req 1: Network controls (firewalls, rules, reviews); Req 4: Encryption in transit; Req 10: Logging; Req 11: Vulnerability scanning and pen testing	Firewall rule base with documentation; network diagram showing CDE segmentation; ASV scan reports (quarterly); penetration test report; log retention evidence
HIPAA Security Rule	Healthcare	§164.312(e): Transmission security (encryption); §164.312(b): Audit controls (network logging); §164.308(a)(1): Risk assessment covering network threats	Network encryption evidence; audit log completeness; risk assessment covering network threat vectors; firewall configuration documentation
NIST SP 800-53 (FedRAMP)	Federal/Government	SC-7 (Boundary protection); SC-8 (Transmission integrity and confidentiality); SC-28 (Protection at rest); AU-3/AU-12 (Logging); SI-4 (Network monitoring)	Firewall policy documentation; encryption configuration evidence; network monitoring tool deployment evidence; log completeness verification
ISO 27001:2022	All sectors	A.8.20 (Networks security); A.8.21 (Security of network services); A.8.22 (Segregation of networks); A.8.23 (Web filtering); A.8.24 (Cryptography)	Network architecture documentation; firewall policies; segmentation evidence; web proxy configuration; encryption standards documentation; annual review evidence
CIS Controls v8	All sectors	CIS 12 (Network infrastructure management); CIS 13 (Network monitoring and defense); CIS 9 (Email and web browser protections); CIS 3 (Data protection)	CIS-CAT assessment results; network device inventory; flow monitoring evidence; DNS filtering configuration; email security headers (DMARC/SPF/DKIM)
NERC CIP (Energy)	Critical Infrastructure	CIP-005 (Electronic security perimeters); CIP-007 (Systems security management); CIP-010 (Configuration management — network devices)	ESP (Electronic Security Perimeter) documentation; network access point identification; access control rule documentation; patch management for network devices
NY DFS 23 NYCRR 500	Financial (NY)	§500.7 (Access privileges); §500.8 (Application security); §500.14 (Training); §500.16 (Incident response)	Network security policy; penetration test results; encryption evidence; vulnerability scan reports; network change management records

PCI DSS Network Segmentation Testing

PCI DSS Requirement 12.3.2 requires organizations to perform targeted risk analysis for each applicable requirement. For organizations relying on network segmentation to reduce PCI scope, Requirement 11.4.5 mandates penetration testing of segmentation controls at least every 12 months and after any changes that could affect segmentation. Auditors must verify both that segmentation exists AND that it is tested — documentation alone is insufficient.

Network Security Quick Reference

Topic	Key Point
OSI Layer Security	Layer 7: WAF, app proxies │ Layer 4: Firewall port rules │ Layer 3: Router ACLs, IPsec │ Layer 2: 802.1X, DAI, DHCP snooping │ Layer 1: Physical controls
Defense in Depth	Perimeter → Network → Endpoint → Identity → Application → Data — no single layer provides complete protection; failure of one must not result in complete compromise
DMZ Design	Dual-firewall (two-tier) architecture: outer firewall (Internet→DMZ), inner firewall (DMZ→Internal); different vendor on each firewall; internet-facing servers cannot initiate connections to internal network
Zero Trust	Never trust, always verify — no implicit trust based on network location; verify identity + device + context for every access request; micro-segmentation prevents lateral movement
802.1X / NAC	Port-based authentication before network access; supplicant (device) → authenticator (switch) → RADIUS server; dynamic VLAN assignment; prevents unauthorized devices
VPN Security Minimums	IKEv2 with AES-256, DH Group 14+; TLS 1.2+ for SSL VPN; MFA mandatory; certificate-based auth preferred; session timeout 15-30 min; ZTNA preferred over traditional VPN
Wireless Security	WPA2/3-Enterprise (802.1X) for corporate; WEP/WPA = forbidden; Management Frame Protection (PMF/MFP) prevents deauth attacks; separate SSIDs for corporate/IoT/guest; WIDS for rogue AP detection
DNS Security	DNSSEC for zone signing; DNS RPZ for threat intelligence blocking; monitor for tunneling (high-entropy subdomains); block direct external DNS from clients; force through corporate resolver; log all queries
ARP / DHCP Security	DHCP Snooping (trusted/untrusted ports) + Dynamic ARP Inspection (validates ARP vs. DHCP table) = Layer 2 MitM prevention; disable DTP on access ports to prevent VLAN hopping
Email Authentication	SPF (authorized senders in DNS) + DKIM (cryptographic signature) + DMARC (policy: none → quarantine → reject); goal: p=reject on all sending domains; BIMI requires DMARC enforcement
TLS Requirements	TLS 1.3 preferred; TLS 1.2 acceptable with strong cipher suites; TLS 1.0/1.1 disabled; SSL disabled; HSTS mandatory; certificate max 1 year; ECDHE cipher suites for forward secrecy
DDoS Mitigation Layers	BGP blackholing (fast, destroys availability) → upstream scrubbing (best protection) → anycast routing (distributes attack) → on-premises rate limiting → application resilience (CDN, load balancing)
Cloud Network Security	Default-deny security groups; private subnets for all data stores; VPC Flow Logs always on; no 0.0.0.0/0 on SSH/RDP; Private Endpoints for S3/RDS; centralized egress inspection; CSPM for continuous misconfiguration detection
Firewall Rule Principles	Default-deny last rule; least privilege (specific source/destination/port); business justification for each rule; time-limited temporary rules; annual rule review; no ‘Any/Any’ permit rules
Network Log Retention	Firewall: 12 months minimum; DNS: 12 months; DHCP: 12 months; VPN: 12 months; NetFlow: 90+ days detailed, longer aggregated; essential for incident investigation and compliance

Appendix A: Network Security Architecture Checklist

Use this checklist to verify network security controls are in place. Document completion dates and responsible parties.

✓	Requirement	Owner
Perimeter Security
☐	Next-generation firewall deployed at internet perimeter with application inspection, IPS, and URL filtering	Network Team
☐	Default-deny (implicit deny all) rule at end of all firewall policies	Network Security
☐	WAF deployed in front of all internet-facing web applications	Security Architecture
☐	DDoS mitigation service contracted and configured for all internet-facing services	Network/Security
☐	Firewall rule base reviewed within last 12 months; all rules documented with owner and justification	Network Security
Network Segmentation
☐	DMZ implemented using dual-firewall architecture; internet-facing servers cannot initiate connections to internal network	Network Team
☐	Server zone, workstation zone, and management zone are separate VLANs with inter-zone firewall policy	Network Team
☐	OT/ICS networks physically or logically isolated from corporate IT network	OT/IT Team
☐	Guest/BYOD VLAN restricted to internet access only; no routing to internal resources	Network Team
Identity & Access
☐	802.1X network access control deployed on all wired switch ports for workstations and servers	Network Team
☐	All remote access (VPN/ZTNA) requires multi-factor authentication	Security/IAM
☐	VPN using IKEv2 with AES-256 and DH Group 14 minimum; TLS 1.2+ for SSL VPN	Network Team
Wireless Security
☐	Corporate SSID uses WPA2/3-Enterprise (802.1X) — no WPA-PSK on corporate network	Network Team
☐	WEP and WPA-TKIP disabled on all access points	Network Team
☐	Management Frame Protection (802.11w) enabled on all corporate SSIDs	Network Team
☐	WIDS deployed and integrated with SIEM for rogue AP detection	Network/Security
Monitoring & Logging
☐	All network devices (firewalls, routers, switches) sending syslog to centralized SIEM	Network/Security
☐	NetFlow/IPFIX enabled on all core switches and routers; collected in flow analyzer	Network Team
☐	DNS query logging enabled; all queries forwarded to SIEM for analysis	Network/Security
☐	VPC Flow Logs enabled for all cloud VPCs (minimum 12-month retention)	Cloud/Security
Encryption & Protocol Security
☐	TLS 1.0 and 1.1 disabled on all internet-facing and internal services	Security Architecture
☐	DNSSEC configured for all authoritative DNS zones; DNS RPZ deployed on resolvers	Network/Security
☐	DMARC p=reject policy deployed for all organizational email domains	Security/Email
☐	DHCP Snooping and Dynamic ARP Inspection configured on all access switches	Network Team

Appendix B: Common Ports and Protocols Security Reference

Port	Protocol	Security Status	Notes
21	FTP	INSECURE	Cleartext credentials and data; replace with SFTP (port 22) or FTPS (port 990)
23	Telnet	FORBIDDEN	Cleartext credentials; must be disabled on all network devices; use SSH
22	SSH	SECURE	Acceptable for secure remote management; disable password auth; use key-based; version 2 only
25	SMTP (cleartext)	INSECURE	Use STARTTLS (port 25) or SMTPS (port 465); enforce SMTP TLS; MTA-STS
53	DNS	MONITOR	Log all queries; deploy DNS firewall (RPZ); DNSSEC; block direct external DNS from clients
80	HTTP	UNENCRYPTED	Redirect all HTTP to HTTPS (301); HSTS preloading; no sensitive data over HTTP
443	HTTPS/TLS	SECURE	TLS 1.2+ minimum; TLS 1.3 preferred; strong cipher suites; HSTS; certificate monitoring
161	SNMP v1/v2	INSECURE	SNMPv1/v2 community strings sent in cleartext; use SNMPv3 with auth+priv; ACL restrict queries
162	SNMP Trap v3	SECURE	SNMPv3 traps with authentication and encryption; restrict to management network
389	LDAP	INSECURE	Cleartext directory service; use LDAPS (port 636) or StartTLS; firewall to directory servers
636	LDAPS	SECURE	LDAP over TLS; required for AD authentication with encryption; validate server certificate
3389	RDP	RESTRICT	Never expose to internet; require NLA (Network Level Authentication); MFA; VPN/ZTNA access only
445	SMB	RESTRICT	Never expose to internet; SMBv1 must be disabled; restrict internal to specific authorized hosts
1433	MSSQL	RESTRICT	Firewall to application servers only; never internet-facing; TLS required; strong auth
3306	MySQL	RESTRICT	Firewall to application servers only; never internet-facing; require TLS; strong passwords
5432	PostgreSQL	RESTRICT	Application server access only; pg_hba.conf for source restriction; SSL required
6379	Redis	RESTRICT	Never internet-facing; auth token required; bind to specific interface; TLS if sensitive data
8080/8443	HTTP Alt/HTTPS Alt	MANAGE	Non-standard ports for web services; document legitimate use; same security requirements as 80/443

Appendix C: Recommended Resources

NIST SP 800-41 Rev 1 — Guidelines on Firewalls and Firewall Policy — nist.gov
NIST SP 800-77 Rev 1 — Guide to IPsec VPNs — nist.gov
NIST SP 800-97 — Establishing Wireless Robust Security Networks (802.11 guide)
CIS Benchmarks for Network Devices (Cisco IOS, Palo Alto, Juniper) — cisecurity.org
OWASP DNS Security Cheat Sheet — owasp.org/www-project-cheat-sheets
Cloudflare DDoS Threat Report — blog.cloudflare.com/ddos-threat-report
NSA/CISA Network Infrastructure Security Guide — media.defense.gov
MITRE ATT&CK — Network-based Tactics — attack.mitre.org (Enterprise matrix, Network lateral movement)
testssl.sh — free TLS configuration testing tool — testssl.sh (GitHub)
Shodan — attack surface monitoring for internet-exposed services — shodan.io
DNSViz — DNSSEC visualization and validation tool — dnsviz.net