Partager via


Migrer des règles de détection QRadar vers Microsoft Sentinel

Cet article décrit comment identifier, comparer et migrer vos règles de détection QRadar vers des règles intégrées Microsoft Sentinel.

Identifier et migrer des règles

Microsoft Sentinel utilise l’analytique Machine Learning pour créer des incidents de haute fidélité actionnables. Certaines de vos détections existantes peuvent être redondantes dans Microsoft Sentinel. Par conséquent, ne migrez pas aveuglément toutes vos règles de détection et d’analyse. Passez en revue ces considérations quand vous identifiez vos règles de détection existantes.

  • Veillez à sélectionner les cas d’usage qui justifient la migration des règles, en tenant compte des priorités et de l’efficacité de l’entreprise.
  • Vérifiez que vous comprenez les types de règles Microsoft Sentinel.
  • Vérifiez que vous comprenez la terminologie des règles.
  • Examinez toutes les règles qui n’ont pas déclenché d’alertes au cours des 6 à 12 derniers mois et déterminez si elles sont toujours pertinentes.
  • Éliminez les menaces ou les alertes de bas niveau que vous ignorez régulièrement.
  • Utilisez les fonctionnalités existantes et vérifiez si les règles d’analytique intégrées de Microsoft Sentinel peuvent traiter vos cas d’usage actuels. Étant donné que Microsoft Sentinel utilise l’analytique Machine Learning pour produire des incidents haute fidélité et actionnables, il est probable que certaines de vos détections existantes ne soient plus nécessaires.
  • Vérifiez que vous avez connecté toutes les sources de données requises et passez en revue vos méthodes de connexion de données. Revenez sur les conversations de collecte de données pour vous assurer de la profondeur et de l’étendue des données dans vos cas d’usage.
  • Explorez les ressources de la communauté telles que la Place de marché de détection des menaces SOC Prime pour vérifier si vos règles sont disponibles.
  • Déterminez si un convertisseur de requête en ligne tel que Uncoder.io peut fonctionner pour vos règles.
  • Si les règles ne sont pas disponibles ou ne peuvent pas être converties, elles doivent être créées manuellement à l’aide d’une requête KQL. Examinez le mappage des règles pour créer de nouvelles requêtes.

En savoir plus sur les meilleures pratiques relatives à la migration des règles de détection.

Pour migrer vos règles d’analytique vers Microsoft Sentinel, procédez comme suit :

  1. Vérifiez que vous avez mis en place un système de test pour chaque règle que vous souhaitez migrer.

    1. Préparez un processus de validation pour vos règles migrées, y compris des scénarios et des scripts de test complets.

    2. Assurez-vous que votre équipe dispose des ressources utiles pour tester vos règles migrées.

    3. Confirmez que vous avez connecté toutes les sources de données requises, et révisez vos méthodes de connexion de données.

  2. Vérifiez si vos détections sont disponibles comme modèles intégrés dans Microsoft Sentinel :

    • Si les règles intégrées sont suffisantes, utilisez les modèles de règles intégrées pour créer des règles pour votre propre espace de travail.

      Dans Microsoft Sentinel, accédez à l’onglet Configuration > Analytique > Modèles de règles, puis créez et mettez à jour chacune des règles d’analytique pertinentes.

      Pour plus d’informations, consultez Détection des menaces prête à l’emploi.

    • Si certaines de vos détections ne sont pas couvertes par les règles intégrées de Microsoft Sentinel, essayez un convertisseur de requêtes en ligne, par exemple Uncoder.io, pour convertir vos requêtes en KQL.

      Identifiez la condition du déclencheur et l’action de la règle, puis créez et passez en revue votre requête KQL.

    • Si ni les règles intégrées ni un convertisseur de règles en ligne ne suffisent, vous devrez créer la règle manuellement. Dans ce cas, procédez comme suit pour commencer à créer votre règle :

      1. Identifiez les sources de données que vous souhaitez utiliser dans votre règle. Vous devez créer une table de correspondance entre les sources de données et les tables de données de Microsoft Sentinel pour identifier les tables que vous souhaitez interroger.

      2. Identifiez tous les attributs, champs ou entités de vos données que vous souhaitez utiliser dans vos règles.

      3. Identifiez les critères et la logique de vos règles. À ce stade, vous pouvez utiliser des modèles de règle comme exemples pour construire vos requêtes KQL.

        Pensez aux filtres, aux règles de corrélation, aux listes actives, aux ensembles de référence, aux listes de surveillance, aux anomalies de détection, aux agrégations, etc. Vous pouvez utiliser les références fournies par votre SIEM héritée pour comprendre comment mapper au mieux la syntaxe de vos requêtes.

      4. Identifiez la condition du déclencheur et l’action de la règle, puis créez et passez en revue votre requête KQL. Lorsque vous examinez votre requête, tenez compte des aides relatives à l’optimisation de KQL.

  3. Testez la règle avec chacun de vos cas d’usage pertinents. Si elle ne fournit pas les résultats attendus, vous pouvez revoir la requête KQL et la tester à nouveau.

  4. Lorsque vous êtes satisfait, vous pouvez considérer que la règle a été migrée. Créez un playbook pour votre action de règle le cas échéant. Pour plus d’informations, consultez Automatisation de la réponse aux menaces avec des playbooks dans Microsoft Sentinel.

