Les attaquants n’ont pas besoin d’être sophistiqués lorsque des failles connues restent ouvertes. Dans son rapport 2026 Data Breach Investigations Report, Verizon a constaté que « près d’un tiers (31 %) de toutes les violations commencent par l’exploitation d’une vulnérabilité », ce qui en fait le principal point d’entrée (Verizon, 2026). Ce même rapport a révélé que seulement 26 % des vulnérabilités critiques répertoriées dans le catalogue des vulnérabilités exploitées connues de la CISA avaient été entièrement corrigées en 2025, et que le délai médian de correction complète est passé à 43 jours (synthèse Help Net Security).
La norme PCI DSS v4.0.1 considère cela comme un cycle, et non comme une tâche trimestrielle ponctuelle. Quatre exigences s’articulent entre elles : identifier et classer, corriger, analyser et réanalyser.
1. Identifier et classer (exigence 6.3.1)
Vous devez identifier les nouvelles vulnérabilités « à l’aide de sources reconnues par l’industrie pour les informations sur les vulnérabilités de sécurité » et attribuer à chacune un niveau de risque. Au minimum, ce classement doit identifier tout ce qui est à haut risque ou critique pour votre environnement, et couvrir les logiciels sur mesure, personnalisés et tiers (texte de l’exigence).
En pratique, cela implique de s’abonner aux avis des éditeurs et aux alertes des CERT nationaux, et de consulter le catalogue CISA KEV, qui répertorie les vulnérabilités confirmées comme étant exploitées dans la nature. Une vulnérabilité figurant sur cette liste mérite un classement élevé, même si son score de base paraît modéré.
2. Corriger dans un délai imparti (exigence 6.3.3)
Les correctifs critiques ou à haute sécurité doivent être installés « dans un délai d’un mois suivant leur publication ». Tous les autres correctifs applicables suivent un délai que vous définissez, par exemple dans un délai de trois mois (texte de l’exigence).
Le délai d’un mois commence à la publication par l’éditeur, et non au moment où votre équipe le remarque. Les systèmes qui ne peuvent plus être corrigés parce que l’éditeur a cessé de les prendre en charge constituent un constat permanent. Planifiez leur remplacement.
3. Analyser de l’intérieur (exigence 11.3.1)
Des analyses internes des vulnérabilités sont requises au moins une fois tous les trois mois. Les vulnérabilités à haut risque et critiques doivent être résolues et leur correction confirmée par de nouvelles analyses. L’outil d’analyse doit être tenu à jour, et les analyses doivent être réalisées par du personnel qualifié bénéficiant d’une indépendance organisationnelle (texte de l’exigence).
Deux exigences plus récentes, obligatoires depuis le 31/03/2025, relèvent encore le niveau d’exigence :
- 11.3.1.1 : les vulnérabilités inférieures au niveau élevé ou critique sont traitées sur la base de votre analyse de risque ciblée, avec de nouvelles analyses si nécessaire.
- 11.3.1.2 : les analyses internes doivent être authentifiées. Les systèmes incapables d’accepter des identifiants sont documentés, et les comptes d’analyse sont gérés comme tout compte à privilèges.
Les analyses authentifiées détectent les logiciels installés et les correctifs manquants qu’une analyse non authentifiée ne peut tout simplement pas voir. Attendez-vous à davantage de constats la première fois. C’est précisément l’objectif.
4. Analyser de l’extérieur (exigence 11.3.2)
Des analyses externes sont également requises au moins une fois tous les trois mois, par un prestataire d’analyse agréé (ASV) du PCI SSC, jusqu’à ce que les critères de réussite définis dans l’ASV Program Guide soient respectés. Les analyses internes et externes sont également requises après tout changement significatif (11.3.1.3 et 11.3.2.1).
Les écueils fréquents
- Analyser sans processus de classement des risques, de sorte que personne ne sait quels constats doivent être corrigés en priorité.
- Corriger sans réanalyser, de sorte qu’il n’existe aucune preuve que la correction a fonctionné.
- Un trimestre manqué. Quatre analyses réussies par an sont attendues, et un manquement est difficile à justifier lors de l’évaluation.
- N’analyser que ce qui figure dans l’inventaire des actifs, alors que cet inventaire lui-même n’est pas à jour.
- Considérer le « changement significatif » comme un événement rare, alors que les changements liés au cloud et au réseau surviennent chaque semaine.
Les analyses ne sont pas des tests d’intrusion
Une analyse vérifie si une porte semble déverrouillée. Elle n’essaie pas de l’ouvrir. La norme PCI DSS exige les deux, dans des exigences distinctes. Consultez notre comparatif des analyses et des tests d’intrusion et le déroulement d’un test d’intrusion.
Ubitrak propose des analyses ASV et des analyses internes, suivies dans le portail d’audit, et Accel PCI aide les petits commerçants à respecter le cycle trimestriel. Consultez notre page tests de sécurité ou contactez-nous.
Sources
- Verizon : l’exploitation des vulnérabilités, principal point d’entrée des violations selon le DBIR 2026 (19/05/2026)
- Help Net Security : les enseignements du DBIR 2026 de Verizon
- CISA : catalogue des vulnérabilités exploitées connues
- Microsoft Learn : exigence 6 de PCI DSS (texte de l’exigence)
- Microsoft Learn : exigence 11 de PCI DSS (texte de l’exigence)
- PCI SSC : prestataires d’analyse agréés
- PCI SSC : vient de paraître : PCI DSS v4.0.1
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