Cybersécurité

C’est l’ensemble de ce qu’un tiers peut atteindre ou apprendre sans avoir aucun droit chez vous. Elle comprend plus de choses qu’on ne l’imagine : les noms de domaine et les sous-domaines actifs, les services qui répondent sur le réseau public, les interfaces d’administration accessibles depuis n’importe où, les documents laissés en accès libre, les comptes ouverts sur des services tiers avec les adresses de l’organisation, et les informations que des salariés publient sans y penser. Sa caractéristique gênante est qu’elle grandit toute seule : chaque outil ajouté, chaque prestataire, chaque projet abandonné mais toujours en ligne l’élargit sans que personne ne l’ait décidé. La tenir consiste moins à la réduire à zéro, ce qui est impossible pour une organisation qui travaille, qu’à savoir ce qu’elle contient et pourquoi chaque élément y figure encore.

Les deux gardent leur utilité, mais ils répondent à des menaces qui ne sont plus les plus fréquentes. La voie d’entrée dominante aujourd’hui n’est pas un logiciel qui force une porte, c’est un identifiant valide obtenu par hameçonnage ou récupéré dans une fuite, puis rejoué sur un service qui l’accepte. Aucun antivirus ne distingue une connexion légitime d’une connexion illégitime effectuée avec le bon mot de passe. Ce qui répond à ce scénario est ailleurs : un second facteur d’authentification, des droits limités à ce que chaque compte fait réellement, et la capacité de révoquer un accès rapidement. L’ordre utile est donc celui-là — d’abord les accès, ensuite la capacité à restaurer, et seulement après les outils de détection, qui supposent quelqu’un pour lire ce qu’ils signalent.

Des services publics recensent les fuites de données rendues publiques et permettent de vérifier si une adresse y figure. C’est un point de départ utile, avec deux limites qu’il faut connaître : ils ne voient que ce qui a été publié et signalé, et une absence de résultat ne prouve donc rien. La conséquence pratique compte davantage que le résultat lui-même : un mot de passe apparu dans une fuite doit être considéré comme connu, y compris s’il a l’air complexe, et surtout partout où il a été réutilisé. C’est la réutilisation qui transforme une fuite ancienne sur un service sans importance en accès à votre messagerie. Un gestionnaire de mots de passe, qui rend chaque mot de passe unique par service, est ce qui coupe cette chaîne.

Parce que le courrier électronique a été conçu sans vérification de l’expéditeur : n’importe quel serveur peut prétendre écrire depuis votre domaine, exactement comme on écrit ce qu’on veut au dos d’une enveloppe. Des mécanismes ont été ajoutés depuis pour publier, dans les réglages publics du domaine, quels serveurs sont autorisés à écrire en son nom, comment signer les messages, et ce qu’un destinataire doit faire d’un message qui échoue à ces contrôles. Tant que ces réglages sont absents ou laissés en observation, un message frauduleux portant votre nom arrive normalement chez vos clients. Le point important est que cette configuration se vérifie depuis l’extérieur, par n’importe qui : ce n’est pas une déclaration d’intention, c’est un état constatable.

Elle est la mesure au meilleur rapport entre effort et effet, et elle ne clôt pas le sujet. Elle rend l’hameçonnage nettement moins rentable, puisqu’un mot de passe volé ne suffit plus. Elle reste contournable dans trois cas qu’il faut connaître : un code reçu par message texte peut être intercepté ou obtenu par transfert de ligne ; un jeton de session déjà ouvert peut être volé et rejoué sans repasser par l’authentification ; et une sollicitation répétée finit parfois par être acceptée par lassitude. Les réponses existent et sont connues — préférer une application dédiée ou une clé physique au message texte, limiter la durée de vie des sessions et pouvoir les révoquer, et exiger une correspondance affichée plutôt qu’une simple validation.

Elle l’est, mais pas de la façon qu’on imagine : elle est rarement choisie, elle est rencontrée. L’essentiel des attaques courantes est automatisé et balaye sans discernement ce qui répond sur le réseau, puis exploite ce qui se laisse faire. Une petite structure est donc exposée à la même première vague qu’une grande, avec moins de moyens pour l’absorber. S’y ajoute une position particulière : une organisation modeste est souvent le chemin le plus court vers un client plus gros, par la confiance qu’on lui accorde et par les accès qu’on lui a ouverts. Le raisonnement « nous n’intéressons personne » se trompe donc de question. La bonne est : que peut-on faire de nos accès, de nos données et de notre nom une fois qu’on les détient ?

Trois réflexes valent mieux que la précipitation. Isoler avant d’effacer : couper l’accès réseau de ce qui est touché limite la propagation, alors qu’un nettoyage immédiat détruit ce qui aurait permis de comprendre l’entrée. Conserver les traces : les journaux, les messages reçus et les captures d’écran deviennent la seule matière disponible pour une plainte, une déclaration ou une réclamation, et beaucoup s’effacent d’eux-mêmes. Reprendre le contrôle des accès : changer les mots de passe depuis un appareil sain, révoquer les sessions ouvertes et les jetons applicatifs, car un mot de passe changé ne ferme pas une session déjà active. Vient ensuite la question qu’on oublie souvent dans l’urgence : qui doit être prévenu, et sous quel délai une obligation s’applique.

Elles sont la seule défense qui rende le chantage sans objet, à trois conditions dont aucune n’est automatique. Elles doivent être hors de portée du système qu’elles protègent : une sauvegarde branchée en permanence est chiffrée en même temps que le reste, ce qui est précisément ce que visent ces attaques. Elles doivent conserver plusieurs états dans le temps, car une altération passée inaperçue est recopiée dans la dernière version. Et elles doivent avoir été restaurées pour de vrai, au moins une fois, sur autre chose que le système d’origine — une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Reste une limite qu’il faut énoncer : elles rendent les données récupérables, elles n’empêchent pas leur publication si elles ont aussi été copiées.

Elle dit qu’une organisation a été capable de décrire ses procédures et de les faire vérifier à un instant donné, ce qui n’est pas rien et n’est pas non plus ce qu’on lui fait souvent dire. Une certification porte sur un périmètre déclaré, qui peut être bien plus étroit que l’activité entière ; elle atteste d’un fonctionnement documenté, pas de l’absence de défaut ; et elle vieillit entre deux contrôles. Elle se lit donc comme un indice, jamais comme une conclusion, et deux questions la rendent utile : quel périmètre exact est couvert, et à quelle date la dernière vérification a eu lieu. Ce site n’en revendique aucune, et sa page Sécurité le dit explicitement : ce qui y est décrit, ce sont les mécanismes, afin qu’on puisse les vérifier plutôt que les croire.

En demandant ce qui se constate depuis l’extérieur plutôt que ce qui se déclare. Plusieurs éléments s’observent sans accès privilégié : la configuration publique du domaine, les en-têtes renvoyés par le serveur, la présence d’une adresse de signalement, la façon dont un formulaire valide ce qu’il reçoit. D’autres se demandent et doivent obtenir une réponse précise : qui détient les accès administrateur et comment ils se révoquent, où vivent les sauvegardes et quand la dernière restauration a été faite, ce qui est journalisé et pendant combien de temps. Un dernier point mérite d’être posé avant la signature plutôt qu’après : à qui appartiennent le code, les comptes et les données créés pour le projet, et sous quelle forme ils vous sont remis si la collaboration s’arrête.