Un dimanche après-midi, notre surveillance signale qu’un collaborateur d’une société de gestion vient de télécharger une dizaine de milliers de fichiers en une heure environ, depuis un dossier lié à un fonds. Fausse alerte, au bout du compte. Une alerte classée légitime sans trace écrite ne prouve rien : aux yeux d’un contrôleur, elle n’a tout simplement pas été traitée. Ce cas, vu cette semaine chez une société de gestion que nous accompagnons, démonte une idée reçue tenace.
L’idée reçue : une alerte légitime se referme d’un clic
Le raisonnement paraît sain. Quelqu’un a regardé, le collaborateur avait une bonne raison : on clôt et l’on n’encombre pas le dossier avec un incident qui n’en était pas un. Bien des consoles y invitent, avec un bouton « faux positif » qui retire l’alerte sans demander de justification.
Pour une société de gestion, ce raccourci se paie le jour du contrôle. L’article 10 de DORA impose de détecter rapidement les activités anormales, et l’article 17 demande d’enregistrer les incidents liés aux TIC ainsi que les cybermenaces importantes (règlement (UE) 2022/2554). Une alerte légitime sort du registre des incidents. La trace de sa qualification, elle, reste la seule preuve que la détection a fonctionné et que quelqu’un a tranché.
Comment détecter un téléchargement massif sur SharePoint ?
La détection repose sur un écart à l’habitude : la surveillance compare le volume de fichiers récupérés par un compte sur une courte fenêtre à ce qu’il fait d’ordinaire. L’alerte ne dit rien de l’intention. C’est le journal d’audit de Microsoft 365 qui reconstitue ensuite le geste, action par action, avec l’adresse d’origine et l’appareil. Microsoft conserve ces événements 180 jours dans son offre d’audit standard (Microsoft Learn), ce qui laisse le temps d’enquêter sur une alerte récente mais pas de rouvrir un dossier vieux d’un an, d’où l’intérêt de verser la levée de doute au dossier le jour même plutôt que de compter sur le journal.
Ce que l’équipe a vérifié, ce dimanche-là
Le journal d’audit a parlé en premier. Le téléchargement venait du bouton « Télécharger » de SharePoint, appliqué à un dossier entier, depuis le réseau du bureau et sur un appareil géré. Aucun partage externe. Aucun lien anonyme.
Restait l’intention, que le journal ne contient pas. L’équipe a contacté l’utilisateur : il constituait des échantillons de contrôle, avait interrompu le téléchargement, n’avait conservé aucune copie et n’avait rien transmis à un tiers. Une seconde alerte née de la même opération a été rattachée à cette vérification.
Verdict : activité légitime.
Nous préférons déranger un collaborateur un dimanche plutôt que classer une alerte sur une supposition, et tous nos clients n’apprécient pas cet appel sur le moment.
Que doit contenir la levée de doute d’une alerte légitime ?
Ce qui a fait de ce dimanche une preuve tient dans ce que nous appelons la fiche des quatre lignes : d’où, avec quoi, vers où et pourquoi, remplies pour chaque alerte qualifiée avec le nom de la personne qui a vérifié et l’heure du constat.
D’où : le réseau et l’adresse d’origine, lus dans le journal d’audit. Avec quoi : l’appareil, géré ou non, et l’action précise (bouton de téléchargement, synchronisation, outil tiers). Vers où : la présence ou l’absence de partage externe, de lien anonyme ou de transfert. Pourquoi : la déclaration de l’utilisateur, recueillie, datée et rattachée à l’alerte.
Les trois premières lignes viennent des journaux. La quatrième vient d’un humain.
Pour un RCCI, cette fiche fait de l’alerte un contrôle de premier niveau contre la fuite d’information. Nous appliquons la même logique de preuve à nos SLA d’infogérance sous DORA. Et pour situer ce scénario de fuite face aux autres risques de la société, notre simulateur d’analyse de risques selon la méthode de l’ANSSI aide à le placer sur la carte.
La limite de la déclaration
Rien, dans les journaux, ne prouve que l’utilisateur n’a gardé aucune copie : une fois les fichiers sur un appareil géré, la suite relève d’autres contrôles, comme le chiffrement du poste ou le blocage des clés USB. La fiche ne certifie donc pas l’absence de fuite. Elle sépare ce qui a été vérifié de ce qui a été déclaré.
Un dirigeant objectera : « si le collaborateur ment, la fiche ne sert à rien ». Elle sert justement ce jour-là. Une déclaration datée, rattachée à une alerte précise, devient une pièce du dossier, là où un « vu, c’est bon » dans une messagerie ne laisse aucune prise.
Mercredi 6 janvier 2027
Le mercredi 6 janvier 2027, les politiques de fichiers du service de Microsoft consacré à la sécurité des applications cloud s’arrêtent, au profit de la prévention des pertes de données de Microsoft Purview (notes de version Microsoft). La détection des téléchargements massifs reste documentée par l’éditeur. Un contrôle bâti sur ces politiques doit en revanche être revu avant cette date, et cette revue mérite sa ligne au dossier.
Marin vous consacre trente minutes pour regarder comment vos alertes sont closes aujourd’hui et ce qui manque pour en faire des preuves : réserver le rendez-vous.
Marin Barjhoux, fondateur et président chez ITAIA
Sources
- EUR-Lex, Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA) : article 10 (détection des activités anormales) et article 17 (enregistrement des incidents liés aux TIC et des cybermenaces importantes).
- Microsoft Learn, Microsoft Purview auditing solutions : contenu du journal d’audit et conservation de 180 jours en audit standard.
- Microsoft Learn, notes de version du service de sécurité des applications cloud de Microsoft : fin des politiques de fichiers le 6 janvier 2027 et bascule vers Microsoft Purview.
