Auditer et suivre les modifications apportées aux tâches d’incident dans Microsoft Sentinel dans le Portail Azure

Les tâches relatives aux incidents garantissent un traitement complet et uniforme des incidents pour l’ensemble du personnel soc. Les listes de tâches sont généralement définies en fonction des déterminations effectuées par les analystes supérieurs ou les responsables SOC, et mises en pratique à l’aide de règles d’automatisation ou de playbooks.

Vos analystes peuvent voir la liste des tâches qu’ils doivent effectuer pour un incident particulier sur la page des détails de l’incident et les marquer comme terminées. Les analystes peuvent également créer leurs propres tâches sur place, manuellement, directement à partir de l’incident.

Cet article explique comment, en tant que responsable SOC, vous pouvez auditer l’historique des tâches d’incident Microsoft Sentinel et suivre les modifications qui y ont été apportées tout au long de leur cycle de vie, afin d’évaluer l’efficacité de vos attributions de tâches et leur contribution à l’efficacité et au bon fonctionnement de votre SOC.

Structure du tableau Tasks dans la table SecurityIncident

La table SecurityIncident est une table d’audit : elle ne stocke pas les incidents eux-mêmes, mais plutôt les enregistrements de la durée d’un incident : sa création et les modifications qui y sont apportées. Chaque fois qu’un incident est créé ou qu’une modification est apportée à un incident, un enregistrement est généré dans cette table montrant l’état actuel de l’incident.

L’ajout des détails des tâches au schéma de cette table vous permet d’auditer les tâches plus en profondeur.

Les informations détaillées ajoutées au champ Tâches se composent de paires clé-valeur prenant la structure suivante :

Afficher les tâches d’incident dans la table SecurityIncident

Outre le classeur Tâches d’incident, vous pouvez auditer l’activité des tâches en interrogeant la table SecurityIncident dans Journaux. Le reste de cet article vous montre comment procéder, ainsi que comment lire et comprendre les résultats de la requête pour obtenir des informations sur l’activité des tâches.

1. Dans la page Journaux , entrez la requête suivante dans la fenêtre de requête et exécutez-la. Cette requête retourne tous les incidents auxquels des tâches sont affectées.

   SecurityIncident
   | where array_length( Tasks) > 0
   

   Vous pouvez ajouter n’importe quel nombre d’instructions à la requête pour filtrer et affiner les résultats. Pour montrer comment afficher et comprendre les résultats, nous allons ajouter des instructions pour filtrer les résultats afin de voir uniquement les tâches d’un seul incident, et nous allons également ajouter une project instruction afin de voir uniquement les champs qui seront utiles à nos fins, sans trop d’encombrement.

   Pour plus d’informations, consultez Langage de requête Kusto vue d’ensemble.

   SecurityIncident
   | where array_length( Tasks) > 0
   | where IncidentNumber == "405211"
   | sort by LastModifiedTime desc 
   | project IncidentName, Title, LastModifiedTime, Tasks
   

2. Examinons l’enregistrement le plus récent de cet incident et trouvons la liste des tâches qui lui sont associées.

   1. Sélectionnez le développeur en regard de la ligne supérieure dans les résultats de la requête (qui ont été triés dans l’ordre décroissant de récurrence).

      

   2. Le champ Tâches est un tableau de l’état actuel de toutes les tâches de cet incident. Sélectionnez le développeur pour afficher chaque élément du tableau dans sa propre ligne.

      

   3. Vous voyez maintenant qu’il y a deux tâches dans cet incident. Chacun d’eux est représenté à son tour par un tableau extensible. Sélectionnez l’expandeur d’une tâche unique pour afficher ses informations.

      

   4. Ici, vous voyez les détails de la première tâche dans le tableau (« 0 » étant la position d’index de la tâche dans le tableau). Le champ titre affiche le nom de la tâche tel qu’affiché dans l’incident.

Afficher les tâches ajoutées à la liste

