M365-Expert : LLM sécurité et hardening Microsoft 365

M365-Expert est un assistant LLM mis à disposition sur le portfolio huggingface de Ayi Nedjimi pour accompagner les administrateurs et RSSI dans le hardening de Microsoft 365. Le modèle a été fine-tuné sur un corpus combinant le CIS Benchmark Microsoft 365 dans sa version la plus récente, la documentation Microsoft Defender for Office 365 et Defender for Cloud Apps, les guides Purview pour la classification et la prévention des pertes de données, la documentation Entra ID anciennement Azure AD avec une focale sur Conditional Access et Privileged Identity Management, ainsi que les recommandations ANSSI applicables aux environnements cloud français. L'objectif est de fournir un copilote capable de diagnostiquer une configuration tenant, de prioriser les actions de hardening, de proposer des politiques Conditional Access concrètes, d'aider à investiguer un incident MailFlow, ou de produire la documentation d'un projet Zero Trust dans Microsoft 365. Tout est calibré pour rester déployable en local et préserver la confidentialité des tenants traités.

Pourquoi un LLM dédié à Microsoft 365

Microsoft 365 est devenu le cœur du SI bureautique de l'écrasante majorité des entreprises. Sa surface d'attaque est colossale : Exchange Online, SharePoint, OneDrive, Teams, Power Platform, Entra ID, Microsoft Defender, Purview, Intune. Chaque service expose ses propres réglages, ses propres consoles, ses propres journaux. Les attaquants exploitent les failles de configuration et les autorisations OAuth permissives plus que des vulnérabilités logicielles classiques. La consoles d'administration changent régulièrement, les noms des fonctionnalités évoluent et les bonnes pratiques se déplacent.

Un LLM généraliste fournit des réponses approximatives sur Microsoft 365, mélangeant l'ancien Azure AD avec le nouveau Entra ID, confondant DLP Purview avec les anciennes règles MailFlow, ou suggérant des paramètres déconseillés. M365-Expert a été fine-tuné spécifiquement pour éliminer ces confusions. Il connaît la nomenclature à jour, sait référencer les contrôles CIS par leur numéro et anticipe les pièges fréquemment relevés lors d'audits.

À quoi sert M365-Expert

Le modèle s'adresse à quatre profils. L'administrateur Microsoft 365 qui veut un copilote pour configurer ou auditer un tenant. Le RSSI qui veut comprendre rapidement la posture de sécurité de son environnement cloud collaboratif. L'auditeur ou consultant qui réalise des missions d'évaluation Microsoft 365. L'équipe SOC qui investigue un incident impliquant Exchange, SharePoint ou Entra ID.

Concrètement, le modèle peut générer une checklist de hardening, expliquer un contrôle CIS spécifique, proposer une politique Conditional Access pour un cas d'usage donné, suggérer une stratégie DLP Purview adaptée à un secteur, analyser un message d'erreur PowerShell Exchange Online, expliquer le fonctionnement de la cascade d'autorisations Microsoft Graph et préparer une réponse à un incident BEC ou phishing avancé.

Méthodologie d'entraînement

Le corpus repose sur quatre piliers. Premier pilier, le CIS Microsoft 365 Foundations Benchmark, dans sa version la plus récente avec les niveaux L1 et L2. Chaque contrôle a été reformulé en plusieurs paires question-réponse couvrant la finalité, la commande PowerShell ou la procédure portail, l'impact opérationnel et les pièges de mise en œuvre.

Deuxième pilier, la documentation Microsoft officielle des services suivants : Defender for Office 365, Defender for Cloud Apps, Defender for Identity, Purview, Entra ID dont Conditional Access et PIM, Intune. Le corpus a été enrichi par les advisories et bulletins sécurité émis par le MSRC.

Troisième pilier, les recommandations ANSSI applicables au cloud collaboratif, en particulier les guides hygiène et configuration sécurisée. La perspective francophone et souveraine est essentielle pour les organisations soumises à des exigences SecNumCloud ou voulant s'aligner sur la doctrine nationale.

Quatrième pilier, un corpus d'incidents M365 anonymisés couvrant Business Email Compromise, exfiltration via OneDrive, élévation OAuth, abus PowerShell Graph, prise de contrôle d'Entra Connect Sync. Cette couche apporte un ancrage opérationnel au modèle.

