New PCI MFA Guidance

On February 9, 2017 the PCI SSC released a new Information Supplement Multi-Factor Authentication with the intent to aid Organizations in meeting Requirement 8.3.

One interesting quote in the document’s Overview:

While PCI DSS Requirement 8.3 does not currently require organizations to validate their MFA implementation to all the principles described in this guidance document, these principles may be incorporated in a future revision of the standard. Organizations are therefore strongly encouraged to evaluate all new and current MFA implementations for conformance to these principles.

With that in mind, let us take a look at what the Supplement actually contains.

Authentication Factors

The Council provides the same definitions everyone is used to seeing (something you know, something you have, and something you are). Requirement 8.2 requires at leasttwo of these factors. The Council noted that information like time restrictions or geolocation information can help reduce risk, they do not count towards the 2/3 factor requirement.

Independence of Authentication Mechanisms

This is an important note that may be overlooked.

The authentication mechanisms used for MFA should be independent of one another such that access to one factor does not grant access to any other factor, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor. For example, if the same set of credentials (e.g., username/password) is used as an authentication factor and also for gaining access to an e-mail account where a secondary factor (e.g., one-time password) is sent, these factors are not independent

OTP via email are a fairly common option for MFA, but in order to satisfy Requirement 8.2, You cannot rely on network credentials and a OTP sent to the corporate email. Out-of-Band Authentication is a good way to isolate the authentication factors. The Council also refers back to some NIST Special Publications for use of cryptographic tokens (both embedded and removable).

Multi-Step vs. Multi-Factor

I found this section to be interesting, especially as I started to think about the accounts in my day-to-day life that fail this Multi-step process. Essentially, all authentication factors should be submitted/failed together. The “user” should not be able to submit (test) a user name and password before providing a second factor. If this authentication is to happen in stages (steps), then “no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented.” The Council points out that if this is not the case, than an attack is simply facing several single authentication factors, rather than the intended MFA.

Use of SMS for Authentication

The Council concludes the Information Supplement with a bit of warning:

While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice has been deprecated and may be removed from future releases of their publication.

This potential change from NIST will make waves in just about every industry, as most consumer services that offer any form of MFA almost all offer SMS as a second factor. Universal 2nd Factor (U2F) provides us with a bit of hope here. This open standard has been gaining more traction and offers a wide range of solutions for gaining that added assurance during user authentication. These developments will certainly be worth keeping an ear to the ground.

As always, I am interested in your feedback. I am interested in hearing what folks think about the implications, both for entities under PCI scrutiny, as well as potential runoff to other regulating bodies. Feel free to reach out on any of the social networks below!