Understanding Multi-Factor Authentication for PCI Compliance

Understanding Multi-Factor Authentication for PCI Compliance

The PCI Data Security Standard (PCI DSS) has required multi-factor authentication (MFA) since its earliest versions. With the recent updates to PCI DSS v3.2 published in 2016, organizations are also required to enforce MFA for administrators with non-console administrative access to the cardholder data environment (CDE). This is under requirement 8.3. This new standard will be enforced starting February 1st, 2018.

Not all merchants are impacted by MFA. The requirement depends on the design, business processes and SAQ category of the environment.

The PCI Security Standards Council found that insecure remote access is the #1 point of entry for attacks against brick-and-mortar merchants. Securing this attack vendor is a top priority.

Aside from PCI requirements, using MFA for remote access is now accepted as a general security best practice. Consider that 81% of hacking-related breaches leveraged either stolen and/or weak passwords according to the PCI Security Standards Council. Requiring MFA would prevent remote attackers from gaining access to your network or email system by guessing weak passwords. Once an attacker is in with a normal user account, they can gather network information and pivot to gain elevated privileges. MFA would mitigate this risk.

What is Multi-Factor Authentication?

MFA is most commonly implemented by requiring users to respond to a notification on their mobile phone from an app after entering their Windows password successfully. Other common methods include receiving a phone call or SMS (text) message.

Note that NIST is no longer recommending MFA Using SMS or phone calls, because of their many insecurities. PCI leverages the NIST standards and is also discouraging use of SMS or voice.

A traditional and more low-tech approach is to require users to carry around a token on their keychain that displays a 6-digit code that changes every 30 seconds. When prompted, the users must manually enter this 6-digit code. This method is still popular in office areas where mobile devices are prohibited or with limited Internet or cellular data access.

What is Non-Console Access?

“Non-console” access is related to IT admins performing administration or management tasks over the network whether remotely, from the internal network or from the CDE itself. It is called non-console administrative access since the IT administrator is not physically present at the system’s console interacting via the local screen and keyboard.

For example, remote desktop, web-based management tools, VPN, virtual desktop infrastructure (VDI), Secure Shell (SSH) or other remote management or support software would fall into this category of requiring MFA. This pertains to internal IT staff as well as any third-party IT support personnel which supports or has administrative access to the CDE.

What about Support or Management Servers?

Many environments will have some support servers that aren’t considered directly a part of their CDE. These servers are often on a DMZ network which connects to both workstations both inside and outside of the CDE. The new PCI requirements clarify that while these servers are in scope for PCI because they affect the security of the CDE. As a result, these systems should require multi-factor authentication for non-console (remote desktop) access. Depending on an environment’ network design, this may require MFA be required on the majority of servers for a midsize organization.

Tips for Implementation

The first step is to consolidate the scope of administration as much as possible. After gaining an understanding of the impacted administrative roles, the tools and methods of system administration used and all routes of access into the CDE, a merchant’s next step should be to simplify, centralize and consolidate administrative accounts, activity and CDE entry points. This could require preventing the use of shared service accounts or further restricting access into the CDE from untrusted public or internal networks.

Third-Party Management

If using a third-party to handle or process credit cards, stay up to date on their progress for rolling out MFA. Merchants should be assured the providers will meet the deadlines or else the merchants will fall out of compliance.

Look out for vendors that have remote access setup to support the terminals they provide or support other parts of the CDE. These entry points require MFA. Merchants should also talk with their vendors to make sure remote access is only turned on when needed, monitored when it is active and that multi-factor authentication (MFA) is in use.

What Solutions are Available?

Fortunately, the MFA solution market is mature. For organizations which use Office 365, reviewing Azure Multi-Factor Authentication as part of the Office 365 ecosystem makes a lot of sense. The Network Policy Server (NPS) extension for Azure MFA adds cloud-based MFA capabilities to a VPN or Remote Desktop Gateway infrastructure using an internal NPS (RADIUS) server.

If Azure MFA does not meet your requirements, strong and flexible solutions are available from other vendors such as Duo.

If you are interested in learning more about MFA and PCI compliance, contact us to connect with our team.

Teams security and compliance demo