Créer les règles de détection personnalisées

Les règles de détection personnalisées sont des règles que vous concevez et ajustez à l’aide de requêtes de repérage avancées . Ces règles vous permettent de surveiller de manière proactive différents événements et états système, notamment les activités de violation présumée et les points de terminaison mal configurés. Vous pouvez les définir pour qu’ils s’exécutent à intervalles réguliers, en générant des alertes et en effectuant des actions de réponse chaque fois qu’il y a des correspondances.

Autorisations requises pour la gestion des détections personnalisées

Pour gérer les détections personnalisées, vous avez besoin de rôles qui vous permettent de gérer les données ciblées par ces détections. Par exemple, pour gérer les détections personnalisées sur plusieurs sources de données (Microsoft Defender XDR et Microsoft Sentinel, ou plusieurs charges de travail Defender), vous avez besoin de tous les rôles Defender XDR et Sentinel applicables. Pour plus d’informations, consultez les sections suivantes.

Microsoft Defender XDR

Pour gérer les détections personnalisées sur les données Microsoft Defender XDR, vous devez disposer de l’un des rôles suivants :

• Paramètres de sécurité (gérer) : les utilisateurs disposant de cette autorisation Microsoft Defender XDR peuvent gérer les paramètres de sécurité dans le portail Microsoft Defender.

• Administrateur de la sécurité : les utilisateurs disposant de ce rôle Microsoft Entra peuvent gérer les paramètres de sécurité dans le portail Microsoft Defender et dans d’autres portails et services.

• Opérateur de sécurité : les utilisateurs disposant de ce rôle Microsoft Entra peuvent gérer les alertes et disposer d’un accès global en lecture seule aux fonctionnalités liées à la sécurité, y compris toutes les informations dans le portail Microsoft Defender. Ce rôle est suffisant pour gérer les détections personnalisées uniquement si le contrôle d’accès en fonction du rôle (RBAC) est désactivé dans Microsoft Defender pour point de terminaison. Si vous avez configuré RBAC, vous avez également besoin de l’autorisation Gérer les paramètres de sécurité pour Defender pour point de terminaison.

Vous pouvez gérer les détections personnalisées qui s’appliquent aux données de solutions Defender XDR spécifiques si vous disposez des autorisations appropriées pour celles-ci. Par exemple, si vous disposez uniquement d’autorisations de gestion pour Microsoft Defender pour Office 365, vous pouvez créer des détections personnalisées à l’aide Email* de tables, mais pas Identity* de tables.

De même, étant donné que la IdentityLogonEvents table contient les informations d’activité d’authentification de Microsoft Defender for Cloud Apps et de Defender pour Identity, vous devez disposer d’autorisations de gestion pour les deux services afin de gérer les détections personnalisées interrogeant la table.

Microsoft Sentinel

Pour gérer les détections personnalisées sur Microsoft Sentinel données, vous devez disposer du rôle Contributeur Microsoft Sentinel. Les utilisateurs disposant de ce rôle Azure peuvent gérer Microsoft Sentinel données de l’espace de travail SIEM, y compris les alertes et les détections. Vous pouvez attribuer ce rôle sur un espace de travail principal spécifique, Azure groupe de ressources ou un abonnement entier.

Gestion des autorisations requises

Pour gérer les autorisations requises, un administrateur général peut :

• Attribuez le rôle Administrateur de la sécurité ou Opérateur de sécurité dans Centre d’administration Microsoft 365 sous Rôles>Administrateur de la sécurité.

• Vérifiez les paramètres RBAC pour Microsoft Defender pour point de terminaison dans Microsoft Defender XDR sous Paramètres>Autorisations>Rôles. Sélectionnez le rôle correspondant pour attribuer l’autorisation gérer les paramètres de sécurité .

Créer une règle de détection personnalisée

1. Préparer la requête

Dans le portail Microsoft Defender, accédez à Repérage avancé et sélectionnez une requête existante ou créez-en une. Lorsque vous utilisez une nouvelle requête, exécutez la requête pour identifier les erreurs et comprendre les résultats possibles.

Colonnes obligatoires dans les résultats de la requête

Pour créer une règle de détection personnalisée à l’aide de données Defender XDR, la requête doit retourner les colonnes suivantes :

