Comment calibrer les alertes d’un SIEM sans noyer le SOC

Un SIEM (Security Information and Event Management) ne protège rien par le seul fait qu’il ingère des journaux. Il arbitre entre deux erreurs coûteuses : déclencher une alerte inutile ou manquer une activité hostile. Le compromis central est là : augmenter la sensibilité réduit les ratés, mais paie cette réduction en bruit opérationnel.

→ Lire l’explication complète de la marmotte

Taux de base et fausses alertes dans un SIEM

Une règle de détection produit une décision à partir d’indices observables : une connexion inhabituelle, une élévation de privilège, une extraction massive de données, une commande suspecte. Sa sensibilité est la proportion de menaces réelles détectées. Sa spécificité est la proportion d’activités légitimes correctement écartées. Ces deux propriétés ne disent pas ce que voit l’analyste dans sa file.

La mesure qui compte est la valeur prédictive positive : parmi les alertes reçues, quelle part correspond réellement à une menace ? Elle dépend de la qualité de la règle, mais surtout de la prévalence de l’événement recherché. Une compromission active reste rare par rapport au volume de connexions, processus, requêtes et authentifications légitimes. C’est le problème du taux de base.

Prenons une détection avec 99 % de sensibilité et 99 % de spécificité. Sur 100 000 événements, supposons 10 activités réellement malveillantes. La règle détecte environ 10 menaces, mais classe aussi à tort 1 % des 99 990 événements bénins, soit environ 1 000 faux positifs. La probabilité qu’une alerte soit une vraie menace tombe sous 1 %. La règle est excellente sur une slide. Dans une file d’alertes, elle devient une machine à trier du gravier.

Le seuil de déclenchement doit donc être lié au coût d’investigation et à la prévalence attendue. Une alerte d’exécution de code sur un contrôleur de domaine peut accepter une forte sensibilité : le contexte est rare, l’impact est élevé, l’investigation est justifiée. Une alerte sur chaque échec d’authentification Internet n’a aucun droit à la même tolérance, sauf à transformer le SOC (Security Operations Center) en centre d’observation des erreurs de frappe.

Le taux de base varie selon le périmètre. Une commande PowerShell lancée sur un poste bureautique, sur un serveur d’administration et dans une chaîne d’intégration continue n’a ni la même fréquence normale ni le même risque. Une règle globale sans enrichissement de contexte mesure surtout l’incapacité du SIEM à connaître son terrain.

Les menaces et mécanismes d’attaque donnent le vocabulaire de l’adversaire. La détection, elle, doit partir des actifs critiques, des identités à privilèges et des chemins d’accès réels. Sans inventaire fiable, on règle des seuils sur une silhouette dans le brouillard.

Calibrage des seuils et coût des erreurs

Le seuil est la valeur à partir de laquelle un score, un compteur ou une séquence d’événements devient une alerte. Le monter diminue les faux positifs et augmente les faux négatifs. Le baisser fait l’inverse. Aucun seuil n’est objectivement bon : il est bon pour une capacité de traitement, un niveau de risque et une source de télémétrie donnés.

La recommandation est nette : calibrer d’abord les règles existantes avant d’en ajouter. Une règle non évaluée ne devient pas meilleure parce qu’elle est accompagnée de cinquante cousines. Elle devient plus difficile à attribuer, à corriger et à désactiver. L’accumulation de règles est le stockage objet de la détection : infiniment extensible jusqu’au jour où quelqu’un doit retrouver ce qui a produit l’alerte.

Pour chaque règle, définir quatre éléments avant activation :

L’hypothèse de menace : comportement détecté, actif visé et impact plausible.
Le signal attendu : sources, champs, horodatage, identifiant de corrélation et qualité connue des données.
La décision attendue : enrichissement automatique, triage humain, blocage ou ouverture d’incident.
Le budget d’erreur : volume maximal d’alertes injustifiées acceptable et délai maximal de traitement.

Une règle de seuil brut est rarement stable. Compter dix échecs de connexion en cinq minutes est défendable seulement si le compte, l’adresse source, la destination et la plage horaire sont corrélés. Sinon, une passerelle d’authentification mal configurée, un robot d’inventaire ou une migration oubliée produisent une tempête parfaitement légitime. Le SIEM ne distingue pas une attaque d’une panne par intuition mystique.

