Notification des cybermenaces : quand et comment alerter les destinataires du service

Qui devrait lire ceci : équipes de communication, juristes, responsables de la gestion d’incidents, responsables du service client, équipes de conformité, entités régulées.

Le devoir d’alerte est un principe fondamental de la cybersécurité moderne. Lorsqu’une organisation détecte une cybermenace importante visant ses clients ou utilisateurs, elle a l’obligation morale, et de plus en plus juridique, de communiquer la menace ainsi que les mesures de protection. La directive NIS2 codifie ce principe à l’article 23, paragraphe 2, qui exige que « les entités essentielles et importantes communiquent, sans retard injustifié, aux destinataires de leurs services qui sont potentiellement affectés par une cybermenace importante, toute mesure ou solution que ces destinataires sont en mesure de prendre en réponse à cette menace. Lorsque cela est approprié, les entités informent également ces destinataires de la cybermenace importante elle-même. »

Cette obligation est simple en principe mais complexe en pratique. Quand exactement une entité doit-elle notifier ? Qu’est-ce qui constitue une menace « importante » ? Quel niveau de détail l’alerte doit-elle contenir ? Qui doit l’envoyer : l’équipe conformité, l’équipe communication ou l’équipe technique ? Comment l’organisation doit-elle concilier transparence et prévention de la panique ou de la désinformation ? Cet article décortique l’article 23, paragraphe 2, et explique comment les entités essentielles et importantes doivent aborder la notification des cybermenaces.

L’approche de la directive en matière de notification des menaces diffère de celle des incidents. Un incident est un événement de sécurité qui s’est déjà produit et a causé, ou pourrait causer, un préjudice. Une menace est une attaque potentielle ou une activité adverse qui ne s’est pas encore matérialisée en incident, ou qui s’est matérialisée pour une entité mais crée un risque pour d’autres. Par exemple, si un fournisseur de télécommunications découvre qu’un adversaire scanne le réseau à la recherche de vulnérabilités, c’est une menace, pas encore un incident. Si le scan mène à une brèche, il devient un incident. Le fournisseur doit alerter les destinataires du service à la fois de la menace et de l’incident, mais le calendrier, le contenu et le mode de communication diffèrent.

Les cybermenaces importantes au sens de l’article 23, paragraphe 2

La directive ne définit pas « cybermenace importante » avec une précision mathématique. Elle établit plutôt des principes. Une menace est importante si elle est « susceptible d’affecter négativement la fourniture desdits services » ou si elle crée un risque pour les destinataires du service. Cette formulation est volontairement flexible car les menaces varient énormément selon le secteur, la vulnérabilité exploitée et les capacités de l’adversaire.

Certaines menaces sont évidentes. Si un fournisseur de services cloud détecte une variante de rançongiciel connue qui scanne activement des serveurs non corrigés dans son environnement, et si ces serveurs pourraient contenir des données clients, il s’agit clairement d’une menace importante. Le fournisseur doit alerter ses clients immédiatement. D’autres menaces sont plus ambiguës. Si le fournisseur détecte un scan automatisé correspondant au schéma d’un ver qui se propage sans distinction, mais que ses contrôles de sécurité empêchent l’exploitation, cette menace est-elle encore importante ? La directive répondrait : évaluez la probabilité et l’impact potentiel. Si le schéma de scan suggère que le ver évolue pour contourner ces contrôles, la menace est importante. Si le scan n’a rien de nouveau et que vos contrôles ont fait leurs preuves, elle ne l’est peut-être pas.

En pratique, les cybermenaces importantes se rangent en catégories :

• Vulnérabilités zero-day : une vulnérabilité logicielle inconnue du fournisseur et pour laquelle aucun correctif n’existe. Si une entité découvre qu’un adversaire exploite un zero-day dans un logiciel largement utilisé par ses clients, les destinataires du service doivent le savoir pour appliquer des contournements.
• Campagnes de rançongiciel : des indices qu’une variante spécifique de rançongiciel cible le secteur ou la clientèle de l’entité. C’est important car un rançongiciel peut causer une perturbation opérationnelle sévère et des pertes financières.
• Infections par botnet : la détection que des dispositifs ou systèmes clients sont compromis et participent à des botnets ou à d’autres activités malveillantes. C’est important car cela peut mener à une compromission plus poussée ou à une responsabilité juridique pour le client.
• Compromission d’identifiants : des indices que des noms d’utilisateur et mots de passe pour les services de l’entité ont été volés ou circulent sur des marchés du dark web. Les destinataires doivent changer leurs mots de passe et surveiller les usages abusifs de leur compte.
• Attaques sur la chaîne d’approvisionnement : des indices qu’un fournisseur utilisé par l’entité ou ses clients a été compromis et distribue des mises à jour ou produits malveillants. Les destinataires du service doivent savoir quels produits ou versions sont affectés et comment se protéger.
• Menaces de déni de service distribué : un renseignement selon lequel un client ou un secteur spécifique est ciblé par des attaquants préparant une campagne DDoS majeure. Les destinataires peuvent se préparer en activant une protection DDoS, en ajustant les filtres d’entrée ou en alertant leurs propres clients.

