Checklist Sécurité ANC

📊 Checklist Sécurité Microsoft 365

Sécurisation M365 : Entra ID, Conditional Access, Exchange Online, SharePoint, Teams, Intune, DLP et Purview.

74 sections 297 contrôles 56823 mots PDF + Excel

La plus complète de nos checklists avec 297 contrôles sur 74 sections : MFA et Conditional Access, Exchange Online (anti-phishing, anti-malware), SharePoint et OneDrive, Microsoft Teams, Intune/MDM, DLP, Microsoft Purview et supervision du tenant. Indispensable pour tout environnement M365.

Télécharger le PDF Télécharger le Excel

PDF Excel

📑 Table des matières

CHECKLIST SÉCURITÉ MICROSOFT 365

AYI NEDJIMI CONSULTANTS (ANC)

Référentiel : CIS Microsoft 365 Foundations Benchmark v6.0.1 + CISA SCuBA M365 Baseline v1.7 + ANSSI + BOD 18-01 / BOD 25-01

Document : CHECKLIST-M365-ANC Version : 4.6 Date : 2026-03-26 Classification : CONFIDENTIEL Auteur : AYI NEDJIMI CONSULTANTS

LÉGENDE

Symbole	Signification
✅	Conforme
❌	Non conforme
⚠️	Partiellement conforme
N/A	Non applicable
🔴	Critique
🟠	Élevé
🟡	Moyen
🟢	Faible

MODE DÉCOUVERTE RAPIDE — 15 Questions Clés (< 30 min)

Objectif : Identifier les risques critiques en moins de 30 minutes, avant l’audit complet. Scoring : OUI = 0 pt | NON = 1 pt | Seuil d’alerte : ≥ 5 réponses NON Résultat : Un score élevé indique des lacunes critiques prioritaires à traiter immédiatement.

#	Question clé	Contrôle	Risque si NON	Statut
Q1	MFA est-il activé pour TOUS les comptes administrateurs ?	1.1.1	🔴 Critique — compromission totale du tenant	☐ OUI ☐ NON
Q2	L’authentification héritée (Legacy Auth) est-elle bloquée par Conditional Access ?	1.3.1	🔴 Critique — bypass MFA complet	☐ OUI ☐ NON
Q3	Le nombre de Global Admins est-il ≤ 4 à 8 et ces comptes sont-ils Cloud-Only sans licence Exchange/Teams (uniquement licence admin P2) ?	1.8.2	🔴 Critique — surface d’attaque élevée	☐ OUI ☐ NON
Q4	PIM est-il activé pour tous les rôles privilégiés (aucune assignation permanente) ?	1.8.1	🔴 Critique — droits permanents = risque persistant	☐ OUI ☐ NON
Q5	Defender for Office 365 : Safe Links et Safe Attachments sont-ils activés ?	2.3.1 / 2.3.2	🔴 Critique — phishing et malware non filtrés	☐ OUI ☐ NON
Q6	Des politiques DLP sont-elles actives sur Exchange, SharePoint et Teams ?	6.1.3	🟠 Élevé — fuite de données non détectée	☐ OUI ☐ NON
Q7	L’Audit Log unifié est-il activé avec rétention ≥ 1 an ?	6.1.1	🟠 Élevé — investigation forensic impossible	☐ OUI ☐ NON
Q8	Le partage externe SharePoint est-il ≤ “Invités existants uniquement” ?	5.1.1	🔴 Critique — exfiltration de données	☐ OUI ☐ NON
Q9	DMARC est-il configuré en p=reject (pas p=none) pour tous les domaines ?	2.2.4	🔴 Critique — usurpation d’identité email	☐ OUI ☐ NON
Q10	Les étiquettes de sensibilité sont-elles publiées pour tous les utilisateurs ?	6.1.4	🟠 Élevé — pas de classification des données	☐ OUI ☐ NON
Q11	Les Service Principals / App Registrations inactifs > 90j ont-ils été examinés ?	1.5c.6	🟠 Élevé — identités zombies exploitables	☐ OUI ☐ NON
Q12	Le Secure Score est-il ≥ 50% de l’objectif défini et suivi mensuellement ?	8.1.1	🟠 Élevé — posture de sécurité dégradée	☐ OUI ☐ NON
Q13	Le signalement de sécurité Teams est-il activé pour les utilisateurs ?	4.2.6	🟡 Moyen — phishing Teams non signalé	☐ OUI ☐ NON
Q14	Le SSPR est-il configuré avec ≥ 2 méthodes d’authentification sécurisées ?	1.2b.5	🟠 Élevé — réinitialisation de mot de passe non sécurisée	☐ OUI ☐ NON
Q15	Les règles de redirection automatique de boîte mail vers l’extérieur sont-elles bloquées ?	3.1.1 / 3.2.11	🔴 Critique — exfiltration silencieuse des emails	☐ OUI ☐ NON

Interprétation du score de découverte rapide

Nb NON	Niveau de risque	Action recommandée
0–1	🟢 Faible	Audit complet de confirmation — posture mature
2–4	🟡 Moyen	Audit complet avec focus sur les NON identifiés
5–8	🟠 Élevé	Plan de remédiation immédiat pour les questions critiques
≥ 9	🔴 Critique	Intervention d’urgence requise — sécurité fondamentale absente

INFORMATIONS CLIENT

Champ	Valeur
Organisation
Tenant ID
Domaine principal
Date d’audit
Auditeur
Version M365

SECTION 1 — GESTION DES IDENTITÉS ET DES ACCÈS

1.1 Authentification Multi-Facteurs (MFA)

1.1.1 — Activer MFA pour tous les comptes Administrateurs

Niveau : 🔴 Critique Référence CIS : CIS Control 5.3 MITRE ATT&CK : T1078.004 (Valid Accounts: Cloud) · T1556.006 (Modify Authentication: MFA) · T1621 (MFA Request Generation)

Description : L’authentification multi-facteurs (MFA) est la mesure de sécurité la plus efficace pour protéger les comptes administrateurs contre les compromissions. Sans MFA, un mot de passe volé suffit à compromettre l’intégralité du tenant M365. Les comptes administrateurs disposant de privilèges élevés sont les cibles prioritaires des attaquants.

Vérification :

Accéder à : Entra ID > Protection > Authentification multifacteur > Paramètres
Ou via PowerShell :

Get-MgUser -Filter "assignedLicenses/$count ne 0" | Get-MgUserAuthenticationMethod

Vérifier que 100% des comptes avec rôles admin ont MFA activé
Vérifier dans les rapports de connexion qu’aucune connexion admin ne s’est faite sans MFA

Remédiation :

Activer les Paramètres de sécurité par défaut (Security Defaults) si l’organisation n’utilise pas l’Accès Conditionnel
Ou créer une Politique d’Accès Conditionnel : Utilisateurs → Tous les utilisateurs avec rôles admin → Accorder → Exiger MFA
Enrôler tous les administrateurs dans MFA via : https://aka.ms/mfasetup
Méthodes recommandées par ordre de préférence : Application Authenticator > Clé FIDO2 > SMS (déconseillé)

Impact si non conforme : Compromission totale du tenant en cas de phishing ou fuite de mot de passe administrateur.

1.1.2 — Activer MFA pour tous les utilisateurs

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.3 MITRE ATT&CK : T1078 (Valid Accounts) · T1586.003 (Compromise Accounts: Cloud) · T1199 (Trusted Relationship)

Description : Tous les utilisateurs, pas uniquement les administrateurs, doivent utiliser le MFA. Un compte utilisateur standard compromis peut servir de pivot pour des attaques de latéralisation, l’exfiltration de données ou des attaques BEC (Business Email Compromise).

Vérification :

Entra ID > Protection > Authentification multifacteur > Rapport d’activité
Vérifier le pourcentage d’utilisateurs enrôlés dans MFA
PowerShell :

Get-MgReportAuthenticationMethodUserRegistrationDetail | Where-Object {$_.IsMfaRegistered -eq $false}

Remédiation :

Déployer une Politique d’Accès Conditionnel ciblant tous les utilisateurs
Utiliser la fonctionnalité Campagne d’enrôlement MFA dans Entra ID pour guider les utilisateurs
Définir un délai de grâce raisonnable (14 jours maximum)
Former les utilisateurs via Microsoft Learn ou sessions internes

1.1.3 — Désactiver MFA via SMS comme méthode principale

Niveau : 🟡 Moyen Référence CIS : CIS Control 5.3

Description : Le SMS est vulnérable aux attaques de SIM swapping et d’interception SS7. Bien qu’il soit préférable à l’absence de MFA, il ne doit pas être la méthode principale recommandée par l’organisation.

Vérification :

Entra ID > Protection > Méthodes d’authentification > Stratégies
Vérifier si le SMS est activé et quelle est sa priorité

Remédiation :

Dans Entra ID > Méthodes d’authentification, favoriser Microsoft Authenticator avec Number Matching et Additional Context
Désactiver ou déprioriser le SMS pour les comptes sensibles
Activer les clés FIDO2 pour les environnements à haute sécurité
Activer la résistance au phishing : Paramètres > Number Matching = Activé

1.1.4 — Exiger une MFA Résistante au Phishing pour les Rôles Privilégiés

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.3.6v1 Référence CIS : CIS Control 5.3

Description : Les méthodes MFA classiques (notification push, TOTP) restent vulnérables aux attaques de type AiTM (Adversary-in-the-Middle) et phishing en temps réel (Evilginx2, Modlishka). Les méthodes résistantes au phishing — FIDO2/clés de sécurité physiques (YubiKey, etc.), Windows Hello for Business, ou certificats client — sont liées cryptographiquement au domaine légitime et ne peuvent pas être relayées par un proxy d’attaque.

Vérification :

Entra ID > Protection > Accès Conditionnel > Vérifier l’existence d’une politique exigeant une MFA résistante au phishing pour les rôles admin
PowerShell :

Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.DisplayName -like "*phishing*" -or $_.DisplayName -like "*FIDO*"} | Select-Object DisplayName, State

Remédiation :

Créer une politique CA : Utilisateurs → Rôles d’annuaire (sélectionner tous les rôles admin)
Accorder → Exiger la force d’authentification → Créer une force d’authentification personnalisée avec : FIDO2 Security Key, Windows Hello for Business, Certificate-based Authentication (hardware)
Enrôler tous les administrateurs dans au moins une méthode résistante au phishing
Pour les environnements très sensibles : étendre aux utilisateurs à accès privilégié (RH, Finance, Direction)

Impact si non conforme : Les campagnes AiTM (type EvilProxy, Evilginx) peuvent intercepter les tokens MFA push en temps réel.

1.1.5 — Désactiver SMS, Appel Vocal et Email OTP comme méthodes MFA

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.3.5v2 Référence : NIST SP 800-63B

Description : Le SMS, l’appel vocal et l’Email OTP sont explicitement déconseillés par le NIST SP 800-63B pour l’authentification des systèmes gouvernementaux et d’entreprise. Ces méthodes sont vulnérables au SIM swapping, à l’interception SS7, au vishing, et au forwarding de messages. La CISA impose leur désactivation dans les organisations fédérales américaines (BOD 25-01).

Vérification :

Entra ID > Protection > Méthodes d’authentification > Stratégies
Vérifier le statut de “SMS”, “Voice Call”, “Email OTP”
PowerShell :

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId "Sms" | Select-Object State
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId "Voice" | Select-Object State

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Stratégies
Désactiver “SMS” (état : Désactivé)
Désactiver “Voice Call” (état : Désactivé)
Désactiver “Email OTP” (état : Désactivé)
Avant désactivation : s’assurer que 100% des utilisateurs ont une méthode alternative (Authenticator App ou FIDO2)
Utiliser la fonctionnalité de campagne d’enrôlement MFA pour migrer les utilisateurs

1.1.6 — Activer Number Matching pour Microsoft Authenticator

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.3

Description : Le Number Matching prévient les attaques de type MFA Fatigue (MFA Bombing) où un attaquant envoie des notifications push répétées jusqu’à ce que l’utilisateur accepte par erreur ou fatigue. Avec Number Matching, l’utilisateur doit saisir un code affiché sur l’écran de connexion.

Vérification :

Entra ID > Protection > Méthodes d’authentification > Microsoft Authenticator > Configurer
Vérifier que “Correspondance de nombre” = Activé

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Microsoft Authenticator
Cliquer sur “Configurer”
Activer “Correspondance de nombre” pour tous les utilisateurs
Activer également “Contexte supplémentaire” (affiche l’application et la localisation)

1.1.7 — Finaliser la migration des méthodes d’authentification (Authentication Methods Migration)

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.3.4v1

Description : Microsoft dispose de deux systèmes de gestion des méthodes d’authentification : l’ancien (hérité, dans les paramètres MFA legacy) et le nouveau (Authentication Methods Policy dans Entra ID). Tant que la migration n’est pas complète, des politiques contradictoires peuvent coexister, créant des lacunes de sécurité et des configurations inattendues.

Vérification :

Entra ID > Protection > Méthodes d’authentification > Stratégies > Migration
Vérifier que l’état est “Migration terminée” et non “En cours” ou “Non commencée”

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Gérer la migration
Auditer les méthodes activées dans l’ancienne console MFA
Reconfigurer de manière équivalente dans la nouvelle console Authentication Methods
Cliquer sur “Terminer la migration” une fois la configuration validée
Après migration : toute gestion se fait exclusivement via Authentication Methods Policy

1.1.8 — Bloquer l’authentification héritée (Legacy Authentication)

Niveau : 🔴 Critique Référence CIS : CIS Control 4.8

Description : Les protocoles d’authentification héritée (SMTP AUTH, POP3, IMAP, MAPI basique, EWS Basic Auth) ne supportent pas le MFA. Ils représentent un vecteur d’attaque majeur car ils permettent de bypasser entièrement le MFA via des attaques par force brute ou password spray.

Vérification :

Entra ID > Connexions > Filtrer par “Application cliente” → protocoles hérités
PowerShell :

Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'SMTP Auth' or clientAppUsed eq 'POP3' or clientAppUsed eq 'IMAP4'" | Select-Object UserPrincipalName, ClientAppUsed, CreatedDateTime

Vérifier les 30 derniers jours d’activité

Remédiation :

Créer une Politique d’Accès Conditionnel : Bloquer les authentifications héritées
- Utilisateurs : Tous
- Applications cloud : Toutes
- Conditions > Applications clientes : cocher “Autres clients”
- Accorder : Bloquer l’accès
Avant le blocage, identifier les applications utilisant encore ces protocoles
Migrer les applications vers les protocoles modernes (OAuth 2.0, MSAL)
Dans Exchange : Désactiver SMTP AUTH au niveau tenant sauf exceptions justifiées

1.2 Paramètres M365 Admin Center (Org Settings)

1.2.1 — Utiliser des licences à empreinte applicative réduite pour les comptes admin

Niveau : 🟠 Élevé Référence CIS : 1.1.4 (L1) — Automated Profile : E3 Level 1

Description : Les comptes administrateurs dédiés ne doivent pas disposer de licences M365 complètes incluant Teams, Exchange, SharePoint, etc. Une licence complète augmente inutilement la surface d’attaque : si un compte admin est compromis, l’attaquant hérite de toutes les capacités de la licence. La recommandation CIS est d’utiliser des licences minimales (ex: Azure AD P2 seule) pour les comptes admin purs.

Vérification :

# Lister les comptes admin et leurs licences
$adminRoles = Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'"
$adminMembers = Get-MgDirectoryRoleMember -DirectoryRoleId $adminRoles.Id
foreach ($admin in $adminMembers) {
    $user = Get-MgUser -UserId $admin.Id -Property DisplayName,AssignedLicenses,UserPrincipalName
    Write-Output "$($user.UserPrincipalName): $($user.AssignedLicenses.SkuId -join ', ')"
}

Vérifier qu’aucun compte admin dédié ne possède de licence incluant Exchange Online, Teams, SharePoint, OneDrive, etc.

Remédiation :

Pour chaque compte admin dédié, retirer les licences M365 complètes
Assigner uniquement les licences nécessaires pour les fonctions admin (ex: Microsoft Entra ID P2, Microsoft 365 E3 sans Exchange/Teams si besoin de conformité)
Les admins utilisent leurs comptes utilisateur standards pour accéder à Teams, email, etc.
Vérifier que les comptes admin n’ont pas de boîte mail activée

Valeur par défaut : Aucune restriction — les comptes admin peuvent avoir n’importe quelle licence.

1.2.2 — Bloquer la connexion aux boîtes mail partagées (Shared Mailboxes)

Niveau : 🟠 Élevé Référence CIS : 1.2.2 (L1) — Automated Profile : E3 Level 1

Description : Les boîtes mail partagées sont conçues pour être accédées via délégation, pas par connexion directe. Un compte de boîte mail partagée avec connexion activée peut être utilisé par un attaquant comme point d’entrée : ces comptes ont souvent des mots de passe anciens, ne sont pas soumis au MFA standard, et passent sous le radar des revues d’accès.

Vérification :

# Identifier les shared mailboxes avec connexion non bloquée
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
    ForEach-Object {
        $mbx = $_
        $user = Get-MgUser -UserId $mbx.ExternalDirectoryObjectId -Property AccountEnabled,UserPrincipalName -ErrorAction SilentlyContinue
        if ($user.AccountEnabled -eq $true) {
            Write-Output "ATTENTION - Connexion active : $($user.UserPrincipalName)"
        }
    }

Remédiation :

# Bloquer la connexion sur toutes les shared mailboxes (Microsoft Graph)
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | ForEach-Object {
    Update-MgUser -UserId $_.ExternalDirectoryObjectId -AccountEnabled:$false
}

Les boîtes mail partagées restent accessibles via délégation depuis les comptes utilisateur autorisés.

Valeur par défaut : Connexion activée par défaut sur les comptes de boîtes partagées.

1.2.3 — Restreindre les groupes publics aux groupes approuvés par l’organisation

Niveau : 🟡 Moyen Référence CIS : 1.2.1 (L2) — Automated Profile : E3 Level 2

Description : Les groupes M365 publics (Microsoft 365 Groups avec accès public) permettent à n’importe quel utilisateur de l’organisation de rejoindre le groupe et d’accéder à son contenu (Teams, SharePoint, emails du groupe). Sans gouvernance, des données sensibles peuvent être stockées dans des groupes publics accessibles à tous.

Vérification :

# Lister les groupes publics non approuvés
Get-MgGroup -Filter "groupTypes/any(g:g eq 'Unified') and visibility eq 'Public'" |
    Select-Object DisplayName, Id, Visibility |
    Sort-Object DisplayName

Remédiation :

M365 Admin Center > Équipes et groupes > Groupes actifs
Pour chaque groupe public non justifié : changer la visibilité en “Privé”
Créer une politique de nommage et de gouvernance pour les nouveaux groupes
PowerShell pour convertir en privé :

Update-MgGroup -GroupId <GroupId> -Visibility "Private"

Activer l’approbation d’un administrateur pour la création de nouveaux groupes publics

Valeur par défaut : La visibilité du groupe est définie lors de la création, par défaut souvent “Public”.

1.2.4 — Configurer le délai d’expiration de session pour les appareils non gérés (≤ 3 heures)

Niveau : 🟠 Élevé Référence CIS : 1.3.2 (L2) — Automated Profile : E3 Level 2

Description : Sans délai d’expiration de session, une session M365 reste active indéfiniment sur un appareil non géré (ordinateur partagé, cybercafé, appareil personnel). Un attaquant ayant un accès physique temporaire à l’appareil peut réutiliser la session. La CIS recommande 3 heures maximum pour les appareils non gérés.

Vérification :

M365 Admin Center > Paramètres > Org Settings > Sécurité et confidentialité > Délai d’expiration de session inactive
PowerShell :

# Via SharePoint (contrôle le délai pour OWA/M365 web sur appareils non gérés)
Get-SPOTenant | Select-Object SignInAccelerationDomain, IdleSessionSignOut, IdleSessionSignOutWarnMinutes, IdleSessionSignOutMinutes

Remédiation :

M365 Admin Center > Paramètres > Org Settings > Sécurité et confidentialité
Activer “Délai d’expiration de session inactive pour les utilisateurs non actifs dans les applications web Microsoft 365”
Délai d’inactivité : 3 heures (ou moins selon la politique interne)
Avertissement avant déconnexion : 5 minutes
Via PowerShell SharePoint :

Set-SPOTenant -IdleSessionSignOut $true -IdleSessionSignOutWarnMinutes 5 -IdleSessionSignOutMinutes 180

Valeur par défaut : Pas de délai d’expiration configuré par défaut.

Note : Les contrôles CIS 1.3.4 à 1.3.9 (Office Store, Forms, Customer Lockbox, Stockage tiers, Sway, Bookings) sont couverts en Section 12 — Gestion Administrative (contrôles 12.1.6 à 12.1.11).

1.2b Politiques de Mots de Passe

1.2b.1 — Désactiver l’expiration automatique des mots de passe

Niveau : 🟡 Moyen Référence CIS : CIS Control 5.2 / NIST SP 800-63B

Description : Contrairement aux politiques historiques, le NIST recommande depuis 2017 de ne pas forcer l’expiration périodique des mots de passe. Cette pratique pousse les utilisateurs à choisir des mots de passe prévisibles avec incrémentation (ex: Motdepasse1 → Motdepasse2). Microsoft recommande désormais de ne pas expirer les mots de passe, couplé à la surveillance des compromissions.

Vérification :

Microsoft 365 Admin Center > Paramètres > Org Settings > Security & Privacy > Password expiration policy
Vérifier que “Set passwords to never expire” est activé

Remédiation :

M365 Admin Center > Paramètres > Org Settings > Sécurité et confidentialité
Activer “Les mots de passe n’expirent jamais”
Activer à la place la protection par mot de passe Entra ID (protection contre les mots de passe faibles/compromis)
Activer l’Identity Protection pour détecter les credentials compromis

1.2b.2 — Activer la Protection des Mots de Passe Entra ID

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.2

Description : La protection par mot de passe Entra ID bloque l’utilisation de mots de passe communs et facilement devinables. Microsoft maintient une liste des mots de passe compromis, et les organisations peuvent ajouter leurs propres termes interdits (nom de l’entreprise, termes métier, etc.).

Vérification :

Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe
Vérifier le mode (Audit ou Appliqué) et la liste personnalisée

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe
Activer “Activer la protection par mot de passe sur Windows Server Active Directory” si AD hybride
Passer du mode Audit au mode Appliqué après période de test
Ajouter termes interdits personnalisés : nom entreprise, variantes, termes sectoriels

1.2b.3 — Configurer le verrouillage intelligent (Smart Lockout) — Seuil ≤10 / Durée ≥60s

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.2 + M365SAT CISAz66/67 + EIDSCA.PR05/PR06 — Automated Licence requise : Entra ID Free

Description : Le Smart Lockout doit être configuré avec des valeurs précises : seuil ≤ 10 tentatives et durée ≥ 60 secondes. Par défaut, les valeurs sont trop permissives. Un seuil > 10 facilite les attaques par password spray (qui envoient 1 tentative par compte sur des milliers de comptes, sous le radar des lockouts). La durée de 60 secondes minimum empêche les attaques rapides en rafale.

Vérification :

# Vérifier via l'API interne Azure AD (non disponible via Graph standard)
$token = (Get-MgContext).AccessToken
$headers = @{ Authorization = "Bearer $token" }
$lockoutConfig = Invoke-RestMethod -Uri "https://main.iam.ad.ext.azure.com/api/PasswordProtectionPolicy" `
    -Headers $headers -Method GET -ErrorAction SilentlyContinue
$lockoutConfig | Select-Object lockoutThreshold, lockoutDurationInSeconds
# Résultat attendu : lockoutThreshold ≤ 10, lockoutDurationInSeconds ≥ 60

Portail : Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe
Seuil de verrouillage : 10 maximum (idéalement 5 pour environnements sensibles)
Durée de verrouillage : 60 secondes minimum (idéalement 120s)
Mode : passer d’Audit à Appliqué après validation
Pour environnements très sensibles : seuil = 5, durée = 120s

Valeur par défaut : Seuil = 10 (correct), durée = 60s (correct) — mais le mode est souvent “Audit” et non “Appliqué”.

1.2b.4 — Configurer une liste de mots de passe bannis personnalisée

Niveau : 🟡 Moyen Référence CIS : CIS Control 5.2 + M365SAT CISAz68 + EIDSCA.PR03 — Manual Licence requise : Entra ID P1

Description : En complément de la liste globale de mots de passe bannis Microsoft (500+ millions de mots de passe compromis), chaque organisation doit configurer une liste personnalisée incluant : le nom de l’entreprise, ses variantes, les termes métier courants, les noms de produits, etc. Ces termes sont facilement devinables par des attaquants qui connaissent l’organisation (OSINT).

Vérification :

# Vérifier la liste personnalisée via l'API interne
$token = (Get-MgContext).AccessToken
$headers = @{ Authorization = "Bearer $token" }
$pwdProtection = Invoke-RestMethod -Uri "https://main.iam.ad.ext.azure.com/api/PasswordProtectionPolicy" `
    -Headers $headers -Method GET -ErrorAction SilentlyContinue
$pwdProtection | Select-Object enableBannedPasswordCheck, bannedPasswordList
# Résultat attendu : enableBannedPasswordCheck = True, bannedPasswordList non vide

Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe > Liste personnalisée

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe
Activer “Appliquer la liste personnalisée”
Ajouter minimum : nom entreprise, acronymes, termes métier principaux (15+ termes)
Activer aussi sur l’AD on-premises si environnement hybride (agent Azure AD Password Protection)

Valeur par défaut : Liste personnalisée vide — seule la liste globale Microsoft est active.

1.2b.5 — Exiger 2 méthodes pour la réinitialisation de mot de passe (SSPR)

Niveau : 🟠 Élevé Référence CIS : CIS 5.2.4.1 + M365SAT CISAz65 — Automated Licence requise : Entra ID P1

Description : La réinitialisation de mot de passe en libre-service (SSPR) avec une seule méthode (ex: email uniquement) ne constitue pas un vrai second facteur. Si l’attaquant a accès à la boîte mail, il peut réinitialiser le mot de passe et prendre le contrôle du compte M365. Exiger 2 méthodes indépendantes (ex: application d’authentification + téléphone) empêche ce scénario.

Vérification :

# Vérifier le nombre de méthodes requises pour SSPR
$ssprPolicy = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy" -Method GET
$ssprConfig = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/directory/authenticationMethodConfigurations/passwordReset" -Method GET -ErrorAction SilentlyContinue
# Vérifier aussi via l'API interne :
$token = (Get-MgContext).AccessToken
$headers = @{ Authorization = "Bearer $token" }
$sspr = Invoke-RestMethod -Uri "https://main.iam.ad.ext.azure.com/api/PasswordReset/IsEnabled" `
    -Headers $headers -Method GET -ErrorAction SilentlyContinue
Write-Host "SSPR enabled: $sspr"

Entra ID > Protection > Réinitialisation du mot de passe > Méthodes d’authentification > “Nombre de méthodes requises pour la réinitialisation” = 2

Remédiation :

Entra ID > Protection > Réinitialisation du mot de passe > Méthodes d’authentification
Nombre de méthodes requises : 2
Méthodes recommandées : Application d’authentification + Téléphone (pas email seul)
Désactiver les questions de sécurité (devinables via OSINT)
Désactiver l’authentification par email seul comme méthode SSPR

Valeur par défaut : 1 méthode requise — insuffisant pour une protection réelle.

1.3 Accès Conditionnel (Conditional Access)

1.3.1 — Activer les Paramètres de Sécurité par Défaut ou l’Accès Conditionnel

Niveau : 🔴 Critique Référence CIS : CIS Control 4.1 MITRE ATT&CK : T1078.004 (Valid Accounts: Cloud) · T1550.001 (Application Access Token) · T1110 (Brute Force)

Description : Les Security Defaults fournissent un niveau de sécurité minimal sans configuration. Pour les organisations plus matures, l’Accès Conditionnel offre une granularité plus fine. L’un ou l’autre DOIT être activé. Un tenant sans l’un ni l’autre est extrêmement vulnérable.

Vérification :

Entra ID > Vue d’ensemble > Paramètres de sécurité par défaut (Security Defaults)
OU Entra ID > Protection > Accès Conditionnel > Politiques

Remédiation :

Si organisation < 50 utilisateurs sans équipe IT : activer Security Defaults
Si organisation avec besoins spécifiques : désactiver Security Defaults et créer des politiques CA granulaires
Ne jamais avoir les deux désactivés simultanément

1.3.2 — Politique CA : Exiger un appareil conforme ou hybride Azure AD

Niveau : 🟠 Élevé Référence CIS : CIS Control 12.1

Description : Restreindre l’accès aux ressources M365 aux seuls appareils conformes (gérés par Intune avec politiques de conformité validées) ou hybrides Azure AD réduit considérablement la surface d’attaque et empêche l’accès depuis des appareils personnels non sécurisés.

Vérification :

Accès Conditionnel > Politiques
Vérifier l’existence d’une politique vérifiant la conformité des appareils

Remédiation :

Créer politique CA : Utilisateurs → Tous, Ressources → Toutes apps cloud
Conditions > Plateformes d’appareils → Sélectionner plateformes concernées
Accorder → Exiger que l’appareil soit marqué comme conforme
Prérequis : Déployer Intune et définir des politiques de conformité

1.3.3 — Politique CA : Bloquer les pays à risque

Niveau : 🟠 Élevé Référence CIS : CIS Control 13.1

Description : Bloquer les connexions provenant de pays où l’organisation n’a pas d’activité réduit significativement la surface d’attaque pour les campagnes de phishing et de password spray souvent initiées depuis des pays spécifiques.

Vérification :

Accès Conditionnel > Emplacements nommés > Vérifier les politiques de blocage géographique

Remédiation :

Entra ID > Protection > Accès Conditionnel > Emplacements nommés
Créer un emplacement “Pays autorisés” avec les pays légitimes
Créer politique CA : Conditions > Emplacements → Exclure les pays autorisés → Bloquer

1.3.4 — Politique CA : Protéger l’accès à Azure/Entra ID Management

Niveau : 🔴 Critique Référence CIS : CIS Control 4.1

Description : L’accès au portail Azure et aux APIs de gestion doit être restreint aux seuls utilisateurs légitimes depuis des postes de travail d’administration dédiés (PAW - Privileged Access Workstations).

Vérification :

Vérifier l’existence d’une politique CA ciblant “Microsoft Azure Management”
Vérifier les conditions restrictives appliquées

Remédiation :

Créer politique CA ciblant l’application “Microsoft Azure Management”
Restreindre aux administrateurs uniquement
Exiger MFA renforcé (FIDO2 ou Windows Hello for Business)
Optionnel : Restreindre aux PAW (appareils spécifiques via filtres d’appareils)

1.3.5 — Politique CA : Fréquence de reconnexion et sessions persistantes

Niveau : 🟡 Moyen Référence CIS : CIS Control 4.3

Description : Les sessions persistantes sur des appareils non gérés représentent un risque si l’appareil est compromis ou partagé. Définir une fréquence de reconnexion limite la durée d’exposition en cas de vol de session.

Vérification :

Politiques CA > Sessions > Vérifier les paramètres de fréquence de connexion

Remédiation :

Pour appareils non conformes : fréquence de connexion = 1 heure
Pour appareils conformes : fréquence de connexion = 8 heures ou persistante
Désactiver “Rester connecté” pour les appareils non gérés
Politique CA : Conditions > Appareils non conformes → Session → Fréquence de connexion : 1h

1.3.6 — Bloquer le flux Device Code (Device Code Flow) — Storm-2372

Niveau : 🔴 Critique Référence : Maester MT.1052 + CISA Advisory 2025 — Automated Licence requise : Entra ID P1

Description : Le Device Code Flow (deviceCodeFlow) est une méthode d’authentification OAuth conçue pour les appareils sans navigateur (TV, imprimantes). En 2025, le groupe d’attaquants Storm-2372 (étatique) a massivement exploité ce flux pour du phishing : l’attaquant demande un code appareil, l’envoie à la victime par email/Teams, la victime entre le code sur un site légitime Microsoft et l’attaquant obtient un token d’accès complet sans jamais avoir besoin du mot de passe. Ce flux doit être bloqué par une politique CA.

Vérification :

# Vérifier si une politique CA bloque le Device Code Flow
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$deviceCodePolicy = $caPolicies | Where-Object {
    $_.Conditions.AuthenticationFlows -ne $null -and
    $_.Conditions.AuthenticationFlows.TransferMethods -contains "deviceCodeFlow"
}
if ($deviceCodePolicy) {
    Write-Host "✅ Device Code Flow bloqué par la politique : $($deviceCodePolicy.DisplayName)" -ForegroundColor Green
} else {
    Write-Host "❌ CRITIQUE : Aucune politique CA ne bloque le Device Code Flow (Storm-2372 vector)" -ForegroundColor Red
}

Remédiation :

Entra ID > Sécurité > Accès conditionnel > Nouvelle politique
Nom : “ANC-CA-Block-DeviceCodeFlow”
Utilisateurs : Tous les utilisateurs
Conditions > Flux d’authentification > Device Code Flow = Inclure
Contrôles d’accès > Accorder > Bloquer l’accès
État : Activé

# PowerShell via Graph
$params = @{
    displayName = "ANC-CA-Block-DeviceCodeFlow"
    state = "enabled"
    conditions = @{
        users = @{ includeUsers = @("All") }
        authenticationFlows = @{ transferMethods = "deviceCodeFlow" }
    }
    grantControls = @{ operator = "OR"; builtInControls = @("block") }
}
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Method POST -Body ($params | ConvertTo-Json -Depth 5)

Valeur par défaut : Device Code Flow autorisé — aucune restriction par défaut.

1.3.7 — Bloquer le flux d’authentification legacy (Other Clients)

Niveau : 🔴 Critique Référence : CIS 5.2.1.1 (L1) + CISA MS.AAD.1.1v1 — Automated Licence requise : Entra ID P1

Description : Les clients d’authentification legacy (MAPI, POP, IMAP, SMTP AUTH, Exchange ActiveSync ancienne version) ne supportent pas le MFA et l’Accès Conditionnel. Une politique CA doit bloquer explicitement les deux types : “Other clients” et “Exchange ActiveSync clients”. De nombreux audits révèlent que seul l’un des deux est bloqué, laissant un vecteur ouvert.

Vérification :

# Vérifier les deux types de clients legacy
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }

# Politique pour "Other clients"
$blockOther = $caPolicies | Where-Object {
    $_.Conditions.ClientAppTypes -contains "exchangeActiveSync" -or
    $_.Conditions.ClientAppTypes -contains "other"
} | Where-Object {
    $_.GrantControls.BuiltInControls -contains "block"
}

Write-Host "Legacy auth (Other) bloqué : $(if($blockOther){'✅'}else{'❌ CRITIQUE'})"

Remédiation :

Politique CA couvrant exchangeActiveSync ET other client types
Vérifier que les deux sont dans la même politique ou deux politiques distinctes
Exclure uniquement les comptes Break Glass

Valeur par défaut : Clients legacy non bloqués — auth sans MFA possible.

1.3.8 — Politique CA : Auth résistante au phishing pour les administrateurs (FIDO2/Passkey)

Niveau : 🟠 Élevé Référence : CISA MS.AAD.3.6v1 + M365-Assess CA-PHISHRES-001 — Automated Licence requise : Entra ID P1 + Microsoft Authenticator / FIDO2

Description : Le MFA classique (SMS, push notification) est vulnérable aux attaques de type AiTM (Adversary-in-the-Middle) et MFA fatigue. Les méthodes d’authentification résistantes au phishing (FIDO2, Windows Hello for Business, Certificate-based Auth) ne peuvent pas être interceptées car elles sont liées au domaine. La CISA exige ces méthodes pour les rôles hautement privilégiés.

Vérification :

# Vérifier une politique CA exigeant l'auth résistante au phishing pour les admins
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$phishResistant = $caPolicies | Where-Object {
    $_.GrantControls.AuthenticationStrength -ne $null
} | Where-Object {
    $_.Conditions.Users.IncludeRoles.Count -gt 0
}
$phishResistant | Select-Object DisplayName, @{N='Strength';E={$_.GrantControls.AuthenticationStrength.DisplayName}} | Format-Table

Remédiation :

Entra ID > Sécurité > Méthodes d’authentification > Niveaux d’authentification
Utiliser le niveau prédéfini “Phishing-resistant MFA”
Politique CA ciblant les rôles admin avec ce niveau d’authentification requis
Déployer les clés FIDO2 ou Windows Hello for Business pour les admins

Valeur par défaut : MFA standard (pas résistant au phishing) — méthodes SMS/push autorisées.

1.3.9 — Politique CA : Restreindre l’accès aux réseaux conformes uniquement (Compliant Network)

Niveau : 🟠 Élevé Référence : Entra ID P1 + Global Secure Access Licence requise : Entra ID P1 + Entra Suite (pour Global Secure Access)

Description : La condition “Réseau conforme” (Compliant Network) dans l’Accès Conditionnel restreint l’accès aux ressources M365 aux seuls appareils passant par le réseau approuvé de l’organisation — qu’il soit physique (réseau d’entreprise) ou virtuel (Microsoft Entra Internet Access). Elle complète les Named Locations en ajoutant une dimension de conformité réseau : même depuis une IP d’entreprise, un appareil personnel ou compromis peut être bloqué si le trafic ne transite pas par le SWG approuvé. C’est une défense clé contre les contournements de CA via VPN partagés.

Vérification :

# Vérifier l'existence d'une politique CA avec condition de réseau conforme
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$compliantNetwork = $caPolicies | Where-Object {
    ($_.Conditions | ConvertTo-Json -Depth 5) -match "compliantNetwork|networkType"
}
if ($compliantNetwork) {
    Write-Host "✅ Politique CA avec Compliant Network trouvée : $($compliantNetwork.DisplayName)" -ForegroundColor Green
} else {
    Write-Host "⚠️  Aucune politique CA avec condition réseau conforme" -ForegroundColor Yellow
}
# Portail : Entra ID > CA > [Politique] > Conditions > Réseaux > Réseau conforme

Remédiation :

Prérequis : déployer Microsoft Entra Internet Access (Global Secure Access)
Créer politique CA : Conditions > Réseaux > Inclure “Réseau conforme”
Applications cloud : Exchange Online, SharePoint Online, Teams
Accorder : Accorder l’accès (le réseau conforme est lui-même le contrôle)
Démarrer en mode “Rapport seul” avant d’activer pour mesurer l’impact

Valeur par défaut : Aucune condition réseau conforme — accès depuis n’importe quel réseau possible.

1.3b Paramètres Utilisateurs Entra ID Supplémentaires

1.3b.1 — Désactiver le MFA par utilisateur (Per-User MFA legacy)

Niveau : 🔴 Critique Référence CIS : 5.1.2.1 (L1) — Automated Profile : E3 Level 1

Description : La console MFA “par utilisateur” (legacy, accessible via https://account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx) est l’ancienne méthode de gestion du MFA, distincte de l’Accès Conditionnel. Si des utilisateurs ont leur MFA géré via cet ancien système ET via l’Accès Conditionnel, des conflits peuvent survenir. La CIS exige que le MFA per-user legacy soit désactivé pour tous les utilisateurs, le MFA étant exclusivement géré via l’Accès Conditionnel.

Vérification :

# Vérifier les utilisateurs avec per-user MFA encore activé (Enforced ou Enabled)
$uri = "https://graph.microsoft.com/beta/users?`$select=userPrincipalName,strongAuthenticationRequirements"
$response = Invoke-MgGraphRequest -Uri $uri -Method GET
$response.value | Where-Object {
    $_.strongAuthenticationRequirements.state -ne $null -and
    $_.strongAuthenticationRequirements.state -ne "disabled"
} | Select-Object userPrincipalName, @{N='MFA State';E={$_.strongAuthenticationRequirements.state}}

Remédiation :

Accéder à l’ancienne console MFA : https://account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx
Sélectionner tous les utilisateurs > Désactiver le MFA per-user
Ou via PowerShell (module MSOnline legacy) :

# Via l'API beta
$allUsers = Get-MgUser -All -Property UserPrincipalName,StrongAuthenticationRequirements
$allUsers | Where-Object {$_.StrongAuthenticationRequirements} | ForEach-Object {
    # Utiliser l'ancienne interface ou l'API beta pour désactiver
}

S’assurer qu’une politique CA est en place pour exiger le MFA avant de désactiver le per-user MFA

Impact : Si le per-user MFA est désactivé SANS politique CA correspondante, les utilisateurs n’auront plus de MFA. Toujours vérifier la politique CA avant.

1.3b.2 — Restreindre l’accès au portail Entra ID Admin Center aux administrateurs

Niveau : 🟠 Élevé Référence CIS : 5.1.2.4 (L1) — Manual Profile : E3 Level 1

Description : Par défaut, les utilisateurs standards peuvent accéder à certaines fonctionnalités du portail Entra ID (https://entra.microsoft.com) et y consulter des informations sur les utilisateurs, groupes et applications. Restreindre cet accès aux administrateurs limite la reconnaissance interne possible depuis un compte compromis.

Vérification :

Entra ID > Utilisateurs > Paramètres utilisateur > “Restreindre l’accès au portail d’administration Entra ID”

Remédiation :

Entra ID > Utilisateurs > Paramètres utilisateur
“Restreindre l’accès au portail d’administration Microsoft Entra” = Oui
Nota : Ce paramètre ne restreint pas l’accès via PowerShell ou API — utiliser des politiques CA pour cela

Valeur par défaut : Non restreint — tous les utilisateurs peuvent accéder au portail Entra.

Note : Les contrôles 1.3b.3 (Rester connecté), 1.3b.4 (LinkedIn), 1.3b.5 (Groupe dynamique guests), 1.3b.6 (Groupes de sécurité) sont consolidés en Section 1.9 — contrôles 1.9.6, 1.9.7, 1.9.1, 1.9.2.

1.3c Gestion des Appareils Entra ID

1.3c.1 — Ne pas ajouter le Global Administrator comme administrateur local lors de la jonction Entra

Note : Ce contrôle est consolidé en Section 12 — contrôle 12.1.x (Gestion Administrative des appareils). Référence CIS : 5.1.4.3 (L1).

1.3c.2 — Activer la solution de mot de passe administrateur local (LAPS)

Niveau : 🟠 Élevé Référence CIS : 5.1.4.5 (L1) — Automated Profile : E3 Level 1

Description : LAPS (Local Administrator Password Solution) gère automatiquement les mots de passe des comptes administrateurs locaux Windows. Sans LAPS, tous les postes de travail peuvent avoir le même mot de passe admin local — si un attaquant l’obtient, il peut se déplacer latéralement sur l’ensemble du parc. LAPS génère un mot de passe unique par machine, stocké dans Entra ID, et le renouvelle régulièrement.

Vérification :

Entra ID > Appareils > Tous les appareils > Sélectionner un appareil > Mot de passe administrateur local
PowerShell :

# Vérifier si LAPS est activé dans Entra ID
$deviceSettings = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/deviceRegistrationPolicy" -Method GET
$deviceSettings.localAdminPassword.isEnabled

Remédiation :

Entra ID > Appareils > Paramètres d’appareil
Activer “Gestion des mots de passe d’administrateur local”
Configurer la stratégie de rotation : fréquence recommandée = après chaque utilisation ou 30 jours
Via Intune : déployer une politique LAPS pour tous les appareils Windows
Restreindre qui peut lire les mots de passe LAPS (rôle “Local Administrator Password Reader”)

Valeur par défaut : LAPS non configuré par défaut.

1.3c.3 — Restreindre la récupération des clés BitLocker par les utilisateurs

Niveau : 🟡 Moyen Référence CIS : 5.1.4.6 (L2) — Automated Profile : E3 Level 2

Description : Si les utilisateurs peuvent récupérer eux-mêmes leurs clés BitLocker depuis Entra ID, un attaquant ayant compromis le compte M365 d’un utilisateur peut déchiffrer le disque dur de son poste de travail. Les clés BitLocker ne doivent être récupérables que par les administrateurs IT ou le helpdesk.

Vérification :

Entra ID > Appareils > Paramètres d’appareil > “Les utilisateurs peuvent récupérer la clé BitLocker”

Remédiation :

Entra ID > Appareils > Paramètres d’appareil
“Les utilisateurs peuvent récupérer la clé BitLocker pour leurs appareils” = Non
Définir un processus helpdesk pour la récupération des clés BitLocker sur demande justifiée

Valeur par défaut : Les utilisateurs peuvent récupérer leurs propres clés BitLocker.

1.3c.4 — Limiter le nombre maximum d’appareils par utilisateur

Niveau : 🟡 Moyen Référence CIS : 5.1.4.2 (L1) — Automated Profile : E3 Level 1

Description : Limiter le nombre d’appareils qu’un utilisateur peut enregistrer dans Entra ID réduit la surface d’attaque et limite les abus (enregistrement massif d’appareils malveillants pour obtenir des tokens d’accès).

Vérification :

Entra ID > Appareils > Paramètres d’appareil > “Nombre maximal d’appareils par utilisateur”

(Get-MgPolicyDeviceRegistrationPolicy).UserDeviceQuota

Remédiation :

Entra ID > Appareils > Paramètres d’appareil
Nombre maximal d’appareils par utilisateur : 5 (ou selon politique interne, CIS recommande une valeur limitée)
Pour les utilisateurs ayant besoin de plus d’appareils : créer un groupe d’exception documenté

Valeur par défaut : Illimité.

1.3d Gestion Hybride

1.3d.1 — Activer la synchronisation du hachage de mot de passe (PHS) pour les déploiements hybrides

Niveau : 🟠 Élevé Référence CIS : 5.1.8.1 (L1) — Manual Profile : E3 Level 1

Description : La synchronisation du hachage de mot de passe (Password Hash Sync - PHS) entre l’AD on-premises et Entra ID permet plusieurs bénéfices sécurité : 1) détection des credentials compromis (Microsoft Identity Protection peut vérifier les hachages contre des bases de données de compromission connues), 2) continuité en cas de panne AD FS, 3) protection contre les attaques de pulvérisation de mots de passe. Sans PHS, Entra ID ne peut pas détecter les compromissions de mots de passe AD.

Vérification :

Entra Connect / Entra Cloud Sync > Vérifier que la synchronisation du hachage est activée
PowerShell (sur le serveur Entra Connect) :

Get-ADSyncScheduler | Select-Object SyncCycleEnabled

Dans Entra ID : vérifier sous “Méthodes d’authentification” si le “Leaked Credentials” detection est actif (nécessite PHS)

Remédiation :

Sur le serveur Azure AD Connect : ouvrir l’assistant de configuration
Tâches supplémentaires > Personnaliser les options de synchronisation
Activer “Synchronisation du hachage de mot de passe”
Pour Entra Cloud Sync : vérifier dans les paramètres du connecteur

Valeur par défaut : Dépend de la configuration initiale choisie lors de l’installation d’Entra Connect.

1.4 Accès Conditionnel Basé sur le Risque (Identity Protection)

1.4.1 — Bloquer les utilisateurs détectés comme à haut risque

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.2.1v1 Licence requise : Entra ID P2 MITRE ATT&CK : T1078 (Valid Accounts) · T1586 (Compromise Accounts) · T1110.004 (Brute Force: Credential Stuffing)

Description : Entra ID Identity Protection calcule un score de risque pour chaque utilisateur basé sur des signaux d’intelligence des menaces (Microsoft détecte des milliards de connexions et identifie des patterns d’attaque). Un utilisateur “haut risque” a probablement ses credentials dans une base de données compromise ou a montré des comportements anormaux. Ces comptes doivent être bloqués immédiatement jusqu’à remédiation sécurisée.

Vérification :

Entra ID > Protection > Accès Conditionnel > Vérifier l’existence d’une politique de risque utilisateur élevé
PowerShell :

Get-MgIdentityConditionalAccessPolicy | Where-Object {
    $_.Conditions.UserRiskLevels -contains "high"
} | Select-Object DisplayName, State

Remédiation :

Entra ID > Protection > Accès Conditionnel > Créer une politique
Conditions > Risque de l’utilisateur → Élevé
Accorder → Bloquer l’accès
Alternativement : Exiger MFA + Changement de mot de passe sécurisé (si vous souhaitez permettre une auto-remédiation)
Configurer les alertes pour notifier le SOC lors de la détection d’utilisateurs à haut risque (MS.AAD.2.2v1)

1.4.2 — Bloquer les connexions détectées comme à haut risque

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.2.3v1 Licence requise : Entra ID P2

Description : Distinct du risque utilisateur, le risque de connexion évalue chaque tentative de connexion individuellement : voyage impossible (connexion depuis Paris puis New York en 10 minutes), adresses IP anonymisées (Tor, VPN connus malveillants), pulvérisation de mots de passe, etc. Ces connexions doivent être bloquées même si les credentials sont corrects.

Vérification :

Entra ID > Protection > Accès Conditionnel > Vérifier l’existence d’une politique de risque de connexion élevé
Entra ID > Protection > Rapport sur les connexions risquées

Remédiation :

Créer une politique CA : Conditions > Risque de connexion → Élevé
Accorder → Bloquer l’accès (ou Exiger MFA résistante au phishing)
Pour le risque moyen : Exiger MFA comme étape d’auto-remédiation
Réviser hebdomadairement le tableau de bord des connexions risquées

1.4b Politique CA Supplémentaires (CIS v6.0.1)

1.4b.1 — Bloquer les sessions navigateur persistantes pour les administrateurs

Niveau : 🟠 Élevé Référence CIS : 5.2.2.4 (L1) — Automated Profile : E3 Level 1

Description : Les sessions navigateur persistantes (cookies de session à longue durée de vie) permettent de rester authentifié même après la fermeture du navigateur. Pour les comptes administrateurs, cette persistance est particulièrement dangereuse : un token volé ou un cookie exfiltré reste valide indéfiniment. Les sessions admin doivent être non-persistantes et soumises à une fréquence de reconnexion stricte.

Vérification :

# Vérifier les politiques CA avec paramètres de session pour les admins
Get-MgIdentityConditionalAccessPolicy | Where-Object {
    $_.SessionControls.PersistentBrowser -ne $null
} | Select-Object DisplayName, @{N='PersistentBrowser';E={$_.SessionControls.PersistentBrowser.Mode}}

Remédiation :

Créer une politique CA ciblant les utilisateurs avec rôles d’administration
Session > Session de navigateur persistante : Jamais persistante
Session > Fréquence de connexion : 1 heure (ou à chaque fois pour les rôles les plus sensibles)
Cette politique doit s’appliquer même sur des appareils conformes pour les comptes admin

1.4b.2 — Bloquer le risque de connexion moyen ET élevé (pas seulement élevé)

Niveau : 🟠 Élevé Référence CIS : 5.2.2.8 (L2) — Automated Profile : E3 Level 2 Licence requise : Entra ID P2

Description : Notre checklist bloque uniquement le risque de connexion ÉLEVÉ. Le CIS v6.0.1 recommande également de bloquer ou d’exiger une action pour le risque MOYEN. Un risque moyen peut indiquer des activités suspectes comme une connexion depuis un pays inhabituel ou une anomalie de comportement qui mérite investigation.

Vérification :

Get-MgIdentityConditionalAccessPolicy | Where-Object {
    $_.Conditions.SignInRiskLevels -contains "medium"
} | Select-Object DisplayName, State

Remédiation :

Modifier la politique CA de risque de connexion existante
Ajouter “Moyen” aux niveaux de risque couverts
Pour le risque moyen : Exiger MFA (auto-remédiation) plutôt que bloquer directement
Pour le risque élevé : maintenir le blocage complet

1.4b.3 — Exiger une fréquence de connexion “À chaque fois” pour l’inscription Intune

Niveau : 🟡 Moyen Référence CIS : 5.2.2.11 (L1) — Automated Profile : E3 Level 1

Description : Lors de l’inscription d’un appareil dans Intune, l’utilisateur doit se ré-authentifier systématiquement. Cela évite qu’un attaquant avec un token de session volé puisse inscrire un appareil malveillant dans la gestion Intune de l’organisation, ce qui lui donnerait accès aux configurations et politiques déployées.

Vérification :

Vérifier l’existence d’une politique CA ciblant l’application “Microsoft Intune Enrollment”
Session > Fréquence de connexion : “À chaque fois”

Remédiation :

Créer politique CA : Applications cloud → Microsoft Intune Enrollment
Session > Fréquence de connexion = “À chaque fois” (Every time)
Cette politique force une authentification fraîche à chaque tentative d’enrôlement

1.5 Gestion des Applications et Consentements

1.5.1 — Restreindre l’enregistrement d’applications aux administrateurs uniquement

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.5.1v1

Description : Par défaut, n’importe quel utilisateur peut enregistrer des applications dans Entra ID. Des applications malveillantes enregistrées par des utilisateurs compromis peuvent obtenir des tokens OAuth persistants avec des permissions larges sur les données de l’organisation.

Vérification :

(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.AllowedToCreateApps

Doit retourner : False

Remédiation :

$permObj = (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions
$permObj.AllowedToCreateApps = $false
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $permObj

1.5.2 — Restreindre le consentement aux applications tierces aux administrateurs uniquement

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.5.2v1 MITRE ATT&CK : T1528 (Steal Application Access Token) · T1550.001 (Use Alternate Auth Material: Application Access Token) · T1071.001 (Web Protocols)

Description : Le consentement OAuth des utilisateurs est exploité dans les attaques de type “Consent Phishing” (ou OAuth Phishing) : un attaquant crée une application malveillante qui demande des permissions sur les données M365, envoie un lien à la victime, et obtient un accès persistant sans mot de passe ni MFA une fois le consentement accordé.

Vérification :

Entra ID > Applications d’entreprise > Paramètres utilisateur > Consentement utilisateur pour les applications
Doit être configuré sur : “Ne pas autoriser le consentement utilisateur”

Remédiation :

Entra ID > Applications d’entreprise > Consentement et permissions
Consentement utilisateur pour les applications : “Ne pas autoriser le consentement utilisateur”
Activer le workflow d’approbation administrateur (MS.AAD.5.3v1) pour que les utilisateurs puissent demander l’autorisation
Désigner des réviseurs de consentement (RSSI, équipe IT)

1.5.3 — Activer le workflow de consentement administrateur

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.5.3v1

Description : Une fois le consentement utilisateur désactivé, les utilisateurs légitimes qui ont besoin d’une application tierce doivent pouvoir soumettre une demande d’approbation. Sans ce workflow, ils contournent les politiques en cherchant des alternatives non sécurisées.

Vérification :

Entra ID > Applications d’entreprise > Consentement et permissions > Workflow d’approbation administrateur

Remédiation :

Entra ID > Applications d’entreprise > Paramètres utilisateur > Workflow d’approbation administrateur
Activer “Les utilisateurs peuvent demander le consentement administrateur pour les applications auxquelles ils ne peuvent pas accorder leur consentement”
Ajouter des réviseurs de consentement
Délai d’expiration des demandes : 30 jours

1.5.4 — Exiger des Éditeurs Vérifiés (Verified Publishers) pour les applications tierces

Niveau : 🟠 Élevé Référence : Entra ID — OAuth Governance Licence requise : Entra ID P1

Description : Les applications OAuth tierces d’éditeurs non vérifiés sont la source principale des attaques de Consent Phishing : n’importe qui peut créer une application Azure AD demandant des permissions M365, sans aucune validation d’identité. Les éditeurs vérifiés (Verified Publishers) ont prouvé leur identité via Microsoft Partner Network. Restreindre le consentement ou la visibilité aux seules applications d’éditeurs vérifiés réduit drastiquement la surface des applications malveillantes.

Vérification :

# Lister les applications tierces consentées sans éditeur vérifié
$sps = Get-MgServicePrincipal -All | Where-Object {
    $_.AppOwnerOrganizationId -ne (Get-MgContext).TenantId -and
    $_.VerifiedPublisher.DisplayName -eq $null
}
Write-Host "Applications tierces sans éditeur vérifié : $($sps.Count)"
$sps | Select-Object DisplayName, AppId | Format-Table

Remédiation :

Entra ID > Applications d’entreprise > Consentement et permissions > Paramètres de consentement utilisateur
“Consentement pour les applications d’éditeurs vérifiés” : activer la restriction
Pour les applications existantes sans éditeur vérifié : évaluer le besoin et révoquer les consentements non justifiés
Entra ID > Applications d’entreprise > filtrer par “Non vérifié” et revoir chaque application
Former les utilisateurs à identifier le badge “Éditeur vérifié” avant de consentir

Valeur par défaut : Aucune restriction sur le statut d’éditeur — applications vérifiées et non vérifiées traitées identiquement.

1.5b Méthodes d’Authentification Supplémentaires (CIS v6.0.1)

1.5b.1 — Activer le MFA préféré par le système (System-Preferred MFA)

Niveau : 🟠 Élevé Référence CIS : 5.2.3.6 (L1) — Automated Profile : E3 Level 1

Description : La fonctionnalité “System-Preferred MFA” fait en sorte qu’Entra ID présente automatiquement la méthode MFA la plus sécurisée disponible pour l’utilisateur, plutôt que la méthode qu’il a définie comme préférée (qui pourrait être le SMS). Cela garantit que si un utilisateur a à la fois l’Authenticator App et le SMS enregistrés, Entra ID lui proposera toujours l’Authenticator App en premier.

Vérification :

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId "MicrosoftAuthenticator" |
    Select-Object -ExpandProperty AdditionalProperties |
    ConvertTo-Json
# Chercher "isSoftwareOathEnabled" et les paramètres de system-preferred

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Stratégies > Paramètres
Activer “Méthode d’authentification préférée du système”
Cela s’applique automatiquement à tous les utilisateurs enrôlés dans plusieurs méthodes

1.5b.2 — S’assurer que tous les utilisateurs membres sont capables MFA (MFA Capable)

Niveau : 🟠 Élevé Référence CIS : 5.2.3.4 (L1) — Automated Profile : E3 Level 1

Description : Un utilisateur “MFA Capable” a enregistré au moins une méthode d’authentification forte dans Entra ID. Un utilisateur non enrôlé dans une méthode MFA ne peut pas satisfaire les exigences MFA des politiques CA, ce qui peut bloquer son accès ou forcer un contournement. L’objectif est 100% des utilisateurs membres enrôlés dans MFA.

Vérification :

# Rapport des utilisateurs non enrôlés dans MFA
Get-MgReportAuthenticationMethodUserRegistrationDetail |
    Where-Object {$_.IsMfaRegistered -eq $false -and $_.UserType -eq "member"} |
    Select-Object UserPrincipalName, UserDisplayName, IsMfaRegistered, MethodsRegistered

Remédiation :

Activer la campagne d’enrôlement MFA dans Entra ID
Entra ID > Protection > Méthodes d’authentification > Campagne d’enrôlement
Définir un délai de grâce de 14 jours maximum
Suivre le taux d’enrôlement dans les rapports Entra ID
Pour les utilisateurs récalcitrants : intervention helpdesk individuelle

1.5b.3 — Activer la protection par mot de passe pour l’Active Directory on-premises

Niveau : 🟠 Élevé Référence CIS : 5.2.3.3 (L1) — Automated Profile : E3 Level 1

Description : La protection par mot de passe Entra ID peut être étendue à l’Active Directory on-premises. Les mêmes listes de mots de passe interdits (liste globale Microsoft + liste personnalisée de l’organisation) sont appliquées lors des changements de mot de passe dans l’AD local. Sans cette extension, les mots de passe faibles peuvent exister dans l’AD on-premises même si la protection cloud est active.

Vérification :

Vérifier si l’agent de protection par mot de passe Azure AD est installé sur les Domain Controllers

# Sur les DCs - vérifier le service
Get-Service -Name "AzureADPasswordProtectionDCAgent" -ErrorAction SilentlyContinue

Remédiation :

Télécharger l’agent de protection par mot de passe Azure AD
Installer sur tous les Domain Controllers
Installer le service proxy sur les serveurs membres (pour la communication avec Entra ID)
Entra ID > Protection > Méthodes d’authentification > Protection par mot de passe
Passer en mode “Appliqué” après la période d’audit

1.5b.4 — Configurer la réinitialisation de mot de passe en libre-service (SSPR) pour tous les utilisateurs

Niveau : 🟠 Élevé Référence CIS : 5.2.4.1 (L1) — Manual Profile : E3 Level 1

Description : Le SSPR (Self-Service Password Reset) permet aux utilisateurs de réinitialiser leur mot de passe eux-mêmes sans passer par le helpdesk. Bien que cela soit une mesure de commodité, le CIS recommande qu’il soit activé pour TOUS les utilisateurs car un SSPR non disponible peut pousser les utilisateurs à utiliser des mots de passe simples dont ils se souviennent facilement (pour éviter les appels au helpdesk). Le SSPR correctement sécurisé (avec vérification d’identité à 2 méthodes) est aussi sécurisé que le helpdesk.

Vérification :

Entra ID > Protection > Réinitialisation du mot de passe > Propriétés
Vérifier que “Réinitialisation de mot de passe en libre-service activée” = Tout

Remédiation :

Entra ID > Protection > Réinitialisation du mot de passe > Propriétés
Activer pour : Tout (tous les utilisateurs)
Configuration recommandée : 2 méthodes requises pour la réinitialisation
Méthodes autorisées : Application mobile / Notification, Code d’application mobile, Email, Téléphone
Désactiver : Questions de sécurité (facilement devinables via OSINT)
Activer la réécriture des mots de passe vers l’AD on-premises (si environnement hybride)

1.5c Sécurité Avancée des Applications et Service Principals

1.5c.1 — Auditer les permissions dangereuses Midnight Blizzard (AppRoleAssignment + RoleManagement)

Niveau : 🔴 Critique Référence : MSRC Advisory Jan 2024 — Automated Licence requise : Entra ID P1 MITRE ATT&CK : T1098.003 (Account Manipulation: Add Cloud Credentials) · T1550.001 (Application Access Token) · T1528 (Steal Application Access Token)

Description : Les permissions AppRoleAssignment.ReadWrite.All et RoleManagement.ReadWrite.Directory permettent à une application de s’attribuer elle-même n’importe quel rôle ou permission dans le tenant, y compris Global Administrator. C’est le vecteur exact utilisé par Midnight Blizzard (SVR russe) en janvier 2024 pour compromettre Microsoft. Toute application tierce ou interne disposant de ces permissions représente un risque critique immédiat.

Vérification :

# Détecter les apps avec permissions dangereuses
$dangerousPerms = @(
    "AppRoleAssignment.ReadWrite.All",
    "RoleManagement.ReadWrite.Directory",
    "Application.ReadWrite.All",
    "Directory.ReadWrite.All"
)
$sps = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$expand=appRoleAssignments" -Method GET
foreach ($sp in $sps.value) {
    $assignments = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$($sp.id)/appRoleAssignedTo" -Method GET
    # Filtrer par permissions dangereuses
    Write-Host "$($sp.displayName) — $($assignments.value.Count) assignments"
}
# Approche simplifiée via Graph Explorer :
# GET /v1.0/servicePrincipals?$filter=appRoles/any(r:r/value eq 'AppRoleAssignment.ReadWrite.All')

Remédiation :

Entra ID > Applications d’entreprise > Toutes les applications > Filtrer par permission
Identifier toutes les apps avec AppRoleAssignment.ReadWrite.All ou RoleManagement.ReadWrite.Directory
Pour chaque app : évaluer la légitimité du besoin — supprimer si non justifié
Remplacer par des permissions à granularité fine (ex: RoleAssignmentSchedule.ReadWrite.Directory)
Activer les alertes Defender pour Identité sur ces permissions

Valeur par défaut : Aucune restriction par défaut — toute app peut demander ces permissions si un admin consent.

1.5c.2 — Auditer les rôles Partner Tier1/Tier2 Support (invisibles dans l’interface Entra)

Niveau : 🔴 Critique Référence : Microsoft Partner Support Roles — Manual Licence requise : Entra ID Free

Description : Les rôles Partner Tier1 et Tier2 Support sont assignés par des partenaires Microsoft (revendeurs, MSP) et donnent accès au tenant avec des privilèges élevés, parfois équivalents au Global Administrator. Ces rôles sont invisibles dans l’interface Entra ID standard et ne sont pas listés dans PIM. Un partenaire non fiable ou compromis peut utiliser ces rôles pour prendre le contrôle complet du tenant sans laisser de trace dans les logs habituels.

Vérification :

# Détecter les rôles Partner cachés
$partnerRoles = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directoryRoles" -Method GET
$partnerRoles.value | Where-Object {
    $_.displayName -like "*Partner*" -or $_.displayName -like "*Tier1*" -or $_.displayName -like "*Tier2*"
} | ForEach-Object {
    $members = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directoryRoles/$($_.id)/members" -Method GET
    [PSCustomObject]@{ Role = $_.displayName; Members = ($members.value | Select-Object -ExpandProperty displayName) -join ", " }
} | Format-Table

# Vérifier aussi via la relation delegatedAdminRelationships
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/tenantRelationships/delegatedAdminRelationships" -Method GET |
    ConvertTo-Json -Depth 3

Remédiation :

Microsoft 365 Admin Center > Paramètres > Relations partenaires
Identifier tous les partenaires avec accès délégué (DAP/GDAP)
Supprimer les relations DAP au profit de GDAP (Granular Delegated Admin Privileges)
Restreindre les rôles GDAP au strict nécessaire (pas de Global Admin)
Activer les notifications d’accès partenaires

Valeur par défaut : Les rôles Partner sont invisibles dans Entra UI et non audités par défaut.

1.5c.3 — Applications avec credentials certificat (bypass potentiel MFA/CA)

Niveau : 🔴 Critique Référence : CIS 5.2.6.x — Automated Licence requise : Entra ID P1

Description : Les applications utilisant des credentials de type certificat ou secret client peuvent s’authentifier directement via OAuth 2.0 sans passer par les politiques de Conditional Access ou le MFA. Si ces applications ont des permissions élevées (Mail.Read, User.ReadWrite.All, etc.), un attaquant qui obtient le certificat ou le secret peut accéder aux données M365 en contournant toutes les protections d’identité. C’est particulièrement critique pour les Service Principals avec des rôles d’annuaire permanents.

Vérification :

# Applications avec credentials certificat ET rôles d'annuaire permanents
$apps = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/applications?`$select=displayName,appId,keyCredentials,passwordCredentials" -Method GET
$apps.value | Where-Object { $_.keyCredentials.Count -gt 0 } | ForEach-Object {
    $roles = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '$($_.appId)'&`$expand=memberOf" -Method GET
    [PSCustomObject]@{
        App = $_.displayName
        KeyCreds = $_.keyCredentials.Count
        DirectoryRoles = ($roles.value[0].memberOf.value | Where-Object { $_.'@odata.type' -eq '#microsoft.graph.directoryRole' } | Select-Object -ExpandProperty displayName) -join ", "
    }
} | Where-Object { $_.DirectoryRoles } | Format-Table

# Maester MT.1057 : apps encore avec secrets (à migrer vers workload identity)
$appsWithSecrets = Get-MgApplication -All | Where-Object { $_.PasswordCredentials.Count -gt 0 }
$appsWithSecrets | Select-Object DisplayName, @{N="SecretExpiry"; E={($_.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime}} | Format-Table

Remédiation :

Migrer vers les Workload Identity Federations (pas de secret/certificat stocké)
Pour les apps devant conserver des credentials : rotation régulière (< 90 jours)
Supprimer les credentials expirés ou inutilisés
Configurer des alertes sur l’expiration via Azure Monitor ou scripts automatisés
Restreindre les permissions de ces apps au strict minimum nécessaire
Activer App Instance Property Lock pour empêcher la modification des credentials

Valeur par défaut : Pas de restriction sur le type de credential — secrets et certificats autorisés par défaut.

1.5c.4 — Managed Identities avec permissions Graph dangereuses

Niveau : 🟠 Élevé Référence : M365-Assess ENTRA-ENTAPP-008/009 — Automated Licence requise : Entra ID P1

Description : Les Managed Identities (identités gérées Azure) sont une excellente pratique pour éviter les secrets, mais si elles se voient attribuer des permissions Graph dangereuses (Mail.Send, User.ReadWrite.All, Files.ReadWrite.All) ou des rôles d’annuaire, elles deviennent un vecteur d’escalade de privilèges depuis Azure vers M365. Une VM Azure ou un Function App compromis pourrait exfiltrer tous les emails ou modifier des comptes utilisateurs.

Vérification :

# Managed Identities avec permissions Graph élevées
$managedIds = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=servicePrincipalType eq 'ManagedIdentity'" -Method GET
foreach ($mi in $managedIds.value) {
    $appRoles = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$($mi.id)/appRoleAssignments" -Method GET
    if ($appRoles.value.Count -gt 0) {
        Write-Host "⚠️ $($mi.displayName)" -ForegroundColor Yellow
        $appRoles.value | ForEach-Object { Write-Host "  → $($_.principalDisplayName) : $($_.resourceDisplayName)" }
    }
}

Remédiation :

Inventorier toutes les Managed Identities et leurs permissions Graph
Supprimer les permissions non justifiées (Mail.Send, Files.ReadWrite.All, User.ReadWrite.All)
Appliquer le principe du moindre privilège — préférer des permissions de lecture
Documenter chaque Managed Identity et son usage légitime
Revue trimestrielle des permissions des Managed Identities

Valeur par défaut : Aucune permission assignée par défaut — mais les admins peuvent en attribuer sans restriction.

1.5c.5 — App registrations : propriétaires sans MFA enregistré

Niveau : 🟠 Élevé Référence : Maester MT.1063 — Automated Licence requise : Entra ID P1

Description : Les propriétaires d’application (App Registration Owners) peuvent modifier les credentials, les permissions et les paramètres d’une application. Si un propriétaire n’a pas de MFA enregistré, son compte peut être compromis via phishing ou credential stuffing, permettant à l’attaquant de modifier l’application pour obtenir des accès supplémentaires.

Vérification :

# App owners sans MFA
$apps = Get-MgApplication -All
foreach ($app in $apps) {
    $owners = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/applications/$($app.Id)/owners" -Method GET
    foreach ($owner in $owners.value) {
        $authMethods = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/users/$($owner.id)/authentication/methods" -Method GET -ErrorAction SilentlyContinue
        $hasMFA = $authMethods.value.Count -gt 1  # Plus que juste le mot de passe
        if (-not $hasMFA) {
            Write-Host "⚠️ App: $($app.DisplayName) — Owner without MFA: $($owner.displayName)" -ForegroundColor Red
        }
    }
}

Remédiation :

Identifier tous les propriétaires d’app registrations sans MFA
Forcer l’enregistrement MFA pour ces utilisateurs
Supprimer les propriétaires inutiles (principe du moindre privilège)
Préférer des groupes de sécurité comme propriétaires plutôt que des individus

Valeur par défaut : Aucune vérification MFA pour les propriétaires d’applications.

1.5c.6 — Workload Identities dormantes — Service Principals inactifs depuis > 90 jours

Niveau : 🟠 Élevé Référence : CIS 5.1.x + M365-Assess ENTRA-ENTAPP — Automated Licence requise : Entra ID P1 (Workload Identities Premium pour surveillance continue)

Description : Les Service Principals (identités de workload) inactifs depuis plus de 90 jours représentent un risque de sécurité : des credentials non révoqués (secrets/certificats) sur des identités abandonnées peuvent être exfiltrés et exploités sans que personne ne le détecte. Ces identités “zombies” sont particulièrement dangereuses car elles disposent souvent de permissions Graph élevées héritées de leur configuration initiale.

Vérification :

# Service Principals avec signInActivity > 90 jours (Workload Identities Premium requis)
$cutoff = (Get-Date).AddDays(-90)
$sps = Get-MgServicePrincipal -All -Property "displayName,appId,signInActivity,keyCredentials,passwordCredentials"
$dormant = $sps | Where-Object {
    $_.SignInActivity.LastSignInDateTime -lt $cutoff -or
    $_.SignInActivity.LastSignInDateTime -eq $null
} | Select-Object DisplayName, AppId, @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}},
    @{N="HasSecrets";E={$_.PasswordCredentials.Count -gt 0}},
    @{N="HasCerts";E={$_.KeyCredentials.Count -gt 0}}
$dormant | Format-Table
# Résultat attendu : Aucun SP actif avec credentials valides et SignIn > 90j

Remédiation :

Pour chaque SP dormant identifié : vérifier l’utilité avec l’équipe propriétaire
Supprimer les credentials (secrets/certificats) des SP non utilisés
Désactiver les SP non utilisés (Update-MgServicePrincipal -ServicePrincipalId <Id> -AccountEnabled:$false)
Supprimer complètement les SP inutiles et leurs app registrations associées
Mettre en place une revue trimestrielle des workload identities via Access Reviews Entra ID
Activer Workload Identities Premium pour la détection continue des comportements anormaux

Valeur par défaut : Aucune détection automatique des SP dormants — les identités inactives conservent leurs permissions et credentials indéfiniment.

1.6 Journalisation et SIEM

1.6.1 — Envoyer les journaux de sécurité Entra ID vers un SIEM

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.4.1v1 Référence : OMB M-21-31

Description : Les journaux Entra ID (connexions, audit, provisionning) doivent être transmis en temps réel vers un SIEM ou un SOC pour la corrélation, la détection et la réponse aux incidents. La rétention native M365 (90 jours standard) est insuffisante pour les investigations d’incidents découverts tarditement. Le NIST et l’OMB M-21-31 exigent 12 mois de rétention active + 18 mois de stockage froid.

Vérification :

Entra ID > Journaux de diagnostic (Diagnostic Settings)
Vérifier qu’une destination est configurée (Log Analytics, Event Hub, Storage Account, SIEM partenaire)

Remédiation :

Entra ID > Surveillance > Paramètres de diagnostic > Ajouter un paramètre de diagnostic
Sélectionner les journaux : SignInLogs, AuditLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, RiskyUsers, UserRiskEvents
Destination : Log Analytics Workspace (Microsoft Sentinel recommandé) ou Event Hub vers SIEM tiers
Durée de rétention Log Analytics : 90 jours minimum, archive 18 mois
Pour conformité OMB M-21-31 : 12 mois actif + 18 mois stockage froid

1.7 Gestion des Invités (Guest Access)

1.7.1 — Restreindre l’accès des invités aux objets de l’annuaire

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.8.1v1

Description : Par défaut, les utilisateurs invités peuvent énumérer les objets de l’annuaire Entra ID (utilisateurs, groupes, applications). Cette capacité peut être utilisée pour de la reconnaissance interne par des comptes invités malveillants ou compromis.

Vérification :

Entra ID > Identités externes > Paramètres de collaboration externe
Vérifier les permissions des utilisateurs invités

Remédiation :

Entra ID > Identités externes > Paramètres de collaboration externe
Autorisations des utilisateurs invités : “Les utilisateurs invités ont un accès limité aux propriétés et appartenances des objets d’annuaire” (ou “L’accès des utilisateurs invités est restreint à…”)
Ne pas utiliser “Les utilisateurs invités ont les mêmes accès que les membres”

1.7.2 — Restreindre qui peut inviter des utilisateurs invités

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.8.2v1

Description : Si n’importe quel utilisateur peut inviter des guests, des invitations non contrôlées peuvent introduire des comptes externes non vérifiés dans le tenant, augmentant la surface d’attaque et les risques de fuite de données.

Vérification :

(Get-MgPolicyAuthorizationPolicy).AllowInvitesFrom

Doit retourner : adminsAndGuestInviters ou adminsOnly

Remédiation :

Entra ID > Identités externes > Paramètres de collaboration externe
“Qui peut inviter des utilisateurs invités” : Administrateurs et utilisateurs ayant le rôle d’inviteur d’invités
Ou : Uniquement les administrateurs (option la plus restrictive)

1.7.3 — Restreindre les invitations aux domaines externes approuvés

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.8.3v1

Description : Sans liste blanche de domaines, des comptes invités peuvent être créés depuis n’importe quel domaine, y compris des domaines créés spécifiquement pour l’attaque. Restreindre aux domaines partenaires connus réduit ce risque.

Vérification :

Entra ID > Identités externes > Paramètres de collaboration externe > Restrictions de collaboration

Remédiation :

Entra ID > Identités externes > Paramètres de collaboration externe
Restrictions de collaboration : “Autoriser les invitations uniquement aux domaines spécifiés”
Ajouter la liste des domaines partenaires approuvés
Révision trimestrielle de la liste des invités actifs

1.8 Gestion des Rôles Privilégiés

1.8.1 — Activer Privileged Identity Management (PIM)

Niveau : 🔴 Critique Référence CIS : CIS Control 5.4 Licence requise : Entra ID P2 MITRE ATT&CK : T1078.004 (Valid Accounts: Cloud) · T1548 (Abuse Elevation Control Mechanism) · T1098 (Account Manipulation)

Description : PIM implémente le principe du Just-In-Time (JIT) : les administrateurs n’ont pas de droits permanents, ils les activent à la demande pour une durée limitée avec justification. Cela réduit drastiquement la fenêtre d’exposition en cas de compromission de compte admin.

Vérification :

Entra ID > Gestion des identités > Privileged Identity Management
Vérifier les rôles configurés en mode “Eligible” vs “Active permanent”
PowerShell :

Get-MgRoleManagementDirectoryRoleAssignment | Where-Object {$_.AssignmentType -eq "Assigned"} | Select-Object PrincipalId, RoleDefinitionId

Remédiation :

Activer PIM pour tous les rôles privilégiés Entra ID
Convertir les assignations permanentes en assignations “Éligibles”
Configurer : durée d’activation max = 4 heures, justification obligatoire, approbation pour rôles critiques
Configurer les alertes PIM (assignations permanentes détectées, activations suspectes)
Rôles prioritaires à protéger : Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator

1.8.2 — Limiter le nombre d’Administrateurs Globaux

Niveau : 🔴 Critique Référence CIS : CIS Control 5.4 MITRE ATT&CK : T1078.004 (Valid Accounts: Cloud) · T1136.003 (Create Account: Cloud) · T1087.004 (Account Discovery: Cloud)

Description : Le rôle Global Administrator est le plus puissant de M365. Plus il y a de personnes avec ce rôle, plus la surface d’attaque est grande. Le CIS recommande entre 2 et 4 Global Admins maximum (pour la redondance sans excès).

Vérification :

Entra ID > Rôles et administrateurs > Administrateur général
PowerShell :

Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id | Select-Object -ExpandProperty AdditionalProperties

Remédiation :

Conserver uniquement 2 à 4 Global Admins maximum
Remplacer le Global Admin par des rôles spécialisés (Exchange Admin, SharePoint Admin, etc.) pour les tâches spécifiques
Utiliser des comptes dédiés “break glass” (comptes d’urgence) distincts des comptes quotidiens
Activer PIM pour le rôle Global Admin

1.8.3 — Utiliser des rôles à granularité fine plutôt que Global Admin

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.7.2v1

Description : Le Global Administrator a accès à TOUT dans le tenant M365. La grande majorité des tâches d’administration peuvent être effectuées avec des rôles spécialisés qui limitent l’impact d’une compromission. Un administrateur Exchange n’a pas besoin d’accéder à SharePoint ou Intune.

Vérification :

# Identifier les utilisateurs avec Global Admin qui pourraient avoir un rôle plus restreint
$gaMembers = Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
$gaMembers | ForEach-Object {
    Get-MgUserAppRoleAssignment -UserId $_.Id
}

Remédiation : Rôles de remplacement recommandés par fonction :

Exchange : Exchange Administrator
SharePoint : SharePoint Administrator
Teams : Teams Administrator
Sécurité : Security Administrator / Security Reader
Utilisateurs : User Administrator
Facturation : Billing Administrator
Intune : Intune Administrator
Conformité : Compliance Administrator

1.8.4 — Provisionner les administrateurs avec des comptes cloud uniquement

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.7.3v1

Description : Les comptes admin synchronisés depuis l’Active Directory on-premises héritent des risques de l’AD : si un DC est compromis, l’attaquant obtient automatiquement les credentials des comptes admin cloud. Les comptes admin cloud-only sont isolés de cette chaîne de compromission.

Vérification :

# Vérifier les admins synchronisés depuis on-prem (OnPremisesSyncEnabled = true)
Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id | ForEach-Object {
    Get-MgUser -UserId $_.Id | Select-Object DisplayName, UserPrincipalName, OnPremisesSyncEnabled
}

Remédiation :

Créer de nouveaux comptes admin directement dans Entra ID (cloud-only)
Format recommandé : adm_prenom.nom@domaine.com (ne pas synchroniser depuis l’AD)
Migrer les assignations de rôles vers ces nouveaux comptes cloud-only
Révoquer les rôles sur les comptes synchronisés

1.8.5 — Exiger une approbation pour l’activation du rôle Global Administrator

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.7.6v1 Licence requise : Entra ID P2 (PIM)

Description : Même avec PIM, l’activation du rôle le plus puissant (Global Admin) ne doit pas être auto-approuvée. Exiger une approbation humaine d’un second administrateur crée un contrôle de validation (“four-eyes principle”) qui ralentit un attaquant ayant compromis un compte éligible.

Vérification :

Entra ID > PIM > Rôles Entra ID > Administrateur général > Paramètres
Vérifier que “Approbation requise” est activé et qu’au moins un approbateur est configuré

Remédiation :

PIM > Rôles Entra ID > Administrateur général > Paramètres du rôle > Modifier
Activation : Exiger l’approbation → Oui
Ajouter des approbateurs (au moins 2 personnes de confiance distinctes)
Durée maximale d’activation : 4 heures

1.8.6 — Configurer des alertes sur les activations de rôles privilégiés

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.AAD.7.7v1, MS.AAD.7.8v1, MS.AAD.7.9v1 Licence requise : Entra ID P2 (PIM)

Description : Toute activation de rôle hautement privilégié doit déclencher une notification immédiate vers le SOC ou le RSSI. Les assignations permanentes de rôles (sans PIM) doivent également déclencher une alerte — elles peuvent indiquer qu’un attaquant a consolidé un accès persistant.

Vérification :

PIM > Rôles Entra ID > Alertes > Vérifier les alertes configurées
Vérifier que les notifications email sont configurées pour chaque rôle critique

Remédiation :

PIM > Rôles Entra ID > Alertes PIM : activer toutes les alertes disponibles
PIM > Chaque rôle critique > Paramètres > Notifications : configurer l’email du SOC/RSSI pour activation et assignation
Rôles prioritaires pour alertes : Global Admin, Privileged Role Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin
Créer des règles d’alerte Microsoft Sentinel (ou SIEM) pour corréler avec d’autres activités suspectes

1.8.7 — Créer des comptes d’urgence (Break Glass Accounts)

Niveau : 🔴 Critique Référence CIS : CIS Control 5.4 MITRE ATT&CK : T1078.004 (Valid Accounts: Cloud) · T1098.001 (Account Manipulation: Additional Cloud Credentials) · T1556 (Modify Authentication Process)

Description : Les comptes d’urgence permettent de récupérer l’accès au tenant en cas de panne MFA, de problème avec les politiques CA, ou de compromission des comptes admin normaux. Sans ces comptes, l’organisation risque d’être bloquée hors de son propre tenant.

Vérification :

Vérifier l’existence de 2 comptes d’urgence avec le rôle Global Admin
Vérifier qu’ils sont exclus de TOUTES les politiques CA (y compris MFA)
Vérifier qu’ils utilisent des mots de passe complexes stockés dans un coffre-fort physique
Vérifier la surveillance des connexions sur ces comptes (alerte immédiate si utilisés)

Remédiation :

Créer 2 comptes type : breakglass01@domaine.com et breakglass02@domaine.com
Mots de passe aléatoires de 32+ caractères, imprimés et stockés en coffre-fort physique
Exclure ces comptes de TOUTES les politiques CA
Créer une alerte : toute connexion sur ces comptes = notification immédiate SOC/RSSI
Tester trimestriellement que ces comptes fonctionnent
Ne jamais utiliser pour les tâches quotidiennes

1.8.8 — Utiliser des comptes admin dédiés (sans messagerie)

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.4

Description : Les comptes administrateurs ne doivent pas recevoir d’emails. Un admin qui lit ses emails depuis son compte admin peut être victime de phishing, et si le compte admin est compromis via phishing, l’attaquant a directement accès aux privilèges admin. Les comptes admin doivent être distincts des comptes utilisateur quotidiens.

Vérification :

Vérifier que les comptes admin n’ont pas de boîte mail active ou de licence Exchange
Vérifier que les admins utilisent des comptes séparés pour les tâches admin vs quotidiennes

Remédiation :

Créer des comptes admin avec convention de nommage distincte (ex: adm_prenom.nom@domaine.com)
Ne pas assigner de licence Exchange/M365 aux comptes admin purs
Utiliser un compte utilisateur standard pour la messagerie et naviguer, un compte admin pour les tâches d’administration
Former les administrateurs à utiliser des navigateurs séparés ou profils distincts

1.8.9 — Activer les révisions d’accès pour les utilisateurs invités (Guests)

Niveau : 🟠 Élevé Référence CIS : 5.3.2 (L2) — Automated Profile : E3 Level 2 Licence requise : Entra ID P2

Description : Au-delà des révisions d’accès pour les rôles admin, les comptes invités doivent faire l’objet de révisions régulières. Les invités sont souvent des prestataires, partenaires ou anciens collaborateurs dont l’accès n’est plus justifié mais n’a jamais été révoqué. Chaque invité actif est un risque potentiel.

Vérification :

Entra ID > Gestion des identités > Révisions d’accès
Vérifier l’existence de révisions ciblant le groupe dynamique des guests

Remédiation :

Créer une révision d’accès trimestrielle pour le groupe dynamique “Tous les invités”
Réviseurs : responsables métier ou sponsoring managers des invités
Paramètre : si non répondu dans 30 jours → supprimer l’accès automatiquement
Exiger une justification pour conserver l’accès

1.8.10 — Exiger une approbation pour l’activation du rôle Privileged Role Administrator

Niveau : 🔴 Critique Référence CIS : 5.3.5 (L1) — Automated Profile : E3 Level 1 Licence requise : Entra ID P2 (PIM)

Description : Le rôle “Privileged Role Administrator” permet de modifier les attributions de rôles PIM elles-mêmes — c’est le “roi des rois” en termes de persistance : un attaquant obtenant ce rôle peut s’octroyer n’importe quel autre rôle. Il doit donc être traité avec le même niveau de contrôle que le Global Administrator.

Vérification :

PIM > Rôles Entra ID > Administrateur de rôles privilégiés > Paramètres
Vérifier que “Approbation requise” est activé

Remédiation :

PIM > Rôles Entra ID > Administrateur de rôles privilégiés > Paramètres du rôle > Modifier
Approbation requise pour activation : Oui
Approbateurs : au moins 2 Global Admins distincts
Durée maximale d’activation : 2 heures

1.8.11 — Activer les révisions d’accès (Access Reviews) pour les rôles admin

Niveau : 🟠 Élevé Référence CIS : CIS Control 5.4 Licence requise : Entra ID P2

Description : Les droits d’administration s’accumulent avec le temps (privilege creep). Les Access Reviews permettent une révision périodique des assignations de rôles pour s’assurer que seuls les utilisateurs légitimes conservent leurs droits.

Vérification :

Entra ID > Gestion des identités > Révisions d’accès
Vérifier l’existence de révisions programmées pour les rôles admin

Remédiation :

Créer des révisions d’accès trimestrielles pour tous les rôles admin
Désignation des réviseurs : managers directs ou RSSI
Paramètre : si le réviseur ne répond pas dans le délai → supprimer l’accès automatiquement
Révision annuelle pour les utilisateurs standards sur les applications sensibles

1.8.12 — Détecter les comptes administrateurs inactifs depuis plus de 90 jours

Niveau : 🟠 Élevé Référence : M365-Assess ENTRA-STALEADMIN-001 — Automated Licence requise : Entra ID P1

Description : Les comptes administrateurs inactifs depuis plus de 90 jours représentent un risque élevé : ils sont souvent liés à des anciens employés, des comptes de service abandonnés ou des comptes créés temporairement et jamais désactivés. Un attaquant qui obtient ces credentials (breach, dark web) accède directement à des rôles élevés sans déclencher d’alerte comportementale.

Vérification :

# Admins inactifs depuis plus de 90 jours
$threshold = (Get-Date).AddDays(-90)
$adminRoles = Get-MgDirectoryRole
foreach ($role in $adminRoles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All
    foreach ($member in $members) {
        $user = Get-MgUser -UserId $member.Id -Property "displayName,userPrincipalName,signInActivity" -ErrorAction SilentlyContinue
        if ($user -and $user.SignInActivity.LastSignInDateTime -lt $threshold) {
            [PSCustomObject]@{
                Role = $role.DisplayName
                User = $user.DisplayName
                UPN  = $user.UserPrincipalName
                LastSignIn = $user.SignInActivity.LastSignInDateTime
            }
        }
    }
} | Format-Table

Remédiation :

Désactiver immédiatement les comptes admins sans connexion depuis > 90 jours
Révoquer les sessions actives : Revoke-MgUserSignInSession -UserId <id>
Déplacer les comptes suspects dans un groupe de quarantaine avant suppression
Implémenter un processus offboarding qui inclut la révocation des rôles admin
Configurer une alerte automatique mensuelle sur les admins inactifs

Valeur par défaut : Aucune alerte sur l’inactivité des comptes admin.

1.8.13 — Vérifier que les administrateurs privilégiés ne sont pas exclus des politiques CA critiques

Niveau : 🔴 Critique Référence : M365-Assess CA-EXCLUSION-001 + Maester MT.1036 — Automated Licence requise : Entra ID P1

Description : Les politiques de Conditional Access contiennent souvent des exclusions (comptes de service, comptes d’urgence). Si des administrateurs privilégiés ou des groupes admin se retrouvent dans les exclusions de politiques CA critiques (MFA, blocage auth legacy, conformité appareil), ces comptes peuvent contourner toutes les protections. C’est l’une des failles les plus fréquemment exploitées lors d’incidents M365.

Vérification :

# Vérifier les exclusions dans les politiques CA critiques
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
foreach ($policy in $caPolicies) {
    $excludedUsers = $policy.Conditions.Users.ExcludeUsers
    $excludedGroups = $policy.Conditions.Users.ExcludeGroups
    if ($excludedUsers.Count -gt 0 -or $excludedGroups.Count -gt 0) {
        # Vérifier si des admins privilégiés sont dans les exclusions
        foreach ($userId in $excludedUsers) {
            $user = Get-MgUser -UserId $userId -ErrorAction SilentlyContinue
            $adminRoles = Get-MgUserMemberOf -UserId $userId | Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.directoryRole' }
            if ($adminRoles) {
                Write-Host "⚠️ CRITICAL: Admin user $($user.DisplayName) excluded from policy: $($policy.DisplayName)" -ForegroundColor Red
            }
        }
    }
}

Remédiation :

Revoir toutes les exclusions des politiques CA — enlever les comptes admin non justifiés
Les exclusions doivent se limiter aux comptes Break Glass et aux comptes de service documentés
S’assurer que les exclusions sont temporaires et révisées mensuellement
Documenter chaque exclusion avec sa justification et sa date d’expiration
Utiliser les noms de groupes plutôt que des utilisateurs individuels pour faciliter l’audit

Valeur par défaut : Aucune validation automatique des exclusions CA.

1.8.14 — Détecter les comptes AD synchronisés dans des rôles cloud privilégiés

Niveau : 🔴 Critique Référence : CIS 5.4.x + M365-Assess ENTRA-SYNCADMIN-001 — Automated Licence requise : Entra ID P1

Description : Les comptes synchronisés depuis l’Active Directory on-premises ne doivent jamais avoir de rôles cloud privilégiés. Si le compte AD on-prem est compromis (ransomware, DC compromise, GPO malveillante), l’attaquant hérite automatiquement des rôles cloud. La règle absolue : les admins cloud doivent être des comptes cloud-only. C’est le chemin d’attaque AD → M365 le plus fréquent en 2026.

Vérification :

# Comptes synchros avec rôles cloud privilégiés — vecteur critique
$adminRoles = Get-MgDirectoryRole
$syncedAdmins = @()
foreach ($role in $adminRoles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All
    foreach ($member in $members) {
        $user = Get-MgUser -UserId $member.Id -Property "displayName,userPrincipalName,onPremisesSyncEnabled" -ErrorAction SilentlyContinue
        if ($user -and $user.OnPremisesSyncEnabled -eq $true) {
            $syncedAdmins += [PSCustomObject]@{
                Role = $role.DisplayName
                User = $user.DisplayName
                UPN  = $user.UserPrincipalName
                OnPremSync = $true
            }
        }
    }
}
$syncedAdmins | Format-Table
# Résultat attendu : Aucun résultat

Remédiation :

Créer des comptes cloud-only dédiés pour chaque admin ayant un compte synchro
Transférer les rôles admin cloud vers les comptes cloud-only
Supprimer les rôles cloud des comptes synchros
Désactiver les comptes synchros dans Entra ID (conserver pour accès on-prem uniquement)
Configurer une alerte sur toute future assignation de rôle cloud à un compte synchro

Valeur par défaut : Aucune restriction — les comptes synchros peuvent avoir des rôles cloud.

1.8.15 — Enforcer l’authentification Passwordless (FIDO2 / Windows Hello for Business) pour les comptes privilégiés

Niveau : 🔴 Critique Référence CISA SCuBA : MS.AAD.3.6v1 + MS.AAD.3.8v1 — Manual Licence requise : Entra ID P1 + Entra ID P2 (recommandé)

Description : L’authentification passwordless (FIDO2, Windows Hello for Business, Microsoft Authenticator Passwordless) élimine les risques liés aux mots de passe : credential stuffing, phishing, password spray. Pour les comptes privilégiés, c’est le niveau de protection le plus élevé recommandé par CISA en 2026. Les méthodes classiques MFA (OTP, SMS, Authenticator push) restent vulnérables aux attaques de type AiTM (Adversary-in-The-Middle). Le passwordless élimine ce vecteur car il n’y a pas de secret partageable.

Vérification :

# Vérifier les méthodes d'authentification des admins — identifier ceux sans Passwordless
$adminRoles = Get-MgDirectoryRole | Where-Object { $_.DisplayName -match "Administrator" }
foreach ($role in $adminRoles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All
    foreach ($member in $members) {
        $methods = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/users/$($member.Id)/authentication/methods" -Method GET -ErrorAction SilentlyContinue
        $hasPasswordless = $methods.value | Where-Object {
            $_.'@odata.type' -match "fido2|microsoftAuthenticatorAuthentication|windowsHelloForBusiness"
        }
        if (-not $hasPasswordless) {
            Write-Host "⚠️ Admin sans Passwordless: $($member.AdditionalProperties.displayName) — Role: $($role.DisplayName)" -ForegroundColor Red
        }
    }
}

Remédiation :

Entra ID > Protection > Méthodes d’authentification > Politiques
Activer FIDO2 Security Keys pour les comptes admin (Microsoft.Graph.Identity.SignIns)
Créer une politique CA : Admins privilégiés → Exiger auth résistante au phishing (FIDO2/WHfB)
Déployer des clés FIDO2 physiques (YubiKey, Feitian) pour les Global Admins et les comptes Break Glass
Former les administrateurs à l’usage des clés FIDO2 et WHfB
Supprimer les méthodes SMS et appel vocal pour les comptes admin via la politique de méthodes d’auth

Valeur par défaut : Aucune exigence Passwordless — les admins peuvent utiliser des méthodes MFA traditionnelles vulnérables au phishing AiTM.

1.9 Groupes, Appareils et Paramètres Avancés

1.9.1 — Créer un groupe dynamique pour les utilisateurs invités

Niveau : 🟠 Élevé Référence CIS : CIS 5.1.3.1 (L1) — Automated Profile : E3 Level 1

Description : Un groupe dynamique Entra ID avec la règle (user.userType -eq "Guest") permet d’appliquer automatiquement des politiques d’accès conditionnel, des restrictions et des contrôles de sécurité à tous les invités actuels et futurs. Sans ce groupe, les nouveaux comptes invités peuvent temporairement échapper aux contrôles de sécurité.

Vérification :

Connect-MgGraph -Scopes "Group.Read.All"
$groups = Get-MgGroup -All | Where-Object { $_.GroupTypes -contains "DynamicMembership" }
$groups | Where-Object { $_.MembershipRule -match "userType" } | ft DisplayName, MembershipRule

Vérifier qu’un groupe existe avec la règle (user.userType -eq "Guest").

Remédiation :

$params = @{
    DisplayName = "Dynamic Guest Group"
    MailNickname = "DynGuestUsers"
    MailEnabled = $false
    SecurityEnabled = $true
    GroupTypes = @("DynamicMembership")
    MembershipRule = '(user.userType -eq "Guest")'
    MembershipRuleProcessingState = "On"
}
New-MgGroup @params

Utiliser ce groupe dans les politiques d’Accès Conditionnel ciblant les invités.

1.9.2 — Désactiver la création de groupes de sécurité par les utilisateurs

Niveau : 🟠 Élevé Référence CIS : CIS 5.1.3.2 (L1) — Automated Profile : E3 Level 1

Description : Par défaut, tous les utilisateurs peuvent créer des groupes de sécurité dans Azure Portal, l’API ou PowerShell. Cela peut conduire à une prolifération incontrôlée de groupes et à des escalades de privilèges si ces groupes sont ensuite utilisés pour gérer des accès.

Vérification :

(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object AllowedToCreateSecurityGroups
# Valeur attendue : False

Remédiation :

$params = @{
    defaultUserRolePermissions = @{
        AllowedToCreateSecurityGroups = $false
    }
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Ou via Entra ID > Groupes > Paramètres généraux : “Les utilisateurs peuvent créer des groupes de sécurité dans les portails Azure” → Non.

1.9.3 — Limiter le nombre maximum d’appareils par utilisateur (≤ 20)

Niveau : 🟠 Élevé Référence CIS : CIS 5.1.4.2 (L1) — Automated Profile : E3 Level 1

Description : Cette limite définit le nombre maximum d’appareils qu’un utilisateur peut inscrire dans Entra ID. Un quota élevé (défaut : 50) permet à un attaquant ayant compromis un compte d’inscrire de multiples appareils pour établir de la persistance. Microsoft recommande ≤ 20 appareils par utilisateur.

Vérification :

$Uri = "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy"
(Invoke-MgGraphRequest -Method GET -Uri $Uri).userDeviceQuota
# Valeur attendue : ≤ 20

Remédiation :

Entra ID > Appareils > Paramètres des appareils
“Nombre maximum d’appareils par utilisateur” → 20 (ou moins)

1.9.4 — Ne pas ajouter le Global Administrator comme admin local lors de la jointure Entra

Niveau : 🔴 Critique Référence CIS : CIS 5.1.4.3 (L1) — Automated Profile : E3 Level 1

Description : Par défaut, le rôle Global Administrator est ajouté automatiquement au groupe des administrateurs locaux lors de la jointure Entra. Cela viole le principe du moindre privilège — les GA ont alors un accès admin local sur tous les appareils joints, ce qui crée un vecteur latéral majeur.

Vérification :

$Uri = "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy"
(Invoke-MgGraphRequest -Method GET -Uri $Uri).azureADJoin.localAdmins
# Valeur attendue : enableGlobalAdmins = False

Remédiation :

Entra ID > Appareils > Paramètres des appareils
“Le rôle Global Administrator est ajouté comme administrateur local lors de la jointure Microsoft Entra” → Non

1.9.5 — Restreindre la jointure d’appareils à Entra ID

Niveau : 🟡 Moyen Référence CIS : CIS 5.1.4.1 (L2) — Automated Profile : E3 Level 2

Description : Par défaut, tous les utilisateurs peuvent joindre leurs appareils à Entra ID. Un attaquant ayant compromis un compte standard peut inscrire un appareil malveillant qui hérite des politiques MDM et semble conforme, obtenant ainsi un accès persistant aux ressources cloud sans déclencher de MFA.

Vérification :

$Uri = "https://graph.microsoft.com/beta/policies/deviceRegistrationPolicy"
(Invoke-MgGraphRequest -Method GET -Uri $Uri).azureADJoin.allowedToJoin
# Type attendu : #microsoft.graph.enumeratedDeviceRegistrationMembership (Sélectionné) ou #microsoft.graph.noDeviceRegistrationMembership (Aucun)

Remédiation :

Entra ID > Appareils > Paramètres des appareils
“Les utilisateurs peuvent joindre des appareils à Microsoft Entra” → Sélectionné (définir un groupe autorisé) ou Aucun

1.9.6 — Masquer l’option “Rester connecté” (Stay signed in)

Niveau : 🟡 Moyen Référence CIS : CIS 5.1.2.5 (L2) — Manual Profile : E3 Level 2

Description : L’option “Rester connecté” crée un jeton d’actualisation persistant de 90 jours. Sur un ordinateur partagé ou public, cela permet à tout utilisateur suivant d’accéder aux données M365 sans authentification. Cette option doit être masquée pour tous les utilisateurs.

Vérification :

Entra ID > Entreprise > Paramètres utilisateur
“Afficher l’option Maintenir la connexion” → Non

Remédiation :

Entra ID Admin Center > Identité > Marque de société
Sélectionner votre configuration de marque
“Afficher l’option permettre aux utilisateurs de rester connectés” → Non
Sauvegarder

1.9.7 — Désactiver les connexions de compte LinkedIn

Niveau : 🟡 Moyen Référence CIS : CIS 5.1.2.6 (L2) — Manual Profile : E3 Level 2

Description : L’intégration LinkedIn permet aux utilisateurs de connecter leur compte professionnel Microsoft avec LinkedIn. Cela expose des informations organisationnelles (contacts, organigrammes) à un réseau social externe et peut faciliter des attaques de spear-phishing ciblées.

Vérification :

Entra ID > Utilisateurs > Paramètres utilisateur
“Connexions de compte LinkedIn” → Non

Remédiation :

Entra ID Admin Center > Identité > Utilisateurs > Paramètres utilisateur
“Les utilisateurs peuvent connecter leur compte professionnel ou scolaire avec LinkedIn” → Non
Sauvegarder

1.10 Cross-Tenant Access, Tenant Restrictions et Évaluation Continue des Accès (CAE)

1.10.1 — Configurer les paramètres d’accès cross-tenant (XTAP)

Niveau : 🟠 Élevé Référence CIS : CIS 5.1.5.1 (L1) — Manual Profile : E3 Level 1 Licence requise : Entra ID P1

Description : Les paramètres d’accès cross-tenant (Cross-Tenant Access Policies — XTAP) contrôlent comment les utilisateurs de votre tenant interagissent avec d’autres organisations Entra ID, et réciproquement. Par défaut, tous les accès B2B entre tenants sont autorisés sans restriction. Une mauvaise configuration permet à des utilisateurs externes non approuvés d’accéder à vos ressources ou à vos utilisateurs d’exfiltrer des données vers des tenants non contrôlés.

Vérification :

# Vérifier la politique par défaut cross-tenant
$policy = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy" -Method GET
$policy | ConvertTo-Json -Depth 5

# Vérifier les politiques spécifiques par organisation partenaire
$partners = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners" -Method GET
$partners.value | Select-Object tenantId, displayName | Format-Table

Vérifier que la politique par défaut est restrictive (inboundTrust, b2bCollaborationInbound/Outbound configurés).

Remédiation :

Entra ID > Identités externes > Paramètres d’accès cross-tenant
Paramètres par défaut : Configurer pour bloquer toute collaboration B2B par défaut
Paramètres inbounds : Bloquer tous les utilisateurs externes sauf exceptions autorisées
Paramètres outbounds : Restreindre les applications accessibles depuis l’extérieur
Créer des politiques spécifiques pour les partenaires de confiance uniquement
Activer l’authentification multi-facteurs de confiance pour les partenaires spécifiques (MFA trust)

Valeur par défaut : Toutes les collaborations B2B sont autorisées par défaut.

1.10.2 — Implémenter les Tenant Restrictions v2 (TRv2)

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.AAD.7.x — Manual Profile : E3 Level 1 Licence requise : Entra ID P1 + proxy réseau ou Windows 11 intégré

Description : Les Tenant Restrictions v2 (TRv2) empêchent les utilisateurs d’accéder à des tenants M365 non autorisés depuis les appareils ou réseaux de l’organisation. C’est une défense critique contre l’exfiltration de données via des tenants personnels ou non approuvés. Un utilisateur pourrait créer un tenant gratuit et y transférer des données sensibles — TRv2 bloque cette technique.

Vérification :

# Vérifier la politique de restriction de tenant
$policy = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default" -Method GET
$policy.tenantRestrictions | ConvertTo-Json

# Pour Windows 11 : vérifier via registre (à exécuter sur les postes de travail)
# HKLM\SOFTWARE\Policies\Microsoft\Windows\TenantRestrictions

Remédiation :

Entra ID > Identités externes > Paramètres d’accès cross-tenant > Paramètres par défaut > Restrictions de tenant
Activer les restrictions de tenant et définir les tenants autorisés
Pour les appareils Windows 11 : configurer via Intune la stratégie TRv2 (Global Secure Access ou proxy)
Pour les environnements avec proxy : injecter les en-têtes Restrict-Access-To-Tenants et Restrict-Access-Context
Utiliser Microsoft Entra Global Secure Access si disponible

Valeur par défaut : Aucune restriction de tenant configurée — les utilisateurs peuvent accéder à n’importe quel tenant.

1.10.3 — Activer l’Évaluation Continue des Accès (CAE)

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.AAD.6.x — Automated Profile : E3 Level 1 Licence requise : Entra ID P1

Description : L’Évaluation Continue des Accès (CAE — Continuous Access Evaluation) permet à Entra ID de révoquer en temps quasi-réel les tokens d’accès lorsqu’un événement critique se produit (désactivation de compte, réinitialisation de mot de passe, modification de risque). Sans CAE, un token valide peut être utilisé pendant jusqu’à 1 heure même si le compte a été compromis et désactivé entre-temps. CAE réduit cette fenêtre à quelques secondes/minutes.

Vérification :

# Vérifier l'état de CAE
$caePolicy = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/continuousAccessEvaluationPolicy" -Method GET
$caePolicy | ConvertTo-Json

# Résultat attendu : migrationState = "migrationComplete" ou isEnabled = $true

Portail Entra ID > Protection > Évaluation continue des accès

Remédiation :

Entra ID > Protection > Évaluation continue des accès
Activer CAE pour l’ensemble du tenant (migration vers le mode “Tous les utilisateurs”)
Vérifier que les applications clés supportent CAE (Exchange Online, SharePoint, Teams — supportés nativement)
Configurer les politiques CA avec le mode “Strict Location Enforcement” si nécessaire
PowerShell :

$params = @{
    isEnabled = $true
}
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/continuousAccessEvaluationPolicy" -Method PATCH -Body ($params | ConvertTo-Json)

Valeur par défaut : CAE activé en mode migration partielle — à forcer en mode complet.

1.10.4 — Auditer les accès B2B et réaliser des Access Reviews régulières

Niveau : 🟡 Moyen Référence CIS : CIS 5.1.8.1 (L2) — Manual Profile : E3 Level 2 Licence requise : Entra ID P2

Description : Les utilisateurs invités (B2B) accumulent souvent des accès non nécessaires au fil du temps. Sans revues périodiques, des anciens partenaires, prestataires ou collaborateurs temporaires conservent des accès indéfiniment. Les Access Reviews automatisent ce processus de certification et révocation périodique des accès.

Vérification :

# Lister les Access Reviews actives
$reviews = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/accessReviews/definitions" -Method GET
$reviews.value | Select-Object displayName, status, createdDateTime | Format-Table

# Compter les utilisateurs invités actifs
(Get-MgUser -Filter "userType eq 'Guest'" -All).Count

Remédiation :

Entra ID > Gouvernance des identités > Access Reviews > Nouvelle révision d’accès
Configurer une révision trimestrielle de tous les utilisateurs invités
Assigner les réviseurs (managers des sponsors ou groupe d’administration)
Activer la révocation automatique si non réponse dans le délai (auto-apply)
Configurer une politique d’expiration pour les comptes invités inactifs depuis 90 jours

Valeur par défaut : Aucune Access Review configurée — les accès invités ne sont jamais révisés.

SECTION 1.11 — GOUVERNANCE DES DROITS (ENTITLEMENT MANAGEMENT)

Contexte : La gouvernance des droits (Entra ID Entitlement Management) est l’une des surfaces d’attaque les plus négligées. Des access packages avec des rôles supprimés, des groupes inexistants ou des approbateurs invalides créent des voies d’escalade silencieuses. Maester (MT.1106–1110) est le seul outil à automatiser ces vérifications.

1.11 Gestion des Access Packages et Catalogues

1.11.1 — Auditer les ressources d’access packages avec rôles obsolètes

Niveau : 🟠 Élevé Référence : Maester MT.1106 — Automated Licence requise : Entra ID P2 (Governance)

Description : Les access packages peuvent référencer des rôles d’applications qui ont été supprimés ou des Service Principals qui n’existent plus. Ces références fantômes créent des incohérences dans la gouvernance des droits et peuvent masquer des accès non révoqués.

Vérification :

# Vérifier les ressources de catalogues avec des rôles invalides
$catalogs = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/catalogs" -Method GET
foreach ($catalog in $catalogs.value) {
    $resources = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/catalogs/$($catalog.id)/resources?`$expand=roles" -Method GET
    $resources.value | Where-Object { $_.roles.Count -eq 0 } | ForEach-Object {
        Write-Host "⚠️ Catalog: $($catalog.displayName) — Resource sans rôles: $($_.displayName)" -ForegroundColor Yellow
    }
}

Remédiation :

Entra ID > Gouvernance des identités > Gestion des droits > Catalogues
Identifier les ressources sans rôles ou avec des rôles supprimés
Supprimer les ressources invalides des catalogues
Mettre à jour les access packages affectés

Valeur par défaut : Aucune validation automatique des ressources — les rôles supprimés restent référencés.

1.11.2 — Détecter les access packages référençant des groupes supprimés

Niveau : 🟠 Élevé Référence : Maester MT.1107 — Automated Licence requise : Entra ID P2

Description : Les access packages peuvent référencer des groupes de sécurité ou M365 qui ont été supprimés. Quand un utilisateur reçoit un access package avec un groupe supprimé, l’assignation échoue silencieusement — l’utilisateur pense avoir les droits mais ne les a pas, ou inversement, les droits restent assignés sans le groupe de contrôle.

Vérification :

# Détecter les groupes supprimés dans les access packages
$accessPackages = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages?`$expand=resourceRoleScopes" -Method GET
foreach ($pkg in $accessPackages.value) {
    foreach ($rrs in $pkg.resourceRoleScopes) {
        $resourceId = $rrs.resourceRole.resource.id
        $group = Get-MgGroup -GroupId $resourceId -ErrorAction SilentlyContinue
        if (-not $group) {
            Write-Host "⚠️ Access Package '$($pkg.displayName)' — Groupe supprimé: $resourceId" -ForegroundColor Red
        }
    }
}

Remédiation :

Identifier tous les access packages avec des groupes supprimés
Supprimer les références invalides
Recréer les groupes si nécessaire ou remplacer par des groupes existants
Révoquer et réassigner les droits aux utilisateurs concernés

Valeur par défaut : Pas de validation — les groupes supprimés restent dans les access packages.

1.11.3 — Identifier les politiques d’access packages inactives ou orphelines

Niveau : 🟡 Moyen Référence : Maester MT.1108 — Automated Licence requise : Entra ID P2

Description : Des politiques d’assignation d’access packages peuvent devenir “orphelines” si les conditions de déclenchement ne sont plus valides (groupe de portée supprimé, politique expirée). Ces politiques peuvent créer des assignations inattendues ou bloquer des demandes légitimes.

Vérification :

$assignments = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies" -Method GET
$assignments.value | Where-Object { $_.status -eq "inactive" -or $_.status -eq "disabled" } |
    Select-Object displayName, status, createdDateTime | Format-Table

Remédiation :

Désactiver et supprimer les politiques inactives sans assignations actives
Documenter les politiques légitimement désactivées (maintenance planifiée)
Révision semestrielle de toutes les politiques d’access packages

Valeur par défaut : Politiques inactives conservées indéfiniment.

1.11.4 — Valider les approbateurs des workflows d’access packages

Niveau : 🟠 Élevé Référence : Maester MT.1109 — Automated Licence requise : Entra ID P2

Description : Les workflows d’approbation des access packages peuvent référencer des utilisateurs qui ont quitté l’organisation ou dont le compte a été supprimé. Si l’approbateur n’existe plus, les demandes d’accès restent en attente indéfiniment ou passent sans approbation réelle.

Vérification :

# Vérifier les approbateurs valides dans les politiques d'access packages
$policies = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies?`$expand=requestApprovalSettings" -Method GET
foreach ($policy in $policies.value) {
    if ($policy.requestApprovalSettings.approvalStages) {
        foreach ($stage in $policy.requestApprovalSettings.approvalStages) {
            foreach ($approver in $stage.primaryApprovers) {
                if ($approver.objectType -eq "User") {
                    $user = Get-MgUser -UserId $approver.id -ErrorAction SilentlyContinue
                    if (-not $user -or $user.AccountEnabled -eq $false) {
                        Write-Host "⚠️ Policy: $($policy.displayName) — Approbateur invalide: $($approver.id)" -ForegroundColor Red
                    }
                }
            }
        }
    }
}

Remédiation :

Identifier toutes les politiques avec des approbateurs invalides
Remplacer les approbateurs inexistants par des utilisateurs actifs
Préférer des groupes de sécurité comme approbateurs (plutôt que des individus)
Alerte automatique sur la désactivation d’un compte approbateur

Valeur par défaut : Aucune validation des approbateurs — les workflows peuvent bloquer silencieusement.

1.11.5 — Détecter les catalogues sans access packages associés

Niveau : 🟢 Faible Référence : Maester MT.1110 — Automated Licence requise : Entra ID P2

Description : Des catalogues contenant des ressources mais sans access packages associés représentent des ressources “flottantes” qui ne peuvent pas être attribuées via le processus officiel de gouvernance. Ces ressources peuvent soit être des reliquats de configuration, soit des ressources qui devraient être accessibles mais ne le sont pas.

Vérification :

$catalogs = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/catalogs" -Method GET
foreach ($catalog in $catalogs.value) {
    $packages = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages?`$filter=catalog/id eq '$($catalog.id)'" -Method GET
    if ($packages.value.Count -eq 0) {
        $resources = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/catalogs/$($catalog.id)/resources" -Method GET
        if ($resources.value.Count -gt 0) {
            Write-Host "⚠️ Catalogue '$($catalog.displayName)' a $($resources.value.Count) ressources mais aucun access package" -ForegroundColor Yellow
        }
    }
}

Remédiation :

Créer des access packages pour les ressources dans des catalogues vides
Ou supprimer les ressources non gouvernées de ces catalogues
Supprimer les catalogues vides inutiles

Valeur par défaut : Aucune alerte — les catalogues sans access packages sont ignorés.

1.12 Protection des Tokens et Sessions Avancées

1.12.1 — Activer la Protection des Tokens (Token Protection) pour Exchange, SharePoint et Teams

Niveau : 🔴 Critique Référence : Entra ID P2 — CISA Phishing-resistant guidance Licence requise : Entra ID P2 + appareils Entra Joined

Description : La protection des tokens (Token Protection / Token Binding) lie cryptographiquement le token d’accès à l’appareil qui l’a obtenu. Sans cette protection, un attaquant ayant volé un access token (via AiTM, memory injection ou exfiltration réseau) peut le rejouer depuis n’importe quel autre appareil — c’est l’attaque Pass-the-Token. Avec Token Protection activé dans une politique CA, le token devient inutilisable en dehors de l’appareil d’origine car il est lié à la clé TPM.

Vérification :

# Vérifier les politiques CA avec Token Protection activé
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$tokenProtected = $caPolicies | Where-Object {
    ($_.SessionControls | ConvertTo-Json -Depth 5) -match "tokenProtection|primaryRefreshToken"
}
if ($tokenProtected) {
    Write-Host "✅ Token Protection configuré : $($tokenProtected.DisplayName)" -ForegroundColor Green
} else {
    Write-Host "❌ Aucune politique CA avec Token Protection" -ForegroundColor Red
}
# Portail : Entra ID > Protection > Accès Conditionnel > créer politique > Session > Token Protection = Activé

Remédiation :

Créer une politique CA : Applications cloud → Exchange Online, SharePoint Online, Teams
Session > Protection des tokens = Activé
Conditions : Appareils joints Entra ID ou conformes (requis pour le binding TPM)
Exclure les appareils sans TPM (anciens postes) en phase de déploiement progressif
Prioriser pour les comptes admin et utilisateurs sensibles en premier

Valeur par défaut : Token Protection désactivé — les tokens peuvent être rejoués depuis n’importe quel appareil.

1.12.2 — Activer les Actions Protégées (Protected Actions) pour les opérations Entra critiques

Niveau : 🔴 Critique Référence : Entra ID P2 Licence requise : Entra ID P2

Description : Les Actions Protégées (Protected Actions) exigent une ré-authentification fraîche (step-up MFA) avant d’exécuter des opérations Entra ID particulièrement sensibles, même si l’administrateur est déjà connecté avec une session valide. Un attaquant avec un token admin volé ne peut pas supprimer une politique CA, modifier les paramètres d’authentification ou assigner un rôle permanent sans déclencher un nouveau challenge MFA résistant au phishing.

Actions prioritaires à protéger : suppression de politiques CA, modification des paramètres fédérés, assignation de rôles permanents, modification de la liste des mots de passe interdits.

Vérification :

# Vérifier les actions protégées configurées dans les niveaux d'authentification
$authStrengths = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" -Method GET
$authStrengths.value | Select-Object displayName, policyType | Format-Table
# Via portail : Entra ID Admin Center > Protection > Actions protégées
# Vérifier que les opérations critiques nécessitent une force d'authentification phishing-resistant

Remédiation :

Entra ID Admin Center > Protection > Actions protégées
Créer un groupe d’actions protégées : sélectionner les opérations critiques
Assigner la force d’authentification “Phishing-resistant MFA” (FIDO2 / Certificate-based)
Actions prioritaires à protéger :
- Supprimer une politique d’accès conditionnel
- Modifier les paramètres d’autorisation
- Assigner des rôles PIM permanents
- Modifier la fédération d’identité
Tester que la ré-authentification step-up est bien déclenchée

Valeur par défaut : Aucune action protégée configurée — les opérations sensibles n’exigent pas de step-up auth.

1.13 Global Secure Access (Microsoft Entra Internet/Private Access)

1.13.1 — Déployer Microsoft Entra Internet Access (Secure Web Gateway cloud-natif)

Niveau : 🟡 Moyen Référence : Microsoft Entra Suite — Zero Trust Architecture Licence requise : Entra Suite ou Microsoft 365 E5

Description : Microsoft Entra Internet Access est un Secure Web Gateway (SWG) cloud-natif intégré à Entra ID. Il filtre le trafic Internet, applique les politiques CA au niveau réseau et implémente les Tenant Restrictions v2 sans proxy traditionnel. Cas d’usage critiques : bloquer l’accès aux tenants M365 non autorisés depuis les appareils d’entreprise (prévention de l’exfiltration via tenant personnel), filtrer les sites malveillants, surveiller le shadow IT.

Vérification :

Microsoft Entra Admin Center > Global Secure Access > Tableau de bord
Vérifier le profil de transfert “Internet Access” et le nombre d’utilisateurs connectés
Entra Admin Center > Global Secure Access > Trafic > Journaux réseau

Remédiation :

Entra Admin Center > Global Secure Access > Démarrage > Activer Global Secure Access
Activer le profil de transfert de trafic “Internet Access”
Déployer le client Global Secure Access via Intune (Windows 10/11)
Configurer le filtrage de contenu web (catégories : malware, phishing, adulte, Shadow IT)
Activer la protection avancée contre les menaces web
Configurer Tenant Restrictions v2 via le profil Global Secure Access

Valeur par défaut : Non déployé — nécessite une activation et une licence spécifique.

1.13.2 — Remplacer le VPN traditionnel par Microsoft Entra Private Access (ZTNA)

Niveau : 🟡 Moyen Référence : NIST SP 800-207 — Zero Trust Architecture Licence requise : Entra Suite

Description : Microsoft Entra Private Access est un Zero Trust Network Access (ZTNA) qui remplace le VPN en autorisant l’accès aux ressources privées on-premises (applications métier, fichiers réseau, serveurs) basé sur l’identité et la conformité de l’appareil — et non sur l’appartenance au réseau. Contrairement au VPN, il n’accorde pas l’accès à tout le réseau : seules les applications spécifiquement publiées sont accessibles, réduisant drastiquement le mouvement latéral possible en cas de compromission.

Vérification :

Entra Admin Center > Global Secure Access > Private Access
Vérifier les Application Segments configurés et les connecteurs déployés

Remédiation :

Entra Admin Center > Global Secure Access > Private Access
Créer des Application Segments pour chaque ressource interne (IP/FQDN + port)
Déployer des connecteurs Entra Private Access sur le réseau interne (Windows ou Linux)
Migrer progressivement les cas d’usage VPN vers Private Access
Appliquer des politiques CA : conformité appareil + MFA pour chaque accès

Valeur par défaut : Non déployé — VPN traditionnel sans contrôle d’identité granulaire.

1.14 Lifecycle Workflows — Automatisation Joiner/Mover/Leaver

1.14.1 — Automatiser l’offboarding (Leaver) via Lifecycle Workflows Entra ID

Niveau : 🟠 Élevé Référence : Entra ID Governance P2 — CISA Zero Trust Licence requise : Entra ID Governance (P2)

Description : Les Lifecycle Workflows automatisent les processus d’offboarding : désactivation du compte à J0, révocation des sessions actives, retrait des groupes sensibles, notification au manager, suppression différée. Sans cette automatisation, les offboardings manuels génèrent des comptes actifs plusieurs jours après le départ d’un employé et des accès non révoqués — source principale de comptes “zombies” exploitables.

Vérification :

# Lister les Lifecycle Workflows actifs de type Leaver
$workflows = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/workflows" -Method GET
$leaverWorkflows = $workflows.value | Where-Object { $_.category -eq "leaver" }
if ($leaverWorkflows) {
    $leaverWorkflows | Select-Object displayName, isEnabled, @{N="Tasks";E={$_.tasks.Count}} | Format-Table
    Write-Host "✅ $($leaverWorkflows.Count) workflow(s) Leaver configuré(s)" -ForegroundColor Green
} else {
    Write-Host "❌ Aucun Lifecycle Workflow Leaver configuré" -ForegroundColor Red
}

Remédiation :

Entra ID Admin Center > Gouvernance des identités > Lifecycle Workflows
Créer un workflow “Leaver” avec les tâches ordonnées :
- J0 : Désactiver le compte utilisateur
- J0 : Révoquer toutes les sessions actives
- J0 : Retirer des groupes sensibles
- J0 : Envoyer notification au manager
- J+7 : Supprimer les licences
- J+30 : Supprimer le compte (ou J+90 selon politique RH)
Connecter à la date de départ via attribut employeeLeaveDateTime
Tester en mode simulation avant activation

Valeur par défaut : Aucun Lifecycle Workflow configuré — offboarding 100% manuel, risque de délai.

1.14.2 — Configurer les Lifecycle Workflows pour les Joiners (onboarding + TAP automatique)

Niveau : 🟡 Moyen Référence : Entra ID Governance P2 Licence requise : Entra ID Governance (P2)

Description : Les workflows Joiner créent automatiquement un Temporary Access Pass (TAP) pour l’enrôlement MFA à J-1, assignent les licences selon le département et ajoutent l’utilisateur aux groupes appropriés. Sans automatisation, les délais d’onboarding et les erreurs d’assignation de droits sont fréquents. Le TAP automatique garantit que les nouveaux arrivants enrôlent une méthode MFA forte dès le premier jour sans passer par le helpdesk.

Vérification :

$workflows = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/workflows" -Method GET
$joinerWorkflows = $workflows.value | Where-Object { $_.category -eq "joiner" }
$joinerWorkflows | Select-Object displayName, isEnabled, @{N="Tasks";E={$_.tasks.Count}} | Format-Table

Remédiation :

Créer un workflow “Joiner” déclenchant J-1 avant la date d’arrivée :
- J-1 : Générer un TAP (valable 24h, utilisation unique)
- J-1 : Envoyer email de bienvenue au manager avec le TAP
- J0 : Assigner les licences selon le département
- J0 : Ajouter aux groupes appropriés
Connecter à la date d’arrivée via attribut employeeHireDate
Activer la tâche “Activer le compte” uniquement le jour J (pas avant)

Valeur par défaut : Aucun workflow Joiner — provisioning 100% manuel.

1.15 Unités Administratives et Délégation Granulaire

1.15.1 — Implémenter des Restricted Management AUs pour protéger les comptes critiques

Niveau : 🟠 Élevé Référence : Entra ID P1 Licence requise : Entra ID P1

Description : Les Unités Administratives Restreintes (Restricted Management Administrative Units) placent des comptes dans une “zone de protection maximale” : même les Global Administrators ne peuvent pas modifier les paramètres, réinitialiser les mots de passe ou désactiver les méthodes d’authentification des membres sans être gestionnaires de l’AU. C’est la protection la plus forte pour les comptes Break Glass, les comptes RSSI et les comptes SOC — un attaquant ayant compromis un Global Admin ne peut pas neutraliser ces comptes.

Vérification :

# Lister les Restricted Management AUs
$aus = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/administrativeUnits?`$filter=isMemberManagementRestricted eq true" -Method GET
if ($aus.value.Count -gt 0) {
    Write-Host "✅ $($aus.value.Count) Restricted Management AU(s) configurée(s)" -ForegroundColor Green
    foreach ($au in $aus.value) {
        $members = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$($au.id)/members" -Method GET
        Write-Host "  AU: $($au.displayName) — $($members.value.Count) membre(s) protégé(s)"
    }
} else {
    Write-Host "❌ Aucune Restricted Management AU — comptes critiques non protégés" -ForegroundColor Red
}

Remédiation :

Entra ID Admin Center > Identité > Rôles et administrateurs > Unités administratives > Nouvelle AU
Activer isMemberManagementRestricted = $true (Portail ou API Graph)
Ajouter les membres à protéger : comptes Break Glass, compte RSSI, comptes SOC, SPs critiques
Désigner des gestionnaires de l’AU dédiés (distincts des GA standard)
Documenter qui peut gérer cette AU et les procédures d’accès d’urgence

Valeur par défaut : Aucune Restricted Management AU — tous les GA peuvent modifier tous les comptes sans restriction.

1.15.2 — Déléguer la gestion des utilisateurs par Unités Administratives sans droits globaux

Niveau : 🟡 Moyen Référence : CIS 5.x — Least Privilege Licence requise : Entra ID P1

Description : Les Unités Administratives permettent de déléguer la gestion des utilisateurs et des groupes par périmètre organisationnel (pays, département, filiale) sans accorder des droits sur l’ensemble du tenant. Un IT admin d’une filiale n’a besoin que de gérer les utilisateurs de sa filiale — pas d’un rôle global. Sans AUs, toute délégation nécessite un rôle tenant-wide avec surface d’attaque étendue.

Vérification :

$aus = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/administrativeUnits" -Method GET
$aus.value | Select-Object displayName, description, membershipType | Format-Table
# Vérifier que les admins délégués n'ont PAS de rôles au niveau tenant
$scopedRoles = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/administrativeUnits" -Method GET

Remédiation :

Créer des AUs par département, filiale ou région géographique
Assigner le rôle “User Administrator” ou “Helpdesk Administrator” limité à l’AU (pas au tenant)
Révoquer les rôles globaux des administrateurs locaux qui n’en ont pas besoin
Configurer des AUs dynamiques si la structure est basée sur des attributs AD (department, country)

Valeur par défaut : Aucune AU configurée — délégation au niveau tenant uniquement.

1.16 Santé, Recommandations et Conformité Entra ID

1.16.1 — Activer et traiter les Recommandations de Sécurité Entra ID

Niveau : 🟠 Élevé Référence : Entra ID — Built-in Recommendations Licence requise : Entra ID P2

Description : Microsoft Entra ID génère automatiquement des recommandations de sécurité personnalisées basées sur l’analyse en temps réel du tenant : “X utilisateurs admin sans MFA résistant au phishing”, “X applications avec secrets expirés”, “Per-user MFA encore actif pour Y comptes”. Ces recommandations sont priorisées par impact. Les ignorer laisse des lacunes connues et documentées non traitées, ce qui constitue une faute de gestion en cas d’incident.

Vérification :

# Lister les recommandations actives haute priorité
$recommendations = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/recommendations" -Method GET
$active = $recommendations.value | Where-Object { $_.status -notin @("completedBySystem","completedByUser","dismissed") }
Write-Host "Recommandations actives non traitées : $($active.Count)"
$active | Sort-Object priority | Select-Object displayName, status, priority, @{N="Impact";E={$_.impactedResources.Count}} | Format-Table
# Résultat attendu : 0 recommandation haute priorité en statut actif

Remédiation :

Entra ID Admin Center > Identité > Vue d’ensemble > Recommandations
Trier par priorité (Critique / Élevé)
Traiter chaque recommandation selon les instructions Microsoft intégrées
Recommandations non applicables : les “Ignorer” avec justification documentée
Révision mensuelle des nouvelles recommandations générées

Valeur par défaut : Recommandations générées mais aucune action automatique — elles restent actives indéfiniment.

1.16.2 — Surveiller la santé de la synchronisation Entra Connect (Connect Health)

Niveau : 🟠 Élevé Référence : CIS 5.1.8.x — Manual Licence requise : Entra ID P1 Applicabilité : Environnements hybrides uniquement

Description : Entra Connect Health surveille la santé des serveurs de synchronisation AD. Un problème non détecté peut entraîner : des comptes désactivés on-premises qui restent actifs dans le cloud (accès fantôme persistant), des mots de passe non synchronisés (écart AD/Entra exploitable), ou des groupes de sécurité incorrects. La latence de synchronisation > 30 minutes est souvent le premier signe d’une compromission de l’infrastructure hybride.

Vérification :

# Vérifier la latence de synchronisation via Graph
$syncState = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization" -Method GET -ErrorAction SilentlyContinue
$syncState.value | Select-Object lastSyncDateTime, synchronizationClientErrorCount | Format-Table
# Via portail : Entra ID > Surveillance et santé > Entra Connect Health > Alertes actives

Remédiation :

Installer l’agent Entra Connect Health sur tous les serveurs Entra Connect / Cloud Sync
Configurer des alertes email (SOC ou RSSI) pour les erreurs de synchronisation
Objectif : délai de synchronisation ≤ 30 minutes, 0 objets en quarantaine
Vérifier quotidiennement : erreurs d’exportation, objets en conflit, agents déconnectés
Configurer une alerte si la synchronisation s’arrête > 1 heure

Valeur par défaut : Connect Health doit être installé manuellement — aucune surveillance sans agent.

1.17 PIM pour Groupes et Gestion des Comptes de Service

1.17.1 — Activer PIM pour les Groupes d’Accès Privilégiés (PIM for Groups)

Niveau : 🟠 Élevé Référence : Entra ID P2 (PIM) Licence requise : Entra ID P2

Description : PIM for Groups étend le contrôle Just-In-Time (JIT) au-delà des rôles Entra ID vers les groupes de sécurité : groupes donnant accès aux applications SaaS, aux ressources Azure, ou aux rôles personnalisés. Un groupe “Finance-Admins” donnant accès aux environnements de production financiers peut être géré via PIM — les membres ne sont actifs que lorsqu’ils ont besoin de cet accès, avec approbation et justification documentée. Les memberships permanents créent une surface d’attaque inutile.

Vérification :

# Lister les groupes gérés via PIM for Groups
$privilegedGroups = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/privilegedAccess/aadGroups/resources?`$filter=status eq 'Active'" -Method GET -ErrorAction SilentlyContinue
Write-Host "Groupes gérés via PIM for Groups : $($privilegedGroups.value.Count)"
$privilegedGroups.value | Select-Object displayName, status | Format-Table

# Identifier les groupes candidats (avec app role assignments, non gérés par PIM)
Get-MgGroup -Filter "securityEnabled eq true" -All | ForEach-Object {
    $assignments = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/groups/$($_.Id)/appRoleAssignments" -Method GET
    if ($assignments.value.Count -gt 0) {
        [PSCustomObject]@{ Group = $_.DisplayName; AppRoles = $assignments.value.Count }
    }
} | Sort-Object AppRoles -Descending | Format-Table

Remédiation :

Entra ID > Gestion des identités > Privileged Identity Management > Groupes
Identifier les groupes sensibles (accès applicatifs élevés, rôles custom, accès Azure)
“Gérer” → activer la gestion PIM pour ces groupes
Configurer : durée d’activation max = 4h, approbation requise, justification obligatoire
Convertir les membres permanents en membres “Éligibles”

Valeur par défaut : Groupes de sécurité sans contrôle JIT — memberships permanents par défaut.

1.17.2 — Migrer les comptes de service avec mots de passe vers Managed Identities ou Workload Federation

Niveau : 🟠 Élevé Référence : CIS 5.x / CISA Zero Trust — Automated Licence requise : Entra ID Free + Azure

Description : Les comptes de service avec mots de passe sont une cible privilégiée : mots de passe rarement changés, souvent exclus du MFA et des politiques CA, rarement surveillés. Microsoft recommande de migrer vers les Managed Identities (ressources Azure) ou les Workload Identity Federations (CI/CD et applications externes). Ces alternatives éliminent complètement les mots de passe — l’identité est cryptographiquement liée à la ressource, aucun secret ne peut être volé ou rejoué.

Vérification :

# Comptes utilisateurs ressemblant à des comptes de service actifs
Get-MgUser -All -Property "UserPrincipalName,DisplayName,SignInActivity,AccountEnabled" |
    Where-Object {
        ($_.UserPrincipalName -match "svc|service|bot|auto|system|app|api") -and
        $_.AccountEnabled -eq $true
    } | Select-Object UserPrincipalName, @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} | Format-Table

# Service Principals avec password credentials à migrer
Get-MgServicePrincipal -All -Property "DisplayName,PasswordCredentials" |
    Where-Object { $_.PasswordCredentials.Count -gt 0 } |
    Select-Object DisplayName, @{N="NbSecrets";E={$_.PasswordCredentials.Count}},
        @{N="ExpirationLaPlusProche";E={($_.PasswordCredentials | Sort-Object EndDateTime | Select-Object -First 1).EndDateTime}} |
    Format-Table

Remédiation :

Inventorier tous les comptes de service avec mots de passe et leur propriétaire
Migrer vers Managed Identity si ressource Azure (VM, Function App, Logic App)
Migrer vers Workload Identity Federation si CI/CD (GitHub Actions, Azure DevOps, GitLab)
Pour les cas impossibles à migrer : secret rotatif < 90j + exclusion CA documentée + alerte sur usage
Supprimer immédiatement les comptes de service inactifs depuis > 90 jours

Valeur par défaut : Aucune restriction — comptes de service avec mots de passe en persistance indéfinie.

1.18 Workload Identity Federations et CI/CD Security

1.18.1 — Auditer les Federated Identity Credentials (OIDC) pour CI/CD

Niveau : 🔴 Critique Référence : Entra ID Free — CISA Zero Trust Licence requise : Entra ID Free

Description : Les Workload Identity Federations (GitHub Actions, Azure DevOps, GitLab, Kubernetes) permettent aux pipelines CI/CD de s’authentifier dans Entra ID via des tokens OIDC éphémères — sans secret stocké. C’est une excellente pratique, mais une mauvaise configuration (audience trop large, subject trop générique comme repo:org/*) permet à un attaquant ayant accès à n’importe quel repo de l’organisation d’obtenir un token valide vers le tenant M365. C’est un vecteur d’attaque supply chain critique en 2026.

Vérification :

# Lister toutes les Federated Identity Credentials configurées
$apps = Get-MgApplication -All -Property "displayName,federatedIdentityCredentials"
$apps | Where-Object { $_.FederatedIdentityCredentials.Count -gt 0 } | ForEach-Object {
    $app = $_
    $app.FederatedIdentityCredentials | ForEach-Object {
        [PSCustomObject]@{
            App      = $app.DisplayName
            Name     = $_.Name
            Issuer   = $_.Issuer
            Subject  = $_.Subject
            Audience = $_.Audiences -join ","
        }
    }
} | Format-Table
# Alertes : Subject contenant "*", "repo:org/*", ou audience non standard

Remédiation :

Revoir chaque Federated Credential et vérifier que le Subject est précis (ex: repo:org/repo:environment:prod)
Supprimer les credentials avec Subject trop large (* ou repo:org/*)
Vérifier que l’Audience est api://AzureADTokenExchange uniquement
Limiter les permissions de l’App Registration associée au strict minimum
Documenter chaque Federated Credential avec son propriétaire et son use case

Valeur par défaut : Aucune validation des claims — Subject et Audience non contraints par défaut.

1.18.2 — Restreindre les permissions des App Registrations utilisées par les pipelines CI/CD

Niveau : 🟠 Élevé Référence : CIS 5.x — Least Privilege Licence requise : Entra ID Free

Description : Les App Registrations utilisées par les pipelines CI/CD (déploiement, tests automatisés, provisioning) accumulent souvent des permissions Graph élevées pour “simplifier” les workflows. Une pipeline compromise ou un token OIDC mal configuré peut alors exécuter des opérations critiques (créer des comptes, modifier des politiques CA, exfiltrer des données). Le principe du moindre privilège doit s’appliquer strictement aux identités CI/CD.

Vérification :

# Apps utilisées en CI/CD avec permissions Graph élevées
$dangerousPerms = @("Directory.ReadWrite.All","RoleManagement.ReadWrite.Directory","Application.ReadWrite.All","User.ReadWrite.All")
$apps = Get-MgApplication -All
foreach ($app in $apps) {
    $graphPerms = $app.RequiredResourceAccess |
        Where-Object { $_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000" } |
        Select-Object -ExpandProperty ResourceAccess
    $high = $graphPerms | Where-Object { $_.Id -in $dangerousPerms }
    if ($high) {
        Write-Host "⚠️ $($app.DisplayName) — Permissions élevées : $($high.Id -join ', ')" -ForegroundColor Red
    }
}

Remédiation :

Inventorier toutes les App Registrations liées aux pipelines CI/CD
Remplacer les permissions ReadWrite par des permissions ReadOnly si possible
Utiliser des rôles personnalisés Entra ID avec permissions minimales
Revoir trimestriellement les permissions des apps CI/CD avec le responsable DevOps

Valeur par défaut : Aucune restriction spécifique aux apps CI/CD — elles peuvent demander toutes les permissions.

SECTION 2 — MICROSOFT DEFENDER FOR OFFICE 365

2.1 Politiques de Sécurité Prédéfinies (Preset Security Policies)

2.1.1 — Activer les politiques de sécurité Standard et Stricte

Niveau : 🔴 Critique Référence CISA SCuBA : MS.DEFENDER.1.1v1, MS.DEFENDER.1.2v1, MS.DEFENDER.1.3v1

Description : Microsoft propose des politiques de sécurité prédéfinies (Standard et Stricte) qui regroupent en un seul clic toutes les configurations optimales anti-spam, anti-phishing, anti-malware, Safe Attachments et Safe Links, alignées sur les recommandations Microsoft. Elles simplifient la configuration et garantissent un niveau de protection cohérent. La politique Stricte doit s’appliquer aux utilisateurs les plus sensibles.

Vérification :

Portail Microsoft Defender > Email & Collaboration > Politiques > Politiques de sécurité prédéfinies
Vérifier que Standard Protection et Strict Protection sont activées

Remédiation :

Portail Defender > Email & Collaboration > Politiques & Règles > Stratégies contre les menaces > Stratégies de sécurité prédéfinies
Activer “Protection standard” → Assigner à : Tous les destinataires
Activer “Protection stricte” → Assigner à : Utilisateurs sensibles (Direction, Finance, RH, IT)
EOP (Exchange Online Protection) ET Defender for Office 365 doivent tous deux être configurés
La politique stricte prend la priorité sur la standard pour les utilisateurs des deux groupes

2.1.2 — Ajouter les comptes sensibles à la politique Stricte

Niveau : 🔴 Critique Référence CISA SCuBA : MS.DEFENDER.1.4v1, MS.DEFENDER.1.5v1

Description : Les comptes des dirigeants, de la finance, des RH et du service IT sont les cibles prioritaires des attaques BEC, du spear phishing et des fraudes au président. Ces utilisateurs doivent bénéficier du niveau de protection le plus élevé (politique Stricte) avec toutes les protections contre l’usurpation d’identité activées.

Vérification :

Portail Defender > Politiques de sécurité prédéfinies > Protection stricte > Utilisateurs, groupes et domaines inclus

Remédiation :

Dans la politique Stricte, ajouter explicitement :
- Tous les membres de la direction (PDG, DAF, DRH, DSI, RSSI, etc.)
- Tous les membres de l’équipe finance et comptabilité
- Tous les administrateurs IT et sécurité
- Tout utilisateur avec accès à des systèmes critiques
Créer un groupe Entra ID “Utilisateurs Protection Stricte” pour faciliter la gestion

2.2 Protection Anti-Phishing

2.2.1 — Configurer les politiques Anti-Phishing

Niveau : 🔴 Critique Référence CIS : CIS Control 9.2 Licence requise : Defender for Office 365 Plan 1 ou 2

Description : Les attaques de phishing représentent le vecteur d’intrusion n°1 dans les organisations. Les politiques anti-phishing de Defender for Office 365 incluent la protection contre l’usurpation d’identité (impersonation) de domaines et d’utilisateurs clés, ainsi que des fonctionnalités d’intelligence sur les boîtes mail.

Vérification :

Portail Microsoft Defender > Email & Collaboration > Politiques > Anti-phishing
Vérifier la politique par défaut et les politiques personnalisées
PowerShell :

Get-AntiPhishPolicy | Select-Object Name, Enabled, PhishThresholdLevel, EnableTargetedUserProtection, EnableOrganizationDomainsProtection, EnableMailboxIntelligence

Remédiation :

Niveau de seuil de phishing : 3 (Agressif) ou 2 (Standard) minimum
Activer la protection contre l’usurpation d’identité :
- Utilisateurs protégés : PDG, DAF, DG, RSSI (ajouter adresses explicitement)
- Domaines protégés : activer pour les domaines de l’organisation
Activer Mailbox Intelligence
Activer Mailbox Intelligence pour la protection contre l’usurpation d’identité
Action si usurpation détectée : Mettre en quarantaine

2.2.2 — Configurer DMARC, DKIM et SPF

Niveau : 🔴 Critique Référence CIS : CIS Control 9.2

Description : Ces trois protocoles d’authentification email forment un triple rempart contre l’usurpation d’identité (spoofing). SPF définit les serveurs autorisés à envoyer des emails pour le domaine. DKIM signe cryptographiquement les messages. DMARC définit la politique en cas d’échec SPF/DKIM et permet les rapports d’abus.

Vérification :

# Vérification SPF
Resolve-DnsName -Name "_spf.domaine.com" -Type TXT
# Vérification DKIM
Get-DkimSigningConfig | Select-Object Domain, Enabled, Status
# Vérification DMARC
Resolve-DnsName -Name "_dmarc.domaine.com" -Type TXT

Ou utiliser : https://mxtoolbox.com/SuperTool.aspx

Remédiation : SPF :

v=spf1 include:spf.protection.outlook.com -all

(Le -all est obligatoire pour refuser tous les autres serveurs)

DKIM :

Exchange Admin Center > Email Authentication > DKIM
Activer DKIM pour chaque domaine
Publier les enregistrements CNAME fournis par Microsoft dans le DNS

DMARC :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@domaine.com; ruf=mailto:dmarc-forensics@domaine.com; pct=100

Commencer avec p=none pour observer, puis p=quarantine, puis p=reject

2.2.3 — Activer la Protection contre l’usurpation (Anti-Spoofing)

Niveau : 🔴 Critique Référence CIS : CIS Control 9.2

Description : L’anti-spoofing empêche les emails qui semblent provenir de domaines internes mais qui arrivent de sources externes non autorisées. C’est une protection critique contre les attaques BEC.

Vérification :

Get-AntiPhishPolicy | Select-Object Name, EnableSpoofIntelligence, AuthenticationFailAction

Remédiation :

Activer Spoof Intelligence dans les politiques anti-phishing
Action en cas de spoofing détecté : Déplacer en dossier Courrier indésirable ou Mettre en quarantaine
Réviser régulièrement le tableau de bord Spoof Intelligence pour valider/bloquer les expéditeurs légitimes

2.3 Protection Anti-Malware et Safe Attachments

2.3.1 — Activer Safe Attachments

Niveau : 🔴 Critique Référence CIS : CIS Control 9.3 Licence requise : Defender for Office 365 Plan 1 MITRE ATT&CK : T1566.001 (Phishing: Spearphishing Attachment) · T1204.002 (User Execution: Malicious File) · T1027 (Obfuscated Files or Information)

Description : Safe Attachments ouvre les pièces jointes dans un environnement sandbox isolé avant de les livrer à l’utilisateur. Cette protection est essentielle contre les malwares zero-day qui n’ont pas encore de signature antivirus connue.

Vérification :

Get-SafeAttachmentPolicy | Select-Object Name, Enable, Action, Redirect, RedirectAddress

Remédiation :

Portail Defender > Email & Collaboration > Politiques > Safe Attachments
Activer Safe Attachments pour tous les domaines
Action : Bloquer (Block) — les pièces jointes malveillantes sont bloquées
Activer Safe Attachments pour SharePoint, OneDrive et Teams
Activer le rapport de malwares en temps réel

2.3.2 — Activer Safe Links

Niveau : 🔴 Critique Référence CIS : CIS Control 9.3 Licence requise : Defender for Office 365 Plan 1

Description : Safe Links réécrit les URLs dans les emails et les documents Office pour passer par le service de vérification Microsoft au moment du clic. Cela protège contre les liens malveillants, même ceux qui deviennent malveillants après la livraison de l’email (time-of-click protection).

Vérification :

Get-SafeLinksPolicy | Select-Object Name, IsEnabled, EnableForInternalSenders, EnableSafeLinksForTeams, TrackClicks, AllowClickThrough

Remédiation :

Activer Safe Links pour tous les domaines et utilisateurs
Activer Safe Links pour les applications Office 365
Activer Safe Links pour Teams
AllowClickThrough : Désactivé (l’utilisateur ne peut pas bypasser l’alerte)
TrackClicks : Activé (pour les rapports)
Ne PAS utiliser de liste d’exclusion (Do not rewrite URLs list) sauf exception justifiée

2.3.3 — Configurer la politique Anti-Malware avec types de fichiers étendus

Niveau : 🟠 Élevé Référence CIS : CIS Control 9.3

Description : La politique anti-malware standard de M365 peut être renforcée pour bloquer proactivement les types de fichiers à haut risque (.exe, .ps1, .vbs, .bat, .js, etc.) même sans signature malware connue.

Vérification :

Get-MalwareFilterPolicy | Select-Object Name, EnableFileFilter, FileTypes

Remédiation :

Exchange Admin Center > Protection > Filtre anti-programme malveillant
Activer le filtrage des types de fichiers courants
Types de fichiers à bloquer minimums : .exe, .dll, .ps1, .vbs, .bat, .cmd, .com, .js, .jar, .wsf, .msi
Configurer des notifications à l’administrateur pour les pièces jointes bloquées

2.4 Protection contre le Spam

2.4.1 — Configurer les politiques Anti-Spam

Niveau : 🟠 Élevé Référence CIS : CIS Control 9.2

Description : Les emails de spam sont souvent le vecteur initial des campagnes de phishing et d’infection par malware. Une politique anti-spam bien configurée réduit significativement l’exposition des utilisateurs.

Vérification :

Get-HostedContentFilterPolicy | Select-Object Name, SpamAction, HighConfidenceSpamAction, PhishSpamAction, BulkSpamAction, BulkThreshold

Remédiation :

Spam Action : Mettre en quarantaine (recommandé) ou Dossier Courrier indésirable
High Confidence Spam : Mettre en quarantaine
Phish : Mettre en quarantaine
Bulk Email : Seuil BCL ≤ 6 (niveau 4-5 recommandé pour organisations sensibles)
Activer les rapports de spam pour les utilisateurs (pour signalement)

2.4.2 — Configurer l’impersonation utilisateurs ciblés (Targeted User Impersonation Protection)

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.DEFENDER.2.1v1 — Automated Licence requise : Microsoft Defender for Office 365 Plan 1

Description : La protection contre l’usurpation d’identité ciblée (user impersonation) protège les comptes à haut risque (dirigeants, finances, IT) contre les emails qui imitent leur adresse ou leur nom. Un email qui semble venir du PDG mais utilise un domaine légèrement différent (ex: ceo@contoso-corp.com) peut tromper les collaborateurs. Cette protection doit être configurée pour les comptes sensibles dans la politique anti-phishing.

Vérification :

# Vérifier la protection impersonation dans les politiques anti-phishing
Get-AntiPhishPolicy | Select-Object Name, EnableTargetedUserProtection, TargetedUsersToProtect, TargetedUserProtectionAction | Format-List
# Résultat attendu : EnableTargetedUserProtection = True, TargetedUsersToProtect contient les comptes sensibles

Remédiation :

Portail Defender > Email & Collaboration > Politiques > Anti-phishing
Modifier la politique Stricte ou créer une politique dédiée VIP
Section “Impersonation” > Activer “Activer la protection des utilisateurs”
Ajouter : CEO, CFO, RSSI, DRH, responsables financiers, admins IT
Action : Déplacer vers quarantaine (pas juste ajouter un conseil de sécurité)

Set-AntiPhishPolicy -Identity "Default" `
    -EnableTargetedUserProtection $true `
    -TargetedUsersToProtect @("ceo@contoso.com","cfo@contoso.com") `
    -TargetedUserProtectionAction Quarantine

Valeur par défaut : Protection impersonation ciblée désactivée.

2.4.3 — Configurer l’impersonation domaines owned et partenaires clés

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.DEFENDER.2.2v1 + MS.DEFENDER.2.3v1 — Automated Licence requise : Microsoft Defender for Office 365 Plan 1

Description : En complément de l’impersonation utilisateur, la protection d’impersonation de domaine protège contre les emails qui imitent vos domaines owned (ex: contoso-corp.com au lieu de contoso.com) et les domaines de vos partenaires/fournisseurs clés. C’est une couche de protection supplémentaire contre le Business Email Compromise (BEC).

Vérification :

Get-AntiPhishPolicy | Select-Object Name, EnableTargetedDomainsProtection, TargetedDomainsToProtect, EnableOrganizationDomainsProtection | Format-List
# Résultat attendu : EnableOrganizationDomainsProtection = True (domaines owned)
# TargetedDomainsToProtect = liste des domaines partenaires

Remédiation :

Set-AntiPhishPolicy -Identity "Default" `
    -EnableOrganizationDomainsProtection $true `
    -EnableTargetedDomainsProtection $true `
    -TargetedDomainsToProtect @("partner1.com","supplier.com") `
    -TargetedDomainProtectionAction Quarantine

Valeur par défaut : Protection impersonation domaine désactivée.

2.4.4 — Activer ZAP (Zero-Hour Auto Purge) pour Microsoft Teams

Niveau : 🟡 Moyen Référence : CIS M365 2.4.4 + M365-Assess DEFENDER-ZAP-001 — Automated Licence requise : Microsoft Defender for Office 365 Plan 1

Description : Le ZAP (Zero-Hour Auto Purge) pour Teams détecte et supprime automatiquement les messages malveillants envoyés dans Teams après leur délivrance. C’est le pendant du ZAP email pour Teams — si un fichier malveillant est détecté après partage dans un canal, il est automatiquement mis en quarantaine.

Vérification :

# Vérifier ZAP pour Teams
$atpPolicy = Get-AtpPolicyForO365
$atpPolicy | Select-Object Name, ZapEnabled, EnableATPForSPOTeamsODB | Format-List
# ZapEnabled doit être True

Remédiation :

Set-AtpPolicyForO365 -EnableATPForSPOTeamsODB $true -ZapEnabled $true

Portail Defender > Email & Collaboration > Paramètres > Paramètres Microsoft Teams > ZAP pour Teams

Valeur par défaut : ZAP Teams désactivé sur les anciens tenants.

2.4.5 — Configurer la DLP avec un périmètre complet (EXO + OD + SPO + Teams + Devices)

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.DEFENDER.4.2v1 — Automated Licence requise : Microsoft 365 E3 + Purview DLP

Description : Une politique DLP doit couvrir l’ensemble des services M365 simultanément pour être efficace. Si seul Exchange est couvert, un utilisateur peut exfiltrer des données via Teams ou SharePoint. Le périmètre minimum recommandé par CISA inclut : Exchange, OneDrive, SharePoint, Teams ET les appareils (endpoint DLP).

Vérification :

Connect-IPPSSession
$dlpPolicies = Get-DlpCompliancePolicy | Where-Object { $_.Mode -eq "Enable" }
foreach ($policy in $dlpPolicies) {
    $locations = @()
    if ($policy.ExchangeLocation.Count -gt 0) { $locations += "Exchange" }
    if ($policy.SharePointLocation.Count -gt 0) { $locations += "SharePoint" }
    if ($policy.OneDriveLocation.Count -gt 0) { $locations += "OneDrive" }
    if ($policy.TeamsLocation.Count -gt 0) { $locations += "Teams" }
    if ($policy.EndpointDlpLocation.Count -gt 0) { $locations += "Devices" }
    Write-Host "$($policy.Name): $($locations -join ', ')"
}
# Résultat attendu : au moins une politique couvre les 5 locations

Remédiation :

Microsoft Purview > Prévention des pertes de données > Modifier la politique existante
Étendre l’emplacement à : Exchange + SharePoint + OneDrive + Teams + Appareils
Vérifier que les règles existantes s’appliquent à tous les emplacements ajoutés

Valeur par défaut : DLP souvent configuré uniquement pour Exchange.

SECTION 3 — EXCHANGE ONLINE ET MESSAGERIE

3.1 Configuration de la Messagerie

3.1.1 — Désactiver le transfert automatique des emails vers des domaines externes

Niveau : 🔴 Critique Référence CIS : CIS Control 9.1 MITRE ATT&CK : T1114.003 (Email Collection: Email Forwarding Rule) · T1048 (Exfiltration Over Alternative Protocol) · T1567 (Exfiltration Over Web Service)

Description : Le transfert automatique d’emails est l’une des techniques les plus utilisées par les attaquants après compromission d’un compte. L’attaquant configure un transfert silencieux vers sa propre boîte mail pour exfiltrer durablement les communications de l’organisation.

Vérification :

Get-TransportRule | Where-Object {$_.RedirectMessageTo -ne $null -or $_.BlindCopyTo -ne $null} | Select-Object Name, RedirectMessageTo, BlindCopyTo
Get-RemoteDomain | Select-Object DomainName, AutoForwardEnabled
Get-HostedOutboundSpamFilterPolicy | Select-Object AutoForwardingMode

Remédiation :

Politique de spam sortant : AutoForwardingMode = Off
Remote Domain (domaine par défaut) : AutoForwardEnabled = False
Créer une règle de transport pour bloquer les transferts automatiques :
- Condition : Le message a les propriétés → Définir l’en-tête “X-MS-Exchange-Inbox-Rules-Loop”
- Action : Rejeter avec message “Le transfert automatique d’emails vers des domaines externes est interdit”
Créer une alerte pour détecter les règles de boîte mail créant des transferts

3.1.2 — Activer l’audit de la boîte mail (Mailbox Auditing)

Niveau : 🟠 Élevé Référence CIS : CIS Control 8.2

Description : L’audit des boîtes mail enregistre les actions effectuées sur les emails (lecture, suppression, transfert, accès délégué). Ces journaux sont essentiels pour les investigations forensics après incident et la détection d’accès non autorisés.

Vérification :

Get-OrganizationConfig | Select-Object AuditDisabled
Get-Mailbox -ResultSize Unlimited | Where-Object {$_.AuditEnabled -eq $false} | Select-Object UserPrincipalName, AuditEnabled

Remédiation :

Activer l’audit global :

Set-OrganizationConfig -AuditDisabled $false

Pour les boîtes mail non auditées :

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $true -AuditAdmin Update,Copy,Move,MoveToDeletedItems,SoftDelete,HardDelete,SendAs,SendOnBehalf,MessageBind -AuditDelegate Update,Move,MoveToDeletedItems,SoftDelete,HardDelete,SendAs,SendOnBehalf -AuditOwner Update,Move,MoveToDeletedItems,SoftDelete,HardDelete,MailboxLogin

Durée de rétention des journaux : 90 jours minimum (365 jours recommandé)

3.1.3 — Désactiver SMTP AUTH au niveau de l’organisation

Niveau : 🟠 Élevé Référence CIS : CIS Control 4.8

Description : SMTP AUTH (port 587 avec authentification basique) ne supporte pas le MFA et est souvent utilisé par des malwares ou des attaquants ayant compromis des credentials. Sa désactivation globale force les applications à utiliser OAuth 2.0.

Vérification :

Get-TransportConfig | Select-Object SmtpClientAuthenticationDisabled
Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.SmtpClientAuthenticationDisabled -eq $false} | Select-Object UserPrincipalName

Remédiation :

Désactiver SMTP AUTH globalement :

Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Pour les applications nécessitant SMTP AUTH (imprimantes, systèmes legacy) :
- Créer un compte dédié avec SMTP AUTH activé uniquement pour ce compte
- Restreindre l’envoi à un seul destinataire ou groupe
- Surveiller l’activité de ce compte
Migrer vers Microsoft Graph API pour l’envoi programmatique d’emails

3.1.4 — Configurer les connexions sécurisées TLS pour les emails entrants

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.10

Description : Forcer le TLS pour les communications email entrant depuis les partenaires commerciaux clés protège contre l’interception des emails en transit (man-in-the-middle).

Vérification :

Get-ReceiveConnector | Select-Object Name, RequireTLS, TLSCertificateName
Get-TransportConfig | Select-Object TLSReceiveDomainSecureList, TLSSendDomainSecureList

Remédiation :

Pour les partenaires critiques : configurer des connecteurs avec TLS obligatoire et vérification de certificat
Exchange Admin Center > Flux de messagerie > Connecteurs
Activer MTA-STS (Mail Transfer Agent Strict Transport Security) pour le domaine

3.1.5 — Désactiver les protocoles POP3 et IMAP4

Niveau : 🟠 Élevé Référence CIS : CIS Control 4.8

Description : POP3 et IMAP4 utilisent l’authentification basique qui ne supporte pas le MFA. Ces protocoles hérités doivent être désactivés sauf nécessité absolue documentée.

Vérification :

Get-CASMailboxPlan | Select-Object DisplayName, PopEnabled, ImapEnabled
Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.PopEnabled -eq $true -or $_.ImapEnabled -eq $true} | Select-Object UserPrincipalName, PopEnabled, ImapEnabled

Remédiation :

Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise -PopEnabled $false -ImapEnabled $false
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -PopEnabled $false -ImapEnabled $false

3.1.6 — Implémenter les avertissements d’expéditeur externe

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.EXO.7.1v1 Référence : BOD 25-01

Description : Signaler visuellement les emails provenant de l’extérieur de l’organisation réduit le risque de phishing interne (usurpation d’identité d’un collègue ou d’un dirigeant). Un utilisateur averti qu’il reçoit un email externe sera plus méfiant avant de cliquer sur un lien ou ouvrir une pièce jointe.

Vérification :

Get-TransportRule | Where-Object {$_.Name -like "*external*" -or $_.PrependSubject -like "*[Externe]*"} | Select-Object Name, State, PrependSubject

Remédiation :

Exchange Admin Center > Règles de flux de messagerie > Créer une règle
Condition : “L’expéditeur se trouve” → À l’extérieur de l’organisation
ET : “Le destinataire se trouve” → À l’intérieur de l’organisation
Action : Insérer une clause d’exclusion de responsabilité → ⚠️ ATTENTION : Cet email provient d'un expéditeur externe à l'organisation.
Ou : Ajouter le préfixe [EXTERNE] au sujet de l’email
Exception : Exclure les domaines partenaires connus si souhaité (pour éviter la lassitude des utilisateurs)

3.1.7 — Désactiver les listes d’autorisation IP dans les politiques anti-spam

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.EXO.12.1v1, MS.EXO.12.2v1

Description : Les listes d’autorisation d’adresses IP dans les politiques anti-spam font passer les emails de ces IPs sans aucun filtrage de spam, phishing ou malware. Ces IPs peuvent changer de propriétaire, être compromises, ou être utilisées pour du “trusted sender abuse”. Les listes “safe” (expéditeurs approuvés) ont le même problème.

Vérification :

# Vérifier la liste blanche IP dans la politique de filtre de connexion
Get-HostedConnectionFilterPolicy | Select-Object Name, IPAllowList, EnableSafeList

Remédiation :

Portail Defender > Email & Collaboration > Politiques > Anti-spam > Politique de filtre de connexion
IPAllowList : Supprimer toutes les entrées
EnableSafeList : Désactiver
Si des IPs doivent être autorisées pour des raisons légitimes : utiliser les règles de transport avec filtrage maintenu plutôt que l’bypass total

3.1.8 — Activer la purge automatique Zero-Hour (ZAP)

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.EXO.10.3v1

Description : ZAP (Zero-Hour Auto Purge) permet à Microsoft Defender de reclassifier et retirer des boîtes mail des emails qui ont été initialement livrés mais reconnus ultérieurement comme malveillants (malware, phishing). Cette protection post-livraison est essentielle car les IOCs de nouveaux malwares peuvent n’être disponibles qu’après la livraison initiale.

Vérification :

Get-HostedContentFilterPolicy | Select-Object Name, ZapEnabled
Get-MalwareFilterPolicy | Select-Object Name, ZapEnabled

Remédiation :

Portail Defender > Email & Collaboration > Politiques > Anti-spam
ZAP pour les spams : Activé
ZAP pour le phishing : Activé
Anti-malware : ZAP également activé par défaut, vérifier qu’il n’a pas été désactivé

3.1.9 — Ne pas ajouter de domaines dans les listes d’autorisation anti-spam

Niveau : 🔴 Critique Référence CISA SCuBA : MS.EXO.14.3v1

Description : Ajouter des domaines entiers en liste blanche anti-spam est extrêmement dangereux : tout email prétendant venir de ce domaine (y compris des spoofs) passera le filtrage. Même les domaines partenaires de confiance ne doivent pas être en liste blanche, car ils peuvent être compromis et utilisés pour envoyer des spams ou du phishing vers l’organisation.

Vérification :

Get-HostedContentFilterPolicy | Select-Object Name, AllowedSenderDomains

Doit retourner : vide / aucune entrée

Remédiation :

Portail Defender > Email & Collaboration > Politiques > Anti-spam
Dans chaque politique > Expéditeurs autorisés et domaines autorisés → Supprimer tous les domaines autorisés
Pour les partenaires légitimes qui rencontrent des faux positifs : utiliser des règles de transport ciblées ou des connecteurs entrants avec TLS, plutôt qu’une liste blanche

3.1.10 — Activer le chiffrement des emails sensibles (OME)

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.10 Licence requise : Microsoft 365 E3 ou supérieur

Description : Office Message Encryption (OME) chiffre automatiquement les emails contenant des informations sensibles (données personnelles, financières, médicales) pour protéger leur contenu en cas d’interception ou d’envoi à un mauvais destinataire.

Vérification :

Get-OMEConfiguration | Select-Object Identity, OTPEnabled, SocialIdSignIn
Get-TransportRule | Where-Object {$_.ApplyRightsProtectionTemplate -ne $null} | Select-Object Name

Remédiation :

Activer Azure Information Protection (AIP)
Créer des règles de transport pour le chiffrement automatique basé sur des mots clés ou classifications de données
Former les utilisateurs à l’utilisation du chiffrement manuel

3.1.11 — Valider DMARC p=reject (pas seulement p=none)

Niveau : 🔴 Critique Référence : CISA SCuBA MS.EXO.4.2v1 + 365Inspect (Inspect-DMARCPolicyAction) — Automated Licence requise : Entra ID Free (DNS public)

Description : Avoir un enregistrement DMARC avec p=none signifie uniquement monitoring — les emails qui échouent DMARC sont quand même délivrés. Ce n’est PAS une protection. Seul p=reject (ou p=quarantine comme étape transitoire) protège contre l’usurpation de domaine. La grande majorité des organisations ont p=none et croient être protégées.

Vérification :

# Vérifier DMARC pour tous les domaines acceptés
$acceptedDomains = Get-AcceptedDomain
foreach ($domain in $acceptedDomains.DomainName) {
    try {
        $dmarc = Resolve-DnsName -Name "_dmarc.$domain" -Type TXT -ErrorAction Stop
        $dmarcRecord = ($dmarc.Strings | Where-Object { $_ -like "v=DMARC1*" }) -join ""
        $policy = if ($dmarcRecord -match "p=(\w+)") { $Matches[1] } else { "ABSENT" }
        $color = if ($policy -eq "reject") { "Green" } elseif ($policy -eq "quarantine") { "Yellow" } else { "Red" }
        Write-Host "$domain : p=$policy" -ForegroundColor $color
    } catch { Write-Host "$domain : DMARC ABSENT" -ForegroundColor Red }
}

Résultat attendu : p=reject pour tous les domaines (ou p=quarantine comme étape de transition documentée)

Remédiation :

Démarrer avec p=none + rua=mailto:dmarc-reports@votre-domaine.com pour collecter les rapports
Analyser les rapports (outil : DMARC Analyzer, dmarcian, Valimail)
Passer à p=quarantine après validation (0% de faux positifs)
Passer à p=reject une fois stable
_dmarc.contoso.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@contoso.com; ruf=mailto:dmarc@contoso.com; pct=100"

Valeur par défaut : DMARC souvent absent ou p=none — aucune protection réelle.

3.1.12 — Valider SPF avec hard fail (-all) et non soft fail (~all)

Niveau : 🟠 Élevé Référence : CIS + 365Inspect (Inspect-SPFSoftFail) — Automated

Description : Un enregistrement SPF avec ~all (soft fail / tilde) indique aux serveurs destinataires que les emails hors périmètre sont “suspects mais pas rejetés” — ils sont souvent quand même délivrés. Seul -all (hard fail / tiret) indique un rejet. La grande majorité des organisations utilisent ~all par précaution, laissant le spoofing possible.

Vérification :

$acceptedDomains = Get-AcceptedDomain
foreach ($domain in $acceptedDomains.DomainName) {
    try {
        $spf = Resolve-DnsName -Name $domain -Type TXT -ErrorAction Stop
        $spfRecord = ($spf.Strings | Where-Object { $_ -like "v=spf1*" }) -join ""
        if ($spfRecord -match "-all") { Write-Host "✅ $domain : SPF hard fail (-all)" -ForegroundColor Green }
        elseif ($spfRecord -match "~all") { Write-Host "⚠️ $domain : SPF soft fail (~all) — protection incomplète" -ForegroundColor Yellow }
        else { Write-Host "❌ $domain : SPF absent ou mal configuré" -ForegroundColor Red }
    } catch { Write-Host "❌ $domain : Erreur DNS" -ForegroundColor Red }
}

Remédiation :

Identifier tous les serveurs légitimes d’envoi d’emails pour votre domaine
Lister les IPs/services autorisés dans le SPF (include:, ip4:, ip6:)
Remplacer ~all par -all dans tous les enregistrements SPF
Tester avec des outils SPF checker avant publication

Valeur par défaut : ~all (soft fail) — souvent utilisé pour éviter les faux positifs.

3.1.13 — Vérifier les 7 alertes obligatoires Microsoft (MS.EXO.16.1)

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.EXO.16.1v1 — Automated Licence requise : Microsoft 365 E3

Description : La CISA exige que 7 alertes spécifiques soient activées et configurées pour envoyer des notifications. Ces alertes couvrent les événements de sécurité les plus critiques : détection de malware, activités suspectes dans la boîte mail, connexions depuis des pays inhabituels, etc.

Vérification :

Connect-IPPSSession
$requiredAlerts = @(
    "Email messages containing malware removed after delivery",
    "Email messages containing phish URLs removed after delivery",
    "Email reported by user as malware or phish",
    "Suspicious email sending patterns detected",
    "Unusual increase in email reported as phish",
    "Messages have been delayed",
    "Tenant restricted from sending email"
)
$existingAlerts = Get-ProtectionAlert | Where-Object { $_.IsSystemPolicy -eq $false -or $_.Disabled -eq $false }
foreach ($required in $requiredAlerts) {
    $found = $existingAlerts | Where-Object { $_.Name -like "*$required*" -and -not $_.Disabled }
    Write-Host "$(if($found){'✅'}else{'❌'}) $required"
}

Remédiation :

Microsoft Purview > Alertes > Gérer les politiques d’alerte
Vérifier que les 7 alertes CISA sont activées avec notifications email
Configurer les notifications vers une adresse surveillée (SOC, équipe sécurité)
Les alertes doivent être envoyées vers un SIEM ou une adresse monitored H24

Valeur par défaut : Certaines alertes système activées, mais pas nécessairement les 7 requises.

3.1.14 — Activer les conseils de sécurité “First Contact” et Mailbox Intelligence

Niveau : 🟡 Moyen Référence : CISA SCuBA MS.EXO.11.2v1 + MS.EXO.11.3v1 + ORCA.241 — Automated Licence requise : Microsoft Defender for Office 365 Plan 1

Description : Les conseils de sécurité “First Contact” alertent l’utilisateur lorsqu’il reçoit pour la première fois un email d’un expéditeur. La Mailbox Intelligence utilise l’IA pour identifier les expéditeurs inhabituels. Ces deux fonctionnalités réduisent significativement le risque de BEC et de phishing en alertant l’utilisateur avant qu’il ne réponde ou clique.

Vérification :

Get-AntiPhishPolicy | Select-Object Name, EnableFirstContactSafetyTips, EnableMailboxIntelligence, EnableMailboxIntelligenceProtection | Format-Table
# Résultat attendu : EnableFirstContactSafetyTips = True, EnableMailboxIntelligence = True

Remédiation :

Set-AntiPhishPolicy -Identity "Default" `
    -EnableFirstContactSafetyTips $true `
    -EnableMailboxIntelligence $true `
    -EnableMailboxIntelligenceProtection $true `
    -MailboxIntelligenceProtectionAction MoveToJmf

Valeur par défaut : First Contact Safety Tips désactivé, Mailbox Intelligence activé mais sans protection.

3.1.15 — Bloquer les règles de transport bypass pour la simulation de phishing (PhishSim)

Niveau : 🟠 Élevé Référence : 365Inspect (Inspect-SimPhish) — Manual Licence requise : Microsoft Defender for Office 365 Plan 2

Description : Les règles de transport créées pour contourner Safe Attachments/Safe Links lors de simulations de phishing (Attack Simulator) utilisent souvent des IPs ou des domaines de prestataires. Si ces IPs/domaines sont connus, un vrai attaquant peut les usurper pour que ses emails passent dans les règles de bypass. Ces règles doivent être limitées aux IPs légitimes du prestataire de simulation et révisées régulièrement.

Vérification :

# Identifier les règles qui bypassent Safe Attachments ou Safe Links
Get-TransportRule | Where-Object {
    $_.SetHeaderName -eq "X-MS-Exchange-Organization-SkipSafeAttachmentProcessing" -or
    $_.SetHeaderName -eq "X-MS-Exchange-Organization-SkipSafeLinksProcessing" -or
    $_.SetSCL -eq -1
} | Select-Object Name, State, Conditions, SetHeaderName | Format-List

Remédiation :

Identifier toutes les règles bypass Safe Attachments/Safe Links
Vérifier qu’elles sont uniquement liées à des IPs de prestataires de simulation connus
Supprimer les règles inutilisées ou génériques (conditions trop larges)
Utiliser la fonctionnalité native “Attack Simulation Training” de Microsoft qui ne nécessite pas de règles de transport

Valeur par défaut : Les règles bypass sont créées manuellement — aucune restriction par défaut.

3.1.16 — Configurer ARC (Authenticated Received Chain) pour les flux d’emails complexes

Niveau : 🟡 Moyen Référence : ORCA.243 — Manual Licence requise : Exchange Online

Description : ARC (Authenticated Received Chain) préserve les résultats d’authentification email (SPF/DKIM/DMARC) lorsque les emails transitent par des intermédiaires légitimes (filtres anti-spam tiers, services de routage). Sans ARC, les emails légitimes réacheminés peuvent échouer DMARC et être rejetés ou marqués comme spam.

Vérification :

# Vérifier les sealers ARC de confiance configurés
Get-ArcConfig | Format-List
# Ou via :
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/admin/edge/internetExplorerMode/siteLists" -Method GET -ErrorAction SilentlyContinue
Get-TransportConfig | Select-Object ArcTrustedSealers

Remédiation :

Exchange Admin Center > Mail flow > Paramètres ARC
Ajouter les domaines des intermédiaires légitimes comme ARC sealers de confiance
Vérifier régulièrement les rapports DMARC pour identifier les échecs liés au réacheminement

Valeur par défaut : Aucun ARC sealer de confiance configuré.

3.1.17 — Auditer les délégations de boîte mail (Send As, Full Access, Send on Behalf)

Niveau : 🟠 Élevé Référence : 365Inspect (Inspect-EXOSendAsPermissions + EXOFullAccess) + M365-Assess — Automated Licence requise : Exchange Online

Description : Les délégations de boîte mail (Full Access, Send As, Send on Behalf) accordent à d’autres utilisateurs des droits d’accès complets à une boîte mail. Ces délégations s’accumulent dans le temps et sont rarement révoquées. Un attaquant qui compromet un compte avec délégation sur une boîte VIP peut envoyer des emails au nom du dirigeant ou lire tous ses emails en toute discrétion.

Vérification :

# Audit complet des délégations Send As
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    $mbx = $_
    $sendAs = Get-RecipientPermission -Identity $mbx.Identity -AccessRights SendAs | Where-Object { $_.Trustee -ne "NT AUTHORITY\SELF" }
    $fullAccess = Get-MailboxPermission -Identity $mbx.Identity | Where-Object { $_.AccessRights -contains "FullAccess" -and $_.User -notlike "*SELF*" -and $_.User -notlike "*S-1-5*" }
    if ($sendAs -or $fullAccess) {
        Write-Host "📬 $($mbx.DisplayName)" -ForegroundColor Yellow
        $sendAs | ForEach-Object { Write-Host "  Send As: $($_.Trustee)" }
        $fullAccess | ForEach-Object { Write-Host "  Full Access: $($_.User)" }
    }
}

Remédiation :

Inventorier toutes les délégations actives
Supprimer les délégations non justifiées ou liées à d’anciens employés
Documenter les délégations légitimes (assistants direction, secrétariats)
Révision semestrielle des délégations

Valeur par défaut : Délégations accumulées sans révision périodique.

3.2 Gestion des Calendriers et du Partage

3.2.1 — Restreindre le partage de calendriers avec des domaines externes

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.3

Description : Un calendrier partagé avec des domaines externes peut révéler des informations sensibles : présence/absence des dirigeants, sujets de réunions confidentielles, participants à des négociations stratégiques.

Vérification :

Get-SharingPolicy | Select-Object Name, Enabled, Domains

Remédiation :

Restreindre le partage à “Disponibilité uniquement” (FreeBusy) pour les domaines externes non partenaires
Créer des politiques de partage spécifiques pour les partenaires de confiance
Interdire le partage “Détails complets” avec des domaines non approuvés

3.2.2 — Interdire le partage de dossiers de contacts avec des domaines externes

Niveau : 🟠 Élevé Référence CIS : MS.EXO.6.1v1 / CIS 6.2 Profile : E3 Level 1

Description : Les dossiers de contacts Exchange partagés avec des domaines externes exposent l’annuaire interne de l’organisation : noms, fonctions, numéros de téléphone, adresses email. Ces informations sont exploitables pour des campagnes de spear phishing et de social engineering.

Vérification :

Get-SharingPolicy | Select-Object Name, Enabled, Domains
# Vérifier qu'aucune politique n'autorise ContactsSharing vers des domaines All

Remédiation :

# Modifier la politique de partage par défaut pour interdire ContactsSharing
Set-SharingPolicy -Identity "Default Sharing Policy" -Domains "Anonymous:CalendarSharingFreeBusySimple" # Retirer ContactsSharing

3.2.3 — Restreindre le partage de calendriers aux domaines de confiance spécifiés (whitelist)

Niveau : 🟠 Élevé Référence CIS : MS.EXO.6.1v1 — Automated Profile : E3 Level 1

Description : Les contrôles 3.2.1 et 3.2.2 restreignent le type d’information partageable (calendrier/contacts). Ce contrôle va plus loin en limitant les domaines vers lesquels le partage est autorisé. Sans whitelist, tout domaine externe peut recevoir des informations de disponibilité, même si le partage de données complètes est bloqué. Une liste de domaines de confiance approuvés garantit que seuls les partenaires connus peuvent voir les calendriers.

Vérification :

# Vérifier la politique de partage par défaut et les domaines autorisés
Get-SharingPolicy | Select-Object Name, Enabled, Domains | Format-List
# Résultat attendu : Domains contient uniquement des domaines partenaires explicites, pas "Anonymous" ou "*"

Remédiation :

Exchange Admin Center > Flux de messagerie > Politiques de partage
Modifier “Default Sharing Policy” pour limiter aux domaines de confiance
Créer des politiques de partage spécifiques par partenaire si nécessaire

# Limiter aux domaines approuvés
Set-SharingPolicy -Identity "Default Sharing Policy" -Domains "partenaire1.com:CalendarSharingFreeBusySimple","partenaire2.com:CalendarSharingFreeBusySimple"

Désactiver la politique par défaut si aucun partage externe n’est nécessaire

Valeur par défaut : Partage autorisé vers tous les domaines selon le type configuré.

3.2.4 — Désactiver les réponses automatiques d’absence du bureau (OOF) vers les domaines externes

Niveau : 🟡 Moyen Référence CIS : MS.EXO.6.1v1 — Automated Profile : E3 Level 1

Description : Les messages d’absence du bureau (Out-of-Office) envoyés automatiquement vers l’extérieur divulguent des informations exploitables : dates de congé, nom et contact du remplaçant, numéros de téléphone internes, structure hiérarchique. Ces informations facilitent les attaques BEC ciblées (usurpation d’identité pendant l’absence d’un décideur) et le spear phishing. Exchange peut être configuré pour n’envoyer les OOF qu’en interne.

Vérification :

# Vérifier la politique OOF au niveau tenant
Get-RemoteDomain -Identity "Default" | Select-Object DomainName, AutoReplyEnabled, AutoForwardEnabled
# Résultat attendu : AutoReplyEnabled = False pour le domaine Default (externe)

# Vérifier aussi les remote domains spécifiques
Get-RemoteDomain | Select-Object DomainName, AutoReplyEnabled | Format-Table

Remédiation :

# Désactiver les OOF automatiques vers l'extérieur
Set-RemoteDomain -Identity "Default" -AutoReplyEnabled $false
# Appliquer à tous les remote domains
Get-RemoteDomain | Set-RemoteDomain -AutoReplyEnabled $false

Exchange Admin Center > Flux de messagerie > Domaines distants > Modifier “Default” > désactiver “Autoriser les réponses automatiques”

Valeur par défaut : AutoReplyEnabled = True — les OOF sont envoyés vers tous les domaines externes.

3.2.5 — Bloquer la connexion directe aux boîtes aux lettres partagées

Niveau : 🔴 Critique Référence CIS : CIS 1.2.2 (L1) — Automated Profile : E3 Level 1

Description : Les boîtes partagées ne doivent pas permettre de connexion directe avec un mot de passe. Si la connexion est activée, un attaquant peut se connecter directement avec les identifiants de la boîte partagée, contournant la traçabilité (qui a fait quoi). L’accès doit uniquement être possible via permissions déléguées.

Vérification :

Connect-ExchangeOnline
$SharedMailboxes = Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited
$SharedMailboxes | ForEach-Object {
    Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property DisplayName,UserPrincipalName,AccountEnabled
} | Where-Object { $_.AccountEnabled -eq $true } | ft DisplayName, UserPrincipalName, AccountEnabled
# Résultat attendu : aucune boîte partagée avec AccountEnabled = True

Remédiation :

# Désactiver la connexion pour toutes les boîtes partagées
$SharedMBX = Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited
$SharedMBX | ForEach-Object {
    Update-MgUser -UserId $_.ExternalDirectoryObjectId -AccountEnabled:$false
}

3.2.6 — Vérifier qu’aucune règle de transport n’autorise des domaines entiers

Niveau : 🔴 Critique Référence CIS : CIS 6.2.2 (L1) — Automated Profile : E3 Level 1

Description : Des règles de transport qui fixent le niveau de confiance spam (SCL) à -1 pour des domaines entiers contournent complètement le filtrage anti-spam pour ces domaines. Si un domaine autorisé est compromis, tous les emails malveillants depuis ce domaine atteignent directement les boîtes sans filtrage.

Vérification :

Get-TransportRule | Where-Object { $_.SetSCL -eq -1 -and $_.SenderDomainIs -ne $null } |
    ft Name, SenderDomainIs, SetSCL
# Résultat attendu : aucune règle retournée

Remédiation :

Supprimer toutes les règles de transport qui autorisent des domaines entiers via SCL=-1
Si un besoin de partenaire existe, utiliser plutôt des connecteurs avec TLS mutuellement authentifié

# Identifier et supprimer
Get-TransportRule | Where-Object { $_.SetSCL -eq -1 } | Remove-TransportRule -Confirm:$true

3.2.7 — Désactiver AuditBypassEnabled sur toutes les boîtes aux lettres

Niveau : 🔴 Critique Référence CIS : CIS 6.1.3 (L1) — Automated Profile : E3 Level 1 MITRE ATT&CK : T1562.008 (Impair Defenses: Disable Cloud Logs) · T1070 (Indicator Removal) · T1562 (Impair Defenses)

Description : La propriété AuditBypassEnabled désactive l’audit pour une boîte spécifique. Des outils de migration ou des comptes de service peuvent activer ce contournement, créant des zones aveugles dans la surveillance de sécurité. Aucune boîte ne devrait avoir ce paramètre activé.

Vérification :

Get-MailboxAuditBypassAssociation -ResultSize Unlimited |
    Where-Object { $_.AuditBypassEnabled -eq $true } |
    ft Name, AuditBypassEnabled
# Résultat attendu : aucune boîte retournée

Remédiation :

# Corriger toutes les boîtes avec AuditBypass activé
Get-MailboxAuditBypassAssociation -ResultSize Unlimited |
    Where-Object { $_.AuditBypassEnabled -eq $true } |
    ForEach-Object { Set-MailboxAuditBypassAssociation -Identity $_.Name -AuditBypassEnabled $false }

3.2.8 — Configurer des limites d’envoi dans la politique anti-spam sortant

Niveau : 🟠 Élevé Référence CIS : CIS 2.1.15 (L1) — Automated Profile : E3 Level 1

Description : La politique anti-spam sortant doit définir des limites sur le nombre de destinataires par heure et par jour. Sans ces limites, un compte compromis peut envoyer des milliers de spams/phishings en quelques heures, nuisant à la réputation du domaine et pouvant conduire à son blacklistage.

Vérification :

Get-HostedOutboundSpamFilterPolicy -Identity Default |
    Select-Object RecipientLimitExternalPerHour, RecipientLimitInternalPerHour,
    RecipientLimitPerDay, ActionWhenThresholdReached
# Valeurs recommandées : ≤500 externe/h, ≤1000 interne/h, ≤1000/jour, ActionWhenThresholdReached = BlockUser

Remédiation :

Set-HostedOutboundSpamFilterPolicy -Identity Default `
    -RecipientLimitExternalPerHour 500 `
    -RecipientLimitInternalPerHour 1000 `
    -RecipientLimitPerDay 1000 `
    -ActionWhenThresholdReached BlockUser `
    -NotifyOutboundSpam $true `
    -NotifyOutboundSpamRecipients @("security@votredomaine.com")

3.2.9 — Désactiver la liste sûre du filtre de connexion

Niveau : 🟠 Élevé Référence CIS : CIS 2.1.13 (L1) — Automated Profile : E3 Level 1

Description : La “liste sûre” (SafeList) du filtre de connexion est une liste maintenue par Microsoft de soi-disant expéditeurs de confiance. Si elle est activée, les emails de ces expéditeurs contournent le filtrage anti-spam. Cette liste est gérée par Microsoft et peut inclure des expéditeurs compromis ou mal configurés.

Vérification :

Get-HostedConnectionFilterPolicy -Identity Default | Select-Object EnableSafeList
# Valeur attendue : False

Remédiation :

Set-HostedConnectionFilterPolicy -Identity Default -EnableSafeList $false

3.2.10 — Activer les notifications pour les malwares envoyés par des utilisateurs internes

Niveau : 🟠 Élevé Référence CIS : CIS 2.1.3 (L1) — Automated Profile : E3 Level 1

Description : Quand un malware est détecté dans un email envoyé par un utilisateur interne, l’administrateur doit être notifié immédiatement. Cela permet de détecter rapidement un compte compromis ou un appareil infecté avant que la propagation ne s’élargisse dans l’organisation.

Vérification :

Get-MalwareFilterPolicy | Select-Object Identity, EnableInternalSenderAdminNotifications, InternalSenderAdminAddress
# Valeur attendue : EnableInternalSenderAdminNotifications = True et adresse admin configurée

Remédiation :

Set-MalwareFilterPolicy -Identity Default `
    -EnableInternalSenderAdminNotifications $true `
    -InternalSenderAdminAddress "security@votredomaine.com"

3.2.11 — Détecter et bloquer les règles de boîte de réception malveillantes (Inbox Rules)

Niveau : 🔴 Critique Référence CIS : CIS 6.2.4 (L1) — Automated Référence CISA SCuBA : MS.EXO.8.1v1 MITRE ATT&CK : T1114.003 (Email Collection: Email Forwarding Rule) · T1074 (Data Staged) · T1564.008 (Hide Artifacts: Email Hiding Rules) Profile : E3 Level 1

Description : Les règles de boîte de réception malveillantes sont l’un des indicateurs les plus fiables d’une compromission BEC (Business Email Compromise). Après avoir compromis un compte, les attaquants créent des règles qui : (1) redirigent les emails vers des dossiers masqués, (2) transfèrent les emails vers des comptes externes, (3) suppriment automatiquement les alertes de sécurité. Ces règles permettent à l’attaquant de maintenir un accès persistant discret pendant des semaines ou des mois.

Vérification :

# Détecter les règles de redirection/transfert automatique suspectes
$mailboxes = Get-Mailbox -ResultSize Unlimited
foreach ($mailbox in $mailboxes) {
    $rules = Get-InboxRule -Mailbox $mailbox.UserPrincipalName -IncludeHidden -ErrorAction SilentlyContinue
    $suspiciousRules = $rules | Where-Object {
        $_.ForwardTo -ne $null -or
        $_.ForwardAsAttachmentTo -ne $null -or
        $_.RedirectTo -ne $null -or
        ($_.DeleteMessage -eq $true -and $_.SubjectContainsWords -match "security|alert|breach|phish|invoice|wire|payment")
    }
    if ($suspiciousRules) {
        Write-Host "⚠️ Règle suspecte sur: $($mailbox.UserPrincipalName)" -ForegroundColor Red
        $suspiciousRules | Select-Object Name, ForwardTo, RedirectTo, DeleteMessage | Format-Table
    }
}

Remédiation :

Investiguer et supprimer toutes les règles de redirection vers des domaines externes non légitimes
Configurer une alerte de sécurité Microsoft 365 sur la création/modification de règles de boîte de réception
Bloquer le forwarding automatique vers l’externe (déjà couvert par 3.1.1 — vérifier que la règle de transport est en place)
Activer Microsoft Defender for Office 365 pour la détection des règles suspectes
Surveiller via le journal d’audit : Search-UnifiedAuditLog -Operations "New-InboxRule","Set-InboxRule","UpdateInboxRules"
En cas de règle suspecte confirmée : initier la procédure de réponse aux incidents BEC

Valeur par défaut : Aucune détection automatique des règles de boîte de réception malveillantes.

SECTION 4 — MICROSOFT TEAMS

4.1 Sécurité des Communications Teams

4.1.1 — Restreindre l’accès des invités (Guest Access)

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.3

Description : L’accès invité dans Teams permet à des utilisateurs externes de rejoindre des équipes et d’accéder à des conversations, fichiers et réunions. Sans restriction, des informations sensibles peuvent être partagées accidentellement avec des personnes non autorisées.

Vérification :

Teams Admin Center > Paramètres à l’échelle de l’organisation > Accès invité
PowerShell :

Get-CsTeamsClientConfiguration | Select-Object AllowGuestUser
(Get-MgPolicyAuthorizationPolicy).AllowInvitesFrom

Remédiation :

Teams Admin Center > Accès invité : Configurer les autorisations spécifiques
Désactiver pour les invités : appels privés, partage vidéo (selon politique interne)
Activer le processus d’approbation pour l’ajout d’invités (via Entra ID)
Révision périodique des comptes invités actifs via Access Reviews
Définir une expiration automatique des comptes invités (ex: 90 jours)

4.1.2 — Restreindre l’accès externe (Federation)

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.3

Description : L’accès externe (fédération) permet aux utilisateurs Teams de communiquer avec des utilisateurs d’autres organisations Teams ou Skype. Sans liste blanche de domaines autorisés, tout domaine externe peut contacter vos utilisateurs, créant un vecteur de phishing via Teams.

Vérification :

Get-CsTenantFederationConfiguration | Select-Object AllowFederatedUsers, AllowedDomains, BlockedDomains

Remédiation :

Teams Admin Center > Paramètres > Accès externe
Choisir entre : Autoriser tous les domaines externes (déconseillé) OU Autoriser uniquement les domaines spécifiques
Si autorisation large : activer le blocage des domaines connus malveillants
Désactiver l’accès depuis Skype Consumer si non nécessaire

4.1.3 — Sécuriser les réunions Teams

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.3

Description : Les réunions Teams peuvent être rejointes par des participants non authentifiés si elles sont mal configurées. Des attaquants peuvent se joindre à des réunions sensibles ou injecter du contenu malveillant.

Vérification :

Get-CsTeamsMeetingPolicy | Select-Object Identity, AllowAnonymousUsersToJoinMeeting, AutoAdmittedUsers, AllowCloudRecording

Remédiation :

AllowAnonymousUsersToJoinMeeting : Désactivé (ou activé avec salle d’attente obligatoire)
AutoAdmittedUsers : EveryoneInCompanyExcludingGuests (les invités passent par la salle d’attente)
AllowExternalParticipantGiveRequestControl : Désactivé
DesignatedPresenterRoleMode : OrganizerOnlyUserOverride (seul l’organisateur est présentateur par défaut)

4.1.4 — Désactiver l’intégration Email dans les canaux Teams

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.TEAMS.4.1v1 Référence : BOD 25-01

Description : L’intégration email dans Teams permet d’envoyer des emails directement dans un canal Teams via une adresse email générée. Cette fonctionnalité contourne les politiques de filtrage des emails et peut permettre l’injection de contenu malveillant dans des canaux Teams sans passer par les protections Exchange/Defender.

Vérification :

Get-CsTeamsClientConfiguration | Select-Object AllowEmailIntoChannel

Remédiation :

Teams Admin Center > Teams > Paramètres Teams > Email integration
“Les utilisateurs peuvent envoyer des emails à une adresse email de canal” : Désactivé
PowerShell :

Set-CsTeamsClientConfiguration -AllowEmailIntoChannel $false

4.1.5 — Gouvernance des applications Teams

Niveau : 🟡 Moyen Référence CISA SCuBA : MS.TEAMS.5.1v2, MS.TEAMS.5.2v2, MS.TEAMS.5.3v2

Description : Les applications Teams (Microsoft Store, tierces parties, applications personnalisées) peuvent accéder aux données Teams, SharePoint et Exchange via des permissions OAuth. Sans gouvernance, des applications malveillantes ou non vérifiées peuvent être installées par n’importe quel utilisateur et obtenir un accès persistant aux données d’entreprise.

Vérification :

Teams Admin Center > Applications Teams > Paramètres d’application à l’échelle de l’organisation

Remédiation :

Teams Admin Center > Applications Teams > Gérer les applications > Paramètres d’application à l’échelle de l’organisation
Applications tierces : Désactiver les applications tierces globalement, puis activer sélectivement les applications approuvées
Applications personnalisées : Restreindre à un groupe d’administrateurs valideurs
Créer une liste des applications Microsoft approuvées et une liste des applications tierces autorisées
Processus de validation : toute nouvelle application doit faire l’objet d’une revue sécurité avant autorisation

4.1.6 — Activer la protection contre les malwares dans Teams (Safe Attachments)

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.TEAMS.7.1v1, MS.TEAMS.7.2v1

Description : Les pièces jointes partagées dans Teams (fichiers dans les conversations et canaux) peuvent contenir des malwares. La protection Safe Attachments pour Teams scanne ces fichiers dans un sandbox avant de les rendre accessibles, comme pour les emails.

Vérification :

Get-SafeAttachmentPolicy | Select-Object Name, Enable, EnableForInternalSenders
# Vérifier également dans les paramètres globaux

Portail Defender > Email & Collaboration > Politiques > Safe Attachments > Paramètres globaux : “Activer Defender pour Office 365 pour SharePoint, OneDrive et Microsoft Teams”

Remédiation :

Portail Defender > Safe Attachments > Paramètres globaux
Activer “Activer Microsoft Defender pour Office 365 pour SharePoint, OneDrive et Microsoft Teams”
Les utilisateurs seront bloqués s’ils tentent de télécharger un fichier détecté comme malveillant

4.1.7 — Activer la protection Safe Links pour Teams

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.TEAMS.8.1v1, MS.TEAMS.8.2v1

Description : Les URLs partagées dans les conversations Teams doivent être vérifiées au moment du clic, tout comme les URLs dans les emails. Des attaquants envoient des liens malveillants directement via Teams, contournant potentiellement les protections email si Safe Links n’est pas activé pour Teams.

Vérification :

Get-SafeLinksPolicy | Select-Object Name, EnableSafeLinksForTeams, TrackClicks, AllowClickThrough

Remédiation :

Dans la politique Safe Links : EnableSafeLinksForTeams = $true
TrackClicks = $true (suivi des clics pour les rapports)
AllowClickThrough = $false (l’utilisateur ne peut pas outrepasser le blocage)

4.1.8 — Contrôler le partage d’écran dans Teams

Niveau : 🟢 Faible Référence CIS : CIS Control 3.3

Description : Le partage d’écran non contrôlé peut conduire au partage accidentel d’informations confidentielles lors de réunions avec des participants externes.

Vérification :

Get-CsTeamsMeetingPolicy | Select-Object Identity, ScreenSharingMode, AllowParticipantGiveRequestControl

Remédiation :

ScreenSharingMode : SingleApplication (partage d’une seule application plutôt que tout l’écran)
AllowParticipantGiveRequestControl : Désactivé pour les réunions avec invités externes
Former les utilisateurs aux bonnes pratiques de partage d’écran

4.1.9 — Désactiver les 5 fournisseurs de stockage cloud tiers dans Teams

Niveau : 🟡 Moyen Référence CIS : 8.1.1 (L2) — Automated Profile : E3 Level 2

Description : Teams permet par défaut le partage de fichiers depuis 5 services cloud tiers : Box, Dropbox, Google Drive, Egnyte, ShareFile. Ces services contournent les politiques DLP, les étiquettes de sensibilité et l’audit M365. Les fichiers partagés depuis ces services ne bénéficient pas de la protection Safe Attachments et ne sont pas indexés dans Microsoft Purview.

Vérification :

Get-CsTeamsClientConfiguration | Select-Object AllowDropBox, AllowBox, AllowGoogleDrive, AllowShareFile, AllowEgnyte | Format-List
# Résultat attendu : Tous à False

Remédiation :

Set-CsTeamsClientConfiguration -AllowDropBox $false -AllowBox $false -AllowGoogleDrive $false -AllowShareFile $false -AllowEgnyte $false

Conserver uniquement SharePoint/OneDrive comme sources de fichiers approuvées.

Valeur par défaut : Tous les 5 fournisseurs tiers autorisés.

4.1.10 — Empêcher les communications avec les tenants Teams en mode trial

Niveau : 🟠 Élevé Référence CIS : 8.2.4 (L1) — Automated Profile : E3 Level 1

Description : Les tenants Teams en version d’essai (trial) ont des contrôles de sécurité moins stricts et peuvent être créés facilement par des attaquants pour tenter d’établir des communications avec votre organisation.

Vérification :

Get-CsTenantFederationConfiguration | Select-Object AllowTeamsConsumerInbound

Remédiation :

Set-CsTenantFederationConfiguration -AllowTeamsConsumerInbound $false

4.1.11 — Bloquer les utilisateurs Teams non gérés d’initier des conversations entrantes

Niveau : 🟠 Élevé Référence CIS : 8.2.3 (L1) — Automated Profile : E3 Level 1

Description : Des utilisateurs Teams non gérés (comptes personnels, Skype) peuvent initier des conversations avec vos utilisateurs si cette option n’est pas désactivée.

Vérification :

Get-CsExternalAccessPolicy -Identity Global | Select-Object EnableTeamsConsumerAccess

Remédiation :

Set-CsExternalAccessPolicy -Identity Global -EnableTeamsConsumerAccess $false

4.2 Sécurité des Réunions Teams — Contrôles Supplémentaires

4.2.1 — Empêcher les utilisateurs en appel entrant (dial-in) de bypasser le lobby

Niveau : 🟡 Moyen Référence CIS : 8.5.4 (L1) — Automated Profile : E3 Level 1

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object AllowPSTNUsersToBypassLobby

Remédiation :

Set-CsTeamsMeetingPolicy -Identity Global -AllowPSTNUsersToBypassLobby $false

4.2.2 — Désactiver le chat de réunion pour les utilisateurs anonymes

Niveau : 🟡 Moyen Référence CIS : 8.5.5 (L2) — Automated Profile : E3 Level 2

Description : Le chat visible par des participants anonymes peut être utilisé pour partager des liens malveillants cliqués par des participants internes.

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object MeetingChatEnabledType

Remédiation :

Set-CsTeamsMeetingPolicy -Identity Global -MeetingChatEnabledType "EnabledExceptAnonymous"

4.2.3 — Restreindre la présentation aux organisateurs et co-organisateurs

Niveau : 🟡 Moyen Référence CIS : 8.5.6 (L2) — Automated Profile : E3 Level 2

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object DesignatedPresenterRoleMode

Remédiation :

Set-CsTeamsMeetingPolicy -Identity Global -DesignatedPresenterRoleMode "OrganizerOnlyUserOverride"

4.2.4 — Désactiver le chat avec des participants externes post-réunion

Niveau : 🟡 Moyen Référence CIS : 8.5.8 (L2) — Automated Profile : E3 Level 2

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object AllowExternalNonTrustedMeetingChat

Remédiation :

Set-CsTeamsMeetingPolicy -Identity Global -AllowExternalNonTrustedMeetingChat $false

4.2.5 — Désactiver l’enregistrement automatique des réunions par défaut

Niveau : 🟡 Moyen Référence CIS : 8.5.9 (L2) — Automated Profile : E3 Level 2

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object AllowCloudRecording

Remédiation :

Set-CsTeamsMeetingPolicy -Identity Global -AllowCloudRecording $false

4.2.6 — Activer le signalement de problèmes de sécurité dans Teams

Niveau : 🟡 Moyen Référence CIS : 8.6.1 (L1) — Automated Profile : E3 Level 1

Description : Permet aux utilisateurs de signaler des messages suspects directement dans Teams — les signalements arrivent dans le portail Microsoft Defender pour analyse. Ce mécanisme de signalement interne accélère la détection des campagnes de phishing ciblant l’organisation via Teams.

Vérification :

Get-CsTeamsMessagingPolicy -Identity Global | Select-Object AllowSecurityEndUserReporting
# AllowSecurityEndUserReporting doit être True

Remédiation :

Set-CsTeamsMessagingPolicy -Identity Global -AllowSecurityEndUserReporting $true

Configurer l’adresse de destination : Portail Defender > Settings > Security incident reporting.

Valeur par défaut : Signalement de sécurité Teams désactivé.

Note : Le ZAP pour Teams (Zero-Hour Auto Purge) est couvert en Section 2.4.4 (Microsoft Defender for Office 365).

4.2.7 — Désactiver la publication automatique des enregistrements de réunions Teams

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.TEAMS.3.1v1 — Automated Profile : E3 Level 1

Description : Lorsque l’enregistrement automatique des réunions est activé avec la publication automatique, tous les participants — y compris les invités et utilisateurs externes — reçoivent immédiatement un lien vers l’enregistrement. Cette configuration peut provoquer des fuites involontaires de données sensibles discutées en réunion vers des personnes non autorisées. Un seul invité non identifié dans une réunion peut ainsi obtenir l’enregistrement complet d’une réunion confidentielle.

Vérification :

Get-CsTeamsMeetingPolicy -Identity Global | Select-Object Identity, AllowCloudRecording, AutoRecording, NewMeetingRecordingExpirationDays
# Vérifier : AutoRecording = "Disabled" OU si activé, l'accès post-réunion est contrôlé
# MS.TEAMS.3.1v1 : RecordingStorageMode ne doit pas permettre l'autopublish externe

Remédiation :

Teams Admin Center > Politiques de réunion > Politique globale
Désactiver “Enregistrement automatique des réunions” ou configurer la restriction post-réunion
Si l’enregistrement automatique est requis : configurer DesignatedPresenter = OrganizerAndCoOrganizersOnly
Restreindre l’accès aux enregistrements aux membres authentifiés uniquement :

Set-CsTeamsMeetingPolicy -Identity Global `
    -AllowRecordingStorageOrStreamUpload $false

Configurer la rétention/expiration automatique des enregistrements (recommandé : 60 jours)
Former les organisateurs à la politique d’enregistrement et à la gestion des accès post-réunion

Valeur par défaut : Les enregistrements sont publiés automatiquement et accessibles à tous les participants sans restriction.

SECTION 5 — SHAREPOINT ONLINE ET ONEDRIVE

5.1 Partage et Permissions

5.1.1 — Restreindre le partage SharePoint/OneDrive à des domaines spécifiques

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.3 MITRE ATT&CK : T1213.002 (Data from Cloud Storage: SharePoint) · T1530 (Data from Cloud Storage) · T1048.003 (Exfiltration Over Alternative Protocol: HTTP/HTTPS)

Description : Par défaut, SharePoint et OneDrive permettent le partage avec n’importe quelle adresse email externe. Restreindre le partage aux domaines partenaires approuvés réduit le risque d’exfiltration accidentelle ou malveillante de données.

Vérification :

SharePoint Admin Center > Partage > Paramètres de partage externe
PowerShell :

Get-SPOTenant | Select-Object SharingCapability, SharingDomainRestrictionMode, SharingAllowedDomainList

Remédiation :

Niveau de partage externe SharePoint : Invités existants uniquement OU Invités nouveaux et existants (selon besoins)
Activer la restriction par domaine : Autoriser uniquement les domaines spécifiques
OneDrive : même niveau ou plus restrictif que SharePoint
Désactiver “Tout le monde” (liens anonymes) pour les données sensibles

5.1.2 — Désactiver les liens de partage anonymes (“Anyone”)

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.3

Description : Les liens “Anyone” permettent à toute personne possédant le lien d’accéder au fichier sans authentification. Ces liens peuvent être partagés involontairement ou interceptés, menant à une fuite de données.

Vérification :

Get-SPOTenant | Select-Object DefaultSharingLinkType, DefaultLinkPermission

Remédiation :

SharePoint Admin Center > Paramètres > Partage
Désactiver les liens “Toute personne” ou définir une expiration maximale (ex: 7 jours)
Lien de partage par défaut : Personnes spécifiques (pas “Personnes de l’organisation”)
Permissions par défaut des liens : Affichage (pas Modification)

5.1.2b — Configurer une expiration obligatoire sur tous les liens anonymes (30 jours max)

Niveau : 🔴 Critique Référence CIS : CIS 7.2.9 (L1) — Automated Référence CISA SCuBA : MS.SHAREPOINT.3.2v1 Profile : E3 Level 1

Description : Lorsque les liens anonymes (“Anyone”) ne peuvent pas être complètement désactivés pour des raisons métier, une politique d’expiration obligatoire est indispensable. Sans expiration, un lien anonyme créé aujourd’hui reste valide indéfiniment, même si l’employé quitte l’entreprise ou si le fichier ne doit plus être partagé. Un attaquant qui intercepte ce lien peut accéder aux données sans limite de temps. Configurer une expiration maximale de 30 jours (idéalement 7 jours) limite drastiquement la fenêtre d’exposition.

Vérification :

# Vérifier la durée d'expiration des liens anonymes au niveau tenant
$tenant = Get-SPOTenant
$tenant | Select-Object RequireAnonymousLinksExpireInDays, DefaultLinkPermission, DefaultSharingLinkType

# Résultat attendu :
# RequireAnonymousLinksExpireInDays : entre 1 et 30 (valeur -1 = pas d'expiration = NON CONFORME)

SharePoint Admin Center > Stratégies > Partage > “Ces liens doivent expirer dans ce nombre de jours”

Remédiation :

# Définir l'expiration obligatoire à 30 jours maximum (recommandé : 7 jours)
Set-SPOTenant -RequireAnonymousLinksExpireInDays 30

# Idéalement pour les environnements sensibles
Set-SPOTenant -RequireAnonymousLinksExpireInDays 7

SharePoint Admin Center > Stratégies > Partage
Section “Liens anonymes” > “Ces liens doivent expirer dans ce nombre de jours” = 30 (ou moins)
Appliquer également la même politique au niveau de chaque site critique via :

# Appliquer sur un site spécifique
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" -AnonymousLinkExpirationInDays 7

Combiner avec une politique de rappel DLP qui détecte les liens anonymes sans expiration configurée

Valeur par défaut : -1 = Aucune expiration — les liens anonymes sont valides indéfiniment.

⚠️ Point critique (365Inspect — Inspect-SharepointLinkExpiry) : Ce paramètre est l’un des contrôles les plus fréquemment trouvés non conforme lors des audits M365. La valeur par défaut est systématiquement -1 (pas d’expiration) et n’est presque jamais modifiée sans audit proactif.

5.1.3 — Activer l’accès conditionnel pour SharePoint (accès non géré)

Niveau : 🟠 Élevé Référence CIS : CIS Control 12.1

Description : Les appareils non gérés (personnels) accédant à SharePoint peuvent télécharger et stocker localement des données d’entreprise sans contrôle. La politique d’accès non géré permet de restreindre ces appareils à un accès en lecture seule ou via navigateur uniquement.

Vérification :

Get-SPOTenant | Select-Object ConditionalAccessPolicy

Remédiation :

SharePoint Admin Center > Contrôle des accès > Appareils non gérés
Choisir : Autoriser un accès limité (navigateur uniquement, pas de téléchargement)
Ou bloquer complètement l’accès depuis des appareils non gérés

5.1.4 — Configurer la durée d’expiration des sessions SharePoint

Niveau : 🟢 Faible Référence CIS : CIS Control 4.3

Description : Des sessions SharePoint trop longues sur des appareils partagés ou non sécurisés augmentent le risque d’accès non autorisé si l’utilisateur oublie de se déconnecter.

Vérification :

Get-SPOTenant | Select-Object SignInAccelerationDomain, UsePersistentCookiesForExplorerView

Remédiation :

Activer la déconnexion automatique après inactivité via Accès Conditionnel
Pour les appareils non gérés : session max = 1 heure d’inactivité

5.1.5 — Configurer les permissions par défaut des liens en mode Affichage uniquement

Niveau : 🔴 Critique Référence CISA SCuBA : MS.SHAREPOINT.2.2v1 Profile : E3 Level 1

Description : Lorsqu’un utilisateur crée un lien de partage, la permission par défaut détermine si le destinataire peut modifier ou seulement consulter le fichier. Si la valeur par défaut est “Modification”, un utilisateur distrait peut partager involontairement des droits d’écriture sur des fichiers critiques. En définissant “Affichage uniquement” comme défaut, on suit le principe du moindre privilège.

Vérification :

$tenant = Get-SPOTenant
$tenant | Select-Object DefaultLinkPermission
# Valeur attendue : View (1 = View, 2 = Edit)
# Si DefaultLinkPermission = 2 (Edit) → NON CONFORME

Remédiation :

Set-SPOTenant -DefaultLinkPermission View

SharePoint Admin Center > Stratégies > Partage
Section “Liens de fichiers et de dossiers” > Autorisations par défaut : Affichage

Valeur par défaut : Edit (Modification) — les nouveaux liens accordent des droits d’écriture par défaut.

5.1.7 — Restreindre les liens “Anyone” à la permission Affichage uniquement

Niveau : 🔴 Critique Référence CISA SCuBA : MS.SHAREPOINT.3.2v1 Profile : E3 Level 1

Description : Même lorsque les liens anonymes (“Anyone”) sont autorisés pour des raisons métier, leur permission doit être limitée à Affichage uniquement. Un lien “Anyone” en modification permet à n’importe quelle personne possédant le lien de modifier, supprimer ou écraser des fichiers d’entreprise sans authentification.

Vérification :

$tenant = Get-SPOTenant
$tenant | Select-Object FileAnonymousLinkType, FolderAnonymousLinkType
# FileAnonymousLinkType = 1 (View) → CONFORME
# FileAnonymousLinkType = 2 (Edit) → NON CONFORME

Remédiation :

Set-SPOTenant -FileAnonymousLinkType View
Set-SPOTenant -FolderAnonymousLinkType View

SharePoint Admin Center > Stratégies > Partage
Section “Liens Toute personne” > Permissions : Affichage

Valeur par défaut : Edit — les liens anonymes accordent la modification par défaut.

5.1.8 — Exiger une ré-authentification périodique pour les codes de vérification email (≤ 30 jours)

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.SHAREPOINT.3.3v1 Profile : E3 Level 1

Description : Les utilisateurs externes accédant à SharePoint via un code de vérification email reçoivent un cookie de session persistant. Sans expiration configurée, ce cookie reste valide indéfiniment. Configurer une expiration à 30 jours ou moins force la ré-authentification périodique des invités, limitant la fenêtre d’exploitation d’un cookie volé.

Vérification :

$tenant = Get-SPOTenant
$tenant | Select-Object EmailAttestationRequired, EmailAttestationReAuthDays
# EmailAttestationRequired = True ET EmailAttestationReAuthDays ≤ 30 → CONFORME
# EmailAttestationRequired = False → NON CONFORME

Remédiation :

Set-SPOTenant -EmailAttestationRequired $true
Set-SPOTenant -EmailAttestationReAuthDays 30

SharePoint Admin Center > Stratégies > Partage
Section “Autres paramètres” > “Les personnes qui utilisent un code de vérification doivent s’authentifier de nouveau après” = 30 jours

Valeur par défaut : Ré-authentification désactivée — les cookies invités ne expirent jamais.

5.1.10 — Exiger l’authentification moderne pour SharePoint

Niveau : 🔴 Critique Référence CIS : 7.2.1 (L1) — Automated Profile : E3 Level 1

Description : SharePoint Online doit être configuré pour exiger l’authentification moderne (OAuth 2.0/OIDC). Les clients utilisant l’authentification basique contournent le MFA et l’Accès Conditionnel.

Vérification :

Get-SPOTenant | Select-Object LegacyAuthProtocolsEnabled

Doit retourner : False

Remédiation :

Set-SPOTenant -LegacyAuthProtocolsEnabled $false

5.1.11 — Activer l’intégration SharePoint/OneDrive avec Azure AD B2B

Niveau : 🟠 Élevé Référence CIS : 7.2.2 (L1) — Automated Profile : E3 Level 1

Description : L’intégration Azure AD B2B pour SharePoint et OneDrive permet d’utiliser les politiques d’accès conditionnel Entra ID pour les invités accédant aux fichiers partagés. Sans cette intégration, les invités contournent les politiques CA lors de l’accès aux liens de partage SharePoint.

Vérification :

Get-SPOTenant | Select-Object EnableAzureADB2BIntegration

Doit retourner : True

Remédiation :

Set-SPOTenant -EnableAzureADB2BIntegration $true

5.1.12 — Empêcher les invités SharePoint de partager des éléments qu’ils ne possèdent pas

Niveau : 🟠 Élevé Référence CIS : 7.2.5 (L2) — Automated Profile : E3 Level 2

Description : Par défaut, les invités peuvent repartager des fichiers ou dossiers qui ont été partagés avec eux, potentiellement avec d’autres personnes non autorisées. Cela crée des chaînes de partage incontrôlables.

Vérification :

Get-SPOTenant | Select-Object PreventExternalUsersFromResharing

Doit retourner : True

Remédiation :

Set-SPOTenant -PreventExternalUsersFromResharing $true

5.1.13 — Restreindre le partage externe SharePoint à un groupe de sécurité spécifique

Niveau : 🟠 Élevé Référence CIS : 7.2.8 (L2) + MS.SHAREPOINT.1.3v1 — Manual Profile : E3 Level 2

Description : Plutôt que d’autoriser tous les utilisateurs à partager en externe, restreindre cette capacité à un groupe de sécurité dédié (ex: “SPO-External-Sharing-Authorized”). Seuls les membres approuvés peuvent créer des liens de partage externe. Cela permet un contrôle granulaire par utilisateur et une traçabilité complète des partages externes.

Vérification :

Get-SPOTenant | Select-Object SharingAllowedDomainList, SharingBlockedDomainList, SharingDomainRestrictionMode, ExternalUserExpirationRequired | Format-List
# Vérifier aussi :
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/groupSettings" -Method GET | ConvertTo-Json -Depth 3

SharePoint Admin Center > Stratégies > Partage > “Autoriser uniquement les utilisateurs de groupes de sécurité spécifiques à partager en externe”

Remédiation :

SharePoint Admin Center > Stratégies > Partage
Activer “Autoriser uniquement les utilisateurs d’un groupe de sécurité spécifique”
Créer un groupe “SPO-External-Sharing-Authorized” avec les utilisateurs approuvés
Revue trimestrielle des membres du groupe
Documenter le processus d’ajout/retrait du groupe

Valeur par défaut : Tous les utilisateurs peuvent partager en externe (dans les limites du niveau de partage tenant).

5.1.14 — Configurer l’expiration automatique de l’accès guest à SharePoint/OneDrive

Niveau : 🟠 Élevé Référence CIS : 7.2.9 (L1) — Automated Profile : E3 Level 1

Description : Les accès guest SharePoint/OneDrive ne doivent pas durer indéfiniment. Une expiration automatique force la révision et le renouvellement des accès, garantissant que les ex-prestataires ou anciens partenaires perdent automatiquement l’accès.

Vérification :

Get-SPOTenant | Select-Object ExternalUserExpirationRequired, ExternalUserExpireInDays

Remédiation :

Set-SPOTenant -ExternalUserExpirationRequired $true -ExternalUserExpireInDays 60

CIS recommande 60 jours ou moins. Adapter selon la politique interne.

5.1.15 — Bloquer le téléchargement de fichiers infectés depuis SharePoint

Niveau : 🟠 Élevé Référence CIS : 7.3.1 (L2) — Automated Profile : E3 Level 2

Description : Par défaut, SharePoint peut permettre le téléchargement de fichiers détectés comme infectés (comportement attendu : afficher un avertissement mais permettre le téléchargement). La CIS recommande de bloquer complètement le téléchargement de fichiers infectés.

Vérification :

Get-SPOTenant | Select-Object DisallowInfectedFileDownload

Doit retourner : True

Remédiation :

Set-SPOTenant -DisallowInfectedFileDownload $true

5.1.16 — Restreindre la synchronisation OneDrive aux appareils gérés

Niveau : 🟠 Élevé Référence CIS : 7.3.2 (L2) — Automated Profile : E3 Level 2

Description : La synchronisation OneDrive sur des appareils non gérés (BYOD, appareils personnels) copie les données d’entreprise localement sur des machines sans contrôle Intune. En cas de compromission ou de perte de l’appareil, ces données sont exposées.

Vérification :

Get-SPOTenant | Select-Object BlockMacSync, OneDriveForGuestsEnabled
# Vérifier également la stratégie Intune pour la sync OneDrive

Remédiation :

# Restreindre la sync aux domaines Entra ID approuvés (appareils joints)
Set-SPOTenant -TenantRestrictionsDomains @("votre-tenant-id")

Ou via Intune : déployer la configuration OneDrive pour n’autoriser la sync que sur les appareils conformes.

5.1.17 — Bloquer les scripts personnalisés sur les sites SharePoint

Niveau : 🟡 Moyen Référence : M365-Assess SPO-SCRIPT-001/002 — Automated Licence requise : SharePoint Online

Description : Les scripts personnalisés (custom scripts) permettent d’exécuter du JavaScript et du code sur les sites SharePoint. Si un site SharePoint contient un script malveillant (XSS, injection), il s’exécute dans le contexte des utilisateurs qui visitent le site avec leurs credentials M365.

Vérification :

# Vérifier la politique globale des scripts personnalisés
Get-SPOTenant | Select-Object DenyAddAndCustomizePages
# DenyAddAndCustomizePages doit être True (scripts désactivés)

# Vérifier les sites spécifiques autorisant les scripts
Get-SPOSite -Limit All | Where-Object { $_.DenyAddAndCustomizePages -eq "Disabled" } | Select-Object Url, Title

Remédiation :

# Désactiver les scripts sur tous les sites
Set-SPOTenant -DenyAddAndCustomizePages $true
# Pour un site spécifique :
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/DevSite" -DenyAddAndCustomizePages Enabled

Valeur par défaut : Scripts personnalisés désactivés globalement, mais certains sites anciens peuvent avoir des exceptions.

SECTION 6 — PROTECTION DE L’INFORMATION ET CONFORMITÉ

6.1 Microsoft Purview (anciennement Compliance Center)

6.1.1 — Activer l’Audit Unifié (Unified Audit Log)

Niveau : 🔴 Critique Référence CIS : CIS Control 8.2 MITRE ATT&CK : T1562.008 (Impair Defenses: Disable Cloud Logs) · T1070.003 (Indicator Removal: Clear Command History) · T1490 (Inhibit System Recovery)

Description : L’Audit Log unifié enregistre l’ensemble des activités administratives et utilisateur dans M365 (emails, fichiers, connexions, modifications de configuration). Sans ce journal, toute investigation forensic après incident est impossible. Depuis 2023, l’audit est activé par défaut pour les nouveaux tenants, mais doit être vérifié.

Vérification :

Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

Remédiation :

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Vérifier que la rétention est de 90 jours (standard) ou 180/365 jours (avec licences E5/Audit Premium)
Exporter les journaux vers un SIEM externe pour rétention longue durée
Configurer des alertes sur les activités critiques

6.1.2 — Configurer des politiques de rétention des données

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.11

Description : Les politiques de rétention permettent de conserver les données pendant la durée légale requise et de les supprimer automatiquement ensuite. Sans politiques de rétention, l’organisation risque soit de supprimer des preuves nécessaires aux investigations, soit de conserver indéfiniment des données inutiles augmentant les risques.

Vérification :

Microsoft Purview > Gestion du cycle de vie des données > Stratégies de rétention
Vérifier l’existence de politiques couvrant Exchange, SharePoint, OneDrive, Teams

Remédiation :

Créer des politiques de rétention selon les exigences légales du secteur (ex: 5 ans pour données financières, 3 ans pour emails standard)
Appliquer aux emplacements : Exchange, SharePoint, OneDrive, Teams Channel Messages, Teams Chats
Configurer la suppression automatique après la période de rétention

6.1.3 — Activer la prévention des pertes de données (DLP)

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.13

Description : Les politiques DLP détectent et empêchent le partage d’informations sensibles (numéros de carte bancaire, NIR, IBAN, données personnelles RGPD) via email, SharePoint, Teams ou OneDrive.

Vérification :

Microsoft Purview > Prévention des pertes de données > Stratégies
Vérifier les politiques actives et leurs périmètres

Remédiation :

Créer des politiques DLP pour les types d’informations sensibles pertinents (RGPD France, données financières, données de santé)
Actions recommandées : Bloquer le partage externe, notifier l’utilisateur, alerter l’administrateur
Activer en mode simulation d’abord pour mesurer le volume de faux positifs
Couvrir : Exchange, SharePoint, OneDrive, Teams, Endpoints (si Defender for Endpoint)

6.1.4 — Activer les étiquettes de sensibilité (Sensitivity Labels)

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.1 Licence requise : Microsoft 365 E3 ou supérieur avec AIP P1

Description : Les étiquettes de sensibilité permettent de classifier les documents et emails selon leur niveau de confidentialité (Public, Interne, Confidentiel, Strictement Confidentiel). Ces étiquettes peuvent déclencher automatiquement des protections (chiffrement, marquage visuel, restrictions d’accès).

Vérification :

Microsoft Purview > Protection des informations > Étiquettes

Remédiation :

Créer une taxonomie d’étiquettes adaptée à l’organisation (ex: Public / Interne / Confidentiel / Secret)
Configurer les étiquettes avec : marquage visuel (en-tête, pied de page), chiffrement pour les niveaux élevés, restrictions de partage externe
Déployer le client AIP ou l’étiquetage intégré dans les apps M365
Activer l’étiquetage automatique pour certains types de données

6.1.5 — Activer Microsoft Purview Communication Compliance

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.3 Licence requise : Microsoft 365 E5 Compliance

Description : Communication Compliance permet de détecter les communications à risque : harcèlement, divulgation d’informations confidentielles, mots clés réglementaires. Essentiel pour les secteurs financiers et régulés.

Vérification :

Microsoft Purview > Communication Compliance

Remédiation :

Créer des politiques de surveillance pour les canaux de communication (Email, Teams)
Configurer les mots clés et classifieurs appropriés au secteur
Désigner des réviseurs indépendants des personnes surveillées

6.1.6 — Configurer Microsoft Purview Insider Risk Management

Niveau : 🟠 Élevé Référence CIS : CIS Control 3.3 + 13.1 Licence requise : Microsoft 365 E5 Compliance ou Microsoft 365 E5

Description : L’Insider Risk Management de Microsoft Purview détecte les comportements anormaux des utilisateurs internes qui pourraient indiquer une exfiltration de données, une sabotage volontaire ou une compromission de compte. Les indicateurs surveillés incluent : téléchargements massifs avant la démission, partages externes anormaux, accès à des données hors périmètre habituel, utilisation d’appareils USB non autorisés. Ce contrôle est particulièrement critique pour les organisations avec des données sensibles ou soumises à des exigences RGPD/NIS2.

Séquence de détection :

Déclencheur (ex: préavis HR) → Indicateurs comportementaux (téléchargements > seuil)
→ Score de risque → Alerte investigateur → Action (Legal Hold, restriction accès)

Vérification :

Microsoft Purview > Insider Risk Management > Tableau de bord
Vérifier l’existence d’au moins une politique de gestion des risques internes active
Vérifier que les connecteurs HR sont configurés (si disponibles)

# Vérifier via Graph API (nécessite permissions Compliance)
# Microsoft Purview > Insider Risk Management > Policies
# Vérifier : au moins 1 politique active couvrant "Data leaks" ou "Data theft by departing users"

Remédiation :

Microsoft Purview > Insider Risk Management > Créer une politique
Configurer en priorité les politiques :
- Fuites de données : détection téléchargements/partages anormaux
- Vol de données par les utilisateurs partants : déclenché par signal HR (préavis, résiliation)
Configurer les seuils d’alerte adaptés à l’organisation (éviter les faux positifs)
Désigner un groupe d’investigateurs IR indépendants (séparation des responsabilités)
Connecter le connecteur HR RH Microsoft 365 pour les signaux de départ d’employés
Activer l’intégration avec Microsoft Defender for Cloud Apps pour enrichir les signaux

Valeur par défaut : Insider Risk Management non configuré — aucune détection des comportements internes à risque.

SECTION 7 — SÉCURITÉ DES APPAREILS (INTUNE/MICROSOFT ENDPOINT MANAGER)

7.1 Gestion des Appareils

7.1.1 — Exiger le chiffrement des appareils (BitLocker)

Niveau : 🔴 Critique Référence CIS : CIS Control 3.6

Description : Le chiffrement des disques durs protège les données en cas de perte ou vol d’un appareil. Sans BitLocker, toutes les données M365 synchronisées localement sont accessibles par quiconque obtient physiquement l’appareil.

Vérification :

Intune > Appareils > Politiques de conformité
Vérifier l’existence d’une politique exigeant BitLocker

Remédiation :

Intune > Sécurité des points de terminaison > Chiffrement de disque > Créer une politique
Exiger BitLocker activé sur tous les appareils Windows
Configurer le dépôt automatique des clés BitLocker dans Entra ID
Politique de conformité : appareil non conforme (BitLocker absent) = accès bloqué

7.1.2 — Exiger un code PIN/mot de passe sur les appareils mobiles

Niveau : 🟠 Élevé Référence CIS : CIS Control 4.1

Description : Les smartphones accédant aux données M365 (email, Teams, OneDrive) doivent être protégés par un code PIN ou biométrie. Un téléphone sans verrouillage d’écran expose directement les données d’entreprise.

Vérification :

Intune > Appareils > Politiques de conformité > iOS/Android
Vérifier les exigences de verrouillage d’écran

Remédiation :

Politique de conformité iOS : PIN minimum 6 caractères, biométrie acceptée
Politique de conformité Android : PIN minimum 6 caractères, chiffrement exigé
App Protection Policies (MAM) pour les appareils non gérés accédant aux apps M365

7.1.3 — Configurer les App Protection Policies (MAM)

Niveau : 🟠 Élevé Référence CIS : CIS Control 2.7

Description : Les politiques de protection des applications (MAM) permettent de sécuriser les données M365 sur des appareils non gérés (BYOD) sans nécessiter l’inscription MDM. Elles isolent les données d’entreprise dans un conteneur sécurisé.

Vérification :

Intune > Applications > Stratégies de protection des applications

Remédiation :

Créer des politiques MAM pour iOS et Android ciblant les apps M365 (Outlook, Teams, OneDrive, SharePoint)
Configurer : Copier/Coller restreint entre apps gérées et non gérées, Capture d’écran désactivée, Chiffrement des données app, Wipe sélectif des données d’entreprise si non conformité

7.1.4 — Activer Windows Hello for Business

Niveau : 🟡 Moyen Référence CIS : CIS Control 5.2

Description : Windows Hello for Business remplace les mots de passe par une authentification biométrique ou PIN local, et utilise des clés cryptographiques liées à l’appareil. C’est une authentification résistante au phishing car elle ne transmet pas de credentials réseau.

Vérification :

Intune > Appareils > Profils de configuration > Windows Hello for Business

Remédiation :

Intune > Appareils > Inscription > Inscription Windows > Windows Hello for Business
Activer Windows Hello for Business pour tous les appareils
Exiger un PIN de 6 chiffres minimum (8 recommandé)
Activer la biométrie (empreinte digitale, reconnaissance faciale)

7.1.5 — Marquer les appareils sans politique de conformité comme Non conformes

Niveau : 🟠 Élevé Référence CIS : CIS 4.1 (L2) — Automated Profile : E3 Level 2

Description : Par défaut, les appareils sans politique de conformité assignée sont marqués “Conformes” dans Intune — ce qui peut permettre un accès aux ressources protégées par Accès Conditionnel (CA) sans aucun contrôle de conformité. La configuration recommandée est “Non conforme” pour forcer l’assignation d’une politique à chaque appareil.

Vérification :

$Uri = 'https://graph.microsoft.com/v1.0/deviceManagement/settings'
(Invoke-MgGraphRequest -Uri $Uri -Method GET).secureByDefault
# Valeur attendue : True

Ou via Intune > Appareils > Conformité > Paramètres de conformité > “Appareils sans politique de conformité” = Non conforme.

Remédiation :

Intune Admin Center > Appareils > Conformité > Paramètres de conformité
“Marquer les appareils sans politique de conformité assignée comme” → Non conforme
Déployer ensuite des politiques de conformité pour chaque plateforme (Windows, iOS, Android, macOS)

7.1.6 — Bloquer l’inscription d’appareils personnels (BYOD) par défaut

Niveau : 🟠 Élevé Référence CIS : CIS 4.2 (L2) — Automated Profile : E3 Level 2

Description : Les restrictions d’inscription permettent de bloquer l’inscription d’appareils personnels dans Intune. Un attaquant ayant compromis un compte et contourné l’Accès Conditionnel peut inscrire un appareil personnel pour obtenir un point d’ancrage persistant, simuler une conformité, et réaliser une reconnaissance ou un mouvement latéral.

Vérification :

$Uri = 'https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations'
$Config = (Invoke-MgGraphRequest -Uri $Uri -Method GET).value |
    Where-Object { $_.id -match 'DefaultPlatformRestrictions' -and $_.priority -eq 0 }
$Config | Select-Object -ExpandProperty windowsRestriction | Select-Object personalDeviceEnrollmentBlocked
# Valeur attendue : True pour toutes les plateformes

Remédiation :

Intune > Appareils > Inscription des appareils > Restriction de plateforme
Politique de priorité par défaut > Modifier les paramètres de plateforme
Colonne “Appareils personnels” → Bloquer pour toutes les plateformes (Windows, iOS, Android, macOS)

7.1.7 — Activer Intune Multi-Admin Approval (MAA) pour les actions critiques

Niveau : 🟠 Élevé Référence : Maester MT.1096 + M365-Assess INTUNE-MAA-001 — Automated Licence requise : Microsoft Intune Plan 1

Description : Le Multi-Admin Approval (MAA) d’Intune exige qu’une seconde approbation d’un autre administrateur soit obtenue avant d’exécuter des actions critiques (suppression massive d’appareils, modification de politiques de conformité, déploiement de scripts). Cela protège contre les erreurs humaines, les comptes admin compromis et les insider threats.

Vérification :

# Vérifier les politiques MAA Intune
$maaApprovals = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/deviceManagement/approvalWorkflowProviders" -Method GET -ErrorAction SilentlyContinue
if ($maaApprovals.value.Count -gt 0) {
    Write-Host "✅ Intune MAA configuré — $($maaApprovals.value.Count) politiques" -ForegroundColor Green
    $maaApprovals.value | Select-Object displayName, isEnabled | Format-Table
} else {
    Write-Host "❌ Intune MAA non configuré" -ForegroundColor Red
}

Remédiation :

Intune Admin Center > Administration des locataires > Approbations multi-administrateur
Créer des workflows d’approbation pour : Scripts, Applications, Politiques de conformité
Configurer les approbateurs : au moins 2 admins distincts
Les demandes expirent après 72h sans approbation

Valeur par défaut : Aucun MAA configuré — toutes les actions admin s’exécutent instantanément.

7.1.8 — Vérifier que l’autorité MDM est définie sur Intune

Niveau : 🟠 Élevé Référence : Maester MT.1105 — Automated Licence requise : Microsoft Intune

Description : L’autorité MDM détermine quelle solution gère les appareils mobiles. Si elle est définie sur “SCCM” ou “None” au lieu d’“Intune”, les politiques Intune ne s’appliquent pas aux appareils mobiles, laissant les appareils iOS/Android sans gestion.

Vérification :

$mdmAuthority = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/organization" -Method GET
$mdmAuthority.value[0] | Select-Object mobileDeviceManagementAuthority
# Valeur attendue : intune

Remédiation :

Intune Admin Center > Administration des locataires > Autorité MDM
Définir sur “Intune” si ce n’est pas déjà le cas

Valeur par défaut : Intune si déployé via M365, mais peut être défini sur SCCM en environnement hybride.

7.1.9 — Configurer le nettoyage automatique des appareils inactifs Intune

Niveau : 🟡 Moyen Référence : Maester MT.1053 — Automated Licence requise : Microsoft Intune

Description : Les appareils inscrits dans Intune mais inactifs depuis longtemps (ex: appareils d’anciens employés, appareils remplacés) consomment des licences et faussent les rapports de conformité. Une règle de nettoyage automatique supprime ces appareils après un délai configurable.

Vérification :

$cleanupRule = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDeviceCleanupSettings" -Method GET
$cleanupRule | Select-Object deviceInactivityBeforeRetirementInDays
# Valeur attendue : entre 30 et 90 jours

Remédiation :

Intune Admin Center > Appareils > Règles de nettoyage des appareils
Activer la règle de nettoyage automatique
Seuil d’inactivité recommandé : 90 jours

Valeur par défaut : Aucune règle de nettoyage — les appareils inactifs restent indéfiniment.

7.2 Microsoft Defender for Endpoint — Durcissement

7.2.1 — Activer la protection anti-falsification (Tamper Protection)

Niveau : 🔴 Critique Référence : CIS Microsoft 365 Benchmark — Automated

Description : La Tamper Protection empêche les attaquants (et les malwares) de désactiver ou modifier les composants de Microsoft Defender Antivirus via le registre, PowerShell ou des outils tiers. Sans Tamper Protection, un attaquant ayant accès local ou via SYSTEM peut silencieusement désactiver la protection en temps réel avant d’exécuter son payload. C’est l’une des premières actions que les ransomwares modernes tentent. MITRE ATT&CK : T1562.001 (Impair Defenses: Disable or Modify Tools)

Vérification :

# Via Microsoft Graph (Intune)
$configs = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations" -Method GET
$configs.value | Where-Object { $_.oDataType -match "windows10EndpointProtection" } |
    Select-Object displayName, @{N="TamperProtection"; E={ $_.defenderTamperProtection }}
# Valeur attendue : enable

Ou dans Defender Portal > Paramètres > Fonctionnalités avancées > Tamper Protection = Activé

Remédiation :

Intune > Sécurité des points de terminaison > Antivirus > Créer une politique Windows Antivirus
Activer Tamper Protection = Activé
Appliquer à tous les groupes d’appareils Windows
Vérifier via Defender Portal > Paramètres > Protection contre les falsifications

Valeur par défaut : Désactivée sur les appareils non gérés par Intune/MDE.

7.2.2 — Configurer les règles de réduction de la surface d’attaque (ASR Rules)

Niveau : 🔴 Critique Référence : CIS Microsoft 365 Benchmark + NIST SP 800-53 SI-3

Description : Les règles ASR (Attack Surface Reduction) bloquent des comportements spécifiques utilisés par les malwares : macros Office injectant du shellcode, lancement de processus fils depuis Office/Adobe, création de processus via WMI, vol de credentials depuis LSASS, etc. Ces règles sont la couche de défense la plus efficace contre les vecteurs d’attaque modernes (phishing, living-off-the-land). MITRE ATT&CK : T1566 (Phishing) · T1055 (Process Injection) · T1059 (Command and Scripting Interpreter) · T1003.001 (LSASS Memory)

Vérification :

# Vérifier les règles ASR configurées via MDE
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
# Les GUID des règles critiques et leurs actions (0=Off, 1=Block, 2=Audit, 6=Warn)

Defender Portal > Gestion de la configuration > Politiques de sécurité des points de terminaison > Règles ASR

Remédiation : Configurer via Intune (Endpoint Security > Attack Surface Reduction) les règles critiques en mode Block :

Règle	GUID	Mode recommandé
Bloquer les contenus exécutables des emails	BE9BA2D9-…	Block
Bloquer Office de créer des processus fils	D4F940AB-…	Block
Bloquer les injections dans d’autres processus	75668C1F-…	Block
Bloquer le vol de credentials depuis LSASS	9E6C4E1F-…	Block
Bloquer PowerShell obfusqué	5BEB7EFE-…	Block
Bloquer les macros Win32 depuis Office	92E97FA1-…	Block
Bloquer les processus issus de commandes PSExec/WMI	D1E49AAC-…	Block

Déploiement recommandé : démarrer en mode Audit pendant 2 semaines pour identifier les faux positifs, puis basculer en Block.

Valeur par défaut : Toutes les règles ASR désactivées.

7.2.3 — Activer la protection réseau (Network Protection)

Niveau : 🟠 Élevé Référence : CIS Microsoft 365 Benchmark

Description : La Network Protection étend les capacités de SmartScreen à tout le trafic réseau sortant, bloquant les connexions vers des domaines malveillants, serveurs C2 connus et URLs de phishing — même depuis des applications non-navigateur (PowerShell, cmd.exe, malwares custom). C’est une couche critique contre les attaques de type C2 callback. MITRE ATT&CK : T1071 (Application Layer Protocol) · T1041 (Exfiltration Over C2 Channel)

Vérification :

Get-MpPreference | Select-Object EnableNetworkProtection
# 0 = Disabled | 1 = Enabled (Block) | 2 = Audit
# Valeur attendue : 1 (Block)

Remédiation :

# Via Intune — Endpoint Security > Attack Surface Reduction > Network Protection = Block
Set-MpPreference -EnableNetworkProtection Enabled  # Pour test local uniquement

Intune > Sécurité des points de terminaison > Réduction de la surface d’attaque
Créer une politique > Protection réseau = Activé (mode Bloquer)
Déployer sur tous les groupes d’appareils Windows gérés

Valeur par défaut : Désactivée.

7.2.4 — Configurer l’investigation et la réponse automatisées (AIR) en mode complet

Niveau : 🟠 Élevé Référence : MS.DEFENDER.1.5v1

Description : L’Automated Investigation and Response (AIR) de Microsoft Defender for Endpoint analyse automatiquement les alertes, collecte des preuves et peut remédier automatiquement aux menaces. En mode “Approbation requise” (semi-automatique), les actions de remédiation attendent une validation humaine. En mode “Automatique complet”, MDE remédie directement aux menaces non critiques, réduisant le temps de réponse de heures à minutes. MITRE ATT&CK : M1038 (Execution Prevention) · M1040 (Behavior Prevention on Endpoint)

Vérification :

Defender Portal > Paramètres > Points de terminaison > Groupes d’appareils
Vérifier le niveau d’automatisation de chaque groupe : valeur attendue = Complet

Remédiation :

Defender Portal (security.microsoft.com) > Paramètres > Système > Groupes d’appareils
Pour chaque groupe : modifier le niveau d’automatisation = Complet - corriger les menaces automatiquement
S’assurer que tous les appareils sont rattachés à un groupe avec automatisation complète

Valeur par défaut : Semi-automatique (approbation requise pour la remédiation).

7.2.5 — Activer Microsoft Defender Antivirus en mode protection en temps réel

Niveau : 🔴 Critique Référence : CIS 9.4.1

Description : La protection en temps réel de Microsoft Defender Antivirus scanne les fichiers à l’ouverture, à l’écriture et à l’exécution. Sa désactivation — même temporaire — crée une fenêtre d’exposition critique. Des GPO ou scripts malveillants peuvent la désactiver. Surveiller son état via Intune garantit une couverture continue.

Vérification :

# Vérifier via Intune — Rapport de conformité antivirus
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices?`$filter=operatingSystem eq 'Windows'" -Method GET |
    Select-Object -ExpandProperty value | Select-Object deviceName, isEncrypted, complianceState
# Ou via Defender Portal > Rapports > Appareils à risque

Remédiation :

Intune > Sécurité des points de terminaison > Antivirus > Créer une politique Microsoft Defender Antivirus
Activer : Protection en temps réel = Oui, Protection fournie par le cloud = Oui, Soumission automatique d’échantillons = Oui
Configurer une alerte sur les appareils ayant la protection en temps réel désactivée

Valeur par défaut : Activée par défaut, mais peut être désactivée localement sans Intune.

SECTION 8 — MICROSOFT SECURE SCORE ET MONITORING

8.1 Secure Score et Alertes

8.1.1 — Atteindre et maintenir un Secure Score ≥ 50%

Niveau : 🟠 Élevé Référence CIS : CIS Control 1.1

Description : Le Microsoft Secure Score est un indicateur de la posture de sécurité du tenant M365. Un score bas indique de nombreuses mesures de sécurité non implémentées. Le score doit être mesuré régulièrement et les améliorations priorisées.

Vérification :

Portail Microsoft Defender > Secure Score
Documenter le score actuel et la tendance

Remédiation :

Portail Defender > Secure Score > Actions recommandées
Prioriser les actions par : Impact élevé, Facilité d’implémentation
Assigner des responsables pour chaque action
Définir un objectif de score cible (ex: +10 points par trimestre)
Exclure les recommandations non applicables (avec justification documentée)

8.1.2 — Configurer les alertes de sécurité obligatoires Exchange/Defender

Niveau : 🔴 Critique Référence CISA SCuBA : MS.EXO.16.1v1, MS.DEFENDER.5.1v1 Référence : BOD 25-01

Description : La CISA impose l’activation d’un ensemble minimum d’alertes dans M365 pour les organisations. Ces alertes couvrent les principaux vecteurs d’attaque : compromission de comptes d’envoi, activités de connecteurs suspects, transferts d’emails malveillants, etc.

Vérification :

Microsoft Purview > Alertes > Stratégies d’alerte
Vérifier que les alertes suivantes sont actives et ont des destinataires configurés :

Liste des alertes CISA obligatoires :

1. Patterns d'envoi d'emails suspects détectés
2. Activité suspecte du connecteur
3. Activité suspecte de transfert d'emails
4. Les messages ont été retardés
5. Tenant restreint de l'envoi d'emails non provisionnés
6. Tenant restreint de l'envoi d'emails
7. Un clic sur une URL potentiellement malveillante a été détecté

Remédiation :

Microsoft Purview > Alertes > Stratégies d’alerte
Activer chacune des alertes listées ci-dessus
Configurer les destinataires : adresse email SOC ou RSSI
Tester les alertes via des simulations d’activités suspectes

8.1.3 — Configurer des alertes de sécurité personnalisées

Niveau : 🟠 Élevé Référence CIS : CIS Control 8.11

Description : Des alertes proactives permettent de détecter rapidement les incidents de sécurité : connexions suspectes, activation de règles de transfert malveillantes, tentatives de connexion depuis des pays inhabituels, alertes administratives critiques.

Vérification :

Microsoft Purview > Alertes > Stratégies d’alerte
Portail Defender > Incidents & Alertes

Remédiation :

Activer les politiques d’alerte par défaut (déjà disponibles dans M365)
Créer des alertes personnalisées pour :
- Connexion depuis un pays jamais vu
- Création de règle de transfert d’emails
- Téléchargement massif de fichiers (> 50 fichiers en < 5 min)
- Activation/désactivation MFA sur un compte admin
- Connexion sur les comptes break glass
- Attribution du rôle Global Administrator
Configurer les destinataires des notifications (SOC, RSSI)

8.1.4 — Activer Microsoft Defender for Identity (si AD hybride)

Niveau : 🟠 Élevé Référence CIS : CIS Control 8.11 Licence requise : Microsoft 365 E5 ou Defender for Identity standalone

Description : Defender for Identity surveille le trafic Active Directory on-premises et dans le cloud pour détecter les comportements suspects : Golden Ticket, Pass-the-Hash, reconnaissance LDAP, escalade de privilèges.

Vérification :

Portail Defender > Paramètres > Identités
Vérifier que les capteurs sont installés sur tous les contrôleurs de domaine

Remédiation :

Créer un compte de service dédié pour Defender for Identity
Installer les capteurs sur tous les Domain Controllers
Configurer les notifications et intégration SIEM
Réviser les alertes hebdomadairement

8.1.5 — Activer Microsoft Defender for Cloud Apps (CASB)

Niveau : 🟠 Élevé Référence CIS : CIS Control 8.11 Licence requise : Microsoft 365 E5 Security

Description : Defender for Cloud Apps (anciennement MCAS) est un Cloud Access Security Broker qui permet la visibilité et le contrôle des applications cloud utilisées dans l’organisation (Shadow IT), la détection d’anomalies comportementales, et la protection contre les menaces avancées.

Vérification :

Portail Defender > Cloud Apps > Tableau de bord

Remédiation :

Connecter les applications cloud principales (M365, Salesforce, Box, etc.)
Activer Cloud Discovery pour identifier le Shadow IT
Configurer des politiques d’anomalie détectant : voyage impossible, téléchargements massifs, activités depuis des adresses IP anonymes
Intégrer avec Accès Conditionnel pour le contrôle d’application en temps réel

8.1.6 — Activer et configurer la protection des comptes prioritaires

Niveau : 🟠 Élevé Référence CIS : CIS 2.4.1 (L1) — Manual Profile : E5 Level 1 Licence requise : Microsoft Defender for Office 365 Plan 2

Description : La protection des comptes prioritaires offre une surveillance et une protection renforcées pour les utilisateurs à haute valeur : dirigeants, DSI, DRH, responsables financiers, comptes IT admin. Ces comptes sont les cibles privilégiées du whaling (spear-phishing ciblant les cadres dirigeants).

Vérification :

Microsoft Defender > Paramètres > Email & collaboration > Protection des comptes prioritaires
Vérifier que la protection est activée
Microsoft Defender > Paramètres > Email & collaboration > Balises utilisateur
Vérifier que les comptes critiques sont tagués “Compte prioritaire”

Remédiation :

Defender > Paramètres > Email & collaboration > Protection des comptes prioritaires → Activer
Defender > Paramètres > Email & collaboration > Balises utilisateur → Ajouter les dirigeants, admins IT, équipe financière comme “Comptes prioritaires”
Configurer des alertes email pour les activités des comptes prioritaires

8.1.7 — Appliquer le preset de sécurité Strict aux comptes prioritaires

Niveau : 🟠 Élevé Référence CIS : CIS 2.4.2 (L1) — Automated Profile : E5 Level 1 Licence requise : Microsoft Defender for Office 365 Plan 2

Description : Les comptes prioritaires (dirigeants, IT admins) doivent bénéficier de la protection preset “Stricte” de Defender for Office 365 — le niveau le plus agressif couvrant : anti-spam, anti-malware, anti-phishing avec protection contre l’usurpation, Safe Attachments et Safe Links.

Note : Les presets ne peuvent pas cibler des balises Priority Account — utiliser des groupes de sécurité à la place.

Vérification :

Defender > Email & collaboration > Politiques et règles > Politiques de menaces > Politiques de sécurité prédéfinies
Vérifier que “Strict Preset Security Policy” inclut les groupes contenant les comptes prioritaires

Remédiation :

Defender > Email & collaboration > Politiques et règles > Politiques de sécurité prédéfinies
Cliquer “Gérer les paramètres de protection” pour la protection Stricte
Ajouter le groupe des comptes prioritaires aux sections EOP Protection et Defender Protection
Configurer la protection contre l’usurpation d’identité (usurpation d’utilisateurs internes et de domaines partenaires)

8.1.8 — Configurer des alertes d’activité pour les comptes d’accès d’urgence (Break Glass)

Niveau : 🔴 Critique Référence CIS : CIS 2.2.1 (L1) — Manual Profile : E5 Level 1

Description : Les comptes Break Glass ne doivent être utilisés qu’en cas d’urgence absolue (blocage de tous les autres admins). Toute connexion avec ces comptes doit déclencher immédiatement une alerte à l’équipe sécurité — il peut s’agir d’une urgence légitime ou d’une compromission critique.

Vérification :

Microsoft Defender > Politiques et règles > Gestion des alertes > Politiques d’alertes
Vérifier l’existence d’une alerte sur “Connexion” pour les UPNs des comptes Break Glass

Remédiation :

Microsoft Defender > Politiques et règles > Gestion des alertes
Créer une politique d’alerte : Activité = “Connexion réussie”, Utilisateurs = [UPN des comptes Break Glass]
Configurer une notification immédiate vers le RSSI et l’équipe SOC
Tester l’alerte trimestriellement en se connectant avec un compte Break Glass en conditions contrôlées

8.1.9 — Détecter les credentials admins exposés sur des endpoints vulnérables (XSPM)

Niveau : 🟠 Élevé Référence : Maester MT.1080 (XSPM) — Automated MITRE ATT&CK : T1552 (Unsecured Credentials) · T1078.004 (Valid Accounts: Cloud) · T1555 (Credentials from Password Stores) Licence requise : Microsoft Defender XDR P2

Description : Microsoft Defender Exposure Management (XSPM) détecte lorsque des credentials d’utilisateurs hautement privilégiés (Global Admins, Security Admins) ont été utilisés sur des endpoints vulnérables ou compromis. Si un admin se connecte sur un poste non patché ou infecté, ses credentials peuvent être exposés via un credential dump. Ce contrôle croise les données Defender avec les données d’identité Entra.

Vérification :

# Via l'API Defender Exposure Management
$exposedCredentials = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/security/exposureManagement/attackPaths?`$filter=contains(targetId,'GlobalAdmin')" -Method GET -ErrorAction SilentlyContinue
if ($exposedCredentials) {
    $exposedCredentials.value | Select-Object displayName, risk | Format-Table
} else {
    Write-Host "Vérifier dans le portail Microsoft Defender > Gestion de l'exposition > Chemins d'attaque"
}

Microsoft Defender XDR > Gestion de l’exposition > Chemins d’attaque > Filtrer par admins privilégiés

Remédiation :

Identifier les endpoints vulnérables utilisés par des admins privilégiés
Patcher immédiatement ou isoler ces endpoints via Intune
Forcer une réinitialisation MFA et mot de passe pour les admins concernés
Déployer Windows Credential Guard sur tous les postes d’administration

Valeur par défaut : Non configuré — nécessite Defender XDR P2.

8.1.10 — Implémenter la détection de dérive de configuration (Configuration Drift)

Niveau : 🟡 Moyen Référence : Maester MT.1060 — Automated Licence requise : Entra ID P1

Description : La dérive de configuration (configuration drift) survient lorsque des paramètres de sécurité sont modifiés sans suivi. Un export JSON de l’état de référence (baseline) permet de détecter les changements non autorisés. Maester propose un mécanisme de comparaison JSON automatisé via CI/CD.

Vérification :

# Exporter l'état de référence des politiques CA
$baseline = Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json -Depth 5
$baseline | Out-File "C:\Security\CA_Baseline_$(Get-Date -Format 'yyyy-MM-dd').json"

# Comparer avec une baseline existante
$current = Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json -Depth 5
$reference = Get-Content "C:\Security\CA_Baseline_reference.json"
if ($current -ne $reference) {
    Write-Host "⚠️ DRIFT DÉTECTÉ : les politiques CA ont changé depuis la baseline" -ForegroundColor Yellow
}

Remédiation :

Créer une baseline JSON mensuelle de la configuration de sécurité (CA, auth methods, PIM)
Intégrer la comparaison dans un pipeline CI/CD ou une tâche planifiée
Alerter sur toute dérive non autorisée
Maester peut être exécuté en mode monitoring continu pour ce contrôle

Valeur par défaut : Aucun mécanisme de détection de dérive — les changements de config passent inaperçus.

SECTION 9 — POWER PLATFORM ET AUTRES SERVICES

9.1 Power Platform

9.1.1 — Restreindre la création d’environnements de production et sandbox aux administrateurs

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.POWERPLATFORM.1.1v1 Référence : BOD 25-01 Niveau : 🟡 Moyen Référence CIS : CIS Control 4.1

Description : Par défaut, n’importe quel utilisateur avec une licence M365 peut créer des environnements Power Apps, des flux Power Automate et des applications Canvas. Des données sensibles peuvent être exportées via des connecteurs non contrôlés.

Vérification :

Power Platform Admin Center > Paramètres > Gouvernance > Environnements

Remédiation :

Power Platform Admin Center > Paramètres > Gouvernance
Restreindre la création d’environnements aux administrateurs Power Platform uniquement
Désactiver les connecteurs à haut risque (connecteurs tierces parties non approuvés) via Data Loss Prevention policies
Activer la journalisation des activités Power Platform

9.1.2 — Restreindre la création d’environnements d’essai (trial) aux administrateurs

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.POWERPLATFORM.1.2v1 Référence : BOD 25-01

Description : Les environnements d’essai créés par les utilisateurs échappent aux politiques DLP et de gouvernance de l’organisation, pouvant contenir des flux et applications qui manipulent des données sensibles sans contrôle.

Vérification :

Power Platform Admin Center > Paramètres > Environnements d’essai

Remédiation :

Power Platform Admin Center > Paramètres > Gouvernance
“Qui peut créer des environnements d’essai” : Uniquement les administrateurs spécifiques

9.1.3 — Activer l’isolation des tenants Power Platform

Niveau : 🟠 Élevé Référence CISA SCuBA : MS.POWERPLATFORM.3.1v1 Référence : BOD 25-01

Description : L’isolation des tenants Power Platform empêche les connecteurs Power Apps/Power Automate de l’organisation de se connecter à des tenants Entra ID externes non approuvés, et empêche des tenants externes de se connecter au tenant de l’organisation. Cela bloque l’exfiltration de données via des flux inter-tenants malveillants.

Vérification :

Power Platform Admin Center > Sécurité > Identité et accès > Isolation des tenants

Remédiation :

Power Platform Admin Center > Sécurité > Isolation des tenants
Activer “Restreindre les connexions inter-tenants”
Configurer une liste d’autorisation (allowlist) pour les tenants partenaires légitimes
PowerShell :

# Activer tenant isolation
$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.governance.disableTenantIsolation = $false
Set-TenantSettings -RequestBody $tenantSettings

9.1.4 — Activer la Content Security Policy (CSP) pour les Power Apps

Niveau : 🟡 Moyen Référence CISA SCuBA : MS.POWERPLATFORM.4.1v1

Description : La Content Security Policy (CSP) pour les Power Apps (model-driven et canvas) empêche les attaques XSS en définissant quelles sources de contenu sont autorisées à s’exécuter dans l’application. Sans CSP, du code JavaScript malveillant pourrait être injecté dans les applications Power Apps.

Vérification :

Power Platform Admin Center > Environnements > Paramètres > Produit > Confidentialité + Sécurité
Vérifier que CSP est activé pour les applications model-driven et canvas

Remédiation :

Pour chaque environnement : Power Platform Admin Center > Environnements > Sélectionner l’environnement > Paramètres > Produit > Confidentialité + Sécurité
Activer CSP pour les applications model-driven
Activer CSP pour les applications canvas

9.1.5 — Restreindre la création de sites Power Pages aux administrateurs

Niveau : 🟡 Moyen Référence CISA SCuBA : MS.POWERPLATFORM.5.1v1

Description : Power Pages permet de créer des portails web accessibles publiquement depuis les données Dataverse. Un portail mal configuré créé par un utilisateur non averti peut exposer des données sensibles sur Internet.

Vérification :

$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.powerPages.disablePortalsCreationByNonAdminUsers

Doit retourner True

Remédiation :

$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.powerPages.disablePortalsCreationByNonAdminUsers = $true
Set-TenantSettings -RequestBody $tenantSettings

9.1.6 — Désactiver le partage Power Apps avec “Tout le monde”

Niveau : 🟡 Moyen Référence CISA SCuBA : MS.POWERPLATFORM.6.1v1

Description : La fonctionnalité “Partager avec tout le monde” dans Power Apps peut exposer une application à l’ensemble des utilisateurs de l’organisation, y compris ceux qui n’ont pas besoin d’y accéder. Cela viole le principe du moindre privilège.

Vérification :

$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.powerApps.disableShareWithEveryone

Doit retourner True

Remédiation :

$tenantSettings = Get-TenantSettings
$tenantSettings.powerPlatform.powerApps.disableShareWithEveryone = $true
Set-TenantSettings -RequestBody $tenantSettings

9.1.7 — Configurer les politiques DLP Power Platform

Niveau : 🟡 Moyen Référence CIS : CIS Control 3.3

Description : Les politiques DLP de Power Platform contrôlent quels connecteurs peuvent être utilisés ensemble dans un flux ou une application. Cela prévient la création de flux qui exportent des données M365 vers des services non approuvés.

Vérification :

Power Platform Admin Center > Politiques de données > Politiques DLP

Remédiation :

Créer une politique DLP couvrant tous les environnements
Déplacer les connecteurs M365 (SharePoint, Excel, Outlook) dans le groupe “Business”
Déplacer les connecteurs à risque dans le groupe “Non-Business” ou “Blocked”
Les connecteurs dans des groupes différents ne peuvent pas être utilisés dans le même flux

SECTION 10 — MICROSOFT FABRIC (POWER BI)

Référence : CIS Microsoft 365 Foundations Benchmark v6.0.1 — Chapitre 9 Microsoft Fabric (anciennement Power BI) permet de créer des tableaux de bord, rapports et analyses de données partagés dans l’organisation. Sans gouvernance, des données sensibles peuvent être publiées publiquement, partagées avec des invités, ou accessibles via des APIs non sécurisées.

10.1 Paramètres du Tenant Fabric

10.1.1 — Restreindre l’accès invité à Microsoft Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.1 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.1.1v1 Profile : E3 Level 1

Description : L’accès des invités Entra ID à Microsoft Fabric doit être restreint. Des utilisateurs invités ayant accès à Fabric peuvent consulter des tableaux de bord contenant des données commerciales sensibles (chiffres d’affaires, KPIs, données RH, etc.) qui n’étaient pas destinées à une audience externe.

Vérification :

Portail Power BI Admin > Paramètres du tenant > Paramètres d’exportation et de partage
Vérifier “Autoriser Azure Active Directory les utilisateurs invités à accéder à Microsoft Fabric”

Remédiation :

Portail Fabric Admin (app.powerbi.com/admin-portal) > Paramètres du tenant
“Autoriser les utilisateurs invités Azure AD à accéder à Microsoft Fabric” : Désactivé
Si des invités ont besoin d’accès : créer des groupes de sécurité dédiés avec accès explicitement approuvé

10.1.2 — Restreindre les invitations d’utilisateurs externes dans Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.2 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.1.2v1 Profile : E3 Level 1

Description : Fabric peut inviter des utilisateurs externes directement, contournant potentiellement les restrictions d’invitation d’invités configurées dans Entra ID. Cette fonctionnalité doit être désactivée pour centraliser la gestion des invités dans Entra ID.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Inviter des utilisateurs externes dans votre organisation”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Inviter des utilisateurs externes dans votre organisation” : Désactivé
Toutes les invitations doivent passer par le processus Entra ID standard

10.1.3 — Restreindre l’accès guest au contenu Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.3 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.1.3v1 Profile : E3 Level 1

Description : Même si les invités peuvent accéder à Fabric, l’accès au contenu (rapports, tableaux de bord, datasets) doit être restreint aux ressources explicitement partagées, sans accès global au tenant Fabric.

Vérification :

Portail Fabric Admin > “Autoriser les utilisateurs invités Azure AD à accéder à Microsoft Fabric”
Différent du contrôle 10.1.1 — ceci contrôle l’accès au contenu spécifique

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Les utilisateurs invités peuvent accéder aux rapports Fabric via un lien” : Désactivé (ou restreint à un groupe approuvé)

10.1.4 — Restreindre la publication sur Internet (Publish to Web)

Niveau : 🔴 Critique Référence CIS : 9.1.4 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.2.1v1 Profile : E3 Level 1

Description : La fonctionnalité “Publier sur le web” de Power BI/Fabric crée un lien public accessible à n’importe quelle personne sur Internet, sans authentification. Des rapports contenant des données sensibles peuvent être publiés accidentellement. Cette fonctionnalité doit être désactivée ou restreinte aux administrateurs uniquement.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Publier sur le web”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Publier sur le web” : Désactivé
Si nécessaire pour des cas légitimes : restreindre à un groupe de sécurité approuvé avec processus de validation

10.1.5 — Désactiver les visuels R et Python interactifs

Niveau : 🟡 Moyen Référence CIS : 9.1.5 (L2) — Automated Profile : E3 Level 2

Description : Les visuels R et Python dans Fabric exécutent du code sur les postes clients ou dans le cloud. Du code R/Python malveillant intégré dans un rapport peut exfiltrer des données, exécuter des commandes système, ou servir de vecteur d’attaque.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Interagir avec et partager des visuels R et Python”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Interagir avec et partager des visuels R et Python” : Désactivé

10.1.6 — Activer l’application des étiquettes de sensibilité dans Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.6 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.3.1v1 Profile : E3 Level 1

Description : Les étiquettes de sensibilité Microsoft Purview doivent pouvoir être appliquées aux contenus Fabric (rapports, datasets, tableaux de bord). Cela permet la classification des données et le déclenchement de politiques de protection associées (chiffrement, restrictions d’accès).

Vérification :

Portail Fabric Admin > Paramètres du tenant > Protection des informations
“Permettre aux utilisateurs d’appliquer des étiquettes de sensibilité au contenu” : Activé

Remédiation :

Portail Fabric Admin > Protection des informations
Activer “Permettre aux utilisateurs d’appliquer des étiquettes de sensibilité au contenu”
Activer “Appliquer des étiquettes de sensibilité depuis des sources de données aux données dans Fabric”

10.1.7 — Restreindre les liens partageables dans Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.7 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.2.3v1 Profile : E3 Level 1

Description : Les liens partageables dans Fabric peuvent donner accès à des rapports à toute personne de l’organisation ou externe. Ces liens doivent être restreints pour éviter la diffusion non contrôlée de données analytiques sensibles.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Créer des liens partageables vers du contenu avec accès activé”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
Désactiver les liens partageables avec “Toute personne dans l’organisation”
Maintenir uniquement les liens pour des utilisateurs spécifiques

10.1.8 — Restreindre le partage de données externes dans Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.8 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.2.2v1 Profile : E3 Level 1

Description : Fabric peut se connecter à des sources de données externes et potentiellement envoyer des données vers l’extérieur. Cette fonctionnalité doit être restreinte pour éviter l’exfiltration non intentionnelle de données d’entreprise.

Vérification :

Portail Fabric Admin > “Autoriser les connexions de données externes spécifiques”

Remédiation :

Portail Fabric Admin > Paramètres du tenant > “Activation du partage externe de données”
Désactiver ou restreindre à un groupe d’utilisateurs approuvés

10.1.9 — Activer BlockResourceKeyAuthentication dans Fabric

Niveau : 🟠 Élevé Référence CIS : 9.1.9 (L1) — Automated Référence CISA SCuBA : MS.POWERBI.4.1v1 Profile : E3 Level 1

Description : L’authentification par clé de ressource (ResourceKey) dans Power BI Embedded permet d’accéder à des rapports sans authentification Entra ID. Si cette méthode est utilisée avec des clés exposées, n’importe qui ayant la clé peut accéder aux rapports. Bloquer cette méthode force l’utilisation d’OAuth 2.0.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Bloquer l’authentification par clé de ressource”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Bloquer l’authentification par clé de ressource” : Activé

10.1.10 — Restreindre l’accès aux APIs Fabric par les principaux de service

Niveau : 🟠 Élevé Référence CIS : 9.1.10 (L1) — Automated Profile : E3 Level 1

Description : Les principaux de service (Service Principals) peuvent accéder aux APIs Fabric avec des permissions très larges. Sans restriction, des applications tierces ou des scripts automatisés peuvent lire, modifier ou exporter l’ensemble des données analytiques de l’organisation.

Vérification :

Portail Fabric Admin > Paramètres du tenant > “Permettre aux principaux de service d’utiliser les APIs Power BI”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Permettre aux principaux de service d’utiliser les APIs Power BI” : Désactivé ou restreint à des groupes de sécurité spécifiques
Pour chaque principal de service autorisé : documenter le cas d’usage et effectuer une révision trimestrielle

10.1.11 — Empêcher les principaux de service de créer et utiliser des profils

Niveau : 🟡 Moyen Référence CIS : 9.1.11 (L1) — Automated Profile : E3 Level 1

Description : Les profils de principal de service dans Fabric peuvent être utilisés pour contourner les restrictions d’accès normales. Restreindre cette capacité limite les vecteurs d’abus potentiels par des applications mal configurées ou compromises.

Vérification :

Portail Fabric Admin > “Permettre aux principaux de service de créer et d’utiliser des profils”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
“Permettre aux principaux de service de créer et d’utiliser des profils” : Désactivé

10.1.12 — Restreindre la création d’espaces de travail Fabric par les principaux de service

Niveau : 🟡 Moyen Référence CIS : 9.1.12 (L1) — Automated Profile : E3 Level 1

Description : Des principaux de service capables de créer des espaces de travail, connexions et pipelines de déploiement peuvent contourner les workflows de gouvernance et créer des environnements shadow IT dans Fabric.

Vérification :

Portail Fabric Admin > “Capacité des principaux de service à créer des espaces de travail, connexions et pipelines”

Remédiation :

Portail Fabric Admin > Paramètres du tenant
Désactiver la capacité des principaux de service à créer des espaces de travail automatiquement
Exiger une validation humaine pour toute création d’espace de travail via API

10.1.13 — Restreindre le partage de datasets Power BI entre espaces de travail (Cross-Workspace)

Niveau : 🟠 Élevé Référence : MS.POWERBI.5.1v1 (équivalent) — Manual Profile : E3 Level 1

Description : La fonctionnalité “Partage de datasets entre espaces de travail” (Cross-Workspace Dataset Sharing) permet aux utilisateurs de connecter des rapports Power BI à des datasets situés dans d’autres espaces de travail auxquels ils n’ont pas nécessairement accès direct. Sans restriction, cette fonctionnalité peut permettre à un utilisateur d’accéder indirectement à des données sensibles via un dataset partagé, contournant les permissions configurées sur l’espace de travail source.

Vérification :

Portail d’administration Fabric > Paramètres du tenant > “Autoriser la connexion XMLA et l’utilisation de datasets dans Power BI Desktop”
Portail d’administration Fabric > Paramètres du tenant > “Partager des datasets avec des utilisateurs extérieurs à votre organisation”

# Vérifier via API Fabric Admin
$headers = @{ Authorization = "Bearer $token" }
Invoke-RestMethod -Uri "https://api.fabric.microsoft.com/v1/admin/tenantsettings" -Headers $headers |
    Select-Object -ExpandProperty tenantSettings |
    Where-Object { $_.settingName -match "CrossWorkspace|DatasetShare|XMLA" } |
    Format-Table settingName, enabled, canSpecifySecurityGroups

Remédiation :

Portail Fabric Admin > Paramètres du tenant > Partage
Désactiver “Permettre aux utilisateurs de partager des datasets avec d’autres utilisateurs”
Si nécessaire pour des cas légitimes : restreindre à des groupes de sécurité spécifiques
Activer le chiffrement RLS (Row-Level Security) sur tous les datasets sensibles
Revoir trimestriellement les datasets avec des permissions cross-workspace actives

Valeur par défaut : Le partage de datasets entre espaces de travail est activé par défaut dans Fabric.

SECTION 11 — MICROSOFT 365 APPS — SÉCURITÉ DES APPLICATIONS OFFICE

Référence : Microsoft Security Compliance Toolkit — M365 Apps for Enterprise Security Baseline v2512 (Décembre 2025) Ces contrôles s’appliquent aux applications Office (Word, Excel, PowerPoint, Outlook, OneNote) déployées via Intune (politiques ADMX/Settings Catalog) ou via GPO Active Directory.

11.1 Macros et Code Actif

11.1.1 — Exiger la signature des macros (Require Macro Signing)

Niveau : 🔴 Critique Référence : MSCT M365 Apps v2512 — GPO “Require Macro Signing - User” Déploiement : Intune (Settings Catalog) / GPO AD MITRE ATT&CK : T1137 (Office Application Startup) · T1204.002 (User Execution: Malicious File) · T1059.005 (Command and Scripting: Visual Basic)

Description : Les macros VBA non signées représentent l’un des vecteurs d’infection les plus courants dans les campagnes de ransomware et d’espionnage. En exigeant une signature numérique valide pour l’exécution des macros, l’organisation s’assure que seules les macros approuvées et développées en interne peuvent s’exécuter. Les macros dans les documents reçus par email ou téléchargés seront bloquées.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Exiger la signature des macros = Activé

Ou via Intune : Settings Catalog > Microsoft Office 2016 > Security Settings > Require Macro Signing

Vérification :

# Via registre sur poste client
Get-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Office\16.0\Common\Security" -Name "RequireAddinSig" -ErrorAction SilentlyContinue
# Valeur attendue : 1

Remédiation :

Intune > Appareils > Profils de configuration > Créer > Windows 10 et ultérieur > Settings Catalog
Rechercher “Require Macro Signing” pour chaque application Office concernée
Activer et assigner au groupe d’appareils
Établir un processus de signature des macros internes (certificat de signature de code interne)

Impact : Les macros existantes non signées seront bloquées. Inventaire préalable indispensable.

11.1.2 — Bloquer les macros VBA dans les fichiers Office depuis Internet (MOTW)

Niveau : 🔴 Critique Référence : CIS Office Benchmark / MSCT M365 Apps Déploiement : Intune / GPO AD MITRE ATT&CK : T1204.002 (User Execution: Malicious File) · T1566.001 (Phishing: Spearphishing Attachment) · T1059.005 (Visual Basic)

Description : Windows marque les fichiers téléchargés depuis Internet avec une balise “Mark of the Web” (MOTW). Office doit bloquer l’exécution des macros dans tous les fichiers portant cette balise. Depuis 2022, Microsoft a renforcé ce blocage par défaut, mais il peut avoir été désactivé par des GPOs ou des utilisateurs.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Block macros from running in Office files from the Internet = Enabled

Vérification :

# Vérifier que le blocage MOTW est actif pour Excel
Get-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Office\16.0\Excel\Security" -Name "BlockContentExecutionFromInternet" -ErrorAction SilentlyContinue
# Valeur attendue : 1

Remédiation :

Intune > Settings Catalog > “Block macros from running in Office files from the Internet” = Enabled
Appliquer pour Word, Excel, PowerPoint, Outlook, Visio

11.1.3 — Bloquer les objets OLE actifs dans PowerPoint

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — GPO “PowerPoint OLE Active Content” Déploiement : Intune / GPO AD

Description : Les objets OLE (Object Linking and Embedding) embarqués dans des présentations PowerPoint peuvent exécuter du code externe, charger des applications tierces, ou établir des connexions réseau non sécurisées. La baseline v2512 désactive les actions OLE interactives.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft PowerPoint 2016\PowerPoint Options\Security\
→ OLE Active Content = No OLE content will be activated

Remédiation :

Intune > Settings Catalog > Microsoft PowerPoint 2016 > Security > OLE Active Content > Désactivé

11.1.4 — Bloquer l’exécution de DDE dans Excel

Niveau : 🔴 Critique Référence : MSCT M365 Apps v2512 — GPO “DDE Block - User” Déploiement : Intune / GPO AD

Description : DDE (Dynamic Data Exchange) est un protocole hérité permettant à Excel de requêter des données depuis d’autres applications ou processus systèmes, y compris cmd.exe et PowerShell. Des documents Excel malveillants exploitent DDE pour exécuter du code arbitraire sans macro VBA, contournant les protections anti-macro.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Excel 2016\Excel Options\Security\Trust Center\
→ Don't allow Dynamic Data Exchange (DDE) server launch in Excel = Enabled

Vérification :

Get-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Office\16.0\Excel\Security" -Name "DisableDDEServerLaunch" -ErrorAction SilentlyContinue
# Valeur attendue : 1

11.1.5 — Bloquer les formats de fichiers Office hérités (Legacy File Block)

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — GPO “Legacy File Block - User” Déploiement : Intune / GPO AD

Description : Les anciens formats Office (.doc, .xls, .ppt pre-2007) contiennent souvent des vulnérabilités connues et non corrigées dans leurs parsers. Bloquer l’ouverture de ces formats réduit la surface d’attaque pour les exploits de format de fichier.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Legacy File Block = Prevent opening/saving

11.1.6 — Désactiver JScript hérité dans Internet Explorer / Zones restreintes Office

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — GPO “Legacy JScript Block - Computer” Déploiement : Intune / GPO AD

Description : Le moteur JScript hérité de Microsoft (distinct de V8/Node.js) est utilisé dans la zone Internet d’Internet Explorer et dans certains contextes Office pour exécuter des scripts embarqués dans des documents. Ce moteur présente de nombreuses vulnérabilités CVE critiques. La baseline v2512 désactive JScript dans la zone Internet et la zone Sites restreints pour Office.

Paramètre GPO :

Computer Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Block Legacy JScript Execution = Enabled

11.1.7 — Désactiver les add-ins Office non gérés (DisableAllAddIns)

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — “Disable All Add-ins” — Automated Déploiement : Intune (Settings Catalog) / GPO AD

Description : Les add-ins Office non gérés (COM add-ins, VSTO add-ins, Web Add-ins tiers non approuvés) représentent un vecteur d’attaque significatif. Des malwares avancés utilisent des add-ins malveillants pour persister dans le système, intercepter des communications Outlook, exfiltrer des données, ou contourner les contrôles de sécurité. Le Microsoft Security Compliance Toolkit v2512 recommande de désactiver tous les add-ins non approuvés et de n’autoriser que les add-ins déployés via le Catalogue d’Applications centralisé (Admin Center).

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Disable All Add-ins = Enabled (Force désactivation de tous les add-ins non gérés)

User Configuration\Administrative Templates\Microsoft Outlook 2016\Miscellaneous\
→ Do not allow Outlook object model scripts to run for shared folders = Enabled

Vérification :

# Vérifier via Intune — Settings Catalog policy pour Office Add-ins
# Microsoft Intune Admin Center > Devices > Configuration > Policies
# Filtrer par "Office Add-in" ou "DisableAllAddIns"

# Via registry sur les postes (si GPO)
Get-ItemProperty "HKCU:\Software\Microsoft\Office\16.0\Common\General" -Name "DisableAllAddIns" -ErrorAction SilentlyContinue
# Valeur attendue : DisableAllAddIns = 1

Remédiation :

Intune > Devices > Configuration > Settings Catalog > Créer une politique pour les Apps M365
Ajouter le paramètre “Disable All Add-ins” = Enabled
Déployer les add-ins légitimes via le Catalogue d’Applications centralisé (Admin Center > Settings > Integrated apps)
Créer une liste blanche des add-ins approuvés dans le portail M365
Auditer les add-ins actuellement installés sur les postes via Intune Device Reports

Valeur par défaut : Les utilisateurs peuvent installer tout add-in disponible dans l’Office Store sans restriction.

11.2 Protocoles et Connexions Sécurisées

11.2.1 — Bloquer les protocoles non-HTTPS dans les applications Office

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — “Block Insecure Protocols” Déploiement : Intune / GPO AD

Description : La baseline v2512 introduit la politique “Block Insecure Protocols” qui bloque tous les protocoles non-HTTPS (HTTP, FTP, etc.) lors de l’ouverture de documents ou de la résolution de liens dans les applications M365. Cela élimine les chemins de déclassement (downgrade) et les connexions non sécurisées pouvant être interceptées.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Block Insecure Protocols = Enabled

11.2.2 — Bloquer les liens externes dans les classeurs Excel (File Block External Links)

Niveau : 🟠 Élevé Référence : MSCT M365 Apps v2512 — “Excel File Block Includes External Link Files” Déploiement : Intune / GPO AD

Description : Les classeurs Excel avec liens vers des fichiers externes bloqués par File Block ne doivent pas pouvoir rafraîchir ces liens. Cela empêche l’ingestion de données depuis des sources non approuvées ou potentiellement malveillantes, et prévient les techniques de reconnaissance utilisant des liens OLE/Excel vers des serveurs attaquants.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Excel 2016\Excel Options\Security\Trust Center\File Block Settings\
→ File Block includes external link files = Enabled

11.2.3 — Bloquer le fallback FPRPC dans les applications Office

Niveau : 🟡 Moyen Référence : MSCT M365 Apps v2512 — “Restrict FPRPC Fallback” Déploiement : Intune / GPO AD

Description : Le protocole FrontPage Server Extensions RPC (FPRPC) est un protocole d’accès aux fichiers vieillissant, non conçu pour les exigences sécurité modernes. La baseline v2512 désactive le fallback vers FPRPC pour garantir l’utilisation exclusive de méthodes d’accès aux fichiers modernes et authentifiées.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Restrict Apps from FPRPC Fallback = Enabled

11.2.4 — Désactiver les composants OLE Graph hérités (MSGraph.Application)

Niveau : 🟡 Moyen Référence : MSCT M365 Apps v2512 — “Block OLE Graph” Déploiement : Intune / GPO AD

Description : MSGraph.Application et MSGraph.Chart sont des composants OLE Graph classiques qui constituent une interface d’automatisation historiquement risquée. La baseline v2512 remplace leur exécution par un rendu d’image statique, éliminant l’exposition au moteur d’automation sous-jacent.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Block OLE Graph = Enabled

11.2.5 — Désactiver le composant OrgChart Add-in hérité

Niveau : 🟡 Moyen Référence : MSCT M365 Apps v2512 — “Block OrgChart” Déploiement : Intune / GPO AD

Description : L’add-in OrgChart hérité utilise des frameworks d’automatisation obsolètes. La baseline le désactive et remplace son rendu par une image statique, réduisant l’exposition aux vulnérabilités des frameworks d’automation.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Office 2016\Security Settings\
→ Block OrgChart = Enabled

11.3 Journaux et Télémétrie Office

11.3.1 — Activer la journalisation des erreurs Office via Intune

Niveau : 🟡 Moyen Référence : MSCT M365 Apps / CIS Office Benchmark Déploiement : Intune / GPO AD

Description : Les journaux d’erreur et d’utilisation des applications Office permettent de détecter des comportements anormaux (tentatives d’exploitation, crashes répétés sur des fichiers spécifiques) et de corréler avec des indicateurs de compromission.

Vérification :

Intune > Politiques de configuration > Vérifier l’activation des journaux Office
Ou via Registre :

Get-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Office\16.0\Common" -Name "SendCustomerData" -ErrorAction SilentlyContinue

Remédiation :

Activer le journal d’audit Office via Intune (Settings Catalog > Office)
Configurer l’envoi des journaux vers Microsoft Defender for Endpoint ou le SIEM

11.3.2 — Activer la protection contre les documents malveillants (Protected View renforcé)

Niveau : 🟠 Élevé Référence : CIS Office Benchmark / MSCT Déploiement : Intune / GPO AD

Description : La Protected View d’Office ouvre les documents potentiellement dangereux en mode lecture seule dans un bac à sable, sans activer les macros, les objets OLE, ni les connexions réseau. Forcer l’activation de Protected View pour les fichiers Internet, les pièces jointes Outlook, et les emplacements potentiellement dangereux est une mesure de sécurité critique.

Paramètre GPO :

User Configuration\Administrative Templates\Microsoft Word/Excel/PowerPoint\Options\Security\Trust Center\
→ Enable Protected View for files originating from the Internet = Enabled
→ Enable Protected View for files in potentially unsafe locations = Enabled
→ Enable Protected View for Outlook attachments = Enabled

SECTION 12 — GESTION ADMINISTRATIVE

12.1 Paramètres du Tenant

12.1.1 — Restreindre l’accès au portail d’administration M365

Niveau : 🟠 Élevé Référence CIS : CIS Control 4.1

Description : L’accès au portail Microsoft 365 Admin Center doit être restreint aux administrateurs uniquement. Les utilisateurs standards n’ont pas besoin d’y accéder.

Vérification :

Get-MsolCompanyInformation | Select-Object UsersPermissionToReadOtherUsersEnabled, UsersPermissionToUserConsentToAppEnabled

Remédiation :

M365 Admin Center > Paramètres > Org Settings > Services
Désactiver l’accès au portail d’admin pour les non-administrateurs
Créer une politique CA : Bloquer l’accès à “Microsoft Admin Portals” pour les non-admins

12.1.2 — Désactiver le consentement des utilisateurs aux applications tierces

Niveau : 🟠 Élevé Référence CIS : CIS Control 4.1

Description : Par défaut, les utilisateurs peuvent donner leur consentement à des applications tierces pour accéder à leurs données M365 (emails, fichiers, contacts). Des applications malveillantes exploitent cela pour obtenir un accès persistant (OAuth Phishing).

Vérification :

(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Select-Object AllowedToCreateApps, AllowedToCreateSecurityGroups, AllowedToCreateTenants
Get-MgPoliciesPermissionGrantPolicies

Remédiation :

Entra ID > Applications d’entreprise > Paramètres utilisateur
“Les utilisateurs peuvent donner leur consentement aux applications accédant aux données de l’entreprise” → Non
Activer le workflow de consentement administrateur pour que les utilisateurs puissent demander l’approbation
Réviser les applications ayant déjà reçu des consentements larges

12.1.3 — Activer les restrictions de création de tenants

Niveau : 🟡 Moyen Référence CIS : CIS Control 4.1

Description : Sans restrictions, les utilisateurs peuvent créer de nouveaux tenants Entra ID avec leur adresse email professionnelle pour contourner les contrôles de sécurité de l’organisation.

Vérification :

(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.AllowedToCreateTenants

Remédiation :

$permissionsObject = (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions
$permissionsObject.AllowedToCreateTenants = $false
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions $permissionsObject

12.1.4 — Restreindre l’enregistrement d’appareils par les utilisateurs

Niveau : 🟡 Moyen Référence CIS : CIS Control 1.1

Description : Limiter quels utilisateurs peuvent enregistrer des appareils dans Entra ID empêche l’enregistrement non autorisé d’appareils personnels qui pourraient obtenir des tokens d’accès ou contourner des politiques CA basées sur les appareils.

Vérification :

Entra ID > Appareils > Paramètres d’appareil > Les utilisateurs peuvent joindre des appareils à Azure AD

Remédiation :

Entra ID > Appareils > Paramètres d’appareil
“Les utilisateurs peuvent joindre des appareils à Azure AD” : Sélectionné (groupe restreint) au lieu de Tous
Nombre maximum d’appareils par utilisateur : 5 (ou selon politique interne)

12.1.5 — Vérifier la configuration des domaines personnalisés

Niveau : 🟡 Moyen Référence CIS : CIS Control 2.1

Description : Les domaines personnalisés non vérifiés ou mal configurés peuvent être utilisés pour l’usurpation d’identité. Tous les domaines associés au tenant doivent avoir leurs enregistrements DNS correctement configurés.

Vérification :

M365 Admin Center > Paramètres > Domaines
Vérifier le statut de chaque domaine (Sain / Avertissements)

Remédiation :

Résoudre tous les avertissements DNS sur les domaines personnalisés
S’assurer que SPF, DKIM et DMARC sont configurés pour TOUS les domaines
Supprimer les domaines inutilisés du tenant

12.1.6 — Restreindre l’accès au Microsoft Office Store pour les utilisateurs

Niveau : 🟠 Élevé Référence CIS : CIS 1.3.4 (L1) — Automated Profile : E3 Level 1

Description : Par défaut, les utilisateurs peuvent accéder à l’Office Store et installer des applications et compléments Microsoft 365 de leur propre initiative. Ces applications non gérées peuvent accéder aux données M365 (emails, fichiers, contacts), introduire des risques de sécurité et contourner les politiques DLP.

Vérification :

$Uri = "https://graph.microsoft.com/beta/admin/appsAndServices/settings"
Invoke-MgGraphRequest -Uri $Uri
# Valeurs attendues : isAppAndServicesTrialEnabled = false, isOfficeStoreEnabled = false

Remédiation :

$uri = "https://graph.microsoft.com/beta/admin/appsAndServices"
$body = @{
    Settings = @{
        isAppAndServicesTrialEnabled = $false
        isOfficeStoreEnabled = $false
    }
} | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri $uri -Body $body

Ou via M365 Admin Center > Paramètres > Paramètres Org > Services > Applications et services.

12.1.7 — Activer la protection phishing interne pour Microsoft Forms

Niveau : 🟠 Élevé Référence CIS : CIS 1.3.5 (L1) — Automated Profile : E3 Level 1

Description : Microsoft Forms dispose d’une protection anti-phishing interne qui détecte lorsque des formulaires sont utilisés pour des attaques de phishing en interne (collecte de credentials, informations sensibles). Des attaquants ayant compromis un compte peuvent créer des formulaires de phishing pour cibler d’autres employés.

Vérification :

$uri = 'https://graph.microsoft.com/beta/admin/forms/settings'
(Invoke-MgGraphRequest -Uri $uri).isInOrgFormsPhishingScanEnabled
# Valeur attendue : True

Remédiation :

$uri = 'https://graph.microsoft.com/beta/admin/forms/settings'
$body = @{ isInOrgFormsPhishingScanEnabled = $true } | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri $uri -Body $body

12.1.8 — Activer Customer Lockbox pour les accès Microsoft au tenant

Niveau : 🟡 Moyen Référence CIS : CIS 1.3.6 (L2) — Automated Profile : E5 Level 2 Licence requise : Microsoft 365 E5 ou Microsoft 365 E5 Compliance

Description : Customer Lockbox garantit que Microsoft ne peut pas accéder aux données client sans approbation explicite. Quand le support Microsoft doit accéder aux données pour résoudre un incident, une demande d’approbation est envoyée à l’administrateur du tenant. Sans Customer Lockbox, Microsoft peut accéder aux données avec uniquement une notification interne.

Vérification :

Get-OrganizationConfig | Select-Object CustomerLockBoxEnabled
# Valeur attendue : True

Remédiation :

Set-OrganizationConfig -CustomerLockBoxEnabled $true

Ou via M365 Admin Center > Paramètres > Paramètres Org > Sécurité et confidentialité > Customer Lockbox.

12.1.9 — Restreindre les services de stockage tiers dans Microsoft 365 Web

Niveau : 🟡 Moyen Référence CIS : CIS 1.3.7 (L2) — Automated Profile : E3 Level 2

Description : Par défaut, les applications web M365 (Word, Excel, PowerPoint Online) permettent d’ouvrir et sauvegarder des fichiers depuis des services tiers comme Dropbox, Box ou Google Drive. Cela peut conduire à des fuites de données sensibles vers des espaces non contrôlés par l’organisation.

Vérification :

$SP = Get-MgServicePrincipal -Filter "appId eq 'c1f33bc0-bdb4-4248-ba9b-096807ddb43e'"
if ((-not $SP) -or $SP.AccountEnabled) {
    Write-Host "NON CONFORME - Stockages tiers autorisés"
} else {
    Write-Host "CONFORME - Stockages tiers bloqués"
}

Remédiation :

$SP = Get-MgServicePrincipal -Filter "appId eq 'c1f33bc0-bdb4-4248-ba9b-096807ddb43e'"
if (-not $SP) { $SP = New-MgServicePrincipal -AppId "c1f33bc0-bdb4-4248-ba9b-096807ddb43e" }
Update-MgServicePrincipal -ServicePrincipalId $SP.Id -AccountEnabled:$false

12.1.10 — Désactiver le partage externe de Sway

Niveau : 🟡 Moyen Référence CIS : CIS 1.3.8 (L1) — Manual Profile : E3 Level 1

Description : Sway est un outil de création de présentations interactives. Par défaut, les utilisateurs peuvent partager leurs Sways publiquement avec des personnes extérieures à l’organisation. Des Sways peuvent contenir des informations stratégiques, des données RH ou des plans commerciaux qui ne doivent pas être accessibles publiquement.

Vérification :

M365 Admin Center > Paramètres > Paramètres Org > Services
Rechercher “Sway”
Vérifier que “Permettre aux personnes de votre organisation de partager leurs Sways avec des personnes extérieures” est décoché

Remédiation :

M365 Admin Center > Paramètres > Paramètres Org > Services > Sway
Décocher “Permettre aux personnes de votre organisation de partager leurs Sways avec des personnes extérieures à votre organisation”

12.1.11 — Restreindre ou désactiver Microsoft Bookings

Niveau : 🟡 Moyen Référence CIS : CIS 1.3.9 (L2) — Automated Profile : E3 Level 2

Description : Microsoft Bookings permet aux utilisateurs externes de réserver des créneaux avec les employés de l’organisation, exposant publiquement les calendriers et les coordonnées du personnel. Ce service peut également permettre la création de boîtes partagées Bookings non gérées, augmentant la surface d’attaque.

Vérification :

Get-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default | Select-Object BookingsMailboxCreationEnabled
Get-OrganizationConfig | Select-Object BookingsEnabled
# Valeurs attendues : les deux à False

Remédiation :

Set-OwaMailboxPolicy "OwaMailboxPolicy-Default" -BookingsMailboxCreationEnabled:$false
Set-OrganizationConfig -BookingsEnabled $false

SECTION 13 — RÉPONSE AUX INCIDENTS ET PLANS DE CONTINUITÉ

13.1.1 — Documenter les procédures de réponse aux incidents M365

Niveau : 🟡 Moyen Référence CIS : CIS Control 17.4

Description : L’absence de procédures documentées pour les incidents M365 (compromission de compte, ransomware via email, fuite de données) retarde significativement la réponse et augmente l’impact de l’incident.

Vérification :

Vérifier l’existence d’un plan de réponse aux incidents documenté spécifique M365
Vérifier que les procédures incluent : isolation de compte compromis, révocation de sessions, analyse forensic M365

Remédiation :

Documenter les procédures pour les scénarios : Compte admin compromis, Règle de transfert malveillante, Ransomware via SharePoint, Business Email Compromise (BEC)
Tester les procédures via des exercices de simulation (tabletop exercises) annuels
Maintenir les contacts Microsoft DART (Detection and Response Team) pour les incidents critiques

13.1.2 — Activer la journalisation avancée (Audit Premium)

Niveau : 🟡 Moyen Référence CIS : CIS Control 8.5 Licence requise : Microsoft 365 E5 ou Microsoft 365 E5 Compliance

Description : L’Audit Premium de Microsoft Purview offre une rétention des journaux de 1 an (voire 10 ans), une bande passante d’API accrue pour les enquêtes forensics, et des événements d’audit supplémentaires critiques pour les investigations (MailItemsAccessed, SearchQueryInitiatedExchange, etc.).

Vérification :

Get-Mailbox -Identity user@domain.com | Select-Object AuditEnabled, DefaultAuditSet

Remédiation :

Assigner la licence Microsoft Purview Audit (Premium) aux utilisateurs prioritaires (dirigeants, IT, finance)
Activer l’audit MailItemsAccessed pour détecter les accès à des emails spécifiques lors d’investigations
Configurer l’exportation vers un SIEM pour rétention à long terme

13.1.3 — Maintenir des playbooks de réponse aux incidents BEC et ransomware

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.DEFENDER.6.x — Manual | NIST 800-61r2 Profile : E3 Level 1

Description : La compromission de messagerie d’entreprise (BEC) et les ransomwares sont les deux principales menaces M365. Sans playbooks documentés et testés, le temps de réponse en cas d’incident est multiplié par 3 à 5 et les erreurs critiques (mauvaises réinitialisations, non-préservation des preuves) sont fréquentes. Les playbooks doivent être spécifiques à M365 et inclure les actions PowerShell/API nécessaires.

Vérification :

Documentation de l’organisation > Existence de playbooks IR M365 (BEC, ransomware, phishing, accès admin compromis)
Vérifier la date du dernier test/simulation (< 12 mois)
Vérifier la liste des comptes Break Glass et leur procédure d’activation

Remédiation :

Créer un playbook BEC couvrant :
- Détection via Defender for Office 365 Alert
- Révocation immédiate des sessions (Revoke-MgUserSignInSession)
- Reset MFA et MDP
- Investigation des règles de transfert et délégations suspectes
- Analyse des emails exfiltrés via eDiscovery
Créer un playbook Ransomware couvrant :
- Isolation de l’appareil compromis via Intune
- Blocage de compte M365
- Restauration OneDrive/SharePoint via versioning (180 jours)
- Analyse de propagation via Microsoft 365 Defender
Tester les playbooks annuellement via simulation tabletop
Référence : Microsoft Incident Response Playbooks — https://aka.ms/IRplaybooks

Valeur par défaut : Aucun playbook IR spécifique M365 n’est fourni par défaut.

13.1.4 — Activer et tester la sauvegarde M365 (backup tiers ou natif)

Niveau : 🟠 Élevé Référence : Microsoft 365 Backup Policy — Manual Profile : E3 Level 1 Licence requise : Microsoft 365 Backup (module add-on) ou solution tierce

Description : Microsoft n’est pas responsable de la sauvegarde des données M365 — sa responsabilité est la disponibilité de la plateforme, pas la récupération en cas de suppression accidentelle, de ransomware ou d’erreur administrative. Les outils natifs (corbeille, versioning) ont des limitations (30–93 jours). Une solution de sauvegarde dédiée est nécessaire pour les SLA de récupération critiques.

Vérification :

# Vérifier si Microsoft 365 Backup est configuré
$backupPolicy = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/admin/m365Apps/installation/backupPolicies" -Method GET -ErrorAction SilentlyContinue
$backupPolicy | ConvertTo-Json

Vérifier aussi : solution tierce active (Veeam, Acronis, Druva, Barracuda, AvePoint)
Tester la restauration d’une boîte mail et d’un site SharePoint < 12 mois

Remédiation :

Option 1 — Microsoft 365 Backup (natif) :
- Microsoft 365 Admin Center > Settings > Microsoft 365 Backup
- Configurer les politiques de sauvegarde pour Exchange, SharePoint, OneDrive
- RTO/RPO : restauration en minutes pour les 180 derniers jours
Option 2 — Solution tierce : déployer et configurer selon la politique de l’organisation
Documenter le processus de restauration et le tester annuellement
Vérifier que les sauvegardes sont stockées hors du tenant (protection contre suppression admin)

Valeur par défaut : Aucune sauvegarde dédiée M365 par défaut.

SECTION 14 — MICROSOFT COPILOT FOR M365

Contexte : Microsoft Copilot for M365 est un vecteur de risque critique en 2026. Il accède à toutes les données auxquelles l’utilisateur a accès (emails, Teams, SharePoint, OneDrive). Un déploiement sans contrôle préalable peut exposer massivement des données sensibles via oversharing, réponses inappropriées ou exfiltration involontaire.

14.1 Gouvernance et Sécurité de Microsoft Copilot for M365

14.1.1 — Évaluer le périmètre d’oversharing avant le déploiement Copilot

Niveau : 🔴 Critique Référence : Microsoft Purview DSPM for AI — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot + Purview DSPM for AI (add-on)

Description : Copilot accède aux données via le Microsoft Graph — toutes les données accessibles par l’utilisateur sont potentiellement accessibles à Copilot. En entreprise, il est courant que des données sensibles (RH, financier, juridique) soient accessibles à des utilisateurs qui n’auraient pas dû y avoir accès. Avant tout déploiement Copilot, un audit d’oversharing doit être réalisé via Microsoft Purview DSPM for AI (Data Security Posture Management).

Vérification :

# Vérifier les sites SharePoint avec "Tout le monde sauf les utilisateurs externes"
$sites = Get-PnPTenantSite -Detailed
$sites | Where-Object { $_.SharingCapability -eq "ExternalUserAndGuestSharing" } | Select-Object Url, Title

# Identifier les fichiers partagés avec "Tout le monde"
# À exécuter via Purview Content Explorer ou DSPM for AI

Microsoft Purview > DSPM for AI > Rapport d’oversharing
Vérifier que les sites SharePoint sensibles n’ont pas de permissions “Tout le monde”

Remédiation :

Déployer Microsoft Purview DSPM for AI et générer le rapport d’oversharing
Identifier les 10 sites/bibliothèques les plus à risque et restreindre les permissions
Supprimer les partages “Tout le monde” et “Tout le monde sauf les utilisateurs externes”
Activer la restriction d’accès aux sites SharePoint selon les étiquettes de sensibilité
Déployer une politique “SharePoint Advanced Management” pour audit continu
Ne pas activer Copilot avant que le score DSPM soit acceptable

Valeur par défaut : Aucune évaluation d’oversharing — Copilot peut exposer toutes les données accessibles à l’utilisateur.

14.1.2 — Configurer les politiques DLP spécifiques à Copilot

Niveau : 🔴 Critique Référence : Microsoft Purview DLP — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot + Purview DLP

Description : Les politiques DLP (Data Loss Prevention) doivent être étendues pour couvrir les interactions Copilot. Sans DLP spécifique, Copilot peut inclure dans ses réponses des données sensibles (numéros de carte, données santé, données personnelles RGPD) qui se retrouvent dans des prompts partagés ou des résumés.

Vérification :

# Vérifier les politiques DLP actives et leurs emplacements
Connect-IPPSSession
$policies = Get-DlpCompliancePolicy | Where-Object { $_.Mode -eq "Enable" }
$policies | Select-Object Name, Mode, ExchangeLocation, SharePointLocation | Format-Table

# Vérifier si les politiques couvrent Copilot (Microsoft365CopilotWorkloads)
$policies | Where-Object { $_.Workload -match "Copilot" } | Select-Object Name

Remédiation :

Microsoft Purview > Prévention des pertes de données > Stratégies > Nouvelle stratégie
Créer une stratégie DLP dédiée “Copilot” couvrant :
- Exchange Online + Teams + SharePoint + OneDrive + Copilot interactions
Définir des règles pour détecter et bloquer : numéros de carte bancaire, NIR, données santé, mots de passe
Configurer les actions : bloquer, notifier l’utilisateur, log dans le portail de conformité
Activer la surveillance des interactions Copilot via Purview Communication Compliance

Valeur par défaut : Aucune politique DLP spécifique à Copilot configurée.

14.1.3 — Activer la journalisation et l’audit des interactions Copilot

Niveau : 🟠 Élevé Référence : CISA SCuBA MS.AAD — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot + Purview Audit Premium

Description : Toutes les interactions Copilot (prompts et réponses) doivent être journalisées pour permettre l’investigation en cas d’incident (fuite de données, usage inapproprié, accès non autorisé). Les logs Copilot sont stockés dans Microsoft Purview et disponibles via Audit Premium.

Vérification :

# Vérifier l'état de l'audit unifié
Connect-IPPSSession
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Rechercher les événements Copilot dans les logs
$startDate = (Get-Date).AddDays(-30)
$endDate = Get-Date
Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate -RecordType CopilotInteraction -ResultSize 10 |
    Select-Object CreationDate, UserIds, Operations | Format-Table

Remédiation :

Vérifier que le journal d’audit unifié est actif (voir contrôle 8.1.1)
Microsoft Purview > Audit > Recherche d’audit > Filtrer par “Copilot”
Configurer des alertes sur les interactions Copilot anormales (volume élevé, données sensibles)
Activer Microsoft Purview Communication Compliance pour surveillance continue
Exporter les logs Copilot vers le SIEM pour corrélation

Valeur par défaut : Journalisation des interactions Copilot non activée par défaut.

14.1.4 — Contrôler les plugins et extensions Copilot tiers

Niveau : 🟠 Élevé Référence : Microsoft 365 App Governance — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot + App Governance

Description : Les plugins Copilot (connecteurs tiers, extensions d’agents Copilot) peuvent accéder à des données sensibles et les transmettre à des services externes. Sans gouvernance, les utilisateurs peuvent installer des plugins non approuvés qui créent des risques de fuite de données ou d’injection de prompts malveillants.

Vérification :

# Vérifier les consentements d'applications tiers pour Copilot
$apps = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=tags/any(t:t eq 'WindowsAzureActiveDirectoryIntegratedApp')" -Method GET
$apps.value | Select-Object displayName, appId | Format-Table

# Lister les agents Copilot déployés
# Microsoft 365 Admin Center > Copilot > Agents

Remédiation :

Microsoft 365 Admin Center > Settings > Integrated apps > Gérer les plugins Copilot
Désactiver les plugins tiers non approuvés par le service IT
Créer une liste d’applications Copilot approuvées
Activer Microsoft App Governance pour surveiller les comportements des plugins
Configurer le consentement administrateur obligatoire pour tous les nouveaux plugins Copilot (voir contrôle 1.5.x)

Valeur par défaut : Tous les plugins disponibles dans le store peuvent être installés par les utilisateurs.

14.1.5 — Appliquer les étiquettes de sensibilité aux contenus générés par Copilot

Niveau : 🟠 Élevé Référence : Microsoft Purview Sensitivity Labels — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot + AIP/Purview P2

Description : Les documents créés ou modifiés par Copilot doivent hériter de l’étiquette de sensibilité la plus élevée des sources utilisées. Sans cette configuration, Copilot peut créer un document non classifié en se basant sur des contenus Confidentiels — le document résultant ne sera pas protégé.

Vérification :

# Vérifier les politiques d'étiquettes auto-appliquées
Connect-IPPSSession
Get-AutoSensitivityLabelPolicy | Select-Object Name, Mode, ApplySensitivityLabel | Format-Table

# Vérifier si Copilot est configuré pour hériter des étiquettes
Get-LabelPolicy | Select-Object Name, Settings | Format-Table

Remédiation :

Microsoft Purview > Protection des informations > Étiquettes de sensibilité > Paramètres Copilot
Activer “Copilot doit utiliser l’étiquette la plus restrictive parmi les contenus référencés”
Configurer des politiques d’étiquetage automatique pour les contenus générés par IA
Former les utilisateurs à vérifier les étiquettes des documents générés par Copilot

Valeur par défaut : Copilot ne propage pas les étiquettes de sensibilité automatiquement.

14.1.6 — Gouverner les licences Copilot et restreindre l’accès aux groupes autorisés

Niveau : 🟡 Moyen Référence : CIS 5.1.x — Manual Profile : E5 / Copilot for M365 Add-on Licence requise : Microsoft 365 Copilot (add-on)

Description : Les licences Copilot doivent être assignées de manière contrôlée via des groupes d’approbation, et non distribués massivement. Un utilisateur avec Copilot peut accéder et synthétiser en secondes des volumes de données auxquels il aurait normalement accès mais ne consulterait jamais. Une gouvernance stricte des licences réduit la surface d’exposition.

Vérification :

# Lister les utilisateurs avec licence Copilot
Get-MgUser -All | Where-Object {
    $_.AssignedLicenses.SkuId -contains "639dec6b-bb19-468b-871c-c5c441c4b0cb" # SKU Copilot M365
} | Select-Object DisplayName, UserPrincipalName | Format-Table

# Vérifier le nombre total de licences utilisées
(Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -like "*COPILOT*" }).ConsumedUnits

Remédiation :

Microsoft 365 Admin Center > Facturation > Licences > Microsoft 365 Copilot
Créer un groupe de sécurité “Copilot-Autorisés” pour l’assignation des licences
Définir un processus d’approbation (manager + IT) pour les nouvelles demandes Copilot
Revoir trimestriellement la liste des utilisateurs Copilot et retirer les licences inutilisées
Lier l’activation Copilot à la completion d’une formation sur l’utilisation responsable de l’IA

Valeur par défaut : Les licences peuvent être assignées sans processus d’approbation.

14.1.7 — Détecter et bloquer les attaques par injection de prompt (Prompt Injection) dans Copilot

Niveau : 🟠 Élevé Référence : OWASP LLM Top 10 — LLM01 · Microsoft Purview — Manual MITRE ATT&CK : T1059 (Command and Scripting Interpreter) · T1534 (Internal Spearphishing) · T1656 (Impersonation) Licence requise : Microsoft 365 Copilot + Purview Communication Compliance

Description : Les attaques par injection de prompt ciblent Copilot for M365 de deux façons : (1) Injection directe — un utilisateur malveillant formule un prompt conçu pour contourner les garde-fous de Copilot et accéder à des données auxquelles il n’aurait normalement pas accès ; (2) Injection indirecte — un document SharePoint ou un email contient des instructions cachées (texte blanc sur fond blanc, métadonnées) qui manipulent Copilot lorsqu’il traite ce contenu pour exfiltrer des informations. Ces attaques sont difficiles à détecter sans surveillance spécifique.

Vérification :

# Rechercher des interactions Copilot anormales dans les logs d'audit
Connect-IPPSSession
$startDate = (Get-Date).AddDays(-30)
Search-UnifiedAuditLog -StartDate $startDate -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 100 |
    Select-Object CreationDate, UserIds, Operations, AuditData |
    Where-Object { $_.AuditData -match "SharePoint|OneDrive" } |
    Format-Table

# Rechercher des documents SharePoint avec du texte masqué (indicateur d'injection)
# Purview > Content Search > filtrer par type de document et contenu suspect

Remédiation :

Activer Microsoft Purview Communication Compliance avec politique de surveillance Copilot
Configurer des alertes sur les prompts contenant des patterns suspects (ex: “ignore previous instructions”, “act as”, injections en base64)
Activer la protection Purview Information Barriers pour prévenir les accès croisés non autorisés
Sensibiliser les utilisateurs aux risques d’injection via des documents SharePoint/email malveillants
Mettre en place une révision périodique des interactions Copilot à haut volume ou hors périmètre habituel
Activer Microsoft Defender XDR pour la détection des comportements Copilot anormaux

Valeur par défaut : Aucune protection spécifique contre les injections de prompt dans Copilot.

14.1.8 — Détecter les comptes zombies avec licences M365 actives (License Hygiene)

Niveau : 🟡 Moyen Référence : CIS 5.1.x — Manual MITRE ATT&CK : T1078 (Valid Accounts) · T1078.004 (Valid Accounts: Cloud) · T1531 (Account Access Removal) Licence requise : Microsoft 365 (toute édition)

Description : Les comptes “zombies” (utilisateurs désactivés ou partis depuis > 30 jours) qui conservent des licences M365 actives représentent un double problème : (1) Risque de sécurité — un compte désactivé peut être réactivé par un attaquant ou un insider, conservant ses accès et données ; (2) Coût inutile — chaque licence non recyclée représente un surcoût mensuel. Les licences Copilot (≈ 30$/user/mois) sont particulièrement importantes à récupérer. Une bonne hygiène de licences est aussi un signal de maturité en cybersécurité.

Vérification :

# Identifier comptes désactivés avec des licences actives
$disabledWithLicenses = Get-MgUser -All -Filter "accountEnabled eq false" `
    -Property "displayName,userPrincipalName,accountEnabled,assignedLicenses,signInActivity" |
    Where-Object { $_.AssignedLicenses.Count -gt 0 } |
    Select-Object DisplayName, UserPrincipalName,
        @{N="Licences";E={$_.AssignedLicenses.Count}},
        @{N="DernièreConnexion";E={$_.SignInActivity.LastSignInDateTime}}
$disabledWithLicenses | Format-Table
Write-Host "Total comptes zombies avec licences: $($disabledWithLicenses.Count)" -ForegroundColor Red

# Identifier comptes avec licence Copilot inactifs depuis > 90 jours
$copilotSku = "639dec6b-bb19-468b-871c-c5c441c4b0cb"
$staleDate = (Get-Date).AddDays(-90)
Get-MgUser -All -Property "displayName,userPrincipalName,assignedLicenses,signInActivity" |
    Where-Object {
        $_.AssignedLicenses.SkuId -contains $copilotSku -and
        ($_.SignInActivity.LastSignInDateTime -lt $staleDate -or $_.SignInActivity.LastSignInDateTime -eq $null)
    } | Select-Object DisplayName, UserPrincipalName | Format-Table

Remédiation :

Supprimer immédiatement les licences des comptes désactivés
Mettre en place un processus de départ automatisé (offboarding) : désactivation → retrait licence → archivage → suppression (90 jours)
Configurer une Access Review automatique trimestrielle pour les comptes inactifs depuis > 90 jours
Récupérer en priorité les licences Premium (Copilot, E5, Entra ID P2)
Intégrer la revue de licences dans le processus RH de départ

Valeur par défaut : Les licences sont conservées sur les comptes désactivés jusqu’à suppression manuelle.

14.1.9 — Désactiver ou restreindre la recherche Web dans Copilot pour M365

Niveau : 🟠 Élevé Référence : Microsoft Copilot Security — OWASP LLM09

Description : La recherche Web dans Copilot permet à l’outil d’interroger Bing lors d’une interaction. Des prompts contenant des données internes sensibles (noms de projets confidentiels, clients, données financières) peuvent ainsi être partiellement exposés à des moteurs de recherche externes ou au traitement Bing. Dans les environnements haute sécurité, cette fonctionnalité doit être désactivée ou limitée aux utilisateurs autorisés.

Vérification :

Microsoft 365 Admin Center > Paramètres > Copilot > Recherche Web
Ou via Microsoft 365 Apps Admin Center > Paramètres de confidentialité Copilot

Remédiation :

Microsoft 365 Admin Center > Paramètres > Microsoft Copilot
Désactiver “Autoriser les utilisateurs à utiliser la recherche Web dans Copilot”
Si recherche web nécessaire pour certains groupes : créer une stratégie ciblée
Informer les utilisateurs de la désactivation et des raisons de sécurité

Valeur par défaut : Recherche Web activée — les prompts peuvent interroger Bing.

14.1.10 — Gouverner la création d’agents Copilot personnalisés par les utilisateurs

Niveau : 🟠 Élevé Référence : Microsoft Copilot Extensibility — OWASP LLM08

Description : Microsoft 365 Copilot permet aux utilisateurs de créer des “agents” (Custom Copilot) qui peuvent accéder à des sources de données spécifiques, exécuter des actions et être partagés avec d’autres utilisateurs. Sans gouvernance, un utilisateur peut créer un agent malveillant ou mal configuré qui exfiltre des données via des prompts, partage des informations sensibles avec des utilisateurs non autorisés, ou interagit avec des API externes non approuvées.

Vérification :

Microsoft 365 Admin Center > Paramètres > Copilot > Agents et plugins
Vérifier qui peut créer et publier des agents

Remédiation :

Restreindre la création d’agents Copilot aux utilisateurs/groupes approuvés
Exiger une approbation IT avant la publication d’un agent à d’autres utilisateurs
Activer l’audit des agents créés dans Microsoft Purview
Revoir trimestriellement les agents publiés dans l’organisation

Valeur par défaut : Tous les utilisateurs Copilot peuvent créer et partager des agents.

14.1.11 — Configurer la rétention et l’audit des interactions Copilot (prompts et réponses)

Niveau : 🟠 Élevé Référence : Microsoft Purview — Copilot Audit

Description : Les interactions Copilot (prompts et réponses) doivent être journalisées dans Microsoft Purview pour permettre l’investigation forensic en cas d’incident : fuite de données, utilisation inappropriée, ou injection de prompt réussie. Sans journalisation, il est impossible de déterminer quelles données ont été exposées lors d’un incident impliquant Copilot.

Vérification :

# Vérifier que les événements Copilot sont dans l'audit log
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -RecordType CopilotInteraction -ResultSize 10 | Select-Object CreationDate, UserIds, Operations
# Résultat attendu : événements présents si Copilot est utilisé

Remédiation :

S’assurer que l’Unified Audit Log est activé (contrôle 6.1.1)
Microsoft Purview > Audit > Vérifier que “CopilotInteraction” est dans les événements journalisés
Créer une politique de rétention Purview couvrant les interactions Copilot (12 mois minimum)
Configurer des alertes sur les interactions avec des fichiers hautement sensibles (label Confidentiel)

Valeur par défaut : Interactions Copilot dans l’audit log si UAL activé — mais pas de politique de rétention spécifique.

SECTION 15 — ATTACK PATH & IDENTITY EXPOSURE

Contexte : Un audit de contrôles vérifie que les bonnes configurations existent. Cette section vérifie si un attaquant peut concrètement exploiter des chemins d’escalade dans le tenant. Elle transforme l’audit de posture en audit offensif-aware. Sources : Microsoft Security Exposure Management, BloodHound Enterprise concepts, Entra Attack Paths.

15.1 Chemins d’Escalade vers les Privilèges Globaux

15.1.1 — Auditer les chemins d’escalade vers Global Administrator (Attack Path)

Niveau : 🔴 Critique Référence : Microsoft Security Exposure Management — Automated

Description : Un chemin d’attaque vers Global Administrator existe quand une identité non-privilégiée peut atteindre ce rôle en une ou plusieurs étapes : via une App Registration avec permissions RoleManagement.ReadWrite.Directory, via un group owner d’un groupe assigné au rôle GA, via un SP avec credentials non sécurisés et droits élevés, ou via une Workload Identity Federation mal configurée. Ces chemins sont souvent invisibles dans les audits de configuration classiques.

Vérification :

# Identifier les identités pouvant s'escalader vers Global Admin
# Étape 1 : Apps avec RoleManagement.ReadWrite.Directory
$dangerous = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$expand=appRoleAssignments" -Method GET
$escalationPaths = @()

# Étape 2 : Propriétaires de groupes assignés à des rôles
$gaRole = Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'"
$gaGroups = Get-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id -All | Where-Object { $_.'@odata.type' -eq '#microsoft.graph.group' }
foreach ($group in $gaGroups) {
    $owners = Get-MgGroupOwner -GroupId $group.Id
    $escalationPaths += $owners | ForEach-Object {
        [PSCustomObject]@{ Type = "GroupOwner→GA"; Identity = $_.AdditionalProperties.displayName; Via = $group.AdditionalProperties.displayName }
    }
}
$escalationPaths | Format-Table
Write-Host "⚠️ Chemins d'escalade vers GA identifiés : $($escalationPaths.Count)"

Remédiation :

Pour chaque chemin d’escalade identifié : évaluer la légitimité et corriger
Supprimer les App Registrations non nécessaires avec permissions de gestion des rôles
Convertir les assignations de groupes directs en PIM for Groups
Activer Microsoft Security Exposure Management pour la détection continue des attack paths
Revoir trimestriellement les chemins d’escalade avec l’équipe SecOps

Valeur par défaut : Aucune détection automatique des chemins d’escalade — visibles uniquement via audit manuel ou outils spécialisés.

15.1.2 — Détecter les scénarios de contournement des politiques CA (CA Policy Bypass)

Niveau : 🔴 Critique Référence : Entra ID — CA Gap Analysis

Description : Les politiques CA peuvent être contournées via : des exclusions trop larges (groupes entiers exclus), des applications non couvertes (toutes les apps cloud ≠ toutes les apps réellement utilisées), des protocoles legacy non bloqués, ou des comptes service exclus sans justification. Un attaquant qui identifie ces angles morts peut s’y engouffrer. Microsoft propose un outil d’analyse des lacunes CA dans le portail Entra.

Vérification :

# Analyser les lacunes CA : utilisateurs exclus de la politique MFA principale
$mfaPolicy = Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.State -eq "enabled" -and
    $_.Conditions.Users.IncludeUsers -contains "All" -and
    $_.GrantControls.BuiltInControls -contains "mfa"
}
foreach ($policy in $mfaPolicy) {
    $excludedUsers = $policy.Conditions.Users.ExcludeUsers.Count
    $excludedGroups = $policy.Conditions.Users.ExcludeGroups.Count
    Write-Host "Politique: $($policy.DisplayName)"
    Write-Host "  Utilisateurs exclus : $excludedUsers"
    Write-Host "  Groupes exclus     : $excludedGroups"
    if ($excludedUsers + $excludedGroups -gt 5) {
        Write-Host "  ⚠️ Nombre d'exclusions élevé — risque de lacune CA" -ForegroundColor Yellow
    }
}
# Portail : Entra ID > Protection > CA > Insights & Reporting > What If

Remédiation :

Utiliser l’outil “What If” CA pour simuler des scénarios d’accès suspects
Réduire les exclusions au strict minimum (seulement Break Glass + comptes de service documentés)
Vérifier que les applications critiques (Exchange, SharePoint, Teams, Azure Portal) sont toutes couvertes
Activer le mode “Rapport seul” pour tester les nouvelles politiques avant activation
Revoir toutes les exclusions CA mensuellement

Valeur par défaut : Aucun outil de détection des lacunes CA — les bypass sont identifiables uniquement par revue manuelle.

15.1.3 — Auditer les scénarios d’abus de relations cross-tenant (Cross-Tenant Trust Abuse)

Niveau : 🟠 Élevé Référence : Entra ID — Cross-Tenant Access Settings

Description : Les relations B2B cross-tenant peuvent être exploitées si la politique d’accès cross-tenant est trop permissive : un tenant partenaire compromis peut utiliser sa relation de confiance pour pivoter vers votre tenant. Les paramètres de “trust MFA” (faire confiance au MFA du tenant partenaire) sont particulièrement risqués si le tenant partenaire a une posture MFA faible.

Vérification :

# Vérifier les paramètres de confiance cross-tenant
$xtapDefault = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default" -Method GET
Write-Host "Trust MFA externe : $($xtapDefault.inboundTrust.isMfaAccepted)"
Write-Host "Trust Compliant Device externe : $($xtapDefault.inboundTrust.isCompliantDeviceAccepted)"
if ($xtapDefault.inboundTrust.isMfaAccepted -eq $true) {
    Write-Host "⚠️ CRITIQUE : Vous faites confiance au MFA de tenants externes inconnus" -ForegroundColor Red
}

# Vérifier les partenaires avec trust MFA spécifique
$partners = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners" -Method GET
$partners.value | Where-Object { $_.inboundTrust.isMfaAccepted -eq $true } |
    Select-Object tenantId, displayName | Format-Table

Remédiation :

Désactiver le trust MFA par défaut pour les tenants inconnus
Activer le trust MFA uniquement pour des partenaires de confiance spécifiques et documentés
Revoir trimestriellement les partenaires avec relations de confiance actives
Pour les partenaires critiques : exiger leur conformité à votre politique MFA (pas de trust aveugle)

Valeur par défaut : Confiance MFA externe désactivée par défaut, mais configurable — risque si mal paramétré.

SECTION 16 — DETECTION & MATURITÉ SOC

Contexte : Vérifier la configuration ne suffit pas — il faut s’assurer que quelqu’un détecte réellement les attaques en cours. Cette section audite la capacité de détection et de réponse, passant de l’audit de posture à l’audit SOC-ready.

16.1 Détection des Menaces Identité

16.1.1 — Activer et configurer les alertes Defender for Identity mappées MITRE ATT&CK

Niveau : 🔴 Critique Référence : Microsoft Defender for Identity — CISA MS.DEFENDER Licence requise : Microsoft 365 E5 ou Defender for Identity add-on

Description : Microsoft Defender for Identity détecte les attaques sur les identités (pass-the-hash, pass-the-ticket, Kerberoasting, LDAP recon, DCSync, Golden Ticket). Sans alertes configurées et transmises au SOC, ces attaques sont invisibles même si toutes les politiques de configuration sont correctes. En 2026, les incidents M365 les plus graves (BEC, ransomware, APT) passent tous par la couche identité.

Vérification :

# Vérifier les alertes Defender for Identity actives
$alerts = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/security/alerts_v2?`$filter=serviceSource eq 'microsoftDefenderForIdentity'&`$top=20" -Method GET
Write-Host "Alertes Defender for Identity (7 derniers jours) : $($alerts.value.Count)"

# Vérifier la couverture des capteurs (pour environnements hybrides)
# Portail MDI : security.microsoft.com > Settings > Identities > Sensors

Remédiation :

Activer Microsoft Defender for Identity dans le portail Defender XDR
Pour environnements hybrides : déployer les capteurs MDI sur tous les Domain Controllers
Configurer les notifications email pour toutes les alertes de sévérité Haute et Critique
Intégrer les alertes MDI dans Microsoft Sentinel via le connecteur MDI
Créer des règles d’analytics Sentinel pour les tactiques MITRE clés : T1078 (Valid Accounts), T1110 (Brute Force), T1003 (Credential Dumping)

Valeur par défaut : Defender for Identity non configuré — les attaques sur les identités sont invisibles.

16.1.2 — Activer les Use Cases Microsoft Sentinel pour BEC, Token Theft et Consent Grant

Niveau : 🟠 Élevé Référence : Microsoft Sentinel — MITRE ATT&CK Coverage Licence requise : Microsoft Sentinel (Log Analytics)

Description : Microsoft Sentinel propose des règles d’analytics prêtes à l’emploi (OOTB) pour les scénarios d’attaque M365 les plus courants. Sans ces règles activées, les indicateurs d’attaque sont dans les logs mais personne ne les corrèle : un vol de token, une campagne BEC ou un consent phishing réussi passent inaperçus pendant des semaines.

Vérification :

# Les règles Sentinel ne sont pas vérifiables via Graph — utiliser le portail
# Sentinel > Analytics > Vérifier les règles actives pour :
$keyRules = @(
    "Suspicious application consent similar to O365 Attack Toolkit",
    "Rare application consent",
    "Mail forwarding rules to external domains",
    "Token-stealing sign-in patterns",
    "Azure AD Identity Protection risky sign-ins",
    "Sign-ins from IPs matching known malicious actors"
)
Write-Host "Règles clés à vérifier dans Sentinel Analytics :"
$keyRules | ForEach-Object { Write-Host "  - $_" }

Remédiation :

Microsoft Sentinel > Gestion des contenus > Hub de contenus > Microsoft 365 Defender
Installer la solution “Microsoft 365 Defender” (inclut les règles BEC, Token Theft, etc.)
Activer les règles d’analytics OOTB pour M365 Identity
Configurer la fréquence de détection : 5 minutes pour les alertes critiques
Créer des playbooks d’auto-réponse (Logic Apps) pour les alertes haute sévérité

Valeur par défaut : Aucune règle d’analytics activée — les logs sont collectés mais non analysés.

16.1.3 — Activer UEBA (User and Entity Behavior Analytics) dans Microsoft Sentinel

Niveau : 🟠 Élevé Référence : Microsoft Sentinel UEBA Licence requise : Microsoft Sentinel + Entra ID P2

Description : L’UEBA (User and Entity Behavior Analytics) dans Sentinel construit des profils comportementaux pour chaque utilisateur et entité (appareil, IP, application). Toute déviation statistiquement significative génère une alerte avec score de risque. C’est la détection des “unknown unknowns” — les comportements anormaux qui ne correspondent à aucune règle connue mais indiquent une compromission (utilisateur se connectant à 3h du matin, accédant à des fichiers inhabituels, depuis une IP jamais vue).

Vérification :

Microsoft Sentinel > Configuration > Paramètres > UEBA
Vérifier que UEBA est activé et que les sources de données sont connectées

Remédiation :

Microsoft Sentinel > Configuration > Paramètres > UEBA
Activer UEBA pour le tenant
Connecter les sources : Entra ID Sign-in Logs, Audit Logs, Defender for Endpoint
Définir les groupes sensibles pour la surveillance renforcée (Direction, Finance, IT)
Configurer des alertes sur les scores UEBA > 8/10

Valeur par défaut : UEBA désactivé — aucune analyse comportementale des utilisateurs.

SECTION 17 — GOUVERNANCE OPÉRATIONNELLE SÉCURITÉ

Contexte : Les auditeurs NIS2, ISO 27001 et SOC2 exigent non seulement des contrôles techniques, mais la preuve qu’ils sont maintenus dans le temps via des processus opérationnels documentés.

17.1 Processus et Runbooks SOC

17.1.1 — Documenter et tester les runbooks SOC pour les incidents M365

Niveau : 🟠 Élevé Référence : NIST SP 800-61 — Incident Response — Manual

Description : Un tenant M365 sans runbooks SOC est une organisation qui découvrira comment répondre à un incident pendant l’incident. Les runbooks doivent couvrir les scénarios les plus probables : compromission de compte admin, BEC (virement frauduleux), ransomware cloud, exfiltration SharePoint, consent phishing réussi. Ils doivent être testés annuellement via des exercices tabletop.

Vérification :

Demander les runbooks SOC M365 à l’équipe sécurité
Vérifier la date du dernier test (tabletop ou exercice réel)
Vérifier que les runbooks couvrent les scénarios : compromission admin, BEC, ransomware cloud, consent phishing

Remédiation :

Créer des runbooks pour chaque scénario d’incident M365 critique
Chaque runbook doit inclure : détection, confinement, éradication, récupération, communication
Tester les runbooks via tabletop exercise annuel minimum
Intégrer les runbooks dans Microsoft Sentinel comme playbooks Logic Apps
Former l’équipe SOC sur les spécificités M365 (Graph API, PowerShell, portail Defender)

Valeur par défaut : Aucun runbook SOC M365 — réponse aux incidents improvisée.

17.1.2 — Automatiser la rotation des secrets App Registration (< 90 jours)

Niveau : 🟠 Élevé Référence : CIS 5.x — Automated

Description : Les secrets clients des App Registrations ont souvent des durées de vie excessives (jusqu’à 2 ans), parfois créés avec des valeurs maximales par habitude. Un secret expiré ou volé non détecté reste utilisable jusqu’à sa date d’expiration. La rotation automatique via Azure Key Vault ou des scripts planifiés garantit qu’aucun secret n’a une durée de vie supérieure à 90 jours.

Vérification :

# Secrets App Registration avec expiration > 90 jours ou déjà expirés
$cutoff90 = (Get-Date).AddDays(90)
Get-MgApplication -All | ForEach-Object {
    $app = $_
    $app.PasswordCredentials | ForEach-Object {
        [PSCustomObject]@{
            App        = $app.DisplayName
            SecretName = $_.DisplayName
            Created    = $_.StartDateTime
            Expires    = $_.EndDateTime
            Status     = if ($_.EndDateTime -lt (Get-Date)) { "❌ EXPIRÉ" }
                         elseif ($_.EndDateTime -gt $cutoff90) { "⚠️ DURÉE > 90j" }
                         else { "✅ OK" }
        }
    }
} | Where-Object { $_.Status -ne "✅ OK" } | Format-Table

Remédiation :

Créer un script planifié (Azure Automation Runbook) pour détecter les secrets expirant dans 30 jours
Envoyer une alerte au propriétaire de l’application 30 jours avant expiration
Migrer vers Azure Key Vault + Managed Identity pour les applications Azure
Pour les apps impossibles à migrer : rotation automatique via Automation Account
Définir une politique : durée maximale des secrets = 90 jours

Valeur par défaut : Secrets avec durée de vie jusqu’à 2 ans — aucune rotation automatique.

17.1.3 — Réaliser un exercice Purple Team annuel sur le tenant M365

Niveau : 🟡 Moyen Référence : CISA CTEM (Continuous Threat Exposure Management) — Manual

Description : Un Purple Team exercise combine des attaques simulées (Red Team) avec une analyse en temps réel de la détection (Blue Team) sur le tenant M365. Les scénarios typiques : MFA Fatigue attack, AiTM phishing, consent phishing, exfiltration SharePoint via API, privilege escalation via App Registration. Ces exercices révèlent les lacunes de détection que les audits de configuration ne trouvent pas.

Vérification :

Demander le rapport du dernier Purple Team exercise M365
Vérifier que les scénarios MITRE ATT&CK couvrent au minimum : Initial Access (T1566), Credential Access (T1078), Persistence (T1098), Exfiltration (T1048)

Remédiation :

Planifier un Purple Team exercise M365 annuel (ou semestriel pour les organisations à risque élevé)
Utiliser des outils de simulation : Microsoft Attack Simulator (pour phishing), AADInternals (pour tests AD), Maester (pour validation de posture)
Documenter tous les écarts de détection identifiés et les corriger dans les 30 jours
Mettre à jour les règles Sentinel et les runbooks SOC après chaque exercice

Valeur par défaut : Aucun exercice Purple Team — lacunes de détection non identifiées.

SECTION 18 — RISQUE HUMAIN & INSIDER THREAT

Contexte : 85% des incidents de sécurité impliquent l’humain. Cette section audite les contrôles ciblant le comportement humain — phishing, erreurs non intentionnelles, et risques internes.

18.1 Sensibilisation et Simulation

18.1.1 — Déployer des simulations de phishing régulières avec métriques de taux de clic

Niveau : 🟠 Élevé Référence : CIS Control 14 — Security Awareness Licence requise : Microsoft Defender for Office 365 P2 (Attack Simulator)

Description : Microsoft Attack Simulator (intégré dans Defender for Office 365 P2) permet de lancer des campagnes de phishing simulées ciblant les utilisateurs. Sans simulation régulière, le taux de clic réel sur les phishing est inconnu, et les utilisateurs vulnérables ne sont pas identifiés. L’objectif est un taux de clic < 5% après formation et une amélioration mesurable d’une campagne à l’autre.

Vérification :

Portail Defender > Entraînement à la simulation d’attaque
Vérifier la date de la dernière simulation et le taux de clic moyen

Remédiation :

Portail Defender > Entraînement à la simulation d’attaque > Créer une simulation
Fréquence recommandée : une simulation par trimestre minimum
Cibler en priorité : Direction, Finance, RH, IT (comptes à haut risque)
Assigner automatiquement une formation aux utilisateurs qui cliquent
Partager les métriques avec la direction (taux de clic, évolution, comparaison sectorielle)

Valeur par défaut : Aucune simulation de phishing configurée.

18.1.2 — Activer et configurer Insider Risk Management (Microsoft Purview)

Niveau : 🟠 Élevé Référence : CISA Insider Threat — Manual Licence requise : Microsoft 365 E5 Compliance ou add-on

Description : Microsoft Purview Insider Risk Management détecte les comportements anormaux pouvant indiquer un risque interne : téléchargements massifs avant une démission, envois de fichiers vers des emails personnels, accès inhabituels à des projets sensibles, utilisation de clés USB. En 2026, les départs d’employés vers des concurrents accompagnés d’exfiltration de données sont l’une des menaces internes les plus fréquentes.

Vérification :

Microsoft Purview > Insider Risk Management > Vue d’ensemble
Vérifier si des politiques de risque sont actives et si des alertes ont été générées

Remédiation :

Microsoft Purview > Insider Risk Management > Politiques > Créer
Activer la politique “Fuite de données par des utilisateurs qui quittent l’entreprise”
Connecter les données RH (dates de départ) via le connecteur RH Purview
Définir des indicateurs : exfiltration email, téléchargements SharePoint, activité USB
Configurer des seuils d’alerte adaptés au contexte de l’organisation

Valeur par défaut : Insider Risk Management non configuré — risques internes non détectés.

18.1.3 — Surveiller le Shadow IT via Microsoft Defender for Cloud Apps (MCAS)

Niveau : 🟡 Moyen Référence : CIS Control 2 — Software Asset Management Licence requise : Microsoft 365 E5 ou Defender for Cloud Apps add-on

Description : Le Shadow IT — applications cloud utilisées par les employés sans approbation IT — représente un vecteur de fuite de données majeur. Des utilisateurs copiant des données M365 vers Dropbox, Slack personnel, ou des outils IA non approuvés créent des canaux d’exfiltration non surveillés. Microsoft Defender for Cloud Apps découvre ces usages via les logs réseau et les signaux Microsoft 365.

Vérification :

Portail Defender > Cloud Apps > Cloud Discovery > Tableau de bord
Vérifier le nombre d’applications découvertes et leur niveau de risque

Remédiation :

Activer Cloud Discovery dans Defender for Cloud Apps
Intégrer les logs réseau (proxy, pare-feu) ou utiliser l’intégration Defender for Endpoint
Identifier les applications à risque élevé et les bloquer via Conditional Access App Control
Créer une politique d’utilisation acceptable pour les applications cloud (liste approuvée)
Générer un rapport mensuel Shadow IT pour la direction sécurité

Valeur par défaut : Shadow IT non surveillé — fuite de données via applications non approuvées invisible.

RÉCAPITULATIF — CHECKLIST RAPIDE D’AUDIT M365

Cochez chaque point lors de l’audit. Un point non conforme (❌) doit faire l’objet d’un plan de remédiation avec priorité et date cible.

SECTION 1 — IDENTITÉS ET ACCÈS (MFA, CA, PIM, Invités)

#	Contrôle	Réf.	Niveau	Statut
1.1.1	MFA activé pour TOUS les comptes Administrateurs	MS.AAD.3.2v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.2	MFA activé pour TOUS les utilisateurs	MS.AAD.3.2v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.3	MFA résistante au phishing exigée pour les rôles admin (FIDO2/WHfB)	MS.AAD.3.6v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.4	SMS, appel vocal et Email OTP désactivés comme méthodes MFA	MS.AAD.3.5v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.5	Number Matching activé pour Microsoft Authenticator	MS.AAD.3.3v2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.6	Migration des méthodes d’authentification terminée	MS.AAD.3.4v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.7	Migration méthodes d’authentification finalisée	MS.AAD.3.4v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.1.8	Authentification héritée (Legacy Auth) bloquée	MS.AAD.1.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.2b.1	Expiration des mots de passe désactivée	MS.AAD.6.1v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.2b.2	Protection des mots de passe Entra ID activée	CIS 5.2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.2b.3	Smart Lockout configuré (≤10 tentatives, ≥60s)	CIS 5.2 + M365SAT	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.2b.4	Liste de mots de passe bannis personnalisée configurée	M365SAT CISAz68 + EIDSCA.PR03	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.2b.5	SSPR exige 2 méthodes d’authentification	M365SAT CISAz65	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.1	Security Defaults OU Accès Conditionnel activé	CIS 4.1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.2	Politique CA : appareils conformes exigés	MS.AAD.3.7v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.3	Politique CA : blocage pays à risque	CIS 13.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.4	Politique CA : protection portails Azure Management	CIS 4.1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.5	Fréquence de reconnexion configurée (appareils non gérés)	CIS 4.3	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.6	CA : Device Code Flow bloqué (Storm-2372)	MT.1052 + CA-DEVICECODE-001	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.7	CA : Legacy Auth complète bloquée (Other Clients + EAS)	MS.AAD.1.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.3.8	CA : Auth résistante au phishing pour admins (FIDO2/Passkey)	MS.AAD.3.6v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.4.1	Politique CA : utilisateurs à HAUT RISQUE bloqués	MS.AAD.2.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.4.2	Politique CA : connexions à HAUT RISQUE bloquées	MS.AAD.2.3v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5.1	Enregistrement d’applications restreint aux admins	MS.AAD.5.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5.2	Consentement apps tierces désactivé pour les utilisateurs	MS.AAD.5.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5.3	Workflow de consentement administrateur activé	MS.AAD.5.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.1	Permissions Midnight Blizzard (AppRoleAssignment + RoleManagement) auditées	Inspect-DangerousAppPerms	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.2	Rôles Partner Tier1/Tier2 Support audités (invisibles UI)	Inspect-PartnerSupport	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.3	Apps avec certificat credentials examinées (bypass MFA/CA)	Inspect-AppKeyCredentials	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.4	Managed Identities avec permissions Graph dangereuses auditées	MT.1050/1051	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.5	Propriétaires d’app registrations sans MFA identifiés	MT.1063	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.5c.6	Service Principals / Workload Identities dormants > 90 jours identifiés	M365-Assess ENTRA-ENTAPP	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.6.1	Journaux Entra ID envoyés vers SIEM (12 mois actif)	MS.AAD.4.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.7.1	Accès invités aux objets d’annuaire limité	MS.AAD.8.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.7.2	Invitation de guests restreinte (rôle Guest Inviter uniquement)	MS.AAD.8.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.7.3	Invitations guests limitées aux domaines approuvés	MS.AAD.8.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.1	PIM activé — Aucune assignation permanente de rôle privilégié	MS.AAD.7.4v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.2	Nombre de Global Admins entre 2 et 8	MS.AAD.7.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.3	Rôles à granularité fine utilisés (pas de GA inutile)	MS.AAD.7.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.4	Comptes admin provisionnés en cloud-only (pas de sync AD)	MS.AAD.7.3v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.5	Approbation requise pour activer le rôle Global Administrator	MS.AAD.7.6v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.6	Alertes sur activations de rôles privilégiés configurées	MS.AAD.7.7v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.7	Comptes Break Glass créés et sécurisés	CIS 5.4	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.8	Comptes admin dédiés sans messagerie	CIS 5.4	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.9	Access Reviews trimestrielles configurées pour rôles admin	CIS 5.4	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.10	PIM : approbation requise pour Privileged Role Administrator	MS.AAD.7.8v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.11	Access Reviews configurées pour tous les rôles admin (PIM)	MS.AAD.7.9v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.12	Admins inactifs >90 jours détectés et désactivés	ENTRA-STALEADMIN-001	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.13	Admins privilégiés non exclus des politiques CA critiques	CA-EXCLUSION-001 + MT.1036	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.14	Comptes AD synchronisés absents des rôles cloud privilégiés	Inspect-DirSyncAdmins + MT.1026	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.8.15	Authentification Passwordless (FIDO2/WHfB) enforced pour comptes privilégiés	MS.AAD.3.6v1 + MS.AAD.3.8v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.1	Groupe dynamique pour utilisateurs invités créé	CIS 5.1.3.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.2	Création de groupes de sécurité par les utilisateurs désactivée	CIS 5.1.3.2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.3	Nombre maximum d’appareils par utilisateur ≤ 20	CIS 5.1.4.2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.4	GA non ajouté comme admin local lors de la jointure Entra	CIS 5.1.4.3	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.5	Jointure d’appareils à Entra restreinte (L2)	CIS 5.1.4.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.6	Option “Rester connecté” masquée (L2)	CIS 5.1.2.5	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.9.7	Intégration LinkedIn désactivée (L2)	CIS 5.1.2.6	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.10.1	Paramètres d’accès cross-tenant (XTAP) configurés de manière restrictive	CIS 5.1.5.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.10.2	Tenant Restrictions v2 (TRv2) activées	MS.AAD.7.x	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.10.3	Évaluation Continue des Accès (CAE) activée (mode complet)	MS.AAD.6.x	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.10.4	Access Reviews trimestrielles pour utilisateurs invités B2B	CIS 5.1.8.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.11.1	Access packages avec rôles obsolètes identifiés	MT.1106	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.11.2	Access packages référençant des groupes supprimés nettoyés	MT.1107	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.11.3	Politiques d’access packages inactives/orphelines identifiées	MT.1108	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.11.4	Approbateurs invalides dans workflows d’access packages corrigés	MT.1109	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
1.11.5	Catalogues sans access packages associés identifiés	MT.1110	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 2 — MICROSOFT DEFENDER FOR OFFICE 365

#	Contrôle	Réf.	Niveau	Statut
2.1.1	Politique de sécurité Standard activée (tous utilisateurs)	MS.DEFENDER.1.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.1.2	Politique de sécurité Stricte activée (utilisateurs sensibles)	MS.DEFENDER.1.4v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.2.1	Politiques Anti-Phishing configurées (niveau agressif)	MS.DEFENDER.2.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.2.2	SPF publié pour tous les domaines (mécanisme -all)	MS.EXO.2.2v3	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.2.3	DKIM activé pour tous les domaines	MS.EXO.3.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.2.4	DMARC p=reject pour tous les domaines	MS.EXO.4.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.2.5	Anti-Spoofing activé et configuré	CIS 9.2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.3.1	Safe Attachments activé pour Email, SPO, OneDrive, Teams	MS.DEFENDER.3.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.3.2	Safe Links activé (AllowClickThrough = Off)	MS.EXO.15.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.3.3	Filtrage des types de fichiers dangereux activé	MS.EXO.9.1v2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.4.1	Anti-Spam configuré (spam/phishing → quarantaine)	MS.EXO.14.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
2.4.2	DLP personnalisée pour PII (CC, IBAN, NIR, etc.)	MS.DEFENDER.4.1v2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 3 — EXCHANGE ONLINE ET MESSAGERIE

#	Contrôle	Réf.	Niveau	Statut
3.1.1	Transfert automatique vers domaines externes désactivé	MS.EXO.1.1v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.2	Avertissement d’expéditeur externe configuré ([EXTERNE])	MS.EXO.7.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.3	Audit des boîtes mail (Mailbox Auditing) activé	MS.EXO.13.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.4	SMTP AUTH désactivé au niveau organisation	MS.EXO.5.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.5	POP3 et IMAP4 désactivés pour tous les utilisateurs	CIS 4.8	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.6	Listes blanches IP (IPAllowList) vides dans anti-spam	MS.EXO.12.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.7	Aucun domaine en liste d’autorisation anti-spam	MS.EXO.14.3v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.8	ZAP (Zero-Hour Auto Purge) activé	MS.EXO.10.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.9	TLS configuré pour les partenaires critiques	CIS 3.10	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.10	Chiffrement OME configuré pour données sensibles	CIS 3.10	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.11	DMARC p=reject (pas p=none) pour tous les domaines	Inspect-DMARCPolicyAction	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.12	SPF hard fail (-all) et non soft fail (~all)	Inspect-SPFSoftFail	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.13	7 alertes obligatoires Microsoft Exchange configurées	MS.EXO.16.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.14	First Contact Safety Tips + Mailbox Intelligence activés	MS.EXO.11.2/11.3 + ORCA.241	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.15	Règles transport bypass PhishSim inexistantes/sécurisées	Inspect-SimPhish	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.16	ARC (Authenticated Received Chain) configuré	ORCA.243	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.1.17	Délégations boîte mail auditées (Send As, Full Access)	Inspect-EXOSendAsPermissions	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.1	Partage de dossiers de contacts avec domaines externes désactivé	MS.EXO.6.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.2	Détails de calendriers non partagés avec tous les domaines	MS.EXO.6.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.3	Alertes Exchange obligatoires CISA activées (7 alertes)	MS.EXO.16.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.4	Audit Log rétention ≥ 12 mois actif + 18 mois archive	MS.EXO.17.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.5	Connexion directe aux boîtes partagées bloquée	CIS 1.2.2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.6	Aucune règle de transport n’autorise des domaines entiers (SCL=-1)	CIS 6.2.2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.7	AuditBypassEnabled désactivé sur toutes les boîtes	CIS 6.1.3	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.8	Politique anti-spam sortant avec limites d’envoi configurées	CIS 2.1.15	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.9	Safe list filtre de connexion désactivée	CIS 2.1.13	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.10	Notifications admin pour malware sortant interne activées	CIS 2.1.3	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
3.2.11	Règles de boîte de réception malveillantes détectées et bloquées	CIS 6.2.4 + MS.EXO.8.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 4 — MICROSOFT TEAMS

#	Contrôle	Réf.	Niveau	Statut
4.1.1	Utilisateurs anonymes ne peuvent PAS démarrer de réunions	MS.TEAMS.1.2v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.2	Accès invité Teams restreint et gouverné	MS.TEAMS CIS	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.3	Accès externe : seulement domaines spécifiques autorisés	MS.TEAMS.2.1v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.4	Utilisateurs non gérés ne peuvent PAS initier le contact	MS.TEAMS.2.2v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.5	Réunions : salle d’attente pour invités/anonymes	MS.TEAMS.1.3v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.6	Intégration email dans les canaux Teams désactivée	MS.TEAMS.4.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.7	Gouvernance des applications Teams (apps tierces contrôlées)	MS.TEAMS.5.2v2	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.8	Safe Attachments pour Teams activé	MS.TEAMS.7.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.9	Stockage cloud tiers désactivé dans Teams (Box, Dropbox, GDrive, Egnyte, ShareFile)	M365SAT CISMTm811	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.10	Partage d’écran restreint (SingleApplication)	CIS 3.3	🟢	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.1.11	Utilisateurs Teams non gérés ne peuvent initier de conversations	MS.TEAMS.2.2v2	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.2.6	Signalement d’incidents de sécurité Teams activé	CIS 8.6.1 + TEAMS-REPORTING-001	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
4.2.7	Publication automatique des enregistrements Teams désactivée	MS.TEAMS.3.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 5 — SHAREPOINT ONLINE ET ONEDRIVE

#	Contrôle	Réf.	Niveau	Statut
5.1.1	Partage SharePoint ≤ “Invités existants”	MS.SHAREPOINT.1.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.2	Partage OneDrive ≤ “Invités existants”	MS.SHAREPOINT.1.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.3	Partage externe restreint aux domaines approuvés	MS.SHAREPOINT.1.3v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.4	Type de lien par défaut : “Personnes spécifiques”	MS.SHAREPOINT.2.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.5	Permissions par défaut des liens : Affichage uniquement	MS.SHAREPOINT.2.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.2b	Expiration obligatoire liens anonymes ≤ 30 jours — `RequireAnonymousLinksExpireInDays` configuré (défaut = -1 = ∞)	CIS 7.2.9 / MS.SHAREPOINT.3.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.7	Liens “Anyone” : permission Affichage uniquement	MS.SHAREPOINT.3.2v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.8	Ré-authentification code de vérification ≤ 30 jours	MS.SHAREPOINT.3.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.9	Accès conditionnel pour appareils non gérés activé	CIS 12.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.13	Partage externe SharePoint restreint à un groupe de sécurité	SPO-SHARING-008 + MS.SHAREPOINT.1.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.14	Expiration automatique accès guest SPO/OD (≤60 jours)	CIS 7.2.9	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
5.1.17	Scripts personnalisés bloqués sur les sites SharePoint	SPO-SCRIPT-001/002	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 6 — PROTECTION DE L’INFORMATION ET CONFORMITÉ

#	Contrôle	Réf.	Niveau	Statut
6.1.1	Audit Log unifié activé	MS.EXO.17.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
6.1.2	Politiques de rétention configurées (Exchange, SPO, OD, Teams)	CIS 3.11	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
6.1.3	Politiques DLP actives pour données sensibles (PII)	MS.DEFENDER.4.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
6.1.4	Étiquettes de sensibilité déployées	CIS 3.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
6.1.5	Communication Compliance configurée (si secteur réglementé)	CIS 3.3	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
6.1.6	Insider Risk Management — au moins 1 politique active (Data Leaks / Departing Users)	CIS 3.3 + 13.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 7 — SÉCURITÉ DES APPAREILS (INTUNE)

#	Contrôle	Réf.	Niveau	Statut
7.1.1	BitLocker exigé via Intune pour tous les appareils Windows	CIS 3.6	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.2	Code PIN/mot de passe exigé sur appareils mobiles	CIS 4.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.3	App Protection Policies (MAM) configurées pour BYOD	CIS 2.7	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.4	Windows Hello for Business activé	MS.AAD.3.7v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.5	Appareils sans politique de conformité = Non conforme (L2)	CIS 4.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.6	Inscription d’appareils personnels bloquée par défaut (L2)	CIS 4.2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.7	Multi-Admin Approval (MAA) Intune activé pour actions critiques	MT.1096 + INTUNE-MAA-001	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.8	Autorité MDM définie sur Intune (pas SCCM ou non configuré)	MT.1105	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.1.9	Nettoyage automatique appareils inactifs Intune configuré	MT.1053	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.2.1	Tamper Protection (anti-falsification MDE) activée	CIS MDE	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.2.2	Règles ASR (Attack Surface Reduction) configurées en mode Block	CIS MDE + NIST SI-3	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.2.3	Network Protection activée en mode Block	CIS MDE	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.2.4	Investigation et réponse automatisées (AIR) configurées en mode complet	MS.DEFENDER.1.5v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
7.2.5	Protection antivirus en temps réel activée et supervisée	CIS 9.4.1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 8 — SECURE SCORE ET MONITORING

#	Contrôle	Réf.	Niveau	Statut
8.1.1	Secure Score ≥ 50% et suivi régulier	CIS 1.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.2	7 alertes Exchange/Defender obligatoires CISA actives	MS.EXO.16.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.3	Alertes de sécurité personnalisées configurées et surveillées	MS.EXO.16.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.4	Defender for Identity déployé (si hybride AD)	CIS 8.11	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.5	Defender for Cloud Apps (CASB) activé	CIS 8.11	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.6	Protection des comptes prioritaires activée (E5)	CIS 2.4.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.7	Comptes prioritaires avec preset Strict Defender (E5)	CIS 2.4.2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.8	Alertes d’activité configurées pour comptes Break Glass	CIS 2.2.1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.9	Credentials admins exposés sur endpoints vulnérables détectés (XSPM)	MT.1080	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
8.1.10	Drift de configuration détecté (baseline JSON comparée)	MT.1060	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 9 — POWER PLATFORM

#	Contrôle	Réf.	Niveau	Statut
9.1.1	Création d’environnements production/sandbox restreinte aux admins	MS.POWERPLATFORM.1.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.2	Création d’environnements d’essai restreinte aux admins	MS.POWERPLATFORM.1.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.3	Isolation des tenants Power Platform activée	MS.POWERPLATFORM.3.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.4	Content Security Policy (CSP) pour Power Apps activée	MS.POWERPLATFORM.4.1v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.5	Création de sites Power Pages restreinte aux admins	MS.POWERPLATFORM.5.1v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.6	Partage “Tout le monde” Power Apps désactivé	MS.POWERPLATFORM.6.1v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.7	Politiques DLP Power Platform configurées	MS.POWERPLATFORM.2.1v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
9.1.8	DLP pour environnements non-default configurée	MS.POWERPLATFORM.2.2v1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 10 — MICROSOFT FABRIC (POWER BI)

#	Contrôle	Réf.	Niveau	Statut
10.1.1	Accès invité à Microsoft Fabric restreint	MS.POWERBI.1.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.2	Invitations d’utilisateurs externes dans Fabric désactivées	MS.POWERBI.1.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.3	Accès invité au contenu Fabric restreint	MS.POWERBI.1.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.4	Publication sur Internet (Publish to Web) désactivée	MS.POWERBI.2.1v1	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.5	Visuels R et Python interactifs désactivés	CIS 9.1.5	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.6	Étiquettes de sensibilité appliquées dans Fabric	MS.POWERBI.3.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.7	Liens partageables dans Fabric restreints	MS.POWERBI.2.3v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.8	Partage de données externes dans Fabric restreint	MS.POWERBI.2.2v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.9	BlockResourceKeyAuthentication activé dans Fabric	MS.POWERBI.4.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.10	Accès APIs Fabric par principaux de service restreint	CIS 9.1.10	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.11	Principaux de service ne peuvent créer de profils Fabric	CIS 9.1.11	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.12	Création d’espaces de travail Fabric par SP restreinte	CIS 9.1.12	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
10.1.13	Partage de datasets Power BI cross-workspace restreint	MS.POWERBI.5.1v1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 11 — MICROSOFT 365 APPS — SÉCURITÉ OFFICE

#	Contrôle	Réf.	Niveau	Statut
11.1.1	Signature des macros exigée (Require Macro Signing)	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.2	Macros VBA bloquées depuis Internet (MOTW)	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.3	Objets OLE actifs bloqués dans PowerPoint	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.4	Exécution DDE bloquée dans Excel	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.5	Formats de fichiers hérités bloqués (Legacy File Block)	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.6	JScript hérité désactivé dans zones restreintes Office	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.1.7	Add-ins Office non gérés désactivés (DisableAllAddIns)	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.2.1	Protocoles non-HTTPS bloqués dans les apps Office	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.2.2	Liens externes Excel bloqués (File Block External Links)	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.2.3	Fallback FPRPC bloqué dans les apps Office	MSCT v2512	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.2.4	Composants OLE Graph hérités désactivés (MSGraph)	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.2.5	Add-in OrgChart hérité désactivé	MSCT v2512	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.3.1	Journalisation des erreurs Office activée via Intune	MSCT v2512	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
11.3.2	Protected View renforcé — documents malveillants bloqués	MSCT v2512	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 12 — GESTION ADMINISTRATIVE

#	Contrôle	Réf.	Niveau	Statut
12.1.1	Accès portail admin M365 restreint aux admins	CIS 4.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.2	Consentement des utilisateurs aux applications tierces désactivé	CIS 4.1	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.3	Création de tenants par les utilisateurs désactivée	CIS 4.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.4	Enregistrement d’appareils restreint aux admins	CIS 1.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.5	Domaines personnalisés correctement configurés et vérifiés	CIS 2.1	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.6	Accès Office Store restreint aux administrateurs	CIS 1.3.4	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.7	Protection phishing interne Microsoft Forms activée	CIS 1.3.5	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.8	Customer Lockbox activé (E5)	CIS 1.3.6	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.9	Stockages tiers restreints dans M365 Web (L2)	CIS 1.3.7	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.10	Partage externe Sway désactivé	CIS 1.3.8	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
12.1.11	Microsoft Bookings restreint ou désactivé (L2)	CIS 1.3.9	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 13 — RÉPONSE AUX INCIDENTS

#	Contrôle	Réf.	Niveau	Statut
13.1.1	Plan de réponse aux incidents M365 documenté et testé	CIS 17.4	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
13.1.2	Audit Premium activé pour utilisateurs critiques (E5)	CIS 8.5	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
13.1.3	Playbooks IR BEC et ransomware M365 documentés et testés	NIST 800-61r2	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
13.1.4	Sauvegarde M365 dédiée activée et testée (natif ou tiers)	Best Practice	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 14 — MICROSOFT COPILOT FOR M365

#	Contrôle	Réf.	Niveau	Statut
14.1.1	Audit d’oversharing réalisé avant déploiement Copilot (DSPM for AI)	Purview DSPM	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.2	Politiques DLP spécifiques à Copilot configurées	Purview DLP	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.3	Journalisation des interactions Copilot activée (Audit Premium)	MS.AAD	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.4	Plugins et extensions Copilot tiers contrôlés et approuvés	App Governance	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.5	Étiquettes de sensibilité héritées dans les contenus générés par Copilot	Purview Labels	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.6	Licences Copilot gouvernées via groupe d’approbation	CIS 5.1.x	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.7	Protection contre les injections de prompt Copilot (Communication Compliance)	OWASP LLM01	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
14.1.8	Comptes zombies avec licences M365 actives détectés et nettoyés	CIS 5.1.x	🟡	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 15 — CHEMINS D’ESCALADE ET PRIVILEGE ESCALATION

#	Contrôle	Réf.	Niveau	Statut
15.1.1	Chemins d’escalade vers Global Administrator (Attack Path) audités	MSEM Attack Path	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
15.1.2	Scénarios de contournement des politiques CA (CA Policy Bypass) détectés	MT.1036 + CA-BYPASS-001	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
15.1.3	Scénarios d’abus de relations cross-tenant (Cross-Tenant Trust Abuse) audités	XTAP-ABUSE-001	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 16 — DÉTECTION DES MENACES IDENTITÉ

#	Contrôle	Réf.	Niveau	Statut
16.1.1	Alertes Defender for Identity mappées MITRE ATT&CK activées et configurées	MS.DEFENDER + Defender for Identity	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
16.1.2	Use Cases Microsoft Sentinel pour BEC, Token Theft et Consent Grant activés	Sentinel — MS.AAD	🔴	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
16.1.3	UEBA (User and Entity Behavior Analytics) activé dans Microsoft Sentinel	Sentinel UEBA	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 17 — PROCESSUS ET RUNBOOKS SOC

#	Contrôle	Réf.	Niveau	Statut
17.1.1	Runbooks SOC pour incidents M365 documentés et testés	NIST SP 800-61	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
17.1.2	Rotation automatisée des secrets App Registration (< 90 jours)	CIS 5.1.x + ENTRA-SECRET-001	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
17.1.3	Exercice Purple Team annuel sur le tenant M365 réalisé	MITRE ATT&CK Purple	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

SECTION 18 — SENSIBILISATION ET SIMULATION

#	Contrôle	Réf.	Niveau	Statut
18.1.1	Simulations de phishing régulières déployées avec métriques de taux de clic	CIS Control 14 — Attack Simulator	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
18.1.2	Insider Risk Management (Microsoft Purview) activé et configuré	Purview IRM — CIS 3.3	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A
18.1.3	Shadow IT surveillé via Microsoft Defender for Cloud Apps (MCAS)	MCAS — CIS 8.11	🟠	☐ ✅ ☐ ❌ ☐ ⚠️ ☐ N/A

RÉSUMÉ EXÉCUTIF DE L’AUDIT — v2

Version : ANC M365 Security Checklist v4.6 — Mars 2026 Contrôles : 280 contrôles uniques | Sources intégrées : CIS M365 v6.0.1 · CISA SCuBA v1.7 · ScubaGear v1.7.1 · M365-Assess v0.9.8 · Maester v2.0 · 365Inspect · M365SAT · ANSSI · RGPD/NIS2 · Microsoft Security Compliance Toolkit v2512 Niveaux de criticité : 🔴 Critique (~53) · 🟠 Élevé (~125) · 🟡 Moyen (~60) · 🟢 Faible (3)

Score Global de Conformité

Indicateur	Valeur
Score brut	___ / 280
Pourcentage de conformité	___%
Score pondéré	___ / 100
Contrôles CRITIQUE non conformes	___ / ~60
Contrôles ÉLEVÉ non conformes	___ / ~135
Contrôles MOYEN non conformes	___ / ~65

Calcul du score pondéré /100

Catégorie	Poids	Nb contrôles	Max pts
🔴 Critique	× 3	~60	~180
🟠 Élevé	× 2	~135	~270
🟡 Moyen	× 1	~65	~65
🟢 Faible	× 0.5	3	1.5
TOTAL normalisé	—	280	→ /100

Score pondéré = (Σ points conformes × poids) / total pondéré × 100

Niveau de Maturité Sécurité

Score %	Niveau	Description
< 30%	🔴 Initial	Contrôles fondamentaux absents — risque critique immédiat
30–49%	🟠 En développement	Bases posées mais lacunes majeures
50–69%	🟡 Défini	Posture acceptable — améliorations prioritaires identifiées
70–84%	🟢 Géré	Bonne maturité — optimisations ciblées requises
≥ 85%	✅ Optimisé	Posture excellente — surveillance continue et amélioration continue

Niveau actuel de l’organisation : ____% → __________________

TOP 3 RISQUES CRITIQUES IDENTIFIÉS

À compléter après l’audit — indiquer les 3 non-conformités à impact le plus élevé

#	Risque	Impact	Contrôle	Remédiation estimée
1		🔴 Critique
2		🔴 Critique
3		🟠 Élevé

Tableau de Couverture par Section

Catégorie	Total	Conformes ✅	Non Conformes ❌	Partiels ⚠️	N/A
1. Identités et Accès (MFA, CA, PIM, App Sec, CAE, XTAP)	~82
2. Defender for Office 365	9
3. Exchange Online	34
4. Microsoft Teams	18
5. SharePoint / OneDrive	18
6. Protection Information (Purview)	6
7. Sécurité Appareils (Intune + MDE)	14
8. Secure Score & Monitoring	10
9. Power Platform	8
10. Microsoft Fabric / Power BI	13
11. M365 Apps — Sécurité Office	14
12. Gestion Administrative	11
13. Réponse aux Incidents	4
14. Microsoft Copilot for M365	6
TOTAL	🏆 280

Répartition par Niveau de Risque

Niveau	Nb non-conformités	Délai remédiation	Responsable	Date cible
🔴 Critique		Immédiat (< 15 jours)
🟠 Élevé		Court terme (< 30 jours)
🟡 Moyen		Moyen terme (< 90 jours)
🟢 Faible		Long terme (< 180 jours)

Roadmap de Maturité — 3 Horizons

Horizon	Délai	Objectif	Contrôles prioritaires
H1 — Fondations	0–30 jours	Éliminer les risques CRITIQUES	1.1.1, 1.8.1, 1.8.2, 2.3.1/2, 3.2.11, 5.1.1, 6.1.1
H2 — Consolidation	30–90 jours	Traiter les risques ÉLEVÉS prioritaires	1.3.x CA, 1.5c.6, 2.2.1-5, 4.2.7, 6.1.3/6, 8.1.1-3
H3 — Optimisation	90–180 jours	Niveau Géré/Optimisé	Scoring pondéré ≥ 70%, MITRE mapping, Insider Risk, Copilot Gov

Frameworks de Conformité Couverts

Framework	Couverture estimée	Notes
CIS M365 Foundations v6.0.1	~95%	Base principale de la checklist
CISA SCuBA v1.7 (ScubaGear)	~98%	99/101 contrôles couverts
ANSSI Recommandations M365	~80%	Sections 1, 3, 5, 6 principalement
RGPD / NIS2	~75%	Articles 32/33/34 RGPD + Annexe I NIS2
NIST 800-53 Rev5	~70%	Mapping partiel (AC, AU, IA, SI, SC familles)
ISO 27001:2022	~65%	Contrôles A.5, A.8, A.9, A.12 principalement

TABLEAU DE VÉRIFICATION — COUVERTURE DES 5 OUTILS OPEN-SOURCE

Vérification de l’intégration des contrôles issus de ScubaGear v1.7.1, M365-Assess v0.9.8, Maester v2.0, 365Inspect, et M365SAT dans la présente checklist.

ScubaGear v1.7.1 (CISA) — 101 contrôles / 7 services

Service	Total	Couverture	%	Notes
MS.AAD	30	30	100%	Tous couverts (Sections 1.1–1.11)
MS.EXO	34	34	100%	Sections 3.1–3.2 + 2.2 (DMARC/SPF)
MS.DEFENDER	19	19	100%	Section 2 + 3.1.13 (alertes)
MS.SHAREPOINT	8	8	100%	Section 5.1 complète
MS.TEAMS	20	19	95%	Sections 4.1–4.2 + 4.2.7 Recording (ajout v4.6)
MS.POWERPLATFORM	9	9	100%	Section 9.1 complète
MS.POWERBI	8	8	100%	Section 10.1 complète (ajout v4.2)
TOTAL	101	100	~99%	Couverture quasi-complète

M365-Assess v0.9.8 — Contrôles clés intégrés

Module M365-Assess	Contrôle checklist	Section
CA-DEVICECODE-001	Device Code Flow bloqué	1.3.6
CA-EXCLUSION-001	Admins non exclus CA critiques	1.8.13
CA-PHISHRES-001	Auth phish-resistant admins	1.3.8
ENTRA-STALEADMIN-001	Admins inactifs >90j	1.8.12
ENTRA-SYNCADMIN-001	AD sync accounts in cloud roles	1.8.14
ENTRA-ENTAPP-003	Permissions Midnight Blizzard	1.5c.1
ENTRA-ENTAPP-008/009	Managed Identities Graph dangerous	1.5c.4
INTUNE-MAA-001	Multi-Admin Approval Intune	7.1.7
INTUNE-WIPEAUDIT-001	Audit wipe appareils	7.1.9
SPO-SHARING-008	Partage externe groupe sécurité	5.1.13
SPO-SCRIPT-001/002	Custom scripts bloqués	5.1.17
TEAMS-REPORTING-001	Signalement sécurité Teams	4.2.6
TEAMS-CLIENT-002	Email into channel bloqué	4.1.4
Stryker Incident Readiness	Admins inactifs + credentials	1.8.12, 8.1.9
ENTRA-DORMANTSP-001	Service Principals inactifs > 90j	1.5c.6
EXO-INBOXRULE-001	Règles inbox malveillantes (BEC)	3.2.11

Maester v2.0 — Contrôles MT, ORCA, EIDSCA, XSPM intégrés

Catégorie	IDs clés	Couverture
MT (Built-in)	MT.1009/1010/1026/1027/1036/1050/1051/1052/1053/1060/1063/1080/1096/1105/1106-1110	✅ 19/19 intégrés
ORCA (EXO/Defender)	ORCA.241 (First Contact), ORCA.243 (ARC), ORCA.226 (Safe Links clickthrough)	✅ Principaux intégrés
EIDSCA	EIDSCA.PR03 (banned pwd), EIDSCA.PR05/PR06 (lockout)	✅ 3 prioritaires intégrés
XSPM	MT.1080 (credentials exposés endpoints)	✅ Section 8.1.9
CIS	Via contrôles CIS v6.0.1 natifs	✅ Entièrement couvert
CISA	Via MS.AAD/EXO/DEFENDER natifs	✅ Entièrement couvert

365Inspect (Soteria) — 108 modules — Intégrations clés

Module 365Inspect	Contrôle checklist	Section
Inspect-DangerousAppPermissions	Permissions Midnight Blizzard	1.5c.1
Inspect-PartnerSupport	Rôles Partner Tier1/Tier2	1.5c.2
Inspect-AppKeyCredentials	Apps avec certificat creds	1.5c.3
Inspect-DirSyncAdmins	Comptes synchro dans rôles cloud	1.8.14
Inspect-DMARCPolicyAction	DMARC p=reject vs p=none	3.1.11
Inspect-SPFSoftFail	SPF -all vs ~all	3.1.12
Inspect-SimPhish	Règles bypass PhishSim	3.1.15
Inspect-EXOSendAsPermissions	Délégations Send As/Full Access	3.1.17

M365SAT — Contrôles publics intégrés

Référence M365SAT	Contrôle	Section
CISAz65	SSPR exige 2 méthodes	1.2b.5
CISAz66/67	Smart Lockout seuil/durée	1.2b.3
CISAz68	Custom banned password list	1.2b.4
CISMTm811	5 fournisseurs cloud tiers Teams	4.1.9

TABLEAU DE MAPPING MULTI-FRAMEWORKS

Correspondance entre les contrôles ANC M365 v4.6 et les principaux référentiels : NIST SP 800-53 Rev5, ISO 27001:2022, MITRE ATT&CK Enterprise, RGPD et NIS2.

Mapping NIST SP 800-53 Rev5 ↔ Contrôles ANC

Famille NIST	Contrôle NIST	Description	Contrôle(s) ANC
AC	AC-2	Account Management	1.8.2, 1.8.3, 1.8.12, 14.1.8
AC	AC-2(1)	Automated System Account Management	1.8.11, 1.8.12
AC	AC-3	Access Enforcement	1.8.1, 2.1.1, 5.1.1
AC	AC-6	Least Privilege	1.8.3, 1.8.4, 1.5.2
AC	AC-7	Unsuccessful Logon Attempts	1.2b.3
AC	AC-17	Remote Access	1.3.1, 1.3.2
AC	AC-20	Use of External Information Systems	1.7.1, 1.10.1
IA	IA-2	Identification and Authentication	1.1.1, 1.1.2, 1.8.15
IA	IA-2(1)	Multi-Factor Authentication (Privileged)	1.1.1, 1.1.3, 1.8.15
IA	IA-2(2)	Multi-Factor Authentication (Non-Privileged)	1.1.2
IA	IA-5	Authenticator Management	1.2b.1, 1.2b.2, 1.2b.4
IA	IA-5(1)	Password-Based Authentication	1.2b.3, 1.2b.5
IA	IA-12	Identity Proofing	1.7.1, 1.7.2
AU	AU-2	Event Logging	6.1.1, 3.1.2, 8.1.1
AU	AU-3	Content of Audit Records	6.1.1, 8.1.3
AU	AU-6	Audit Record Review, Analysis, Reporting	8.1.2, 8.1.3
AU	AU-9	Protection of Audit Information	3.2.7
AU	AU-11	Audit Record Retention	3.2.4, 6.1.2
AU	AU-12	Audit Record Generation	6.1.1, 3.1.13
CM	CM-6	Configuration Settings	1.2.x, 12.1.x
CM	CM-7	Least Functionality	3.1.5, 4.1.5, 11.1.7
SC	SC-5	Denial of Service Protection	2.4.1, 3.2.8
SC	SC-8	Transmission Confidentiality and Integrity	3.1.4, 11.2.1
SC	SC-28	Protection of Information at Rest	6.1.4, 7.1.1
SI	SI-3	Malicious Code Protection	2.3.1, 2.3.2, 11.1.1, 11.1.2
SI	SI-4	System Monitoring	8.1.2, 8.1.3, 6.1.6
SI	SI-10	Information Input Validation	14.1.7
PM	PM-14	Testing, Training, and Monitoring	13.1.1, 13.1.3

Mapping ISO 27001:2022 ↔ Contrôles ANC

Contrôle ISO 27001:2022	Titre	Contrôle(s) ANC
A.5.2	Information security roles and responsibilities	12.1.1, 1.8.x
A.5.15	Access control	1.3.1, 1.8.1, 5.1.1
A.5.16	Identity management	1.1.x, 1.8.2, 1.8.4
A.5.17	Authentication information	1.2b.x, 1.8.15
A.5.18	Access rights	1.5.x, 1.8.3, 1.8.11
A.5.23	Information security for use of cloud services	1.10.1, 9.1.1, 14.1.1
A.5.26	Response to information security incidents	13.1.1, 13.1.3
A.5.28	Collection of evidence	6.1.1, 3.1.2
A.5.36	Compliance with policies	6.1.3, 8.1.1
A.6.8	Information security event reporting	4.2.6, 8.1.2
A.8.2	Privileged access rights	1.8.1, 1.8.2, 1.8.5
A.8.3	Information access restriction	1.3.1, 1.3.2, 5.1.4
A.8.5	Secure authentication	1.1.1, 1.1.3, 1.8.15
A.8.7	Protection against malware	2.3.1, 2.3.2, 11.1.1, 11.1.2
A.8.8	Management of technical vulnerabilities	8.1.1, 8.1.10
A.8.11	Data masking	6.1.3, 6.1.4
A.8.12	Data leakage prevention	6.1.3, 5.1.x, 14.1.2
A.8.15	Logging	6.1.1, 3.2.7, 8.1.1
A.8.16	Monitoring activities	8.1.2, 8.1.3, 6.1.6
A.8.17	Clock synchronization	6.1.1
A.8.23	Web filtering	2.3.2
A.8.24	Use of cryptography	7.1.1, 3.1.10

Mapping MITRE ATT&CK Enterprise ↔ Contrôles ANC (vue globale)

MITRE Tactic	Technique	Titre	Contrôle(s) ANC
Initial Access	T1566.001	Spearphishing Attachment	2.3.1, 11.1.2
Initial Access	T1566.002	Spearphishing Link	2.3.2
Initial Access	T1078.004	Valid Accounts: Cloud	1.1.1, 1.3.1, 1.8.1, 1.8.2
Initial Access	T1528	Steal Application Access Token	1.5.2, 1.3.6, 1.5c.1
Credential Access	T1110	Brute Force	1.2b.3, 1.2b.2
Credential Access	T1111	MFA Interception	1.1.3, 1.8.15
Credential Access	T1552	Unsecured Credentials	8.1.9
Credential Access	T1555	Credentials from Password Stores	8.1.9
Credential Access	T1621	MFA Request Generation	1.1.1, 1.1.3
Persistence	T1098	Account Manipulation	1.8.1, 1.8.6
Persistence	T1098.003	Add Cloud Credentials	1.5c.1, 1.5c.3
Persistence	T1137	Office Application Startup	11.1.1
Persistence	T1114.003	Email Forwarding Rule	3.1.1, 3.2.11
Defense Evasion	T1562.008	Disable Cloud Logs	6.1.1, 3.2.7
Defense Evasion	T1564.008	Email Hiding Rules	3.2.11
Defense Evasion	T1550.001	Application Access Token	1.5.2, 1.5c.1
Collection	T1114	Email Collection	3.1.1, 3.2.11
Collection	T1213.002	Data from SharePoint	5.1.1, 5.1.4, 14.1.1
Collection	T1530	Data from Cloud Storage	5.1.1, 10.1.4, 10.1.13
Exfiltration	T1048	Exfiltration Over Alt Protocol	3.1.1, 5.1.1
Execution	T1059.005	Visual Basic	11.1.1, 11.1.2
Execution	T1204.002	Malicious File	2.3.1, 11.1.1, 11.1.2
Privilege Escalation	T1548	Abuse Elevation	1.8.1

Mapping RGPD / NIS2 ↔ Contrôles ANC

Référence	Article/Annexe	Obligation	Contrôle(s) ANC
RGPD	Art. 5	Principes de traitement (intégrité, confidentialité)	6.1.3, 6.1.4, 7.1.1
RGPD	Art. 25	Privacy by Design / by Default	5.1.1, 5.1.4, 14.1.1
RGPD	Art. 32	Sécurité du traitement	1.1.x, 1.3.1, 6.1.3, 7.1.1
RGPD	Art. 33	Notification de violation dans les 72h	6.1.1, 8.1.2, 13.1.1
RGPD	Art. 34	Communication aux personnes concernées	13.1.1, 13.1.3
NIS2	Annexe I	Mesures de gestion des cyber-risques	1.1.1, 1.8.1, 2.1.1, 6.1.1
NIS2	Art. 21(2)(a)	Politiques de sécurité SI	8.1.1, 12.1.x
NIS2	Art. 21(2)(b)	Gestion des incidents	13.1.1, 13.1.3, 8.1.2
NIS2	Art. 21(2)(e)	Sécurité chaîne d’approvisionnement	1.5.x, 9.1.3, 10.1.x
NIS2	Art. 21(2)(h)	Hygiène informatique de base + MFA	1.1.x, 1.2b.x, 7.1.1
NIS2	Art. 21(2)(i)	Politiques de cryptographie	3.1.4, 7.1.1, 3.1.10
NIS2	Art. 23	Signalement d’incidents	6.1.1, 13.1.1
NIS2	Art. 32	Contrôle de supervision (entités essentielles)	8.1.1, 8.1.10

PLAN DE REMÉDIATION

#	Contrôle non conforme	Niveau	Action corrective	Responsable	Date cible	Statut

Document produit par AYI NEDJIMI CONSULTANTS (ANC) Confidentiel — Usage exclusif du client Version 4.5 — Mars 2026

📋 Autres checklists

Toutes nos checklists sécurité

Retrouvez l'ensemble de nos 11 checklists d'audit et de durcissement professionnelles.

Voir toutes les checklists