Clôturer une alerte SOC : verdict, action et vérification ne sont pas le même statut
Une alerte fermée n’est pas forcément un incident résolu. Séparez qualification, résultat des actions et clôture du dossier pour garder des décisions vérifiables.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un analyste ferme une alerte après un échange avec l’équipe informatique. Le lendemain, le compte rendu indique « incident résolu ». Pourtant, l’échange confirmait seulement que quelqu’un allait examiner la demande.
Cet exemple fictif illustre un problème simple : un même mot, « fermé », peut désigner la fin du travail dans une file, une qualification de sécurité ou la réussite d’une correction. Ces trois décisions ne sont pas équivalentes.
Notre recommandation : les séparer, même si votre outil ne dispose que d’un seul champ de statut. Quelques informations structurées valent mieux qu’une clôture que chacun interprète différemment.
Trois questions avant de cliquer sur « Fermer »
La première concerne le verdict : que permettent de conclure les éléments examinés ? Une activité suspecte peut être confirmée, expliquée par une opération autorisée, attribuée à une erreur de détection ou rester indéterminée.
La deuxième concerne l’action : une mesure était-elle nécessaire, qui l’a exécutée et quel résultat a été constaté ? Une demande de désactivation envoyée n’est pas une désactivation vérifiée. Une commande acceptée n’est pas toujours la preuve que son effet attendu est obtenu.
La troisième concerne le dossier : pourquoi peut-on arrêter son traitement dans cette file ? L’activité a-t-elle été expliquée, le travail transféré à un autre responsable, le risque accepté par une personne habilitée, ou la résolution vérifiée ?
Pour les incidents nécessitant un rétablissement, le NIST SP 800-61 révision 3 prévoit une fin de récupération fondée sur des critères et une documentation achevée, notamment sous RC.RP-06. Il ne prescrit pas les trois champs proposés ici : cette séparation est une recommandation opérationnelle. Source : NIST
Ne transformez pas tous les dossiers non malveillants en faux positifs
Une règle peut détecter exactement le comportement attendu, alors que ce comportement appartient à une opération autorisée. La règle n’est pas nécessairement incorrecte.
Microsoft Sentinel distingue, dans sa documentation de clôture, l’activité suspecte, l’activité suspecte mais attendue, les erreurs de logique ou de données, et la qualification indéterminée. Ces catégories illustrent pourquoi un seul libellé « faux positif » appauvrit le retour vers l’ingénierie de détection. Elles ne constituent pas une taxonomie universelle à imposer à tous les outils. Source : Microsoft Learn
Adaptez votre vocabulaire, mais gardez ces distinctions :
- Test confirmé : le responsable de l’exercice confirme l’opération ; sa période, ses cibles et les événements observés concordent. La simple présence d’un nom d’outil de test ne suffit pas.
- Activité autorisée et expliquée : l’autorisation couvre l’opération réellement observée, pas seulement le compte utilisé.
- Erreur de détection démontrée : une condition de règle ou une donnée incorrecte explique l’alerte. Le correctif peut faire l’objet d’un suivi distinct.
- Indéterminé : les éléments ne permettent pas de trancher. Cette conclusion n’équivaut ni à une compromission confirmée, ni à une activité sûre.
Cette précision évite aussi de dégrader une règle utile pour faire baisser artificiellement le volume de dossiers.
Une matrice courte pour décider
Sur écran étroit, faites défiler le tableau horizontalement pour lire les trois colonnes.
| Situation observée | Conclusion défendable | Ce qui manque éventuellement |
|---|---|---|
| L’équipe confirme un exercice et les traces correspondent | Test confirmé sur le périmètre recoupé | Examiner les événements hors de ce périmètre |
| Une correction a été annoncée, sans résultat vérifié | Correction déclarée, vérification en attente | Contrôle de l’effet attendu et responsable de ce contrôle |
| Un prestataire a accusé réception | Demande reçue | Prise en charge explicite, décision ou résultat |
| Une recherche ne retourne rien, mais une source manque | Aucun résultat dans le périmètre consulté | Limite de visibilité à conserver dans la conclusion |
| Le responsable habilité accepte un risque documenté | Traitement décidé avec risque résiduel accepté | Référence de décision, portée et conditions de réexamen |
La matrice est une proposition de fonctionnement, pas une description des capacités d’un produit. Elle s’applique avec un SIEM, un EDR, un outil de tickets ou un dossier d’investigation séparé.
Fermer une tâche sans faire disparaître le reste
Un SOC peut avoir terminé sa qualification alors qu’une équipe technique poursuit la correction. Il peut alors terminer sa propre tâche selon le processus convenu, à condition de ne pas annoncer que l’incident entier est résolu.
Avant cette transition, reliez le dossier à l’action restante, nommez son propriétaire et conservez le critère qui permettra d’en constater la fin. Un transfert simplement envoyé reste différent d’un transfert effectivement pris en charge.
Inversement, l’absence d’un message de résolution ne prouve pas qu’un incident est encore ouvert. Consultez la source de suivi faisant autorité lorsque vous y avez accès. Sinon, écrivez « statut actuel non confirmé » plutôt que de déduire l’état à partir du silence de la messagerie.
Un commentaire de clôture que l’on peut relire
Voici un modèle court à adapter :
- Verdict retenu et raison.
- Éléments qui soutiennent ce verdict, avec leur périmètre et leurs liens.
- Actions réalisées, résultats vérifiés et éléments seulement déclarés.
- Limites restantes et effet sur la conclusion.
- Motif de clôture dans cette file, responsable de la décision et suivi encore actif.
- Condition qui ferait réexaminer le dossier.
Il ne s’agit pas de recopier les logs dans chaque ticket. Conservez les éléments dans leurs emplacements autorisés et évitez de multiplier les secrets ou données sensibles dans les commentaires. La fiche OWASP sur la journalisation recommande notamment de ne pas enregistrer directement les tokens d’accès et mots de passe. Source : OWASP
Vérifiez la qualité sur un petit échantillon
Prenez quelques dossiers déjà fermés et faites-les relire par un analyste autorisé qui ne les a pas traités. Peut-il expliquer le verdict, retrouver le résultat de l’action et identifier ce qui reste à faire, sans appeler l’auteur ?
S’il ne le peut pas, corrigez d’abord le modèle de clôture et les responsabilités. Ajouter un nouveau score ou une automatisation ne résoudra pas une décision restée implicite.
Pour préparer une revue avec Seculogik, partez de dossiers anonymisés ou de scénarios fictifs : l’objectif est de rendre chaque clôture explicable, pas d’afficher une file vide.