Un outil de détection comme Wazuh produit beaucoup d’alertes. Une partie est répétée, une partie est sans danger, et les analystes passent une grande partie de leur temps à trier. L’agent cybersécurité de Cloud Inspire prend en charge ce tri et prépare le travail de l’analyste. Il n’agit jamais sur un système. L’analyste décide.
Cet article décrit comment l’agent est mis en place, comment il traite un incident, comment il retient les faux positifs, ce qui est automatisé, et où il se place dans votre organisation.
Où se place l’agent dans votre chaîne de sécurité
L’agent se place après vos outils de détection et à côté de votre ticketing. Il ne remplace ni votre SIEM, ni votre SOC, ni vos analystes.
| Étape | Outil | Qui agit |
|---|---|---|
| Détection | Wazuh, ou tout outil capable d’envoyer une alerte HTTP signée | L’outil de détection |
| Réception et regroupement | Plateforme Cloud Inspire | La plateforme |
| Ticket | Chatwoot | La plateforme ouvre le ticket |
| Lecture et note d’orientation | Plateforme Cloud Inspire | L’agent cybersécurité |
| Qualification et décision | Console de la plateforme | L’analyste |
| Confinement et correction | Vos outils, ou votre pipeline GitLab CI | Votre équipe ou votre pipeline, après décision |
La même plateforme porte l’agent IA SRE pour les incidents d’exploitation. Les deux partagent le même circuit : ticket, équipe, délai, procédure, compte rendu.
La mise en place
1. Installer la plateforme
La plateforme s’installe sur des machines que vous fournissez, sur votre site ou dans un environnement privé opéré par Cloud Inspire. Aucun accès entrant n’est demandé depuis Internet. Le modèle d’IA est celui de votre choix, y compris un modèle open source hébergé chez vous (Ollama). Le détail des prérequis est dans l’article L’agent IA SRE en pratique.
2. Brancher la source d’alertes
Un administrateur crée une source d’alertes pour Wazuh. La source a sa propre clé de signature. Un script d’intégration Wazuh est fourni : il envoie chaque alerte à la plateforme par une requête HTTP signée. Une alerte non signée est refusée, et le débit est limité par source.
La correspondance entre la gravité Wazuh et la priorité du ticket se règle sur la source.
3. Créer le bot de type Cybersécurité
Le réglage conseillé est le suivant :
- Mode Observation. Le bot écrit uniquement des notes privées. Sur un ticket ouvert par une alerte, il ne peut de toute façon jamais écrire à l’extérieur.
- Outils limités à la lecture, à la note privée et au transfert à un humain.
- Base de connaissances : vos playbooks d’incident et vos procédures SOC. C’est dans ces documents que l’agent puise ses recommandations.
- Actions du Copilot : le jeu « cyber », qui permet à l’analyste de demander une analyse, de préparer une escalade ou de faire proposer un confinement.
4. Définir les équipes et les délais
Les équipes (analystes de premier niveau, experts, astreinte) et les politiques de délai avec leurs paliers d’escalade se règlent comme pour tout autre ticket.
Le traitement d’un incident : des tentatives de connexion répétées
Le scénario suivant est un exemple.
1. Les alertes arrivent. Wazuh détecte des échecs de connexion SSH répétés sur un serveur exposé. Il envoie une alerte, puis la même alerte à chaque nouvelle série d’échecs.
2. Elles sont regroupées. Les alertes identiques (même empreinte) forment un seul incident, donc un seul ticket. L’analyste ne reçoit pas cinquante tickets pour la même attaque.
3. Les détails sont extraits. La plateforme extrait la règle Wazuh, l’agent Wazuh concerné, les adresses IP, les comptes utilisateurs visés et les techniques MITRE ATT&CK. Elle pose une étiquette par technique, ici attck-t1110 (attaque par force brute). L’analyste peut filtrer les incidents par règle, par machine ou par technique.
4. L’agent écrit une note d’orientation. L’agent cybersécurité lit l’alerte et vos playbooks. Il écrit une note privée sur le ticket avec :
- les indicateurs relevés (adresses, comptes, fréquence) ;
- une gravité estimée ;
- des pistes d’investigation ;
- des mesures de confinement proposées, par exemple bloquer l’adresse source sur le pare-feu ou désactiver un compte visé.
5. L’analyste décide. L’analyste lit la note, vérifie, et décide. Il peut interroger l’agent à tout moment en l’appelant par @cyber dans une note privée. Le confinement est une proposition écrite : c’est l’analyste ou votre équipe qui l’applique, avec vos outils.
6. Le ticket est suivi jusqu’au bout. Le délai et les escalades s’appliquent comme pour tout ticket. Si l’analyste ne traite pas l’alerte, elle n’est pas perdue (voir « Rattrapage » plus bas).
Les faux positifs : appris par l’analyste, jamais décidés par l’IA
Une partie des alertes est sans danger : un scanner de vulnérabilités interne, une tâche planifiée, un compte de service mal configuré. Sans mémoire, la même alerte revient et un analyste refait la même analyse.
Le fonctionnement est le suivant :
- Sur le ticket, l’analyste clique sur Marquer comme faux positif et écrit un motif, par exemple « scan hebdomadaire de l’outil de vulnérabilités interne ».
- L’incident est fermé et le ticket résolu, avec une note privée.
- Les prochaines alertes identiques (même source, même empreinte) ouvrent toujours un ticket, mais en priorité basse, sans escalade de délai, avec l’étiquette
faux-positif-connuet le motif de l’analyste cité dans le ticket.
Trois garde-fous encadrent ce mécanisme :
- Aucun modèle d’IA ne décide qu’une alerte est un faux positif. La correspondance se fait uniquement sur la source et l’empreinte de l’alerte.
- Rien n’est supprimé. Chaque occurrence reste visible et traçable.
- Un manager relit et peut annuler. La page « Faux positifs appris » montre chaque qualification, son motif, son auteur, sa date et le nombre d’alertes couvertes depuis. Si une qualification est annulée, les alertes suivantes reprennent leur priorité normale et leur délai.
La même page indique la part des alertes reçues sur 30 jours qui correspondaient à un faux positif déjà qualifié, au total et par source. C’est une mesure de votre bruit, propre à votre environnement.
Rattrapage : aucune alerte oubliée
L’écran Rattrapage liste trois types d’alertes :
- celles qui n’ont jamais été traitées ;
- celles qui se répètent ;
- celles qui n’ont plus reçu de nouvel événement, et qu’il faut peut-être fermer.
Un manager le consulte pour vérifier que rien ne reste ouvert sans responsable.
Ce qui est automatisé, et ce qui reste à l’analyste
| Automatisé par la plateforme | Fait par l’agent cybersécurité | Décidé par une personne |
|---|---|---|
| Vérification de la signature des alertes | Lecture de l’alerte et des playbooks | La qualification de l’incident |
| Regroupement des alertes identiques | Note d’orientation : indicateurs, gravité estimée, pistes | Le marquage d’un faux positif |
| Extraction des IP, comptes, règles et techniques ATT&CK | Proposition écrite de confinement | Le confinement et la correction |
| Priorité, équipe, délai, escalades | Préparation d’une escalade, à la demande | L’annulation d’une qualification |
| Traitement des faux positifs déjà qualifiés | Réponses aux questions de l’analyste (@cyber) | La publication d’une procédure |
Pour aller plus loin dans l’automatisation, un runbook peut lancer un pipeline GitLab que vous avez déclaré, par exemple pour ajouter une règle de blocage. Ce lancement peut être réglé en manuel : l’analyste voit la cible et chaque paramètre avant de cliquer. C’est votre pipeline qui agit, pas la plateforme.
Ce que l’agent ne fait pas : il n’isole pas de poste, ne bloque rien lui-même, ne reconfigure aucun outil et ne lit pas les journaux bruts de vos équipements.
La veille sur les avis de sécurité
Les alertes ne couvrent pas tout. Une faille publiée par un éditeur peut toucher vos systèmes avant toute attaque.
Cette veille est assurée par l’équipe Cloud Inspire. Nous suivons les avis du CERT-EU et des éditeurs des logiciels que vous utilisez. Pour chaque avis critique, nous vérifions dans votre inventaire quels services utilisent la version concernée. Chaque service touché devient un ticket, traité dans le même circuit : priorité, équipe, délai, correction par pipeline, rapport.
Les alertes de vulnérabilité produites par Wazuh sur vos machines arrivent, elles, directement comme les autres alertes.
L’article Failles critiques PHP (CERT-EU 2026-018) montre ce circuit sur un cas réel.
La traçabilité : des preuves pour vos audits
La plateforme ne garantit pas, à elle seule, le respect d’une réglementation. Elle conserve en revanche les éléments qu’un contrôle demande sur la gestion des incidents de sécurité :
- l’historique de chaque alerte et de chaque ticket : réception, regroupement, priorité, équipe, escalades ;
- la note de l’agent et la décision de l’analyste ;
- chaque qualification de faux positif, avec son auteur et son motif, et chaque annulation, inscrites dans le journal d’audit ;
- les actions lancées par pipeline, avec leurs paramètres et leur résultat.
Ces éléments aident à préparer les contrôles liés à NIS2 et à DORA, qui demandent de détecter, traiter et documenter les incidents. Voir nos guides NIS2 et DORA.
Pour aller plus loin
- La page Cybersécurité présente l’offre complète.
- Vous voulez voir l’agent sur vos propres alertes Wazuh ? Réservez 30 minutes avec un ingénieur sécurité.