Bases de KQL que tout analyste SOC doit connaître

Kusto Query Language (KQL) est la base de la chasse aux menaces et du tri des alertes dans Microsoft Sentinel et Microsoft Defender. Si vous travaillez dans un SOC, la maîtrise de KQL sépare les analystes capables de répondre rapidement à « qu'est-ce qui s'est passé ici ? » de ceux bloqués à cliquer dans les tableaux de bord. Ce n'est pas une référence de langage complète — c'est le sous-ensemble pratique qui est utilisé constamment en service.

Pourquoi KQL compte dans le SOC

KQL est en lecture seule et optimisé pour interroger rapidement d'énormes ensembles de données de journaux. Sentinel, Defender for Endpoint, Azure Monitor et Log Analytics le parlent tous. Une fois que vous le maîtrisez, vous pouvez basculer entre les produits avec le même modèle mental : choisir une table, la filtrer, façonner la sortie. Chaque enquête — triage de phishing, chasses de mouvement latéral, ajustement des faux positifs — commence par une requête.

Le pipe est tout

Les requêtes KQL sont construites comme un pipeline. Vous commencez avec une table et transmettez les données à travers une série d'opérateurs, chacun filtrant, transformant ou résumant le résultat précédent :

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Lisez-le de haut en bas comme une phrase : commencez par les journaux SecurityEvent, ne gardez que les ouvertures de session échouées (4625), limitez au dernier jour, comptez les défaillances par compte/ordinateur, puis triez. Cette lisibilité linéaire est la plus grande force de KQL par rapport à SQL pour la chasse ad hoc.

Opérateurs essentiels à mémoriser

• where — votre filtre principal. Utilisez-le tôt et souvent pour réduire le volume de données avant les opérations coûteuses.
• project — sélectionnez et renommez des colonnes spécifiques, en éliminant le bruit que vous n'avez pas besoin en sortie.
• extend — ajoutez des colonnes calculées sans supprimer les colonnes existantes, utile pour analyser les chaînes ou marquer les conditions.
• summarize — agrégez les données avec count(), sum(), dcount() ou make_set(), presque toujours associé à by.
• join — mettez en corrélation les tables, par exemple en liant les journaux de connexion à l'inventaire des appareils pour repérer les connexions d'appareils non gérés.
• render — visualisez les résultats sous forme de timechart ou barchart directement dans l'éditeur de requête, pratique pour repérer les pics.

Filtrage du temps fait correctement

Filtre toujours sur TimeGenerated (ou la colonne d'horodatage équivalente de la table) aussi tôt que possible dans le pipeline. Les moteurs KQL s'optimisent fortement autour des filtres de plage horaire, et placer | where TimeGenerated > ago(7d) près du haut au lieu du bas peut faire la différence entre une requête qui retourne en secondes et une qui expire sur un locataire occupé.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Correspondance de chaîne : has vs contains vs ==

Une erreur courante est de se fier par défaut à `contains` pour tout. `has` met en correspondance des termes entiers et utilise un index de termes, ce qui le rend considérablement plus rapide sur les grandes tables. Utilisez `contains` uniquement lorsque vous avez besoin de correspondances de sous-chaînes à l'intérieur d'un mot (comme un fragment de domaine partiel), et utilisez `==` pour les correspondances exactes sur des champs structurés comme EventID ou IPAddress. Cette seule habitude accélère notablement les chasses sur les tables à gros volume comme `DeviceNetworkEvents` ou `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Construire une logique de détection réutilisable

Une fois qu'une requête s'avère utile, encapsulez-la en tant que fonction avec let, ou enregistrez-la en tant que règle d'analyse Sentinel avec exécution programmée. Paramétrez les seuils (comme les nombres d'ouverture de session échouées) afin que la même logique s'étend sur les locataires ou soit ajustée sans réécrire à partir de zéro. C'est ainsi que les requêtes de chasse ponctuelles évoluent en détections permanentes qui alertent automatiquement le SOC.

Pièges courants

• Oublier les filtres TimeGenerated, causant des analyses complètes de tables lentes et coûteuses.
• Utiliser summarize avant where, ce qui force le moteur à agréger les données non filtrées.
• Noms de colonnes non correspondants lors de la jointure de tables — vérifiez toujours le schéma avec getschema d'abord.
• Abuser de contains, qui ignore les avantages d'indexation et ralentit les chasses à grande échelle.

KQL récompense les analystes qui pensent en pipelines plutôt qu'en sous-requêtes imbriquées. Commencez chaque enquête avec une fenêtre de temps étroite et une table spécifique, puis élargissez uniquement selon vos besoins.

Si cela vous a donné une base solide, explorez les segments Blue Team et Digital Forensics sur Korra Studio pour d'autres procédures pas à pas de requêtes SOC pratiques et des exercices de création de détections.