Service Providers with Remote Access to Customer Premises Must Use Unique Authentication Credential for Each Customer

Multiple Customers, Multiple Authentication Credentials

The PCI DSS has several requirements that are specific to service providers, including PCI Requirement 8.5.1, which states, “Service providers with remote access to customer premises must use a unique authentication credential for each customer.” PCI Requirement 8.5.1 prevents the compromise of multiple customers through the use of a single set of authentication credentials; if a malicious individual compromises an account, they could compromise more if only one authentication credential is used.

The PCI DSS also notes, “This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

The PCI DSS has several requirements that are specific to service providers. If your organization is a service provider, you need to use unique authentication credentials for each of your customers. This means that if you have five clients, you use unique authentication credentials for each one. The purpose and intent behind this is if Hacker Joe is able to compromise Account 1, we want to prevent him from compromising Accounts 2, 3, 4, and 5. To limit this type of vulnerability, it’s required that you use unique authentication credentials for each customer.

From an assessment perspective, this entails examining your policies and procedures, and interviewing staff so that we understand that they understand what’s required about using unique authentication credentials.

Do Not Use Group, Shared, or Generic Authentication Methods

PCI Requirement 8.5 cautions, “Do not use group, shared, or generic IDs, passwords, or other authentication methods.” It also outlines the following requirements:

• Generic user IDs are disabled or removed.
• Shared user IDs do not exist for system administration and other critical functions.
• Shared and generic user IDs are not used to administer any system components.

Group, shared, or generic authentication methods cause a loss of accountability for the actions that have taken place within your systems and make it impossible to determine who has taken which actions. You should not use group, shared, or generic authentication methods for administrative purposes or any accounts that have access to sensitive cardholder data.

To verify compliance with PCI Requirement 8.5, a sample of user IDs should be examined to ensure your organization’s configurations are set up so that you do not use group, shared, or generic IDs, passwords, or other authentication methods. Policies and procedures will also be examined, along with staff interviews.

We started out in PCI Requirement 8.1, which says everyone needs their own unique username and password. Now we come down to PCI Requirement 8.5 that is kind of married to that. It says that we shouldn’t be using any group, shared, or generic IDs. You should not use these for administrative purposes or any accounts or service that has access to sensitive cardholder data.

One area where organizations get into trouble is with the use of root. There’s ways you can address this so that we can recreate the accountability that’s lost when more than one individual uses an account. If you have a Linux or Unix mainframe environment, when there is a root account being used, what I would recommend is using sudo to address the accountability aspect of these accounts.

From an assessment perspective, we’ll be interviewing administrative staff and talking about how to manage generic passwords. What do you do when your manager comes to you and says, “Create an account for this group of people.” We’ll also be looking at your authentication store to try and identify if you have generic accounts.

Understand that system accounts are not necessarily the same thing as a generic account. A system account is never used by an individual. These accounts are typically used for applications to run or for systems to operate and perform certain tasks. You should never have your staff logging onto these system accounts.

Understand that in the assessment process, we’re going to be asking for a list of all your authentication directories, we’re going to look at all places where you’re authenticating, all of your applications, and look to make sure you’re not sharing or using generic user accounts.

Authentication Policies and Procedures

Every single PCI DSS requirement needs documented and implemented policies and procedures. PCI Requirement 8.4 specifically requires you to document and communicate authentication policies and procedures to all users, which include:

• Guidance on selecting strong authentication credentials.
• Guidance for how users should protect their authentication credentials.
• Instructions on why not to reuse previously used passwords.
• Instructions to change passwords if there is any suspicion the password could be compromised.

Educating your personnel on proper authentication methods is vital to the security of the cardholder data you are protecting. It helps all users have the chance to understand and follow important authentication policies. The PCI DSS explains that this guidance could be suggestions on what not to do, like using dates of birth or easy-to-guess passwords, writing down passwords, or saving them somewhere insecure. Or, it could be recommendations on how to become more aware of malicious activity and prevent it.

Why does PCI Requirement 8.4 require you to document and communicate authentication policies and procedures to all users? It’s not enough just to talk about these policies or document them for the sake of an audit. An assessor will examine all of your authentication policies and procedures and training methods, as well as interview personnel to ensure that policies and procedures are implemented. Does staff know what to do if they suspect malicious activity? Do they know how to securely change their password? Can they come up with a hard-to-guess password? Assessors want to know if your personnel have an understanding of your authentication policies and procedures.

If you’ve been involved with the PCI DSS for very long, I’m sure you’re aware that every single one of these requirements has a multitude of policies and procedures that are required. PCI Requirement 8.4 says that you need to educate your staff and provide them guidance and training on methods for good and bad authentication procedures, and what they should and shouldn’t do. You need to provide your end-users with instructions so that if they ever suspect that their passwords have been compromised, they know how to change their password.

From an assessment perspective, we’re going to be reading all of your authentication policies and procedures. We’re going to look at your training program. We’re going to look at how you’ve implemented your policies and procedures. We’re going to go find Betty sitting in the kitchen and ask her to tell us about authentication policies and procedures, tell us what your company has educated you about. We’re not look for Betty to regurgitate exactly what your policies say, but we’re looking for an understanding of these things. I don’t care verbatim what the policy says, what I’m looking for is that your staff has an understanding of your intent and that they know what to do if their password has been compromised.

Remote Network Access and Multi-Factor Authentication

PCI Requirement 8.3.2 requires, “Incorporate multi-factor authentication for all remote network access originating from outside the entity’s network.” This applies to all personnel, general users, administrators, and even vendors accessing for support or maintenance – anyone coming into your environment using remote network access must use multi-factor authentication.

As PCI Requirement 8.2 describes, the three accepted forms of multi-factor authentication that comply with PCI Requirement 8.3.2 include: something you know, something you have, and something you are. Something you know is something like as a password or passphrase, something you have would be a token device, and something you are is something like a biometric.

If a network has proper segmentation and remote users cannot access or impact the cardholder data environment, multi-factor authentication for remote access to that network would not be required. However, multi-factor authentication is required for any remote access to networks with access to the cardholder data environment, and is recommended for all remote access to the entity’s networks.

If you’re originating traffic from a remote or untrusted environment, it’s required that you use multi-factor authentication to do so. The PCI DSS doesn’t really call out what technology you can and cannot use. What it effectively says, though, is that you need to use something you know, something you have, or something you are.

One of the things I would caution you against is NIST’s new guidance around using SMS text messaging for multi-factor authentication. That was deprecated. I wouldn’t be surprised if in the near future the council came out with some guidance on that as well.

Understand that this multi-factor authentication is not just required for you, it’s required for all remote access. If you have a vendor, employees, or administration staff coming into your environment from remote, they’re required to use multi-factor authentication.