PCI DSS 3.2.1 updates and ShieldX

Ratinder Ahuja

Ratinder Ahuja

December 04, 2019

While the May 2019 changes made to take the PCI DSS standard from version 3.2 to version 3.2.1 were largely clarifications of the existing standard, any change in the standard is an occasion to take another look at how your organization is achieving compliance.

PCI sets out a number of requirements, not all of which are addressed by capabilities ShieldX provides (we don’t address physical access to servers, to take one obvious example). Here are a handful of requirements where ShieldX and the microsegmentation it provides are particularly relevant (or check the more complete listing here):

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Not last but least, there’s this sub-item about intrusion detection, which is something ShieldX builds in at a per-container granularity (unique in the industry as far as we’re aware):

11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

Cloud security

How is ShieldX relevant to the above requirements? Almost across the board, it has to do with building a data center architecture that uses not only containers for server workloads, but also uses containers to implement security services (making them more granular to deploy with greater agility). ShieldX creates tiers within a network that are elastic with the dynamic allocation of workloads.

So when it comes to Requirement 1, maintaining a firewall, ShieldX gives you a next-gen firewall like capabilities performing deep-packet inspection on a per-workload basis. When it comes to the requirements for data protected in storage and restriction of access to a need-to-know basis, access to tiers is limited by business policy, not by IP address—which some solutions do by using server Access Control Lists (ACLs).

One other point that has to be made has to do with scoping. The PCI Security Standards Council information supplement “Guidance for PCI DSS Scoping and Network Segmentation” makes it clear that organizations should give serious consideration to which elements of their business systems are within scope and which properly should not fall under PCI DSS compliance requirements. As the guidance notes, “when properly implemented, network segmentation is one method that can help reduce the number of system components in scope for PCI DSS.”

To state the obvious, reducing the segments of the network where PCI compliance is required inherently reduces the scope and complexity of PCI assessments.

Bottom line, we think ShieldX makes an enormous amount of sense for PCI DSS compliance regimes. Learn more about this in our recent writeup.