Wazuh et Shuffle SOAR : préparer un confinement maîtrisé

Une alerte détectée vite ne suffit pas si personne ne peut décider quoi faire. À l’inverse, isoler automatiquement tous les équipements associés à une alerte peut provoquer une panne. Wazuh et Shuffle permettent de relier détection et orchestration. Le travail essentiel consiste à définir les conditions d’action, ses limites et la vérification du résultat.

1. Choisir un scénario limité

Le SOAR désigne l’orchestration, l’automatisation et la réponse en sécurité. Pour un premier pilote, choisissez un poste de laboratoire et une action réversible. Commencez par enrichir l’alerte et proposer un confinement à un opérateur. Les contrôleurs de domaine, systèmes industriels, serveurs de sauvegarde et équipements vitaux doivent faire l’objet de règles distinctes, pas d’un automatisme générique.

L’article Wazuh sur l’intégration Shuffle décrit le transfert d’alertes via webhook et un exemple d’orchestration. Il fournit un point de départ documentaire, pas une preuve que votre connecteur de confinement, votre réseau et vos permissions fonctionnent. Relevez les versions Wazuh, Shuffle et des applications d’intégration, puis vérifiez la compatibilité.

2. Dessiner les frontières de confiance

Protégez le point d’entrée, les secrets et les communications. Ne placez pas une URL de webhook sensible dans une capture publique. Une alerte contient parfois des valeurs contrôlées par un attaquant, comme un nom de fichier : ne les injectez pas dans une commande shell. Le workflow doit sélectionner une action connue avec des paramètres validés.

L’identité technique du connecteur ne doit pas disposer de tous les droits d’administration pour isoler un seul poste pilote. Limitez les ressources accessibles et vérifiez les possibilités d’arrêt manuel. Prévoyez aussi le comportement si Shuffle, l’annuaire ou l’API de réponse deviennent indisponibles.

3. Formaliser les états du workflow

La déduplication empêche de traiter plusieurs fois le même événement comme autant de nouvelles décisions. Utilisez un identifiant d’événement et un identifiant d’actif stables, avec une fenêtre documentée. L’idempotence signifie qu’une répétition ne doit pas produire d’effet supplémentaire indésirable. Ce comportement doit être testé ; il ne vient pas automatiquement de l’outil SOAR.

Fixez un nombre maximal d’actions, un délai d’approbation et une règle d’arrêt en cas de volume inhabituel. Une absence de réponse humaine ne vaut pas approbation. Si le connecteur retourne un succès technique, interrogez ensuite l’état ou utilisez la preuve prévue pour confirmer l’effet.

4. Distinguer blocage réseau et isolement

Bloquer une adresse IP dans un pare-feu local ne signifie pas isoler un poste de tous les autres systèmes. L’adresse peut être partagée, changer ou ne représenter qu’un flux. Définissez exactement ce que fait votre action : destinations bloquées, trafic encore autorisé, durée et moyen de joindre l’agent de sécurité.

L’isolement doit préserver les communications nécessaires à la supervision et à la sortie du confinement si l’outil fonctionne ainsi. Testez également le cas où l’agent n’est plus joignable. La procédure doit indiquer comment intervenir localement ou via un accès de secours autorisé. Un temporisateur de règle ne suffit pas à garantir la reprise.

Ne programmez pas une libération inconditionnelle d’un poste simplement parce qu’une durée expire. À l’échéance, réévaluez son état et faites décider l’opérateur. Une action temporaire doit avoir une durée de revue, un propriétaire et un mécanisme de restauration éprouvé.

5. Recette avant toute action automatique

• Injecter une alerte synthétique de laboratoire sans déclencher une vraie attaque.
• Vérifier la réception, le filtrage et l’identification de la cible pilote.
• Envoyer un doublon, une alerte ancienne et un identifiant inconnu : aucune action non prévue ne doit partir.
• Tester une cible exclue et une approbation expirée.
• Simuler un refus API, un délai dépassé et un état de confinement inconnu.
• Après approbation, vérifier l’effet réseau exact et la conservation du canal de gestion prévu.
• Faire autoriser puis vérifier la sortie du confinement et le fonctionnement du poste.

Mesurez le temps entre réception, qualification, décision et effet confirmé. Conservez les faux positifs et les interruptions métier. Le critère de réussite n’est pas seulement « le workflow est vert », mais « la bonne action a touché la bonne cible, avec une preuve et une reprise possible ».

6. Déploiement progressif et retour arrière

Passez d’abord par un mode d’observation, puis un pilote avec approbation. Une automatisation sans validation humaine ne se discute qu’après des résultats stables sur un scénario précis et un périmètre accepté. Gardez la possibilité de suspendre les actions sans perdre la réception des alertes.

Le retour arrière désactive le déclenchement des réponses, révoque si nécessaire le droit du connecteur et traite les actions déjà engagées une par une. Rétablir le workflow précédent ne libère pas forcément les équipements. Ce guide décrit un workflow conceptuel. Adaptez et vérifiez les connecteurs, les champs et les droits pour votre propre environnement.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Wazuh - Intégration avec Shuffle
• Shuffle - Projet et documentation
• Wazuh - Automatisation du reporting et de la réponse