PCI DSS v4.0: Network Security Controls

The PCI DSS defines network security controls as ‘network policy enforcement points that typically control network traffic between two or more logical or physical network segments (or subnets) based on pre-defined policies or rules.’  This means that the PCI DSS considers NSCs to be something that analyses all network traffic at a certain point within or between networks/segments and, based on the defined rules, determines whether the traffic is allowed through or not.

That may sound a lot like the definition of a firewall, and in fact a firewall would fit that definition. But crucially, due to advancements in technology and services, there are many other devices and systems that could provide the same functionality such as virtual firewalls, cloud access controls, containerisation systems, virtual private clouds (VPCs), software defined networking, app-service security groups, access control lists, core routing tables, and many more.

By understanding the definition of an NSC and how it differs from a firewall, we can also detect the reasoning for the change; the PCI Security Standards Council (SSC) wanted to ensure that organisations are adequately controlling network traffic without being restricted to a specific device.  To that end, the more generic term of ‘network security control’ provides much greater flexibility for organisations to meet the requirements of the Standard.

With all that in mind, what should you use as your NSCs?  This will very much depend on your environment and organisation, as well as budget, expertise, and experience.  A firewall will often be the obvious solution, but it is important to remember that there are many other options available and as long as they meet the PCI DSS requirements, they will be perfectly acceptable.

The critical aspect is to ensure that your chosen NSC is capable of providing all the key functionality that the PCI DSS mandates for NSCs. Functionality such as providing segmentation to isolate devices and networks from each other, enforcing the use of secure network protocols to encrypt data transmissions (for example, transport layer security), maintenance and updating of its configuration to protect cardholder data from potential threats, intrusion detection or prevention systems (IDS/IPS), anti-spoofing measures, stateful packet inspection, and others.

Finally, you should carefully consider where to position your NSCs within your network.  Whilst firewalls are traditionally placed at network perimeters and internal boundaries between networks, other types of NSC may be better positioned elsewhere.  For example, you may use NSCs to control the traffic to each individual device irrespective of actual network boundaries, which is otherwise known as micro-segmentation. In containerised cloud systems, the NSCs will be better placed between the containers and, if you are using serverless cloud applications, then the NSCs will be positioned between the app-services to control data flow between them.  As is often the case with the PCI DSS, the solution that is best suited to any given organisation will be heavily dependent on what the environment looks like.

In conclusion, whilst this change might seem like a simple wording change, in actual fact it introduces significant flexibility to the PCI DSS as well as providing a certain level of future proofing, as the definition of NSC will no doubt apply to newer technologies and systems as they are developed over the coming years.  This flexibility and future-proofing is a running theme with the changes seen in v4.0, as it was the key consideration and motivation for the new version.