Fixer un délai de repérage pour chaque porte ouverte

La fuite la plus instructive de cet automne n’est pas une effraction. Le droit licite d’une entreprise danoise à interroger le registre national de la population a été détourné, au moyen présumé de requêtes automatisées, pendant une dizaine de jours en septembre. Un employé du registre l’a repéré le 2 octobre. Un tel accès existe pour être utilisé : impossible de simplement le verrouiller. Ce que vous pouvez décider, c’est combien de temps un usage abusif peut durer avant que quelqu’un qui le comprend s’en aperçoive.

Chaque porte qui laisse sortir des données a besoin d’un délai de repérage

Chaque canal qui laisse sortir des données a besoin d’un chiffre : combien de temps un usage abusif pourrait durer avant que quelqu’un qui comprend ce canal le sache. La plupart des organisations fixent un objectif de délai de rétablissement pour les pannes, et rien pour l’usage abusif des accès qu’elles ont accordés à dessein. Cela vaut pour les intégrations avec des partenaires, les dossiers partagés, les portails de consultation et les connecteurs d’IA.

Les dernières semaines montrent ce que coûte son absence. Au Danemark, le ministère responsable du registre CPR a indiqué le 5 octobre 2026 que des personnes non autorisées avaient eu accès aux noms, adresses et numéros CPR d’environ 8,8 millions de personnes enregistrées « en détournant l’accès licite d’une entreprise danoise à la recherche d’informations dans le système CPR » (notre traduction). Datatilsynet, l’autorité danoise de protection des données, indique que les numéros auraient été obtenus par des requêtes automatisées, et Ritzau rapporte que, selon le ministre, la sécurité entourant l’accès de cette entreprise n’était pas suffisante. Aux États-Unis, une faille dans un système de partage de fichiers du Defense Manpower Data Center a laissé des fichiers accessibles pendant environ neuf mois avant d’être découverte, et un petit nombre d’utilisateurs non autorisés y ont accédé, rapporte SecurityWeek. Chez Shinhan Bank, une personne extérieure a contourné l’authentification normale d’un service de consultation conçu pour les courtiers en prêts, et Herald Corporation rapporte que les données ont été extraites en saisissant à répétition des valeurs de requête changeantes. Aucune requête prise isolément n’avait à paraître inhabituelle ; le schéma tenait à la répétition.

Les trois enquêtes sont en cours ; il ne s’agit pas de désigner des coupables, mais de pointer une mesure qui manque à la plupart des organisations.

Votre SIEM voit les événements ; seul le responsable peut les juger

Votre SIEM est le bon endroit pour les alertes en temps réel, mais seul le responsable d’un accès peut juger si un usage d’apparence normale est légitime. Kiteworks peut envoyer son activité au SIEM que vous exploitez déjà via syslog, et c’est là que doivent se faire les alertes sur ce qui paraît hostile.

L’usage abusif d’un accès licite a toutes les apparences de l’activité ordinaire. Un partenaire qui extrait de gros volumes en fin de trimestre, c’est normal ; le même partenaire qui extrait des données en continu pendant dix jours au cours d’un mois ordinaire ne l’est peut-être pas. Le NIST Cybersecurity Framework 2.0 exige les deux volets : la surveillance de l’activité du personnel (DE.CM-03) et celle de l’activité des prestataires de services externes (DE.CM-06).

Attribuez à chaque identité à fort volume (un partenaire, un compte de service, un agent IA) un responsable métier nommément désigné, qui valide une fois par an son profil d’usage normal : volume, horaires et dossiers attendus. Faites découler les seuils du SIEM de ce profil, et transmettez chaque écart au responsable, pas seulement à la file du SOC.

Faire tourner trois horloges, pas une seule

Une seule cadence ne peut pas servir à la fois les machines et les personnes : faites-en tourner trois.