1. Timestamp ou TimeGenerated - Cette colonne définit l’horodatage des alertes générées. La requête ne doit pas manipuler cette colonne et la retourner exactement telle qu’elle apparaît dans l’événement brut.

2. Pour les détections basées sur des tables XDR, une colonne ou une combinaison de colonnes qui identifient de manière unique l’événement dans ces tables :

   • Pour Microsoft Defender pour point de terminaison tables, les Timestampcolonnes , DeviceIdet ReportId doivent apparaître dans le même événement
   • Pour les tables Alert*, Timestamp doit apparaître dans l’événement
   • Pour les tables Observation*, Timestampet ObservationId doivent apparaître dans le même événement
   • Pour tous les autres, Timestamp et ReportId doit apparaître dans le même événement

3. Colonne qui contient un identificateur fort pour une ressource affectée. Pour mapper automatiquement une ressource impactée dans l’Assistant, projetez l’une des colonnes suivantes qui contiennent un identificateur fort pour une ressource impactée :

   • DeviceId
   • DeviceName
   • RemoteDeviceName
   • RecipientEmailAddress
   • SenderFromAddress(expéditeur d’enveloppe ou adresse de chemin d’accès)
   • SenderMailFromAddress(adresse de l’expéditeur affichée par le client de messagerie)
   • SenderObjectId
   • RecipientObjectId
   • AccountObjectId
   • AccountSid
   • AccountUpn
   • InitiatingProcessAccountSid
   • InitiatingProcessAccountUpn
   • InitiatingProcessAccountObjectId

Les requêtes simples, telles que celles qui n’utilisent pas l’opérateur project ou summarize pour personnaliser ou agréger les résultats, retournent généralement ces colonnes courantes.

Il existe plusieurs façons de s’assurer que les requêtes plus complexes retournent ces colonnes. Par exemple, si vous préférez agréger et compter par entité sous une colonne telle que DeviceId, vous pouvez toujours retourner Timestamp et ReportId en les obtenir à partir de l’événement le plus récent impliquant chaque unique DeviceId.

L’exemple de requête suivant compte le nombre d’appareils uniques (DeviceId) avec des détections antivirus et utilise ce nombre pour rechercher uniquement les appareils avec plus de cinq détections. Pour retourner le dernier Timestamp et le correspondant ReportId, il utilise l’opérateur summarize avec la arg_max fonction .

DeviceEvents
| where ingestion_time() > ago(1d)
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId
| where count_ > 5

2. Créer une règle et fournir les détails de l’alerte

Avec la requête dans l’éditeur de requête, sélectionnez Créer une règle de détection et spécifiez les détails d’alerte suivants :

• Nom de la détection : nom de la règle de détection ; doit être unique.
• Fréquence : intervalle d’exécution de la requête et d’action. Pour plus d’informations, consultez la section Fréquence des règles
• Titre de l’alerte : titre affiché avec les alertes déclenchées par la règle ; doit être unique et en texte clair. Les chaînes sont nettoyées à des fins de sécurité, de sorte que HTML, Markdown et tout autre code ne fonctionnent pas. Toutes les URL incluses dans le titre doivent suivre le format d’encodage du pourcentage pour qu’elles s’affichent correctement.
• Gravité : risque potentiel du composant ou de l’activité identifié par la règle.
• Catégorie : composant ou activité de menace identifié par la règle.
• MITRE ATT&techniques CK : une ou plusieurs techniques d’attaque identifiées par la règle, comme indiqué dans l’infrastructure MITRE ATT&CK. Cette section est masquée pour certaines catégories d’alertes, notamment les logiciels malveillants, les rançongiciels, les activités suspectes et les logiciels indésirables.
• Rapport d’analyse des menaces : liez l’alerte générée à un rapport d’analyse des menaces existant afin qu’elle apparaisse sous l’onglet Incidents associés de l’analyse des menaces.
• Description : plus d’informations sur le composant ou l’activité identifié par la règle. Les chaînes sont nettoyées à des fins de sécurité, de sorte que HTML, Markdown et tout autre code ne fonctionnent pas. Toutes les URL incluses dans la description doivent suivre le format d’encodage en pourcentage pour qu’elles s’affichent correctement.
• Actions recommandées : actions supplémentaires que les répondeurs peuvent effectuer en réponse à une alerte.