Le fine-tuning combine SFT et DPO avec une évaluation interne sur 200 questions auditées par trois experts Microsoft 365. Le modèle atteint 84 pour cent de réponses correctes ou utiles, contre 65 pour cent pour un modèle généraliste 7B francophone.

Cas d'usage concrets

Un MSSP utilise M365-Expert pour pré-instruire les rapports d'audit M365 livrés à ses clients. Le consultant collecte la configuration via un script PowerShell générique, transmet la sortie au modèle accompagné d'une question structurée et obtient une analyse priorisée par criticité. Le rapport final est révisé manuellement.

Une ETI met le modèle à disposition de ses administrateurs M365 internes via un chatbot Slack ou Teams self-hosted. Les administrateurs posent leurs questions techniques sans devoir attendre la disponibilité de l'expert interne. Le ticket arrive enrichi de premières pistes lorsqu'il monte au niveau 2.

Un RSSI prépare un plan Zero Trust pour son tenant. Le modèle propose une feuille de route articulée autour de quatre vagues : identité Conditional Access et PIM, devices Intune Compliance et Defender for Endpoint, applications OAuth governance et Defender for Cloud Apps, données Purview classification, DLP et chiffrement.

Une équipe SOC investigue un incident BEC. Le modèle aide à reconstituer la chronologie en lisant les journaux Unified Audit Log filtrés, suggère les requêtes KQL pour Sentinel et propose des règles Conditional Access ajustées pour bloquer la récidive.

Un développeur Power Platform vérifie la sécurité d'une application Power Apps avant déploiement. Le modèle relit les permissions des connecteurs, signale les risques de partage trop large et propose des bonnes pratiques DLP Power Platform.

Installation rapide

Le modèle est livré aux formats SafeTensors et GGUF. Un wrapper PowerShell d'aide est fourni pour faciliter l'usage par les administrateurs Windows.

ollama pull m365-expert:q4
ollama run m365-expert:q4 "Genere une politique Conditional Access pour bloquer logins non MFA hors France."

# Couplage avec extraction PowerShell
Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"
Get-MgIdentityConditionalAccessPolicy | Out-File ca.json
# Puis pousser ca.json en contexte du modele pour analyse

Pour les organisations qui veulent un assistant intégré, une recette LangChain est fournie : elle combine M365-Expert avec un connecteur Microsoft Graph pour lire à la demande les configurations en lecture seule et produire des recommandations contextualisées sur le tenant réel. L'accès Graph doit rester en lecture seule et limité aux scopes minimaux.

Articulation avec Microsoft Graph et automatisation

Le modèle est conçu pour s'articuler avec une couche d'extraction Microsoft Graph qui collecte la configuration réelle du tenant en lecture seule. Cette articulation permet d'aller au-delà des recommandations génériques : l'analyste fournit en contexte le JSON résultant de l'extraction Graph et le modèle produit un diagnostic adapté à la configuration effective. Les scripts d'extraction PowerShell sont documentés dans le dépôt. Ils couvrent les politiques Conditional Access, les paramètres Defender for Office 365, les règles Exchange Online, les paramètres SharePoint et OneDrive, les autorisations Power Platform, les paramètres Intune Compliance et l'inventaire des applications avec leurs permissions OAuth.

Pour les organisations matures, une boucle d'automatisation hebdomadaire est envisageable : un job planifié extrait la configuration, la soumet au modèle, génère un rapport de drift par rapport à la baseline souhaitée et alerte le RSSI sur les écarts critiques. Cette approche industrialise le monitoring de configuration sans dépendance à un produit commercial dédié de type Microsoft Secure Score Premium.

Couverture des contrôles CIS Microsoft 365

Le modèle couvre les sept sections principales du benchmark : Account et Authentication Policies, Application Permissions, Data Management, Email Security et Exchange Online, Auditing Policies, Storage Policies, Mobile Device Management. Chaque contrôle est associé à sa commande de vérification PowerShell ou Graph, à sa procédure portail, à son score CIS niveau et à un commentaire de mise en œuvre.

