VIGIL — analyse guidée d'alertes N1 / N2

On renseigne l'alerte — type, hash, poste, utilisateur. VIGIL pose les questions qu'un analyste expérimenté poserait, oriente les recherches, puis rédige un compte rendu qui conclut : critique ou non, et pourquoi.

Le problème

Face à une alerte, un analyste N1 sait rarement par où commencer. Le hash est-il connu ? Ce comportement est-il normal pour ce poste ? Faut-il escalader ? L’expérience répond à ces questions en quelques minutes ; sans elle, on tâtonne, ou l’on ferme trop vite.

Les playbooks existent pour ça — mais ils sont rarement ouverts au moment où l’on en a besoin.

Ce que fait l’outil

On renseigne l’alerte : son type, le hash, l’actif, l’identité concernée.
VIGIL questionne. Selon le type d’alerte, il pose les questions qui orientent l’investigation — réputation du hash, chaîne de processus, contexte de l’utilisateur, occurrences passées — et indique où aller chercher chaque réponse.
Il conclut par un compte rendu prêt à verser au ticket : chronologie, éléments vérifiés, technique MITRE ATT&CK rattachée, et une qualification — critique ou non — argumentée.

Vos playbooks, pas les miens

Chaque SOC a ses procédures. VIGIL accepte qu’on lui fournisse les siennes : les questions posées, les seuils d’escalade et la forme du compte rendu suivent alors le playbook de l’équipe, et non un modèle générique.

Le principe

L’outil prépare, l’analyste tranche. Une qualification sans justification lisible est inutilisable en N2 et dangereuse en N1 : chaque conclusion doit pouvoir être relue et contestée.

État

En cours de construction.