Fréquence de la règle

Lorsque vous enregistrez une nouvelle règle, elle s’exécute et recherche les correspondances des 30 derniers jours de données. La règle s’exécute ensuite à nouveau à intervalles fixes, en appliquant une période de recherche arrière en fonction de la fréquence que vous choisissez :

• Toutes les 24 heures : s’exécute toutes les 24 heures, en vérifiant les données des 30 derniers jours.
• Toutes les 12 heures : s’exécute toutes les 12 heures, en vérifiant les données des dernières 48 heures.
• Toutes les 3 heures : s’exécute toutes les 3 heures, en vérifiant les données des dernières 12 heures.
• Toutes les heures : s’exécute toutes les heures, en vérifiant les données des 4 dernières heures.
• Continu (NRT) : s’exécute en continu, en vérifiant les données des événements à mesure qu’ils sont collectés et traités en quasi temps réel (NRT). Consultez Fréquence continue (NRT).
• Personnalisé : s’exécute en fonction de la fréquence que vous avez sélectionnée. Cette option est disponible si la règle est basée uniquement sur des données ingérées à Microsoft Sentinel. Consultez Fréquence personnalisée pour les données Microsoft Sentinel (préversion) .

Lorsque vous modifiez une règle, les modifications sont appliquées lors de la prochaine exécution planifiée en fonction de la fréquence que vous définissez. La fréquence de la règle est basée sur l’horodatage de l’événement et non sur le temps d’ingestion. Il peut également y avoir de petits retards dans des exécutions spécifiques, où la fréquence configurée n’est pas précise à 100 %.

Fréquence continue (NRT)

La définition d’une détection personnalisée pour qu’elle s’exécute en fréquence continue (NRT) augmente la capacité de votre organization à identifier les menaces plus rapidement. L’utilisation de la fréquence continue (NRT) a un impact minime ou nul sur l’utilisation de vos ressources et doit donc être prise en compte pour toute règle de détection personnalisée qualifiée dans votre organization.

À partir de la page Règles de détection personnalisées, vous pouvez migrer des règles de détection personnalisées qui correspondent à la fréquence continue (NRT) avec un seul bouton, Migrer maintenant :

La sélection de Migrer vous donne maintenant une liste de toutes les règles compatibles en fonction de leur requête KQL. Vous pouvez choisir de migrer toutes les règles ou les règles sélectionnées uniquement en fonction de vos préférences :

Une fois que vous avez sélectionné Enregistrer, la fréquence des règles sélectionnées est mise à jour en fréquence continue (NRT).

Requêtes que vous pouvez exécuter en continu

Vous pouvez exécuter une requête en continu tant que :

• La requête fait référence à une seule table.
• La requête utilise un opérateur de la liste des fonctionnalités KQL prises en charge. (Pour matches regex, les expressions régulières doivent être encodées en tant que littéraux de chaîne et suivre les règles de guillemets de chaîne. Par exemple, l’expression \A régulière est représentée dans KQL sous la forme "\\A". La barre oblique inverse supplémentaire indique que l’autre barre oblique inverse fait partie de l’expression \Arégulière .)
• La requête n’utilise pas de jointures, d’unions ou d’opérateur externaldata .
• La requête n’inclut aucune ligne/information de commentaire.

Tables qui prennent en charge la fréquence continue (NRT)

Les détections en quasi-temps réel sont prises en charge pour les tables suivantes :

• AlertEvidence
• CloudAppEvents
• DeviceEvents
• DeviceFileCertificateInfo
• DeviceFileEvents
• DeviceImageLoadEvents
• DeviceLogonEvents
• DeviceNetworkEvents
• DeviceNetworkInfo
• DeviceInfo
• DeviceProcessEvents
• DeviceRegistryEvents
• EmailAttachmentInfo
• EmailEvents (à l’exception des LatestDeliveryLocation colonnes et LatestDeliveryAction )
• EmailPostDeliveryEvents
• EmailUrlInfo
• IdentityDirectoryEvents
• IdentityLogonEvents
• IdentityQueryEvents
• UrlClickEvents

