Deny by default is something you check, not assume

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.

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

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.

The expensive step is the second one, because resolving nested groups and NAT by hand across several vendors takes days. SAMURAI’s 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, or the firewall analyzer page for what SAMURAI reads from each vendor.