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.