1. Ajoutons une tâche à l’incident, puis revenons ici, réexécutons la requête et voyons les modifications apportées aux résultats.

   1. Dans la page Incidents , entrez le numéro d’id d’incident dans la barre de recherche.

   2. Ouvrez la page détails de l’incident et sélectionnez Tâches dans la barre d’outils.

   3. Ajoutez une nouvelle tâche, nommez-la « Cette tâche est une tâche de test », puis sélectionnez Enregistrer. La dernière tâche illustrée ci-dessous est celle avec laquelle vous devez vous retrouver :

      

2. Revenons maintenant à la page Journaux et réexécutons notre requête.

   Dans les résultats, vous verrez qu’il existe un nouvel enregistrement dans la table pour ce même incident (notez les horodatages). Développez l’enregistrement et vous verrez que, alors que l’enregistrement que nous avons vu précédemment avait deux tâches dans son tableau Tâches , le nouveau en a trois. La tâche la plus récente est celle que nous venons d’ajouter, comme vous pouvez le voir par son titre.

   

Afficher status modifications apportées aux tâches

À présent, si nous revenons à cette nouvelle tâche dans la page des détails de l’incident et la marquez comme terminée, puis revenons aux journaux et réexécutons la requête, nous voyons un autre nouvel enregistrement pour le même incident, montrant cette fois la nouvelle status de notre tâche comme Terminée.

Afficher la suppression des tâches

Revenons à la liste des tâches dans la page des détails de l’incident et supprimons la tâche que nous avons ajoutée précédemment.

Lorsque nous revenons aux journaux et réexécutons la requête, nous voyons un autre nouvel enregistrement, mais cette fois le status pour notre tâche : celui intitulé « Cette tâche est une tâche de test ! » : sera supprimé.

Toutefois, une fois que la tâche est apparue une telle fois dans le tableau (avec un status supprimé), elle n’apparaît plus dans le tableau Tâches dans les nouveaux enregistrements de cet incident dans la table SecurityIncident. Les dossiers existants, comme ceux que nous avons vus ci-dessus, continueront de conserver la preuve que cette tâche existait autrefois.

Afficher les tâches actives appartenant à un incident fermé

La requête suivante vous permet de voir si un incident a été fermé, mais si toutes les tâches qui lui ont été attribuées n’ont pas été terminées. Ces connaissances peuvent vous aider à vérifier que toutes les fins restantes de votre enquête ont été conclues : toutes les parties concernées ont été averties, tous les commentaires ont été entrés, toutes les réponses ont été vérifiées, et ainsi de suite.

SecurityIncident
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status == 'Closed'
| mv-expand Tasks
| evaluate bag_unpack(Tasks)
| summarize arg_max(lastModifiedTimeUtc, *) by taskId
| where status !in ('Completed', 'Deleted')
| project TaskTitle = ['title'], TaskStatus = ['status'], createdTimeUtc, lastModifiedTimeUtc = column_ifexists("lastModifiedTimeUtc", datetime(null)), TaskCreator = ['createdBy'].name, lastModifiedBy, IncidentNumber, IncidentOwner = Owner.userPrincipalName
| sort by lastModifiedTimeUtc desc

Pour plus d’informations sur les éléments suivants utilisés dans les exemples précédents, consultez la documentation Kusto :

• where, opérateur
• opérateur de projet
• opérateur de tri
• Summarize, opérateur
• fonction d’agrégation arg_max()

Pour plus d’informations sur KQL, consultez vue d’ensemble de Langage de requête Kusto (KQL).

Autres ressources :

• Informations de référence rapides sur KQL
• ressources d’apprentissage Langage de requête Kusto

Étapes suivantes

• En savoir plus sur les tâches d’incident.
• Découvrez comment examiner les incidents.
• Découvrez comment ajouter automatiquement des tâches à des groupes d’incidents à l’aide de règles d’automatisation ou de playbooks, et quand les utiliser.
• En savoir plus sur les règles d’automatisation et sur la façon de les créer.
• En savoir plus sur les playbooks et comment les créer.