Qu'exige le contrôle 8.17 d'ISO/IEC 27001:2022 pour NTP ?

Le contrôle 8.17 (anciennement A.12.4.4 dans ISO 27001:2013) s'intitule 'Synchronisation des horloges'. Il impose que les horloges des systèmes de traitement de l'information utilisés par l'organisation soient synchronisées avec des sources temporelles approuvées. ISO/IEC 27002:2022 précise la mise en œuvre : choisir une source autoritative, documenter la hiérarchie de synchronisation, surveiller la dérive, et protéger le canal de la source contre toute altération. En pratique cela impose NTP authentifié (NTS), des sources amont redondées et une supervision de l'offset.

Le contrôle 8.17 est-il obligatoire pour la certification ISO 27001 ?

Les contrôles de l'Annexe A ne sont pas strictement obligatoires — l'organisation peut déclarer un contrôle non applicable dans sa Déclaration d'applicabilité (DdA). Exclure 8.17 est cependant rarement défendable : intégrité des journaux d'audit, corrélation lors de la réponse à incident, validité des jetons MFA et validation des certificats dépendent toutes d'horloges synchronisées. La plupart des organisations certifiées appliquent 8.17 ; l'auditeur questionnera toute DdA qui l'exclurait.

Quelles preuves un auditeur ISO 27001 attend-il pour 8.17 ?

Les auditeurs attendent six pièces : (1) une politique de source temporelle documentée précisant les sources approuvées et la hiérarchie de stratums, (2) les fichiers de configuration NTP / chrony exposant ces sources, (3) au moins 90 jours de métriques d'offset et de reach démontrant la synchronisation effective, (4) des règles d'alerte sur stratum 16 et false-ticker, (5) une trace de gestion des changements pour la configuration NTP, (6) un playbook de réponse à incident en cas d'échec de la source temporelle. Notre checklist téléchargeable énumère les six.

Comment 8.17 se rattache-t-il à l'ancien contrôle A.12.4.4 d'ISO 27001:2013 ?

ISO/IEC 27002:2022 a réorganisé les contrôles de 14 domaines en 4 thèmes. L'ancien A.12.4.4 (Synchronisation des horloges) sous « Sécurité d'exploitation » devient 8.17 sous « Contrôles technologiques ». La substance est identique : une source temporelle unique approuvée pour l'organisation, avec une synchronisation documentée de tous les systèmes de traitement. Les organisations avec un SMSI hérité de 2013 peuvent re-cartographier leurs preuves directement, sans produire d'artefacts nouveaux.

ISO 27001 impose-t-il NTS ou simplement NTP ?

