New Information Supplement on “Multi-Factor Authentication”

4. April 2017

With version 3.2 of the PCI DSS, the PCI Security Standards Council (PCI SSC) has further expanded its focus on strong encryption and multi-factor authentication (MFA).

Requirement 8.3 is a concrete example of this development. As of version 3.2, this requirement has been changed from
„8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).” – PCI DSS 3.1
into
„8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.” – PCI DSS 3.2
Any administrator with (internal) access to the cardholder data environment is now required to use at least two factors without using any factor twice. In February 2017, the PCI SSC published the “Guidance for Multi-Factor Authentication“ – in the following referred to as MFA Guidance – to provide further clarification on the topic. Its key points are summarised below:
Multi-factor authentication. MFA generally requires a combination of at least two factors for authentication. Valid factors are:
• Something you have (token, key, (banking) card, …)
• Something you know (password, PIN, …)
• Something you are (finger print, iris scan, voice recognition, …)
Independence of authentication methods. Independence of the factors should be ensured by ruling out that access to one factor also provides access to another factor, thus maintaining integrity and confidentiality for each of the factors used. The guidance provides two examples of how to ensure factor independence, such as out-of-band (OOB) authentication (transmission of factors via different networks or channels) and cryptographic tokens (built-in into a device or stored on removable media).
Protection of factors. In order to protect their integrity and confidentiality, the factors in use have to be protected themselves. In this regard the guidance refers to the controls defined in requirement 8 of the PCI DSS.
• Something you have: For this type of factor it is important to ensure that the factor will not be shared with unauthorised users, or come into the possession of unauthorised parties. In addition, this type of factor should be protected against reproduction.
• Something you know: This type of factor must not be easy to guess or vulnerable to brute force attacks. A high level of protection for this type of factor can be achieved through high complexity.
• Something you are: This type of factor should not be replicable. In addition, it must be ensured that other users will not be able to use this factor on devices on which these data are present.
Multi-step vs multi-factor. According to the MFA Guidance, it must remain unknown whether an individual factor has been successful within the authentication process or not. Thus, it may only be made known whether the overall authentication process (i.e. after entering all factors used for authentication) has been successful.
A multi-step authentication not recognised as multi-factor authentication by the guidance includes a factor that provides access to another factor. One instance of such a multi-step authentication not permitted by the guidance would be a process in which the user enters the first factor, comprised of user name and password, and is then prompted to enter the second factor (such as biometric data) upon successful authentication.
Viktor Ahrens & Dennis Yang
PCI & Payment Security

Any questions? Talk to us. We‘ll be happy to help you. +49 6102 8631-90. E-mail: pci@usd.de.
About the PCI Expert Tips:
With our PCI Expert Tips we would like to keep you informed about changes to the PCI Security Standards and provide you with first explanations as to what the changes entail and how they may affect you. Please take our articles always as a general reference – they do not replace individual case-by-case evaluations.

Also interesting:

3 Reasons for a Cloud Security Audit

3 Reasons for a Cloud Security Audit

Outsourcing applications and data to the cloud brings significant benefits for companies, but at the same time also new challenges for the corresponding IT departments. The technologies and processes of a cloud environment differ from those of local data centers....

usd HeroLab Top 5 Vulnerabilities 2020: SMB 1.0 & SMB Signing

usd HeroLab Top 5 Vulnerabilities 2020: SMB 1.0 & SMB Signing

During penetration tests our security analysts repeatedly uncover gateways in IT systems and applications that pose significant risks to corporate security. They increasingly identify the same vulnerabilities in different IT assets, some of which have been known for...

Categories

Categories