In PCI the focus of requirement 8 is on authentication/user account management. Making certain that the people using credentials are the ones that are the account holders. With one of the primary concepts of IT security being the “need to know” process, this feeds right into that.
Overall Thoughts
When I am chatting with my peers in the realm known as “IT Security-landia” (I know, I know. I panicked), one of the common thought processes is around how to mitigate the biggest area of risk in most environments – the human factor. Not just from external threats, even those are real and need to be part of the overall equation, but also from internal threats. To get even more granular, internal threat doesn’t just mean an employee who is acting in what I call “bad faith”, or counter to the benefit of the company. Most of your internal risk comes from employees that just make mistakes. This can happen via weak passwords, poor management of their own personal information, or being to naïve/trusting of others. Requirement 8 is designed to help the company reduce the impact from these people (and the others mentioned as well).
What’s New for Req 8 in v4
The new controls in requirement 8 of v4 are:
- 8.1.2 – Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 7 (which was cut from 6, etc.)
- 8.3.6 – Minimum level of complexity for passwords when used as an authentication factor. – Most of the changes are for internal/non-consumer accounts, with an exception for companies with a technology barrier (look this one up)
- 8.3.10.1 – If passwords/passphrases are the only authentication factor for customer user access, passwords/passphrases are changed at least every 90 days, or the security posture of accounts is dynamically analyzed to determine real-time access to resources.
- 8.4.2 – Multi-factor authentication for all access into the CDE. (ALL ACCESS – this will have heavy impact on call centers and client support groups – plan ahead and start working on the workstream planning and training)
- 8.5.1 – Multi-factor authentication systems are implemented appropriately. (aka, increased assessment requirements and documentation needed)
- 8.6.1 – Manage interactive login for accounts used by systems or applications. (A lot of the system accounts that the enterprise views as “set it and forget it” will require a more active management philosophy.)
- 8.6.2 – Passwords/passphrases used for interactive login for application and system accounts are protected against misuse.
- 8.6.3 – Passwords/passphrases for any application and system accounts are protected against misuse.
Requirement 8 is changing not only how user accounts are managed, but also how system accounts are as well. Between the changes to system accounts and MFA needed for all users that access the cardholder data environment, you can see where they are forcing companies to exert additional effort into preventing unauthorized users from gaining access to sensitive data.
- 8 – Clarification/guidance – Standardized on terms “authentication factor” and “authentication credentials.”
- 8 – Clarification/guidance – Removed “non-consumer users” and clarified in the overview that requirements do not apply to accounts used by consumers (cardholders).
- 8 – Structure/Format – Removed note in overview that listed requirements that do not apply to user accounts with access to only one card number at a time to facilitate a single transaction and added that note to each related requirement.
- 8.1.1 – Now 8.2.1 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.5 – Now 8.2.2 – Evolving Requirement – Changed focus of requirement to allow use of shared authentication credentials, but only on an exception basis. (Rejoice Root users! Rejoice!)
- 8.5 – Now 8.2.2 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.5/8.5.1 – Now 8.2.2 & 8.2.3 – Structure/format – Moved requirements for group, shared, or generic accounts and for service providers with remote access to customer premises under Requirement 8.2.
- 8.1.8 – Now 8.2.8 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.2 – Now 8.3.1 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.1.6 / 8.1.7 – Now 8.3.4 – Structure/format – Merged requirements and moved under Requirement 8.3. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.1.6 / 8.1.7 – Now 8.3.4 – Evolving Requirement – Increased the number of invalid authentication attempts before locking out a user ID from six to 10 attempts. (Woohoo! The helpdesk is happy)
- 8.2.6 – Now 8.3.5 – Clarification/guidance – Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1
- 8.2.5 – Now 8.3.7 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.4 – Now 8.3.8 – Structure/format – Moved content about communicating user authentication policies and procedures under Requirement 8.3.
- 8.2.4 – Now 8.3.9 – Clarification/guidance – Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation).
- 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.
- 8.2.4 – Now 8.3.9 – Evolving Requirement – Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days.
- 8.2.4.b – Now 8.3.10 – Structure/format – Moved content from a former testing procedure to a requirement for service providers to provide guidance to customers about changing passwords/ passphrases.
- 8.6 – Now 8.3.11 – Structure/format – Moved requirement about authentication factors such as physical or logical security tokens, smart cards, and certificates under Requirement 8.3.
- 8.3 – REMOVED (all components covered by other requirements)
- 8.7 – Moved to 7.2.6 Discussed in previous post)
Conclusion
As you read over the list of changes to requirement 8 you will see there is a lot of them. Don’t let this intimidate you however, as a lot of the changes are changes to the control number and/or just a note to be specific about the personnel that are in scope for it (ie it shouldn’t be applied to retail workers that have access to a single payment card at a time, etc.) The areas to spend time looking into the impact of your environment are going to be mostly found in the new items. Not that you can ignore the changes to existing controls, but the new ones have some changes that from a PCI perspective would be on the fundamental level.
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 8. We will continue to work through each of the PCI requirements each week.