Auditer et suivre les modifications apportées aux tâches d’incident dans Microsoft Sentinel
Les tâches d’incident 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 des analystes principaux ou des 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 à effectuer pour un incident particulier dans la page des détails de l’incident. Ils peuvent les marquer comme terminées au fur et à mesure. Les analystes peuvent également créer leurs propres tâches 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 affectations 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 stocke non pas les incidents eux-mêmes, mais plutôt les enregistrements de la vie 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 Tasks (Tâches) se composent de paires clé-valeur prenant la structure suivante :
Clé | Description de la valeur |
---|---|
createdBy | Identité qui a créé la tâche : - email : adresse e-mail de l’identité - name : nom de l’identité - objectId : GUID de l’identité - userPrincipalName : UPN de l’identité |
createdTimeUtc | Heure de création de la tâche, en UTC. |
lastCompletedTimeUtc | Heure à laquelle la tâche a été marquée comme terminée, en UTC. |
lastModifiedBy | Identité qui a modifié la tâche pour la dernière fois : - email : adresse e-mail de l’identité - name : nom de l’identité - objectId : GUID de l’identité - userPrincipalName : UPN de l’identité |
lastModifiedTimeUtc | Heure de la dernière modification de la tâche, en UTC. |
statut | État actuel de la tâche : New (Nouveau), Completed (Terminé), Deleted (Supprimé). |
taskId | ID de ressource de la tâche. |
title | Nom convivial donné à la tâche par son créateur. |
Afficher les tâches d’incident dans la table SecurityIncident
Outre le classeur Incident tasks (Tâches d’incident), vous pouvez auditer l’activité des tâches en interrogeant la table SecurityIncident dans Logs (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.
Dans la page Logs (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 un nombre quelconque 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 que nous voyions uniquement les tâches d’un seul incident, et nous allons également ajouter une instruction
project
pour ne voir que les champs qui seront utiles à nos fins, sans trop d’encombrement.En savoir plus sur le langage de requête Kusto
SecurityIncident | where array_length( Tasks) > 0 | where IncidentNumber == "405211" | sort by LastModifiedTime desc | project IncidentName, Title, LastModifiedTime, Tasks
Examinons l’enregistrement le plus récent de cet incident et trouvons la liste des tâches qui lui sont associées.
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écence).
Le champ Tasks (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.
Vous voyez maintenant que cet incident comporte deux tâches. Chacun d’eux est représenté à son tour par un tableau extensible. Sélectionnez le développeur d’une tâche pour afficher ses informations.
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 title (titre) affiche le nom de la tâche tel qu’affiché dans l’incident.
Afficher les tâches ajoutées à la liste
Ajoutons une tâche à l’incident, puis revenons ici, réexécutons la requête et voyons les modifications apportées aux résultats.
Dans la page Incidents, entrez le numéro d’ID d’incident dans la barre de recherche.
Ouvrez la page des détails de l’incident, puis sélectionnez Tâches dans la barre d’outils.
Ajoutez une nouvelle tâche, attribuez-lui le nom « Cette tâche est un test », puis sélectionnez Enregistrer. La dernière tâche illustrée ci-dessous est ce que vous devez obtenir :
Revenons à 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 timestamps). Développez l’enregistrement et vous voyez que, tandis 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 les modifications d’état des tâches
À présent, si nous revenons à cette nouvelle tâche dans la page des détails de l’incident et la marquons comme étant terminée, puis revenons à Journaux et réexécutons la requête, nous voyons encore un nouvel enregistrement pour le même incident, montrant cette fois le nouvel état de notre tâche comme Terminé.
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 que nous exécutons à nouveau la requête, nous voyons un autre nouvel enregistrement, mais cette fois l’état de notre tâche (celle intitulée « Cette tâche est un test ») est supprimé.
Toutefois, une fois que la tâche est apparue une fois dans le tableau (avec l’état Supprimé), elle n’apparaît plus dans le tableau Tâches dans de nouveaux enregistrements pour cet incident dans la table SecurityIncident. Les documents existants, comme ceux que nous avons vus ci-dessus, conserveront la preuve que cette tâche a existé.
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é effectuées. Ces connaissances peuvent vous aider à vérifier que toutes les questions en suspens de votre enquête ont été résolues : toutes les parties concernées ont été informées, tous les commentaires ont été entrés, toutes les réponses ont été vérifiées, etc.
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
| order by lastModifiedTimeUtc desc
Étapes suivantes
- Découvrez-en plus sur les tâches d’incident.
- Découvrez comment investiguer des incidents.
- Découvrez comment ajouter automatiquement des tâches à des groupes d’incidents à l’aide de règles d’automatisation ou de playbooks, ainsi que dans quelles circonstances les utiliser.
- Découvrez-en plus sur les règles d’automatisation et la manière de les créer.
- Découvrez-en plus sur les playbooks et la manière de les créer.