Guide

Exigences strictes de résidence des données dans plusieurs régions géographiques.

→Déployer plusieurs espaces de travail Microsoft Sentinel, un par région. Utiliser Azure Lighthouse pour une gestion centralisée.

Pourquoi: Maintient les données de journalisation dans les limites géographiques pour la conformité tout en permettant à un SOC central d'opérer sur tous les espaces de travail.

Référence↗

Espace de travail Sentinel ingérant plus de 100 Go de données par jour.

→Changer le niveau tarifaire de l'espace de travail Log Analytics de Pay-As-You-Go à Commitment Tiers.

Pourquoi: Les Commitment Tiers offrent des économies significatives pour une ingestion de données prévisible et à grand volume par rapport aux tarifs standards.

Les journaux à grand volume (par exemple, les événements de sécurité Windows) augmentent les coûts du SIEM.

→1. Utiliser une règle de collecte de données (DCR) pour filtrer les événements à la source. 2. Configurer la table de destination pour les Basic Logs.

Pourquoi: Les DCR réduisent les coûts d'ingestion en ne collectant que les événements nécessaires. Les Basic Logs réduisent les coûts de stockage pour les données verbeuses ne nécessitant pas d'analyse complète.

Référence↗

La conformité exige une rétention des données de plus de 2 ans (par exemple, 7 ans).

→Configurer l'espace de travail avec une rétention interactive de 90 jours et une rétention totale de 7 ans (niveau d'archive).

Pourquoi: Équilibre la capacité de recherche immédiate (interactive) avec un stockage à faible coût et à long terme (archive). Accéder aux données archivées via les Search Jobs.

Collecter les événements de sécurité des serveurs Windows et Linux sur site.

→Installer l'agent Azure Arc pour la gestion, puis déployer l'Azure Monitor Agent (AMA) via Arc.

Pourquoi: Arc étend le plan de contrôle Azure sur site, permettant une gestion native et la collecte de données avec l'agent AMA moderne.

Ingérer les journaux de périphériques tiers (par exemple, pare-feu) qui prennent en charge Syslog.

→Déployer une VM Linux dédiée comme Log Forwarder avec l'AMA. Utiliser le format CEF pour les données de sécurité structurées.

Pourquoi: Centralise la collecte pour les appareils qui ne peuvent pas héberger d'agent. CEF fournit un schéma normalisé et interrogeable pour les événements de sécurité.

Ingérer les incidents et alertes de Microsoft Defender XDR dans Sentinel.

→Activer le connecteur de données Microsoft Defender XDR et son option de création d'incident/synchronisation bidirectionnelle.

Pourquoi: Crée une file d'attente d'incidents unifiée et garantit que les changements de statut sont synchronisés entre Sentinel et le portail Defender.

Filtrer des ID d'événements Windows spécifiques à la source pour réduire le volume d'ingestion.

→Configurer une règle de collecte de données (DCR) avec une requête XPath pour spécifier les ID d'événements à collecter.

Pourquoi: Réduit le volume et le coût d'ingestion en filtrant les données au niveau de l'agent source, avant qu'elles ne soient envoyées à l'espace de travail.

Exiger le temps de détection le plus rapide possible pour les événements critiques.

→Utiliser une règle d'analyse en quasi temps réel (NRT).

Pourquoi: Les règles NRT s'exécutent toutes les minutes, offrant une latence de détection d'environ 1 à 2 minutes, beaucoup plus rapide que le minimum de 5 minutes pour les règles planifiées.

Détecter un seuil d'événements dans une fenêtre de temps spécifique (par exemple, attaques par force brute).

→Créer une règle d'analyse planifiée utilisant KQL `summarize ... by bin(TimeGenerated, 5m), ...`.

Pourquoi: La fonction `bin()` est essentielle pour regrouper les événements en fenêtres de temps discrètes et non chevauchantes pour une détection précise des seuils.

Détecter les attaques complexes à plusieurs étapes que les alertes individuelles pourraient manquer.

→Activer les règles d'analyse Fusion pour la détection avancée des attaques multistades.

Pourquoi: Fusion utilise le ML pour corréler des signaux de faible fidélité provenant de plusieurs sources de données en incidents de haute confiance, réduisant la fatigue des alertes.

Détecter les menaces internes ou les comptes compromis basés sur un comportement anormal.

→Activer l'analyse du comportement des utilisateurs et des entités (UEBA).

Pourquoi: L'UEBA établit des lignes de base comportementales pour les utilisateurs et les entités, puis signale les déviations significatives qui ne correspondent pas à une logique de règle spécifique.

Écrire une règle d'analyse unique, agnostique à la source, pour plusieurs sources de données (par exemple, DNS de divers fournisseurs).

→Utiliser les analyseurs Advanced Security Information Model (ASIM) dans la requête KQL.

Pourquoi: ASIM fournit un schéma normalisé, permettant aux requêtes de s'exécuter sur une vue unifiée (par exemple, `imDns`) au lieu de plusieurs tables spécifiques aux fournisseurs.

