Se conformer à la norme PCI DSS 3.2 : authentification multi-facteurs

Le 1er février 2018, l’exigence 8.3 de la norme de sécurité de l'industrie des cartes de paiement (PCI DSS 3.2) est entrée en vigueur, rendant obligatoire l’authentification multi-facteurs pour l’accès non-console aux ordinateurs et aux systèmes traitant les données des titulaires de cartes, et l’accès à distance à l’environnement des données du titulaire (CDE). En début d'année, le Conseil des normes de sécurité PCI avait également publié des directives pour la mise en œuvre de l'authentification multi-facteurs.

PCI DSS 3.2

La norme PCI DSS s’applique à toutes les entités impliquées dans le traitement des cartes de paiement, y compris les commerçants, les processeurs, les acquéreurs, les émetteurs et les fournisseurs de services. Elle s’applique également à toutes les autres entités qui stockent, traitent ou transmettent les données des titulaires de cartes ou les données d’authentification sensibles.

Depuis le lancement de la norme PCI DSS, deux versions majeures ont été publiées, la version 2.0 en novembre 2010 et la version 3.0 en octobre 2013. La sous-version la plus récente, la version 3.2, a été publiée en avril 2016 et introduit de nouvelles exigences considérées comme de bonnes pratiques jusqu’au 31 janvier 2018, date après laquelle elles deviendront des exigences obligatoires. Ces changements permettent de s'assurer que les normes sont à jour par rapport aux nouvelles menaces et aux évolutions du marché. Le changement le plus important porte sur la révision de l’exigence 8.3 concernant l’authentification multi-facteurs.

Certains de ces changements font suite à des incidents majeurs de piratage informatique aux États-Unis, notamment les violations des données de Target et Home Depot, où des pirates ont obtenu des noms, des numéros de cartes de crédit et d’autres informations sur des millions de personnes. À elle seule, la violation de données dont Target a été victime en 2013 a compromis les informations des cartes de paiement de 40 millions de clients et en a partiellement exposé 70 millions d’autres. Après une longue enquête, Target versera 18,5 millions de dollars pour manquement aux règles de sécurité. La chaîne de magasins de détail a dépensé 202 millions de dollars en frais de justice et autres coûts depuis cette violation des données.

Exigence 8.3 et authentification multi-facteurs

La première modification apportée à l’exigence 8.3 est l’introduction du terme « authentification multi-facteurs » en lieu et place de l’ancien terme « authentification à deux facteurs », puisque désormais, deux facteurs ou plus peuvent être utilisés. En changeant cette terminologie, deux facteurs d’authentification deviennent l’exigence minimale.

La seconde modification, majeure, consiste à étendre l’exigence 8.3 en deux sous-exigences, afin d’imposer l'authentification multi-facteurs à tout le personnel ayant un accès administratif non-console et à tout le personnel ayant un accès à distance à l'environnement CDE.

La nouvelle exigence 8.3.1 traite de l’authentification multi-facteurs pour tout le personnel ayant un accès administratif non-console à l'environnement CDE, où « l’accès non-console » fait référence à l’accès logique qui se produit sur un réseau plutôt que via une connexion physique directe, y compris l’accès à partir de réseaux internes ainsi que l’accès à partir de réseaux externes ou distants.

La nouvelle exigence 8.3.2 reprend l’ancienne exigence 8.3 et traite de l’authentification multi-facteurs pour tout le personnel ayant un accès à distance à l'environnement CDE. Cette exigence a vocation à s’appliquer à tout le personnel, y compris les utilisateurs généraux, les administrateurs et les fournisseurs (pour l’assistance et la maintenance) ayant un accès à distance au réseau lorsque cet accès à distance pourrait conduire à l’accès à l'environnement CDE.

Directives sur l'authentification multi-facteurs

Depuis la modification de l’exigence 8.3, le Conseil des normes de sécurité PCI a reçu un certain nombre de questions sur la manière dont les différents facteurs devraient être mis en œuvre, à la fois de la part des organisations qui prévoient de mettre en œuvre l’AMF et des évaluateurs de la sécurité qui contrôlent les mises en œuvre de l’AMF.

Pour répondre à ces questions, le Conseil a publié un Supplément d’informations - Authentification multi-facteurs version 1.0 pour clarifier les bonnes pratiques et les principes acceptés par le secteur pour une mise en œuvre de l’AMF, notamment :

• la définition, l’indépendance et la protection des facteurs d’authentification ; et
• l'utilisation abusive de facteurs multiples, y compris l’authentification en plusieurs étapes.

Dans la dernière section, le Conseil passe en revue les scénarios d’authentification courants et les considérations relatives à l’authentification multi-facteurs.

