I. Présentation
Cet article décrypte les points clés du guide ANSSI “Recommandations de sécurité pour l’architecture d’un système de journalisation”, pour vous aider à concevoir une architecture de journalisation à la fois robuste, efficace et conforme aux bonnes pratiques de sécurité.
La journalisation fait partie des indispensables pour la maintenance et la sécurité du SI, tant de manière proactive (anticiper un problème, inventorier) que réactive (diagnostique, investigation numérique, détection automatisée). Production, transmission, stockage et analyse, un système complet de journalisation passe par de nombreuses étapes, composants et configurations qu’il convient de concevoir de manière complète et sécurisée.
L’objectif du document est de fournir les principales lignes directrices concernant la mise en place d’un système de journalisation sécurisé en passant par :
L’identification de ses prérequis techniques ;
L’architecture générale d’un système de journalisation ;
La bonne configuration des systèmes générateurs de journaux.
En plus d’explications précises et enrichissantes sur la journalisation et la sécurité des systèmes qui les traitent, transmettent et stockent, il propose 31 recommandations concrètes pour aider à mettre en place et à auditer la sécurité d’un système de journalisation.
L’idée de vous exposer les principales idées de ce document pour vos besoins opérationnels, mais aussi de vous donner envie de le lire pour mieux comprendre cette thématique.
II. Un mot sur les journaux d’évènements
La première partie du document s’attarde sur la notion de journaux d’évènements en vue de dresser les prérequis à la constitution d’un système de journalisation plus complet. Voici quelques notions à connaitre pour mieux le comprendre :
TermeDéfinitionÉvénement, journal, log Trace écrite, structurée et horodatée d’une activité, opération ou action réalisée par un composant (système, application, équipement réseau, etc.). Les logs sont essentiels pour le suivi, l’audit et le dépannage.Système de journalisationEnsemble des processus, outils et politiques mis en place pour collecter, stocker, gérer et analyser les journaux d’évènements générés par les différents composants d’un système d’information.Export des journauxProcessus consistant à copier ou transférer les évènements vers une machine ou un système centralisé, distinct de celui qui les a générés, afin d’en assurer la sauvegarde, l’analyse ou la corrélation.MCS (Maintien en Condition de Sécurité)Ensemble des actions et bonnes pratiques visant à maintenir un niveau de sécurité optimal pour les systèmes et les données, incluant la surveillance des logs, la mise à jour des correctifs, et la réponse aux vulnérabilités.Rotation des journauxMécanisme automatisé consistant à archiver ou supprimer les journaux lorsqu’ils atteignent une certaine taille, une durée de conservation prédéfinie, ou pour optimiser les performances de stockage et faciliter leur gestion.Détection des incidentsProcessus proactif ou réactif visant à identifier, grâce à l’analyse des logs et d’autres indicateurs, les activités suspectes ou malveillantes au sein d’un système d’information, afin de déclencher une réponse adaptée.InvestigationProcessus méthodique d’analyse des journaux d’évènements, des alertes et des traces numériques afin d’identifier la cause, l’étendue et l’impact d’un incident de sécurité ou d’un dysfonctionnement. L’investigation peut inclure la corrélation de logs, l’examen des artefacts, la reconstruction de la chronologie des évènements, et la production de rapports pour soutenir la réponse aux incidents ou les actions correctives.
Tout d’abord, pour journaliser : il faut générer et stocker les évènements de sécurité et métier qui se déroulent sur les composants du SI. Systèmes, services, applications et équipements réseaux n’ont pas les mêmes fonctionnalités de journalisation. Qu’il s’agisse des évènements de sécurité ou d’activités métier, il convient dans un premier temps de connaitre les capacités de journalisation (qu’est-ce qui est journalisable), de transmission et de formatage des journaux.
La structure des journaux doit respecter un certain format pour faciliter leur traitement, par exemple être interprétable par un être humain avec des champs fixes et une grammaire définie. Autrement, ils seront difficilement exploitables par des solutions, scripts ou outils tiers, et donc pratiquement inutiles. Les évènements doivent également être horodatés et sourcés (nom de l’équipement) pour être exploitables efficacement.
L’absence de journaux rend impossible tout diagnostic, investigation ou réaction. C’est un risque direct pour le SI (plutôt un outil indispensable en moins) et peut parfois contrevenir à des réglementations, normes ou lois. Les journaux d’évènements contribuent directement au MCS (Maintien en condition de sécurité) d’un SI.
Les premières recommandations du guide vous invitent à intégrer dans le choix des composants leurs capacités de journalisation, mais aussi à gérer leur bonne configuration et leur structure avec attention, etc.
Naturellement, les journaux prennent de la place sur un système et, dans la mesure où ils seront stockés au moins temporairement en local, puis centralisés, il est important de bien calibrer configurations et espaces de stockage.
S’intéresser aux journaux d’évènements est l’occasion d’apprendre ou de se rappeler l’intérêt du protocole NTP dans nos SI. Le Network Time Protocol fait rarement parler de lui, mais reste indispensable. Son rôle : synchroniser le temps des différents équipements du SI pour préserver la cohérence et l’exploitation des logs horodatés.
La bonne configuration des journaux d’évènements sur chaque composant vise à faciliter leur intégration dans un ensemble qui se nomme le système de journalisation.
III. Système de journalisation
Cette partie du document s’attarde sur la notion de système de journalisation pour son rôle de centralisateur des journaux d’évènements des composants du SI. Plus qu’un simple agrégateur, il remplit de nombreux rôles clés pour le SI et sa sécurité. Le système de journalisation doit donc lui aussi avoir un niveau de sécurité robuste pour ne pas être le maillon faible du SI.
Pour des raisons d’espace disque et de préservation en cas d’incident (défaillance matérielle, effacement volontaire), les journaux doivent être exportés, et même mieux, centralisés sur un composant autre que celui qui les produit. Cela permet ensuite de corréler les évènements entre eux au sein d’une même plateforme, avec un même outil, notamment pour des besoins de surveillance, de sécurité et d’investigation.
Le système de journalisation est constitué de l’ensemble des composants, objets et services qui permettent la production, le traitement, le formatage, la transmission, le stockage et l’analyse des journaux d’évènements des composants du SI. Il s’agit là d’une architecture complète, et parfois complexe en fonction du nombre et type de composants ou de zones géographiques.
La sensibilité du serveur de centralisation des journaux amène les équipes de sécurité à le positionner dans la zone d’administration du SI, ce qui fait appel à un autre guide de l’ANSSI tout aussi intéressant (Recommandations relatives à l’administration sécurisée des systèmes d’information).
Nous avons écrit un article entier dédié à la centralisation des journaux pour la sécurité du SI, je vous invite à le consulter sur le lien suivant :
IV. De la journalisation à la détection des incidents
À cet égard, la chaîne de collecte des évènements de sécurité est un sous-ensemble critique du SI. Il faut donc veiller à contrôler régulièrement, voire en continu, son bon fonctionnement en analysant les journaux, vérifiant qu’ils sont bien récupérés, complets, etc.
L’annexe A du document vous guide sur les catégories d’évènements qu’il est pertinent de collecter dans différents domaines comme l’authentification, la gestion des comptes, la stratégie de sécurité. Cette approche est intéressante, car suffisamment macro pour s’adapter à tout système, application ou équipement réseau.
Le serveur de collecte des journaux est d’ailleurs une cible de choix pour un attaquant souhaitant obtenir un tas d’informations techniques, se dissimuler sur le réseau (qui surveille le serveur de collecte ?) ou effacer ses traces. Il doit donc faire l’objet d’une sécurisation accrue et d’une isolation forte au niveau réseau.
Il est également nécessaire de se poser la question de la méthode de transfert des journaux. La bande passante du réseau permet-elle de les envoyer en temps réel (en continu, dès qu’ils sont produits) pour une meilleure réactivité ? Où faut-il opter pour un temps différé (une fois par jour) en acceptant de passer à côté d’un incident de sécurité entre deux envois ? Le mode de transfert (pull/push) et les protocoles réseau (TCP/UDP) et de chiffrement (TLS, SSH, IPSEC, etc.) sont par ailleurs à ne pas sélectionner au hasard. Le guide expose longuement les bénéfices/inconvénients de chaque choix qu’il est possible de faire ainsi que différentes recommandations.
Enfin, ce chapitre aborde de nombreux sujets spécifiques à la journalisation tels que :
Gestion de la rotation des journaux.
Gestion et anticipation des espaces de stockages.
Externalisation des journaux et garanties de sécurité associées, notamment via des PDIS (prestataire de détection des incidents de sécurité)
Protection et droits d’accès des journaux (lecture, modification, suppression).
Cas particulier des postes nomades.
Chaque point s’accompagne de recommandations adaptables à votre contexte. L’objectif ? Sécuriser la production, la transmission et le stockage des journaux, puis faciliter leur corrélation et leur analyse pour une surveillance optimale des événements de sécurité du SI.
V. Quelques exemples d’architecture
Ce guide de l’ANSSI est particulièrement intéressant, car il aborde des sujets à la fois très précis, comme les types de journaux qu’il faut collecter, les recommandations concernant leur transmission, stockage, rotation, etc. Mais aussi des points plus macro qui aident à concevoir une architecture robuste de système de journalisation. Différents exemples d’architecture sont d’ailleurs fournis, du simple au multisite :
Source : https://cyber.gouv.fr/publications/recommandations-de-securite-pour-larchitecture-dun-systeme-de-journalisation
Ce schéma met en évidence la zone de confiance dans laquelle doit se trouver le serveur de collecte, la nécessité d’un archivage hors ligne des journaux, la prise en compte des différents types d’équipements dans la journalisation (serveurs, terminaux, équipements réseau) et la synchronisation temporelle de l’ensemble.
Enfin, l’annexe C introduit également le sujet de la détection des incidents, dont la centralisation efficace des journaux des composants du SI est un prérequis indispensable.
Je profite de cet article pour vous orienter aussi sur nos articles relatifs aux journaux d’évènements et la cybersécurité :
VI. Conclusion
C’est tout pour ce format court ! Je vous rappelle qu’il ne s’agit que d’un résumé qui vise à vous donner une synthèse et une idée de ce qui est mentionné dans le document. On a donc dans ce guide une vue complète de la vie et de l’utilisation des journaux d’évènements, de sa production jusqu’à son utilisation pour la détection d’intrusion.
Je vous invite à lire le document en entier, en incluant les différentes annexes. En effet, celles-ci donnent des exemples très concrets d’architectures, de configurations, mais aussi de contextes d’attaques dans lesquels les logs sont utilisés pour la détection, le renforcement de la journalisation et l’identification de scénarios d’attaque (matrice MITRE ATT&CK) :
N’hésitez pas à nous dire dans les commentaires si vous souhaitez d’autres articles de ce type, mais aussi si vous avez mis en place (ou auriez dû mettre en place) les bonnes pratiques de ce guide !
Co-fondateur d’IT-Connect.fr.
Auditeur/Pentester chez Orange Cyberdéfense.