Network Architecture Best Practices — and Things to Watch Out For — Under PCI DSS 4.0

When PCI DSS 4.0 was released in 2022, compliance personnel, Consultants, and Assessors had to essentially relearn the entire standard. Many changes were dramatic and required careful attention to understand them properly, but others were simple and straightforward. 

The network architecture changes under PCI 4.0 were simple, but there’s still plenty of room for damaging errors. This article introduces you to the recent changes to the network architecture requirements in PCI and gives you important best practices to keep your organization out of trouble.

By the way: while the following information is required for PCI 4.0, these are smart practices for any organization to leverage. 

Get TCT’s complete guide to PCI DSS Certification

PCI DSS 4.0 Network Architecture Changes

PCI 4.0 no longer requires you to use specific technologies or tools for your network architecture. Instead, requirements state that you must have “network security controls,” or NSCs, in place. NSCs are the combined technologies that provide network protection.

The reason: nowadays, organizations may not necessarily have an actual firewall or router. Other technologies can effectively perform the same function as a traditional physical firewall and/or a router, and many of them these days are virtual in a cloud-based environment. So you may not have a physical firewall, but you do have controls in place that are controlling traffic and network security groups.

PCI 4.0 has been updated to recognize the evolving technology and simply classifies these tools under Network Security Controls (NSCs). Of course, you can still have a firewall and router, but you are no longer required to use them, or do your best Onion Slave Dance (you’re welcome for the Star Trek throwback) for your Assessor.

Related: 2 Big PCI 4.0 Requirements You Need to Understand Before the Deadline

Network Architecture Best Practices

The change to NSCs in PCI 4.0 may appear simple, but that doesn’t mean setting up your network architecture properly is a simple task. I’ve seen many organizations that technically had a firewall and router or NSCs in place, but their configuration was an absolute mess that put them at risk.

You can put yourself in a better position to protect against bad actors by following these best practices.

Maintaining accurate diagrams and data flows

Be sure that changes to connections and configurations of the NSCs are approved and managed via change control. Nothing should change on the network diagram or data flow without change control. 

As you’re running things through your change control process, be cognizant of whether it will be a modification that will impact the network diagram or data flow diagram. If so, fine — go ahead and make those incremental updates to those documents as you go. 

It’s a whole lot easier to make those changes as you go, because you won’t forget what you did. But if you wait a few months to make all the updates at once, you’re unlikely to accurately remember every change you’ve made over that period. 

Other best practices:

• Keep your network diagram and your data flow diagram up to date and accurate.
• Have the configuration standards in place for the NSC rule sets. Keep them up to date. 
• Make sure that configuration files for NSCs are secure from unauthorized access and that they’re kept consistent with the active network configuration.

Approved services protocols and ports

Make sure all services, protocols, ports, and security features are defined for all of the services, protocols and ports that are in use. You want to review all of these rules to ensure that anything activated is indeed necessary (you’ll need to do this initially and again in the future as part of your operational compliance requirements). That said, review each rule in your allowed ruleset to confirm it’s as buttoned up as is absolutely necessary. As an example, if the only group that requires port 22 access externally is coming from your HQ office IP address, that traffic should be limited to originating from that specific IP address to mitigate the scope of exposure and reduce risk to the organization.

There’s a notion of a defined business need must also be documented for each of these rules you have in place. When people document new rule sets, they typically document what the service/protocol/port does, not why it’s being allowed. For example, they might say “This rule is serving web traffic” instead of “This rule is allowing clients to get to our internet based _____ portal.”

Finally, ensure that there is either an implicit deny all functionality built into your NSC solution, otherwise ensure that the last explicit rule in the NSC is a deny all rule. For the implicit deny all option, you’ll likely need to annually gather up vendor-specific documentation to validate that nothing has changed with the solution you’re depending on to protect your business.

Review NSC configurations every six months

There’s one PCI item that requires you to maintain configuration standards, and a later item in PCI that says you need to review those configurations every six months. The intent is to confirm that you still need each of the rules.

Similar to the change control for network and data flow diagrams, you need to update your configuration standards as you go. When you get down to your six month review, don’t make assumptions — pull the active configuration, compare it to your documented configuration, and validate that there are no unexpected differences between the two. 

What do I mean by expected differences between the two? Over the course of the six month period, there were a number of change controls that may have impacted the last documented configuration standard when compared to the active configuration. These should fall into the bucket of an expected difference, and if everything is working appropriately, this should account for all of the discrepancies being observed between the two.

If there’s an unexpected discrepancy, red sirens should start going off in your head. Some type of failure has occurred. The difference could be benign, but it could be an alert about an incident.

If someone didn’t follow a process, didn’t cross a T or dot an I, you need to be able to determine if it was done innocently or with intent. Did someone get onto your system and change the configuration, or did something simply not get documented in change control? 

If you do find a discrepancy, immediately start an investigation. Figure out who touched what, when, and why. Was it a simple mistake, or did someone gain unauthorized access to your network environment? 

You don’t want to have that question unresolved, and getting to the bottom of the issue could mean longer work days and delays you hadn’t planned for.

Compare the static configuration of the NSC against the active configuration

For some NSC technology, there’s essentially a config file that says if the actively running configuration that’s in memory on this device goes boom, then I need to reset it to this static configuration that’s on the device. 

The way that devices are configured, it’s increasingly important to be aware of the technology you’re using for your NSCs. If your NSCs have a static configuration, you’ll need to pull it to compare the running configuration to the static version.

If a bad actor accesses your network, they may tweak the active configuration, but they wouldn’t get onto the actual config file on the device itself. Alternatively, they could have laid an Easter egg in your static config which will only take effect once the device is rebooted. 

Either way, there should never be differences between these files unless change control is literally actively being deployed to the device and you’re between config modification and reboot at the time of the compare. As unlikely as it may appear to be, I have seen it happen and cause a good deal of consternation until the team figured out what was going on.

Restrict traffic to and from your cardholder data environment

Make sure that inbound and outbound traffic from your cardholder data environment (CDE) is restricted to only necessary traffic, with everything else being denied.

If you’re getting into the PCI space for the first time, it can be hard to identify the necessary outbound traffic from the environment. The inbound traffic is fairly easy to understand, but many organizations don’t typically start out with a good sense of their outbound traffic requirements. That’s an area that will take time to understand.

Turn on logging at the NSC and log both inbound and outbound traffic. Let it run for several months and review the logs to get a good starting point with an extraction of the needs of your organization. 

As you review the outbound protocols, don’t assume if the outbound port is being used that it must be necessary. That’s a bad assumption, because you could already have a threat actor in your system who is porting data outbound. 

Take a look at those logs critically and be sure you have it locked down to only the ports that are required for validated, approved business purposes.

Limit disclosure of IP addresses and error information

There’s an item in PCI for disclosing internal IP addresses and allowing only authorized users to view detailed (internal) error information. This is a little line item that tends to trip people up a good amount. 

Error messages may be pushed to the frontend interface — especially when you have a web interface, APIs, or some form of port-level connectivity. Be aware of the error messages that are being pushed back to users to ensure that the error messages aren’t exposing internal IP addresses in the error messaging. 

Internal personnel are the only ones that should be capable of seeing the full internal messages for troubleshooting purposes, since there is a lot of valuable information which could otherwise inadvertently be passed to a bad actor with no legitimate business need to see the information.

Don’t Expose Your Organization to Unnecessary Risks

While the network architecture changes under PCI 4.0 are pretty straightforward, there’s still plenty of opportunity to get tripped up, if you don’t follow best practices closely. Don’t put yourself in a position to compromise your network security — do your due diligence and button up those minute details in your network architecture.