PCI and MFA – what it means to you
I just finished reading the PCI Guru blog post about Multi-Factor Authentication. This is found in the Payment Card Industry Data Security Standard (PCI DSS). PCI Guru Jeffrey Hall explains that requirement 8.3.1 doesn’t go into effect until February 1st, 2018. However, it states that you should:
“Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access”
CDE stands for Cardholder Data Environment. Jeffrey in his blog post states that several organizations already have MFA implemented across the entire network. Therefore, they believe that they are already compliant. Furthermore, Jeffery cites a more particular snippet of requirement 8.3.1:
“If the CDE is segmented from the rest of the entity’s network, then an administrator needs to use multi-factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication is moreover implementable at the network level or at system/application level; therefore it does not have to be both. If the administrator uses MFA when logging into the CDE network, then, they do not also need to use MFA to log into a particular system or application within the CDE.”
Jeffrey further makes his point by saying:
“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 is already applied. The MFA in this scenario does not stop access to the CDE.”
Ok, as much as I’m someone that heavily uses 2-factor authentication as well as recommends it to customers please don’t think that it’s a silver bullet. Yes, attackers have bypassed 2-factor/MFA solutions for quite some time now.
Jeffrey, your recommendation isn’t wrong. However, the logic of the explanation on why to use it for the CDE is. Yes, especially relevant, tell the customer to implement MFA for the cardholder data environment.
Rather, explain and insist to the customer to use MFA to access the cardholder environment. We need not go knee deep explaining that if the attacker uses a spear-phishing attack against the MFA implementation, which, in addition, is applied to your entire network – that somehow, spear phishing will not affect the MFA implementation that is applied to the cardholder data environment
Besides, the council has released some guidance on MFA, and you can look at it here:
I certainly liked this article from a technical perspective:
Similarly, I liked this article most from an Assessor/Security professional’s point of view:
Particularly, I love how Adam Gaydosh finishes the blog post
“While the PCI Community meeting is always good for keeping up on the latest issues, we find that now more than ever, the PCI-DSS needs pragmatism. The debates over MFA are interesting from an academic perspective, but offered little practical insight, other than the fact that folks are quite to argue a position without understanding the details. MFA is still one of the best ways to shrink an attack surface area and increase security.
This debate also shows how PCI, like any complex standard, quickly devolves into nitpicking debates over minutiae. This is particularly why hands-on technology experience is such an important skill for any PCI assessor. Finally, your auditor must have the ability to translate the intent of the standard into the operational realities of your environment.”