I have been challenged over the last few weeks over requirement 8.3.1 along with the implications of the Council’s latest Information Supplement on multi-factor authentication (MFA). Requirement 8.3.1 does not go into effect until February 1, 2018, but there are a lot of organizations trying to get a jump on it. As a result I am hearing from QSAS that they are getting more and more questions and scenarios to see if they are PCI compliant.
As a reminder, requirement 8.3.1 states:
“Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.”
The most common and biggest challenge has come from organizations that have implemented MFA across their entire network and therefore believe that they are automatically in compliance with 8.3.1.
Not so fast. The guidance for 8.3.1 states:
“If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi-factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE.”
According to this guidance, it is the cardholder data environment (CDE) that is the border for the MFA, not the network as a whole. So while an organization might have implemented MFA as part of their general security, having MFA for the entire network does not meet the requirement of 8.3.1.
We need to remember what drove the development of requirement 8.3.1 was a lesson learned from the Target and similar breaches. In all of these breaches, system administrators were spear phished allowing the attackers to access the CDE in one way or another. Requirement 8.3.1 minimizes this threat by requiring MFA to gain access to the CDE. So even if an attacker obtains an administrator’s credentials or compromises an administrator’s system, that fact in and of itself would not compromise the CDE.
This is why the guidance for 8.3.1 puts the MFA border at the CDE. If you have MFA implemented in order to gain access to your network, how does that stop the threat of phishing? It does not. A spear phishing attack against such an MFA implementation defeats the MFA because it has already been applied. The MFA in this scenario does not stop access to the CDE.
But keep in mind, MFA only minimizes the risk to administrators. You still need to be vigilant in ensuring that administrator systems remain secure and free of viruses and malware. As such, it is not unusual to find that organizations are taking more active approaches to securing administrator systems including adding other technologies such as file integrity monitoring, white listing and/or black listing in addition to anti-virus.
But it is not just administrators you need to worry about. Anyone that has access to bulk cardholder data (CHD) that is stored is also at risk. As a result, we are starting to see organizations also requiring these users to use MFA to access the CDE as well as having their systems implement enhanced security to ensure they remain uncompromised.
Just some things to think about as you got through your MFA discussions.
PCI Guru 
Great article. To be clear, accounts that don’t have access to bulk cardholder data (can access only singly – e.g. for an end customer’s own cc data) or have no access to cardholder data (e.g. can see many customers but only ever have access to last 4 digits of cc) would not be subject to MFA, is that right?
Yes that is correct.
I’m seeing lots of info out there regarding administrative access to systems being put behind MFA, but what about application level access? How would this impact, say, third party call center users (AOC’d) accessing an application remotely?
From a PCI DSS perspective, user access is not included because users such as call center personnel only come into contact with CHD one at a time. The whole reason for the MFA requirement is to stop attackers from phishing anyone with access to bulk CHD (typically administrators, but not always). That is why I recommend that all users that have access to bulk CHD use MFA to gain access.
Would a persistent VPN connection from an MSSP meet two factor with certificates and user name / password to the SIEM?
I am thinking that enabling SSH MFA would provide better diligence.
Remote access is still remote access even over a permanent connection regardless of how it is secured. And with the advent of MFA being required for remote console access in January 2018, you really will not have a choice anyway.
There no users on a site-to-site VPN. It is just like an IPSec tunnel on a firewall.
So I am unsure as to how that can be implemented for an MSSP that manages / monitors SIEM.
https://polldaddy.com/js/rating/rating.js
Do you have an Attestation Of Compliance (AOC) from the MSSP for the SIEM management/monitoring services? Then you should be fine. If not, then you will need to include them in your assessment for those services.
Scenario 4 of Multi-Factor-Authentication-Guidance-v1 from the council does not support your contention. MFA into the network followed by an additional password into the CDE is acceptable.
It might be acceptable to the Council, but is it really secure for the rationale I discuss?
Would you please clarify how your article affects, or does not affect, an organization who uses MFA for access to all servers and network devices and not just those in the CDE? I understand your comments in the context of remote access to the internal network being a single-time use of MFA so something else is needed for the CDE.
For example, if time-based single-use tokens that change every minute are used for administrative access to every device independently regardless of whether it is CDE or not, does that meet the requirements? So not an MFA to a jump box but MFA to everything by itself.
In your example (I am assuming you are including network gear as well as servers), you would be PCI compliant because you are enforcing MFA when you are accessing ANY device. Most organizations avoid such a MFA solution, but some do not.
PCI Guru,
I have recently discovered your blog and enjoyed it immensely. I greatly appreciate the wealth of information you provide here and wish you continued success within the QSA community and on this blog in particular.
Thank you,
Chad
I appreciate the compliments. Thanks.
Great article, small typo, “threat of phishing? I does not.” probably should be ‘It does not.’
Thanks.