Fréquence personnalisée pour les données Microsoft Sentinel (préversion)

Microsoft Sentinel clients qui sont intégrés à Microsoft Defender peuvent sélectionner Fréquence personnalisée lorsque la règle est basée uniquement sur des données ingérées à Microsoft Sentinel.

Lorsque vous sélectionnez cette option de fréquence, le composant Exécuter la requête chaque entrée s’affiche. Tapez la fréquence souhaitée pour la règle et utilisez la liste déroulante pour sélectionner les unités : minutes, heures ou jours. La plage prise en charge est n’importe quelle valeur comprise entre 5 minutes et 14 jours. Lorsque vous sélectionnez une fréquence, la période de recherche arrière est déterminée automatiquement avec la logique suivante :

1. Pour les détections définies pour s’exécuter plus d’une fois par jour, la recherche arrière est quatre fois la fréquence. Par exemple, si la fréquence est de 20 minutes, la recherche arrière est de 80 minutes.
2. Pour les détections définies pour s’exécuter une fois par jour ou moins fréquemment, la recherche arrière est de 30 jours. Par exemple, si la valeur est définie pour s’exécuter tous les trois jours, la recherche arrière est de 30 jours.

3. Définir les détails de l’enrichissement des alertes

Vous pouvez enrichir les alertes en fournissant et en définissant plus de détails, ce qui vous permet d’effectuer les actions suivantes :

• Créer un titre et une description d’alerte dynamiques
• Ajouter des détails personnalisés à afficher dans le panneau latéral de l’alerte
• Lier des entités

Créer un titre et une description d’alerte dynamiques (préversion)

Vous pouvez créer dynamiquement le titre et la description de votre alerte en utilisant les résultats de votre requête pour les rendre exacts et indicatifs. Cette fonctionnalité peut améliorer l’efficacité des analystes SOC lors du tri des alertes et des incidents, et lors de la tentative de comprendre rapidement l’essence d’une alerte.

Pour configurer dynamiquement le titre ou la description de l’alerte, intégrez-les à la section Détails de l’alerte en utilisant les noms de texte libre des colonnes disponibles dans les résultats de votre requête et en les entourant de doubles accolades.

Par exemple : User {{AccountName}} unexpectedly signed in from {{Location}}

Pour vous aider à choisir les noms de colonnes exacts que vous souhaitez référencer, vous pouvez sélectionner Explorer la requête et les résultats, ce qui ouvre le volet Contexte de repérage avancé au-dessus de l’Assistant Création de règles, où vous pouvez examiner votre logique de requête et ses résultats.

Ajouter des détails personnalisés (préversion)

Vous pouvez améliorer davantage la productivité de vos analystes SOC en affichant des détails importants dans le panneau latéral de l’alerte. Vous pouvez exposer les données des événements dans des alertes qui sont construites à partir de ces événements. Cette fonctionnalité donne à vos analystes SOC une visibilité immédiate du contenu des événements de leurs incidents, ce qui leur permet de trier, d’examiner et de tirer des conclusions plus rapidement.

Dans la section Détails personnalisés , ajoutez des paires clé-valeur correspondant aux détails que vous souhaitez exposer :

• Dans le champ Clé , entrez un nom de votre choix qui apparaît comme nom de champ dans les alertes.
• Dans le champ Paramètre , choisissez le paramètre d’événement que vous souhaitez exposer dans les alertes dans la liste déroulante. Cette liste est remplie par des valeurs correspondant aux noms de colonnes générés par votre requête KQL.

La capture d’écran suivante montre comment les détails personnalisés sont exposés dans le panneau latéral de l’alerte :

Lier des entités

Identifiez les colonnes dans les résultats de votre requête où vous vous attendez à trouver l’entité principale affectée ou affectée. Par exemple, une requête peut retourner les adresses de l’expéditeur (SenderFromAddress ou SenderMailFromAddress) et du destinataire (RecipientEmailAddress). Identifier laquelle de ces colonnes représente la principale entité impactée qui aide le service à agréger les alertes pertinentes, à corréler les incidents et à cibler les actions de réponse.

