Retrouver la visibilité sur Microsoft 365 : pourquoi les connecteurs SIEM par défaut vous laissent dans l’angle mort

Par Mirko Peters · 2026-08-11

Bienvenue de retour sur le blog ! Si vous gérez les opérations de sécurité d’une organisation qui exploite Microsoft 365, vous éprouvez probablement un faux sentiment de sécurité. Vous avez cliqué sur « en…

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Bienvenue sur le blog ! Si vous gérez les opérations de sécurité d’une organisation qui utilise Microsoft 365, vous avez sans doute un faux sentiment de sécurité. Vous avez cliqué sur « activer » pour le connecteur M365 par défaut de votre SIEM, vérifié que les journaux arrivent, et coché la case de conformité. Mais êtes-vous réellement protégé ? La vérité, peu confortable, est que les connecteurs SIEM prêts à l’emploi laissent souvent de grands angles morts, en ignorant totalement les charges de travail cloud avancées où les attaquants modernes aiment opérer. Pour approfondir ce sujet essentiel, écoutez notre épisode de podcast associé, Send Critical Microsoft 365 Logs to Your SIEM, dans lequel nous détaillons ces lacunes.

Dans cet article, nous allons examiner en profondeur les raisons pour lesquelles vos configurations par défaut vous font défaut, où se cachent les angles morts et comment construire un pipeline d’ingestion résilient et économique, capable de faire remonter des détections à fort signal que vos analystes peuvent réellement exploiter.

Les angles morts de Microsoft 365 dans les principaux SIEM

Que vous utilisiez Microsoft Sentinel, Splunk ou QRadar, les modèles d’ingestion par défaut se concentrent généralement sur les connexions de base à Azure Active Directory et sur les journaux d’activité Office 365 élémentaires. Si cela couvre les fondamentaux, de nombreuses charges de travail critiques restent totalement exposées. Sur les principales plateformes SIEM, plusieurs angles morts majeurs apparaissent de façon récurrente :

• Exchange : les connecteurs par défaut manquent souvent les accès aux boîtes aux lettres par des utilisateurs non propriétaires, la création de règles et de transferts suspects, les activités SendAs ou SendOnBehalf, ainsi que les modifications soudaines des autorisations sur les boîtes aux lettres.
• SharePoint et OneDrive : vous voyez peut-être les téléchargements de fichiers, mais voyez-vous la création et l’utilisation de liens externes et anonymes, les repartages de fichiers ou les modifications des autorisations privilégiées sur les sites ?
• Teams : les attaquants adorent collaborer à découvert. Les configurations par défaut capturent rarement le partage externe via des canaux adossés à SharePoint, les suppressions et modifications de messages, les changements de stratégie de réunion ou le chargement latéral non autorisé d’applications.
• Power Platform : l’essor des environnements low-code/no-code apporte des risques cachés. Les pics de création de flux et d’applications, l’usage risqué de connecteurs (comme Outlook, Teams ou les connecteurs HTTP génériques) et les contournements des stratégies de Prévention de la perte de données (DLP) sont fréquemment omis.
• Étiquettes de confidentialité et DLP : l’application et la suppression d’étiquettes, les correspondances de stratégies et les remplacements manuels sont souvent totalement absents, sauf s’ils sont explicitement ciblés.
• Contexte Azure AD : les informations cruciales sur les connexions à risque, les résultats des accès conditionnels et les anomalies liées à l’appareil ou à la localisation géographique sont fréquemment absentes des requêtes standard.

Causes profondes : pourquoi vous manquez des événements critiques

Pourquoi ces flux de télémétrie critiques font-ils défaut ? Ce n’est presque jamais un hasard ; il s’agit plutôt du résultat de choix architecturaux et commerciaux, faits aussi bien par les fournisseurs de plateformes que par les acheteurs d’entreprise.

Premièrement, les verrous liés aux licences jouent un rôle majeur. L’audit avancé, la télémétrie Exchange granulaire et la journalisation riche des événements SharePoint sont fréquemment réservés aux licences de niveau supérieur, comme Microsoft 365 E5, ou aux modules complémentaires Advanced Audit. Si votre locataire se situe au niveau E3, ces événements ne sont tout simplement pas générés ni conservés.

Deuxièmement, les limites de portée des connecteurs restreignent la collecte de données. Les connecteurs standard récupèrent généralement les flux « OfficeActivity » de base, en ignorant les charges de travail avancées. Troisièmement, la limitation de débit des API et les délais de regroupement peuvent saturer les collecteurs natifs aux heures de pointe, entraînant la perte de journaux. Quatrièmement, les lacunes d’analyse signifient que, même si les blocs JSON bruts arrivent dans votre SIEM, les champs non mappés et les changements de schéma silencieux les rendent illisibles. Enfin, les contrôles de coûts mis en place par des équipes soucieuses du budget excluent discrètement des catégories bruyantes, sans en mesurer les implications en matière de sécurité.

