PCI-DSS NTP — Exigence 10.6
Guide de conformité synchronisation horaire

1. Périmètre : quand 10.6 s'applique-t-il au CDE ?

L'Exigence 10 de PCI DSS v4.0.1 — « Enregistrer et Surveiller tous les Accès aux Composants Système et aux Données des Titulaires de Cartes » — s'applique à chaque composant système de l'environnement de données titulaires (CDE). L'Exigence 10.6 est le sous-ensemble synchronisation horaire. Elle s'applique à :

• Chaque système traitant, stockant ou transmettant des données de compte ;
• Chaque service de sécurité supportant ces systèmes (collecte de logs, SIEM, IDS/IPS, pare-feux, hôtes de rebond) ;
• Chaque système qu'un attaquant pourrait utiliser pour accéder aux systèmes dans le périmètre (postes d'administration, bastions) ;
• Les serveurs de temps des prestataires de services connectés lorsqu'ils tombent dans le périmètre CDE évalué.

Les citations de cette page reprennent la traduction française officielle du PCI SSC (traduction officielle v4.0 ; texte 10.6 inchangé en v4.0.1).

L'obligation principale se lit :

PCI DSS ne fixe aucune tolérance chiffrée ; la procédure de test de l'approche définie examine la configuration. Un hôte visiblement désynchronisé contredit l'objectif de l'approche personnalisée de 10.6.2 : « L'heure sur tous les systèmes est précise et uniforme. »

2. 10.6.1 — Technologie de synchronisation en service

La réponse d'implémentation est quasi-systématiquement NTP, plus Windows W32Time configuré en client NTP (Type=NTP). La procédure de test de 10.6.1 vérifie que la technologie est « mise en œuvre et maintenue à jour ». Les preuves que nous suggérons :

