Prérequis

Spoke : installer le spoke Security Operations (sn_sec_spoke)

Principales options

Le Playbook de connexion ayant échoué 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 autorisés : répertorier les observables
3. Enrichit les observables
4. Effectue une recherche automatisée des 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 des incidents 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 d’analyste en sécurité

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

Utilisation du playbook d’échec de connexion avec les options de Flow Designer

L’image suivante montre une copie du playbook Manuel d’échec de connexion. 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 la connexion
• A un ou plusieurs utilisateurs affectés
• L’incident de sécurité n’est pas fermé ou annulé

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

1. Lorsque le playbook commence à s’exécuter, à l’étape 1, il est automatiquement mis à jour avec une note de travail montrant 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 est ajoutée à l’incident de sécurité indiquant que le compte d’utilisateur est inactif.
   
   
   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 pour votre environnement spécifique. Si vous souhaitez utiliser cette fonctionnalité, nous vous recommandons d’avoir une intégration Active Directory configurée dans votre environnement. Vous pouvez vérifier auprès de votre intégration Active Directory pour trouver 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 se termine.
   
   
7. Si des observables sont trouvés à l’Étape 7, les observables qui ne sont pas autorisés sur la liste sont identifiés.
8. Si au moins un des observables n’est pas autorisé sur la liste, les étapes suivantes sont effectué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’incident de sécurité est mis à jour à l’étape 8.7.
   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 reconfirmer 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 pour Maîtriser.
         2. Un e-mail automatisé est envoyé à l’utilisateur pour réinitialiser le mot de passe.
         3. Le flux secondaire de réinitialisation du mot de passe est lancé et un e-mail est envoyé à l’utilisateur lorsque la tâche est terminée.
         Remarque :

         L’étape de réinitialisation du 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 en fonction de 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é est envoyé à l’utilisateur pour reconfirmer la 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 elle 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 Révision.
12. À l’Étape 10, une tâche de réponse est créée pour que l’utilisateur termine la revue post-incident avant de fermer la tâche.