La partie un était la vente. Ceci est le parc.
La paperasse est signée, la facture tombe chaque mois, et il y a du matériel. Une partie à vous, une partie à eux, l’essentiel choisi avant que quiconque ait demandé ce que l’entreprise fait réellement entre huit et dix-huit heures. Ce qui suit est le matériel lui-même : ce qui est choisi, ce qui a été laissé allumé dedans, et qui d’autre peut atteindre les machines que vous avez payées depuis une console à laquelle vous ne vous êtes jamais connecté.
Deux des défaillances ici portent une conclusion de régulateur avec un chiffre attaché. Aucune n’est arrivée à un client — elles sont arrivées à un prestataire, et les clients étaient en aval. Chaque affirmation porte un lien.
La boîte dont on ne les dissuadera pas
Maintenant la partie gênante. Je veux la faire avec des preuves plutôt qu’avec des assertions, parce que c’est la section où les gens saisissent le mot complot — et saisir ce mot est la façon dont le sujet est abandonné sans que personne ait à le regarder.
Cisco est la recommandation par défaut dans l’essentiel de cette industrie. Alors regardez ce que le fournisseur lui-même a publié sur l’accès non documenté dans son propre matériel.
En mars 2018 ils ont publié un avis pour CVE-2018-0141 : on pouvait se connecter à Prime Collaboration Provisioning par SSH à cause d’« a hard-coded account password on the system » — un mot de passe de compte codé en dur sur le système. Huit mois plus tard, CVE-2018-15439 sur les switches Small Business, où « the affected software enables a privileged user account without notifying administrators of the system » — le logiciel affecté active un compte utilisateur privilégié sans en notifier les administrateurs du système —, sans logiciel corrigé disponible à la publication et un contournement offert à la place. En octobre 2023, CVE-2023-20101 : Emergency Responder était livré avec un compte root portant des « default, static credentials that cannot be changed or deleted » — identifiants statiques par défaut qui ne peuvent être changés ni supprimés —, des identifiants « typically reserved for use during development » — habituellement réservés à l’usage pendant le développement.
Un compte dont personne n’a été averti, que vous ne pouvez pas retirer, avec root sur une boîte de votre parc. Appelez-le comme vous voulez. C’est ce que décrit le propre avis du fournisseur.
Puis il y a le matériel Snowden, qui a maintenant plus d’une décennie et n’a jamais été retiré. En décembre 2013 Der Spiegel a publié le catalogue ANT, rapportant qu’une division de la NSA « has burrowed its way into nearly all the security architecture made by the major players in the industry – including American global market leader Cisco and its Chinese competitor Huawei » — s’est creusé un chemin dans presque toute l’architecture de sécurité faite par les grands acteurs de l’industrie, y compris le leader mondial américain Cisco et son concurrent chinois Huawei. Le même reportage décrivait comment le matériel y arrive : des expéditions détournées vers des ateliers secrets dans un processus que la NSA appelle interdiction, où « at these so-called ’load stations,’ agents carefully open the package in order to load malware onto the electronics, or even install hardware components that can provide backdoor access » — à ces « stations de chargement », des agents ouvrent soigneusement le colis pour charger un logiciel malveillant sur l’électronique, ou même installer des composants matériels fournissant un accès dérobé. Un bulletin interne de la NSA de 2010, publié en 2014 avec les photographies, posait le processus dans les propres mots de l’agence : des appareils « being delivered to our targets throughout the world are intercepted » — livrés à nos cibles à travers le monde sont interceptés —, puis « re-packaged and placed back into transit to the original destination » — remballés et remis en transit vers la destination d’origine.
Ce que le reportage ne montre pas, c’est la complicité. Der Spiegel a dit clairement que rien dans les documents ne suggérait que les fabricants savaient ou aidaient, et Cisco a nié toute implication à l’époque, et en mai 2014 son directeur juridique l’a mis au dossier : « as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products » — par politique et par pratique, Cisco ne travaille avec aucun gouvernement, y compris celui des États-Unis, pour affaiblir ses produits. Ils s’en sont plaints au président. À première vue, ils étaient une victime ici aussi.
Prenez ça pour argent comptant. Ça ne change rien à la boîte sur votre baie, parce que l’interdiction n’a jamais eu besoin de l’aide du fournisseur. Et il vaut de savoir quel poids porte le démenti, parce que la parole de Cisco a été mise à l’épreuve au tribunal. En 2019 ils ont réglé une procédure au titre du False Claims Act pour 8,6 millions de dollars au fédéral, plus 6 millions de dollars auprès d’un groupe d’États, au sujet d’un logiciel de vidéosurveillance vendu à des organismes publics avec des « flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage » — défauts permettant un accès non autorisé au système, avec le potentiel de contrôler et autrement manipuler les caméras de sécurité et les images enregistrées. Le compte rendu de l’Attorney General de New York est que Cisco a su pour les défauts en 2009 et ne les a pas corrigés avant 2013, après le début de l’enquête. Les règlements ne sont pas des aveux de responsabilité et je ne prétendrai pas le contraire. Ce sont quand même quatre ans de vente d’un produit à des forces de police et des organismes publics avec une voie d’entrée connue, sans le dire.
Donc le dossier est : des comptes root non documentés de leur propre aveu, un catalogue vieux d’une décennie les nommant, une chaîne d’expédition démontrée compromettable, et une période où ils savaient pour un trou et ont continué à vendre. Chacun isolément vous pourriez le balayer. Ensemble ils sont un schéma. Une déclaration d’une partie intéressée ne règle pas un schéma.
La réponse à ça, ce sont des contrôles, pas une interdiction. Le risque a sa place dans le document de conception avec tout le reste, et les alternatives sont chiffrées plutôt qu’écartées. Demandez quel matériel concurrent a été évalué et ce qu’il coûtait. Demandez quelle est la politique de vérification et de mise à jour du firmware, et qui la vérifie. Demandez comment le matériel est reçu et inspecté, et par qui. Demandez ce qui se passe sur un numéro de série qui ne correspond pas au bon de commande.
Et remarquez quels fournisseurs reçoivent cet examen dans votre secteur et lesquels non. La même industrie qui a mis Huawei sur un registre de risques au sujet d’une capacité que personne n’a produite en public écrira Cisco dans la conception de bas niveau sans une ligne de justification, sur la force d’un logo partenaire. J’ai écrit sur ce qui arrive à cet argument quand on applique la norme uniformément. Un logo partenaire est une relation commerciale avec des objectifs attachés. À ce titre, ce n’est pas une conclusion de sécurité.
Le pare-feu est la voie d’entrée
Élargissez ça d’un fournisseur à la catégorie, parce que le pare-feu est le produit qu’un MSP vend le plus fort. C’est la ligne qui justifie la partie sécurité du contrat.
La CISA tient un catalogue de vulnérabilités connues pour être exploitées dans la nature — pas théoriquement dangereuses, réellement utilisées contre quelqu’un. J’ai tiré le catalogue et l’ai compté par fournisseur. La version 2026.08.27 tient 1 685 entrées. Cisco en représente 96, second seulement aux 386 de Microsoft, et 42 d’entre elles siègent sur les lignes pare-feu et bordure. Fortinet en a 29. Palo Alto Networks en a 15. Pour l’échelle, Ivanti en a 35 et SonicWall 17.
Regardez ce que les entrées sont réellement, parce que le schéma ne varie jamais. C’est l’interface de gestion ou le VPN, c’est-à-dire la partie délibérément exposée à internet.
Le CVE-2024-3400 de Palo Alto était une injection de commande dans la fonction GlobalProtect de PAN-OS, notée 10,0, exploitée en zero-day. Plus tard la même année CVE-2024-0012 laissait « an unauthenticated attacker with network access to the management web interface » — un attaquant non authentifié avec accès réseau à l’interface web de gestion — passer tout droit l’authentification à 9,8, et c’était chaîné avec une injection de commande dans la même interface.
Le CVE-2022-40684 de Fortinet était un « authentication bypass using an alternate path or channel » — contournement d’authentification par un chemin ou canal alternatif — à 9,8. Son CVE-2018-13379, une traversée de chemin dans le VPN SSL, est entré au catalogue en novembre 2021. Des années après l’existence du correctif, parce que des boîtes étaient encore posées sur internet non corrigées et parcourues à pied.
Le CVE-2023-20198 de Cisco dans l’interface web IOS XE a été noté 10,0. CVE-2025-20333, dans le serveur web VPN de son logiciel Secure Firewall ASA et FTD, a été noté 9,9 en septembre dernier.
Et puis il y a CVE-2026-20316, ajouté au catalogue le 29 juillet 2026. Cisco Secure Firewall Management Center, « use of hard-coded password » — usage d’un mot de passe codé en dur —, laissant « an unauthenticated, remote attacker to log in to an affected device » — un attaquant distant non authentifié se connecter à un appareil affecté. Un identifiant statique, dans la boîte qui gère les pare-feux, confirmé comme exploité, un mois avant ce billet. La même défaillance qu’en 2018 et 2023 dans la section ci-dessus, sur la machine qui administre votre périmètre.
Maintenant la partie utile, parce que « certains fournisseurs sont pires que d’autres » n’est pas vraiment la leçon. Chacun de ceux-ci a un dossier public et rien de tout ça n’apparaît dans une proposition. Plus au point, le total du fournisseur n’est pas le chiffre qui décide si vous êtes touché. Votre exposition est l’écart entre une vulnérabilité entrant dans ce catalogue et votre boîte étant corrigée. Cet écart n’est pas au fournisseur de le combler. Il appartient à celui que vous payez pour faire tourner la chose.
Ce qui est la même mesure que l’ICO a prise chez Capita. Alerte à dix minutes, action à cinquante-huit heures, objectif d’une. Personne ne demande à son prestataire ce chiffre sur la correction des pare-feux, et c’est un chiffre que chaque prestataire a.
Quand les bases sont la chose que vous avez achetée
La partie un parlait de la vente. Ceci est ce qui est venu après, dans deux cas où un régulateur a fait l’enquête et publié ce qu’il a trouvé.
En mars 2025 l’Information Commissioner a infligé une amende de 3,07 millions de livres à Advanced Computer Software Group au sujet d’un incident de rançongiciel en août 2022. Advanced « provides IT and software services to organisations, including the NHS and other healthcare providers » — fournit des services informatiques et logiciels à des organisations, dont le NHS et d’autres prestataires de santé. Les attaquants sont entrés « via a customer account that did not have multi-factor authentication » — via un compte client qui n’avait pas d’authentification à plusieurs facteurs. Le NHS 111 a été perturbé, le personnel de santé ne pouvait pas atteindre les dossiers patients, et les informations personnelles de 79 404 personnes ont été prises. La conclusion de l’ICO sur la cause vaut d’être lue lentement : « while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access » — bien qu’Advanced ait installé l’authentification à plusieurs facteurs sur beaucoup de ses systèmes, l’absence de couverture complète a permis aux pirates d’obtenir l’accès. C’était aussi la première pénalité que l’ICO a émise contre un sous-traitant de données plutôt que l’organisation dont c’étaient les données.
En octobre 2025 le même régulateur a infligé une amende de 14 millions de livres à Capita au sujet de l’attaque de 2023 qui a pris les informations personnelles de 6,6 millions de personnes. Un fichier malveillant a atterri sur l’appareil d’un employé le 22 mars 2023. Une alerte de haute priorité s’est déclenchée en dix minutes. L’appareil n’a pas été mis en quarantaine pendant 58 heures, contre un temps de réponse cible d’une heure, et l’ICO a trouvé que le Security Operations Centre « was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts » — était en sous-effectif, et dans au moins six mois avant l’incident était tombé bien en dessous des temps de réponse cibles pour répondre aux alertes de sécurité —, à côté de tests d’intrusion et d’évaluation des risques inadéquats.
Lisez ce que ces deux conclusions ont en commun. Pas un adversaire habile. Pas un zero-day. Rien que personne n’aurait pu voir. Une authentification à plusieurs facteurs qui a été achetée mais pas finie, et une file d’alertes que personne n’avait dotée. Les deux sont des lignes que quelqu’un a validées et rapportées au vert.
Et rien de tout ça n’a pris l’industrie par surprise. Le 11 mai 2022, trois mois avant l’incident d’Advanced, les agences de cybersécurité du Royaume-Uni, d’Australie, du Canada, de Nouvelle-Zélande et des États-Unis ont sorti un avis conjoint sur les menaces pesant sur les prestataires de services gérés et leurs clients, parce qu’elles étaient « aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers » — au courant de rapports récents observant une hausse de l’activité cybermalveillante visant les prestataires de services gérés. La première action tactique de la liste est d’imposer l’authentification à plusieurs facteurs sur les comptes MSP qui entrent dans l’environnement du client.
Les agences de sécurité de cinq pays l’ont couché sur le papier, en public, et ont nommé le contrôle. Trois ans plus tard un régulateur inflige encore des amendes pour ne pas l’avoir fini.
Aucune de celles-là n’est une histoire de petite entreprise. En voici une. Le vendredi 24 novembre 2023 le prestataire informatique du secteur juridique CTS est tombé dans un incident cyber. Le propre journal de la Law Society a rapporté qu’environ 80 cabinets étaient incapables de conclure des transactions, avec des systèmes hors ligne et des contrats bloqués. Ce sont des études de transactions immobilières, la plupart de petits cabinets, et leurs clients étaient des gens en plein déménagement. L’un d’eux l’a dit platement : « This leaves us with so much uncertainty — with movers needing to be booked, days needing to be taken off work at potentially short notice and lives put on hold » — cela nous laisse tant d’incertitude, avec des déménageurs à réserver, des jours de congé à poser potentiellement au dernier moment et des vies mises en suspens. CTS ne pouvait dire que ceci : il était « unable to give a precise timeline for full restoration » — incapable de donner un calendrier précis pour la restauration complète.
Personne dans cette chaîne n’a choisi CTS. Le cabinet l’a choisi, et chaque client en aval du cabinet a hérité de la décision sans jamais avoir été demandé.
C’est ce que vous achetez quand vous achetez un service géré.
Et comment l’auriez-vous appris ?
Remarquez quelque chose sur chaque incident de la section ci-dessus. Aucun n’est arrivé au client. Ils sont arrivés au prestataire, et les clients étaient posés en aval de la mauvaise semaine de quelqu’un d’autre.
Alors posez la question directement. Si nous sommes piratés, l’apprend-on de vous ? Et à quelle vitesse ?
Il y a un plancher légal, et il est plus bas que les gens ne le supposent. Là où ils traitent des données personnelles pour votre compte, l’article 33 dit que « the processor shall notify the controller without undue delay after becoming aware of a personal data breach » — le sous-traitant notifie le responsable de traitement sans retard indu après avoir eu connaissance d’une violation de données personnelles. Aucun nombre d’heures fixe. Pendant ce temps vous, comme responsable de traitement, avez 72 heures pour prévenir l’Information Commissioner une fois que vous en avez connaissance. Lisez ces deux-là ensemble. Chaque heure qu’ils passent à décider s’il faut vous le dire est une heure de moins sur un compteur qui court contre vous, pas contre eux.
Et ce plancher ne couvre que les données personnelles. Une intrusion dans leur console de gestion, sans preuve encore que quoi que ce soit de vôtre ait bougé, peut ne générer aucun devoir de vous le dire du tout — tandis que les identifiants qui atteignent chaque machine que vous possédez siègent dans les mains de quelqu’un d’autre. C’est l’écart. Il n’est pas petit.
Pensez à qui est prévenu avant vous. Leurs avocats, à cause du privilège. Leur assureur, parce que la police le dit. Leur régulateur, sur le compteur légal. Vous êtes plus bas sur cette liste que vous ne voudriez l’être, et l’incitation à chaque étape est d’en dire moins jusqu’à ce qu’on en sache plus.
Ce qui laisse les alternatives, et elles sont toutes pires. Vous l’apprenez parce que vos systèmes s’arrêtent, ce qui est comme les études de transactions l’ont appris. Vous l’apprenez parce qu’un journaliste appelle. Ou vous l’apprenez parce que quelqu’un repère le nom du prestataire sur le site de fuite d’un groupe de rançongiciel, ce qui n’est pas un processus de notification, c’est un accident du marketing de quelqu’un d’autre.
Alors contractualisez-le, et soyez précis, parce que les clauses vagues retombent sur le plancher légal. Notification de tout incident matériel sur leur réseau dans un nombre d’heures stipulé, par écrit, que vos données soient confirmées impliquées ou non. Notification si un identifiant avec accès à vos systèmes a pu être exposé. Notification s’ils apparaissent sur un site de fuite. Un contact nommé de votre côté, pas une boîte aux lettres générale.
Puis posez la question qui vous dit le plus, et posez-la pendant qu’ils vous vendent encore. Avez-vous eu un incident ? Que s’est-il passé, quand les clients l’ont-ils appris, et comment l’ont-ils appris ? Un prestataire qui en a traversé un et l’a bien géré vous en parlera. C’est la meilleure preuve qu’il a. Quelqu’un qui dit que ce n’est jamais arrivé est soit très chanceux, soit très petit, soit ne compte rien.
L’outil qui atteint chaque client à la fois
Aucun MSP ne gagne d’argent à toucher les machines une par une. L’économie a besoin d’une console qui atteint tout, et c’est à ça que sert le logiciel de surveillance et de gestion à distance. Le RMM siège sur chaque machine sous contrat, tournant en tant que système, et le prestataire pilote le tout depuis un seul identifiant.
Retournez ça et regardez-le de votre côté. Il y a un logiciel sur vos machines que vous n’avez pas choisi, que vous ne pouvez probablement pas nommer, et dont vous n’avez jamais vu le dossier de correction. À ce titre, il peut faire n’importe quoi, à n’importe laquelle d’entre elles, à n’importe quel moment.
Le dossier sur ces outils n’est pas réconfortant. Commencez en 2021.
Kaseya, juillet 2021. La CISA et le FBI ont décrit une réponse à un rançongiciel « leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers » — exploitant une vulnérabilité dans le logiciel des produits sur site Kaseya VSA, contre les prestataires de services gérés (MSP) et leurs clients en aval. Une cinquantaine de prestataires ont été touchés, et jusqu’à 1 500 entreprises posées dessous, dont la plupart n’avaient jamais entendu parler de Kaseya et n’avaient pas leur mot à dire sur sa présence.
En janvier 2023 la CISA, la NSA et le MS-ISAC ont émis un avis conjoint pour « warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software » — avertir les défenseurs de réseau de l’usage malveillant de logiciels légitimes de surveillance et de gestion à distance (RMM) —, après une campagne l’octobre précédent où des attaquants ont hameçonné des gens pour installer ScreenConnect et AnyDesk, puis les ont utilisés pour mener une arnaque au remboursement contre les comptes bancaires des victimes. Personne n’a eu à pirater un MSP pour ça. L’outil marche exactement aussi bien pour eux que pour le prestataire.
En février 2024 ConnectWise ScreenConnect s’est révélé porter CVE-2024-1709, qui « may allow an attacker direct access to confidential information or critical systems » — peut permettre à un attaquant un accès direct à des informations confidentielles ou à des systèmes critiques. Il a été noté 10,0. Notez la classe de faiblesse dessus : contournement d’authentification par un chemin ou canal alternatif, mot pour mot la même catégorie que le contournement FortiOS plus haut. Fournisseur différent, produit différent, même erreur. Note maximale, dans le logiciel qui atteint chaque client d’un prestataire.
Puis SimpleHelp. L’avis de la CISA de juin 2025 décrit des acteurs de rançongiciel « leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider » — exploitant des instances non corrigées d’une vulnérabilité dans SimpleHelp RMM pour compromettre les clients d’un fournisseur de logiciel de facturation de services publics —, atteignant des « downstream customers » — clients en aval — pour une double extorsion. La faille dessous, CVE-2024-57727, laisse un attaquant non authentifié tirer des « server configuration files containing various secrets and hashed user passwords » — fichiers de configuration du serveur contenant divers secrets et mots de passe utilisateur hachés — directement de l’hôte.
Remarquez où la perte atterrit à chaque fois. Pas sur le fournisseur. Pas vraiment sur le prestataire non plus. Sur les clients dessous, qui n’ont jamais acheté l’outil, n’ont jamais été dit lequel c’était, et n’avaient aucun mot à dire sur le moment où il a été corrigé.
Une réserve sur ces sources, parce qu’elle compte. Ce sont des avis américains, et c’est parce que la CISA publie le détail des incidents tandis que le NCSC généralement ne nomme pas. C’est une différence de divulgation, pas de conduite. L’outillage est le même outillage, sorti du même catalogue, et une petite entreprise de support informatique dans ce pays fait tourner ScreenConnect ou SimpleHelp ou un de leurs concurrents sur vos machines cet après-midi.
Alors demandez lequel c’est. Demandez quelle version, quand il a été corrigé pour la dernière fois, qui peut se connecter à la console, si chaque compte dessus a l’authentification à plusieurs facteurs, et quel est le plan la prochaine fois qu’un de ceux-ci sort un dix.
Puis demandez-en une de plus, parce que la réponse vous dit quelque chose que les autres non. Marche-t-il en IPv6 ?
C’est une question juste en 2026 et elle atterrit plus fort qu’il n’y paraît. Si l’outil de gestion ne parle qu’IPv4, alors IPv4 est ce que votre réseau doit garder — pas parce que votre entreprise en a besoin, mais parce que leur outillage en a besoin. C’est le plan d’adressage fixé par le logiciel d’un fournisseur plutôt que par vos besoins, et vous payez chaque mois les adresses qui le rendent possible. Un télétravailleur sur une connexion mobile est fort possiblement déjà sur un réseau uniquement IPv6, auquel cas tout l’arrangement s’appuie sur une traduction que quelqu’un d’autre maintient.
Et si la réponse est qu’ils n’ont jamais vérifié, vous avez appris la chose sur laquelle vous demandiez réellement.
Une plus simple d’abord, qui se perd dans tout le discours sécurité. Quelle charge l’agent met-il sur la machine, et où est la preuve ?
La réponse que vous obtiendrez est « négligeable ». C’est un adjectif. Ce que vous voulez, c’est un chiffre, mesuré sur du matériel comme le vôtre plutôt que relevé d’une fiche technique — CPU moyen et de pointe, mémoire résidente, activité disque pendant un balayage d’inventaire ou un scan de correctifs, et réseau quotidien. Pris sur la machine la plus vieille du parc plutôt que la plus neuve.
Et mesurez toute la pile, pas un agent isolé. Gestion à distance, antivirus, détection sur poste, le client de sauvegarde, la surveillance, le suivi d’actifs. Chaque fournisseur dit moins d’un pour cent, il y en a six, et la personne qui doit réellement travailler sur ce portable est celle qui découvre à combien s’additionnent six d’entre eux. Proche de zéro est le bon objectif. La preuve est le seul moyen de l’établir.
Demandez les chiffres avant le déploiement, et demandez à prendre les vôtres ensuite sur une machine que vous choisissez. Un prestataire confiant dans son outillage offre les deux sans qu’on le pousse.
Une de plus sur l’outil lui-même, et c’est celle que les gens trouvent la plus étrange jusqu’à ce qu’ils y réfléchissent. Vous dit-on quand l’agent se met à jour sur vos machines ?
L’agent est le logiciel au plus haut privilège de votre parc. Il tourne en tant que système, sur tout, et il change de version quand le prestataire ou le fournisseur décide qu’il devrait. Un logiciel est installé à travers toute votre entreprise par un tiers, silencieusement, et sur la plupart des contrats personne ne vous dit que c’est arrivé.
Maintenant mettez ça à côté de ce qui a réellement mal tourné chez Kaseya. Une mise à jour malveillante poussée par un canal de gestion de confiance vers chaque machine à la fois. De là où vous êtes, le jour même, c’est indistinguable d’une mise à jour d’agent de routine — même canal, même privilège, même silence. La seule différence est l’intention. L’intention n’est pas quelque chose que vous pouvez observer.
Alors demandez des notifications de changement de version, demandez qui approuve une mise à jour d’agent et si elle est testée quelque part avant de vous atteindre, et demandez celle qui compte le plus : qu’est-ce qui vous dirait qu’une poussée a eu lieu alors qu’elle n’aurait pas dû ? Si la réponse honnête est rien, alors le contrôle sur lequel vous vous appuyez est la propre vigilance du prestataire, ce qui est la chose dont parle toute cette section.
Et les clés qui l’ouvrent
Puis il y a ce qui ouvre la console. Ça reçoit encore moins d’attention que la console.
Un MSP détient des identifiants administratifs pour chaque client à son carnet. C’est le métier — c’est tout le produit. Donc la norme appliquée à ses propres identifiants devrait être plus haute que celle qu’il fixe pour les vôtres, et en pratique elle est couramment plus basse. Comptes partagés, parce que des identifiants individuels pour douze ingénieurs sur deux cents locations est une corvée. Mots de passe dans un coffre que tout le bureau de service peut lire. Clés SSH sans phrase de passe posées sur des portables qui rentrent à la maison dans le train. Comptes de secours que personne n’a touchés depuis que la personne qui les a faits a quitté l’entreprise.
« Nous utilisons la MFA » est où cette conversation s’arrête normalement, et elle ne devrait pas, parce que ses formes ne sont pas égales. La CISA les classe de la plus forte à la plus faible : FIDO/WebAuthn et à base de PKI en haut, qu’elle appelle « the gold standard » — l’étalon-or ; mots de passe à usage unique par appli et notifications push en dessous, « vulnerable to push bombing attacks as well as user error » — vulnérables aux attaques de bombardement push ainsi qu’à l’erreur utilisateur ; et SMS tout en bas, qui « should only be used as a last resort MFA option » — ne devrait être utilisé que comme option MFA de dernier recours. Seule la rangée du haut résiste au hameçonnage. Tout ce qui est en dessous peut être relayé, fatigué ou intercepté pendant que la personne qui l’approuve croit se connecter normalement.
Les attaquants ont lu ce document aussi. L’avis de la CISA sur Scattered Spider dit que le groupe « targets large companies and their contracted information technology (IT) help desks » — vise les grandes entreprises et leurs services d’assistance informatique sous contrat. Pas le client. Le service d’assistance qui peut réinitialiser les identifiants du client. C’est bien plus facile, et ça vous donne tout le monde à la fois.
Donc la question est plus étroite que de savoir s’ils utilisent la MFA. Chaque compte qui peut atteindre vos systèmes est-il sur un jeton matériel — un jeton, pas une appli — et que se passe-t-il quand quelqu’un appelle le bureau de service à onze heures du soir en disant qu’il est un ingénieur qui s’est verrouillé dehors ?
Le correctif ici est exceptionnellement simple, ce qui rend son absence dure à pardonner. Google a dit à KrebsOnSecurity en 2018 qu’il « has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017 » — n’a eu aucun de ses plus de 85 000 employés hameçonné avec succès sur ses comptes professionnels depuis début 2017 —, quand il a commencé à exiger des clés de sécurité physiques au lieu de mots de passe et de codes à usage unique. Pas moins d’incidents. Aucun. Le même article note que la clé de base se vendait au détail à vingt dollars.
Maintenant mettez ça à l’échelle d’un prestataire de services gérés. Ils n’ont pas besoin d’émettre des clés à votre personnel. Ils ont besoin de les émettre à leurs propres ingénieurs, et il y en a peut-être une douzaine détenant les identifiants qui atteignent chaque client au carnet. Une douzaine de clés, achetées une fois, contre un rayon d’explosion couvrant chaque entreprise qu’ils touchent. Vingt livres chacune. Quand quelqu’un vous dit que les jetons matériels sont impraticables, demandez combien de gens en auraient réellement besoin.
Et il y a une question liée que vous devriez poser sur votre propre parc, parce que la plupart des clients n’y ont jamais pensé. Qui détient le compte de secours pour vos systèmes ? Sur bien des contrats la réponse honnête est que le prestataire le détient, et vous n’en avez pas du tout. Vous ne pouvez pas entrer dans votre propre infrastructure sans les appeler. Ce n’est pas un contrôle de sécurité, c’est une dépendance. Elle mord les pires jours plutôt que les ordinaires. Le jour où vous donnez votre congé. Le jour où ils sont rachetés par quelqu’un que vous n’avez pas choisi. Le jour où ce sont eux qui ont été compromis et où vous devez agir sans eux.
Vous devriez détenir vos propres identifiants de secours, scellés, écrits dans le contrat, et testés à une date que quelqu’un peut montrer du doigt. Si votre prestataire est réticent, la réticence elle-même vous a dit quelque chose.
La même question descend jusqu’au bureau, et c’est celle qu’on oublie complètement. Chaque portable et poste de travail qu’ils vous ont construit a un mot de passe administrateur du BIOS dessus, fixé pendant la construction par quelqu’un de leur côté. Vous possédez la machine. Ils en détiennent la clé.
Pensez à ce que ce mot de passe gouverne réellement. L’ordre de démarrage. Le démarrage sécurisé. Si la chose démarrera d’une clé USB tout court. C’est-à-dire si vous pouvez réinstaller une machine que vous possédez, en récupérer une qui ne démarre pas, en remettre un lot à quelqu’un d’autre, ou les effacer correctement avant qu’ils passent la porte. Sur un portable ça peut aussi être ce qui se dresse entre un voleur et le disque. Rien de tout ça n’est exotique. C’est l’affaire ordinaire de posséder des ordinateurs, et sur bien des parcs le propriétaire ne peut rien faire de tout ça sans appeler le fournisseur.
Demandez le tout. Chaque portable, chaque poste, chaque serveur — le mot de passe BIOS ou firmware, l’identifiant BMC sur tout ce qui en a un, et le mot de passe du chargeur d’amorçage sur tout ce où GRUB ou son équivalent a été verrouillé, ce qui est le même verrou une couche plus haut et est ce qui se dresse entre vous et un démarrage de secours sur un serveur qui ne démarre pas. Si c’est le même mot de passe sur tous, ça vaut de le savoir aussi. Et si la réponse est non, demandez pourquoi non, parce que les raisons offertes sont minces : l’honnête est que ça rend leur construction plus facile, et le reste est habillé en sécurité. Un mot de passe que vous n’avez pas le droit d’avoir ne vous protège de personne. Il les protège de votre départ.
Puis il y a le compte avec lequel vous vous connectez réellement pour réparer une machine. Administrateur local sur chaque boîte Windows, root sur chaque Linux, et quelque chose d’équivalent sur chaque switch, pare-feu et hyperviseur du bâtiment. Deux questions couvrent le tout, et elles couvrent aussi les mots de passe firmware et chargeur d’amorçage ci-dessus. Sont-ils différents sur chaque machine, et quel système de gestion de mots de passe les détient — le vôtre, ou le leur ?
Différent compte plus que les gens ne l’attendent. Un mot de passe administrateur local sur deux cents machines n’est pas deux cents mots de passe, c’en est un, et il est posé sur le portable le moins défendu de l’entreprise autant que sur le serveur des finances. Ce n’est pas une faiblesse théorique, c’est le coup standard — entrer sur n’importe quoi, lire le mot de passe, marcher vers tout. Microsoft livre la réponse dans la boîte. Windows LAPS fixe un mot de passe différent sur chaque machine, le renouvelle sur un calendrier, et le sauvegarde dans Active Directory ou votre propre location Entra. La propre page de Microsoft liste le bénéfice en premier comme « protection against pass-the-hash and lateral-traversal attacks » — protection contre les attaques pass-the-hash et de traversée latérale —, et la fonction est gratuite sur chaque version supportée de Windows, sans rien de plus à payer pour stocker les mots de passe dans votre propre annuaire. Donc si la réponse est un mot de passe partout, ce n’est pas un problème de licence et ce n’est pas un problème d’outillage. Quelqu’un ne l’a jamais activé.
Le système de qui est celui sur lequel appuyer, et remarquez où LAPS met le mot de passe par défaut : dans votre annuaire, sous votre contrôle d’accès, avec votre relevé de qui l’a lu. C’est la forme que vous voulez sur tout. L’identifiant de votre machine vit dans quelque chose que vous possédez, et votre prestataire se voit accorder l’accès — un accès que vous pouvez voir, et retirer un mardi après-midi sans demander la permission.
L’autre forme est la courante. Les mots de passe siègent dans leur gestionnaire de mots de passe, ou dans le coffre d’accès privilégié boulonné sur leur outil de gestion à distance, et vous n’avez aucun identifiant pour lui. Alors chaque mot de passe administratif de votre entreprise est détenu par une entreprise avec qui vous n’avez aucun compte, le journal de qui a lu l’un est le leur, et le jour où la relation tourne au vinaigre vous demandez gentiment les clés de machines que vous possédez.
Alors posez la relance, et posez-la maintenant plutôt qu’à la réunion de sortie. Comment ceux-ci entrent-ils dans notre système ? Il y a trois réponses honnêtes. Déplacer le dépôt dans notre annuaire ou notre coffre, et en prendre un accès délégué. Ou nous donner un accès en lecture au vôtre aujourd’hui, avec un export que nous pouvons lancer nous-mêmes, dans un format que notre propre coffre avalera. Ou nous remettre une copie scellée sur un calendrier, datée, que nous ouvrons et testons. « C’est tout dans notre système et vous pourrez l’avoir quand vous partirez » n’est pas sur la liste, parce que le jour où vous partez est le jour où ils ont le moins de raison d’être rapides sur quoi que ce soit.
Et demandez ce qu’il advient de ces mots de passe ensuite. Un identifiant que leurs ingénieurs ont connu pendant quatre ans n’est pas rendu sûr par un courriel disant qu’il est parti. Chacun d’eux a besoin d’être renouvelé au départ, par vous, sur des machines dont vous détenez maintenant le mot de passe firmware.
Et puis la version en direct de tout ça. Vous dit-on quand un mot de passe d’un de vos systèmes est lu ?
Pas un journal qu’ils tiennent et pourraient vous montrer si vous demandiez. Un message qui arrive de votre côté : quel identifiant, quel ingénieur, quel ticket, et quand. La capacité n’est en doute nulle part — chaque coffre digne du nom enregistre un retrait, et le propre dépôt de Microsoft le fait dans votre propre location, où récupérer un mot de passe est écrit au journal d’audit Entra comme « Recover device local administrator password » — récupérer le mot de passe administrateur local de l’appareil — contre le compte qui l’a fait. Donc la seule vraie question est de savoir si le relevé pointe quelque part que vous pouvez voir.
Demandez, et si la réponse est non, demandez pourquoi non. Il y a un non honnête là-dedans quelque part — une alerte sur chaque retrait dans un parc chargé se déclencherait quarante fois par jour et vous cesseriez de la lire dès le mercredi. Ça a une réponse plutôt que d’être la fin de la conversation. Alertez sur ceux qui devraient être rares : le compte administrateur de domaine, les identifiants de secours, les mots de passe firmware et chargeur d’amorçage, les clés de récupération. Et alertez sur toute lecture sans numéro de ticket attaché, parce que c’est soit une tenue de dossiers négligée soit précisément la chose dont vous voulez entendre parler, et aucune des deux n’est bien servie en le découvrant à la revue trimestrielle.
Ce qu’ils peuvent faire une fois entrés
Une de plus, et c’est celle qui obtient le plus souvent un regard vide. Vous dit-on quand un de leurs ingénieurs entre dans vos systèmes ?
Pas un journal qu’ils tiennent. Une notification que vous recevez — qui est entré, quand, pour combien de temps, et contre quel ticket. Demandez-la, et si la réponse est non, demandez pourquoi non.
Il y a un précédent, et il siège à l’intérieur des produits qu’ils vous revendent. Le Customer Lockbox de Microsoft fait qu’un ingénieur Microsoft demande votre approbation explicite avant de pouvoir atteindre votre contenu dans un dossier de support. Google publie des journaux Access Transparency de son propre personnel touchant vos données, et Access Approval les fait demander d’abord. Donc les plus grands fournisseurs de la terre, avec un accès bien plus étroit que celui que votre prestataire détient, ont bâti des flux d’approbation et des journaux d’accès pour leurs propres employés, et vous remettent le relevé.
Votre MSP a l’administrateur de domaine. Demandez ce qu’il vous remet.
Et il y a une raison plus dure que la responsabilité. Une notification qui arrive de votre côté est le seul signe indépendant que vous obtiendrez jamais que leurs identifiants sont utilisés par quelqu’un qui n’est pas eux. Si un attaquant entre par un bureau de service, chaque journal qui le montrerait siège à l’intérieur de l’organisation qui vient d’être compromise. Une qui atterrit dans votre boîte de réception siège dehors.
Un niveau en dessous de ça encore, à la machine elle-même. L’outil distant peut-il se connecter au poste de quelqu’un sans que cette personne y consente ?
Pour un serveur à trois heures du matin, l’accès sans surveillance est tout l’intérêt et personne de sensé n’objecte. Pour une machine à laquelle quelqu’un est assis, avec son courrier ouvert et son travail à l’écran, c’est un acte différent. Chaque produit de gestion à distance sérieux peut être réglé pour demander avant de se connecter, pour montrer un indicateur visible pendant qu’une session est en cours, et pour laisser la personne refuser. Que le vôtre fasse quoi que ce soit de ça est un réglage de configuration, et le réglage a été choisi par les gens qu’il arrange.
Alors demandez trois choses, et gardez-les séparées. Vos ingénieurs peuvent-ils atteindre un poste du personnel sans invite ? La personne assise devant voit-elle quoi que ce soit pendant que quelqu’un est connecté ? Peut-elle refuser ?
Si la première est oui et les deux autres non, ce n’est pas une contrainte technique. C’est un défaut que personne n’a revisité, sur un produit acheté par la partie qu’il favorise. Ça vaut aussi d’être mis devant quiconque porte la protection des données dans votre organisation, parce que quelqu’un regardant l’écran d’un employé à son insu est une décision qui devrait avoir un nom en face.
Puis la question qui décide si tout ça est prouvable ensuite. Leurs ingénieurs sont-ils enregistrés pendant qu’ils travaillent sur vos systèmes ?
L’enregistrement de session n’est pas exotique et ce n’est pas une grosse demande. C’est une fonction phare de chaque produit d’accès privilégié du marché, ce qui veut dire que votre prestataire le paie fort possiblement déjà et ne l’a jamais activé. Une session enregistrée vous donne une vidéo, ou un journal de frappes et de commandes, ou les deux, liés à un ingénieur nommé et un numéro de ticket. C’est à quoi ressemble la responsabilité quand elle est réelle plutôt que promise — pas une assurance que les ingénieurs se tiennent bien, mais un relevé qui le montrerait si l’un ne le faisait pas.
Alors demandez si c’est activé, et ensuite demandez comment vous y accédez, parce qu’un enregistrement que vous ne pouvez pas obtenir n’est pas une preuve, c’est une rumeur. Il y a trois réponses qui valent d’être eues, par ordre décroissant. Les enregistrements atterrissent dans un stockage que vous possédez, écrits au fur et à mesure. Ou vous avez un accès en lecture à leur système aujourd’hui, avec un export que vous pouvez lancer vous-même. Ou il y a une voie de demande avec un délai stipulé — des heures, par écrit, dans le contrat — que vous avez testée au moins une fois sur une session ordinaire plutôt que pour la première fois pendant une dispute.
Ce que vous ne voulez pas, c’est l’arrangement courant : des enregistrements détenus seulement par le prestataire, une rétention fixée par le prestataire, une suppression au bon vouloir du prestataire. C’est un contrôle qui marche parfaitement jusqu’au jour où il est nécessaire contre le prestataire. Alors demandez qui peut raccourcir la rétention, qui peut en supprimer un, et si regarder un enregistrement est lui-même journalisé. Et demandez ce qu’il advient du tout le jour où vous partez.
Soyez juste sur l’autre côté, parce qu’il y en a un. Un enregistrement d’un ingénieur réparant un portable est aussi un enregistrement de ce que votre personnel avait à cet écran, et de temps en temps d’un identifiant tapé à la vue de tous. Les enregistrements sont sensibles en propre et veulent le même traitement que le coffre : chiffrés, à accès contrôlé, journalisés à la consultation, gardés pour une période stipulée et pas plus. Un prestataire qui soulève ça avec vous avant que vous ne le souleviez avec lui a réfléchi au problème. Un qui ne l’a jamais considéré vous a dit quelque chose aussi.
Le même outil déplace presque certainement des fichiers, dans les deux sens. Demandez s’il le fait, et ensuite demandez ce qui a été mis autour.
Le sortant est celui que personne ne chiffre. Un transfert par le canal de gestion est chiffré, de confiance, et siège hors de chaque contrôle que vous avez déjà payé — la prévention de fuite de données, la surveillance de sortie, la politique sur les clés USB. Quiconque a accès à la console peut prendre une copie de n’importe quoi sur n’importe quelle machine, et sur la plupart des déploiements il n’y a aucun relevé qu’on vous montrera jamais.
L’entrant est comment les incidents plus haut dans ce billet sont réellement arrivés. Pousser un fichier vers chaque poste à la fois n’est pas un défaut de ces produits, c’est la fonction phare. Le rançongiciel l’a simplement utilisée comme elle a été bâtie pour être utilisée.
Alors demandez si le transfert de fichiers est activé du tout, s’il peut être éteint sur les machines qui n’en ont jamais besoin, si chaque transfert est journalisé avec le fichier, la direction, la machine et l’ingénieur — et si ce journal vous parvient, ou rejoint les autres dans leur boîte de réception.
Et dernier là-dessus, parce que c’est celui que personne ne pense à demander du tout. Que collecte réellement l’agent, et qu’advient-il de ça ?
Ces outils recueillent bien plus qu’un niveau de correctif. Inventaire matériel et logiciel, journaux d’événements, télémétrie de performance, souvent des enregistrements de session et des captures d’écran, parfois bien plus selon ce qui est activé. C’est une image détaillée de comment votre entreprise marche et de ce que votre personnel fait toute la journée. Elle quitte vos locaux en continu.
Alors demandez ce qui est collecté, où c’est stocké et sous quelle juridiction, combien de temps c’est gardé, et qui peut le voir — parce que la réponse est en général le prestataire et le fournisseur de l’outil, ce qui est une seconde entreprise que vous n’avez jamais choisie et avec qui vous n’avez aucun contrat. Demandez si quoi que ce soit sert à quoi que ce soit au-delà de vous soutenir : analytique produit, étalonnage, entraînement de modèles. Demandez ce qu’il advient du tout le jour où le contrat finit, et obtenez ça par écrit plutôt que dans une conversation.
Et notez de qui ce sont les données. Des relevés sur votre personnel et vos systèmes, détenus par quelqu’un traitant pour votre compte, est une phrase avec des obligations attachées, et elles sont vôtres plutôt que leurs.
La puce qui répond quand la machine est éteinte
Il y a une couche de plus sous tout ça, et elle vaut d’être demandée par son nom. Utilisent-ils Intel vPro, ou l’Active Management Technology dessous ?
Si vous ne l’avez pas rencontrée, la version courte est qu’un firmware de gestion tourne sur un contrôleur séparé à l’intérieur du chipset, avec sa propre pile réseau. Il répond pendant que la machine est éteinte, à condition qu’il y ait le secteur et un câble. Il peut allumer la boîte, changer les réglages du BIOS, monter une image distante et réinstaller, et sur la bonne configuration prendre l’écran et le clavier au niveau matériel — avant que le système d’exploitation ait chargé, et qu’il le fasse jamais ou non.
Il y a de vraies raisons de vouloir ça. Une machine qui ne démarre pas, un réglage BIOS sur un appareil à trois cents miles, une réimage sans envoyer personne. Dans un grand parc dispersé c’est utile et je ne prétendrai pas le contraire.
Mais regardez où elle siège. Sous le système d’exploitation, ce qui veut dire sous chaque contrôle que vous avez acheté. Votre protection sur poste ne peut pas la voir, parce qu’elle ne tourne pas dans le système d’exploitation. Votre pare-feu hôte ne la filtre pas, parce que le trafic n’atteint jamais la pile réseau du système d’exploitation — il est traité sur ses propres ports avant que rien d’autre y jette un œil. Votre journalisation ne la couvre pas. Rien de ce que vous avez installé ne peut vous dire qu’une session a eu lieu.
Le dossier de sécurité n’est pas rassurant non plus. CVE-2017-5689 a été noté 9,8, et la description vaut d’être lue lentement : « an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs » — un attaquant réseau non privilégié pourrait obtenir des privilèges système sur les SKU de gestion Intel provisionnés. La CISA a émis une alerte et CERT/CC une note de vulnérabilité. Notez ce mot « provisioned » — dormant ce n’est pas une voie d’entrée, et activé c’en est une. Et le firmware qui la porte ne se met pas à jour par la correction normale que vous payez. Il vient du fabricant de la machine, sur son calendrier.
Puis il y a la partie qui devrait concerner quiconque est responsable de personnel plutôt que de serveurs. Le contrôle d’écran au niveau matériel veut dire que quelqu’un peut regarder un affichage pendant que le système d’exploitation n’en a aucune idée. Demandez si l’invite de consentement de l’utilisateur est imposée et si l’indicateur de session visible est activé, parce que les deux sont de la configuration et les deux peuvent être éteints par celui qui l’a provisionnée.
Alors les questions sont courtes. Est-elle provisionnée sur nos machines, et qui l’a fait, et quand — était-ce une partie d’une construction que personne n’a mentionnée ? Quels travaux précis en ont besoin, et combien de machines ont réellement besoin de ces travaux ? Quel réseau peut atteindre les ports de gestion, et est-ce segmenté de tout le reste ? Le consentement est-il imposé, l’indicateur est-il activé, et où est la piste d’audit ? Et peut-elle être déprovisionnée sur chaque machine qui n’en a pas besoin ?
Si la réponse à la première est « nous ne savons pas », ça vaut d’être su en soi, parce que ça veut dire que la capacité est posée là, configurée par quelqu’un et surveillée par personne.
Le risque est entré gratuitement
Retournez tout ce chapitre sens dessus dessous et il dit une chose. Chaque capacité dedans est arrivée comme une commodité et a été tarifée comme une. L’agent qui corrige mille machines est la chose qui peut poser un fichier sur mille machines. La puce qui épargne un trajet de deux cents miles répond quand la machine est éteinte et ne dit rien à votre journalisation. La commodité a été cotée, détaillée et validée. La capacité est venue dans la même boîte, non tarifée. Elle apparaît sur aucun document qu’on vous a jamais montré.
Rien de tout ça n’est un argument pour se passer de tout. Les parcs ont besoin d’être corrigés, et quelqu’un doit pouvoir atteindre une machine morte. C’est un argument pour savoir ce qui est dans le bâtiment, qui peut l’atteindre, d’où, et ce qu’il faudrait pour que la personne détenant cette portée soit quelqu’un d’autre que l’entreprise qui la détient actuellement. Une facture ne vous le dira jamais, parce qu’une facture est une liste de ce que vous payez. Ce n’est pas une liste de ce à quoi vous êtes exposé. Personne dans cet arrangement n’a jamais été prié de produire la seconde.
La partie trois parle de ce qui se passe quand l’un d’eux se déclenche. Ce que le contrat promet réellement, qui finit par porter la perte, à quoi ressemblent les excuses, et ce que partir coûte quand vous en avez enfin eu assez.
Sources
Consultées le 28 août 2026.
Formation et compétences.
- National Vulnerability Database — nombre de CVE publiées par an, sommé par trimestre : 6 595 en 2015 contre 49 972 en 2025.
Le matériel.
- CVE-2018-0141 — mot de passe de compte codé en dur, Cisco Prime Collaboration Provisioning, mars 2018.
- CVE-2018-15439 — switches Small Business, un compte privilégié activé sans en notifier les administrateurs, novembre 2018.
- CVE-2023-20101 — Cisco Emergency Responder, identifiants root statiques qui ne peuvent être changés ni supprimés, octobre 2023.
- Der Spiegel, 29 décembre 2013 — le catalogue ANT, nommant Cisco et Huawei entre autres, à partir des documents Snowden.
- Der Spiegel, 29 décembre 2013 — à l’intérieur de TAO : interdiction, stations de chargement, et ce qui arrive à une expédition détournée.
- Ars Technica, 14 mai 2014 — le bulletin interne de la NSA de 2010 et les photographies d’un routeur Cisco en cours d’implantation, publiés dans No Place to Hide de Glenn Greenwald.
- Cisco, 13 mai 2014 — la réponse de l’entreprise, dans ses propres mots.
- Attorney General de New York, 2019 — le règlement multi-États au sujet d’un logiciel de vidéosurveillance vendu à des organismes publics, et la chronologie de 2009 à 2013.
Le matériel de périmètre.
- Catalogue des vulnérabilités connues exploitées de la CISA — version 2026.08.27, 1 685 entrées ; les décomptes par fournisseur dans ce billet sont mon propre relevé de ce fichier.
- CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect et l’interface web de gestion.
- CVE-2022-40684, CVE-2018-13379 — contournement d’authentification FortiOS et traversée de chemin du VPN SSL.
- CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — interface web Cisco IOS XE, le serveur web VPN de l’ASA, et un mot de passe codé en dur dans Secure Firewall Management Center.
- CISA, Implementing Phishing-Resistant MFA — le classement des formes de MFA, de la plus forte à la plus faible.
- KrebsOnSecurity, juillet 2018 — Google sur ses plus de 85 000 employés et aucun hameçonnage réussi après avoir imposé des clés de sécurité physiques.
- Avis conjoint AA23-320A — Scattered Spider, et son ciblage des services d’assistance informatique sous contrat.
- Aperçu de Windows LAPS — un mot de passe administrateur local différent par machine, renouvelé et sauvegardé dans votre propre Active Directory ou location Entra ; gratuit sur chaque version supportée de Windows.
Quand ça tourne mal.
- ICO, mars 2025 — Advanced Computer Software Group amendé de 3,07 millions de livres, la première pénalité du régulateur contre un sous-traitant de données. La page d’exécution porte le détail.
- ICO, octobre 2025 — Capita amendé de 14 millions de livres au sujet de la violation de 2023 : l’alerte de dix minutes, la réponse de 58 heures contre un objectif d’une heure, et le Security Operations Centre en sous-effectif.
- Law Society Gazette, 28 novembre 2023 — environ 80 études de transactions immobilières incapables de conclure des transactions après la chute de leur prestataire informatique.
- La CISA et le FBI sur l’attaque Kaseya VSA, juillet 2021 — rançongiciel contre les prestataires de services gérés et leurs clients en aval.
- Avis conjoint AA23-025A, 25 janvier 2023 — la CISA, la NSA et le MS-ISAC sur l’usage malveillant de logiciels RMM légitimes.
- CVE-2024-1709 — contournement d’authentification ConnectWise ScreenConnect, CVSS 10,0, février 2024.
- Avis CISA AA25-163A, juin 2025 et CVE-2024-57727 — des acteurs de rançongiciel atteignant des clients en aval par un SimpleHelp RMM non corrigé.
- Avis conjoint AA22-131A, 11 mai 2022 — les agences britannique, australienne, canadienne, néo-zélandaise et américaine sur les menaces pesant sur les prestataires de services gérés et leurs clients.