Aller au contenu

Réponse — du signal à l'action

Une détection qui n'aboutit à rien n'a servi à rien. Cette page décrit ce qui se passe après : qui est prévenu et par quel chemin, ce que le parc fait tout seul, comment on enquête pendant l'incident, et comment un incident sérieux est déclaré.

Les termes techniques renvoient au glossaire.

sequenceDiagram
    autonumber
    participant D as Détecteur
    participant S as SIEM
    participant R as Réponse automatique
    participant H as Répartiteur d'alertes
    participant O as Opérateur
    participant V as Investigation à chaud
    participant I as Registre d'incidents

    D->>S: événement
    S->>S: règle → identifiant → niveau
    alt règle liée à une action
        S->>R: blocage, redémarrage ou isolement
        Note over R: toujours avec une durée :<br/>le blocage se lève seul
    end
    S->>H: alerte filtrée par identifiant de règle
    H->>O: deux messageries, un seul envoi
    O->>V: question posée à toute la flotte
    V-->>O: une réponse par machine
    opt incident important
        O->>I: déclaration datée
        I-->>O: échéances 24 h · 72 h · 1 mois
    end

1. Notifier — un seul chemin

Tout ce qui doit prévenir quelqu'un poste sur un répartiteur unique, qui duplique vers deux messageries. Un repli direct existe pour le seul cas où le répartiteur lui-même ne répond pas. Le geste, les formats et les pièges sont dans la procédure Câbler une notification.

Pourquoi un seul chemin : un troisième chemin de notification est un troisième chemin à maintenir, et c'est toujours celui qu'on a oublié qui se tait le jour où il servirait. Un émetteur ne connaît pas les destinations ; quand l'une change, seule la carte du répartiteur bouge.

Trois règles gouvernent ce qui part :

  1. Filtrer par identifiant de règle. Un filtre par groupe embarque des règles voisines et poste des doublons. Et le niveau de sévérité décide, lui aussi, de ce qui part : une détection qui a son propre chemin doit rester sous le seuil de l'intégration générale, sinon elle arrive deux fois.
  2. Mesurer avant d'armer. Tout nouveau détecteur passe d'abord par une période de collecte seule, avec une date d'armement fixée d'avance. On arme une alerte dont on connaît le volume, pas une alerte dont on découvrira le volume.
  3. Une alerte récurrente porte une hystérésis et la durée de sa série. « Toujours en échec, depuis 3 jours » se lit ; la même ligne répétée toutes les heures ne se lit plus.

2. Agir tout seul — la réponse automatique

Un SIEM qui détecte, corrèle et notifie sans jamais agir laisse ouverte toute la fenêtre entre l'alerte et le moment où un humain la lit — la nuit, cette fenêtre se compte en heures.

La réponse automatique de Wazuh dispose de trois gestes :

Geste Ce qu'il fait
Blocage d'une source Règle de pare-feu posée sur l'hôte contre l'adresse qui a déclenché la détection
Redémarrage d'un service Pour les détections qui signalent un service dans un état anormal
Isolement d'un conteneur Coupure de son trafic par une règle dédiée, et message au répartiteur pour qu'un humain prenne la suite

Et trois contraintes, qui comptent plus que les gestes :

  • Chaque geste est lié à des identifiants de règle précis, jamais à un groupe : une action automatique ne doit se déclencher que sur des détections qu'on a lues une par une.
  • Chaque blocage porte une durée (timeout). Un blocage permanent sur un faux positif est une panne qu'on s'inflige, et elle est d'autant plus longue que personne ne sait qu'elle existe.
  • Les blocages portent sur ce que l'hôte voit réellement. Pour le trafic web, l'hôte de conteneurs voit l'adresse de la bordure, pas celle du client : c'est CrowdSec, en couche applicative, qui agit à cet endroit. La réponse automatique du SIEM traite les sources que l'hôte voit en direct.

Le témoin. Une sonde relit sur une semaine glissante les blocages posés et les blocages levés, et exige qu'il n'existe aucun blocage orphelin — posé, jamais levé. Un mécanisme de levée cassé ne se voit pas autrement : les blocages s'accumulent en silence.


3. Enquêter pendant l'incident — Velociraptor

Le SIEM collecte selon des règles posées d'avance. Il ne répond pas à la question qu'on se pose pendant l'incident, et qu'on n'avait pas prévue : « quels binaires se sont lancés sur ces trois machines depuis hier ? », « quelles connexions sont ouvertes, maintenant, et par quels processus ? ». Sans outil, chaque machine s'interroge à la main, une par une — et c'est la durée de l'enquête qui en paie le prix.

Velociraptor est l'outil de DFIR du parc : un serveur, et un client sur chaque machine — hyperviseur, hôtes de conteneurs, hôte GPU, serveur hors site et poste macOS. Une question s'écrit en VQL et part vers toute la flotte en une fois (hunt).

Choix Pourquoi
Signature de l'éditeur vérifiée avant l'installation Un outil qui a la main sur toutes les machines est la cible la plus rentable du parc
Interface joignable du réseau local et du maillage privé seulement, sans nom public Pas de raison qu'Internet la connaisse
Connexion par OIDC, réservée au compte d'administration Une seule autorité d'identité, même ici
Client bridé en processeur et en mémoire sur l'hyperviseur Une enquête ne doit pas ralentir toutes les machines virtuelles à la fois
Autorité de certification du serveur sauvegardée à deux endroits La perdre obligerait à ré-enrôler chaque client

Le témoin. Une requête d'inventaire lancée sur toute la flotte doit rendre autant de réponses que de clients. La sonde distingue deux pannes qui se ressemblent : un client absent (jamais enrôlé, ou désinstallé) et un client muet (enrôlé, mais qui ne répond plus). La première se corrige par un enrôlement, la seconde par une enquête.

Les requêtes utiles en incident sont consignées dans un runbook, écrit avant d'en avoir besoin.


4. Déclarer — le registre d'incidents

NIS2 impose aux entités concernées, pour tout incident important, trois échéances : une alerte précoce sous 24 heures, une notification sous 72 heures, un rapport final sous un mois. Le parc n'est pas soumis à la directive ; il applique la mécanique, parce qu'elle force à qualifier un incident au lieu de le laisser se dissoudre dans un fil de discussion.

Le registre recueille l'intitulé, la date de détection et la qualification. Pour un incident important, il calcule les échéances et marque tout dépassement. Une sonde les surveille.

Ce que la sonde du registre ne prouve pas

Elle prouve que les échéances des incidents déclarés sont tenues. Elle ne prouve pas qu'un incident réel a été déclaré : un registre vide passe. Cette limite est écrite dans l'en-tête de la sonde elle-même — voir Conformité.

Trois objets distincts, à ne pas confondre :

Objet Ce qu'il porte
La note d'incident Le récit : ce qu'on a vu, cru, mesuré, corrigé
Le ticket L'état : ouvert, résolu, et la façon de vérifier la résolution
Le registre Les échéances réglementaires d'un incident qualifié d'important

Aucun ne remplace les deux autres.


À lire ensuite

Dernière vérification de cette page : 2026-09-11