Gérer le contenu de Sentinel (règles d'analyse, classeurs) comme du code et le déployer dans différents environnements.

→Utiliser les dépôts Microsoft Sentinel pour connecter un dépôt GitHub ou Azure DevOps.

Pourquoi: Permet les workflows CI/CD, le contrôle de version et le déploiement automatisé et cohérent du contenu de sécurité (Sentinel-as-Code).

Automatiser les tâches de tri d'incidents de base comme l'affectation de propriétaires, le changement de statut ou l'ajout de balises.

→Utiliser une règle d'automatisation déclenchée lors de la création d'incident.

Pourquoi: Les règles d'automatisation sont légères et synchrones, idéales pour les actions de tri simples sans la complexité d'une Logic App.

Automatiser les réponses complexes aux incidents impliquant des systèmes externes (par exemple, bloquer un utilisateur dans Entra ID, envoyer un message Teams).

→Créer un Playbook (Azure Logic App) et le déclencher à partir d'une règle d'automatisation.

Pourquoi: Les Logic Apps fournissent le moteur d'orchestration et les connecteurs nécessaires pour des réponses et des intégrations complexes en plusieurs étapes.

Comprendre l'étendue d'une attaque en visualisant les relations entre les entités (utilisateurs, IPs, hôtes).

→Utiliser le graphique d'investigation sur la page des détails de l'incident.

Pourquoi: Fournit une carte interactive de l'attaque, facilitant la visualisation des connexions et le pivotement entre les entités et alertes associées.

Standardiser et accélérer les flux de travail d'investigation courants pour l'équipe SOC.

→Créer et partager un Promptbook dans Microsoft Security Copilot.

Pourquoi: Les Promptbooks enchaînent une série d'invites en langage naturel pour créer un processus d'investigation guidé et reproductible pour les scénarios courants.

Gérer les autorisations de sécurité de manière centralisée pour tous les produits Microsoft Defender.

→Activer le modèle RBAC unifié de Microsoft Defender XDR.

Pourquoi: Remplace les rôles spécifiques à chaque produit par un modèle d'autorisation unique et granulaire, simplifiant l'administration.

Isoler automatiquement les appareils ou corriger les fichiers en fonction de la gravité de l'alerte.

→Configurer les paramètres d'investigation automatisée pour les groupes d'appareils, en définissant le niveau d'automatisation sur 'Full' ou 'Semi'.

Pourquoi: Permet une correction automatique pour les menaces courantes. Les groupes d'appareils permettent différents niveaux d'automatisation pour les postes de travail par rapport aux serveurs critiques.

Référence↗

Bloquer immédiatement un hachage de fichier, une adresse IP ou une URL malveillant connu sur tous les points de terminaison.

→Créer un indicateur de compromission (IoC) avec une action "Bloquer et Corriger".

Pourquoi: Fournit un mécanisme de confinement rapide à l'échelle de l'organisation, plus rapide que d'attendre les mises à jour de signatures AV.

Renforcer les points de terminaison en bloquant les techniques d'attaque courantes (par exemple, Office créant des processus enfants).

→Déployer des règles de réduction de la surface d'attaque (ASR), en commençant en mode 'Audit' pour évaluer l'impact avant de passer en mode 'Block'.

Pourquoi: Les règles ASR sont un contrôle préventif clé. Le mode Audit est essentiel pour éviter toute perturbation des applications métier lors du déploiement.

Effectuer une investigation forensique approfondie ou une correction manuelle sur un point de terminaison en direct.

→Utiliser la fonctionnalité Live Response pour établir un shell distant et collecter des paquets forensiques.

Pourquoi: Fournit un accès direct et en temps réel à l'appareil pour exécuter des commandes, collecter des fichiers et exécuter des scripts forensiques.

Reconstruire les actions d'un attaquant sur un appareil compromis spécifique.

→Analyser la chronologie de l'appareil (Device Timeline).

Pourquoi: Fournit un journal d'événements détaillé et chronologique de toutes les activités de processus, de réseau, de fichier et de registre sur le point de terminaison.

Détecter le vol d'identifiants et les techniques de mouvement latéral comme Pass-the-Hash/Ticket.

→Déployer des capteurs Microsoft Defender for Identity sur tous les contrôleurs de domaine.

Pourquoi: Defender for Identity surveille directement le trafic d'authentification AD sur site, fournissant des alertes de haute fidélité pour les attaques basées sur l'identité.

Protéger les utilisateurs contre les malwares zero-day intégrés dans les pièces jointes des e-mails.

→Configurer une politique Safe Attachments avec l'option Dynamic Delivery.

Pourquoi: Fait exploser les pièces jointes dans un bac à sable pour vérifier les comportements malveillants tout en livrant le corps de l'e-mail immédiatement, équilibrant sécurité et productivité.

Rechercher et supprimer toutes les instances d'un e-mail de phishing des boîtes aux lettres des utilisateurs.

→Utiliser Threat Explorer (ou Advanced Hunting) pour rechercher l'e-mail et exécuter une action de suppression douce ou dure.

Pourquoi: Threat Explorer est un puissant outil de recherche et de correction pour purger les menaces actives du système de messagerie à l'échelle de l'organisation.

Empêcher l'exfiltration de données en bloquant les téléchargements de fichiers sensibles vers des appareils non gérés (non conformes).

→Configurer une politique de session Defender for Cloud Apps utilisant Conditional Access App Control.

Pourquoi: Agit comme un proxy inverse pour inspecter et contrôler l'activité des utilisateurs en temps réel au sein d'une session d'application cloud, appliquant les politiques d'accès aux données.

Contenir automatiquement une attaque active et généralisée comme un ransomware opéré par l'homme.

→Activer la rupture automatique d'attaque (Automatic Attack Disruption) dans Microsoft Defender XDR.

Pourquoi: Utilise des signaux inter-domaines (XDR) pour prendre des mesures décisives à la vitesse de la machine, comme désactiver les comptes d'utilisateurs compromis et isoler les appareils.

Rechercher proactivement les menaces dans toutes les données XDR (point de terminaison, e-mail, identité, applications cloud).

→Utiliser Advanced Hunting avec le langage de requête Kusto (KQL).

Pourquoi: Fournit une interface puissante basée sur des requêtes pour chasser à travers 30 jours de télémétrie brute, permettant la découverte de menaces qui échappent aux détections standards.

Comprendre rapidement l'étendue complète d'un incident complexe impliquant plusieurs alertes et entités.

→Analyser l'Attack Story ou le graphique d'investigation de l'incident.

Pourquoi: Consolide et visualise toute la chaîne d'attaque, montrant comment un attaquant est passé d'un point d'entrée initial à travers différents actifs.

Étendre les protections des charges de travail de Defender for Cloud aux serveurs sur site et multi-cloud.

→Intégrer les serveurs à l'aide d'Azure Arc, puis activer le plan Defender for Servers.

Pourquoi: Azure Arc agit comme un pont de plan de contrôle, projetant les ressources non-Azure dans Azure afin qu'elles puissent être gérées et sécurisées par Defender for Cloud.

Comprendre rapidement l'objectif et la potentielle malveillance d'un script complexe (par exemple, PowerShell).

→Coller le script dans Security Copilot et demander une analyse de sa fonction et de son risque.

Pourquoi: Utilise l'IA générative pour désobfusquer et expliquer le code, accélérant considérablement l'analyse des artefacts sans exécuter le script.

Contenir immédiatement un compte utilisateur compromis synchronisé depuis l'AD sur site.

→Désactiver le compte dans l'Active Directory sur site, puis déclencher une synchronisation AD Connect immédiate.

Pourquoi: Pour les identités synchronisées, l'AD sur site est la source d'autorité. La désactivation du compte à cet endroit est l'action de confinement la plus efficace.

Ingérer des renseignements sur les menaces externes d'un TIP en utilisant un protocole standard de l'industrie.

→Utiliser le connecteur de données "Threat Intelligence - TAXII" dans Sentinel.

Pourquoi: Se connecte aux serveurs TAXII 2.x pour importer automatiquement des indicateurs au format STIX, opérationnalisant les renseignements sur les menaces.

Référence↗

Corréler les indicateurs de menaces connus (adresses IP, domaines, hachages) avec toutes les sources de journaux ingérées.

→Ingérer les indicateurs dans la table ThreatIntelligenceIndicator et activer les règles d'analyse intégrées "TI map...".

Pourquoi: Ces règles associent efficacement les renseignements sur les menaces aux champs d'entité normalisés dans les journaux pour générer des alertes sur les activités malveillantes connues.

Utiliser une liste personnalisée d'indicateurs (par exemple, adresses IP de partenaires commerciaux, comptes d'employés terminés) pour l'alerte ou l'enrichissement.

