Playbook pour l’échec de la connexion manuelle

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 6 minutes de lecture

    • Lorsqu’un utilisateur effectue certaines tentatives de connexion infructueuses (en fonction de la configuration SIM), un incident de sécurité est créé.

    Ces tentatives de connexion infructueuses peuvent être soit des faux positifs, soit des tentatives effectuées par des attaquants pour obtenir l’accès aux comptes de messagerie des utilisateurs. Dans de tels scénarios, le playbook Échec de la connexion manuelle peut fournir des conseils et aider à optimiser l’enquête sur les incidents de sécurité liés à l’échec de la connexion.

    Prérequis

    Rôle requis :
    • sn_si.admin
    • flow_designer

    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. Filtre les éléments observables sur liste d’autorisation
    3. Enrichit les observables
    4. Effectue une recherche automatisée de menace.
    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 IP et URL.
    8. Réinitialise le mot de passe utilisateur.
    9. Met à jour l’état de l’incident de sécurité
    10. Affecte les tâches à un analyste de sécurité pour gérer l’examen post-incident.

    Options requises

    • Recherche de menace (total de virus, analyse hybride)
    • Enrichissement des observables (Whois, ReverseWhois)
    • Recherche de perception (Splunk, QRadar)
    • Blocage des observables (CheckPoint, Palo Alto)

    Pour plus d’informations, consultez le ServiceNow Store.

    Expérience d’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

    Mise en route
    1. Connectez-vous en tant qu’utilisateur disposant des rôles sn_si.user et flow_designer.
    2. Accédez à la Concepteur de flux > Concepteur et cliquez sur le playbook Failed Login (Échec de la connexion ).
    3. Faites une copie des flux suivants pour copier le playbook d’échec de la connexion et apportez les modifications nécessaires. (Il s’agit d’une étape facultative. Suivez cette étape uniquement si vous prévoyez de personnaliser le flux ou d’y apporter des modifications spécifiques.
      • Échec de la connexion manuelle au Playbook V1
      • Échec de la connexion : analyser la réponse de l’utilisateur et mettre à jour la tâche de réponse V1
    4. Apportez les modifications nécessaires en fonction de vos besoins. (Il s’agit d’une étape facultative. Suivez cette étape uniquement si vous prévoyez de personnaliser le flux ou d’y apporter des modifications spécifiques.
    5. Activez les playbooks.
      • Activez le flux principal pour utiliser le playbook disponible avec le système de base.
      • Activez les flux copiés après avoir apporté des modifications en fonction de vos besoins.

    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 dans le playbook.


    Copie du playbook manuel d’échec de la connexion
    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 ni fermé ni annulé

    Échec de la connexion au playbook : déclencheur

    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é.
      Échec de la connexion au playbook : étape 1
    2. À l’étape 2, le playbook est mis à jour et passé à 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é.
      Échec de la connexion au playbook : étape 3
      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 adaptée à 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 pour connaître 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 pour 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.
      Échec de la connexion au playbook : étape 6
    7. Si des observables sont trouvés à l’étape 7, les observables qui ne sont pas autorisés sont identifiés.
    8. Si au moins un des observables n’est pas autorisé par 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.
        Échec de la connexion au playbook : étapes 8.1 et 8.2
      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.
        Échec du flux de playbook : étapes 8.3.1.1 et 8.3.1.2
      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 perceptions sera exécutée sur les observables.
        Échec de la connexion au playbook : étape 8.6
      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 d’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 à ce stade.
      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 passer aux autres é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 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.

        Échec de la connexion au playbook : étape 8.10.2
    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 blocage 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 ce 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 la revue post-incident avant de fermer la tâche.