In PCI requirements 7 and 8 seem to go hand in hand with each other, and if there weren’t so many bleeding changes to 8 going into v4 I would have combined them into a single blog post (but there are, and I didn’t). Requirement 7 is about access management and 8 authentication/user account management. Two halves of the same coin. For this post we are going to just stick with R7, not to be confused with CR7 (if you know you know).
Overall Thoughts
So, as we have discussed in previous posts the council is working to mature the standards in a way to add additional accountability and limit risk associated with human error. In requirement 7 for version 4, we see a continuation of this mindset. As you will notice when we run through the changes most of them are focused on some form of oversight.
What’s New for Req 7 in v4
The new controls in requirement 7 of version 4 are:
- 7.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 6 (which was cut from 5, etc.)
- 7.2.4 – Review all user accounts and related access privileges appropriately.
- 7.2.5 – Assign and manage all application and system accounts and related access privileges appropriately.
- 7.2.5.1 – Review all access by application and system accounts and related access privileges.
Changes to the existing controls
Requirement 7 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it. This is very evidence in the changes to requirement 5 existing controls.
- 7 – Clarification/guidance – Updated principal requirement title to include system components and cardholder data.
- 7.1 – Now 7.2.1 / 7.2.2 / 7.2.3 – Clarification/guidance – Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement. (Expanding the requirements within the company documentation, which by its nature will require more involvement from management and business owners).
- 7.1.1 – Now 7.2.1 – Clarification/guidance – Clarified requirement is about defining an access control model.
- 7.1.2/7.1.3 – Now 7.2.2 – Structure/format – Combined requirements for assigning access based on job classification and function, and least privileges.
- 7.1.4 – Now 7.2.3 – Clarification/guidance – Clarified requirement is about approval of required privileges by authorized personnel. (This is one I have clients with long tenured employees having difficulty providing evidence on during their assessments. If you know you are going to have to provide proof of approval on your administrative staff’s access levels, make a point to have an annual review that is thoroughly documented, in a format that can be exported into an evidentiary document. Don’t just fall back on using an email from their manager saying “Yup. Looks good.”
- 8.7 – Now 7.2.6 – Structure/format – Moved requirement since it aligns better with the content in Requirement 7. (Aligns with our earlier comments on the two requirements being two halves of the same coin.)
- 7.2 – Now removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
Conclusion
As I mentioned at the start of the post, most of the changes to requirement 7 in version 4 have to do with making certain the access management aspect of your environment. The new areas of 7 are focused on account management and review for user and system accounts and the controls that have been modified are moving around to require a deeper dive into those areas to show compliance with the PCI standards. Developing proper management policies and processes will be key in improving your security stance in this realm. In a perfect world you will implement new processes for reviewing accounts (of all kinds) and find out you were already doing everything as you should. I suspect that some of you are going to have some amount of enlightenment when you start putting together an inventory of system level accounts. (Because if you don’t have an accounting of these accounts, how can you perform the needed reviews on their access each year, as required in 7.2.5.1?)
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 6. We will continue to work through each of the PCI requirements each week.