According to a ConsumerCredit.com infographic, “80% of consumer spending was cashless.” So, it is no wonder that the Payment Card Industry Data Security Standard (PCI DSS) arose to develop a set of requirements that apply to companies of any size that accept credit card payments. If your company intends to accept card payment, and store, process and transmit cardholder data, you need to host your data securely with a PCI compliant hosting provider or meet very specific requirements to remain in compliance and avoid costly penalities.
PCI MFA Supplement
The PCI Security Standards Council released an Information Supplement on February 1, 2017 to address multifactor Authentication. Security Analyst George Mateaki at SecurityMetrics offers this assessment of the supplement:
“The PCI SSC wants to help secure remote user access. Remote access is still the biggest vector for an attack into sensitive data systems. But, strong MFA can keep criminals and hackers away from your systems.
This new supplement does not create any new requirements. Its intent is to provide further guidance and help people understand the underlying principles of security, so they can go the extra mile to truly protect their network. The overall security goal is clean, multi-factor authentication into a critical network/CDE, from anywhere outside of that network.
The supplement also does a great job of getting down to the details of MFA; it defines terms and compares authentication principles. It clears up some previous points of confusion, like what is really meant by “independence of factors,” “multi-step,” and “multi-factor.”
CDE refers to Cardholder Data Environment, which in terms of PCI is that equipment that has access to CDE is considered in scope for PCI compliance. A way of simplifying compliance and to minimize risk is to segregate the environment so that your CDE is isolated from your non-CDE environment. There are several ways by which you can achieve this and pass an audit by a QSA, namely physical isolation, logical isolation or compensatory controls.
In this discussion and specially since access to CDE is required as part of business as usual, it may (depending largely on the architecture of each environment) mean that we will need to have two separate sets of Application gateways one for CDE processing and another for non-CDE. It will also mean that transactions/authentications that are tied to CDE will need to be processed in a different way (e.g. using a different application than the ones used for non-CDE).
This also requires that our processing and the privacy assessment of our logs ensure that when we log data, we treat data coming from the CDE in alignment with the PCI requirements e.g. Do not log Credit Card Numbers, bank account numbers.
Finally, if the Application gateway is being used to provide access to CDE then access to it must use MFA to authenticate the user. The main concept to keep in mind at all times is that the CDE environment is treated as the higher security environment and all other environments are treated as lower security, access from outside of the CDE mandates that the access is subject to heightened security e.g. requirement 8.3 establishes a mandatory requirement for Multi-Factor Authentication to be employed when accessing CDE and recommends that MFA is used for all remote access.
In that spirit you can say that Consumer applications should use MFA but it is not mandatory to use it.
PCI DSS 3.2.1 Requirement 8.3
Since it’s early beginnings PCI has mandated strong authentication, initially as Two-Factor authentication and more recently (3 and above) explicitly requests MFA. The acceptable methods of authentication continue to be:
- Something you know: such as a password or passphrase
- Something you have: such as a token device or smartcard
- Something you are: such as a biometric
PCI/DSS 3.2.1 requirement 8.3 requires (mandatory) Multi-Factor Authentication for access to the CDE for all non-console access, it also recommends the use of MFA for all remote access to the Customer networks.
Now this gives origin to a common argument we hear, namely that replacing traditional password-based implementations is expensive and the integration effort is too complex to accommodate, but regardless adhering and meeting PCI requirements this is a “must-have” for you to be compliant.
In today’s web-based application environments, all three requirements can be met and made to work without complexity. The Acceptto approach adheres to and exceeds the MFA requirement by providing an approach that renders the password or passphrase benign and implements a token that is protected by your Bio-Behavioral profile and uses biometrics to further enhance the security of your environment.
Continuous Cognitive Authentication
Acceptto is a transformative Biobehavioral AIML authentication technology delivering you continuous identity protection and peace of mind in an age where passwords are ineffective and identity authentication is mission critical.
Acceptto is built on the premise that your credentials today, and those that you’ve yet to create, have already been compromised. Your identity cannot simply be based on a password or a one-time token or only your biometrics. Your immutable identity is a combination of your physical behaviors, attributes and Digital DNA.
We call it Continuous Cognitive Authentication. You can eliminate preventable harm with our Biobehavioral AIML technology that enables frictionless authentication, prevents credentials stuffing instantaneously, ensures your true immutable identity continuously, and dramatically reduces risk, likelihood of fraud and cost of helpdesk operations without the guesswork or latency.
See for yourself what Acceptto can do to ensure your employees, partners and customers can authenticate without passwords and still ensure security and privacy, especially for your PCI compliance requirements. Register for a free trial today.