• En temps réel, pour les machines. Le SIEM alerte sur ce qui paraît hostile dans tout ce que vous journalisez.
• Chaque jour ou chaque semaine, pour une seule question. Un administrateur Kiteworks pose chaque fois à Activity Explorer la même question agrégée : qu’est-ce qui a changé par rapport à la période précédente, et quels signaux se sont déclenchés ? Les signaux sont de simples règles, pas des scores : un volume quotidien d’une catégorie supérieur à trois fois sa médiane sur la période, dix échecs ou plus pour un même compte en une heure, plus de 100 téléchargements par un même compte en une journée (seuil ajustable), et une activité en dehors des heures ouvrées que vous définissez. Comme cette question ne désigne personne, c’est elle que vous pouvez planifier à intervalle régulier, par exemple avec les tâches planifiées de Claude. Décidez d’abord trois choses : à qui appartient le compte administrateur Kiteworks utilisé pour l’exécution et qui a approuvé cet accès permanent, où arrive la réponse et qui la lit, et si votre connecteur Kiteworks est joignable depuis une exécution planifiée dans votre configuration. Testez-le avant de vous y fier.
• Chaque mois ou chaque trimestre, pour les responsables. Le responsable lit un rapport enregistré couvrant n’importe quelle période jusqu’à 12 mois, lue par fenêtres de 30 jours et comparée à la période précédente. Le rapport indique jusqu’où le journal remontait réellement. User Account Reviewer y ajoute les comptes inactifs, verrouillés et externes, et Sharing Auditor montre où le partage au niveau des dossiers ouvre l’accès au départ.

Les seuils quotidiens laissent passer, par construction, l’usage à bas bruit : un partenaire qui reste sous les 100 téléchargements par jour pendant un mois ne déclenche aucune règle quotidienne. La comparaison des périodes resserre la zone à examiner, car Activity Explorer montre l’évolution par application, par catégorie d’activité et dans la part des utilisateurs externes. Suivre la tendance d’un compte donné est une question qui vise une personne : elle relève d’une enquête ou de votre SIEM, pas du rapport de routine.

Compter les agents IA comme une population à part entière

Un agent IA doté d’un connecteur agit avec les droits d’une personne à la vitesse d’une machine : son activité mérite son propre niveau de référence. Kiteworks indique que chaque opération initiée par une IA via Kiteworks MCP est consignée dans sa piste d’audit, et Activity Explorer réserve à l’activité du client Kiteworks MCP une section propre dans chaque rapport enregistré, y compris lorsqu’elle est nulle, avec ses échecs. Il ne compte que ce client : une automatisation qui appelle Kiteworks par l’intermédiaire d’une autre application apparaît sous cette application ; sachez donc quelle intégration est laquelle. Une hausse des actions d’agent en échec mérite une question à la personne qui a approuvé le connecteur.

Le registre de revue est votre preuve

Les journaux prouvent que des événements ont eu lieu ; seul un registre de revue prouve que quelqu’un a regardé et tranché. Pour chaque cycle, conservez la date, la personne chargée de la revue, la période, jusqu’où remontait le journal et les signaux. Consignez une décision par signal : attendu, ajuster la règle du SIEM, restreindre l’accès ou ouvrir une enquête.

Observez les schémas avant les personnes. Activity Explorer part des agrégats, n’affiche jamais d’adresses IP ni de localisations, n’ouvre une vue par personne qu’avec une référence d’enquête, et demande une approbation avant qu’un rapport enregistré ne nomme qui que ce soit. Cela couvre un outil, pas votre programme : la même activité dans votre SIEM comporte des noms de comptes et des adresses IP. Avant la première exécution, convenez avec votre délégué à la protection des données (DPO) et, s’il existe, votre comité social et économique (CSE) : de la base légale et d’une AIPD pour l’ensemble de la revue, flux SIEM compris ; de l’usage des données de revue à des fins de sécurité, et jamais de gestion de la performance ; de la manière dont le personnel en est informé ; et de la durée de conservation des enregistrements qui nomment quelqu’un.

Cinq questions pour fixer votre propre délai de repérage :

1. Quels canaux peuvent faire sortir des données sensibles, et qui est responsable de chacun ?
2. Pour chaque canal, combien de temps un usage abusif pourrait-il durer avant que son responsable le sache, et est-ce acceptable ?
3. Quels canaux alimentent votre SIEM, et lesquels ne sont lus par personne ?
4. Quelle question unique chaque responsable veut-il voir traitée chaque semaine, et est-elle planifiée ?
5. Qui a validé la dernière revue, à quelle date, et avec quelle décision ?

Le premier chiffre que vous fixerez sera faux. Ne pas en avoir est pire. Si vous souhaitez déterminer avec nous le délai de repérage de vos canaux Kiteworks, écrivez à sales@kiteworks.com ou prenez contact avec nous. Inutile d’avoir configuré Claude ou MCP pour nous solliciter. Pour le volet droits d’accès de la question, voir Vérifier ce à quoi vos fournisseurs ont encore accès.