What PCI-DSS Actually Expects from Your Firewall Rules

The standard says more than you think

If you have ever prepared for a PCI-DSS assessment, you have probably heard something like "make sure your firewalls are configured properly." That sentence sounds simple until you sit down with an assessor who wants to see documented business justification for every single allow rule in your cardholder data environment. PCI-DSS v4.0.1 is remarkably specific about what it expects from network security controls, and most teams discover the gaps only when the audit is already underway.

The problem is not that people ignore the standard. It is that the standard's language sits at a level of abstraction that makes it easy to think you are compliant when you are not. "Restrict inbound and outbound traffic to that which is necessary" reads like common sense. Translating it into actual firewall rules that survive an assessor's review is where things get difficult.

Requirement 1: Install and maintain network security controls

PCI-DSS Requirement 1 is the foundation. It covers the policies, procedures, and technical controls that govern how traffic flows in and out of your network, particularly around the cardholder data environment. Four sub-requirements deserve close attention because they directly dictate what your firewall ruleset should look like.

Requirement 1.2.1 says you must restrict traffic to only that which is necessary for business operations. This sounds obvious, but "necessary" is doing a lot of heavy lifting. It means you cannot have rules that allow traffic just because someone requested it once. Every rule must correspond to a current, documented business need. If a service was decommissioned six months ago but the firewall rule still allows traffic to it, that is a finding.

Requirement 1.2.5 requires that all services, protocols, and ports allowed through network security controls have a documented business justification. Not "we think we need this" but a written explanation tied to a business function. During an assessment, the QSA will pick rules at random and ask your team to produce the justification. If you cannot, the rule fails the test.

Requirement 1.3.1 mandates that inbound traffic to the cardholder data environment is restricted to only necessary traffic, with all other traffic specifically denied. This is the deny-by-default principle applied to inbound flows. Your firewall's last rule for any CDE-facing interface should be an explicit deny-all. Everything above it should be a specific, justified exception.

Requirement 1.3.2 applies the same logic to outbound traffic from the CDE. Many teams focus heavily on what gets in and forget about what gets out. But if a compromised system inside the CDE can reach arbitrary internet destinations, your segmentation has a serious hole. Outbound rules should be just as tight as inbound ones.

Requirement 1.4.1 requires network security controls between trusted and untrusted networks. This is where zone architecture matters. The firewall is not just a box between your network and the internet. It is the enforcement point between every trust boundary: internet to DMZ, DMZ to internal, internal to CDE.

The CDE segmentation requirement

This is where PCI-DSS gets teeth. The cardholder data environment, every system that stores, processes, or transmits cardholder data, must be segmented from the rest of your network. Segmentation is not optional and it is not a suggestion. It is the mechanism that limits the scope of your PCI assessment.

Here is why that matters commercially: if your CDE segmentation is not effective, the assessor can declare your entire network in scope for PCI-DSS. Every server, every workstation, every printer becomes subject to the full set of PCI requirements. For a mid-sized company, the difference between "50 systems in scope" and "3,000 systems in scope" is the difference between a manageable audit and a six-figure remediation project.

Every dashed line in that diagram is a place where your firewall rules must enforce isolation. The CDE should only be reachable through controlled, documented paths. If an assessor can trace a route from the internet to a database holding card numbers without passing through at least two firewall boundaries with explicit allow rules, you have a segmentation failure.

Effective segmentation means your firewall rules must explicitly deny traffic between the CDE and other zones except where there is a documented, justified business need. A payment processing server in the CDE might need to reach a tokenisation service in the DMZ over a specific port. That is fine, as long as it is documented, encrypted, and nothing else can traverse that path.

Default deny, least privilege, and the documentation burden

Three principles run through every PCI-DSS firewall requirement: default deny, least privilege, and documentation. They sound like security basics, but implementing them at scale across a real firewall ruleset is harder than it appears.

Default deny means your firewall policy ends with "deny all" and everything above it is an explicit exception. Most firewalls ship with this as the default, but it is not uncommon to find rulesets where an early "allow any" rule was added during troubleshooting and never removed. One any-to-any rule at the top of your policy can silently negate every carefully crafted rule below it.

Least privilege means each rule allows only the minimum traffic required. Not "allow TCP from the application subnet to the database subnet on ports 1-65535" but "allow TCP from 10.20.30.0/28 to 10.20.40.5 on port 5432." The source should be as narrow as possible, the destination should be a single host where feasible, and the port should be exactly what the service requires.

Documentation is the piece that catches most teams off guard. PCI-DSS does not just require that your rules are correct. It requires that you can explain why each rule exists. During an assessment, the QSA might pull 20 rules at random and ask for the business justification, the ticket that authorised the rule, and the date of the last review. If your firewall has 500 rules and 200 of them have no associated documentation, you are facing a significant number of findings.

Common audit findings and how to avoid them

After working with enough firewall rulesets, patterns emerge. The same types of violations appear in nearly every pre-assessment review. Knowing what assessors look for gives you a head start on remediation.

Any-to-any rules. This is the single most common finding. A rule that allows any source to reach any destination on any port is the antithesis of everything PCI requires. Sometimes these exist because someone added them during an outage and forgot to remove them. Sometimes they are the legacy of a migration that was never cleaned up. Either way, they must go. Every any-to-any rule should be decomposed into specific, justified rules or removed entirely.

Overly broad source or destination ranges. A rule allowing traffic from 10.0.0.0/8 to reach a CDE host is too broad. That /8 covers over 16 million addresses. The assessor will ask why all of them need access to your payment systems. The answer is almost always that they do not, but nobody narrowed the rule when it was created.

Wide port ranges. Allowing ports 1024-65535 is a common shortcut when someone does not know the exact port their application uses. From a PCI perspective, this is nearly as bad as allowing all ports. Each open port is a potential attack vector, and the standard requires you to justify each one.

