Skip to content

Response – From Signal to Action

Machine translation of the French original.

A detection that leads nowhere is useless. This page describes what happens after: who is notified and by what means, what the park does on its own, how an investigation is conducted during the incident, and how a serious incident is declared.

Technical terms refer to the glossary.

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. Notifying – One Path

Everything that needs to be notified is posted on a single switch, which duplicates to two messaging systems. There is a direct fallback in the case where the switch itself does not respond. The actions, formats, and potential pitfalls are described in the Cabling a Notification procedure.

Why one path: A third notification path is a third path to maintain, and it's always the one that's forgotten that goes silent when it's needed. An emitter does not know the destinations; when one changes, only the switch's map moves.

Three rules govern what is sent:

  1. Filter by rule ID. A filter by group sends out rules in sequence, creating duplicates. And the severity level also decides what is sent: a detection that has its own path must remain below the general integration threshold, otherwise it will arrive twice.
  2. Measure before arming. Every new detector first goes through a period of solo collection, with a pre-defined arming date. An alert is armed that you know the volume of, not an alert that you will discover the volume of.
  3. A recurring alert has a hysteresis and the duration of its series. "Still failing, for 3 days" reads; the same line repeated every hour no longer reads.

2. Acting Alone – The Automatic Response

A SIEM that detects, correlates, and notifies without ever taking action leaves a large window of time between the alert and when a human reads it – during the night, this window can be several hours.

Wazuh's automatic response has three actions:

Action What it does
Blocking a source Firewall rule placed on the host against the address that triggered the detection
Restarting a service For detections that indicate a service in an abnormal state
Isolating a container Cutting off its traffic with a dedicated rule, and sending a message to the dispatcher for a human to take over

And three constraints, which are more important than the actions:

  • Each action is linked to specific rule identifiers, never to a group: an automatic action should only be triggered on detections that have been read one by one.
  • Each block has a duration (timeout). A permanent block on a false positive is a mistake that we make, and the longer it lasts, the more we suffer from it.
  • The blocks apply to what the host actually sees. For web traffic, the container host sees the edge address, not the client address: CrowdSec, in the application layer, acts at this point. The SIEM's automatic response processes the sources that the host sees in real-time.

The witness. A probe reads the blocked and unblocked actions over a sliding week, and requires that there are no orphaned blocks – blocks that have been set, but never lifted. A broken unblocking mechanism is not seen otherwise: the blocks accumulate silently.

3. Investigating during the incident — Velociraptor

The SIEM collects data according to pre-defined rules. It does not answer the question that arises during an incident, and that was not anticipated: "Which binaries were launched on these three machines since yesterday?," "What connections are open now, and through which processes?" Without a tool, each machine investigates individually — and this takes time.

Velociraptor is the DFIR tool for the fleet: a server and a client on each machine — hypervisor, container hosts, GPU host, offsite server, and macOS workstation. A question is written in VQL and sent to the entire fleet at once (hunt).

Choice Why
Editor's signature verified before installation A tool that has control over all machines is the most valuable target for the fleet
Network and private mesh accessible only via local network interface There is no reason for it to be accessible over the internet
Connection via OIDC, reserved for the administrator account A single authority for identity, even here
Client limited in CPU and memory on the hypervisor An investigation should not slow down all virtual machines at the same time
Server certificate authority stored in two locations Losing it would require re-enrolling each client

The witness. A request for inventory launched on the entire fleet must return as many responses as there are clients. The tool distinguishes between two types of failures: a client that is absent (never enrolled, or uninstalled) and a client that is silent (enrolled, but no longer responding). The first can be corrected by enrolling, the second by investigating.

Useful requests in an incident are documented in a runbook, which is written before they are needed.

4. Declaration – The Incident Register

NIS2 imposes on relevant entities three deadlines for any significant incident: an early warning within 24 hours, a notification within 72 hours, and a final report within one month. The park is not subject to this directive; it applies the mechanism, because it forces an incident to be classified rather than left to drift in a discussion thread.

The register records the description, detection date, and classification. For a significant incident, it calculates the deadlines and marks any breaches. A probe monitors them.

What the register probe doesn't prove

It proves that the deadlines for declared incidents are met. It does not prove that a real incident was declared: an empty register passes. This limitation is written in the header of the probe itself – see Compliance.

Three distinct objects, which should not be confused:

Object What it contains
The incident note The account: what we saw, believed, and measured, and what was corrected
The ticket The status: open, resolved, and how to verify the resolution
The register The regulatory deadlines for a significant incident that has been classified

None of them replace the other two.

Next to read

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