Maîtriser les coûts sans perdre en visibilité

L’un des principaux freins à l’ingestion d’une visibilité « complète » sur Microsoft 365 concerne le coût. Ingérer chaque journal généré par un grand locataire M365 peut vider votre budget de stockage de sécurité. Cependant, vous n’avez pas à choisir entre la faillite et la cécité. Il faut filtrer intelligemment, et non réduire à l’aveugle.

Commencez par filtrer en amont. Configurez vos mécanismes d’ingestion pour ne conserver que les opérations à forte valeur de signal, comme New-InboxRule, Add-MailboxPermission, ou les événements de création et d’utilisation de liens anonymes. Dédupliquez et regroupez les événements bavards et peu utiles, comme les enregistrements de versions en arrière-plan dans SharePoint, avant qu’ils n’atteignent votre SIEM.

Mettez en place des stratégies de stockage à plusieurs niveaux. Conservez le stockage « chaud » sur une durée courte (30 à 60 jours) pour les investigations en cours, et redirigez le stockage froid ou d’archive vers des magasins d’objets moins coûteux afin de respecter les durées de conservation réglementaires. Par ailleurs, modélisez vos volumes avant d’activer de nouveaux flux. Estimez les gigaoctets par jour et par source, puis doublez ces estimations pour tenir compte des pics d’activité, des audits trimestriels ou des périodes de découverte de preuves dans le cadre de litiges.

Concevoir un pipeline d’ingestion résilient

S’appuyer sur des connecteurs fragiles qui interrogent directement les sources est une recette assurée pour manquer des alertes pendant les incidents de sécurité critiques. Concevez plutôt un pipeline résilient, capable de gérer la limitation de débit. Un modèle éprouvé ressemble à ceci :

• Source : collectez les données du journal d’audit unifié de Microsoft 365, de l’audit avancé, des connexions et journaux de risque Azure AD, de Microsoft Information Protection (MIP), des alertes DLP et des alertes de sécurité Microsoft Defender.
• Transport : acheminez les données de l’API Graph ou de l’API de gestion vers Azure Event Hubs (qui joue le rôle de tampon et de mécanisme de rejeu) avant de les transmettre à votre SIEM.
• Traitement : normalisez et enrichissez les données dès la zone d’atterrissage, en ajoutant le contexte utilisateur, les indicateurs de service, les désignations VIP, l’état des appareils et les données géographiques.
• Gouvernance : mettez en place des contrôles quotidiens d’exhaustivité, des gestionnaires de reprise pour les limitations de débit (erreurs 429), une surveillance des changements de schéma et des alertes sur les files d’attente de messages morts.

Normalisation et enrichissement pour des données prêtes à l’analyse

Les journaux bruts de Microsoft 365 sont réputés désordonnés, avec des objets JSON imbriqués et des conventions de nommage de champs incohérentes d’une charge de travail à l’autre. Si vous remettez des données brutes à un analyste de niveau 1, il passera la moitié de son poste à décoder des charges utiles au lieu de trier les menaces.

Aplatissez les champs clés au moment de l’ingestion : Actor, Target, Action, ResourcePath, LinkType (anonyme, organisation ou personnes spécifiques), ExternalRecipient et LabelName. Faites correspondre ces champs à un schéma unifié, comme le Azure Monitor Common Security Incident Model (ASIM) ou l’Elastic Common Schema (ECS), afin que votre ingénierie de détection couvre sans rupture l’ensemble des charges de travail. Enfin, enrichissez ces événements avec les données RH (rôle, type de contrat, service), les listes VIP, les listes d’autorisation de partenaires, l’état de conformité des appareils et les classifications de sensibilité.

Détections à forte valeur de signal à déployer dès maintenant

Une fois votre pipeline opérationnel et vos données normalisées, vous pouvez déployer des détections à forte valeur de signal capables d’identifier des comportements d’attaquants sophistiqués. Voici huit détections fondamentales à mettre en place immédiatement :

• Exfiltration par boîte aux lettres : détectez la création d’une règle de boîte de réception qui transfère vers l’extérieur ou déplace des messages vers RSS ou les courriers indésirables, lorsqu’elle survient dans l’heure qui suit une connexion depuis une nouvelle localisation géographique ou un appareil non reconnu.
• Accès discret : signalez un accès à la boîte aux lettres d’un compte VIP par un utilisateur qui n’en est pas le propriétaire, lorsqu’il est accompagné d’un événement Add-MailboxPermission dans les 24 heures précédentes.
• Fuite SharePoint : alertez sur les liens de partage anonymes ou « personnes spécifiques » créés sur des fichiers étiquetés Confidentiel ou Restreint.
• Abus de lien : détectez un volume élevé de téléchargements externes dans une fenêtre de 15 minutes, provenant d’un lien de partage récemment créé et d’une nouvelle adresse IP ou d’un nouvel ASN.
• Rebond via Teams : repérez les cas où un fichier est partagé à l’extérieur et où le même utilisateur ajoute un invité externe à l’équipe dans les deux heures.
• Abus de Power Automate : signalez une hausse soudaine d’au moins trois créations de flux par jour, effectuées par un compte non développeur, et utilisant spécifiquement les connecteurs HTTP ou Outlook.
• Extension progressive des privilèges : suivez les ajouts et suppressions répétés de rôles de membre ou d’administrateur sur le même espace de travail ou site sensible, dans une fenêtre de 24 heures.
• Données obsolètes : détectez les cas où les jeux de données de contenus de direction ou de finance ne parviennent pas à s’actualiser pendant deux cycles ou plus, afin d’éviter que la direction prenne des décisions sur la base de données périmées.

