Une vulnérabilité sur la plateforme N-central met en évidence les risques liés aux MSP : qu'implique l'incident N-able pour la sécurité de votre solution de surveillance et de gestion à distance (RMM) ?

Votre RMM dispose d'un accès administratif à chaque appareil que vous gérez, sans surveillance, à tout moment, et dans l'ensemble des environnements client que vous administrez. Cet accès n’est pas une fonctionnalité. C’est le produit. Et c'est cet élément qui fait de votre fournisseur RMM l'une des décisions les plus stratégiques de votre écosystème, non pas en raison de ses performances lorsque tout fonctionne, mais en raison des conséquences lorsqu'un problème survient.

Le 1er août, N-able a révélé la vulnérabilité critique CVE-2026-18577 touchant N-central, la plateforme RMM utilisée par des milliers de MSP pour déployer des correctifs et accéder à distance aux appareils gérés de leurs clients. Elle permettait à des attaquants de prendre le contrôle administratif de la console sans disposer d'identifiants valides. Une fois infiltrés, les attaquants ont exploité la fonctionnalité de contrôle à distance de N-central pour accéder à des terminaux gérés, notamment des contrôleurs de domaine. Plusieurs entreprises étaient concernées. N-able a ensuite publié un correctif d'urgence le 2 août (le rapport d'incident de Huntress présente la chronologie complète). La CISA l’a ajoutée à son catalogue des vulnérabilités exploitées connues la même semaine et a ordonné aux agences fédérales américaines d’appliquer un correctif sous quelques jours.

Lorsque j'ai eu connaissance de cette vulnérabilité, cela m'a rappelé les discussions que nous avions eues lors du développement de LogMeIn Resolve en 2021, juste après une attaque majeure et très médiatisée sur la chaîne d'approvisionnement. L'un de nos ingénieurs principaux a été formel : pour lui, ces attaques allaient continuer de prendre de l'ampleur, et il nous fallait agir différemment pour protéger nos clients. C'est ce que nous avons fait, avec l'architecture Zero Trust de Resolve, en ajoutant des contrôles conçus pour empêcher qu'un seul accès non autorisé au niveau de la couche de gestion n'impacte l'ensemble de la chaîne, c'est-à-dire les environnements gérés qu'un MSP a sous sa responsabilité.

L’architecture de Resolve repose sur l’hypothèse que le serveur sera compromis tôt ou tard. La question que nous nous sommes posée est la même que je poserais aujourd'hui à tout fournisseur de solution RMM : si l'infrastructure est compromise, que peut réellement faire un attaquant ? Dans le cas de LogMeIn Resolve, ils ne pourront pas accéder à vos terminaux. La clé de signature Zero Trust peut empêcher tout attaquant d'exécuter des actions qui nécessitent des privilèges sur un terminal géré, car personne, pas même le fournisseur, ne détient cette clé.

L'architecture figure parmi les critères les plus importants, mais ce n'est pas le seul. D'autres éléments sont à examiner, et avant votre prochain échange en vue d'un renouvellement, ou si vous êtes à la recherche d'une nouvelle plateforme, voici six questions à poser à votre fournisseur RMM.

La plupart des MSP avec lesquels j'échange considèrent leur modèle de déploiement RMM comme une préférence informatique. Toutefois, il s'agit en réalité d'une décision de sécurité, qui n'est que trop rarement traitée comme telle.

La question du système sur site est trop souvent sous-estimée, par exemple. C'est un serveur qui nécessite l'application de correctifs, un renforcement de la sécurité et une protection des terminaux. Mais en pratique, il est rarement géré de cette façon. Comme il ne s'agit pas d'un poste de travail, l'EDR l'ignore souvent. Comme ce n'est pas un service cloud, personne ne surveille sa posture de sécurité, à part vous. Et il réside sur votre réseau, avec des droits d’accès étendus à chaque appareil que vous gérez.

L'incident N-able a confirmé ce schéma presque à l'identique : le système N-central fonctionne sous une version verrouillée de Linux et, selon des experts indépendants, l'EDR n'y est généralement pas déployé, car il est géré comme un appareil et non comme un serveur.

Le déploiement cloud-native transfère cette responsabilité au fournisseur. L'importance de ce point dépend entièrement de la manière dont le fournisseur a sécurisé et audité cette infrastructure (et c'est justement l'objet des questions 3 et 6).

Posez ces questions à votre fournisseur : « Si j'exécute votre produit sur site, de quelle part de la sécurisation de ce serveur suis-je responsable ? Faut-il y déployer un EDR ? »

C’est sans doute la question architecturale la plus importante de cette liste, et celle qui devrait rester au centre de vos préoccupations lors de vos échanges avec un fournisseur. La réponse vous apporte presque toutes les informations essentielles sur l’architecture d’un fournisseur.

Dans une architecture classique, le serveur est un nœud de confiance. Un attaquant qui obtient un accès administrateur à ce serveur hérite de cette confiance, ce qui lui permet d'exécuter des commandes, des scripts et de déclencher des sessions à distance sur chaque appareil géré qui y est connecté. Le backend est la clé du système. C'est précisément ce qui s'est produit lors de l'incident N-able, lorsque les attaquants, après avoir compromis la console, ont utilisé sa fonctionnalité de contrôle à distance intégrée pour atteindre les terminaux gérés, y compris les contrôleurs de domaine, de plusieurs entreprises. C'est précisément cette architecture que l'approche Zero Trust de LogMeIn Resolve vise à dépasser.

Une architecture Zero Trust fonctionne différemment. Chaque commande envoyée à un terminal géré est signée à l'aide de la clé privée du technicien. Or, cette clé ne quitte jamais l'appareil du technicien. Le terminal vérifie la signature avant d'exécuter chaque action. Un serveur backend compromis ne peut pas envoyer de commandes malveillantes, car il n'a jamais eu accès à la clé privée : le backend ne détient que la clé publique, et la clé privée ne peut pas être récupérée à l'aide de la clé publique. Toute commande pour laquelle la vérification de la signature échoue est rejetée au niveau de l'appareil, sans être exécutée.

David Bisztrai, vice-président en charge de l'ingénierie pour la gamme de produits LogMeIn chez GoTo, l'explique ainsi : « Imaginez un grand coffre-fort dans une banque. Dans un système traditionnel, les attaquants creusent un tunnel, et une fois à l'intérieur, ils trouvent le véritable trésor, à savoir les terminaux. Le backend communique avec l’appareil, l’appareil lui accorde sa confiance et exécute toutes les commandes reçues. Notre architecture Zero Trust part d'une hypothèse simple : quelqu'un finira par creuser un tunnel vers notre coffre-fort. Mais ce jour-là, il n'y aura pas de trésor. Il y aura des milliers de petits casiers, et chacun ne peut être ouvert qu'avec une clé de signature détenue par l'utilisateur, et non par nous. Même si vous accédez au coffre-fort, il vous est impossible d’ouvrir quoi que ce soit. »

Il s'agit d'une question de conception, non de correctif. Aucun correctif d'urgence ne modifie le modèle sur lequel la solution de votre fournisseur repose.

Posez cette question à votre fournisseur : « Si toute votre infrastructure était compromise, qu'est-ce qui empêcherait un attaquant d'utiliser votre plateforme pour accéder à mes terminaux gérés ? »

La rapidité compte. La rigueur compte encore plus. Ces deux aspects sont distincts, et la véritable source de risque réside dans l'écart entre les deux.

Un correctif qui neutralise le vecteur d'attaque signalé tout en laissant un point adjacent vulnérable peut donner une fausse impression que le problème est résolu. Les correctifs de suivi pour des vulnérabilités RMM sont courants dans le secteur, et l'incident N-able n'en est qu'un exemple. Ici, les attaquants ont exploité un nouveau vecteur lié à la correction précédente.

Les attaquants n'ont pas besoin d'identifier une nouvelle vulnérabilité. Il leur suffit que le correctif du fournisseur soit incomplet.

La question n'est pas seulement « à quelle vitesse mettez-vous en place le correctif ? » mais « comment vérifiez-vous que la correction est réellement complète ? ».

Posez cette question à votre fournisseur : « À quand remonte la dernière fois où vous avez publié un correctif de suivi pour une vulnérabilité que vous pensiez déjà résolue, et qu'est-ce que votre processus de test n'a pas détecté lors de la première correction ? »

Il s'agit autant d'une question de logistique que de sécurité. C'est la question que la plupart des MSP ne se posent qu'une fois le correctif publié depuis une semaine, alors que la moitié de leurs serveurs en autohébergement restent exposés.

Pour les déploiements hébergés dans le cloud, les fournisseurs appliquent les correctifs de sécurité de façon centralisée : de nombreux utilisateurs n'en ont même pas conscience. Pour les déploiements sur site, cette responsabilité vous incombe.

L'incident N-able a permis de constater concrètement ce problème. Selon la télémétrie de Huntress sur sa propre base de partenaires et d’utilisateurs, plus de la moitié des serveurs N-central atteignables hébergés dans le cloud demeuraient non corrigés le premier jour suivant la publication du correctif N-able. Lors de la mise à jour suivante, l'application des correctifs dans le cloud avait en grande partie comblé le retard, mais près de trois serveurs sur dix atteignables en autohébergement n'étaient pas encore corrigés.

« Le retard de correctif sur le terrain n'est pas qu'une simple erreur à la marge : dix ou vingt pour cent des appareils les plus lents ne sont jamais parfaitement mis à jour, et c'est précisément cette tranche que les attaquants visent », explique Steve Shattuck, vice-président des écosystèmes de partenaires mondiaux chez GoTo.

Posez cette question à votre fournisseur : « Lorsqu'un correctif de sécurité critique est déployé, combien de vos utilisateurs utilisent encore une version vulnérable 48 heures après ? Comment pouvez-vous en avoir la certitude ? »

Le chiffrement est une exigence fondamentale. Ce qui importe le plus, c'est que la plateforme applique des contrôles d'autorisation, conserve une trace d'audit et offre à l'utilisateur un véritable contrôle sur son propre appareil. La véritable distinction entre les fournisseurs réside dans ce qui se passe au-delà du simple chiffrement des sessions.

L'accès sans surveillance doit faire l'objet d’une vigilance particulière. Comment la configuration est-elle réalisée ? Qui l'approuve ? Qui peut la révoquer ? Ce sont ces questions qui déterminent votre niveau d'exposition, ainsi que votre capacité à regarder un client dans les yeux et à lui expliquer dans quelle mesure ses systèmes sont accessibles.

Posez ces questions à votre fournisseur : « Un utilisateur final peut-il révoquer lui-même l'accès à distance sans surveillance, sans passer par le MSP ? Où cela est-il documenté et indiqué à l'utilisateur ? »

Il y a une différence entre un fournisseur qui affirme « nous prenons la sécurité au sérieux » et un autre qui détient des certifications ayant nécessité un audit indépendant pour en attester. Dans le premier cas, ce ne sont que des mots. Dans le second, il y a des preuves.

Voici les certifications à privilégier : ISO/IEC 27001:2022, SOC 2 Type II, BSI C5. Elles constituent une validation externe, vérifiée par audit, des contrôles de sécurité, et non une autoévaluation réalisée par le fournisseur lui-même. Des tests d'intrusion externes, réalisés par des cabinets indépendants, sont de précieuses garanties complémentaires, alors que de nombreux fournisseurs y renoncent.

Posez ces questions à votre fournisseur : « Quelles certifications détenez-vous et à quelle date ont-elles fait l'objet d'un audit pour la dernière fois ? Effectuez-vous des tests d’intrusion externes et pouvez-vous en préciser la portée ? »

Aucun fournisseur ne peut promettre qu'aucun incident ne surviendra. Et nous ne faisons pas exception. La question importante n'a jamais été « ce fournisseur a-t-il déjà rencontré un problème ? » mais bien « quelle disposition architecturale a-t-il mise en place pour limiter les conséquences lorsqu'un incident survient ? ».

Un modèle Zero Trust isole cryptographiquement l'accès au terminal d'une compromission du back-end, ce qui le rend plus robuste au niveau structurel. Non pas parce qu'il empêche toute attaque, mais parce qu'il évite qu'une catégorie d'attaque ne se transforme en réaction en chaîne catastrophique. Il s'agit d'un élément de conception, qui est présent ou non.

LogMeIn Resolve repose sur ce modèle, précisément parce que notre équipe d'ingénierie avait anticipé que les plateformes RMM deviendraient des cibles stratégiques sur la chaîne d'approvisionnement. Le récent incident N-central rappelle l’importance de cette approche architecturale.

Si vous utilisez actuellement un RMM fonctionnant selon un modèle de confiance serveur classique, vous devriez poser ces six questions dès cette semaine, et non lors de votre prochain renouvellement.