Les événements arrivent, l'index se remplit. Reste l'étape où tout cela devient utile : transformer des millions de lignes en quelques écrans qu'on regarde le matin. C'est là que se joue la différence entre une plateforme qui sert et une plateforme qu'on abandonne.
Connecter la source
Grafana interroge le moteur d'indexation comme n'importe quelle source de données. Le seul réglage qui demande de l'attention est le motif d'index : puisque les index sont créés par jour, on ne désigne pas un index précis mais un motif — suricata-eve-* — qui les couvre tous. Sans quoi les tableaux de bord cesseraient de fonctionner le lendemain.
Un test de connexion, une première exploration, et l'on voit apparaître la courbe du volume d'événements. C'est le moment où toute la chaîne est validée d'un coup : capteur, fichier, agent, pipeline, index, restitution.
Les premiers panneaux, et ce qu'ils apprennent
Le lab commence volontairement par des vues simples, construites sur le trafic ordinaire plutôt que sur les alertes :
- volume de requêtes DNS dans le temps — la respiration du réseau. Une courbe plate la nuit qui se met soudain à monter, c'est déjà une information ;
- top 10 des domaines résolus — ce que le réseau contacte réellement, et ce que personne ne sait avant de l'avoir regardé ;
- top des clients DNS — quelle machine résout le plus ;
- volume et hôtes HTTP — les destinations en clair.
Techniquement, chaque panneau se construit de la même façon : une requête qui filtre un type d'événement, une métrique — le plus souvent un simple comptage — et un regroupement par champ. Rien de sophistiqué ; l'essentiel est le choix du champ.
Pourquoi commencer par le trafic normal
C'est le point le plus contre-intuitif, et le plus important. On aurait envie de n'afficher que les alertes. Or les alertes ne racontent qu'une histoire fragmentaire — et souvent fausse au début, tant qu'aucun ajustement n'a été fait.
Le trafic ordinaire, lui, apprend à quoi ressemble un réseau en bonne santé. C'est la condition pour repérer ce qui sort de l'ordinaire : un poste qui résout soudain dix fois plus de domaines qu'à l'accoutumée, un domaine jamais vu qui apparaît dans le top, une plage horaire d'activité qui se décale. Aucune signature ne détecte cela ; une courbe, oui.
C'est aussi la meilleure façon de comprendre le bruit propre à son environnement — préalable indispensable à tout passage en mode blocage.
Deux ou trois principes de construction
- Peu de panneaux, mais lisibles. Un tableau de bord de trente vignettes n'est plus regardé au bout d'une semaine. Cinq à huit panneaux qui tiennent sur un écran valent mieux.
- Une question par panneau. Si l'on ne sait pas dire quelle question un graphique répond, il n'a rien à faire là.
- Des échelles de temps cohérentes — comparer une courbe sur 24 h et une autre sur 7 jours dans la même vue induit systématiquement en erreur.
- Un tableau de bord exporté est un tableau de bord partagé. Le format d'export est un simple document structuré : versionné, il se réimporte à l'identique ailleurs, et se transmet.
Le passage à l'échelle : de la courbe à l'alerte
Regarder un tableau de bord suppose que quelqu'un le regarde. La suite logique consiste à faire remonter l'anormal plutôt qu'à l'attendre : un seuil sur le volume d'alertes d'une catégorie, une apparition de domaine inconnu, une machine qui dépasse son comportement habituel — avec une notification.
Mais la règle vue précédemment s'applique ici encore : peu d'alertes, toutes actionnables. Une notification qu'on apprend à ignorer est pire que pas de notification du tout.
Ce que le lab a produit
Au terme des cinq étapes, l'infrastructure permet d'observer, d'analyser et de corréler — et constitue la base pour la suite : le passage contrôlé en mode prévention, l'ajout d'un second capteur, la corrélation avec les journaux système, ou un centre opérationnel de sécurité pédagogique.
Surtout, elle a produit quelque chose qui ne se lit dans aucune documentation : la mesure du volume réel de journaux, du nombre de faux positifs, et du temps nécessaire pour reconstituer une chronologie. C'est précisément ce qui manque quand on discute de détection en réunion — et ce qui rend crédible une politique de sécurité.
La série « détection réseau »
Cinq articles pour comprendre, cinq pour construire :
- Qu'est-ce qu'un IDS ?
- Qu'est-ce qu'un IPS ?
- Suricata, le moteur
- OpenSearch, le socle analytique
- Détection réseau et NIS2 : la logique de sécurité
- Lab (1) : architecture et passerelle
- Lab (2) : OpenSearch et Grafana
- Lab (3) : Suricata en mode IDS
- Lab (4) : la chaîne d'ingestion
- Lab (5) : les tableaux de bord — vous y êtes