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 :
- 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.
- 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.
- 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¶
- Détection — d'où viennent les signaux.
- Continuité — quand l'incident a détruit quelque chose.
- Câbler une notification — le geste.
Dernière vérification de cette page : 2026-09-11