# Deny by default is something you check, not assume

> What NIST SC-7(5) and AC-4 actually ask of a rule base, the six ways deny-by-default quietly erodes, and how to check it with objects and NAT resolved.

**Compliance** · 2026-09-29 · 6 min read · By Beyrak A., Founder & Security/System Engineer

**Key takeaways**

- SC-7(5) asks you to deny by default and allow by exception, and NIST’s own discussion says that covers outbound traffic as well as inbound.
- A rule base can end in a deny and still not deny by default. Object groups, NAT, “any” services and permissive vendor defaults widen it one rule at a time.
- Checking it means computing effective access with objects and NAT resolved, then treating every allow as an exception that needs a reason.

## What SC-7 and SC-7(5) actually ask for

SC-7 is the boundary protection control in SP 800-53 Rev. 5, and its first line is broader than most people remember: “Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system.” The perimeter is in scope, and so are the firewalls between your own segments.

SC-7(5), deny by default and allow by exception, sharpens that. The control statement reads: “Deny network communications traffic by default and allow network communications traffic by exception”, at managed interfaces, for systems you name, or both. The discussion adds the part teams skip: “Denying by default and allowing by exception applies to inbound and outbound network communications traffic.” The goal, in NIST’s words, is that “only those system connections that are essential and approved are allowed.”

If you’re mapping from an older Rev. 4 document, CA-3(5) (restrictions on external system connections) is gone. Rev. 5 withdrew it and folded it into SC-7(5). Which of these enhancements your system must meet depends on the baseline you tailor from SP 800-53B; this post doesn’t assume one.

## AC-4 is about where traffic goes, not who sends it

The other control that lands on your rule base is AC-4, information flow enforcement. Its discussion draws a line worth keeping: information flow control “regulates where information can travel”, “in contrast to who is allowed to access the information.” Firewall rules belong here and in SC-7. Admin accounts on the firewall belong to AC-3 and AC-6.

AC-4 enforces “organization-defined information flow control policies”, which means a written policy has to exist before any rule can be judged against it: which zones may talk to which, on which services. SC-7(11) says the same for inbound traffic, allowing incoming communications only from authorized sources to authorized destinations. CM-7(1) closes the loop with a periodic review “to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services.” Without the written policy, “deny by default” has nothing to be measured against.

## How a rule base quietly stops denying by default

Almost every rule base ends in a deny, so it looks compliant on a slide. The drift happens above that line, in rules that each looked reasonable when someone added them.

1. **Defaults that allow, or don’t log.** On PAN-OS the built-in intrazone-default rule allows traffic within a zone, and neither default rule logs until you override it. On FortiGate, the implicit deny at the bottom of the policy list doesn’t log violation traffic unless you turn that on. The deny may be there; the evidence of it often isn’t.
2. **Object groups that grew.** A rule written for “app-servers” is only as narrow as that group is today. One nested group added for a migration can turn a /24 into a /16.
3. **NAT that publishes more than intended.** A destination NAT or VIP without port restrictions, paired with a broad rule, exposes a whole host instead of one service.
4. **“Any” as the service.** The source and destination can be tight and the rule still allows every port between them.
5. **Outbound left wide open.** An inside-to-internet rule on any service is the most common exception nobody wrote down, and SC-7(5) covers it just as much as inbound.
6. **Temporary exceptions that stayed.** Access opened for a vendor or a cutover, with no end date, is still an exception two years later.

*Example: rule base, dmz-policy*

| # | source | destination | service | action | note |
|---|---|---|---|---|---|
| 10 | web-dmz | app-servers | tcp/8443 | allow | |
| 12 | web-dmz | app-servers | any | allow | service any |
| 30 | inside | internet | any | allow | outbound, any service |
| 99 | any | any | any | deny | log off |

The rule base ends in a deny, so it looks deny-by-default. Rule 12 allows every service to the app tier, and rule 30 lets the whole inside zone reach the internet on anything. Both are exceptions nobody documented.

Rule 12 looks narrower than it is, because “app-servers” is a group. Expanded, it tells a different story.

*Example: effective access, web-dmz → app-servers*

- rule text: web-dmz → app-servers
- app-servers: 10.20.4.0/24, 10.20.0.0/16 (the /16 arrives via the nested group legacy-all)
- services: tcp/8443 (rule 10), any (rule 12)
- effective: 10.20.0.0/16 on every port, from web-dmz

What the rule text says against what it permits once the group is expanded: one DMZ host can reach an entire /16 on every port.

> A rule base that ends in a deny is not the same thing as a rule base that denies by default.

## How to check it on a real rule base

1. **Write the flow policy first.** List the segment pairs that may talk and the services they need. That document is AC-4’s organization-defined policy, and for external telecommunication services SC-7(4) asks for it explicitly: “Establish a traffic flow policy for each managed interface.”
2. **Compute effective access, not rule text.** For each segment pair, resolve every object and apply NAT, then compare the result with the policy. Anything allowed that the policy doesn’t name is a finding.
3. **Rank the allows by exposure.** Start with the widest: any-any rules, /8 and /16 destinations, service any. That’s where the gap between policy and reality is biggest.
4. **Treat every allow as an exception.** SC-7(4) wants each exception documented “with a supporting mission or business need and duration of that need”, reviewed at a set frequency, and removed when the need is gone. That enhancement is scoped to external telecommunication services, but the same habit is what keeps internal boundaries honest.
5. **Check both directions.** Run the same comparison for outbound traffic. Most drift lives there.
6. **Check the defaults.** Confirm an explicit deny that logs sits at the end of every rule base, as in check 13 of our [firewall audit checklist](https://nometa.az/en/blog/firewall-audit-checklist/).

The expensive step is the second one, because resolving nested groups and NAT by hand across several vendors takes days. [SAMURAI’s Policy Analyzer](https://nometa.az/en/policy-analyzer/) does it from configuration: it computes effective access with objects and NAT resolved across Palo Alto, Cisco FTD, FortiGate, Juniper SRX and ACI, flags overly broad, shadowed and redundant rules, and ranks every rule by exposure. Change detection shows who widened a group or a rule, and when. Together that gives you evidence for an SC-7(5) or SC-7(11) review, and a short list to take into it.

## What configuration analysis can’t show

Be clear about the limits before you put this in front of an assessor. SC-7a asks you to monitor communications as well as control them. SAMURAI reads configuration, not traffic, so it shows what the rules permit, not what actually crossed the boundary. Traffic monitoring is a different tool.

It also doesn’t hold the business justification, the end date or the approval behind each exception, and it doesn’t run rule recertification. Keep those in your change records, where an assessor expects to find them. And no tool makes a system compliant on its own: the organization sets the parameters and an assessor judges the control. What configuration analysis gives you is the part that’s hardest to produce by hand, a true picture of what each boundary allows today. For how that picture is built hop by hop, see [multi-vendor path tracing](https://nometa.az/en/blog/multi-vendor-path-tracing/), or the [firewall analyzer page](https://nometa.az/en/firewall-analyzer/) for what SAMURAI reads from each vendor.

---

Canonical page: https://nometa.az/en/blog/nist-sc-7-deny-by-default/
Part of SAMURAI, a self-hosted, multi-vendor network monitoring & security platform. Overview: https://nometa.az/llms.txt
Contact: info@nometa.az · Docker Hub: https://hub.docker.com/r/beyrak44/samurai