Votre plan de mise en œuvre sur 30 jours pour combler l’écart

Corriger votre niveau de visibilité sur Microsoft 365 ne demande pas forcément une année. Vous pouvez combler systématiquement vos lacunes de visibilité en seulement 30 jours :

• Semaine 1 : activez l’audit avancé là où c’est nécessaire, inventoriez vos connecteurs SIEM actuels et cartographiez les catégories d’événements manquantes.
• Semaine 2 : Mettez en place votre pipeline Event Hub. Acheminez les Unified Audit Logs, Advanced Audit, la télémétrie Azure AD et Defender, puis implémentez vos filtres en amont.
• Semaine 3 : Normalisez et enrichissez vos flux de données, réimportez les journaux critiques des 30 derniers jours, et déployez les sept détections à fort signal listées ci-dessus, avec des fenêtres de suppression appropriées.
• Semaine 4 : Optimisez vos coûts en supprimant le bruit restant et en ajustant les niveaux de rétention. Ajoutez des moniteurs d’exhaustivité et organisez un exercice de table purple team pour tester les règles de boîte aux lettres, le partage externe et les pics de flux.

Les KPI de direction pour prouver que la démarche a fonctionné

Lorsque la direction vous demande si le budget de sécurité consacré aux améliorations du pipeline en valait la peine, vous avez besoin de métriques pour démontrer votre réussite. Suivez ces KPI de direction :

• Couverture : pourcentage des familles d’événements M365 ciblées ingérées et analysées avec succès (objectif de 95 % ou plus).
• Rapidité : délai moyen de prise en charge (MTTA) et délai moyen de résolution (MTTR) des incidents liés à M365 (tendance à la baisse).
• Bruit : ratio alertes/vrais positifs (tendance à la hausse de la qualité du signal).
• Coût : coût par gigaoctet ingéré (tendance à la baisse d’environ 40 % grâce au filtrage en amont).
• Fiabilité : nombre de jours avec des interruptions d’ingestion (objectif : zéro) et délais de mise à jour des analyseurs (sept jours maximum après une modification de schéma par Microsoft).

Les pièges courants et comment les éviter

Même les plans les mieux préparés peuvent rencontrer des obstacles. Méfiez-vous de ces écueils fréquents :

Les équipes affirment souvent « On l’a activé », alors que les journaux n’apparaissent jamais, parce que les licences Advanced Audit ou les bases de référence de l’audit des boîtes aux lettres n’ont jamais été correctement vérifiées. Autre problème courant : les règles du SIEM restent totalement silencieuses pendant les attaques, car elles évaluent les événements isolément au lieu de corréler la création de règles, les changements de localisation géographique et le partage externe.

Les explosions de facturation surviennent lorsque les filtres préalables sont omis. Filtrez toujours en amont les opérations bruyantes et excluez les événements de synchronisation en arrière-plan. La dégradation des analyseurs est un autre fléau silencieux : mettez en place une routine mensuelle de comparaison des schémas et exécutez des tests unitaires sur des charges utiles d’exemple. Enfin, la fatigue des analystes s’installe rapidement si les alertes manquent de contexte. Veillez toujours à ce que vos alertes indiquent qui, quoi, où et les étiquettes de confidentialité, avec des liens directs vers le Centre de conformité Microsoft pour les analyses approfondies.

Conclusion : ne vous fiez plus à la conformité pour la protection

En résumé, les connecteurs SIEM par défaut vous maintiennent en conformité, mais ils ne vous protègent pas. En récupérant les bons journaux Microsoft 365, en les normalisant dans un schéma unifié, en les enrichissant avec le contexte métier indispensable et en chassant les menaces grâce à des détections ajustées au comportement réel des attaquants, vous pouvez éliminer totalement vos angles morts. C’est ainsi que votre SIEM cesse de passer à côté de l’histoire et commence à l’écrire. Pour approfondir cette stratégie, écoutez l’épisode complet sur « Send Critical Microsoft 365 Logs to Your SIEM » et commencez dès aujourd’hui à combler vos lacunes de visibilité !