Microsoft Sentinel

Définition

Microsoft Sentinel (anciennement Azure Sentinel) est la solution SIEM et SOAR cloud-native de Microsoft. Elle collecte, normalise et corrèle les journaux d'événements provenant de l'écosystème Microsoft (Microsoft 365, Entra ID, Azure, Defender XDR) comme de sources tierces (pare-feu, EDR, équipements réseau, applications métier), applique des règles de détection et des modèles d'apprentissage automatique, puis déclenche des réponses automatisées via des playbooks construits sur Azure Logic Apps.

Contrairement à un SIEM traditionnel installé sur site, Sentinel ne nécessite aucune infrastructure de collecte ni dimensionnement de cluster : le stockage et la puissance de calcul sont fournis en mode SaaS, facturés au volume de données ingérées et conservées.

Architecture et fonctionnement technique

Sentinel s'appuie sur un espace de travail Log Analytics, qui constitue son socle de stockage et de requêtage. Toutes les données ingérées y sont écrites dans des tables normalisées (SigninLogs, SecurityEvent, CommonSecurityLog, DeviceProcessEvents…) puis interrogées avec le langage KQL (Kusto Query Language).

L'ingestion repose sur plusieurs mécanismes :

• Connecteurs natifs : intégration en quelques clics pour Entra ID, Defender for Endpoint, Defender for Cloud, Azure Activity, Office 365, AWS CloudTrail ou GCP.
• Azure Monitor Agent (AMA) piloté par des Data Collection Rules (DCR), qui permettent de filtrer et transformer les événements avant ingestion — un levier direct de maîtrise des coûts.
• Syslog / CEF via une passerelle Linux, pour les équipements réseau et les pare-feu (Fortinet, Palo Alto, Check Point).
• API Codeless Connector Platform et Logs Ingestion API pour les sources propriétaires.

Plusieurs niveaux de rétention coexistent : les Analytics logs (interrogeables et corrélables), les Basic/Auxiliary logs (moins coûteux, requêtage limité) et l'archivage long terme, utile pour répondre aux exigences de conservation de la directive NIS 2 ou de la norme ISO 27001.

Détection : règles analytiques, UEBA et machine learning

Les détections prennent la forme de règles analytiques écrites en KQL, exécutées à intervalle programmé. Chaque règle produit des incidents enrichis d'entités (compte, hôte, adresse IP, fichier) et mappés sur la matrice MITRE ATT&CK, ce qui facilite l'évaluation de la couverture défensive.

Trois familles de détection cohabitent :

• Règles scheduled : logique explicite, par exemple détecter cinq échecs d'authentification suivis d'un succès depuis un pays inhabituel.
• Fusion : corrélation probabiliste multi-signaux qui identifie des chaînes d'attaque complètes (accès initial → escalade → exfiltration) avec un très faible taux de faux positifs.
• UEBA (User and Entity Behavior Analytics) : établissement d'une ligne de base comportementale par utilisateur et par machine, puis notation des écarts.

Les watchlists (listes d'actifs critiques, de comptes à privilèges, de plages IP autorisées) et les flux de Threat Intelligence au format STIX/TAXII viennent enrichir ces règles.

SOAR : automatisation par playbooks

La partie SOAR repose sur Azure Logic Apps. Un playbook est un workflow déclenché par un incident ou une alerte, capable d'appeler des centaines de connecteurs. Exemples concrets d'automatisation observés en SOC :

• Sur détection d'un impossible travel, révoquer les sessions Entra ID de l'utilisateur, forcer une réinitialisation MFA et poster un message dans Microsoft Teams.
• Sur alerte ransomware issue de Defender for Endpoint, isoler la machine du réseau, créer un ticket ServiceNow et notifier l'astreinte.
• Sur adresse IP malveillante confirmée, ajouter une règle de blocage sur le pare-feu périmétrique via son API.

Les règles d'automatisation permettent en amont de trier les incidents : affectation à un analyste, changement de gravité, fermeture automatique des faux positifs récurrents.

Positionnement et concepts liés

Sentinel se distingue de Microsoft Defender XDR : ce dernier détecte et répond sur les postes, identités, boîtes mail et applications cloud du périmètre Microsoft, tandis que Sentinel agrège l'ensemble du système d'information, y compris l'OT, le legacy et le multicloud. Les deux produits sont désormais unifiés dans le portail Defender, formant une plateforme SOC cohérente. Sentinel s'inscrit ainsi dans une démarche Zero Trust, alimente le processus de threat hunting proactif et sert de base documentaire pour la réponse à incident et l'investigation forensique.

Bonnes pratiques

• Maîtriser le coût dès la conception : filtrer au niveau des DCR, router les logs verbeux (proxy, DNS) vers les tables Basic, et suivre la consommation avec la table Usage.
• Structurer les espaces de travail : privilégier un workspace centralisé plutôt qu'une dispersion par filiale, ou utiliser Azure Lighthouse pour un modèle multi-tenant (MSSP).
• Versionner les règles en infrastructure-as-code (Bicep, Terraform, dépôt Git) pour tracer les évolutions de détection.
• Mesurer la couverture ATT&CK et combler les techniques non détectées plutôt que de multiplier les règles redondantes.
• Tester les playbooks en mode simulation avant d'autoriser des actions destructives comme l'isolation d'un poste de production.
• Adopter le format ASIM (Advanced Security Information Model) pour écrire des requêtes indépendantes de la source de données.

Bien exploité, Microsoft Sentinel réduit fortement le délai moyen de détection et de remédiation ; mal cadré, il devient un poste de dépense difficile à justifier. La qualité de l'ingénierie de détection et la discipline sur le volume ingéré font toute la différence.