Journalisation : les 14 nouvelles recommandations de l'ANSSI
Publié par Clément Bohic le - mis à jour à
L'ANSSI a actualisé ses recommandations sur les systèmes de journalisation. Quelles nouveautés par rapport à la version précédente, qui datait de 2013 ?
Quelle mesures de sécurité pour un système de journalisation ? L'ANSSI avait publié, fin 2013, une note technique à ce sujet. Elle vient de l'actualiser. Aux 17 recommandations initiales viennent s'en ajouter 14. Les voici.
En commençant par ceux qui composent les passerelles Internet sécurisées et par ceux qui supportent les valeurs métiers les plus importantes ou qui disposent d'un chemin de contrôle permettant d'accéder à ces données.
Cette recommandation complète celle invitant à activer l'horodatage pour l'ensemble des événements. Homogénéiser, c'est notamment avoir un fuseau horaire de référence et synchroniser les horloges avec une précision minimale à la seconde.
Pour chaque équipement, sélectionner les types d'événements devant être stockés. Une politique qui prend en compte les capacités de stockage, de collecte et de traitement des événements. Ainsi que les besoins de sécurité de l'équipement.
En d'autres termes, tester régulièrement que tous les systèmes du SI sont bien journalisés (hors exception dûment identifiées). Et qu'ils transfèrent leurs événements à des serveurs de collecte des journaux.
Journalisation : pull ou push ?
On choisira cette option à défaut de pouvoir effectuer un transfert « temps réel ». L'envoi des journaux aux serveurs de collecte se fera alors « au plus tard quelques heures après leur génération ».
Pull ou push ? Cela doit se décider au cas par cas. En fonction du niveau de sensibilité du serveur collecté et du collecteur. Ainsi que de la surface d'attaque qu'induit la solution retenue. Le mode push authentifié, par exemple, ouvre la voie aux attaques par relais d'authentification, tout en augmentant la surface d'attaque des serveurs centraux. Le mode pull peut nécessiter un compte de service disposant de droits d'authentification sur de nombreuses ressources du SI. On pourra minimiser les risques par filtrage d'IP, en forçant l'authentification par Kerberos ou encore en changeant régulièrement le mot de passe du compte de service.
Si cela n'est pas possible, on stockera les journaux d'événements dans une arborescence de répertoires classés par thématiques (authentification, applications métiers, web...).
Faire en sorte que seuls les comptes utilisateurs dédiés à l'administration privilégiée des équipements disposent de ces droits. Cette recommandation complète celle applicable aux droits d'accès en écriture.
En cas d'externalisation...
Cela suppose d'évaluer les prestataires sur leur capacité à générer des journaux sur les solutions retenues, à les stocker de manière sécurisée et à les rendre disponibles pour le client. Ainsi que leur capacité à s'interconnecter au niveau réseau et à synchroniser la source de temps sur une horloge interne à l'entité. À examiner aussi : la facturation de la bande passante sortante en prévision d'un éventuel export.
En cas d'externalisation d'un sous-système du SI de l'entité, récupérer, de préférence sur le système de journalisation interne de l'entité, tous les journaux liés à l'interconnexion (concentrateurs VPN, serveurs de fédération d'identité...).
Qu'en est-il si le poste de travail ne peut pas joindre un serveur de collecte pendant une certaine durée alors qu'il est connecté au SI ? S'il existe, configurer le système de détection d'incidents pour déclencher des alarmes.
Lorsque la centralisation à travers un tunnel VPN est impossible et qu'un système se trouve déconnecté pour une durée moyenne à longue, la centralisation de ses événements perd son intérêt. Il est dans ce cas nécessaire d'envisager d'autres stratégies de sécurisation et de supervision.
Illustration principale © Pavel Ignatov - Adobe Stock