> ## 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 Fundamentals

> Master network security with defense-in-depth strategies including micro-segmentation, Zero Trust architecture, firewalls, IDS/IPS, and encryption protocols for resilient enterprise networks.

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](https://www.nist.gov/publications/zero-trust-architecture), service mesh architectures, and identity-based access controls. According to [Verizon's Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/), 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](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html), and network ACLs.

[Kubernetes NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) provide pod-level network segmentation, restricting which pods can communicate. Service mesh architectures like [Istio](https://istio.io/latest/docs/concepts/security/) and [Linkerd](https://linkerd.io/2.14/features/server-policy/) enforce authorization policies at Layer 7, enabling fine-grained access control based on service identity and request attributes.

```yaml theme={null}
# 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
```

Least privilege connectivity ensures that compromised systems can only access resources they legitimately need, containing breach impact.

### 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](https://spiffe.io/) 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              |

Authenticated edges prevent network-based attacks including man-in-the-middle, eavesdropping, and session hijacking.

### 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](https://www.splunk.com/), [Elastic Security](https://www.elastic.co/security), or [Sumo Logic](https://www.sumologic.com/).

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](https://www.cloudflare.com/ddos/), [AWS CloudFront](https://aws.amazon.com/cloudfront/), [Akamai](https://www.akamai.com/)), 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](https://datatracker.ietf.org/doc/html/rfc7039) |
| DNS       | Spoofing, cache poisoning, tunneling | DNSSEC, DNS filtering, query logging         | [RFC 4033](https://datatracker.ietf.org/doc/html/rfc4033) |
| BGP       | Route hijacking, prefix leaks        | RPKI, max-prefix limits, route filtering     | [RFC 7454](https://datatracker.ietf.org/doc/html/rfc7454) |
| Email     | Spoofing, phishing, malware          | SPF, DKIM, DMARC, content filtering          | [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) |
| TLS       | Downgrade attacks, weak ciphers      | TLS 1.3, certificate transparency            | [RFC 8446](https://datatracker.ietf.org/doc/html/rfc8446) |

### IPv4 and IPv6 Security

[RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) 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](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en) 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](https://attack.mitre.org/techniques/T1071/004/) 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](https://www.quad9.net/), [Cloudflare Gateway](https://www.cloudflare.com/products/zero-trust/gateway/), or [Cisco Umbrella](https://umbrella.cisco.com/) 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)](https://www.arin.net/resources/manage/rpki/) 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](https://www.manrs.org/) provides routing security best practices.

### Email Security

[SPF](https://datatracker.ietf.org/doc/html/rfc7208) (Sender Policy Framework), [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) (DomainKeys Identified Mail), and [DMARC](https://dmarc.org/) (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](https://www.cisa.gov/topics/cybersecurity-best-practices/email-security).

## 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](https://www.pfsense.org/), [Palo Alto](https://www.paloaltonetworks.com/) |
| WAF                    | L7        | HTTP inspection     | Inline/Reverse proxy | [ModSecurity](https://modsecurity.org/), [AWS WAF](https://aws.amazon.com/waf/)     |
| IDS                    | L3-L7     | Signature/Anomaly   | Passive/TAP          | [Suricata](https://suricata.io/), [Zeek](https://zeek.org/)                         |
| IPS                    | L3-L7     | Signature/Anomaly   | Inline               | [Snort](https://www.snort.org/), Suricata                                           |
| NDR                    | L3-L7     | ML/Behavioral       | Passive              | [Darktrace](https://darktrace.com/), [Vectra](https://www.vectra.ai/)               |

### 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](https://owasp.org/www-community/attacks/SQL_Injection) and [cross-site scripting](https://owasp.org/www-community/attacks/xss/).

Infrastructure-as-code for firewall policies using tools like [Terraform](https://www.terraform.io/) or [Pulumi](https://www.pulumi.com/) enables version control, testing, and automated deployment. Shadow rules in audit mode enable safe policy testing before enforcement.

```hcl theme={null}
# 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]
  }
}
```

Cloud-native firewalls integrate with cloud platforms, providing dynamic rule updates based on resource tags and auto-scaling groups.

### 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](https://suricata.io/) and [Zeek](https://zeek.org/) provide open-source network security monitoring with deep packet inspection. Signature-based detection identifies known attacks from sources like [Emerging Threats](https://rules.emergingthreats.net/), 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](https://attack.mitre.org/) 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](https://aws.amazon.com/shield/), [Cloudflare](https://www.cloudflare.com/ddos/) |
| Protocol (SYN flood)     | L4    | SYN cookies, rate limiting    | Load balancers, firewalls                                                                    |
| Application (HTTP flood) | L7    | WAF, bot detection, CAPTCHA   | [Akamai](https://www.akamai.com/), [Imperva](https://www.imperva.com/)                       |
| Amplification (DNS, NTP) | L3-L4 | BCP38, response rate limiting | ISP filtering                                                                                |

Provider scrubbing services absorb large-scale volumetric attacks before they reach organizational infrastructure. Anycast routing distributes traffic across multiple locations, making attacks harder to execute.

Application-level rate limiting and token buckets prevent application-layer DDoS attacks that bypass network-level protections. Feature flags enable graceful degradation during attacks.

### 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](https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final).

Egress filtering blocks connections to known malicious infrastructure, data exfiltration services, and unauthorized cloud platforms. Tools like [Zscaler](https://www.zscaler.com/) and [Netskope](https://www.netskope.com/) 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](https://aws.amazon.com/organizations/) and [Azure Management Groups](https://learn.microsoft.com/en-us/azure/governance/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](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/multi-tenancy.html) 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](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html) or [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 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](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), [NetFlow](https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html), 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](https://csrc.nist.gov/publications/detail/sp/800-92/final) 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](https://www.wireshark.org/), [tcpdump](https://www.tcpdump.org/), and cloud-native solutions like [AWS Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) enable targeted capture.

### Time Synchronization

Accurate time synchronization through [NTP](https://www.ntp.org/) or [PTP](https://www.nist.gov/pml/time-and-frequency-division/time-realization/precision-time-protocol-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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) and [Google Public NTP](https://developers.google.com/time).

## 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](https://attack.mitre.org/tactics/TA0008/) 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](https://www.cisa.gov/news-events/news/network-segmentation).

### 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](https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final) 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](https://www.nist.gov/publications/zero-trust-architecture).

### 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)](https://www.gartner.com/en/information-technology/glossary/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](https://www.cisecurity.org/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

* [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/publications/detail/sp/800-207/final) - Foundational Zero Trust guidance
* [NIST SP 800-125B: Secure Virtual Network Configuration](https://csrc.nist.gov/publications/detail/sp/800-125b/final) - Cloud network security
* [NIST SP 800-41 Rev 1: Guidelines on Firewalls and Firewall Policy](https://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final) - Firewall configuration guidance
* [NIST SP 800-94: Guide to Intrusion Detection and Prevention Systems](https://csrc.nist.gov/publications/detail/sp/800-94/final) - IDS/IPS implementation
* [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks) - Hardening guides for network devices and cloud platforms
* [MITRE ATT\&CK Network-Based Techniques](https://attack.mitre.org/techniques/enterprise/) - Attack technique reference
* [OWASP Network Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) - Practical segmentation guidance
* [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - Container network security
* [AWS VPC Security Best Practices](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) - Cloud network security
* [Azure Network Security Best Practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/network-best-practices) - Cloud network security