Guide Expert : Déploiement et Opérations sur Microsoft Sentinel (SIEM/SOAR)

Introduction : Industrialiser la Réponse à Incident

Ce guide technique s'adresse aux professionnels de la sécurité et administrateurs confirmés. Nous allons au-delà de la simple activation de Microsoft Sentinel pour nous concentrer sur la mise en place d'un cycle de détection-réponse robuste : depuis la collecte ciblée des logs jusqu'à l'orchestration d'une remédiation automatisée via des playbooks SOAR.

Section 1 : Collecte de Données Stratégique

La pertinence d'un SIEM est directement proportionnelle à la qualité de ses sources de données. Il est crucial de configurer précisément ce qui est collecté.

• Configuration de l'Agent Azure Monitor (AMA) pour Linux : Pour centraliser les logs de vos serveurs Linux (Apache, SSH), le déploiement de l'AMA est essentiel. La configuration se fait via une Data Collection Rule (DCR) dans Azure. Dans cette DCR, vous spécifiez les flux de données à collecter. Par exemple, pour les logs de sécurité :
  • Source : Syslog
  • Niveaux de log : Warning, Error, Critical
  • Facilities : auth, authpriv (pour les logs SSH), daemon
• Connecteurs Tiers via CEF/Syslog : Pour intégrer un pare-feu matériel ou une autre appliance de sécurité, Sentinel utilise le connecteur Syslog, qui attend généralement des logs au format Common Event Format (CEF). La configuration implique la mise en place d'un "log forwarder" (une VM Linux dédiée) qui reçoit les logs de l'équipement et les relaie de manière sécurisée vers l'espace de travail Log Analytics.

Section 2 : Détection Avancée avec KQL - Cas d'une Attaque "Password Spray"

Une attaque "Password Spray" consiste à essayer un seul mot de passe (ex: "Hiver2025!") contre de très nombreux comptes utilisateurs. C'est une technique furtive difficile à détecter. Voici une règle KQL personnalisée pour l'identifier.

// Requête KQL pour une règle d'analyse planifiée
// Variable à définir dans l'interface de la règle :
// let failed_threshold = 10; // Nombre de comptes distincts
// let time_window = 1h; // Fenêtre de temps
SigninLogs
| where TimeGenerated > ago(time_window)
| where ResultType == "50126" // Code d'erreur pour mot de passe invalide
| summarize
    StartTime = min(TimeGenerated),
    EndTime = max(TimeGenerated),
    // Crée une liste unique des comptes attaqués depuis cette IP
    DistinctAccountsAttacked = make_set(UserPrincipalName),
    // Crée une liste des applications ciblées
    ApplicationsTargeted = make_set(AppDisplayName)
    by IPAddress, ResultType
// On ne garde que les IPs qui ont attaqué plus de N comptes différents
| where array_length(DistinctAccountsAttacked) >= failed_threshold
| project StartTime, EndTime, IPAddress, DistinctAccountsAttacked, ApplicationsTargeted

Explication de la requête :

• make_set() : Fonction d'agrégation qui crée un tableau de valeurs uniques. C'est la clé pour différencier une attaque "brute force" (plusieurs mots de passe sur un seul compte) d'un "password spray" (un mot de passe sur plusieurs comptes).
• array_length() : Permet de compter le nombre d'éléments uniques dans le tableau créé par `make_set()`, afin de le comparer à notre seuil.

Section 3 : Réponse Automatisée (SOAR) - Playbook Détaillé

Une fois l'attaque "Password Spray" détectée, une réponse manuelle est trop lente. Nous allons créer un Playbook (Azure Logic App) pour une remédiation instantanée.

Workflow du Playbook :

1. Déclencheur : "Lorsqu'un incident Microsoft Sentinel est créé". On le filtre pour ne s'activer que pour notre règle "Détection de Password Spray".
2. Étape 1 : Obtenir les Entités de l'Incident. Le playbook récupère automatiquement les entités (IPs, comptes) associées à l'incident.
3. Étape 2 : Enrichissement de l'IP. Avant de bloquer, on vérifie la réputation de l'IP source.
   • Action : Utiliser le connecteur "VirusTotal" et l'action "Get IP report".
   • Condition : Si le nombre de détections malveillantes sur VirusTotal est supérieur à 1, alors continuer. Sinon, poster une simple alerte pour analyse manuelle.
4. Étape 3 : Actions de Remédiation (si la condition est remplie).
   • Action A - Bloquer l'IP : Utiliser le connecteur "Azure Firewall" ou "Azure Network Security Group" pour créer une règle "Deny" pour l'adresse IP malveillante.
   • Action B - Forcer la déconnexion des utilisateurs : Utiliser le connecteur "Azure AD" et l'action "Révoquer les sessions de l'utilisateur" pour tous les comptes listés dans l'entité de l'incident.
5. Étape 4 : Notification et Documentation.
   • Action : Utiliser le connecteur "Microsoft Teams" pour poster une Adaptive Card dans le canal du SOC. Cette carte contiendra les détails de l'incident, la réputation de l'IP, et les actions de remédiation effectuées.
   • Action : Utiliser l'action "Add comment to incident (V3)" pour documenter toutes les étapes (IP enrichie, IP bloquée, sessions révoquées) directement dans l'incident Sentinel, créant ainsi une piste d'audit complète.