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.

Multi-Factor Authentication and Administrative Access

PCI Requirement 8.3.1 states, “Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.” This requirement, new to PCI DSS v3.2, applies to all personnel with administrative, non-console access to the cardholder data environment, but to application or system accounts performing automated functions. When someone with administrative privileges is attacked, it can be detrimental to your organization. So, whether you’re coming from a trusted or untrusted environment, if you’re going to be making administrative changes from non-console access, you must use multi-factor authentication.

PCI Requirement 8.2 describes three forms of multi-factor authentication that comply with PCI Requirement 8.3.1: 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 or smart card, and something you are is something like a biometric.

PCI Requirement 8.3.1 is a new requirement that was established for PCI DSS v3.2. This requirement requires that any time your organization accesses your cardholder data environment for administrative purposes, you use multi-factor authentication to do so. Previously, multi-factor authentication was only required when you would originate your traffic from a remote or untrusted environment. This new requirement states that whether you’re coming from an untrusted environment or your own corporate environment, if you’re going to be making administrative changes from non-console access, you must use multi-factor authentication.

What is Multi-Factor Authentication?

PCI Requirement 8.3 states, “Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.” But what is multi-factor authentication? According to the PCI DSS, multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted. This provides additional security and assurance that the person attempting to gain access is who they claim to be.

PCI Requirement 8.2 describes three forms of multi-factor authentication that comply with PCI Requirement 8.3: something you know, something you have, and something you are. Something you know is something like as a password or passphrase. How many times have you entered a PIN after swiping your debit card this week? Your PIN is something you know. Something you have would be a token device or smart card. Has a website ever texted your phone a one-time password in order to gain access? That one-time password is something you have. Something you are is something like a biometric. Do you use facial recognition or a scan of your fingerprint to unlock your smartphone? Your fingerprint is something you are. The PCI DSS explains, “These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used).”

It’s important to note that, “Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component.”

PCI Requirement 8.3 has several sub-requirements to it, but effectively, it states that if you’re coming into the cardholder data environment from remote access or an untrusted environment, you need to use multi-factor authentication.

Unique Value for First-Time Use and Resets

PCI Requirement 8.2.6 states, “Set passwords/passphrases for first-time use and upon reset to a unique value for each and change immediately after first use.” There are two elements to PCI Requirement 8.2.6 compliance. First, whenever a new account is being set up or reset, it needs to be given a unique value. Why? The PCI DSS explains, “If the same password is used for every new user, an internal user, former employee, or malicious individual may know or easily discover this password, and use it to gain access to account.”

The second step is to immediately change the password after the first use. Consider this scenario: a member of administrative staff has set the password for a new account and has provided the password to the end-user. Now, two people know that password. This is why PCI Requirement 8.2.6 requires users to immediately change the password after the first use.

During an assessment, your organization’s password procedures will be examined and security personnel should be observed to ensure that passwords/passphrases for first-time use and upon reset have been set to a unique value.

When you’re setting a password for your staff in your environment, PCI Requirement 8.2.6 requires when you’re initially setting a password for the first time or if you’re resetting it, that password needs to be set to a unique value. It’s also required that the password be changed when it’s used for the first time. If I know, from an attacker’s perspective, that your infrastructure always sets the initial account password to “Password123,” then all I have to do is lock the account and then I know that password is going to be set to “Password123.” We look to see that passwords are set to a unique value.

When you have administrative staff set that password and provide the password to the end-user, there are now two people who know that password. So, we require that when the end-user logs into that system or uses that password for the very first time, the application requires them to reset the password.

From an assessment perspective, we look at the configurations of your systems to make sure it’s forcing those passwords to be reset when they’re first deployed or first used.