d’être, ce serveur doit garantir autant que possible que seules quelques personnes sont
autorisées à y accéder. Ainsi, outre les mesures de protection classiques de
durcissement du système, il convient de placer ce serveur dans un réseau isolé, bien
filtré. Seuls les postes de travail habilités à accéder à cette machine doivent pouvoir la
joindre. De plus, le mot de passe root ne doit être connu d’aucun administrateur.
Naturellement, les accès à cette machine doivent être nominatifs, tracés et non
privilégiés. Les mots de passe de ces comptes doivent être de très bonne qualité.
Supervision : la puissance du serveur de journaux a relativement peu d’importance
(notons toutefois que pour les solutions à base de big data, la puissance de traitement
compte réellement). En revanche, il est essentiel de surveiller l’espace disque
disponible de ce serveur. Superviser ce paramètre est important.
Synchronisation des horloges : il peut paraître trivial de rappeler que tous les
systèmes fournissant des journaux doivent être synchronisés. Pourtant, l’expérience
montre que les serveurs ne sont pas toujours tous calés sur la même référence de
temps. Cela est dû au fait que tous les équipements ne sont pas installés par les mêmes
équipes. Certaines configurent avec soin la synchronisation horaire, alors que d’autres
l’ignorent complétement, si bien que l’adresse du serveur NTP n’est pas toujours
correctement renseignée. Il est donc prudent de vérifier ce point sur chaque système
concerné.
Traitement de journaux : les formats de fichiers étant très nombreux, il est souvent
nécessaire de développer des scripts pour les consolider avec d’autres journaux. Ce
travail peut aussi être fait par des agents spécifiques destinés à cet effet.
Une fois en place, la mise en route de l’analyse de journaux se fera progressivement. On
commencera par récupérer un seul journal, par exemple le journal du proxy HTTP. Cela
permettra de valider l’envoi du journal vers le serveur de logs, son traitement puis son
archivage, ainsi que les éventuels scripts (ou agents) de conversion de format. L’équipe
du RSSI pourra ainsi « se faire la main » sur les procédures techniques de consultation et
d’analyse. Lorsque le processus sera stabilisé, il deviendra possible d’y joindre un autre
type de journal, par exemple celui des accès aux bases de données centrales. Les
procédures seront alors adaptées à ce journal. Les autres journaux pourront être ajoutés
progressivement, au fur et à mesure de l’intégration satisfaisante des précédents.
autorisées à y accéder. Ainsi, outre les mesures de protection classiques de
durcissement du système, il convient de placer ce serveur dans un réseau isolé, bien
filtré. Seuls les postes de travail habilités à accéder à cette machine doivent pouvoir la
joindre. De plus, le mot de passe root ne doit être connu d’aucun administrateur.
Naturellement, les accès à cette machine doivent être nominatifs, tracés et non
privilégiés. Les mots de passe de ces comptes doivent être de très bonne qualité.
Supervision : la puissance du serveur de journaux a relativement peu d’importance
(notons toutefois que pour les solutions à base de big data, la puissance de traitement
compte réellement). En revanche, il est essentiel de surveiller l’espace disque
disponible de ce serveur. Superviser ce paramètre est important.
Synchronisation des horloges : il peut paraître trivial de rappeler que tous les
systèmes fournissant des journaux doivent être synchronisés. Pourtant, l’expérience
montre que les serveurs ne sont pas toujours tous calés sur la même référence de
temps. Cela est dû au fait que tous les équipements ne sont pas installés par les mêmes
équipes. Certaines configurent avec soin la synchronisation horaire, alors que d’autres
l’ignorent complétement, si bien que l’adresse du serveur NTP n’est pas toujours
correctement renseignée. Il est donc prudent de vérifier ce point sur chaque système
concerné.
Traitement de journaux : les formats de fichiers étant très nombreux, il est souvent
nécessaire de développer des scripts pour les consolider avec d’autres journaux. Ce
travail peut aussi être fait par des agents spécifiques destinés à cet effet.
Une fois en place, la mise en route de l’analyse de journaux se fera progressivement. On
commencera par récupérer un seul journal, par exemple le journal du proxy HTTP. Cela
permettra de valider l’envoi du journal vers le serveur de logs, son traitement puis son
archivage, ainsi que les éventuels scripts (ou agents) de conversion de format. L’équipe
du RSSI pourra ainsi « se faire la main » sur les procédures techniques de consultation et
d’analyse. Lorsque le processus sera stabilisé, il deviendra possible d’y joindre un autre
type de journal, par exemple celui des accès aux bases de données centrales. Les
procédures seront alors adaptées à ce journal. Les autres journaux pourront être ajoutés
progressivement, au fur et à mesure de l’intégration satisfaisante des précédents.