PCI Standards , Standards, Regulations & Compliance

Making Sure You're PCI DSS 3.2 Compliant? MFA to the Rescue

Security frameworks are crucial in securing how personal and sensitive data, including health information and financial data, is handled. We can thank HIPAA for offering some level of protection for our personal health information, but we also have the Payment Card Industry Data Security Standard (PCI DSS) to thank for securing consumers' financial data.

It's nice to know that businesses handling our financial data are required to comply with this standard, especially in this day and age where cyber threats are lurking around every corner. Today, I want to take a closer look at the PCI DSS 3.2 standard, starting with Requirement 8 and gradually making our way to Requirement 8.3.2.

PCI DSS 3.2 Requirement 8 starts off by ensuring a unique ID is assigned to each person with computer access. This makes sense as you don't really want multiple people logging into a computer system with the same account. If your business doesn't currently have unique logins for each user, I strongly suggest implementing unique accounts even if you don't need to be PCI DSS compliant. Uniquely identifying users is simply a Security 101 best practice.

Homing in on Requirement 8.3, we see the need to secure all individual non-console administrative access and all remote access using multi-factor authentication (MFA) when accessing the sensitive data. The standard specifically uses CDE, or the cardholder data environment, instead of "sensitive data," but the concept is the same - make sure the person requesting access is truly who they claim to be. This essentially means that any login account must have MFA enabled in order to even have access to the CDE. "Non-console" here can get a bit technical, but for all intents and purposes, consider ANY standard login session to require MFA. This includes a user physically signing into the server handling the financial data or remote users logging in for whatever reason. Console access is a different and special way to log in to a system that requires physical access but also uses a different computer terminal to do so.

Digging even deeper and taking a look at Requirement 8.3.2, the use of MFA is required for all remote access requests originating from outside the entity's network. User types mentioned here are standard users and administrators, which is somewhat the same as 8.3, but also now includes third-party access for support or maintenance. The mention of "third-party" is interesting as supply chain attacks have led to pretty serious data breaches in the past, and the explicit inclusion of "...originating from outside the entity's network". An easy way to read this requirement is that: "Any standard, administrative, or third-party user account accessing the CDE environment from a remote network should be protected with MFA."

At this point, you might be asking what MFA even is. MFA is an authentication method used to validate that a user is who they say they are, adding more security to a standard password by ensuring the user has additional pieces of information to prove who they are, hence the "multi-factor" component of its name. Going back to PCI DSS 3.2, Requirement 8.3 dictates MFA as an authentication requirement requiring at least two authentication methods and then directs readers back to Requirement 8.2 for descriptions of these authentication methods. Requirement 8.2 explains authentication as:

• Something you know, such as a password or passphrase;
• Something you have, such as a token device or smart card;
• Something you are, such as a biometric

That said, complying with the PCI DSS MFA requirements means that two of the above methods must be implemented.

If you're looking for an easy-to-use MFA solution, WatchGuard's AuthPoint MFA solution is right for you. With AuthPoint, you can require users to authenticate with the AuthPoint mobile app or a third-party hardware token when logging in to a protected resource. All three authentication methods can be met with AuthPoint. For instance, when a user requests access to the CDE and enters their username's associated password (the first authentication method), a push notification is sent to that user's configured mobile device (the second authentication method). Users have the option to add unlock protections on their mobile devices, in the form a PIN or even facial recognition or fingerprint matches (the third authentication method).