Les contrôles les plus fréquemment manqués lors d'audits sont identifiés et expliqués en priorité : désactivation de l'authentification basique Exchange, application stricte de Conditional Access aux comptes Service principaux, restriction des consentements utilisateurs OAuth, configuration anti-phishing Defender, rétention Purview adaptée au secteur. Le modèle propose des plans d'action concrets pour chacun.

Templates Conditional Access et stratégies Defender

La bibliothèque de prompts livrée avec le modèle inclut une vingtaine de patrons Conditional Access prêts à adapter : blocage des connexions hors pays autorisés, exigence MFA pour les rôles privilégiés, restriction du téléchargement depuis OneDrive sur appareil non conforme, exigence d'appareil hybride joint pour les applications sensibles, blocage des protocoles d'authentification hérités, exigence de session courte pour les administrateurs. Chaque patron est documenté avec les utilisateurs ciblés, les conditions, les contrôles d'octroi et les pièges de mise en œuvre.

Côté Defender for Office 365, le modèle propose des configurations baseline pour les politiques anti-phishing, anti-spam, anti-malware, Safe Links et Safe Attachments. Pour Defender for Cloud Apps, il aide à structurer la session policy pour les applications SaaS critiques. Pour Purview, il oriente vers les labels de sensibilité et les politiques DLP adaptées aux secteurs régulés santé, finance, juridique. L'objectif est de fournir une base solide que l'organisation affine ensuite selon son contexte, plutôt que de partir de la page blanche que présente la console à l'ouverture.

Limites et garde-fous

M365-Expert n'est pas un produit Microsoft. Il n'a pas d'accès aux préversions privées ni aux roadmaps internes. Les recommandations qu'il fournit s'appuient sur la documentation publique disponible à la date de coupure du corpus. Les évolutions très récentes des produits, en particulier dans Defender et Copilot for Security, peuvent ne pas être reflétées. L'utilisateur est invité à recouper systématiquement avec la documentation officielle pour les décisions critiques.

Le modèle a été aligné pour refuser de produire des scripts offensifs ou des techniques d'abus contre des tenants tiers. Il assiste la défense uniquement. Les organisations qui pratiquent du red team M365 dans un cadre contractuel maîtrisé utiliseront d'autres outils dédiés.

Roadmap

Quatre axes pour la suite. Premier axe, intégration native des contrôles Copilot for Microsoft 365 et de leurs implications data governance. Deuxième axe, extension à Azure Workloads pour les organisations qui hébergent aussi des services Azure au-delà de M365. Troisième axe, support du benchmark CIS Azure et de la matrice de correspondance avec NIS 2. Quatrième axe, intégration plus fine avec Sentinel pour faciliter les rotations entre conseil de configuration et analyse d'incident.

FAQ

Le modèle a-t-il un accès direct à mon tenant ?

Non par défaut. Le modèle traite uniquement les données que vous lui fournissez en prompt. Si vous configurez le wrapper LangChain Graph, l'accès passe par votre propre application enregistrée et reste totalement sous votre contrôle.

Quelle est la version du CIS Benchmark utilisée ?

Le corpus s'appuie sur la version la plus récente publiée par le CIS au moment de la coupure du dataset. La version exacte est précisée dans la model card. Le modèle sait néanmoins répondre sur les versions antérieures quand l'utilisateur le précise.

Le modèle peut-il auditer Defender for Endpoint ou Defender for Cloud ?

Defender for Endpoint et Defender for Office 365 sont couverts. Defender for Cloud, qui concerne Azure plus largement, est partiellement couvert et fait partie de la roadmap. Les utilisateurs Azure intensifs sont invités à coupler M365-Expert avec un outil dédié Azure.

Le modèle peut-il aider à investiguer un BEC ?

Oui. Le modèle propose les requêtes Unified Audit Log et KQL Sentinel pertinentes, aide à reconstituer la timeline et suggère les actions de containment et de remediation. L'investigation finale doit rester pilotée par l'équipe SOC, surtout si l'incident a un impact business significatif.

Pour aller plus loin

La fiche modèle complète, les exemples et la model card sont accessibles via le portfolio /huggingface du compte Ayi Nedjimi. Pour approfondir Microsoft 365, consultez le guide d'audit de sécurité Microsoft 365, l'article pratiques de sécurité Microsoft 365 2025, l'analyse détection d'attaques Microsoft 365 et Azure AD et l'étude implémentation Zero Trust Microsoft 365.