Vous ne pouvez sélectionner qu’une seule colonne pour chaque type d’entité (boîte aux lettres, utilisateur ou appareil). Vous ne pouvez pas sélectionner des colonnes qui ne sont pas retournées par votre requête.

Mappage d’entités développé (préversion)

Vous pouvez lier un large éventail de types d’entités à vos alertes. La liaison d’entités supplémentaires aide notre moteur de corrélation à regrouper les alertes aux mêmes incidents et à corréler les incidents ensemble. Si vous êtes un client Microsoft Sentinel, cela signifie également que vous pouvez mapper n’importe quelle entité de vos sources de données tierces qui sont ingérées dans Microsoft Sentinel.

Pour Microsoft Defender XDR données, les entités sont automatiquement sélectionnées. Si les données proviennent de Microsoft Sentinel, vous devez sélectionner les entités manuellement.

Il existe deux sections sous la section Mappage d’entités développée pour lesquelles vous pouvez sélectionner des entités :

• Ressources impactées : ajoutez les ressources impactées qui apparaissent dans les événements sélectionnés. Les types de ressources suivants peuvent être ajoutés :
  • Compte
  • Appareil
  • Boîte aux lettres
  • Application cloud
  • Ressource Azure
  • Ressource Amazon Web Services
  • Ressource Google Cloud Platform
• Preuve associée : ajoutez des non-éléments qui apparaissent dans les événements sélectionnés. Les types d’entités pris en charge sont les suivants :
  • Processus
  • Fichier
  • Valeur de Registre
  • IP
  • Application OAuth
  • DNS
  • Groupe de sécurité
  • URL
  • Cluster de messagerie
  • Courrier électronique

Après avoir sélectionné un type d’entité, sélectionnez un type d’identificateur qui existe dans les résultats de requête sélectionnés afin qu’il puisse être utilisé pour identifier cette entité. Chaque type d’entité a une liste d’identificateurs pris en charge, comme indiqué dans le menu déroulant approprié. Lisez la description affichée lorsque vous pointez sur chaque identificateur pour mieux le comprendre.

Après avoir sélectionné l’identificateur, sélectionnez une colonne dans les résultats de la requête qui contient l’identificateur sélectionné. Sélectionnez Explorer la requête et les résultats pour ouvrir le panneau de contexte de repérage avancé. Cette option vous permet d’explorer votre requête et vos résultats pour vous assurer que vous choisissez la colonne appropriée pour l’identificateur sélectionné.

4. Spécifier des actions

Si votre règle de détection personnalisée utilise Defender XDR données, elle peut effectuer automatiquement des actions sur les appareils, les fichiers, les utilisateurs ou les e-mails retournés par la requête.

Actions sur des appareils

Ces actions sont appliquées aux appareils dans la colonne DeviceIddes résultats de la requête:

• Isoler l’appareil : utilise Microsoft Defender pour point de terminaison pour appliquer une isolation réseau complète, empêchant l’appareil de se connecter à une application ou à un service. En savoir plus sur Microsoft Defender pour point de terminaison’isolation de machine.
• Collecter le package d’investigation : collecte les informations sur l’appareil dans un fichier ZIP. En savoir plus sur le package d’investigation Microsoft Defender pour point de terminaison.
• Exécuter l’analyse antivirus : effectue une analyse antivirus complète Microsoft Defender sur l’appareil.
• Lancer une investigation : lance une investigation automatisée sur l’appareil.
• Restreindre l’exécution de l’application : définit des restrictions sur l’appareil pour autoriser uniquement l’exécution des fichiers signés avec un certificat émis par Microsoft. En savoir plus sur les restrictions d’application avec Microsoft Defender pour point de terminaison.

Actions sur les fichiers

• Lorsqu’elle est sélectionnée, l’action Autoriser/Bloquer peut être appliquée au fichier. Les fichiers bloquants ne sont autorisés que si vous disposez des autorisations Corriger pour les fichiers et si les résultats de la requête ont identifié un ID de fichier, tel qu’un SHA1. Une fois qu’un fichier est bloqué, d’autres instances du même fichier sur tous les appareils sont également bloquées. Vous pouvez contrôler le groupe d’appareils auquel le blocage est appliqué, mais pas des appareils spécifiques.