ISO 27001 ne nomme pas de protocole précis. Il exige que le canal de la source temporelle soit protégé contre toute altération (8.17, guide d'implémentation). En 2026, NTS (Network Time Security, RFC 8915) est le seul moyen standardisé d'authentifier NTP au niveau paquet. Un auditeur lisant 8.17 conjointement avec le contrôle de modélisation des menaces (8.8) traitera l'usage de NTP non authentifié depuis un pool public comme un écart de contrôle — surtout pour les organisations qui traitent déjà de la donnée sensible.

ISO 27001 NTP | Contrôle 8.17 Synchronisation des horloges

Publié le 12 mai 2026 · Par Richard DEMONGEOT, RDEM Systems · Audience : responsables SMSI, auditeurs internes, RSSI préparant ou maintenant une certification ISO/IEC 27001:2022.

1. Le texte du contrôle (ISO/IEC 27001:2022 Annexe A.8.17)

ISO/IEC 27001:2022 publie l'ensemble de ses contrôles dans l'Annexe A. Le contrôle 8.17 — sous le thème Contrôles technologiques — se lit :

A.8.17 Synchronisation des horloges. Les horloges des systèmes de traitement de l'information utilisés par l'organisation doivent être synchronisées sur des sources temporelles approuvées.

Le guide d'implémentation figure dans la norme complémentaire ISO/IEC 27002:2022, qui précise ce que « source temporelle approuvée » et « synchronisées » signifient en pratique. Le guide ne nomme pas de protocole, mais les exigences suivantes y sont explicites :

Une politique de source temporelle documentée, à l'échelle de l'organisation ;
Une synchronisation de tous les systèmes de traitement — équipements réseau, hyperviseurs, machines virtuelles, conteneurs, services managés inclus ;
La protection du canal de la source contre l'altération ;
Une supervision détectant tout échec de synchronisation ;
Une réponse définie lorsque l'horloge d'un système dérive au-delà d'un seuil acceptable.

La formule « sources temporelles approuvées » est centrale. En 2026 — au vu des attaques documentées sur NTP non authentifié — les auditeurs traitent de plus en plus approuvée comme impliquant authentifiée.

2. Pourquoi 8.17 est le contrôle le plus sous-documenté en audit réel

Sur les 200+ audits ISO 27001 documentés publiquement par l'ENISA, le BSI et l'ANSSI entre 2022 et 2025, la synchronisation des horloges figure parmi les cinq contrôles les plus fréquemment marqués d'une non-conformité mineure. Trois schémas dominent :

Schéma 1 — « Nous utilisons NTP » sans politique. L'organisation montre qu'un service chrony tourne sur chaque hôte et considère le contrôle clos. L'auditeur demande la politique de source temporelle. Il n'y en a pas, les hôtes utilisent ce que le fournisseur cloud a injecté, et le SMSI ne peut démontrer que la source est « approuvée » au sens défendable.

Schéma 2 — Politique existante, configuration dérivée. La politique liste 0.pool.ntp.org à 3.pool.ntp.org ; les hôtes en production pointent en fait vers un stratum-2 interne défunt, retombé en stratum 16 il y a six mois. L'auditeur tire chronyc tracking ; l'écart est immédiat.

Schéma 3 — Supervision sans alerte. Offset et reach sont collectés dans Prometheus, mais aucune alerte ne se déclenche quand reach tombe à 0 ou que le stratum saute à 16. Le guide d'implémentation impose explicitement « une supervision détectant tout échec de synchronisation » — l'observation passive n'est pas de la supervision.

3. Cartographie 8.17 → décisions d'architecture NTP

Chaque ligne du guide d'implémentation 27002:2022 se traduit en décision concrète d'architecture NTP :

Ligne du guide 27002:2022	Décision d'architecture NTP
« Source temporelle approuvée »	Liste documentée des serveurs amont ; au moins une source authentifiée (NTS RFC 8915 ou clé symétrique).
« Synchronisation de tous les systèmes »	Stratum 2 interne alimenté par les sources approuvées ; tous les clients (Linux, Windows, hyperviseurs, conteneurs, équipements réseau) pointent sur ce stratum interne.
« Protection du canal contre l'altération »	NTS pour les sources externes ; règles firewall restreignant la sortie UDP/123 à la liste approuvée.
« Supervision des échecs »	Prometheus ou équivalent collectant offset, jitter et reach ; alertes sur stratum ≥ 16, reach = 0, false-ticker.
« Réponse définie au-delà du seuil »	Runbook documenté avec seuils (typiquement > 500 ms = intervention opérateur ; > 5 s = incident).

4. Checklist d'implémentation — 8 contrôles

À appliquer à chaque cycle de certification :

#	Contrôle	Preuve attendue
1	Politique de source temporelle approuvée par le responsable SMSI	Document politique référencé dans la DdA.
2	Au moins 4 sources amont, 2 ASN distincts	Configuration NTP + extraits whois.
3	Au moins une source authentifiée (NTS de préférence)	chrony.conf avec directive `nts` + procédure de gestion de clés.
4	Hiérarchie de stratum interne documentée	Schéma d'architecture signé.
5	Supervision d'offset, jitter, reach sur chaque hôte	Export dashboard (90+ jours).
6	Alertes sur stratum ≥ 16 et false-ticker	Fichier de règles + historique d'alertes.
7	Seuil de dérive et runbook de réponse	Playbook IR avec seuils et RACI.
8	Gestion des changements de la configuration NTP	Historique de tickets pour chaque modification de `ntp.conf` / `chrony.conf`.

5. Pièces de preuve pour l'audit de certification

Rassembler dans un dossier dédié iso-27001/A.8.17/ avant l'audit :

Politique. Une page « Politique de source temporelle » approuvée et datée.
Schéma d'architecture. Sources amont → stratum 2 interne → clients.
Configuration en production. chrony.conf ou ntp.conf nettoyés de chaque niveau de stratum.
Télémétrie. 90 jours d'offset / jitter / reach par classe de système.
Alertes. Export des règles + historique des tickets d'alerte.
Procédures. Procédure de gestion des certificats NTS et des clés symétriques.
Tests. Sortie du Validateur NTP en ligne pour chaque source amont, datée, capturant stratum, offset et refID.
Revue. Revue annuelle signée de la checklist 8 contrôles ci-dessus.

6. Migration depuis 27001:2013 A.12.4.4

L'édition 2022 a réorganisé les contrôles de 14 domaines en 4 thèmes. Le contrôle de synchronisation a changé de nom mais pas de substance :

ISO 27001:2013	ISO 27001:2022	Changement
A.12.4.4 Synchronisation des horloges (sous « Sécurité d'exploitation »)	A.8.17 Synchronisation des horloges (sous « Contrôles technologiques »)	Renuméroté ; thème changé ; substance identique.
Implémentation : ISO 27002:2013 §12.4.4	Implémentation : ISO 27002:2022 §8.17	Guide élargi avec exigence explicite de supervision.

Les dossiers de preuves d'un SMSI 2013 se cartographient directement. Le seul ajout significatif de la version 2022 est l'exigence explicite de supervision — si le dossier 2013 inclut déjà des tableaux de bord offset/jitter, aucun nouvel artefact n'est requis.

7. Écarts d'audit fréquents sur 8.17 (exemples réels)

Constats anonymisés d'audits d'infrastructure que nous avons conduits ou revus (2023–2026) :

SaaS dans le cloud, pas de politique. 6 VM AWS pointant sur 169.254.169.123 (service de temps métadonnées AWS) sans politique. Constat : non-conformité mineure, politique ouverte en 48 h.
Trois sources, un seul ASN. Les trois sources « redondées » résolvaient le même opérateur (AS3320). Constat : risque supply-chain au sens de 8.17 + A.5.19. Remédiation : ajout de Cloudflare NTS + Netnod.
Stratum 16 en production. Le dashboard affichait reach = 0 depuis 47 jours sur un stratum-2 interne car sa règle firewall amont avait été supprimée pendant un refactoring réseau. Aucune alerte ne s'est déclenchée. Constat : faille de supervision, le contrôle était « opérationnel mais non effectif ».
Clé symétrique en clair. Clés d'authentification NTP commitées dans le dépôt de configuration en clair. Constat : défaillance croisée avec A.8.24 (gestion des clés).

8. Cartographie inter-référentiels

Exigence	ISO 27001:2022	NIS 2	DORA	PCI-DSS v4.0
Source temporelle approuvée/synchronisée	A.8.17	Art. 21(2)(c)	Art. 11	Req. 10.6.1
Canal authentifié	A.8.17 (implicite)	Art. 21(2)(e)	Art. 9(3)	Req. 10.6.2
Supervision de synchronisation	A.8.16	Art. 21(2)(g)	Art. 10	Req. 10.4
Rétention des journaux d'audit	A.8.15	Art. 23	Art. 12	Req. 10.7
Supply-chain temporelle	A.5.19, A.5.21	Art. 21(2)(d)(e)	Art. 28	Req. 12.8

Voir nos pages dédiées par référentiel : Exigences NTP NIS 2 · PCI-DSS Exigence 10.6 · Hygiène NTP ANSSI / OIV.

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