Préférer les seuils relatifs aux seuils absolus lorsque le comportement varie selon l’entité. Une extraction de données peut être anormale à cinq fois la médiane habituelle d’un compte, alors qu’un seuil fixe pénalise les utilisateurs intensifs et ignore les comptes peu actifs. Cette approche exige toutefois un historique représentatif et une exclusion des périodes de changement connu. Un modèle statistique nourri de migrations et de tests de charge apprend surtout à admirer le chaos.

Mesurer la fatigue d’alerte du SOC

La fatigue d’alerte n’est pas une impression recueillie à la machine à café. Elle se mesure par le comportement de la file et par la qualité des décisions. Le premier indicateur est le taux de faux positifs traités :

\text{taux de faux positifs} = \frac{\text{alertes closes bénignes}}{\text{alertes investiguées}}

Cette métrique doit être ventilée par règle, source, criticité et équipe de traitement. Un taux global masque facilement une règle toxique noyée dans un ensemble raisonnable. Une règle qui génère 80 % d’alertes bénignes mais seulement 5 % du volume total mérite une correction ; une règle qui génère 80 % du volume mérite une interruption immédiate, le temps de comprendre.

Mesurer ensuite le délai médian avant abandon : durée entre la création d’une alerte et sa fermeture automatique, sa clôture sans action, ou son dépassement de délai de traitement. Il ne s’agit pas du temps moyen de résolution, souvent amélioré artificiellement par la fermeture rapide des alertes pénibles. Il s’agit de détecter le moment où la file apprend à ignorer un signal.

Suivre aussi ces indicateurs :

proportion d’alertes sans enrichissement consulté ;
proportion d’alertes clôturées avec le même motif générique ;
âge du 95e percentile des alertes ouvertes ;
taux de réouverture après clôture bénigne ;
nombre d’alertes corrélées à un incident confirmé ;
ratio entre alertes créées et alertes ayant conduit à une action de confinement.

Un accroissement simultané du délai d’abandon, des clôtures génériques et de l’âge de file indique une saturation. Ajouter des règles à ce stade ne renforce pas la couverture, il augmente la probabilité qu’une alerte prioritaire disparaisse sous les alertes décoratives. La fatigue n’est pas un problème de motivation individuelle ; c’est une défaillance de conception du système de décision.

Exemple reproductible de seuils et valeur prédictive

Le script suivant simule 100 000 événements, dont 10 malveillants. Il compare trois seuils d’un score de détection. Il ne modélise pas un environnement réel, mais expose l’effet du taux de base sans vendre de poudre statistique.

# Python 3, aucune dépendance externe.
# Les scores bénins et malveillants se chevauchent volontairement.
import random

random.seed(42)

evenements = []
for _ in range(99_990):
    evenements.append(("benin", random.gauss(35, 15)))

for _ in range(10):
    evenements.append(("malveillant", random.gauss(75, 15)))

for seuil in (50, 65, 80):
    vrais_positifs = faux_positifs = faux_negatifs = 0

    for etiquette, score in evenements:
        alerte = score >= seuil
        if etiquette == "malveillant" and alerte:
            vrais_positifs += 1
        elif etiquette == "benin" and alerte:
            faux_positifs += 1
        elif etiquette == "malveillant":
            faux_negatifs += 1

    total_alertes = vrais_positifs + faux_positifs
    precision = vrais_positifs / total_alertes if total_alertes else 0
    print(
        f"seuil={seuil}, alertes={total_alertes}, "
        f"vrais_positifs={vrais_positifs}, faux_positifs={faux_positifs}, "
        f"faux_negatifs={faux_negatifs}, precision={precision:.2%}"
    )

Le seuil bas détectera davantage de comportements malveillants, mais sa précision chutera. Le seuil haut réduira la file, avec davantage de menaces manquées. En production, remplacer les étiquettes simulées par des verdicts d’investigation documentés, puis calculer les mêmes valeurs sur une période stable. Sans verdict fiable, ajuster un seuil revient à régler une balance sans savoir ce qui pèse sur les plateaux.