Facteurs d’authentification

L’authentification multi-facteurs impose d'utiliser au moins deux des trois facteurs d’authentification décrits dans l’exigence 8.2 de la PCI DSS :

• la connaissance, tel qu’un mot de passe, un code PIN ou la réponse à des questions secrètes ;
• la possession, comme un périphérique à jeton ou une carte à puce ; et
• l'inhérence, comme des données biométriques.

Même si cette définition est déjà bien connue par le secteur, celui-ci doit encore déployer des efforts pour savoir comment mettre en œuvre ces différents facteurs d’authentification.

Le Conseil fait également mention d’autres facteurs : « D’autres types d’informations, telles que la géolocalisation et l'heure, peuvent être ajoutés au processus d’authentification ; cependant, au moins deux des trois facteurs identifiés ci-dessus doivent toujours être utilisés. Par exemple, les données relatives à la géolocalisation et à l'heure peuvent être utilisées pour restreindre l’accès à distance au réseau d’une entité en fonction des horaires de travail d’un individu. Bien que l’utilisation de ces critères supplémentaires puisse réduire davantage le risque de détournement de compte ou d’activité malveillante, la méthode d’accès à distance doit toujours nécessiter une authentification via au moins deux des facteurs suivants : quelque chose que vous savez (la connaissance), quelque chose que vous avez (la possession) et quelque chose que vous êtes (l'inhérence) ».

Indépendance des facteurs d’authentification

L’AMF devrait être mise en œuvre avec des mécanismes d’authentification indépendants les uns des autres, afin d’éviter que l’accès à un facteur n’autorise l’accès à un autre facteur et que la compromission d’un facteur n’affecte l’intégrité ou la confidentialité d’un autre.

Voici quelques-uns des pièges décrits par le Conseil :

• Premièrement, lorsque le nom d’utilisateur est combiné au mot de passe pour accéder au réseau de l’entreprise, et que les mêmes informations d’identification donnent également accès à un compte de messagerie auquel un mot de passe à usage unique est envoyé en tant que second facteur, ces facteurs ne sont pas indépendants. Le premier facteur (nom d’utilisateur/mot de passe) donne accès au compte de messagerie et donc au deuxième facteur.
• Deuxièmement, « un certificat logiciel stocké sur un ordinateur portable (quelque chose que vous avez) qui est protégé par le même ensemble d'identifiants que celui utilisé pour se connecter à l’ordinateur portable (quelque chose que vous connaissez) peut ne pas garantir une indépendance ».
• Troisièmement, « la transmission d’un mot de passe à usage unique (OTP) à un smartphone est considérée depuis toujours comme une méthode hors bande efficace. Or, si le même téléphone est ensuite utilisé pour transmettre l’OTP - par exemple, via un navigateur Web - l’efficacité de l’OTP en tant que facteur secondaire est effectivement annulée. » Lorsque vous saisissez les identifiants sur le même appareil qui reçoit (ou stocke/génère) un deuxième facteur d’authentification, le pirate qui en a le contrôle peut saisir les deux facteurs d’authentification.

Protection des facteurs d’authentification

Pour éviter toute utilisation abusive des facteurs d’authentification, ceux-ci doivent être protégés contre tout accès et utilisation non autorisés, comme le définit l’exigence 8 de la norme PCI DSS. En outre, « lorsque des éléments d’authentification reposent sur un appareil grand public polyvalent, par exemple des téléphones mobiles et des tablettes, des contrôles doivent également être mis en place pour atténuer le risque de compromission encouru par l’appareil. »

Multi-étapes ou multi-facteurs

La norme PCI DSS exige que tous les facteurs de l’authentification multi-facteurs soient vérifiés ensemble, avant d'avoir accès au système. Si un utilisateur est en mesure de connaître le succès ou de l’échec du processus avant que tous les facteurs n’aient été soumis, le processus d’authentification global devient une authentification à facteur unique en plusieurs étapes, même si un facteur différent est utilisé pour chaque étape. Ce processus n’est pas conforme à l’exigence d’authentification multi-facteurs.

Scénarios d’authentification courants

Dans la dernière section de ce Supplément d’informations, le Conseil décrit quatre scénarios d’authentification multi-facteurs qui clarifient les différentes conditions des facteurs d’authentification et la meilleure façon de les mettre en œuvre.

Conclusion

À moins de trois mois de l’entrée en vigueur de l’exigence 8.3 de la PCI DSS, il est temps de passer à l'action. Je suis convaincu que le Supplément d’informations - Authentification multi-facteurs version 1.0 est un bon point de départ à l'heure où vous vous préparez à revoir, mettre en œuvre ou mettre à niveau vos solutions d’authentification multi-facteurs.