→Créer une Watchlist et la joindre avec les données dans les requêtes KQL.

Pourquoi: Les Watchlists agissent comme un simple magasin clé-valeur pour les données personnalisées, facilement utilisées dans les requêtes pour la logique de détection ou pour réduire les faux positifs.

Une requête de chasse KQL réussie doit être sauvegardée et opérationnalisée pour une détection automatique.

→1. Sauvegarder la requête dans le volet Hunting. 2. Promouvoir la requête de chasse en une règle d'analyse planifiée.

Pourquoi: Formalise la transition de la découverte ad-hoc (chasse) vers la détection automatisée et reproductible (règle d'analyse).

Évaluer la couverture de détection et identifier les lacunes basées sur le cadre MITRE ATT&CK.

→Utiliser le volet MITRE ATT&CK dans Sentinel. Étiqueter les règles d'analyse avec les tactiques/techniques pertinentes.

Pourquoi: Fournit une carte thermique visuelle des capacités de détection mappées par rapport au cadre standard de l'industrie, guidant l'ingénierie de détection.

Conserver les résultats intéressants ou les preuves trouvées lors d'une chasse pour un suivi ultérieur.

→Créer un Hunting Bookmark à partir des résultats de la requête KQL.

Pourquoi: Capture la requête, les résultats et le contexte de l'entité, permettant à un analyste de sauvegarder les découvertes sans créer immédiatement un incident complet.