En savoir plus sur les règles d’analytique :

Comparer la terminologie des règles

Ce tableau vous aide à clarifier le concept d’une règle dans Microsoft Sentinel par rapport à QRadar.

QRadar Microsoft Sentinel
Type de règle • Événements
• Flux
• Courant
• Infraction
• Règles de détection des anomalies
• Requête planifiée
• Fusion
• Sécurité Microsoft
• Analytique comportementale du Machine Learning
Critères Définir dans la condition de test Définir dans KQL
Condition de déclencheur Définir dans la règle Seuil : le nombre de résultats de la requête
Action • Créer une infraction
• Distribuer un nouvel événement
• Ajouter à un jeu ou des données de référence
• Et plus
• Créer une alerte ou un incident
• S’intègre à Logic Apps

Mapper et comparer des exemples de règles

Utilisez ces exemples pour comparer et mapper des règles de QRadar à Microsoft Sentinel dans différents scénarios.

Règle Syntaxe Exemple de règle de détection (QRadar) Exemples de requête KQL Ressources
Tests de propriétés courantes Syntaxe QRadar Exemple d’expression régulière
Exemple de requête de filtre AQL
Exemple equals/not equals
Exemple d’expression régulière
Exemple de requête de filtre AQL
Exemple equals/not equals
• Expression régulière : matches regex
• Requête de filtre AQL : opérateurs de chaîne
• equals/not equals : opérateurs de chaîne
Tests de date/heure Syntaxe QRadar Exemple de jour du mois sélectionné
Exemple de jour de la semaine sélectionné
Exemple after/before/at
Exemple de jour du mois sélectionné
Exemple de jour de la semaine sélectionné
Exemple after/before/at
Opérateurs de date et d’heure
• Jour du mois sélectionné : dayofmonth()
• Jour de la semaine sélectionné : dayofweek()
• after/before/at : format_datetime()
Tests de propriétés d’événement Syntaxe QRadar Exemple de protocole IP
Exemple de chaîne de charge utile d’événement
Exemple de protocole IP
Exemple de chaîne de charge utile d’événement
• Protocole IP : opérateurs de chaîne
• Chaîne de charge utile d’événement : has
Fonctions : compteurs Syntaxe QRadar Exemple de propriété et d’heure d’événement Exemple de propriété et d’heure d’événement summarize
Fonctions : conditions négatives Syntaxe QRadar Exemple de conditions négatives Exemple de conditions négatives join()
Opérateurs de chaîne
Opérateurs numériques
Fonctions : simples Syntaxe QRadar Exemple de conditions simples Exemple de conditions simples or
Tests d’adresses IP/de ports Syntaxe QRadar Exemple de port source
Exemple d’adresse IP source
Exemple de port source
Exemple d’adresse IP source
Type de source de journal Syntaxe QRadar Exemple de source de journal Exemple de source de journal

Syntaxe des tests de propriétés courantes

Voici la syntaxe QRadar pour une règle de tests de propriétés courantes.

Diagramme illustrant une syntaxe de règle de test de propriété courante.