Plaintext protocols in CDE paths. If traffic carrying cardholder data traverses your network unencrypted, that is a serious finding. HTTP instead of HTTPS, FTP instead of SFTP, Telnet instead of SSH. Any rule that allows a plaintext protocol on a path that touches the CDE needs to be flagged and remediated. This also applies to management protocols: if you are managing firewall appliances in the CDE path over Telnet, that is a problem.

Database ports exposed to broad sources. PostgreSQL on 5432, MySQL on 3306, MSSQL on 1433. These should only be reachable from the specific application servers that need them. A rule allowing the entire internal network to reach a CDE database is an over-permission that assessors will flag immediately.

RDP or SSH from the internet. Remote administration protocols should never be directly reachable from untrusted networks. If your jump host is accessible via RDP from the entire internet, you have both a PCI finding and a significant security risk. These services should be behind a VPN or a bastion host with strict source restrictions.

Missing business justification. This is not a technical misconfiguration but a documentation gap, and PCI-DSS treats it as a control failure just the same. Every allow rule needs a corresponding justification. "Needed for the app" is not sufficient. "Allows payment gateway to communicate with tokenisation service for real-time card processing per architecture document AR-2024-15" is what the assessor wants to see.

How to approach a PCI firewall review

If you are preparing for an assessment, there is a practical sequence that reduces the chance of surprises.

Start by identifying every firewall interface that touches the CDE or sits on a trust boundary. Map the traffic flows. For each flow, verify that there is a corresponding rule and that the rule is as narrow as possible. Then verify that each rule has documentation.

This sounds manageable until you realise that a typical enterprise CDE might involve 8 to 12 firewall zones with hundreds of rules between them. Manually reviewing each rule against PCI requirements takes time, and it is easy to miss things. A rule might look compliant at a glance but allow an overly broad source range that you only catch when you look closely at the subnet mask.

This is where automated validation becomes valuable. netbobr implements 35 PCI-DSS-specific rules that check firewall flows against the requirements discussed above. Rather than manually reviewing each rule against a checklist, you can validate a flow and get immediate feedback on which PCI requirements it might violate.

netbobr's PCI-DSS rule categories

The tool organises its PCI checks into categories that map directly to the types of findings assessors look for.

Default-deny and overly permissive rules (PCI-NET-001 through PCI-NET-005). These catch any-to-any rules, overly broad source and destination ranges, and wide port ranges. PCI-NET-001 flags rules where both source and destination are unrestricted. PCI-NET-003 catches cases where the source or destination covers an excessively large address space. PCI-NET-004 identifies port ranges that are wider than what any single service should require.

Plaintext protocol detection (PCI-NET-010 through PCI-NET-019). These rules flag flows that use unencrypted protocols where encrypted alternatives exist. HTTP when HTTPS should be used, FTP when SFTP is available, Telnet when SSH is the standard. Each rule maps to the PCI requirement that cardholder data must be encrypted in transit across open, public networks, and to the broader principle that sensitive paths should not carry plaintext.

Tunnelling and inspection (PCI-NET-030 through PCI-NET-033). These check for protocols that can tunnel traffic past inspection points, such as GRE or IP-in-IP, and for flows that might bypass security monitoring. If encrypted tunnels cross CDE boundaries without terminating at an inspection point, these rules flag the gap.

Boundary protection (PCI-NET-040 through PCI-NET-042). These validate that trust boundaries have appropriate controls. Traffic from untrusted zones to the CDE must pass through intermediary controls. Direct internet-to-CDE paths are flagged as violations regardless of protocol.

Service exposure (PCI-NET-050 through PCI-NET-062). These are the service-specific checks. PCI-NET-050 catches database ports accessible from overly broad source ranges. PCI-NET-051 flags RDP from internet-facing zones. Other rules in this range check for exposed administration interfaces, unprotected API endpoints, and services that should not be reachable from outside their designated zone.

Documentation requirements (PCI-NET-070). This checks whether flows have associated business justification metadata. While no automated tool can verify the quality of a justification, netbobr can flag flows that have no justification at all, which is the most common documentation finding.

The gap between compliant on paper and compliant in practice

There is a pattern that repeats across organisations preparing for PCI assessments. The policies are written correctly. The architecture diagrams show proper segmentation. But when someone actually looks at the firewall rules, they do not match. The policy says "default deny" but there is an allow-any rule that predates the current team. The architecture shows three distinct zones but the rules between two of them allow all traffic.

This gap exists because firewall rules accumulate over years. People leave, projects get decommissioned without cleaning up their rules, emergency changes become permanent. The rule that was added at 2 AM during an outage is still there 18 months later because nobody went back to tighten it up.

PCI-DSS v4.0.1 tries to address this with Requirement 1.2.5's insistence on documented justification and periodic review. But the review only works if you have a way to check the rules systematically. Scrolling through a ruleset of 400 entries looking for violations is how things get missed.

Automated checking does not replace human judgement. An assessor will still want to understand your architecture and your reasoning. But running your flows through netbobr before the assessment starts means you find the obvious problems early, when they are cheap to fix, rather than during the assessment itself, when every finding carries weight.

What to do next

If your next PCI assessment is approaching, consider this sequence. First, identify your CDE boundaries and map the firewall zones that enforce them. Second, export or document every rule on those zone boundaries. Third, check each rule against the core requirements: is it deny-by-default, is it least privilege, does it have documentation, does it allow plaintext where it should not. Fourth, remediate the gaps.

The organisations that pass PCI assessments cleanly are not the ones with the most sophisticated firewalls. They are the ones that can explain every rule and prove it is as narrow as it needs to be. That combination of tight rules and clear documentation is what PCI-DSS v4.0.1 is really after.