• Lorsqu’elle est sélectionnée, l’action Fichier de mise en quarantaine peut être appliquée aux fichiers dans la SHA1colonne , InitiatingProcessSHA1SHA256, ou InitiatingProcessSHA256 des résultats de la requête. Cette action supprime le fichier de son emplacement actuel et place une copie en quarantaine.

Actions sur les utilisateurs

• Lorsque cette option est sélectionnée, l’actionMarquez l’utilisateur comme compromis est effectuée sur les utilisateurs de la colonneAccountObjectId, InitiatingProcessAccountObjectId ou RecipientObjectIdcolonne des résultats de la requête. Cette action définit le niveau de risque des utilisateurs sur « élevé » dans Microsoft Entra ID, déclenchant les stratégies de protection des identités correspondantes.

• Sélectionnez Désactiver l’utilisateur pour empêcher temporairement un utilisateur de se connecter.

• Sélectionnez Forcer la réinitialisation du mot de passe pour inviter l’utilisateur à modifier son mot de passe lors de la prochaine session de connexion.

• Disable user Les options et Force password reset nécessitent le SID utilisateur, qui se trouve dans les colonnes AccountSid, InitiatingProcessAccountSid, RequestAccountSidet OnPremSid.

Pour plus d’informations sur les actions de l’utilisateur, consultez Actions de correction dans Microsoft Defender pour Identity.

Actions sur les e-mails

• Si la détection personnalisée génère des messages électroniques, vous pouvez sélectionner Déplacer vers le dossier de boîte aux lettres pour déplacer l’e-mail vers un dossier sélectionné (dossier Courrier indésirable, Boîte de réception ou Éléments supprimés ). Plus précisément, vous pouvez déplacer les résultats des e-mails à partir d’éléments mis en quarantaine (pour instance, dans le cas de faux positifs) en sélectionnant l’option Boîte de réception.

  

• Vous pouvez également sélectionner Supprimer l’e-mail , puis choisir de déplacer les e-mails vers Éléments supprimés (suppression réversible) ou de supprimer définitivement les e-mails sélectionnés (suppression définitive).

Les colonnes NetworkMessageId et RecipientEmailAddress doivent être présentes dans les résultats de sortie de la requête pour appliquer des actions aux messages électroniques.

5. Définir l’étendue de la règle

Définissez l’étendue pour spécifier les appareils couverts par la règle. L’étendue influence les règles qui vérifient les appareils et n’affecte pas les règles qui vérifient uniquement les boîtes aux lettres et les comptes d’utilisateur ou les identités.

Lorsque vous définissez l’étendue, vous pouvez sélectionner:

• Tous les appareils
• Groupes d’appareils spécifiques

La règle interroge uniquement les données des appareils de l’étendue. Il effectue des actions uniquement sur ces appareils.

6. Examiner et activer la règle

Après avoir examiné la règle, sélectionnez Créer pour l’enregistrer. La règle de détection personnalisée s’exécute immédiatement. Il s’exécute à nouveau en fonction de la fréquence configurée pour case activée pour les correspondances, générer des alertes et effectuer des actions de réponse.

Comment les détections personnalisées gèrent les alertes en double

Lors de la création et de l’examen de règles de détection personnalisées, il est important de prendre en compte le bruit et la fatigue des alertes. Les détections personnalisées regroupent et dédupliquent les événements en une seule alerte. Si une détection personnalisée se déclenche deux fois sur un événement qui contient les mêmes entités, détails personnalisés et détails dynamiques, elle crée une seule alerte pour ces deux événements. Si la détection reconnaît que les événements sont identiques, elle journalise un seul des événements sur l’alerte créée, puis s’occupe des doublons, ce qui peut se produire lorsque la période de recherche arrière est plus longue que la fréquence. Si les événements sont différents, la détection personnalisée journalise les deux événements sur l’alerte.

Voir aussi

• Vue d’ensemble des détections personnalisées
• Gérer les détections personnalisées
• Vue d’ensemble du repérage avancé
• Découvrir le langage de requête de repérage avancé
• Migrer des requêtes de chasse avancées à partir de Microsoft Defender pour point de terminaison
• API de sécurité Microsoft Graph pour les détections personnalisées