Utilisez ce playbook pour vérifier si la réponse aux incidents a été fournie dans un rapport de hameçonnage exact ou similaire dans le passé et si elle fonctionne automatiquement sur le nouveau rapport de la même manière. Les étapes suivantes vous donnent une procédure pas à pas 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
Procédure
Lorsque le playbook est déclenché et commence à s’exécuter, dans l’action 1, le playbook récupère la date relative de l’incident de sécurité à l’aide de la configuration du jour.
Dans l’action 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
Dans l’action 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 correspondaient à l’ID de message.
Dans l’action 4, en fonction de l’enquête effectuée jusqu’à présent, le playbook vérifie si l’incident correspondant est détecté en fonction de l’ID de message ou non.
Dans l’action 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 pour la détection répétée. Dans l’action 6, le flux se termine.
Si l’incident correspondant n’est pas trouvé, dans l’action 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.
Dans l’action 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 correspondaient à l’objet.
Dans l’action 9, le playbook vérifie si l’incident correspondant est trouvé ou non.
Dans l’action 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 pour la détection répétée. Dans l’action 11, le flux se termine.Figure 2. Incident correspondant
Dans l’action 12, le playbook recherche les enregistrements observables de tâche sur la table sn_ti_m2m_task_observable qui correspondent à l’incident en fonction de l’adresse.
Dans l’action 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 correspondaient à l’adresse.
Dans l’action 14, le playbook vérifie si l’incident correspondant est trouvé en fonction de l’adresse ou non.
Dans l’action 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 pour la détection répétée. Dans l’action 16, le flux se termine.