Exploitation : données, rétention et reprise

Un SIEM dépend de ses sources. Une règle sur les authentifications ne garantit rien si les échecs ne sont pas collectés, si les horloges divergent ou si l’identifiant de session disparaît pendant la normalisation. La détection ne compense pas une journalisation absente. Les fondations d’architecture doivent inclure synchronisation horaire, inventaire des sources, schémas de champs versionnés et contrôle de complétude.

Les accès au SIEM sont eux-mêmes une surface d’attaque. Une compromission de compte analyste permet de masquer des alertes, d’altérer des règles ou de consulter des journaux contenant des secrets, des jetons et des données personnelles. Imposer une authentification forte, séparer administration de plateforme et traitement opérationnel, journaliser les modifications de règles et protéger les comptes de service. Les identités d’administration relèvent des mêmes exigences que les autres systèmes critiques, détaillées dans la section identités.

Sauvegarder les règles, listes d’exclusion, tableaux de bord, pipelines de normalisation et paramètres de rétention dans un dépôt versionné. Une sauvegarde des seuls événements ne restaure pas la capacité de détection : sans règles ni enrichissements, elle restaure une benne de données. Tester la reprise avec une source représentative, des horodatages réalistes et une vérification explicite des alertes attendues.

Enfin, une règle ne garantit ni l’absence d’attaque ni l’exhaustivité des journaux. Un adversaire peut vivre sur des identifiants valides, désactiver une source, chiffrer un canal ou utiliser un comportement indiscernable d’une activité autorisée. Le reste doit venir du durcissement, du contrôle d’accès, de la segmentation, de la sauvegarde et de la réponse à incident. Détecter tard reste préférable à ne jamais détecter, mais empêcher vaut mieux que documenter élégamment le désastre.

🐝 Ce qui arrive si on s’en passe

Sans calibrage, la file d’alertes continue de fonctionner, mais elle cesse d’être une source de preuve. Les alertes vieillissent au-delà de la durée de rétention des journaux : quand un ticket est enfin ouvert, les événements bruts qui l’ont déclenché ont déjà été purgés, et la reconstitution de la chronologie d’un incident devient impossible. Les clôtures génériques privent l’organisation de verdicts exploitables, donc de toute mesure des faux négatifs : la couverture réelle reste inconnue, et aucune règle ne peut être corrigée faute de retour. Les exclusions ajoutées dans l’urgence pour faire taire une règle bruyante s’accumulent sans trace ni revue, créant des angles morts permanents qu’aucun tableau de bord ne signale. Enfin, un attaquant utilisant des identifiants valides produit exactement le type de signal que la file a appris à fermer sans lecture.

🦫 Explication de la marmotte 🍫

Un système de surveillance reçoit beaucoup d’événements : connexions, lancements de programmes, modifications de fichiers et accès à des données. Il applique des règles pour décider lesquels méritent une alerte. Une règle peut repérer la plupart des attaques, tout en signalant aussi beaucoup d’actions normales. Le problème vient du fait que les attaques sont rares. Même avec peu d’erreurs, les actions normales sont si nombreuses que les fausses alertes peuvent dépasser largement les vraies.

Un seuil décide à partir de quel niveau une activité devient suspecte. Si ce seuil baisse, davantage d’attaques sont repérées, mais la quantité de fausses alertes augmente. S’il monte, les analystes reçoivent moins d’alertes inutiles, mais certaines attaques passent inaperçues. Le bon réglage dépend de la gravité du risque, de la capacité de l’équipe à enquêter et de la qualité des informations collectées.

Pour savoir si le système fatigue l’équipe, il faut compter les alertes bénignes, mesurer celles qui sont fermées sans enquête et observer le temps passé avant qu’une alerte soit abandonnée. Une règle qui produit surtout des erreurs doit être corrigée ou arrêtée. Ajouter plus de règles sans vérifier les anciennes augmente le bruit. Enfin, la surveillance échoue si les événements manquent, si les heures sont fausses ou si un attaquant peut modifier les réglages.