Microsoft Secure Score : quelles recommandations corriger en premier?

Secure Score est un indicateur, pas une note de sécurité absolue

Microsoft Secure Score mesure la proportion de recommandations prises en charge dans les produits connectés au locataire. Un score plus élevé indique que davantage d'actions recommandées sont détectées comme réalisées, mais il ne prouve pas qu'une organisation est sécurisée, conforme ou prête à répondre à un incident.

Le score ne couvre pas toutes les surfaces d'attaque. Il ne connaît pas nécessairement la criticité d'une application métier, la qualité d'une procédure de récupération, une exception mal documentée, un réseau local vulnérable ou le risque propre à un fournisseur. À l'inverse, une mesure compensatoire bien conçue peut réduire le risque sans correspondre exactement à la configuration Microsoft attendue.

La bonne utilisation de Secure Score est donc de transformer une longue liste en carnet de travail priorisé, avec propriétaire, preuve, pilote, échéance et décision de risque. L'objectif n'est pas de poursuivre 100 % à tout prix.

• Microsoft — Vue d'ensemble de Microsoft Secure Score ↗
• Microsoft — Évaluer la posture avec les actions d'amélioration ↗

Ce qui fait monter le score — et ce qui peut le fausser

Microsoft attribue généralement au plus dix points par action. Certaines sont binaires; d'autres donnent des points au prorata des utilisateurs, appareils ou objets protégés. Le dénominateur change lorsque Microsoft ajoute des recommandations, qu'un produit devient actif ou que les licences du locataire évoluent.

Suivez donc le score brut, le maximum, le pourcentage et surtout les contrôles réellement modifiés. Comparer seulement deux pourcentages peut masquer une amélioration concrète ou créer une fausse alerte.

Commencer par l'étendue réelle des données

Secure Score agrège des recommandations provenant notamment de Microsoft Entra ID, Exchange Online, SharePoint, Teams, Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, App governance et Purview. D'autres fournisseurs peuvent aussi alimenter l'expérience. Une recommandation absente n'est donc pas nécessairement un contrôle conforme; le produit, le connecteur ou la licence qui l'évalue peut simplement ne pas être actif.

Avant de prioriser, documentez les licences réellement détenues, les produits déployés, leur couverture et les sources qui alimentent le score. Utilisez la vue de score atteignable pour distinguer ce que l'organisation peut mettre en œuvre avec ses licences actuelles, tout en conservant séparément les lacunes qui exigeraient un investissement.

• Nombre d'utilisateurs licenciés et population réellement active.
• Appareils Windows, macOS, Linux, mobiles et serveurs couverts par les outils Microsoft.
• Domaines, boîtes, sites SharePoint, équipes et applications d'entreprise inclus.
• Solutions tierces qui remplacent réellement un contrôle Microsoft.
• Recommandations non applicables, dépendances techniques et contraintes réglementaires.
• Rôles autorisés à lire le score et à modifier les statuts dans Microsoft Defender XDR.

La matrice de priorité : risque avant points

Une action à deux points qui ferme un chemin d'administration exposé peut être prioritaire devant une action à dix points qui améliore un contrôle déjà largement compensé. Utilisez les champs fournis par Microsoft — menaces, niveau, coût d'implantation, impact utilisateur, rang et service — comme intrants, pas comme décision automatique.

Attribuez une priorité P1 à P4 avec une justification courte. Si deux actions ont le même risque, favorisez celle qui produit une réduction mesurable rapidement ou qui débloque plusieurs actions suivantes.

Ordre de travail recommandé pour une PME ou une organisation hybride

Cet ordre est un point de départ, pas une règle universelle. Une organisation déjà sous attaque, un hôpital avec appareils hérités, une usine avec disponibilité critique ou une entreprise fortement exposée par SharePoint peuvent changer complètement la séquence.

