For the sake of clarification the Council split requirement 8.3 into sub-requirements. However this rewording creates more fuzziness than before, even in the head of QSA’s. This newsletter aims to clarify what is meant by MFA, what is acceptable and to whom it applies.
PCI requirements for Multi Factor Authentication are already quite challenging but this could get worst (watch this video).
PCI requirements for Multi Factor Authentication are already quite challenging but this could get worst (watch this video).
MFA Characteristics
Key characteristics of MFA are:
MULTIPLE
Authentication factors must be multiple. This sounds obvious but it is not. With the previous versions of PCI DSS, we have seen QSA’s denying compliance with 8.3 to organizations using more than two-factors. « No I’m sorry guys, this is not compliant with the standard… ». This is the main reason for renaming the two-factor authentication into Multi-factor Authentication.
DIFFERENT
Authentication factors must be of different types. This is the usual blabla…
INDEPENDENT
Authentication factors must be independent. This means that access to one factor should not grant access to the others. This could be seen as the box in the box principle: Key A is used to open a box containing Key B and Key B gives access to the Holly Gray. Key A and Key B are not independent as who owns Key A and the box owns key B. Practically, if one use a first authentication factor to access a device on which other factors are stored or received then those factors aren’t independent.
More reading on independency of MFA can be found in NIST Special Publication 800-63B Digital Authentication Guideline: Authentication and Lifecycle Management (5.1.3. Out-of-Band Devices).
UNIQUE VALIDITY FEEDBACK
When multiple authentication factors are submitted to a system, it is required that the system at stake does not provide separated indication about their validity. In other words it must not be possible to gain knowledge of whether any factor is valid until all factors are presented. The critical issue is not when the validation is actually done; rather it is when feedback to the user is provided. If the user can't tell which factor failed to grant access, then you have unique validity feedback.
Note: There is no timeline for when the above NIST/PCI guidance aout independency and feedback uniqueness will come into force as mandatory requirements. So stay watchful and ready.
MULTIPLE
Authentication factors must be multiple. This sounds obvious but it is not. With the previous versions of PCI DSS, we have seen QSA’s denying compliance with 8.3 to organizations using more than two-factors. « No I’m sorry guys, this is not compliant with the standard… ». This is the main reason for renaming the two-factor authentication into Multi-factor Authentication.
DIFFERENT
Authentication factors must be of different types. This is the usual blabla…
- Something you know (e.g., password, PIN, security question challenge)
- Something you possess (e.g., ICC card, physical token, cryptographic token or private key)
- Something you are (e.g., physical biometric or behavioral biometric)
INDEPENDENT
Authentication factors must be independent. This means that access to one factor should not grant access to the others. This could be seen as the box in the box principle: Key A is used to open a box containing Key B and Key B gives access to the Holly Gray. Key A and Key B are not independent as who owns Key A and the box owns key B. Practically, if one use a first authentication factor to access a device on which other factors are stored or received then those factors aren’t independent.
More reading on independency of MFA can be found in NIST Special Publication 800-63B Digital Authentication Guideline: Authentication and Lifecycle Management (5.1.3. Out-of-Band Devices).
UNIQUE VALIDITY FEEDBACK
When multiple authentication factors are submitted to a system, it is required that the system at stake does not provide separated indication about their validity. In other words it must not be possible to gain knowledge of whether any factor is valid until all factors are presented. The critical issue is not when the validation is actually done; rather it is when feedback to the user is provided. If the user can't tell which factor failed to grant access, then you have unique validity feedback.
Note: There is no timeline for when the above NIST/PCI guidance aout independency and feedback uniqueness will come into force as mandatory requirements. So stay watchful and ready.
When is MFA required?
REMOTE ACCESS TO THE CDE
Per PCI DSS 8.3 MFA is required for all remote access that originates from outside the entity's own network, where that remote access could lead to access to the cardholder data environment. This typically applies where the access originates either from the Internet or from an “untrusted” network or system; for example, access from a third party location or access by personnel from a portable computer over the Internet.
The above requirement applies to the entity’s users, administrators and third-parties.
IT DOES NOT APPLY TO accounts used by consumers (e.g., cardholders).
INTERNAL NON-CONSOLE ACCESS
Per Req 8.3.1 non-console administrative access to the CDE originating from within the company’s internal, “trusted” network must use MFA.
The above requirement DOES NOT apply to non-administrative users nor does it apply to machine accounts, such as system or application accounts performing automated task.
Per PCI DSS 8.3 MFA is required for all remote access that originates from outside the entity's own network, where that remote access could lead to access to the cardholder data environment. This typically applies where the access originates either from the Internet or from an “untrusted” network or system; for example, access from a third party location or access by personnel from a portable computer over the Internet.
The above requirement applies to the entity’s users, administrators and third-parties.
IT DOES NOT APPLY TO accounts used by consumers (e.g., cardholders).
INTERNAL NON-CONSOLE ACCESS
Per Req 8.3.1 non-console administrative access to the CDE originating from within the company’s internal, “trusted” network must use MFA.
The above requirement DOES NOT apply to non-administrative users nor does it apply to machine accounts, such as system or application accounts performing automated task.
Resources
RSS Feed