Tests de propriétés courantes : exemple d’expression régulière (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise une expression régulière :

when any of <these properties> match <this regular expression>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de propriété commune qui utilise une expression régulière.

Tests de propriétés courantes : exemple d’expression régulière (KQL)

Voici la règle de tests de propriétés courantes avec une expression régulière dans KQL.

CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"

Tests de propriétés courantes : exemple de requête de filtre AQL (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise une requête de filtre AQL.

when the event matches <this> AQL filter query

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de propriété courante qui utilise une requête de filtre AQL.

Tests de propriétés courantes : exemple de requête de filtre AQL (KQL)

Voici la règle de tests de propriétés courantes avec une requête de filtre AQL dans KQL.

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Tests de propriétés courantes : exemple equals/not equals (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise l’opérateur equals ou not equals.

and when <this property> <equals/not equals> <this property>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de propriété commune qui utilise equals/not equals.

Tests de propriétés courantes : exemple equals/not equals (KQL)

Voici la règle de tests de propriétés courantes avec l’opérateur equals ou not equals dans KQL.

CommonSecurityLog
| where SourceIP == DestinationIP

Syntaxe des tests de date/heure

Voici la syntaxe QRadar pour une règle de tests de date/heure.

Diagramme illustrant une syntaxe de règle de test de date/heure.

Tests de date/heure : Exemple de jour du mois sélectionné (QRadar)

Voici la syntaxe d’un exemple de règle de tests de date/heure QRadar qui utilise un jour sélectionné du mois.

and when the event(s) occur <on/after/before> the <selected> day of the month

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de date/heure qui utilise un jour sélectionné.

Tests de date/heure : Exemple de jour du mois sélectionné (KQL)

Voici la règle de tests de date/heure avec un jour du mois sélectionné dans KQL.

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Tests de date/heure : Exemple de jour de la semaine sélectionné (QRadar)

Voici la syntaxe d’un exemple de règle de tests de date/heure QRadar qui utilise un jour sélectionné de la semaine :

and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de date/heure qui utilise un jour sélectionné de la semaine.

Tests de date/heure : Exemple de jour de la semaine sélectionné (KQL)

Voici la règle de tests de date/heure avec un jour de la semaine sélectionné dans KQL.

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Tests de date/heure : exemple after/before/at (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés courantes QRadar qui utilise l’opérateur after, before ou at.

and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de date/heure qui utilise l’opérateur after/before/at.

Tests de date/heure : exemple after/before/at (KQL)

Voici la règle de tests de date/heure qui utilise l’opérateur after, before ou at dans KQL.

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated est au format UTC/GMT.

Syntaxe des tests de propriétés d’événement

Voici la syntaxe QRadar pour une règle de tests de propriétés d’événement.

Diagramme illustrant une syntaxe de règle de test de propriété d’événement.

Tests de propriétés d’événement : exemple de protocole IP (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés d’événement QRadar qui utilise un protocole IP.

and when the IP protocol is one of the following <protocols>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de propriété d’événement qui utilise un protocole IP.

Tests de propriétés d’événement : exemple de protocole IP (KQL)

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Tests de propriétés d’événement : exemple de chaîne de charge utile d’événement (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés d’événement QRadar qui utilise une valeur de chaîne Event Payload.

and when the Event Payload contains <this string>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de test de propriété d’événement qui utilise une chaîne de charge utile d’événement.

Tests de propriétés d’événement : exemple de chaîne de charge utile d’événement (KQL)

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Pour optimiser les performances, évitez d’utiliser la commande search si vous connaissez déjà le nom de la table.

Fonctions : syntaxe des compteurs

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des compteurs.

Diagramme illustrant la syntaxe d’une règle de fonctions qui utilise des compteurs.

Compteurs : exemple de propriété et d’heure d’événement (QRadar)

Voici la syntaxe d’un exemple de règle de fonctions QRadar qui utilise un nombre défini de propriétés d’événement en un nombre défini de minutes.

and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de fonctions qui utilise des propriétés d’événement.

Compteurs : exemple de propriété et d’heure d’événement (KQL)

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Fonctions : syntaxe des conditions négatives

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des conditions négatives.

Diagramme illustrant la syntaxe d’une règle de fonctions qui utilise des conditions négatives.

Exemple de conditions négatives (QRadar)

Voici la syntaxe pour un exemple de règle de fonctions QRadar qui utilise des conditions négatives.

and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>

Voici deux règles définies dans QRadar. Les conditions négatives seront basées sur ces règles.

Diagramme illustrant une règle de test de propriété d’événement à utiliser pour une règle de conditions négatives.

Diagramme illustrant une règle de tests de propriété courante à utiliser pour une règle de conditions négatives.

Voici un exemple de règle de conditions négatives basée sur les règles ci-dessus.

Diagramme illustrant une règle de fonction avec des conditions négatives.

Exemple de conditions négatives (KQL)

let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol

Fonctions : syntaxe des conditions simples

Voici la syntaxe QRadar pour une règle de fonctions qui utilise des conditions simples.

Diagramme illustrant la syntaxe d’une règle de fonction qui utilise des conditions simples.

Exemple de conditions simples (QRadar)

Voici la syntaxe pour un exemple de règle de fonctions QRadar qui utilise des conditions simples.

and when an event matches <any|all> of the following <rules>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle de fonction avec des conditions simples.

Exemple de conditions simples (KQL)

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Syntaxe des tests d’adresse IP/de port

Voici la syntaxe QRadar pour une règle de test d’adresse IP/de port.

Diagramme illustrant la syntaxe d’une règle de test d’adresse IP/de port.

Tests d’adresse IP/de port : exemple de port source (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant un port source.

and when the source port is one of the following <ports>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle qui spécifie un port source.

Tests d’adresse IP/de port : exemple de port source (KQL)

CommonSecurityLog
| where SourcePort == 20

Tests d’adresse IP/de port : exemple d’adresse IP source (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant une adresse IP source.

and when the source IP is one of the following <IP addresses>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle qui spécifie une adresse IP source.

Tests d’adresse IP/de port : exemple d’adresse IP source (KQL)

CommonSecurityLog
| where SourceIP in (“10.1.1.1”,”10.2.2.2”)

Syntaxe des tests de source de journal

Voici la syntaxe QRadar pour une règle de tests de source de journal.

Diagramme illustrant la syntaxe d’une règle de test de source de journal.

Exemple de source de journal (QRadar)

Voici la syntaxe d’un exemple de règle QRadar spécifiant des sources de journal.

and when the event(s) were detected by one or more of these <log source types>

Voici l’exemple de règle dans QRadar.

Diagramme illustrant une règle qui spécifie des sources de journaux.

Exemple de source de journal (KQL)

OfficeActivity
| where OfficeWorkload == "Exchange"

Étapes suivantes

Dans cet article, vous avez appris à mapper vos règles de migration de QRadar vers Microsoft Sentinel.