NordVPN a démenti les récentes allégations de fuite, affirmant que les données prétendument dérobées étaient des informations factices provenant d’un environnement de test isolé d’un tiers.
L’entreprise a déclaré qu’aucune donnée client, aucun système de production et aucun identifiant actif n’avaient été compromis.
« Comme il s’agissait d’un test préliminaire et qu’aucun contrat n’a jamais été signé, aucune donnée client réelle, aucun code source de production ni aucun identifiant sensible actif n’ont jamais été téléversés dans cet environnement », a déclaré l’entreprise dans un communiqué adressé à Bleeping Computer.
Ce qui s’est réellement passé lors de l’incident NordVPN
L’incident a commencé lorsqu’un acteur malveillant utilisant le pseudonyme 1011 a affirmé sur un forum de piratage avoir exfiltré plus de 10 bases de données depuis un serveur de développement de NordVPN.
L’acteur a allégué que les données avaient été obtenues en forçant par force brute un système mal configuré et qu’elles comprenaient des ressources de développement sensibles, telles que des clés d’API Salesforce et des jetons Jira.
Même si aucune donnée client n’était alors mise en cause, les allégations concernant des systèmes de développement internes peuvent néanmoins présenter un risque.
Même des allégations de fuite non vérifiées peuvent entraîner une atteinte à la réputation, soulever des questions réglementaires et de conformité, et contraindre les équipes de sécurité à détourner des ressources vers la réponse à incident et les opérations de validation.
NordVPN affirme que son enquête interne a établi que les données ne provenaient ni de son infrastructure de production ni de son infrastructure de développement.
Les informations exposées provenaient plutôt d’un environnement temporaire créé plusieurs mois auparavant lors de l’essai d’une plateforme de tests automatisés tierce.
Selon l’entreprise, cet environnement servait uniquement à une évaluation préliminaire et n’a jamais été connecté aux systèmes internes ni aux réseaux de production de NordVPN.
Comme l’essai n’a pas donné lieu à la signature d’un contrat, NordVPN a déclaré qu’aucune donnée client réelle, aucun code source de production ni aucun identifiant actif n’avaient jamais été téléversés.
Les bases de données ne contenaient, semble-t-il, que des données factices et des artefacts de test destinés à valider les fonctionnalités, et non de véritables informations opérationnelles.
NordVPN a également indiqué avoir contacté le fournisseur tiers afin de comprendre comment l’environnement de test avait été consulté et d’empêcher toute exposition similaire à l’avenir.
L’entreprise a déclaré qu’aucun élément ne prouvait que des attaquants avaient compromis les systèmes de production de NordVPN ou accédé à des identifiants actifs.
Alors que l’acteur malveillant a présenté l’incident comme une attaque réussie contre un serveur de NordVPN, l’entreprise maintient que l’environnement concerné était externe, isolé et sans lien avec son infrastructure centrale.
Combler les failles de sécurité dans les environnements de test
Les incidents impliquant des environnements de test et de développement révèlent souvent des lacunes de gouvernance plutôt que des défaillances des contrôles de sécurité fondamentaux.
Même si ces systèmes sont généralement isolés de la production, ils peuvent néanmoins créer un risque lorsque les identifiants, les données ou les accès ne sont pas gérés avec suffisamment de rigueur.
Réduire ce risque exige de considérer les environnements hors production comme des actifs de sécurité à part entière, en leur appliquant la même visibilité et les mêmes contrôles qu’aux systèmes en production.
- Isolez et contrôlez strictement les environnements de test afin de garantir leur séparation complète des systèmes de production et l’absence de véritables identifiants ou données clients.
- Réduisez les risques liés aux identifiants dans les workflows de développement en utilisant des jetons à durée de vie courte et à privilèges minimaux et en imposant une authentification forte, comme l’authentification multifacteur (MFA) et le SSO.
- Maintenez une visibilité continue sur les outils et environnements tiers en dressant l’inventaire de toutes les plateformes d’assurance qualité, de test et d’automatisation.
- Appliquez une surveillance et une journalisation aux systèmes hors production afin de détecter rapidement les accès non autorisés, les tentatives de force brute ou les comportements anormaux.
- Utilisez par défaut des données synthétiques ou masquées et interdisez les importations manuelles de données d’entreprise ou de clients réelles dans les environnements de test.
- Formalisez les processus de gouvernance et de démantèlement afin que les environnements temporaires soient examinés, sécurisés et désactivés rapidement à l’issue des essais ou des évaluations.
Ensemble, ces contrôles réduisent le risque que les environnements de test deviennent des surfaces d’attaque involontaires.
Quand le risque fournisseur devient un risque d’entreprise
L’incident survient alors que la sécurité des fournisseurs, les risques liés aux tiers et les chaînes logicielles font l’objet d’une attention accrue.
Les acteurs malveillants ciblent de plus en plus les chaînes de développement, les plateformes de test et les prestataires de services externes, qui constituent des points d’entrée plus faciles dans des organisations par ailleurs bien sécurisées.
Par conséquent, même des expositions limitées ou concernant des systèmes hors production peuvent rapidement attirer l’attention, amplifier les inquiétudes et soulever des questions plus générales sur la gouvernance et la supervision.
À mesure que les outils tiers et les systèmes hors production deviennent des points d’entrée fréquents, les approches zero trust qui vérifient chaque demande d’accès deviennent de plus en plus essentielles pour réduire les risques liés à la chaîne d’approvisionnement.