Utiliser le playbook de détection de répétition

Les étapes suivantes vous donnent un aperçu des actions, des tâches et des flux secondaires disponibles dans le playbook Répéter la détection.

Avant de commencer

Rôle requis :

• sn_si.admin
• flow_designer

Assurez-vous d’avoir installé le spoke Security Operations (sn_sec_spoke). Vous pouvez modifier les propriétés système suivantes :

• sn_sec_spoke.similarphish.earlyterminationscore
• sn_sec_spoke.similarphish.lookbackdays
• sn_sec_spoke.similarphish.maxcomparisonsize
• sn_sec_spoke.similarphish.minmatchscore

Procédure

1. Lorsque le playbook est déclenché et commence à s’exécuter, à l’étape 1, il récupère la date relative de l’incident de sécurité à l’aide de la configuration du jour.
2. À l’étape 2, le playbook recherche les enregistrements d’observables de tâche sur la table sn_ti_m2m_task_observable qui correspondent à l’incident en fonction de l’ID de message.

   Figure 1. Playbook de détection de répétition

   

3. À l’étape 3, le playbook compare les observables de tâche et le corps de l’e-mail à l’aide de l’algorithme de Levenshtein pour les incidents qui correspondent à l’ID de message.
4. À l’étape 4, en fonction de l’enquête effectuée jusqu’à présent, le playbook vérifie si l’incident correspondant est trouvé en fonction de l’ID de message ou non.
   À l’étape 5, si l’incident correspondant est trouvé, le playbook met automatiquement à jour la note de travail indiquant qu’une correspondance a été trouvée en fonction de l’automatisation de la détection répétée. À l’étape 6, le flux se termine.
5. Si l’incident correspondant n’est pas trouvé, à l’étape 7, le playbook recherche les enregistrements d’observables de tâche sur la table sn_ti_m2m_task_observable qui correspondent à l’incident en fonction de l’objet.
6. À l’étape 8, le playbook compare les observables de tâche et le corps de l’e-mail à l’aide de l’algorithme de Levenshtein pour les incidents qui correspondent à l’objet.
7. À l’étape 9, le playbook vérifie si l’incident correspondant est trouvé ou non.
   À l’Étape 10, si l’incident correspondant est trouvé, le playbook met automatiquement à jour la note de travail indiquant qu’une correspondance a été trouvée en fonction de l’automatisation de la détection répétée. À l’étape 11, le flux se termine.

   Figure 2. Incident correspondant

   

8. À l’étape 12, le playbook recherche les enregistrements d’observables de tâche sur la table sn_ti_m2m_task_observable qui correspondent à l’incident en fonction de l’adresse.
9. À l’étape 13, le playbook compare les observables de tâche et le corps de l’e-mail à l’aide de l’algorithme de Levenshtein pour les incidents qui correspondent à l’adresse.
10. À l’étape 14, le playbook vérifie si l’incident correspondant est trouvé en fonction de l’adresse ou non.
    À l’Étape 15, si l’incident correspondant est trouvé, le playbook met automatiquement à jour la note de travail indiquant qu’une correspondance a été trouvée en fonction de l’automatisation de la détection répétée. À l’étape 16, le flux se termine.