Calendrier : « sans retard injustifié »

La directive exige la notification « sans retard injustifié ». C’est un standard juridique qui signifie « dès que possible ». Ce n’est pas identique à « immédiatement », car une entité ne peut pas notifier avant d’avoir évalué qu’une menace est réelle et importante. Mais une fois cette évaluation faite, le retard n’est pas acceptable.

En pratique, cela signifie :

Une fois qu’une menace crédible est identifiée et évaluée, le processus de communication doit démarrer en quelques heures, non en jours. Un courriel interne de l’équipe sécurité à l’équipe communication à 10 heures doit se traduire par une notification client en fin d’après-midi, sauf complications imprévues.

Si l’entité doit notifier des centaines de milliers de clients, elle a besoin d’un système efficace : courriel, SMS, notifications in-app ou alertes de portail. Appeler manuellement chaque client n’est pas faisable. L’entité doit disposer de canaux et de modèles de notification préétablis afin que la mécanique de la notification ne retarde pas le message.

Si l’entité est encore en train d’évaluer si une menace est vraiment importante, elle doit le dire explicitement aux clients : « Nous avons identifié une menace potentielle et enquêtons. Nous vous informerons dans X heures. » Cela maintient la transparence tout en évitant les fausses alertes.

Le standard « sans retard injustifié » reconnaît qu’une information parfaite est impossible. Les entités ne sont pas tenues d’attendre une enquête complète avant de notifier. Une alerte préliminaire vaut mieux qu’une alerte complète tardive si la menace exige une action immédiate des destinataires du service.

Contenu : que dire aux destinataires du service

La directive prévoit que les entités communiquent « toute mesure ou solution que ces destinataires sont en mesure de prendre en réponse à cette menace » et que « lorsque cela est approprié, les entités informent également ces destinataires de la cybermenace importante elle-même ».

Cela crée deux niveaux d’information :

• Niveau 1 (toujours) : les mesures de protection que les destinataires du service peuvent prendre. Ce sont les étapes pratiques qui réduisent le risque. Exemples : changez votre mot de passe, mettez à jour votre logiciel, activez l’authentification à deux facteurs, déconnectez le dispositif affecté du réseau, surveillez votre compte pour tout accès non autorisé, contactez notre équipe support en cas d’activité suspecte.
• Niveau 2 (lorsque cela est approprié) : l’information sur la menace elle-même. Cela peut inclure le nom du logiciel malveillant, le type de vulnérabilité exploitée, le secteur ciblé, le nombre estimé de clients affectés ou l’acteur de menace présumé responsable.

Cette distinction reflète le fait que la directive reconnaît que les destinataires du service n’ont pas toujours besoin d’un renseignement de menace détaillé pour se protéger. Ils ont souvent besoin de conseils exploitables. Un client qui ne comprend pas les détails techniques d’une vulnérabilité zero-day bénéficie tout de même de l’instruction « mettez à jour votre logiciel immédiatement ». À l’inverse, certains destinataires du service, en particulier les organisations disposant de leurs propres équipes de sécurité, veulent un renseignement de menace pour évaluer le risque et prendre des mesures défensives.

Une entité doit fournir les deux niveaux lorsque c’est faisable, mais prioriser le Niveau 1. Un client qui ne reçoit que les mesures de protection est mieux servi que celui qui reçoit une analyse détaillée de la menace sans indication claire sur ce qu’il doit faire. L’expression « lorsque cela est approprié » de la directive donne aux entités la flexibilité d’évaluer leur audience et d’adapter le message.

Concilier transparence et responsabilité

Les notifications de cybermenaces marchent sur un fil entre transparence et responsabilité. En dire trop, et les clients paniquent, quittent le service ou entreprennent des actions inappropriées. En dire trop peu, et les clients ne comprennent pas la gravité et ne prennent pas de précautions. Dire la mauvaise chose, et la désinformation se répand.

Plusieurs pratiques aident à trouver cet équilibre :

