PCI DSS v4 a introduit un type de document que de nombreuses organisations n’avaient jamais rédigé auparavant : l’analyse de risque ciblée, souvent appelée TRA. Cela peut sembler lourd, mais une bonne TRA ne fait généralement que quelques pages. Cet article explique ce qu’est une TRA, quand vous en avez besoin et comment en rédiger une qu’un évaluateur acceptera.
Qu’est-ce qu’une analyse de risque ciblée ?
Les versions précédentes de PCI DSS fixaient des fréquences imposées pour de nombreuses activités, comme l’examen quotidien de certains journaux. La version 4 permet aux organisations de définir elles-mêmes certaines de ces fréquences, à condition de justifier ce choix. La TRA constitue cette justification. Comme l’indique le Council, « l’analyse de risque est un outil fondamental qui aide les organisations à identifier et à prioriser les menaces et vulnérabilités potentielles au sein de leur environnement. »
Il en existe deux types, décrits dans les directives TRA du Council publiées le 28/11/2023 :
- Exigence 12.3.1 : une TRA pour les exigences qui permettent une flexibilité quant à la fréquence d’exécution d’un contrôle.
- Exigence 12.3.2 : une TRA pour chaque exigence satisfaite via l’approche personnalisée, montrant comment votre propre contrôle atteint l’objectif.
Cet article se concentre sur la 12.3.1, qui s’applique à la plupart des organisations. Il s’agissait de l’une des exigences à date d’entrée en vigueur différée, devenue obligatoire le 31/03/2025.
Quelles exigences requièrent une TRA 12.3.1 ?
Une TRA n’est nécessaire que lorsque la norme indique que la fréquence est définie par l’analyse de risque ciblée de l’entité. Les praticiens citent les exigences suivantes :
- 5.2.3.1 : à quelle fréquence évaluer les systèmes considérés comme non exposés au risque de logiciels malveillants.
- 5.3.2.1 : à quelle fréquence exécuter des analyses anti-malware périodiques.
- 7.2.5.1 : à quelle fréquence revoir les accès aux comptes applicatifs et systèmes.
- 8.6.3 : à quelle fréquence changer les mots de passe des comptes applicatifs et systèmes.
- 9.5.1.2.1 : à quelle fréquence inspecter les terminaux de paiement afin de détecter toute altération.
- 10.4.2.1 : à quelle fréquence examiner les journaux des composants système à risque plus faible.
- 11.3.1.1 : comment traiter les vulnérabilités qui ne sont pas à haut risque ni critiques.
- 11.6.1 : à quelle fréquence vérifier les pages de paiement pour détecter des modifications non autorisées, si ce n’est pas chaque semaine.
- 12.10.4.1 : à quelle fréquence former le personnel de réponse aux incidents.
Tous les points ne vous concerneront pas. Par exemple, un commerçant sans terminaux de paiement n’a aucune TRA 9.5.1.2.1 à rédiger.
Ce qu’une TRA 12.3.1 doit contenir
L’exigence 12.3.1 précise le contenu. En résumé, chaque TRA doit identifier les actifs protégés, les menaces contre lesquelles l’exigence protège, ainsi que les facteurs qui influent sur la probabilité ou l’impact, et doit analyser comment la fréquence retenue traite le risque. Chaque TRA doit également être réexaminée au moins une fois tous les 12 mois et mise à jour si nécessaire.
Comment en rédiger une, étape par étape
- Indiquez l’exigence et la décision. Par exemple : « Exigence 9.5.1.2.1. Nous inspectons les terminaux de paiement de nos trois magasins chaque semaine. »
- Décrivez les actifs. Quels systèmes, appareils ou données sont concernés, et où ils se trouvent.
- Identifiez les menaces. Que pourrait-il se passer si le contrôle n’était pas effectué ? Pour les terminaux, pensez aux dispositifs de skimming (surcouches) ou au remplacement de l’appareil.
- Listez les facteurs qui influent sur la probabilité et l’impact. Accès du public, présence du personnel, couverture caméra, volume de transactions, incidents passés, scellés inviolables.
- Justifiez la fréquence. Expliquez, en quelques phrases, pourquoi la fréquence choisie réduit le risque à un niveau acceptable. Une exposition plus élevée doit impliquer des contrôles plus fréquents.
- Consignez l’approbation et la revue. Qui l’a approuvée, quand, et quand elle sera réexaminée.
Le Council fournit des modèles d’exemple dans sa bibliothèque de documents. Ils constituent un bon point de départ.
Erreurs à éviter
- Copier un modèle sans l’adapter. Les évaluateurs recherchent des éléments factuels propres à votre environnement.
- Partir à rebours de la réponse la plus facile. Une TRA qui choisit « annuellement » pour tout, sans véritable justification, ne tiendra pas.
- Oublier la revue. Une TRA que personne n’a consultée depuis deux ans attirera l’attention.
- Confondre une TRA avec une évaluation des risques d’entreprise. Une TRA est ciblée et rattachée à une seule exigence. Elle ne remplace pas votre gestion des risques plus globale.
Pourquoi cela vaut la peine de bien le faire
Une TRA bien rédigée fait plus que satisfaire l’évaluateur. Elle impose une discussion courte et honnête sur l’emplacement de vos risques réels, et elle vous fournit une trace défendable si une décision est un jour remise en question. C’est une pratique de gouvernance pertinente, que des cartes soient impliquées ou non.
Consultez notre présentation de PCI DSS pour le contexte, et nos documents d’exemple pour des exemples de la documentation attendue par les évaluateurs. Le portail Accel PCI aide à suivre les TRA et leurs dates de revue, et KW Consulting peut animer des ateliers sur les risques et rédiger des TRA avec votre équipe. Contactez-nous pour obtenir de l’aide.
Sources
Est-ce que cela s’applique à vous? Une consultation gratuite de 30 minutes relie l’exigence à vos systèmes et vous indique quoi faire ensuite.
Réserver une consultation gratuite