External networks are untrusted. SC.L2-3.13.5 requires a default-deny posture on all external-facing systems and network interfaces. Every inbound connection must be explicitly allowed. The assessor will examine firewall rules and may test connectivity to verify the policy is enforced. This is a more specific requirement within the broader SC.L2-3.13.1 boundary protection control.
What the assessor is actually evaluating
The assessor will examine:
Firewall configuration: External-facing firewalls should have an implicit deny rule at the end of the rule set. All rules above it explicitly allow specific traffic. The assessor will review firewall configurations and verify the default action is deny.
Documented firewall rules: You should have a list of all allowed inbound connections, including source, destination port, and business justification. Rules should be minimal and specific (not blanket allows).
Testing: The assessor may perform a port scan of your external interface to verify that only documented ports are open.
What a realistic SSP definition looks like
Policy: “The organization implements a default-deny firewall posture on all external-facing network interfaces. All inbound traffic is blocked by default. Specific inbound rules are created only when business requirements demand it. Firewall rules are documented with owner, business justification, and review dates. Rules are reviewed quarterly and obsolete rules are removed.”
Supporting details:
- Firewall device: Palo Alto Networks or similar enterprise firewall at the internet gateway.
- Allowed inbound rules: HTTPS to web server (ports 443), SSH to administrative access point (port 22, restricted to specific source IPs).
- Blocked inbound: All other ports and protocols are denied by default.
- Rule documentation: Spreadsheet showing each inbound rule, source/destination, port, protocol, and business owner.
- Review process: Quarterly review of all inbound rules; quarterly testing via port scan to verify only documented ports are open.
How to present your evidence
- Default-deny firewall policy document: Describes the default-deny requirement and how it is implemented.
- Firewall configuration screenshots: Show the firewall rule set with the final implicit deny rule visible. Provide at least 10-15 rules showing specific allow statements followed by the deny rule.
- Inbound rule inventory: A spreadsheet or document listing all allowed inbound connections with source, destination, port, protocol, and business justification.
- Rule review records: Documentation of quarterly rule reviews showing obsolete rules were identified and removed.
- Port scan results: Evidence from Nessus, nmap, or similar tool showing a scan of your external IP address with results. Verify that only documented ports are open.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Assessor: “Describe your firewall configuration. What is the default action on your external-facing firewall?”
You: “Default action is deny. All inbound traffic is blocked unless explicitly allowed by a rule.” [Pull up firewall configuration showing the implicit deny rule at the end]
Assessor: “Show me the list of allowed inbound rules.”
You: “We have three inbound rules: HTTPS to the web server, SSH to a bastion host restricted to our vendor’s IP range, and SNMP from our monitoring tool.” [Pull up the rule list with justification for each]
Assessor: “I am going to perform a port scan of your external IP. What will I find?”
You: “You will see only ports 22, 443, and 161 open. Everything else is blocked.” [Later, provide the port scan results showing only those ports are accessible]
Common failures
Default-allow firewall: The firewall is configured to allow all traffic by default and blocks only specific ports. This is backwards. An attacker discovering a new service running on an unexpected port will have immediate access.
No inbound rule documentation: Rules exist in the firewall, but you cannot articulate what they do or why they are needed. The assessor will push back and ask for business justification.
Overly permissive rules: A rule allows all traffic from a broad CIDR block (e.g., 0.0.0.0/0) to a server. While not necessarily wrong, it needs strong justification (e.g., a public-facing web server).
Obsolete rules that were never removed: A rule was created for a contractor 18 months ago but was never removed. The port remains open even though the business need has ended.
Clearly default-deny configuration: The final firewall rule is obviously an implicit deny. No traffic falls through to an allow statement.
Minimal, documented inbound rules: Only the bare minimum ports are open, and each rule has clear business justification.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages your firewall, request a copy of the inbound rule list. Understand what traffic is allowed and why. Participate in quarterly rule reviews. Ensure the MSP maintains a default-deny posture and removes obsolete rules. You are accountable to assessors for the firewall configuration.
This guide is for reference only and does not replace official CMMC documentation or professional compliance advice.