Ce que chaque référentiel exige vraiment sur l'heure
ISO 27001, PCI-DSS, NIST, CIS, ANSSI, DORA, NIS 2, MiFID II
Normes de protocole, recommandations publiées et exigences légales sont trois choses différentes. Voici le texte de chacun, vérifié à la source.
1. Trois sortes de textes, trois sortes d'obligations
Trois familles de documents parlent de l'heure, et elles n'obligent pas de la même façon :
- Les spécifications de protocole — les RFC de l'IETF (RFC 5905 pour NTPv4, RFC 8915 pour NTS). Elles disent comment fonctionne le protocole ; elles n'obligent personne à s'en servir. Voir les textes qui définissent NTP.
- Les référentiels et recommandations de sécurité — ISO/IEC 27001, NIST SP 800-53, CIS Controls, guides de l'ANSSI. Ils n'engagent que ceux qui les adoptent, ou dont un contrat ou une certification y renvoie.
- La réglementation — PCI-DSS par contrat avec les réseaux de cartes ; DORA, NIS 2 et MiFID II par le droit de l'Union, chacun pour son périmètre.
La réponse courte à la question qu'on nous pose le plus : aucun de ces textes n'exige de serveur stratum 1, ni de NTS, ni même le NTP par son nom. Ils exigent des horloges synchronisées, la plupart une référence traçable à l'UTC, certains plusieurs sources. MiFID II est le seul cas où les paliers de précision les plus serrés rendent une référence locale nécessaire en pratique.
2. Les textes, clause par clause
| Référentiel | Clause | Ce qu'il dit | Ce qu'il ne dit pas |
|---|---|---|---|
| PCI-DSS v4.0 | Exig. 10.6.1–10.6.3 | 10.6.1 : horloges synchronisées « à l'aide d'une technologie de synchronisation ». 10.6.2 : serveurs de temps désignés ; eux seuls reçoivent l'heure de sources externes ; heure « basée sur le temps atomique international ou l'UTC » ; mises à jour uniquement depuis « des sources externes spécifiques reconnues par l'industrie » ; s'il y a plusieurs serveurs désignés, ils se synchronisent entre eux ; les systèmes internes ne prennent l'heure que chez eux. 10.6.3 : accès aux données de temps restreint ; modifications des réglages horaires des systèmes critiques « journalisées, surveillées et revues ». | Aucun protocole, aucune strate, aucune précision, aucune méthode d'authentification. Vérifié sur le SAQ D officiel v4.0 (avril 2022) ; citations traduites par nous. Guide |
| NIST SP 800-53 Rev. 5 | AU-8, SC-45, SC-45(1), SC-45(2) | AU-8 : horodatage en UTC (ou avec un décalage fixe ou indiqué), à une granularité définie par l'organisation. SC-45 : synchroniser les horloges au sein des systèmes et entre eux. SC-45(1) : comparer à une source de temps faisant autorité, définie par l'organisation, et resynchroniser au-delà d'un écart défini par l'organisation. SC-45(2) : une source secondaire « dans une autre région géographique ». | AU-8(1) et AU-8(2) sont retirés — déplacés vers SC-45(1) et SC-45(2). Granularité et source sont laissées à l'organisation. La seule référence citée est la RFC 5905. |
| CIS Controls v8 | Mesure 8.4 | « Configurer au moins deux sources de temps synchronisées sur les actifs de l'entreprise, lorsque c'est possible. » Groupes de mise en œuvre 2 et 3. | Aucune strate, aucune précision, aucune authentification. |
| ANSSI | Guide « architecture d'un système de journalisation » v2.0 (28/01/2022), R5 et R4 | R5 : « Les horloges des équipements doivent être synchronisées sur plusieurs sources de temps internes cohérentes entre elles. Ces dernières peuvent elles-mêmes être synchronisées sur plusieurs sources de temps externes fiables, sauf dans le cas particulier de réseaux physiquement isolés. Si NTP est utilisé, il est recommandé d'utiliser la même version du protocole sur l'ensemble du SI. » Le guide recommande une précision minimale à la seconde. | Le guide accepte explicitement des serveurs internes calés sur du matériel spécifique ou sur des serveurs publics d'Internet : pas de stratum 1 sur site, pas de NTS. Guide |
| DORA | RTS (UE) 2024/1774, art. 12(2)(f) | Les garanties de journalisation comprennent « la synchronisation des horloges de chacun des systèmes de TIC de l'entité financière sur une source de temps de référence fiable et documentée » (notre traduction du texte anglais). | Aucun protocole, aucune strate, aucune précision ; le règlement lui-même ne fixe aucun seuil d'horloge. Guide |
| NIS 2 | Règlement d'exécution (UE) 2024/2690, annexe, point 3.2.6 | Des sources de temps synchronisées sur les systèmes, lorsque c'est faisable, pour corréler les journaux. S'applique aux fournisseurs d'infrastructure et de services numériques listés dans ce règlement — pas à toute entité NIS 2. | La directive elle-même (art. 21) ne parle pas de l'heure. Aucune durée de conservation, aucune strate, aucune authentification. Point 3.2.6 lu via une source secondaire : vérifiez le texte sur EUR-Lex. Guide |
| ISO/IEC 27001:2022 | Annexe A, mesure 8.17 (A.12.4.4 en 2013) | Les horloges des systèmes de traitement de l'information sont synchronisées sur des sources de temps approuvées ; l'ISO/IEC 27002:2022 en donne les recommandations de mise en œuvre. | Les textes ISO ne sont pas en accès libre : c'est notre paraphrase — vérifiez sur votre exemplaire. Aucun protocole, aucune strate. Guide |
| MiFID II | RTS 25, règl. (UE) 2017/574 | Une divergence maximale par rapport à l'UTC pour les horloges métier, selon l'activité (paliers de 100 µs à 1 s), avec traçabilité à l'UTC. | Aucune strate ni aucun protocole nommés ; mais les paliers 100 µs et 1 ms appellent en pratique une référence locale (GNSS ou PTP). Guide |
3. Stratum 1, NTS, nombre de sources : qui demande quoi
| Question | Textes qui en parlent |
|---|---|
| Un serveur stratum 1 | Aucun. MiFID II RTS 25 rend une référence locale nécessaire en pratique pour ses paliers 100 µs et 1 ms. |
| Une heure authentifiée (NTS) | Aucun, nommément. PCI-DSS 10.6.3 protège les réglages et données de temps ; DORA demande l'intégrité et l'authenticité des données. Le NTS est un bon moyen d'y répondre, pas une exigence. |
| Plusieurs sources | CIS 8.4 (au moins deux, lorsque c'est possible) ; NIST SC-45(2) (une source secondaire dans une autre région) ; ANSSI R5 (plusieurs internes, plusieurs externes) ; PCI-DSS 10.6.2 (serveurs désignés synchronisés entre eux). |
| Une référence traçable à l'UTC | PCI-DSS 10.6.2 (TAI ou UTC) ; NIST AU-8 (UTC ou décalage indiqué) ; MiFID II (UTC, avec traçabilité) ; DORA (« source de référence fiable et documentée »). |
| Un chiffre de précision | MiFID II (100 µs à 1 s) ; ANSSI (au moins la seconde, recommandé). Le NIST le laisse à l'organisation. Les autres n'en donnent aucun. |
Tout le reste de ce que vous lirez — « au moins quatre sources », « 13 mois de logs NTP », « stratum 1 sur site » — relève du conseil d'architecture, le nôtre compris. Ce peut être un bon conseil ; ce n'est pas ce que disent les textes, et un auditeur qui les connaît fera la différence.
4. Ce qu'un test à distance montre, et ce qu'il ne montre pas
Le validateur interroge un serveur public depuis chez nous : NTP en IPv4 et IPv6, puis NTS avec heure authentifiée, et l'écart à notre serveur de référence avec son incertitude. Il montre si une source dont vous dépendez est joignable, sert l'heure et, si le NTS est utilisé, est authentifiée sous le bon nom.
Il ne montre pas que vos propres systèmes se synchronisent sur cette source, que leurs réglages sont protégés, que la synchronisation est surveillée dans le temps, ni que votre organisation est conforme à l'un des textes ci-dessus. Une mesure, depuis un seul point d'observation, est une photo, pas un audit.
Autre angle ? Le bon outil :
- Mesurer gigue, offset, latence → ntp-tester.eu
- Diagnostiquer pare-feu / port 123 / démon → check-ntp.net
- Architecture de référence entreprise → ntp.rdem-systems.com