La cybersécurité d’un système d’information repose sur un grand nombre de mécanismes différents. Mais ils ont quasiment tous un point commun : ils ont besoin d’une vision correcte et précise de l’heure. Les logs sont horodatés, les certificats ont des dates de validité, les tickets d’authentification expirent, les codes à usage unique ont une durée de vie courte. Tant que les horloges des serveurs et ordinateurs sont d’accord entre elles, tout fonctionne correctement. Mais dès que des divergences apparaissent les mécanismes se dérèglent un par un : des logs impossibles à corréler, des authentifications refusées, des certificats considérés à tort comme expirés. La sécurité est alors compromise.
Pire encore, en cas d’attaque réussie, la traçabilité permettant de déterminer ce qui s’est passé est souvent perdue en l’absence de synchronisation horaire.
Cette synchronisation est donc une nécessité pour la sécurité, mais aussi pour les référentiels de conformité.
Un service conçu originellement sans sécurité
La synchronisation horaire est l’un des plus vieux services d’Internet. Le protocole NTP (Network Time Protocol), qui distribue le temps de machine en machine, date des années 1980. Il a été conçu à une époque où le réseau reliait des laboratoires qui se faisaient confiance : ses échanges ne sont ni authentifiés ni chiffrés, et n’importe quelle machine peut interroger n’importe quel serveur. Cette conception reste robuste sur le plan de la précision, beaucoup moins sur celui de la sécurité. Pendant des décennies, personne ne s’en est inquiété : l’heure était un service d’arrière-plan sans intérêt pour un attaquant. À mesure que les mécanismes de sécurité se sont mis à dépendre de la synchronisation temporelle, le temps est devenu une cible.
Gardez le contrôle de votre réseau horaire
Supervisez et maitrisez votre synchronisation depuis une interface centralisée et intuitive.
L’importance de l’horodatage des logs
L’impact le plus évident et le plus crucial de la synchronisation temporelle est sur les logs. Chaque équipement d’un système d’information enregistre ses événements internes : connexions, erreurs, alertes, etc. Pris isolément, ces logs racontent la « vie » de la machine.
Mais en croisant les logs de toutes les machines d’un même système, on peut comprendre ce qui se passe globalement. Le croisement des logs permet notamment la détection d’attaques. Il existe un type d’outil dédié, le SIEM (Security Information and Event Management), qui collecte les logs de centaines de machines pour y chercher des enchaînements suspects.
Mais croiser des événements de machines différentes suppose de pouvoir les ordonner les uns par rapport aux autres, et on ne peut les ordonner que si toutes les machines datent leurs logs avec la même heure. Un décalage de quelques secondes entre deux serveurs suffit à inverser l’ordre apparent de deux événements, et à induire, par exemple, une conclusion erronée sur le déroulement de ces mêmes évènements.
Le problème est encore plus net après un incident. L’analyse forensique (celle qui suit une attaque) consiste à reconstituer le déroulement des faits à partir des logs de dizaines de machines : par où l’attaquant est entré, quand, ce qu’il a touché. Si les horloges divergent, cette chronologie est inexploitable. Et l’enjeu dépasse la technique : la chronologie d’un incident peut être produite devant un assureur ou un juge, et sa valeur repose sur la fiabilité de la source de temps qui la fonde.
C’est la raison pour laquelle l’ANSSI, dans ses recommandations sur la journalisation, rappelle qu’un événement n’est exploitable que s’il peut être situé dans le temps.
Temps et mécanismes d’authentification
Un autre aspect de l’importance de la synchronisation horaire est moins visible. Il faut savoir qu’une partie des mécanismes de sécurité utilisent l’heure comme composant. C’est par exemple le cas de Kerberos, le protocole d’authentification au cœur des annuaires d’entreprise comme Active Directory, qui horodate ses échanges pour empêcher qu’un attaquant les capture et les rejoue plus tard.
Autre exemple : les certificats qui sécurisent les connexions chiffrées portent une date de début et une date de fin de validité : une machine dont l’horloge est très en avance rejette un certificat pourtant valide, une machine très en retard accepte un certificat expiré.
Enfin, les codes à usage unique des applications d’authentification, basés sur l’algorithme TOTP (Time-based One-Time Password), sont calculés à partir de l’heure courante, par tranches de trente secondes : si l’horloge du serveur dérive, les codes légitimes sont refusés.
Dans tous ces cas, la logique est la même. L’heure sert de preuve de fraîcheur, et une heure fausse transforme un mécanisme de protection en défaillance ou en porte ouverte pour une attaque.
Le temps, cible et arme
Tant de choses dépendant de l’heure, fausser l’heure devient une attaque en soi. Un attaquant capable de décaler l’horloge d’une machine peut brouiller ses logs, faire expirer ses certificats ou prolonger la vie de secrets périmés, sans toucher au reste du système.
Le protocole NTP s’y prête : ses échanges n’étant pas authentifiés, un attaquant placé sur leur chemin peut altérer l’heure distribuée. C’est l’attaque par man-in-the-middle. La parade existe : le protocole NTS (Network Time Security), défini par la RFC 8915, authentifie le serveur de temps et protège les échanges contre la falsification.
Le temps peut aussi servir d’arme contre des tiers. En 2013, une fonction d’administration de NTP, la commande monlist, a été massivement détournée : une petite requête, envoyée avec une adresse d’expéditeur falsifiée, déclenchait une réponse environ deux cents fois plus volumineuse, dirigée vers la victime. Des milliers de serveurs de temps mal configurés ont ainsi servi d’amplificateurs à des attaques par déni de service. Cette vulnérabilité, référencée CVE-2013-5211, porte une leçon simple : un serveur de temps mal configuré n’est pas seulement un risque pour son propriétaire, il peut devenir un instrument d’attaque contre les autres.
La conformité réglementaire
Au fil du temps, en raison des 3 aspects vus ci-dessus, la synchronisation horaire est devenue une exigence de conformité. Le standard PCI-DSS, qui encadre les données de cartes bancaires, impose dans son exigence 10.4 des serveurs de temps internes. En France, les recommandations de l’ANSSI sur la journalisation en font un prérequis de l’exploitabilité des logs. La directive européenne NIS2 (Network and Information Security) impose de notifier les incidents dans des délais courts, ce qui suppose en pratique de pouvoir établir rapidement une chronologie fiable. Pour un responsable de la sécurité, la conséquence est directe : il faut vérifier que l’architecture de temps de son système est à la hauteur de ce que ses référentiels exigent déjà.
Par où commencer
Les mesures à prendre sont peu nombreuses, mais toutes sont importantes. Il faut en premier disposer d’une source de temps interne et maîtrisée, c’est-à-dire d’un serveur de temps dédié.
Ensuite, il faut faire de cette source le point de synchronisation de tous les équipements, pour que la cohérence des horodatages soit garantie par construction.
Enfin, selon l’usage il peut être recommandé l’authentification qu’apporte le protocole NTS, en vue d’améliorer la sécurité du système.
N’oubliez pas de considérer le serveur de temps lui-même comme un équipement de sécurité, certains d’entre eux sont notamment conformes à la norme IEC 62-443.
