Playbook pour Échec de connexion manuelle

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 6 minutes de lecture

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

    Ces tentatives de connexion infructueuses peuvent être des faux positifs ou 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 Manuel d’échec de connexion peut fournir des conseils et aider à optimiser l’enquête sur les incidents de sécurité liés à l’échec de connexion.

    Prérequis

    Rôle requis :
    • sn_si.admin
    • flow_designer

    Spoke : installer le spoke Security Operations (sn_sec_spoke)

    Principales options

    Le playbook Échec de la 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 la liste des éléments autorisés
    3. Enrichit les observables
    4. Effectue une recherche de menace automatisée.
    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 les 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

    • Recherche de menace (Total virus, Hybrid Analysis)
    • Enrichissement des observables (Whois, ReverseWhois)
    • Recherche de perception (Splunk, QRadar)
    • Blocage d’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 en cas d’échec de connexion avec les options de Flow Designer

    Mise en route
    1. Connectez-vous en tant qu’utilisateur avec les rôles sn_si.user et flow_designer.
    2. Accédez à la Concepteur de flux > Concepteur et cliquez sur le playbook Échec de la connexion .
    3. Faites une copie des flux suivants pour copier le Playbook de connexion échouée et apportez les modifications nécessaires. (Il s’agit d’une étape facultative. Suivez cette étape uniquement si vous envisagez de personnaliser ou d’apporter des modifications spécifiques au flux.
      • Échec de la connexion manuelle à 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 envisagez de personnaliser ou d’apporter des modifications spécifiques au flux.
    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 Manuel d’échec de la connexion. Passez en revue les étapes ci-dessous pour mieux comprendre les différentes actions du playbook.


    Copie du playbook manuel de connexion ayant échoué
    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 l’incident de sécurité avec la catégorie d’échec de connexion a été affectée.
      É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 modifiée pour votre environnement spécifique. Si vous souhaitez utiliser cette fonctionnalité, nous vous recommandons d’avoir configuré une intégration Active Directory 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 étapes suivantes pour 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 passer aux autres é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.
      Échec de la connexion au Playbook : étape 6
    7. Si des observables sont trouvés à l’étape 7, les observables qui ne figurent pas sur la liste d’autorisation sont identifiés.
    8. Si au moins un des observables n’est pas autorisé dans la liste, 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.
        Échec du playbook de connexion : é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 perception 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 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 à 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 initié 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 en fonction de votre environnement. Vous pouvez vérifier avec 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 concernée 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 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.

        É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 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 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 Révision.
    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.