• Le démon de synchronisation est installé et activé au démarrage sur chaque système dans le périmètre ;
• Il est maintenu à jour — version du démon et niveau de correctifs, gérés au titre des exigences 6.3.1 et 6.3.3 (note d'applicabilité de 10.6.1) ;
• Il synchronise activement — chronyc tracking ou w32tm /query /status retourne un stratum inférieur à 16 et une valeur reach non nulle ;
• Si le démon est configuré mais que le système échoue à se synchroniser, traitez-le comme un écart à corriger — même si la configuration est correcte sur papier.

3. 10.6.2 — Serveurs désignés et sources approuvées

Cette sous-exigence est dense. Six vérifications pour le QSA :

Ce que « source externe acceptée par l'industrie » signifie en pratique

Le PCI SSC n'a pas publié de liste exhaustive. La norme parle seulement de « sources externes spécifiques acceptées par l'industrie » et, dans ses directives, de « serveurs de temps réputés ». Notre recommandation :

4. 10.6.3 — Protection des paramètres et données

Sous-exigence courte, qui comporte deux éléments : la limitation de l'accès, et des modifications enregistrées, surveillées et examinées. Nous les mettons en œuvre en trois couches :

1. Système de fichiers. chrony.conf ou ntp.conf appartenant à root, mode 0640 ou plus strict, situé hors de tout partage lisible par le monde. Sur Windows, les clés de registre W32Time protégées par l'ACL par défaut plus l'application par stratégie de groupe.
2. Enregistrement et examen des modifications. Toute modification des paramètres horaires sur les systèmes critiques est enregistrée, surveillée et examinée — c'est ce qu'exige 10.6.3. Ouvrir chaque modification par un ticket relu est notre recommandation en plus ; les journaux eux-mêmes sont conservés au moins 12 mois au titre de l'exigence 10.5.1 (« Conserver l'historique des journaux d'audit pendant au moins 12 mois »).
3. Authentification du canal. Non exigée par 10.6.3. En mesure de durcissement (notre recommandation), authentifier la source amont des serveurs désignés : NTS (RFC 8915) ou clés symétriques (RFC 8573), ces dernières étant l'option que mentionnent les directives PCI de 10.6.2 (« chiffrer les mises à jour avec une clé symétrique »). Avec des clés symétriques, documentez la rotation et le stockage — selon notre expérience, des clés en clair dans le dépôt de configuration sont une faiblesse classique.

5. Topologie de référence pour un CDE conforme 10.6

La forme que nous recommandons :

           ┌─────────────────────────────────────────┐
           │  Externe (sources acceptées par l'industrie) │
           │  ───────────────────────────────────────  │
           │  • NIST time.nist.gov     (UDP 123)         │
           │  • Cloudflare NTS, Netnod NTS               │
           │    (UDP 123 + TCP 4460 NTS-KE)              │
           │  • Stratum 1 GNSS         (UDP 123)         │
           └─────────────────┬───────────────────────┘
                             │ Sortie UDP 123 + TCP 4460 (NTS-KE) restreinte
                             │ aux serveurs désignés seulement (FW)
                             ▼
           ┌─────────────────────────────────────────┐
           │  Serveurs de temps centraux désignés      │
           │  ───────────────────────────────────────  │
           │  ntp-cde-a.internal  (chrony 4.x, NTS)    │
           │  ntp-cde-b.internal  (chrony 4.x, NTS)    │
           │  ── peering mutuel ──                     │
           └─────────────────┬───────────────────────┘
                             │ UDP 123 interne uniquement
                             │ vers ntp-cde-a/b
                             ▼
           ┌─────────────────────────────────────────┐
           │  Systèmes dans le périmètre CDE           │
           │  ───────────────────────────────────────  │
           │  Apps paiement · BDD · Pare-feux · SIEM   │
           │  Bastions · IDS · Authentification        │
           └─────────────────────────────────────────┘

Deux serveurs désignés (notre recommandation pour la résilience ; 10.6.2 exige un ou plusieurs serveurs), en peering mutuel, alimentés uniquement par des sources externes acceptées par l'industrie, avec un cloisonnement firewall strict entre couches.

6. Pièces de preuve pour l'évaluation QSA

À rassembler dans pci-dss/req-10.6/ avant l'évaluation :

1. Schéma. La topologie à trois niveaux ci-dessus avec hostnames et IPs réels.
2. Config des serveurs désignés. chrony.conf des deux serveurs désignés, anonymisée.
3. Échantillon interne. chrony.conf / export W32Time d'un échantillon représentatif de systèmes dans le périmètre (bases de données, serveurs applicatifs, pare-feux, bastions).
4. Règles firewall. Export des règles de sortie restreignant UDP 123 + TCP 4460 (NTS-KE) aux serveurs désignés uniquement.
5. Document sources approuvées. Une page listant chaque source amont et la justification « acceptée par l'industrie ».
6. État de synchronisation. Sortie de chronyc tracking et chronyc sources sur chaque serveur désigné, datée dans la fenêtre d'évaluation. Cette sortie montre un instant ; pour couvrir toute la fenêtre, le rapport mensuel scellé de conformité NTP (Time Evidence) de RDEM Systems mesure l'offset en continu, de l'extérieur des serveurs désignés, et scelle chaque mois à son émission.
7. Preuve NTS. Si NTS est utilisé, preuve de validité des certificats et procédure de rotation.
8. Historique des changements. Journaux montrant que les modifications des paramètres horaires sur les systèmes critiques sont enregistrées, surveillées et examinées (10.6.3), conservés au moins 12 mois (10.5.1) ; export ticketing en plus si vous utilisez des tickets.
9. Rapport de test. Sortie du Validateur NTP en ligne contre chaque source externe — strate, écart, verdicts NTP et NTS — collectée dans la fenêtre d'évaluation ; le refID vient de votre propre chronyc sources.

7. Ce qui change sur le plan NTP : v3.2.1 (10.4) → v4.0 / v4.0.1 (10.6)

PCI-DSS v3.2.1 plaçait l'exigence de synchronisation horaire en 10.4 avec trois sous-exigences. v4.0 l'a déplacée en 10.6 ; le Summary of Changes de la v3.2.1 à la v4.0 du PCI SSC classe le passage de 10.4 à 10.6.1–10.6.3 comme un déplacement et une réorganisation, changement de structure ou de format, et non comme une exigence évolutive. Le fond est inchangé ; des éléments qui figuraient dans les procédures de test v3.2.1 sont passés dans le texte de l'exigence :

Si votre dossier de preuves v3.2.1 est solide, la transition v4.0 est essentiellement un re-étiquetage (10.4.x → 10.6.x) : la liste des sources approuvées et la vérification du peering étaient déjà attendues en v3.2.1.

8. Réutilisation inter-référentiels

Un dossier de preuves 10.6 peut servir de point de départ aux preuves de synchronisation d'horloges des autres référentiels ; le texte propre à chaque référentiel doit être vérifié :

Les cellules NIS 2 citent le règlement d'exécution (UE) 2024/2690, qui ne s'applique qu'aux catégories d'entités numériques énumérées à son article 1er.

Voir aussi : Référentiel ANSSI / OIV / loi REC pour le cadre français, et MiFID II — synchronisation des horloges (RTS 25) pour le secteur financier.

Lorsque les preuves pour le QSA sont mieux produites et tenues à jour en service, RDEM Systems opère la synchronisation et constitue le dossier de traçabilité documenté vers UTC — voir l'audit de traçabilité vers UTC.

Autre angle ? Utilisez l'outil adapté :

• Mesurer jitter, offset, latence → ntp-tester.eu
• Diagnostiquer firewall / port 123 / démon → check-ntp.net
• Architecture de référence entreprise → ntp.rdem-systems.com