Documentation Index
Fetch the complete documentation index at: https://threatbasis.io/llms.txt
Use this file to discover all available pages before exploring further.
Network security has evolved from perimeter-focused defense to identity-centric and application-aware controls that assume breach and minimize blast radius. Security engineers architect default-deny, micro-segmented, observable networks where every connection is authenticated, authorized, and logged. Modern network security treats the network as untrusted infrastructure requiring continuous verification rather than a trusted zone protected by perimeter defenses.
Cloud-native architectures and remote work have eliminated traditional network perimeters, requiring network security to adapt through Zero Trust principles, service mesh architectures, and identity-based access controls. According to Verizon’s Data Breach Investigations Report, network-based attacks remain a primary vector for data breaches, making robust network security essential for organizational resilience.
Core Network Security Principles
The following table summarizes the foundational principles that guide modern network security architecture:
| Principle | Description | Key Controls | Outcome |
|---|
| Default Deny | Block all traffic unless explicitly permitted | Allowlists, network policies, security groups | Prevents unauthorized access |
| Least Privilege | Limit connectivity to minimum required | Micro-segmentation, NetworkPolicies | Contains breach blast radius |
| Authenticated Edges | Cryptographically verify all connections | mTLS, SPIFFE/SPIRE, certificate management | Prevents impersonation attacks |
| Network Observability | Log and monitor all network activity | Flow logs, DNS logs, SIEM integration | Enables threat detection |
| Network Resilience | Protect against overload and DoS | Rate limiting, circuit breakers, CDNs | Maintains availability |
Default Deny
Network policies should deny all traffic by default, with explicit allowlists for required connections. Default deny applies to both inbound and outbound traffic, preventing unauthorized ingress and data exfiltration through egress control.
Allowlists should be scoped per service and per tenant, specifying exactly which sources can connect to which destinations on which ports. Overly broad allowlists that permit entire subnets or IP ranges reduce security to checkbox compliance without meaningful protection.
Default deny requires comprehensive understanding of application communication patterns, making network flow mapping essential during architecture design and migration planning.
Least Privilege Connectivity
Micro-segmentation divides networks into small zones with independent access controls, limiting lateral movement from compromised systems. Cloud platforms provide micro-segmentation through VPCs/VNETs, subnets, AWS Security Groups, and network ACLs.
Kubernetes NetworkPolicies provide pod-level network segmentation, restricting which pods can communicate. Service mesh architectures like Istio and Linkerd enforce authorization policies at Layer 7, enabling fine-grained access control based on service identity and request attributes.
# Example Kubernetes NetworkPolicy: Default deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
Authenticated Network Edges
TLS encryption should be universal for data in transit, protecting confidentiality and integrity. Mutual TLS (mTLS) for service-to-service communication provides cryptographic authentication, eliminating reliance on network location for trust.
SPIFFE/SPIRE provides workload identity for mTLS, with automatic certificate rotation and cryptographic service identity. Service mesh platforms including Istio and Linkerd provide mTLS by default with transparent encryption.
| Authentication Method | Use Case | Key Benefit | Implementation |
|---|
| TLS 1.3 | Client-server encryption | Confidentiality and integrity | Load balancers, reverse proxies |
| mTLS | Service-to-service | Mutual authentication | Service mesh, SPIFFE/SPIRE |
| Certificate pinning | High-security clients | Prevents CA compromise | Mobile apps, critical services |
| DANE/TLSA | DNS-based cert validation | Reduces CA dependency | DNS infrastructure |
Network Observability
Comprehensive network logging including flow logs, DNS logs, HTTP logs, and TLS metadata enables threat detection and forensic investigation. Logs should include source and destination identities, not just IP addresses, enabling identity-based analysis.
Tamper-evident log storage prevents attackers from covering tracks by modifying logs. Centralized log aggregation with long retention enables historical analysis and threat hunting using tools like Splunk, Elastic Security, or Sumo Logic.
Network observability provides visibility into attack patterns, data exfiltration, and lateral movement that may evade endpoint detection.
Network Resilience
Rate limiting, backpressure, and circuit breakers protect services from overload and denial-of-service attacks. Token bucket algorithms provide fair rate limiting while allowing burst traffic.
DoS-resistant front doors including CDNs (Cloudflare, AWS CloudFront, Akamai), load balancers, and API gateways absorb attack traffic before it reaches application infrastructure. Graceful degradation with feature flags maintains core functionality during attacks.
Protocol-Specific Security
The following table summarizes security considerations for common network protocols:
| Protocol | Primary Threats | Key Mitigations | Standards/References |
|---|
| IPv4/IPv6 | Spoofing, RA flooding, NDP attacks | RFC 1918 filtering, RA Guard, NDP protection | RFC 7039 |
| DNS | Spoofing, cache poisoning, tunneling | DNSSEC, DNS filtering, query logging | RFC 4033 |
| BGP | Route hijacking, prefix leaks | RPKI, max-prefix limits, route filtering | RFC 7454 |
| Email | Spoofing, phishing, malware | SPF, DKIM, DMARC, content filtering | RFC 7489 |
| TLS | Downgrade attacks, weak ciphers | TLS 1.3, certificate transparency | RFC 8446 |
IPv4 and IPv6 Security
RFC 1918 private address space should be filtered at network edges, preventing external routing of private addresses. IPv6 introduces new attack surfaces including Router Advertisement flooding and Neighbor Discovery Protocol attacks.
RA Guard and NDP protections prevent rogue router advertisements and neighbor discovery spoofing. SLAAC (Stateless Address Autoconfiguration) can create unexpected address assignments, requiring careful configuration or disablement in favor of DHCPv6.
DNS Security
DNSSEC provides cryptographic integrity for DNS responses, preventing DNS spoofing and cache poisoning. While DNSSEC deployment remains limited, it should be used where feasible for critical domains.
Egress control on DNS prevents DNS tunneling for data exfiltration and command-and-control. Dedicated DNS resolvers with logging enable detection of malicious domains and data exfiltration attempts.
DNS filtering using services like Quad9, Cloudflare Gateway, or Cisco Umbrella blocks known malicious domains, phishing sites, and data exfiltration destinations. DNS query logging provides valuable threat intelligence and incident investigation data.
Routing Security
BGP security through RPKI (Resource Public Key Infrastructure) validates route announcements, preventing route hijacking. Max-prefix limits prevent route table overflow attacks.
Provider-managed peering with guardrails reduces exposure to routing attacks while maintaining connectivity. Organizations should avoid operating their own BGP unless they have expertise and monitoring capabilities. The MANRS initiative provides routing security best practices.
Email Security
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) provide email authentication and anti-spoofing protection.
Email should be treated as untrusted ingress requiring content filtering, attachment scanning, and link protection. Email remains a primary attack vector for phishing and malware delivery according to CISA guidance.
Network Security Controls
The following table compares network security control types and their capabilities:
| Control Type | OSI Layer | Detection Method | Deployment Mode | Example Tools |
|---|
| Packet Filter Firewall | L3-L4 | Stateless rules | Inline | iptables, nftables |
| Stateful Firewall | L3-L4 | Connection tracking | Inline | pfSense, Palo Alto |
| WAF | L7 | HTTP inspection | Inline/Reverse proxy | ModSecurity, AWS WAF |
| IDS | L3-L7 | Signature/Anomaly | Passive/TAP | Suricata, Zeek |
| IPS | L3-L7 | Signature/Anomaly | Inline | Snort, Suricata |
| NDR | L3-L7 | ML/Behavioral | Passive | Darktrace, Vectra |
Firewalls and Web Application Firewalls
Layer 3/4 firewalls provide network-level access control based on IP addresses, ports, and protocols. Layer 7 Web Application Firewalls (WAFs) inspect HTTP traffic for application-layer attacks including SQL injection and cross-site scripting.
Infrastructure-as-code for firewall policies using tools like Terraform or Pulumi enables version control, testing, and automated deployment. Shadow rules in audit mode enable safe policy testing before enforcement.
# Example Terraform: AWS Security Group with explicit rules
resource "aws_security_group" "web_tier" {
name = "web-tier-sg"
description = "Security group for web tier"
vpc_id = aws_vpc.main.id
ingress {
description = "HTTPS from load balancer"
from_port = 443
to_port = 443
protocol = "tcp"
security_groups = [aws_security_group.alb.id]
}
egress {
description = "Database access only"
from_port = 5432
to_port = 5432
protocol = "tcp"
security_groups = [aws_security_group.database.id]
}
}
Intrusion Detection and Prevention
Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) analyze network traffic for attack patterns using signature-based and anomaly-based detection. Network Detection and Response (NDR) platforms provide advanced threat detection with machine learning.
Suricata and Zeek provide open-source network security monitoring with deep packet inspection. Signature-based detection identifies known attacks from sources like Emerging Threats, while anomaly detection identifies unusual traffic patterns.
Tuning reduces false positives that create alert fatigue, with continuous refinement based on environment-specific traffic patterns. The MITRE ATT&CK framework provides a taxonomy for mapping detected behaviors to known attack techniques.
DDoS Protection
Distributed Denial of Service (DDoS) protection requires multiple layers including provider-level scrubbing, anycast routing, rate limiting, and application-level controls.
| DDoS Attack Type | Layer | Mitigation Strategy | Protection Service |
|---|
| Volumetric (UDP flood) | L3-L4 | Scrubbing, blackholing | AWS Shield, Cloudflare |
| Protocol (SYN flood) | L4 | SYN cookies, rate limiting | Load balancers, firewalls |
| Application (HTTP flood) | L7 | WAF, bot detection, CAPTCHA | Akamai, Imperva |
| Amplification (DNS, NTP) | L3-L4 | BCP38, response rate limiting | ISP filtering |
Egress Control
Egress proxies with authentication restrict outbound connections to known services, preventing data exfiltration and command-and-control communication. Proxy authentication ensures that only authorized users and services can make outbound connections.
TLS inspection enables deep packet inspection of encrypted traffic but raises privacy concerns requiring strong governance. TLS inspection should be limited to corporate devices with clear user notification and privacy review per NIST guidelines.
Egress filtering blocks connections to known malicious infrastructure, data exfiltration services, and unauthorized cloud platforms. Tools like Zscaler and Netskope provide cloud-based egress security.
Network Segmentation Patterns
Effective network segmentation limits blast radius and prevents lateral movement. The following table summarizes common segmentation patterns:
| Pattern | Implementation | Use Case | Isolation Level |
|---|
| Environment Isolation | Separate accounts/projects | Dev/staging/prod separation | Strong |
| Tenant Isolation | Separate VPCs/VNETs | Multi-tenant SaaS | Strong |
| Control Plane Isolation | Dedicated management network | Security infrastructure | Critical |
| Workload Segmentation | NetworkPolicies, security groups | Microservices | Granular |
| Data Tier Isolation | Private subnets, no internet | Database protection | Strong |
Environment Isolation
Production, staging, and development environments should use separate cloud accounts or projects with independent networking. Environment isolation prevents development environment compromises from affecting production.
Separate credentials per environment ensure that development credentials cannot access production resources. Network-level isolation provides defense-in-depth beyond access control. AWS Organizations and Azure Management Groups enable multi-account strategies.
Tenant Isolation
Multi-tenant systems require isolation at both data and network layers. Shared backends without policy enforcement create cross-tenant data leakage risks.
Network-level tenant isolation through separate VPCs or VNETs provides strong isolation boundaries. Application-level tenant isolation through authorization policies provides fine-grained control. See AWS multi-tenancy best practices for implementation guidance.
Control Plane Isolation
Security tooling and identity infrastructure should reside in separate, locked-down network segments. Control plane isolation prevents attackers from disabling security controls or compromising identity systems.
Dedicated management networks for infrastructure administration prevent production network compromises from affecting management capabilities. Bastion hosts or AWS Systems Manager Session Manager provide secure administrative access without exposing management interfaces.
Network Monitoring and Forensics
Comprehensive network monitoring enables threat detection, incident response, and forensic investigation. The following table outlines key data sources:
| Data Source | Information Captured | Retention Recommendation | Primary Use Case |
|---|
| VPC Flow Logs | Source, destination, ports, bytes | 90 days minimum | Traffic analysis, anomaly detection |
| DNS Query Logs | Domain lookups, client IPs | 90 days minimum | Threat intelligence, exfiltration detection |
| HTTP/Proxy Logs | URLs, headers, response codes | 30-90 days | Application security, forensics |
| Packet Capture | Full packet content | On-demand only | Deep forensic investigation |
| TLS Metadata | Certificate info, cipher suites | 30 days | Encryption compliance, threat detection |
Flow and Connection Logging
VPC Flow Logs, NetFlow, and IPFIX provide network flow data including source, destination, ports, and byte counts. Flow logs enable traffic pattern analysis, anomaly detection, and forensic investigation.
DNS query logs capture all DNS requests, providing visibility into domain access patterns and potential data exfiltration. HTTP reverse proxy logs capture application-layer request details.
Log retention should balance storage costs with forensic and compliance requirements, typically ranging from 30 days to one year per NIST SP 800-92 guidance.
Packet Capture
Full packet capture provides comprehensive network forensics but creates storage and privacy challenges. On-demand packet capture via network taps or port mirrors enables targeted capture during investigations.
Blanket full packet capture in production should be avoided due to storage costs and privacy implications. Packet capture should be triggered by playbooks during security incidents. Tools like Wireshark, tcpdump, and cloud-native solutions like AWS Traffic Mirroring enable targeted capture.
Time Synchronization
Accurate time synchronization through NTP or PTP enables correlation of events across distributed systems. Clock discipline ensures that timestamps are reliable for forensic analysis and compliance.
Time synchronization should be monitored, with alerts on clock drift that could indicate attacks or infrastructure issues. Cloud providers offer managed time services like Amazon Time Sync Service and Google Public NTP.
Common Network Security Pitfalls
The following table summarizes common network security mistakes and their mitigations:
| Pitfall | Risk | Mitigation | Detection Method |
|---|
| Flat Networks | Unlimited lateral movement | Micro-segmentation, NetworkPolicies | Network flow analysis |
| Permissive Egress | Data exfiltration, C2 | Egress proxies, allowlists | Egress monitoring |
| Unmonitored Third-Party | Supply chain attacks | Dedicated segments, monitoring | Connection logging |
| Implicit East-West Trust | Lateral movement | mTLS, service mesh policies | Traffic inspection |
| Shared Jump Boxes | Credential compromise | Individual access, PAM | Session logging |
| Unmanaged Devices | Persistent vulnerabilities | Asset inventory, patching | Vulnerability scanning |
Flat Networks
Flat networks without segmentation provide unlimited lateral movement for attackers. Micro-segmentation should be implemented even in cloud environments where traditional VLANs don’t exist. The MITRE ATT&CK Lateral Movement techniques demonstrate why segmentation is critical.
Permissive Egress
Allowing all outbound traffic enables data exfiltration and command-and-control communication. Egress should be restricted to known services with monitoring and alerting. Implement egress controls following CISA’s network segmentation guidance.
Unmonitored Third-Party Connectivity
Third-party connections including vendor access, partner integrations, and supply chain connections create attack vectors. Third-party connectivity should be monitored with same rigor as user access per NIST SP 800-161 supply chain risk management guidance.
Implicit East-West Trust
Trusting all traffic within the network perimeter enables lateral movement. East-west traffic between services should be authenticated and authorized using Zero Trust principles.
Shared Jump Boxes
Shared jump boxes with long-lived credentials create single points of compromise. Privileged access should use individual credentials with comprehensive logging through Privileged Access Management (PAM) solutions.
Unmanaged Network Devices
Network devices with default credentials or outdated firmware create persistent vulnerabilities. All network devices should be inventoried, hardened, and patched following CIS Benchmarks for network devices.
Network Security Metrics
Measuring network security effectiveness requires tracking key performance indicators:
| Metric | Description | Target | Alert Threshold |
|---|
| Mean Time to Detect (MTTD) | Time from intrusion to detection | < 24 hours | > 72 hours |
| Mean Time to Respond (MTTR) | Time from detection to containment | < 4 hours | > 24 hours |
| Segmentation Coverage | % of workloads with network policies | > 95% | < 80% |
| Egress Policy Coverage | % of egress traffic through proxies | > 90% | < 70% |
| mTLS Adoption | % of service-to-service traffic encrypted | > 99% | < 95% |
| Vulnerability Remediation | Network device patches within SLA | > 95% | < 80% |
Conclusion
Network security fundamentals require defense-in-depth with default deny policies, micro-segmentation, authenticated connections, and comprehensive observability. Security engineers design networks that assume breach and minimize blast radius through least privilege connectivity and continuous monitoring.
Key success factors:
- Default deny policies with explicit allowlists for all network traffic
- Micro-segmentation limiting lateral movement between workloads
- mTLS and authenticated connections for all service-to-service communication
- Comprehensive logging and monitoring for threat detection
- Egress controls preventing data exfiltration and C2 communication
- Regular assessment against security metrics and continuous improvement
Success requires treating network security as foundational architecture rather than perimeter controls, with security integrated into network design from the beginning. Organizations that invest in network security fundamentals build resilient infrastructures that resist network-based attacks while providing visibility for threat detection and response.
References
