PCI Requirement 8.1.2 states, “Control addition, deletion, and modification of user IDS, credentials, and other identifier objects.” To meet PCI Requirement 8.1.2, there must be a formal program of control and someone within your organization must be responsible for the addition, deletion, and modification of user IDS and other credentials. Think about all of the addition, deletion, and modification that has occurred within your organization in the last year: new hires, terminations, quitting, promotions, or a change in role. You must to ensure that the privileges that an individual has been assigned are the privileges that they actually need, but those privileges do not exceed what is required by their job. Additionally, if an individual is no longer at your organization, that account must be removed.
A test of control for PCI Requirement 8.1.2 is to sample privileged user IDs and general user IDs, review the privileges that they need, and review the privileges that they have been given. This helps assessors ensure that only privileges that are documented with approval have been given to individuals.
Somebody within your organization needs to be formally responsible for managing the addition, deletion, and modification of user accounts within your environment. People are going to be coming into your environment, people are going to be leaving, people are going to be terminated, people are going to be changing roles within your environment, and we want to make sure that the privileges that they’ve been assigned are indeed the privileges that they need. However, we want to make sure that these privileges do not exceed what is required for their job. Or, if the individual is no longer within the company, that those accounts have been formally removed. Specific to PCI Requirement 8.1.2, we’re going to look to make sure that you have a program in place for managing the addition, deletion, and modification of those user accounts.
Furthermore, as part of that addition, and deletion, and modification for PCI Requirement 8.1.2, we’re going to be asking for a list of individuals that have been hired over the last period of time and we’re going to be asking for two types of users: a general, everyday user and individuals who’ve been given some type of privileged account. We’re going to take that user request list (we talked about that back in PCI Requirement 7), and we’re going to look at the permissions for these individuals that have actually been authorized. We’re then going to go look at those systems and make sure that whatever privileges that have been assigned or approved, match those that have been assigned to those individuals.
Never Share User IDs and Passwords
PCI Requirement 8.1 focuses on proper user identification management. If there’s no management of users within your system, you’ve lost accountability for the actions that take place within your systems. It’s hard to determine who has taken which actions if you cannot identify users. The PCI DSS states that having uniquely identified users, instead of using one user ID for several employees, allows organizations to maintain individual responsibility for actions and keep an effective audit trail per employee. This will also help speed up resolution and containment processes when misuse or malicious intent occurs.
We can’t stress enough how important it is to define and implement policies and procedures, but it’s especially important here. Specifically, PCI Requirement 8.1 requires organizations to define and implement policies and procedures to ensure proper user identification management. These policies and procedures should outline the measures defined in the sub-requirements of PCI Requirement 8.1:
8.1.1 – Assign all users a unique ID before allowing them to access system components or cardholder data.
8.1.2 – Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
8.1.3 – Immediately revoke access for any terminated users.
8.1.4 – Remove/disable inactive user accounts within 90 days.
8.1.5 – Manage IDs used by third parties to access, support, or maintain system components via remote access.
8.1.6 – Limit repeated access attempts by locking out the user ID after not more than six attempts.
8.1.7 – Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
8.1.8 – If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
To verify compliance with PCI Requirement 8.1, an assessor requires your organization to define and implement policies and procedures to ensure proper user identification management. An assessor will review your organization’s policies and procedures to verify that they outline processes to meet PCI Requirements 8.1.1 through 8.1.8. An assessor will also review all of the authentication that you have within your environment to verify that everyone has their own unique username and password and see if there are generic user accounts being used.
In PCI Requirement 8.1, we call out the need for everybody within your environment to have their own unique user ID. You should never share a username. The purpose and the intent behind that is because when you use somebody else’s username and password, we’ve lost accountability for the actions that have taken place. From a logging and forensics perspective, it gets pretty hard to determine who’s done what when we have multiple people using the same account. Specific to this requirement, we look to see that everybody gets their own username and password.
From an assessment perspective, what we’ll typically do is look at all of the authentication that you have within your environment and we’ll look to see that everybody has their own username and password. When looking at your authentication stores, we’re looking to see if there are generic user accounts. There are some situations where it’s hard to get away from this. For example, if you’re in a break/fix environment, you might have to use an administrator account. There are situations where you can assign privileges to individuals within your organization that give them those rights, but where this really gets sticky is when we come across the use of root, and we’ll talk about that later in subsequent requirements.
What is PCI-DSS Requirement 8?
PCI Requirement 8 focuses on two actions: identify and authenticate. These actions are critical to protecting your systems.
When the PCI DSS describes system components in its requirements, it’s referring to internal and external networks, servers, and applications that are connected to cardholder data. This could be anything from firewalls to switches to databases.
PCI Requirement 8 states, “Identify and authenticate access to system components.” Being able to identify each user in your system enables you to hold each user accountable for their actions. Assigning a unique identification to every user ensures that you know who’s taking which specific actions in your systems. Authentication ensures that whoever is accessing your system is who they say they are. If there are no security measures taken at the point of entry, during transmission, and while in storage, passwords and other authentication methods will likely become susceptible to an attacker. The actions of identify and authenticate function together to protect your system components.
PCI Requirement 8 details the following sub-requirements:
8.1- Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components.
8.1.1 – Assign all users a unique ID before allowing them to access system components or cardholder data.
8.1.2 – Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
8.1.3 – Immediately revoke access for any terminated users.
8.1.4 – Remove/disable inactive user accounts within 90 days.
8.1.5 – Manage IDs used by third parties to access, support, or maintain system components via remote access.
8.1.6 – Limit repeated access attempts by locking out the user ID after not more than six attempts.
8.1.7 – Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
8.1.8 – If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
8.2 – In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: something you know, such as a password or passphrase, something you have, such as a token device or smart card, or something you are, such as a biometric.
8.2.1 – Using strong cryptography, render all authentication credentials unreadable during transmission and storage on all system components.
8.2.2 – Verify user identity before modifying any authentication credential.
8.2.3 – Passwords must require a minimum length of at least seven characters and contain both numeric and alphabetic characters.
8.2.4 – Change user passwords at least once every 90 days.
8.2.5 – Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.
8.2.6 – Set passwords for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
8.3 – Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication.
8.3.1 – Incorporate multi-factor authentication for all non-console access into the cardholder data environment for personnel with administrative access.
8.3.2 – Incorporate multi-factor authentication for all remote network access originating from outside the entity’s network.
8.4 – Document and communicate authentication policies and procedures to all users including: guidance on selecting strong authentication credentials, guidance for how users should protect their authentication credentials, instructions not to reuse previously used passwords, and instructions to change passwords if there is any suspicion the password could be compromised.
8.5 – Do not use group, shared, or generic IDs, passwords, or other authentication methods.
8.5.1 – Service providers with remote access to customer premises must use a unique authentication credential for each customer.
8.6 – Where other authentication mechanisms are used, authentication mechanisms must be assigned to an individual account and not shared among multiple accounts or physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
8.7 – All access to any database containing cardholder data is through programmatic methods, only database administrators have the ability to directly access or query databases, and application IDs for database applications can only be used by the applications.
8.8 – Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
It’s important to note that the PCI DSS states PCI Requirement 8 applies to all accounts, including point-of-sale accounts, with administrative capabilities, as well as all accounts used to view cardholder data, access cardholder data, or access systems with cardholder data. This includes accounts used by vendors and other third parties, but does not apply to accounts used by consumers. However, the PCI DSS states that PCI Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 do not to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction, such as a cashier account.
Passwords, user IDs, two-factor authentication, policies and procedures, and cryptography are all elements that factor into PCI Requirement 8, but the most important actions to remember are identification and authentication. Remembering to identify and authenticate in every area of your access control process will mature and secure your system components.
PCI Requirement 8 is about authentication. When we looked at PCI Requirement 7, we were focused on authorizing individuals to have access into specific areas of your environment or have access to assets. We get to PCI Requirement 8, and it’s focused on making sure that whoever it is that’s authenticating access to those assets are who they say they are, which we’ll talk about in the subsequent videos.
There are a couple of things that you need to be aware of as part of the password management and password requirements. I want you to take a moment and read the preamble to PCI Requirement 8. There are certain accounts and certain people that these password requirements may not apply to, such as individuals that would have access to one bit of cardholder data at a time, perhaps somebody at a register. So, all of these password requirements would not necessarily apply to those individuals. You might have call center agents that only interact with one piece of cardholder data at a time; a portion of these requirements may not apply to them. If you have any questions about this, I recommend you spend some time with your assessor and read that preamble to PCI Requirement 8 to understand how this may or may not apply to you in your specific situation.
Documentation for Restricting Access to Cardholder Data
PCI Requirement 7 states, “Restrict access to cardholder data by business need to know.” Complying with PCI Requirement 7 is critical to ensuring that cardholder data is accessed only by authorized personnel. For this requirement, we’ve discussed access control systems, how to define access needs, limiting privileges based on business need to know, and how to further protect your cardholder data environment. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 7.3.
PCI Requirement 7.3 states, “Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be implementing what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are. If PCI Requirement 7.3 is not met, your systems could be left vulnerable.
Finally, we come to the last requirement within PCI Requirement 7, the capstone, as we’ve been calling it. This requirement, once again, requires that you have policies, procedures, and standards around maintaining user authorization within your environment. It covers the role-based access controls. From an assessment perspective, your assessor should be looking at the policies, looking at the procedures, interviewing staff, and making sure that whatever you’ve documented from a policies and procedures standpoint has been implemented within your environment.
What is a Default “Deny-All” Setting?
PCI Requirement 7.2.3 requires that your organization’s access control systems are set to a default “deny-all” setting, which means that no one is granted access, unless it’s explicitly assigned to someone. Some access control systems are set to a default “allow-all” setting, but PCI Requirement 7.2.3 requires yours is set to a default “deny-all” setting. This ensures no one is granted access unless a rule or authorization is established that specifically grants access, rather than permitting access unless a rule is written to specifically deny access.
A default “deny-all” setting is the starting point of authorization for access control systems. Access control systems are vital to the security of your cardholder data environment because they help automate the process of restricting access and assigning privileges. Without PCI compliance access control systems, your organization could unknowingly grant access to the cardholder data environment to an unauthorized user.
During a PCI assessment, your system settings and relevant documentation will be examined to verify that your access control systems have a default “deny-all” setting in place.
When you implement an application, whether it be an application that you develop within your environment or an application that you purchase, you want to make sure that the starting point for authorization, from the application perspective, is at default “deny-all” setting, meaning that there should be no permissions granted to any individuals, unless it’s been explicitly assigned to somebody. The reverse of that is everybody has permission and you take away stuff that they shouldn’t have.
Once again, the applications that you implement need to be able to support default “deny-all” settings.
