Information Flow Enforcement AC-4

Source: NIST SP 800-53 Rev.5, Access Control family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

AC-4 (Information Flow Enforcement) is about controlling where information is allowed to move — within the system and between it and connected systems — and enforcing those rules on purpose. Where AC-2 and AC-3 ask ‘who can log in and what can they touch,’ AC-4 asks ‘which traffic is allowed to flow, in which direction, to and from where.’ On a Linux lab server this is mostly a host-firewall job: you write down the approved flows and then make the box enforce exactly that. It is an Access Control that lives in the Moderate baseline (it is not selected at Low).

What good looks like

• Write down the approved flows first — which ports, protocols, and directions are allowed, and to or from which hosts or subnets — then enforce exactly that list.
• Default-deny. Block everything, then open only the flows you approved. This applies to inbound traffic and outbound.
• Control egress (outbound traffic leaving the server), not just inbound — a server that can reach anything on the internet is an easy data-exfiltration path.
• Separate traffic by trust — management, application, and monitoring flows should not all share one wide-open path.
• Log the flows you deny so you can see attempts and catch drift over time.

Framework mapping

• NIST CSF 2.0 — PR.IR-01 — Networks and environments are protected from unauthorized logical access and usage
• CIS Controls v8 — Control 3 — Data Protection (safeguard 3.8: Document Data Flows)

How to move it toward Implemented

• Write a one-page data-flow document: list each approved flow (source, destination, port and protocol, direction, and reason). This is your enforcement baseline and it closes CIS safeguard 3.8.
• Set the host firewall to default-deny, then allow only the approved flows — keeping loopback and already-established connections open so you don’t lock yourself out. With nftables, set the input and output chain policy to drop and add explicit accept rules; or with ufw (Uncomplicated Firewall) run ufw default deny incoming, ufw default deny outgoing, then ufw allow only what you listed.
• Turn on logging for dropped packets (ufw logging on, or a log prefix rule in nftables) and confirm denials land in /var/log/ so you can review drift.
• Verify the rules actually enforce the flow — from another host, confirm an approved port connects and an unapproved one is refused (ss -tlnp to see listeners, nc -vz <host> <port> to test a single flow).
• Attach the data-flow document and the firewall ruleset as hardening evidence on the asset, naming AC-4 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.