Traitez en premier les contrôles qui réduisent plusieurs scénarios simultanément. Par exemple, une authentification résistante à l'hameçonnage pour les administrateurs réduit davantage le risque qu'une hausse facile du score sur un paramètre périphérique.

Exemple de triage : ne pas trier seulement par points

Les points ne remplacent pas l'inventaire. Une action Graph critique peut ne pas être le meilleur moyen de gagner des points, mais elle peut fermer le chemin le plus dangereux du locataire. À l'inverse, un déploiement massif mal testé peut améliorer rapidement le tableau de bord tout en interrompant un processus métier.

Valider les licences, les prérequis et les coûts cachés

Le score atteignable aide à filtrer les actions selon les licences et les risques acceptés, mais une recommandation non licenciée peut quand même représenter une exposition réelle. Gardez un registre distinct des risques non financés afin qu'ils restent visibles lors du budget et de la prochaine revue.

• Distinguer la visibilité du portail de la licence nécessaire pour appliquer le contrôle à chaque utilisateur ou appareil.
• Confirmer les prérequis : enrôlement Intune, intégration Defender, connecteurs, journalisation, rôles et groupes pilotes.
• Évaluer le travail récurrent : traitement des alertes, exceptions, renouvellement des certificats et revues d'accès.
• Vérifier qu'une fonctionnalité d'essai n'a pas artificiellement modifié le maximum du score ou le plan d'action.
• Chiffrer les licences additionnelles séparément du risque; ne pas marquer une action comme résolue uniquement parce qu'elle est trop coûteuse.
• Documenter une mesure compensatoire lorsque la fonction Microsoft ne convient pas, avec propriétaire et preuve d'efficacité.

Déployer une recommandation comme un vrai changement

Chaque recommandation doit passer par une validation technique et métier. Lisez les prérequis, la méthode de détection, l'impact annoncé et le lien d'implémentation. Vérifiez ensuite la configuration réelle dans le produit source; le résumé Secure Score n'est pas toujours suffisant pour comprendre les exceptions ou la portée.

Pour les changements à impact élevé, utilisez un groupe pilote représentatif, un mode audit ou Report-only lorsqu'il existe, des critères de succès, une fenêtre d'observation et un retour arrière. Ne combinez pas plusieurs contrôles majeurs dans la même vague si cela empêche d'identifier la cause d'un incident.

• Définir la population, les exclusions temporaires et le propriétaire.
• Capturer l'état avant changement et le comportement attendu.
• Tester les utilisateurs standards, administrateurs, appareils non gérés et comptes de service pertinents.
• Mesurer les erreurs, tickets, événements de sécurité et contournements.
• Étendre par anneaux seulement lorsque les critères de sortie sont atteints.
• Mettre une date d'expiration à chaque exception.

Utiliser correctement les statuts

Microsoft accorde des points aux actions résolues par un tiers ou par une autre atténuation. Cette possibilité sert à refléter une posture réelle, pas à optimiser artificiellement le pourcentage. Une note sans preuve, portée ni test n'est pas une mesure compensatoire.

Le statut Risque accepté ne donne pas de points. C'est souvent la bonne décision lorsqu'un changement créerait un risque opérationnel supérieur, à condition que l'acceptation ait un propriétaire, une durée et une prochaine date de revue. Pour certaines recommandations de la catégorie Appareil, le portail renvoie plutôt vers la recommandation correspondante de Defender Vulnerability Management.

Exporter l'historique avec Microsoft Graph

Microsoft Graph expose les instantanés quotidiens Secure Score et les profils de contrôles. L'API v1.0 documente SecurityEvents.Read.All comme permission minimale en mode délégué ou applicatif. Utilisez une identité de collecte dédiée, protégez l'export et évitez SecurityEvents.ReadWrite.All si la collecte est uniquement en lecture.

Par défaut, le type secureScore conserve 90 jours de données. Un export périodique permet de garder une tendance plus longue et d'expliquer les variations de currentScore et maxScore. Le script suivant ne modifie aucun statut.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes 'SecurityEvents.Read.All' -NoWelcome

