Network Security / Foundations
Network Security Foundations & Policy Enforcement
Network security controls decide which communications may cross a boundary and produce evidence about what actually happened. Addresses, routes, VLANs, and subnets provide reachability and grouping; protection exists only where an enforcement point applies an explicit policy and cannot be bypassed.
Restore the operating model
A network flow has a source, destination, protocol, direction, path, and business purpose. A useful policy names all six and identifies the application or service owner accountable for the exception.
- Data plane: Carries application packets and applies forwarding or filtering decisions.
- Control plane: Learns or distributes routing, switching, and policy state. Compromise here can redirect or disable many data-plane paths.
- Management plane: Configures devices and retrieves telemetry. It should use dedicated identities, restricted paths, and auditable change control.
- Policy decision point: Evaluates identity, device, resource, and contextual signals to decide whether access should be allowed.
- Policy enforcement point: Applies the decision at a firewall, host, proxy, gateway, virtual switch, service-mesh proxy, or application boundary.
Traffic direction is relative to the protected resource: ingress enters it, egress leaves it, east-west moves among internal workloads, and north-south crosses an external or major zone boundary. These labels describe direction, not trustworthiness.
Choose an enforcement point for the property required
| Control | Decision context | Useful for | Important boundary |
|---|---|---|---|
| Stateless ACL | Packet header fields independently | Simple anti-spoofing and coarse protocol/address filters | Does not remember connection state or understand application identity. |
| Stateful firewall | Header fields plus connection-tracking state | Allowing established return traffic and blocking unsolicited new flows | State tables can be exhausted; asymmetric routing can prevent both directions from reaching the same stateful device. |
| Application proxy / gateway | Terminated application session and protocol fields | User or workload identity, method/path policy, content controls | Protects only traffic that is captured and parsed; protocol ambiguity, direct paths, and unsupported encryption can bypass its view. |
| Web application firewall (WAF) | HTTP request and response context | Filtering selected web attack patterns and enforcing HTTP constraints | It is not a replacement for application authorization, input validation, or secure code. |
| Host firewall | Local process, interface, address, and port context | Last-hop control when the surrounding network is shared | A privileged host compromise can alter local policy; centralized evidence is still needed. |
| Identity-aware access proxy | Authenticated subject/device plus resource policy | Per-application administrative or workforce access | The proxy must cover every route, and authorization may be session-based rather than re-evaluated on every packet or request. |
Network Address Translation (NAT), a route table, a VLAN, a subnet, or a private address is not by itself an access-control decision. Each can reduce accidental exposure or shape a path, but an allow/deny policy must still be enforced at a defined boundary.
Build policy from intended communication
This journal working model keeps the rule lifecycle explicit:
- Inventory the source identity or asset, destination resource, protocol, port, direction, environment, and owner.
- Start from deny for new, unclassified communication; add the narrowest allow rule that supports a documented dependency.
- Apply policy at every viable path, including IPv4 and IPv6, alternate interfaces, overlay networks, load balancers, peering, and direct service endpoints.
- Log the decision with enough source, destination, rule, time, and action context to investigate it.
- Test both the allowed flow and representative denied flows from the actual source and path.
- Review usage, ownership, expiration, shadowed rules, and emergency exceptions; remove rules whose dependency has ended.
Default deny is a starting state, not proof of least privilege. Broad identity groups, 0.0.0.0/0, ::/0, all-port rules, inherited policy, and higher-priority exceptions can still make an apparently restrictive policy ineffective.
Account for dependencies and failure modes
- Permit required infrastructure deliberately: Domain Name System (DNS), time synchronization, certificate status or enrollment, identity providers, software repositories, and observability endpoints often sit outside the application zone.
- Preserve necessary Internet Control Message Protocol (ICMP/ICMPv6) behavior for error reporting, path MTU discovery, and IPv6 neighbor discovery; “block all ICMP” can break connectivity and diagnostics.
- Define fail-open or fail-closed behavior for unavailable policy controllers, proxies, threat feeds, and inspection engines. Neither choice is universally correct: availability and exposure consequences differ.
- Treat Transport Layer Security (TLS) inspection as a new trust boundary. It requires certificate deployment, key protection, privacy and legal review, protocol compatibility, and a plan for traffic that cannot or should not be decrypted.
- Protect the management and control planes separately from user traffic. A firewall cannot defend a policy that an attacker can reconfigure.
- Keep an out-of-band recovery path for policy errors without turning the break-glass path into a permanent bypass.
Validate the effective policy, not only its configuration
Configuration review proves what a control is intended to do. Flow logs show selected observed decisions. Active connection tests show behavior for the tested source, destination, protocol, time, and route. None alone proves that every alternate path is covered.
A change is ready when:
- The rule diff and owner approval match the intended dependency.
- Reachability tests pass for permitted traffic and fail for prohibited traffic from each relevant zone and address family.
- The expected enforcement-point log identifies the rule and action.
- Route and topology checks show that no uninspected path bypasses the control.
- Rollback restores the prior policy and does not strand the management plane.
Use DNS Security for name-resolution controls, Network Segmentation & Microsegmentation for zone design, and Network Telemetry, IDS/IPS & Validation for detection and test evidence.
Topology creates paths; an enforcement point creates a security decision. Define the intended flow, cover every viable path and address family, log the effective rule, test both allow and deny behavior, and retire the exception with its dependency.
Primary references
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy — verified firewall roles, policy, deployment, testing, and lifecycle considerations.
- NIST SP 800-207: Zero Trust Architecture — verified policy decision/enforcement concepts and the boundary between network location and resource access decisions.
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment — verified the distinction among examination, testing, findings, and evidence limitations.