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.

Effectiveness of Changing Passwords

PCI Requirement 8.2.5 works in conjunction with PCI Requirement 8.2.4 to create secure passwords. Because PCI Requirement 8.2.4 requires passwords/passphrases to be changed every 90 days, PCI Requirement 8.2.5 dictates that new passwords/passphrases can’t be the same as any of the last four passwords/passphrases used. This prevents users from trying to alternate between the same few passwords or not reset their password at all by using the same password over and over again. The PCI DSS further explains, “If password history isn’t maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future.”

During an assessment, your organization’s system configuration settings will be examined to verify that parameters are in place so new passwords/passphrases can’t be the same as any of the last four passwords/passphrases used.

When we have a requirement that says that we need to change our passwords every 90 days, we find that people will try to use the last password that they had or not reset their password at all by submitting the same password that they’re already using. I can admit that even I’ve done that in the past. From an application security perspective, PCI Requirement 8.2.5 requires that you retain the last four passwords that an individual has used. When the passwords are changed every 90 days, you can’t use the last four passwords for a year. From an assessment perspective, we’re looking at the applications that you’ve developed, commercial off-the-shelf applications, authentication store, and how the password settings prevent somebody from using previous passwords.

Password/Passphrase Expiration

PCI Requirement 8.2.4 expects your organization to change user passwords/passphrases at least once every 90 days. The PCI DSS explains, “Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.” You may think that a shorter password/passphrase expiration date would be more secure, but best practice states that 90 days is an appropriate period of time. A smaller window, like 30 days, can reduce usability and cause users to choose weak passwords.

To verify compliance with PCI Requirement 8.2.4, assessors will examine a sample of system configuration settings to see that you change user passwords/passphrases at least once every 90 days. Service providers must undergo additional testing of their internal processes to see that non-consumer customer user passwords/passphrases are required to change periodically and these users are given guidance on when, and under what circumstances, passwords/passphrases must change.

If I’m Hacker Joe and I have your username and password and I’m using your account, that’s a bad thing, right? From a minimum perspective, the longest Hacker Joe should have access to any account would be 90 days. The reason for that is when we look at PCI Requirement 8.2.4, it requires that you change your password every 90 days. This really becomes a security consideration if you make it every 30 days, because people might start writing their password down just because it’s so cumbersome. They might use “Password1” and then change it to “Password2” and the next time it’s “Password3.” Every 90 days is one of those requirements that you may want to do more, but understand the implication of that and how it could play out in your environment.