SIEM et corrélation de journaux : les principes

Un ordinateur qui se connecte, un compte qui change de groupe, un fichier qui sort du réseau : chaque événement laisse une trace dans un journal. Mais un journal, seul, est une phrase isolée. Pour comprendre une attaque, il faut relier des phrases venues de dizaines de sources. Cette mise en relation s'appelle la corrélation, et l'outil qui la réalise à grande échelle est le SIEM. Voyons comment il fonctionne et comment on en tire de bonnes détections.

Dans le chapitre précédent, vous avez découvert le travail du SOC. Le SIEM est son instrument principal. Le fil rouge de ce chapitre est la construction de votre dossier de détection et de réponse : une règle de corrélation, une fiche d'indicateurs, une cartographie ATT&CK et un plan de réponse à incident.

Qu'est-ce qu'un SIEM ?

SIEM signifie Security Information and Event Management. Retenez-le comme un grand moulin à journaux qui fait cinq choses :

1. Collecter les journaux de nombreuses sources : annuaire, pare-feu, serveurs, postes, messagerie, applications, services cloud.
2. Normaliser : les sources ne parlent pas le même langage. Le SIEM traduit chaque événement dans un format commun (qui, quoi, depuis où, quand, résultat).
3. Stocker et indexer pour pouvoir chercher rapidement, y compris dans plusieurs mois d'historique.
4. Corréler : appliquer des règles qui détectent des motifs sur un ou plusieurs événements.
5. Alerter et présenter : produire des alertes priorisées et des tableaux de bord.

Autour de lui gravitent des solutions de réponse automatisée, des enrichissements, des bases d'indicateurs de menace… mais le cœur reste cette boucle collecte-normalisation-corrélation-alerte.

Pourquoi la corrélation change tout

Prenez une situation fictive dans le laboratoire d'Atelier Boréal :

• Source A (annuaire) : le compte camille échoue 6 fois à se connecter depuis un poste interne.
• Source B (annuaire) : le même compte réussit sa connexion une minute plus tard.
• Source C (serveur de fichiers) : ce compte accède à des dossiers qu'il n'a jamais ouverts.

Chaque événement, séparément, est banal : un oubli de mot de passe, une connexion, une consultation de dossiers. Ensemble, ils racontent une histoire : un mot de passe deviné, puis une exploration. Le SIEM n'a pas l'intelligence d'un humain, mais il sait appliquer ce raisonnement à des millions d'événements, sans fatigue.

Les types de règles de corrélation

• Seuil : « plus de N événements en T minutes » (par exemple, 10 échecs de connexion en 5 minutes).
• Séquence : « A puis B, dans cet ordre, dans un intervalle donné » (des échecs puis une réussite).
• Combinaison de sources : un événement sur l'annuaire et un événement sur le réseau pour la même identité.
• Anomalie : un comportement s'écarte de l'habituel pour ce compte ou cette machine (un horaire, un volume, une destination inhabituelle).
• Liste de référence : un événement implique un élément figurant dans une liste (une adresse connue comme hostile, un compte sensible).

Voici une règle en pseudo-code, lisible sans connaître la syntaxe d'un produit particulier :

REGLE "Echecs puis reussite sur un meme compte"
  SI   au moins 5 evenements "connexion echouee"
       pour le meme compte et la meme source
       en moins de 10 minutes
  PUIS 1 evenement "connexion reussie"
       pour ce compte et cette source
       dans les 10 minutes qui suivent
  ALORS alerte de gravite MOYENNE
        enrichie avec : service du compte, criticite du poste, heure locale
  EXCEPTIONS : comptes de test du laboratoire

Il existe aussi des formats de règles ouverts et indépendants des produits, qui permettent de partager des détections entre organisations : la communauté échange ainsi des règles de détection comme les développeurs échangent des bibliothèques.

Les conditions d'une bonne corrélation

Un SIEM ne vaut que par ce qu'on lui donne. Trois prérequis sont à vérifier avant d'écrire la moindre règle :

• Des horloges synchronisées. Si le serveur A a 3 minutes de retard sur le serveur B, la séquence « échec puis réussite » devient illisible. La synchronisation de l'heure (NTP) est un préalable banal et vital.
• Des journaux utiles. Beaucoup de systèmes ne journalisent pas, par défaut, ce qui intéresse un défenseur (créations de comptes, modifications de groupes, demandes de tickets). Il faut les activer, avec discernement : trop de journaux noient le signal et coûtent cher.
• Une identité cohérente. Pour relier « camille » sur l'annuaire et « c.martin » dans une application, il faut un identifiant commun ou une table de correspondance.

Le réglage : l'art de limiter les fausses alertes

Une règle neuve est presque toujours trop bruyante ou trop silencieuse. Le travail d'ingénierie de détection est un cycle :

1. écrire la règle en mode « observation » (elle enregistre sans alerter) ;
2. examiner ce qu'elle aurait signalé pendant quelques jours ;
3. ajouter les exceptions légitimes (comptes de service, tâches planifiées, outils d'administration connus) ;
4. ajuster les seuils ;
5. activer, puis réévaluer régulièrement.

Une règle qui génère 200 alertes par jour sera ignorée. Une règle réglée qui en génère trois, dont une vraie, sera lue. La qualité d'une détection se mesure à sa précision autant qu'à sa sensibilité.

Conservation et contrôle

Les journaux sont aussi des preuves : s'ils sont modifiables par l'attaquant, ils perdent leur valeur. On les envoie donc en temps réel vers un système distinct, dont l'accès est restreint, afin qu'un intrus qui efface les traces sur une machine ne puisse pas effacer la copie du SIEM. Leur durée de conservation est un compromis entre besoins d'enquête et respect de la vie privée : elle se fixe avec les équipes juridiques.

À vous de jouer

Rédigez en pseudo-code (comme l'exemple ci-dessus) deux règles de corrélation pour Atelier Boréal :

1. une règle de seuil sur la création de comptes ;
2. une règle de séquence mêlant un événement de messagerie et un événement de poste de travail (un courriel avec pièce jointe ouvert, puis un nouveau processus inhabituel lancé sur le même poste dans les minutes qui suivent).

Pour chacune, précisez une exception légitime possible.

REGLE "Creation en rafale de comptes"
  SI   plus de 3 evenements "compte cree"
       par le meme administrateur en moins de 15 minutes
  ALORS alerte de gravite MOYENNE
  EXCEPTIONS : arrivees planifiees (campagne de rentree) declarees par les RH

REGLE "Piece jointe ouverte puis processus inhabituel"
  SI   evenement messagerie "piece jointe ouverte" sur un poste
  PUIS evenement poste "nouveau processus rare dans l'entreprise"
       sur le meme poste dans les 5 minutes
  ALORS alerte de gravite HAUTE
  EXCEPTIONS : logiciels metier recemment deployes par l'equipe informatique