• Utilisez un langage clair. Évitez le jargon. Si vous devez utiliser des termes techniques, expliquez-les. De nombreux destinataires du service n’ont pas d’expertise en sécurité. Une notification disant « une compromission d’identifiants a exposé votre nom d’utilisateur et le hachage de votre mot de passe » devrait plutôt dire « vos identifiants de connexion ont pu être volés. Changez votre mot de passe immédiatement. »
• Quantifiez quand vous le pouvez. « Une vulnérabilité affectant certains clients » est vague et effrayant. « Une vulnérabilité affectant 0,5 % des clients en France » est concret et aide les destinataires à évaluer s’ils sont probablement affectés.
• Distinguez « confirmé » et « suspecté ». Si vous avez confirmé que le compte d’un client a été compromis, dites-le. Si vous soupçonnez qu’un client peut être affecté sur la base des cibles de l’acteur de menace, dites « peut être ». La précision du langage bâtit la confiance.
• Évitez de blâmer les clients (même s’ils ont commis des erreurs). Une notification disant « les clients qui n’ont pas activé l’authentification à deux facteurs sont à risque » sonne accusatrice. Préférez : « Nous recommandons fortement d’activer l’authentification à deux facteurs. Voici comment. »
• Fournissez du support. Après avoir notifié les clients d’une menace, mettez à disposition des ressources de support. Cela peut inclure une hotline temporaire, une FAQ sur votre site web ou des tickets de support dédiés aux clients qui pensent être affectés.
• Testez votre notification à l’avance. Réalisez un exercice où vous rédigez une notification de menace et la partagez avec un petit groupe, y compris des personnes non techniques, pour vérifier qu’elle est claire, exploitable et appropriée.

Canaux et accessibilité

La directive ne prescrit pas le canal de communication, mais elle exige implicitement que les destinataires du service reçoivent effectivement la notification. Cela signifie :

• Utilisez plusieurs canaux. Tous les clients ne consultent pas régulièrement leur courriel. Certains préfèrent le SMS, d’autres utilisent des notifications in-app, d’autres consultent leur portail de compte. Utilisez plusieurs canaux pour maximiser la portée.
• Assurez l’accessibilité. Si vous notifiez par écrit, envisagez de fournir l’information en plusieurs langues si votre service est international, ou dans des formats accessibles aux personnes handicapées (grand texte, compatible lecteur d’écran, etc.).
• Ne dissimulez pas en petits caractères. Une notification de menace noyée dans une mise à jour des conditions d’utilisation ne sera pas efficace. Elle doit être bien visible et facile à trouver.
• Documentez la notification. Enregistrez qui a été notifié, quand, par quel canal et ce qui a été dit. C’est utile si les autorités compétentes vous demandent plus tard si vous avez respecté vos obligations.

Quand la notification n’est pas appropriée

La directive comporte une appréciation : les entités doivent informer les destinataires de la menace « lorsque cela est approprié ». Cela permet de tenir compte des situations où la notification elle-même crée un risque plus grand. Par exemple :

Si la notification alertait un attaquant sur le fait que vous avez détecté sa présence, lui permettant d’effacer ses traces ou de faire monter l’attaque avant que vous puissiez répondre, il peut être approprié de différer la notification jusqu’à ce que vous ayez contenu la menace.

Si la menace vise un petit nombre de cibles de grande valeur (par exemple, des dirigeants visés par du spear-phishing), une notification large à tous les clients peut être inappropriée ; il faut alors notifier uniquement ceux qui sont à risque.

Si la menace a déjà été exploitée et que des clients ont déjà subi un préjudice, la notification doit le reconnaître et fournir des conseils de récupération, sans créer d’alarme supplémentaire.

Dans tous les cas, la présomption par défaut doit être la notification. Ces exceptions sont étroites. Si vous n’êtes pas sûr que la notification soit appropriée, notifiez.

Points clés à retenir

• L’article 23, paragraphe 2, de NIS2 impose aux entités essentielles et importantes de notifier aux destinataires du service les cybermenaces importantes susceptibles d’affecter négativement la fourniture du service.
• Une menace importante est celle qui est susceptible de nuire aux destinataires du service, de porter préjudice à l’entité ou de permettre l’exploitation de vulnérabilités. Les menaces incluent les vulnérabilités zero-day, les campagnes de rançongiciel, les infections par botnet, la compromission d’identifiants, les attaques sur la chaîne d’approvisionnement et les campagnes DDoS.
• La notification doit intervenir « sans retard injustifié », c’est-à-dire dès qu’une entité évalue qu’une menace est réelle et importante, généralement dans un délai de quelques heures.
• Les entités doivent communiquer les mesures de protection que les destinataires peuvent prendre (obligatoire) et l’information sur la menace elle-même (lorsque cela est approprié).
• Les notifications doivent utiliser un langage clair, quantifier l’information quand c’est possible, distinguer les menaces confirmées et suspectées, et fournir des ressources de support.
• Plusieurs canaux de communication et formats accessibles doivent être utilisés pour garantir que les destinataires reçoivent effectivement les notifications.