Prérequis

Spoke : installer le spoke Security Operations (sn_sec_spoke)

Principales options

Le playbook d’échec de connexion couvre les options suivantes pour enquêter sur les incidents de sécurité :

1. Vérifie si l’utilisateur affecté est un utilisateur actif/inactif
2. Filtres des éléments observables sur liste d’autorisation
3. Enrichit les observables
4. Effectue une recherche automatisée de menaces.
5. Envoie un e-mail automatisé à l’utilisateur pour confirmer l’échec de la tentative de connexion.
6. Affecte des tâches à l’analyste pour examiner l’accès des utilisateurs
7. Identifie les observables malveillants et bloque les adresses IP et URL.
8. Réinitialise le mot de passe utilisateur.
9. Met à jour l’état de l’incident de sécurité
10. Affecte des tâches à un analyste de sécurité pour gérer l’examen post-incident.

Options requises

Pour plus d’informations, consultez le ServiceNow Store.

Expérience de l’analyste de sécurité

Pour comprendre comment résoudre les menaces de sécurité étape par étape, reportez-vous à la section Résoudre les menaces de sécurité avec le playbook.

Utilisation du playbook d’échec de connexion avec les options de Concepteur de flux

L’image suivante montre une copie du playbook Échec de la connexion manuelle. Passez en revue les étapes ci-dessous pour mieux comprendre les différentes actions du playbook.

Ce playbook est déclenché et associé à l’incident de sécurité lorsque les conditions suivantes sont remplies :

• La catégorie est Échec de connexion
• A un ou plusieurs utilisateurs affectés
• L’incident de sécurité n’est ni fermé ni annulé

Les étapes suivantes vous guident à travers les actions, les tâches et les flux secondaires disponibles dans le playbook Échec de la connexion manuelle.

1. Lorsque le playbook commence à s’exécuter, à l’étape 1, le playbook est automatiquement mis à jour avec une note de travail indiquant que l’incident de sécurité avec la catégorie d’échec de connexion a été affectée.
   
   
2. À l’étape 2, le playbook est mis à jour et passe à l’état Analyse.
3. À l’étape 3, le playbook vérifie si l’utilisateur affecté est un utilisateur actif ou inactif. Si l’utilisateur est inactif, une note de travail indiquant que le compte d’utilisateur est inactif est ajoutée à l’incident de sécurité.
   
   
   Remarque :

   À l’étape 3 du flux, le flux vérifie les utilisateurs inactifs dans la table sn_si_incident disponible dans ServiceNow. Cette étape est fournie à titre indicatif et doit être modifiée en fonction de votre environnement spécifique. Si vous souhaitez utiliser cette fonctionnalité, nous vous recommandons de configurer une intégration Active Directory dans votre environnement. Vous pouvez vérifier auprès de votre intégration Active Directory l’état de l’utilisateur et, en fonction de la réponse, vous pouvez concevoir les prochaines étapes de votre playbook.

   Si vous n’avez pas d’intégration Active Directory, remplacez cette étape par une tâche manuelle pour que l’analyste de sécurité travaille avec l’équipe informatique pour bloquer l’utilisateur et poursuivre avec le reste des étapes du playbook.

4. À l’étape 4, les observables de l’incident de sécurité sont récupérés.
5. À l’étape 5, les observables sont identifiés.
6. Si aucun observable n’est trouvé, une tâche de réponse manuelle est créée à l’étape 6 et le flux s’arrête.
   
   
7. Si des observables sont trouvés à l’étape 7, les observables qui ne sont pas sur la liste d’autorisation sont identifiés.
8. Si au moins un des observables n’est pas sur liste d’autorisation, les étapes suivantes sont exécutées :
   1. Les étapes 8.1 et 8.2 sont exécutées. Les observables sont récupérés et une tâche de réponse automatisée est lancée.
      
      
   2. Une fois la tâche automatisée créée, l’étape 8.3 (8.3.1.1 et 8.3.2.1) est exécutée et les intégrations Enrichir les observables et Recherche de menace sont exécutées. Notez qu’il s’agit de flux secondaires qui ont été inclus dans le playbook.
      
      
   3. À l’étape 8.4, une fois les intégrations terminées, l’enregistrement d’incident de sécurité est mis à jour.
   4. À l’étape 8.5, une nouvelle tâche de réponse est créée pour indiquer la prochaine tâche automatisée qui aura lieu.
   5. À l’étape 8.6, l’intégration de la recherche de perception sera exécutée sur les observables.
      
      
   6. Une fois le flux secondaire de recherche de perception terminé, à l’étape 8.7, l’incident de sécurité est mis à jour.
   7. À l’étape 8.8, les observables sont vérifiés pour voir s’ils sont malveillants.
   8. Si les observables ne sont pas malveillants et si le compte utilisateur est actif, un e-mail automatisé est envoyé à l’utilisateur pour confirmer à nouveau les tentatives de connexion infructueuses. Une tâche de réponse manuelle est créée pour identifier les observables et les ajouter à l’incident de sécurité. Le playbook se termine alors à cette étape.
   9. Si les observables sont malveillants, trois tâches de réponse sont créées :
      1. Un e-mail automatisé est envoyé à l’utilisateur pour confirmer (Oui ou Non) les tentatives de connexion infructueuses. Si l’utilisateur répond Oui :
         1. L’état de l’incident de sécurité est mis à jour et prend la valeur Maîtriser.
         2. Un e-mail automatisé est envoyé à l’utilisateur pour réinitialiser le mot de passe.
         3. Le flux secondaire Réinitialiser le mot de passe est lancé et un e-mail est envoyé à l’utilisateur lorsque la tâche est terminée.
         Remarque :

         L’étape Réinitialiser le mot de passe est fournie à titre indicatif. Les étapes du flux réinitialisent le mot de passe du compte de l’utilisateur dans le système ServiceNow. Mais le processus de réinitialisation du mot de passe peut être différent selon votre environnement. Vous pouvez vérifier auprès de votre intégration Active Directory pour réinitialiser automatiquement le mot de passe des utilisateurs. Si vous n’avez pas d’intégration Active Directory, remplacez cette étape par une tâche manuelle pour que l’analyste de sécurité travaille avec l’équipe informatique respective pour réinitialiser le mot de passe des utilisateurs et poursuivre avec le reste des étapes du playbook, une fois la tâche respective terminée.
      2. Si l’utilisateur répond Non, un e-mail automatisé lui est envoyé pour confirmer à nouveau sa réponse. L’analyste de sécurité doit prendre manuellement les mesures appropriées.
      3. Si l’utilisateur ne répond pas à l’e-mail automatisé, l’analyste de sécurité doit mettre à jour manuellement l’incident de sécurité et fournir une réponse. Une tâche manuelle est créée pour valider si le compte utilisateur a été compromis.
      
      
      
9. À l’étape 8.10.3, l’état de l’incident de sécurité est mis à jour.
10. À l’étape 8.10.4, une tâche automatisée est créée pour vérifier si l’implémentation de l’aptitude Créer des demandes de bloc pour les adresses IP et URL malveillantes est disponible. Si l’implémentation de l’aptitude est disponible, le flux secondaire Créer des demandes de bloc est exécuté. Si cette option n’est pas disponible, l’incident de sécurité est mis à jour et une note de travail est publiée pour indiquer que l’implémentation de l’aptitude n’est pas disponible.
11. À l’étape 9, l’incident de sécurité est mis à jour et l’état est défini sur Examen.
12. À l’étape 10, une tâche de réponse est créée pour que l’utilisateur termine l’examen post-incident avant de fermer la tâche.