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

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

Identifier et migrer des règles

Microsoft Sentinel utilise l’analytique machine learning pour créer des incidents haute fidélité et actionnables, et certaines de vos détections existantes peuvent être redondantes dans Microsoft Sentinel. Par conséquent, ne migrez pas toutes vos règles de détection et d’analytique à l’aveugle. Passez en revue ces considérations lorsque vous identifiez vos règles de détection existantes.

• Veillez à sélectionner des cas d’usage qui justifient la migration des règles, en tenant compte de la priorité métier et de l’efficacité.
• Vérifiez que vous comprenez Microsoft Sentinel types de règles.
• Vérifiez que vous comprenez la terminologie de la règle.
• Passez en revue les règles qui n’ont déclenché aucune alerte 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 case activée si les règles analytiques intégrées de Microsoft Sentinel peuvent répondre à 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.
• Confirmez les sources de données connectées et passez en revue vos méthodes de connexion de données. Revisitez les conversations de collecte de données pour garantir la profondeur et l’étendue des données dans les cas d’usage que vous prévoyez de détecter.
• Explorez les ressources de la communauté telles que soc Prime Threat Detection Marketplace pour case activée si vos règles sont disponibles.
• Déterminez si un convertisseur de requêtes 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. Passez en revue le mappage des règles pour créer des requêtes.

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

Pour migrer vos règles d’analyse vers Microsoft Sentinel :

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

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

   2. Vérifiez que votre équipe dispose de ressources utiles pour tester vos règles migrées.

   3. Vérifiez que toutes les sources de données requises sont connectées et passez en revue vos méthodes de connexion de données.

2. Vérifiez si vos détections sont disponibles en tant que modèles intégrés dans le hub de contenu :

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

     1. Dans Microsoft Sentinel, accédez au hub de contenu gestion de > contenu.
     2. Recherchez et installez la règle d’analyse appropriée.

     Pour plus d’informations, consultez Découvrir et gérer Microsoft Sentinel contenu prête à l’emploi et Créer des règles d’analyse planifiées à partir de modèles.

   • Si vous avez des détections qui ne sont pas couvertes par les règles intégrées disponibles dans le Hub de contenu, essayez un convertisseur de requête en ligne, tel que Uncoder.io pour convertir vos requêtes en KQL.

     Identifiez la condition de déclencheur et l’action de règle, puis construisez et examinez votre requête KQL.

   • Si ni les solutions du hub de contenu ni le convertisseur de règles en ligne ne sont suffisants, vous devez 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 mappage entre des sources de données et des tables de données dans Microsoft Sentinel pour identifier les tables que vous souhaitez interroger.

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

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

        Considérez les filtres, les règles de corrélation, les listes actives, les ensembles de références, les watchlists, les anomalies de détection, les agrégations, etc. Vous pouvez utiliser des références fournies par votre siem hérité pour comprendre comment mapper au mieux la syntaxe de votre requête.

     4. Identifiez la condition de déclencheur et l’action de règle, puis construisez et examinez votre requête KQL. Lorsque vous examinez votre requête, tenez compte des ressources de conseils d’optimisation KQL.

3. Testez la règle avec chacun de vos cas d’usage pertinents. S’il ne fournit pas les résultats attendus, vous pouvez examiner le KQL et le tester à nouveau.

4. Lorsque vous êtes satisfait, vous pouvez considérer la règle migrée. Créez un playbook pour votre action de règle en fonction des besoins. Pour plus d’informations, consultez Automatiser la réponse aux menaces avec des playbooks dans Microsoft Sentinel.

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

• Règles d’analyse planifiées dans Microsoft Sentinel. Utilisez le regroupement d’alertes pour réduire la fatigue des alertes en regroupant les alertes qui se produisent dans une période donnée.
• Mapper des champs de données à des entités dans Microsoft Sentinel pour permettre aux ingénieurs SOC de définir des entités dans le cadre de la preuve à suivre pendant une enquête. Le mappage d’entités permet également aux analystes SOC de tirer parti d’un graphique d’investigation intuitif qui peut aider à réduire le temps et les efforts.
• Examinez les incidents avec des données UEBA, comme exemple d’utilisation des preuves pour faire apparaître des événements, des alertes et des signets associés à un incident particulier dans le volet d’aperçu de l’incident.
• Langage de requête Kusto (KQL) que vous pouvez utiliser pour envoyer des requêtes en lecture seule à votre base de données Log Analytics afin de traiter des données et de retourner des résultats. KQL est également utilisé dans d’autres services Microsoft, tels que Microsoft Defender pour point de terminaison et Application Insights.

Comparer la terminologie des règles

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

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.

Syntaxe courante des tests de propriété

Voici la syntaxe QRadar pour une règle de test de propriété commune.

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

Voici la syntaxe d’un exemple de règle de tests de propriété commune 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.

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

Voici la règle de test de propriété commune 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 courants : exemple de requête de filtre AQL (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriétés communs 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.

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

Voici la règle de test de propriété commune avec une requête de filtre AQL dans KQL.

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Tests de propriétés courants : égal/non égal à l’exemple (QRadar)

Voici la syntaxe d’un exemple de règle de tests de propriété commune 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.

Tests de propriété courants : est égal/différent de l’exemple (KQL)

Voici la règle de tests de propriété commune 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.

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

Voici la syntaxe d’un exemple de règle de test 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.

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

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

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

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

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

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.

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

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

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

Tests de date/heure : après/avant/à l’exemple (QRadar)

Voici la syntaxe d’un exemple de règle de tests de date/heure QRadar qui utilise l’opérateur after, beforeou 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.

Tests de date/heure : après/avant/à l’exemple (KQL)

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

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

TimeGenerated est en UTC/GMT.

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

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

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

Voici la syntaxe d’un exemple de règle de test de propriété 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.

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

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

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

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

and when the Event Payload contains <this string>

Voici l’exemple de règle dans QRadar.

Tests de propriété 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 search commande 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.

Compteurs : propriété d’événement et exemple d’heure (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 dans 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.

Compteurs : propriété d’événement et exemple d’heure (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.

Exemple de conditions négatives (QRadar)

Voici la syntaxe d’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.

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

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.

Exemple de conditions simples (QRadar)

Voici la syntaxe d’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.

Exemple de conditions simples (KQL)

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

Syntaxe des tests IP/port

Voici la syntaxe QRadar pour une règle de tests IP/port.

Tests IP/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.

Tests IP/port : exemple de port source (KQL)

CommonSecurityLog
| where SourcePort == 20

Tests IP/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.

Tests IP/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.

Exemple de source de journal (QRadar)

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

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

Voici l’exemple de règle dans QRadar.

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 à Microsoft Sentinel.