10
Apr
17

MFA – It Is All In The Implementation

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.

Advertisements

8 Responses to “MFA – It Is All In The Implementation”


  1. 1 Former Texas QSA
    April 12, 2017 at 3:22 PM

    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.

    • April 18, 2017 at 8:02 AM

      It might be acceptable to the Council, but is it really secure for the rationale I discuss?

  2. 3 JJ
    April 10, 2017 at 12:47 PM

    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.

    • April 11, 2017 at 6:35 AM

      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.

  3. 5 Chad
    April 10, 2017 at 10:14 AM

    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

    • April 11, 2017 at 6:35 AM

      I appreciate the compliments. Thanks.

  4. 7 donnoman
    April 10, 2017 at 7:17 AM

    Great article, small typo, “threat of phishing? I does not.” probably should be ‘It does not.’

    • April 10, 2017 at 9:44 AM

      Thanks.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

April 2017
M T W T F S S
« Mar    
 12
3456789
10111213141516
17181920212223
24252627282930

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,814 other followers


%d bloggers like this: