Ce cas est un modèle, pas une référence
Cette page est un gabarit. Elle fixe la structure d'un cas client — contexte, incident, mesures, résultats mesurés, retour critique — et laisse en placeholders tout ce qui relève du terrain. Bi Cloud doit y substituer une mission réellement menée, avec des chiffres relevés dans le tenant et l'accord écrit du client sur ce qui est publié. Un incident de sécurité impose en plus de vérifier ce que le cabinet accepte de rendre public : la plupart préfèrent rester anonymes.
Le contexte
[À COMPLÉTER : nom du cabinet ou "un cabinet d'expertise comptable de 45 collaborateurs"] gère la comptabilité de [À COMPLÉTER : nombre de dossiers clients] dossiers clients répartis sur [À COMPLÉTER : nombre de bureaux] bureaux. Le cabinet utilise Microsoft 365 depuis [À COMPLÉTER : année de bascule], avec des licences [À COMPLÉTER : type de licence, ex. "Business Standard"] déployées sans configuration de sécurité particulière.
Comme dans beaucoup de cabinets, les collaborateurs échangent des relevés bancaires, des bulletins de paie et des mandats de prélèvement par courriel. La boîte aux lettres est donc l'endroit où se concentre la valeur — et le point que les attaquants visent en premier. Les contraintes propres au métier sont détaillées sur notre page Microsoft 365 pour les cabinets d'expertise comptable.
Le problème
[À COMPLÉTER : description factuelle de la tentative de fraude, ex. "un client a reçu un courriel demandant de modifier les coordonnées bancaires d'un virement, envoyé depuis la boîte d'un collaborateur du cabinet"].
Le scénario est classique. Un compte est compromis, en général par un formulaire d'authentification imité. L'attaquant reste discret : il crée une règle de boîte aux lettres qui déplace certains messages vers un dossier peu consulté, lit les échanges pendant [À COMPLÉTER : durée de présence de l'attaquant] et attend une conversation portant sur un paiement pour intervenir.
Ce qui manquait au cabinet :
- l'authentification multifacteur, absente sur [À COMPLÉTER : nombre de comptes sans MFA] comptes ;
- l'authentification héritée, encore autorisée, qui permet de contourner le MFA sur d'anciens protocoles ;
- aucune alerte sur la création de règles de transfert automatique ;
- aucune procédure écrite de vérification des changements de coordonnées bancaires.
Le dernier point n'est pas informatique. C'est pourtant lui qui arrête la fraude quand tout le reste a échoué.
Ce que nous avons mis en place
La première étape a été l'investigation, avant tout durcissement : analyse des journaux de connexion Entra ID et du journal d'audit unifié pour établir quels comptes avaient été touchés et depuis quand. [À COMPLÉTER : conclusion de l'investigation, ex. "un seul compte compromis, aucune exfiltration massive constatée"].
Ensuite, le durcissement, mené en [À COMPLÉTER : durée du chantier] :
- MFA imposé à tous les comptes, y compris les comptes d'administration, avec une méthode résistante au relais de code plutôt que le SMS ;
- blocage de l'authentification héritée et des protocoles POP et IMAP là où ils n'étaient plus utiles ;
- accès administrateur séparés des comptes courants, en nombre limité ;
- alertes sur la création de règles de transfert externe et sur les connexions depuis des pays hors périmètre d'activité ;
- politique anti-hameçonnage renforcée, avec marquage visible des messages externes.
Nous avons ajouté un volet non technique : une procédure de rappel téléphonique sur numéro connu pour tout changement de coordonnées bancaires, et [À COMPLÉTER : nombre de sessions] sessions de sensibilisation. Le détail de ce socle figure sur notre page sécurité Microsoft 365 et, côté messagerie, sur sécuriser ma messagerie contre le phishing.
Les résultats mesurés
À remplir avec des relevés issus du tenant, pas des estimations.
| Indicateur | Avant | Après | Source de la mesure |
|---|---|---|---|
| Comptes avec MFA actif | [À COMPLÉTER : %] | [À COMPLÉTER : %] | Rapport d'authentification Entra ID |
| Authentification héritée autorisée | [À COMPLÉTER : oui/non] | Bloquée | Journaux de connexion Entra ID |
| Comptes disposant de droits d'administration | [À COMPLÉTER : nombre] | [À COMPLÉTER : nombre] | Rôles Entra ID |
| Règles de transfert externe actives | [À COMPLÉTER : nombre] | [À COMPLÉTER : nombre] | Journal d'audit unifié |
| Délai de détection d'une connexion anormale | [À COMPLÉTER : durée] | [À COMPLÉTER : durée] | Alertes configurées |
| Score de sécurité Microsoft | [À COMPLÉTER : valeur] | [À COMPLÉTER : valeur] | Microsoft Secure Score |
| Collaborateurs formés au signalement | [À COMPLÉTER : %] | [À COMPLÉTER : %] | Feuilles d'émargement |
Une précision utile : le score de sécurité Microsoft est un indicateur de configuration, pas une preuve d'absence de risque. Il monte vite et se dégrade tout aussi vite si personne ne le surveille.
Ce que nous ferions différemment
Le durcissement a été mené sous le coup de l'urgence, donc rapidement, mais dans le mauvais ordre. Nous avons activé le MFA avant d'avoir terminé l'inventaire des applications qui se connectaient à la messagerie, ce qui a provoqué [À COMPLÉTER : incident secondaire, ex. "l'arrêt de deux automatisations de dépôt de documents pendant 48 heures"].
Nous aurions aussi dû traiter la question des dossiers partagés dans le même chantier. Après l'incident, [À COMPLÉTER : constat sur les droits d'accès, ex. "la moitié des dossiers clients étaient accessibles à l'ensemble du cabinet"]. Un compte compromis donne accès à ce que ce compte peut voir : réduire ce périmètre limite les dégâts autant que le MFA.
Enfin, un durcissement se dégrade s'il n'est pas revu. Sans revue périodique des règles, des rôles et des dérogations, l'état obtenu ne tient pas quelques mois — c'est l'objet de notre page infogérance Microsoft 365.