$scores = (Invoke-MgGraphRequest -Method GET -Uri `
  'https://graph.microsoft.com/v1.0/security/secureScores?$top=90').value
$latest = $scores | Sort-Object { [datetime]$_.createdDateTime } -Descending |
  Select-Object -First 1

[pscustomobject]@{
  Date = $latest.createdDateTime
  CurrentScore = $latest.currentScore
  MaxScore = $latest.maxScore
  Percent = if ($latest.maxScore) {
    [math]::Round(100 * $latest.currentScore / $latest.maxScore, 1)
  }
  LicensedUsers = $latest.licensedUserCount
  ActiveUsers = $latest.activeUserCount
}

$profiles = (Invoke-MgGraphRequest -Method GET -Uri `
  'https://graph.microsoft.com/v1.0/security/secureScoreControlProfiles').value

$controlReport = foreach ($control in $latest.controlScores) {
  $profile = $profiles | Where-Object id -eq $control.controlName |
    Select-Object -First 1
  [pscustomobject]@{
    Control = $control.controlName
    Title = $profile.title
    Category = $profile.controlCategory
    Service = $profile.service
    Score = $control.score
    MaxScore = $profile.maxScore
    Rank = $profile.rank
    Tier = $profile.tier
    ImplementationCost = $profile.implementationCost
    UserImpact = $profile.userImpact
    Threats = ($profile.threats -join '; ')
  }
}

$controlReport | Sort-Object Rank | Export-Csv `
  .\SecureScore-ControlReport.csv -NoTypeInformation -Encoding UTF8

• Microsoft Graph — Lister les instantanés Secure Score ↗
• Microsoft Graph — Type secureScore ↗
• Microsoft Graph — Profils de contrôles Secure Score ↗

Construire un rapport que la direction peut réellement utiliser

Présentez la tendance du score avec les changements du dénominateur et des licences, puis concentrez le rapport sur les cinq à dix risques les plus importants. Ajoutez les actions terminées, les incidents évités ou détectés, les exceptions qui expirent et les décisions attendues de la direction.

Évitez les objectifs comme « atteindre 90 % » sans contexte. Un objectif plus utile est « protéger tous les comptes privilégiés contre l'hameçonnage, sans verrouillage, avec deux comptes d'urgence testés », puis montrer l'effet correspondant sur Secure Score.

Checklist mensuelle de gouvernance

• Capturer currentScore, maxScore, pourcentage, licences et produits actifs.
• Expliquer chaque variation importante du numérateur ou du dénominateur.
• Réévaluer les nouvelles recommandations et celles dont Microsoft a changé le calcul.
• Vérifier les actions planifiées en retard et les exceptions arrivées à échéance.
• Confirmer par échantillonnage la portée réelle des contrôles marqués terminés.
• Revalider les protections tierces et mesures compensatoires.
• Relier les incidents récents, renseignements sur les menaces et changements métiers aux priorités.
• Présenter les décisions de risque et de budget, pas seulement un graphique de pourcentage.

Secure Score devient utile quand il mène à des décisions

Secure Score est excellent pour découvrir des écarts, suivre des tendances et lancer des conversations entre sécurité, exploitation et direction. Il devient dangereux lorsqu'il est traité comme une certification ou comme une liste à appliquer automatiquement.

Une évaluation Microsoft 365 complète valide les recommandations contre l'architecture, les licences, les journaux, les dépendances et les scénarios d'attaque réels. Elle permet de choisir les contrôles qui réduisent le plus le risque, même lorsqu'ils rapportent peu de points, et de documenter proprement ce qui doit attendre.

• Service — Audit de sécurité Microsoft 365 et Entra ID →
• Article — Passer Conditional Access de Report-only à Enforced →
• Article — Auditer les applications OAuth Microsoft 365 →