Our previous discussion touched on the (very) high level aspects of what makes version 4 of the PCI DSS different than its predecessors, so now we are in a better position to dive into some of the details. To this we are going to look at each requirement individually. This week we are going to start at the beginning – Requirement 1. As we work through the differences, let me apologize in advance for how dry the content is going to be as you work through it. I really wanted to make it lighthearted and fun. I decided that the information regarding the changes was too important, and I didn’t want anyone to miss something. I will write something clever (someday) to make up for this (and the next 11 or so blogs in this series)
Overall Thoughts
Keeping with the general direction of the maturation of PCI with version 4, Requirement 1 is all about expanding the language to be more encompassing of changing technologies and assuring management takes ownership of the program. One of the common shortcomings within security programs is figuring out who will own each aspect of the program. The more complicated the environment, the more complicated the organization structure, and the number of security standards effecting the company all play into a (sometimes) overwhelming jumble of chaos that requires numerous specializations among the staff (PCI, HIPAA, SOX, FedRamp, GDPR, etc.) Not wanting to get lost in the shuffle, PCI is making a point (that you will see mentioned in every post in this series) regarding not losing site of the importance of protecting consumers and their cardholder data.
What’s New for Req 1 in v4
The only net new item in version 4 for requirement 1 is the new 1.1.2, which states “Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.” This goes back to what I was mentioning in the previous paragraph. A formal document stating who is “responsible”. An interesting note though about how this is worded. It doesn’t say to document who is responsible for requirement 1, but rather “for performing activities” are “documented, assigned, and understood”. In short, for each requirement in section 1 of the PCI DSS you have to list who is responsible for actually doing the work, confirm it has been assigned to someone, and they have to demonstrate understanding of the processes, as the apply to PCI.
Changes to the existing controls
A decent number of items have been changed between v3.2.1 and v4. To keep track of them all, I am going to bullet them out for you and give a (very) brief note on them.
- 1 (in general) – Evolving Requirement – Changing the terms “routers” and “firewalls” for a more open “network security controls”. This is done to allow for an expansion of acceptable technologies that do the work normally associated with firewalls and traditional networking equipment. It also opens the door for some outside the box solutions, for those wanting to use the customized approach for any areas.
- 1.1.5 – Evolving Requirement – Now will be covered under 1.1.2
- 1.1 – Clarification/guidance – Now will be 1.2.1 and focus on defining and maintaining configuration standards.
- 1.1.1 – Clarification/guidance – Now 1.2.2 and has additional clarification that change control documentation in Req 1 must match those of Req 6 (6.5.1 specifically)
- 1.1.4 – Clarification/ guidance – Removed, as the SSC deemed it redundant.
- 1.1.6 – Clarification/ guidance – Split into two separate requirements (1.2.5 and 1.2.6) to allow for specific intent of each to be clearer.
- 1.1.7 – Clarification/ guidance – Is now 1.2.7 and adds more specific language around requirement to review configuration files every 6 months. (NOTE – Do NOT read this to be twice a year, but actually every 6 months.)
- 1.2 – Structure / Format – Removed. The SSC felt this was covered in other areas and no longer needed.
- 1.2.2 – Clarification / guidance – Renumbered to 1.2.8. Additional clarification on intent of securing configuration files.
- 1.2.1 – Clarification / guidance – Split into 1.3.1 and 1.3.2 to provide clarity around the intent.
- 1.2.3 – Clarification / guidance – Changed to 1.3.3 and provides additional details on the intent behind security controls between the CDE and wireless networks.
- 1.3 – Clarification / guidance – Renumbered to 1.4.1 to add specifics on the need for security between “trusted” and “Untrusted” networks.
- 1.3.1/1.3.2/1.3.5 – Clarification / guidance – Combined these three previous requirements to provide a focused intent on restricting ‘inbound’ traffic from untrusted networks.
- 1.3.4 – Clarification / guidance – Removed. SSC also felt this one was redundant.
- 1.3.6 – Clarification / guidance – Is now 1.4.4 to provide clarity around security that prevents direct access to cardholder data stores from untrusted networks.
- 1.4 – Clarification / guidance – Now listed in the DSS as 1.5.1 and provides clarity for securing devices that connect to both the CDE and any untrusted networks.
Conclusion
Whew! If you are still with me, then congratulations. You have shown a dedication to IT security, specifically PCI security that makes you a true leader in your environment. I don’t currently have a fancy plaque to present to you but know that I am proud of you. Now, as I stated at the start of our road through requirement 1, it was going to be dry and full of bullets. I feel like I delivered as promised (sorry). As PCI continues to mature and adapt to the ever-changing threat landscape, we will continue to discuss it and make sure you have a base understanding of the changes.
As always, if you have additional questions or feel the need to discuss payment card security (or data privacy or any other IT security/risk/privacy topic) feel free to reach out to us to continue the conversation. If you already have a trusted consultant, good for you on finding someone that you can rely on for counsel. Either way, make sure you are having conversations to build a better understanding of the changes happening that will have an impact on your organization.