Intro to PCI version 4: Requirement 4

Encrypt transmission of cardholder data across open, public networks.  What is an open, public network?  There are technically (no pun intended) many different ways to define an open, public network.  For our purposes, we will just declare that an open network is one that shared connections between internal and external users that are visible to others, outside of the authorized individuals and/or systems.  In other words, if the connection type leaves your environment and does not use a locked down private connection (VPN, etc.), let’s consider it in scope for requirement 4.

Overall Thoughts

So, we can frame the conversation, I feel the need to point something out from the start – we are discussing IT security through the lens of PCI security and what it takes to be compliant with the digital security standards, specifically to point out the deltas between version 3.2.1 and 4.  The reason I say this, is to point out that from an over all security mindset, you should be working to do more than is required for compliance.  Compliance is not a sign of overall security; it is a single measuring point.  Think of compliance against any standards as one of your KPIs and develop additional indicators to achieve a higher level of security within your environment.   Once we are done with the series on changes coming up for PCI v4, I will work on one to highlight some low hanging fruit items to build on your compliant environment and start working towards a more secure stance.

What’s New for Req 4 in v4

Back to the topic at hand.  The changes in the form of new controls in requirement 4 of version 4 are:

  • 4.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?)
  • 4.2.1 – Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. ß Something that has not been part of the assessment before, so start tracking this data now.
  • 4.2.1.1 – An inventory of the entity’s trusted keys and certificates is maintained.  (Certificate inventory – see above where I say “start tracking this data now”)

It would be accurate to say there are not a lot of changes to existing controls, and there are also a lot of changes to existing controls. Generally speaking that is because there is change to the overall focus, which impacts all controls within the requirement, but no changes specifically made to the existing controls.

  • 4 – Clarification/guidance – The overall focus of requirement 4 is to confirm “strong cryptography” being used to protect the transmission of cardholder data as the focus of the requirement.

Conclusion

I can already feel some of relaxing because the lack of changes in requirement 4 make it feel as though this one will be easy to manage.  Well, the good news, for those of you that only use P2PE connections, or hosted iFrame solutions, it will be really easy!  Since it is pretty much not applicable to you already and nothing new changes that.  However, as we mentioned earlier when I mentioned the difference between compliant and secure, even if you can claim N/A due to a service provider managing this aspect of security for you, it is a good idea to track this information.  Now, your service provider is probably not going to share the actual certificate details with you but part of the due diligence in requirement 12 calls for you to maintain a program to confirm service providers are working in a PCI compliant manner.  This not only gives you the authority to check their AoC to make sure there were no issues with this part of their assessment, but it is actually better to view this as a requirement on your end to do so.  Don’t let the interconnectivity of the DSS get lost on you through allowing yourself to focus on the single controls without also looking at the bigger picture.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  Feel free to reach out to me directly with questions or to have a conversation via my email and/or social media information on the TBF website. 

Thanks for taking the time to read my thoughts on PCI v4 Requirement 4.  We will continue to work through each of the PCI requirements each week.