En bref : une bonne communication de crise après une cyberattaque est rapide, honnête et cohérente. Informez d'abord en interne, puis les personnes concernées et les partenaires, et ne dites que ce qui est établi, en le séparant clairement de ce qui est encore à l'étude. Les obligations d'information, par exemple selon l'art. 34 du RGPD, sont à coordonner avec le délégué à la protection des données et le conseil juridique ; cette page ne constitue pas un conseil juridique.
Pourquoi la communication fait partie du traitement de l'incident
Une attaque contre un serveur web est d'abord un problème technique. Très vite, elle devient aussi une question de confiance : les clients remarquent un site inaccessible, les partenaires reçoivent des e-mails suspects, les collaborateurs posent des questions. Qui se tait alors ou répond de façon contradictoire perd plus de confiance que par l'incident lui-même.
La situation actuelle autour de PHP2Shell le rend tangible. De nombreuses entreprises ont mis leurs sites hors ligne à titre préventif ou les ont mis brièvement en maintenance. Cela ne signifie pas automatiquement qu'elles ont été piratées. C'est précisément cette distinction que vous devriez pouvoir expliquer clairement et calmement vers l'extérieur.
Communication de crise après une cyberattaque : le bon ordre
Un ordre éprouvé évite que des groupes importants l'apprennent par la presse ou par des tiers :
- Cellule de crise interne : direction, technique, protection des données, le cas échéant conseil juridique et assureur. C'est ici que l'on décide de ce qui sera dit.
- Collaborateurs : courte information interne, avec la demande de transmettre les demandes au point de contact désigné et des conseils de prudence face aux e-mails suspects.
- Autorités, là où c'est nécessaire : par exemple l'autorité de protection des données selon l'art. 33 du RGPD, le BSI (office fédéral allemand de la sécurité des technologies de l'information) en cas d'obligation NIS2, la police en cas de plainte. Vous coordonnez l'ordre avec votre conseil juridique.
- Clients et partenaires concernés : directement et, si possible, avant une déclaration publique.
- Public : indication sur le site, le cas échéant communiqué de presse.
Selon l'art. 34 du RGPD, les personnes concernées doivent être informées sans retard injustifié lorsqu'une violation de données est susceptible d'engendrer un risque élevé pour elles. Les grandes lignes sont expliquées dans Obligation de notification RGPD : 72 heures.
Ce que doit contenir un message
Un bon message est bref et répond aux questions que se posent les personnes concernées. Cette structure a fait ses preuves :
| Section | Contenu |
|---|---|
| Que s'est-il passé ? | Description factuelle en termes simples, avec la période |
| Que savons-nous, que ne savons-nous pas ? | Faits établis séparés de l'enquête en cours |
| Qui est concerné ? | Groupes de personnes ou de données, dans la mesure où ils sont connus |
| Qu'avons-nous fait ? | Mesures immédiates, intervention de spécialistes et d'autorités |
| Que devriez-vous faire ? | Recommandations concrètes, par exemple changer de mot de passe, se méfier du hameçonnage |
| Comment nous joindre ? | Point de contact fixe pour les questions |
Annoncez quand vous informerez à nouveau, et tenez cet engagement. Même un « pas de nouvelles informations pour l'instant » à l'heure annoncée crée de la confiance.
Préparez des modèles pour l'information interne, le message aux clients et l'indication sur le site avant qu'un incident se produise. En situation de crise, il ne reste alors qu'à insérer les faits.
Ce qu'il vaut mieux éviter
Certaines formulations et certains comportements nuisent régulièrement :
- Fausse alerte levée trop vite : « Aucune donnée n'a été exfiltrée » n'est admissible que si c'est prouvé. Un correctif installé ne prouve pas que rien ne s'est produit auparavant.
- Minimisation : des expressions comme « petit incident technique » paraissent malhonnêtes si l'on en apprend plus ensuite.
- Accusations : désigner l'hébergeur, un prestataire ou un éditeur n'aide pas les personnes concernées et peut avoir des conséquences juridiques.
- Détails techniques utiles aux attaquants : les vulnérabilités concrètes de vos systèmes n'ont pas leur place dans des communications publiques.
- Garanties : des affirmations comme « totalement sûr » ou « impiratable » ne peuvent pas être tenues.
Site web, moteurs de recherche et vague d'hameçonnage
Après une attaque contre un site, deux phénomènes accompagnateurs s'ajoutent souvent. Premièrement, Google peut afficher un avertissement lorsque du code malveillant a été trouvé ; la manière de le faire retirer après le nettoyage figure sous Retirer l'avertissement de Google. Deuxièmement, des escrocs exploitent des incidents connus pour envoyer de faux e-mails au nom de l'entreprise concernée. Mettez activement vos clients en garde et indiquez par quelles voies vous communiquez réellement.
Si vous mettez le site hors ligne à titre préventif, une page statique simple avec une courte indication et un moyen de contact qui ne dépend pas du serveur concerné suffit.
Une fois l'incident clos, un message final à tous ceux que vous aviez informés auparavant vaut la peine : ce que l'enquête a établi, quelles mesures ont été durablement mises en œuvre et à qui l'on peut continuer de s'adresser. De nombreuses entreprises omettent cette étape parce que la pression retombe. Or c'est précisément elle qui montre que vous avez pris l'incident au sérieux. Analysez aussi en interne ce qui a bien fonctionné dans la communication et ce qui n'a pas fonctionné, et adaptez en conséquence modèles et responsabilités dans votre plan d'urgence.
Comment PHP SOS aide-t-il concrètement ?
- Nous présentons les faits techniques de façon compréhensible et séparons clairement ce qui est établi, probable et inconnu.
- Nous vérifions vos projets de messages quant à leur exactitude technique et aux détails qui pourraient aider des attaquants.
- Nous mettons à disposition à court terme une page de maintenance statique, indépendante du système concerné.
- Via la réponse à incident, nous maintenons la technique au rythme de votre communication, afin que les engagements sur l'état de l'information puissent être tenus.
Questions fréquentes
Faut-il rendre une attaque publique alors que tout n'est pas encore clair ?
Cela dépend de la situation, des obligations et des personnes concernées. Souvent, un message bref et factuel avec l'état connu vaut mieux que le silence, car sinon clients et partenaires l'apprennent par d'autres sources. Coordonnez le moment avec votre conseil juridique et l'assureur.
Que ne faut-il en aucun cas faire figurer dans un message aux clients ?
Des hypothèses présentées comme des faits, des accusations contre des tiers, des détails techniques utiles aux attaquants et des engagements que vous ne pouvez pas tenir avec certitude. Des formulations comme totalement exclu ne devraient être utilisées que si elles sont prouvées.
Qui devrait s'exprimer vers l'extérieur ?
Une personne désignée, le plus souvent issue de la direction ou de la communication d'entreprise, soutenue par la technique et le conseil juridique. Tous les autres renvoient vers ce point de contact. Les déclarations restent ainsi cohérentes.
Devons-nous mettre notre site hors ligne et l'expliquer ?
Si vous déconnectez le site du réseau à titre préventif, une courte indication aide, par exemple sur une page de maintenance statique. Elle n'a pas besoin d'être technique. Une mise hors ligne préventive ne signifie pas automatiquement qu'une attaque a réussi.