Kaseya VSA et le fossé de responsabilité dans les services gérés

Résumé

• Des attaquants ont exploité des serveurs Kaseya VSA sur site exposés sur Internet le 2 juillet 2021, contourné l'authentification et utilisé des fonctions légitimes de gestion à distance pour distribuer le ransomware REvil. Les informations publiques ne montrent pas que la version logicielle ou le dépôt de code de Kaseya ait été altéré.
• Kaseya traitait déjà une divulgation coordonnée portant sur sept vulnérabilités de VSA. L'entreprise avait corrigé plusieurs problèmes et déployé les correctifs correspondants dans son environnement SaaS, mais des systèmes sur site vulnérables restaient exposés lorsque l'attaque a commencé. La question de responsabilité non résolue n'est pas de savoir si Kaseya a ignoré les chercheurs; ces derniers affirment que non. Il s'agit de déterminer si la rapidité de correction, les contrôles provisoires, l'avertissement privé des clients et la réduction de l'exposition ont été à la hauteur de l'autorité exceptionnelle du produit.
• Le nombre direct de victimes, environ 50 à 60 clients Kaseya selon le décompte ultérieur de l'entreprise, sous-estime l'événement opérationnel. Beaucoup étaient des fournisseurs de services gérés (MSP), de sorte que le ransomware a atteint entre 800 et 1 500 entreprises en aval, selon l'estimation de Kaseya. Une plateforme d'administration à distance a transformé un plan de contrôle compromis en de multiples défaillances de continuité locales.
• La responsabilité est à plusieurs niveaux. Kaseya contrôlait la sécurité du produit, la gestion de la divulgation, la livraison des correctifs et la communication de crise. Les MSP contrôlaient l'exposition sur Internet, la segmentation, la conception des sauvegardes, la surveillance et la reprise pour leurs clients. Les petites entreprises clientes conservaient des obligations de continuité et d'approvisionnement, mais manquaient souvent de connaissances significatives sur l'outil sous-jacent. Les agences gouvernementales ont contribué à l'alerte, à la coordination de la réponse, aux enquêtes et aux poursuites sans éliminer la nécessité de contrôles privés plus solides.

L'incident était une attaque via une relation de confiance

L'expression « attaque de la chaîne d'approvisionnement » est utile ici, mais seulement si elle décrit le chemin de l'autorité plutôt qu'une compromission présumée du système de construction. L'aperçu de l'incident de Kaseya indique que les attaquants ont exploité des vulnérabilités zero-day dans le produit VSA sur site, contourné l'authentification, exécuté des commandes arbitraires, puis utilisé les fonctionnalités standard de VSA pour déployer le ransomware sur les terminaux gérés. Il précise également qu'il n'y avait aucune preuve que le code source de VSA ait été modifié de manière malveillante.

Cette distinction est essentielle pour la responsabilité. Les attaquants n'ont pas eu à convaincre chaque cabinet dentaire, cabinet comptable, restaurant, détaillant ou entreprise de services locale d'exécuter un programme inconnu. Ils n'ont pas non plus eu besoin d'introduire un paquet empoisonné dans le pipeline de développement de Kaseya et d'attendre une version signée par l'éditeur. Ils ont compromis certains serveurs VSA déjà autorisés à administrer les machines des clients. L'action malveillante est arrivée avec l'autorité pratique de la gestion informatique courante.

VSA est un logiciel de surveillance et de gestion à distance (RMM). Un MSP peut l'utiliser pour inventorier les appareils, déployer des logiciels, exécuter des scripts, automatiser la maintenance et résoudre les incidents dans de nombreux environnements clients. Ces capacités réduisent le coût unitaire du support informatique. Elles permettent à une seule équipe technique de maintenir des systèmes pour des entreprises qui ne pourraient pas employer économiquement des spécialistes équivalents en interne. La même conception crée également un canal de distribution privilégié.

Si un acteur malveillant prend le contrôle du serveur VSA, l'avantage d'échelle change de camp.

Huntress, qui a reçu les premiers rapports de ses partenaires MSP touchés, a réduit la chaîne d'attaque observée à un contournement d'authentification, un téléversement de fichier arbitraire et une exécution de code. Ses enquêteurs ont rapporté que les attaquants ont téléversé une charge utile encodée et un second fichier qui a aidé à supprimer les journaux et les comptes administratifs, puis ont utilisé des procédures de base de données pour planifier la livraison aux terminaux.

Les propres indicateurs de Kaseya répertoriaientagent.crt, son exécutable décodé, et la charge utile REvil, ainsi qu'une séquence de requêtes web contre les serveurs VSA compromis.

Sophos a observé indépendamment les conséquences du côté des terminaux. Son compte-rendu technique contemporain décrit les serveurs VSA exposés sur Internet comme la cible initiale et l'autorité normale de déploiement de logiciels du produit comme la voie d'accès aux environnements clients. Les premiers décomptes des intervenants variaient parce que différentes entreprises de sécurité voyaient différentes populations, et parce que la distinction entre un client VSA compromis, un MSP, un client de MSP et une machine chiffrée n'était pas systématiquement maintenue.

La convergence technique importe plus que tout total précoce: la gestion à distance privilégiée a été transformée en un mécanisme de propagation.

Voilà pourquoi l'événement ne devrait pas être réduit à une « mise à jour » qui a mal tourné. Certaines télémétries de terminaux et certains articles de presse ont décrit le ransomware comme une mise à jour malveillante parce qu'il est arrivé via le logiciel utilisé pour pousser des changements. Opérationnellement, cette description avait du sens pour une victime. Pour l'analyse du contrôle, cependant, le chemin était plus révélateur. Kaseya n'a pas autorisé une mise à jour normale de l'éditeur contenant REvil.

Les attaquants ont pris le contrôle d'instances VSA exploitées par les clients et ont fait en sorte que ces instances exécutent une tâche administrative apparemment légitime. L'objet compromis était la relation de confiance déléguée.

Une divulgation coordonnée a rencontré une échéance criminelle

La chronologie pré-incident résiste à un simple récit de négligence. L'Institut néerlandais pour la divulgation des vulnérabilités (DIVD) a commencé à étudier VSA le 1er avril 2021, a scanné les installations exposées sur Internet à partir du 2 avril et a informé Kaseya le 6 avril. Sa divulgation limitée indique que la réponse de Kaseya a été rapide et engagée. Kaseya a écouté, a publié des correctifs et a permis aux chercheurs de valider les correctifs en cours de développement. DIVD a explicitement comparé cette réponse favorablement à son expérience avec certains autres éditeurs.

La divulgation couvrait sept vulnérabilités, pas une seule faille indifférenciée. DIVD a enregistré un problème de téléversement de fichier non authentifié corrigé en avril, trois autres problèmes corrigés en mai, et des travaux en cours sur une fuite d'informations d'identification et une faille de logique métier, du cross-site scripting et un contournement d'authentification à deux facteurs. Son dossier de cas maintenu indique que la version 9.5.7 a atteint l'environnement SaaS de Kaseya le 26 juin avec des correctifs pour CVE-2021-30116 et CVE-2021-30119.

Il enregistre également que toutes les versions VSA sur site restaient soumises à la recommandation du cas et que ces systèmes devaient rester hors ligne jusqu'à ce que Kaseya fournisse un correctif et des instructions de redémarrage après l'attaque.

DIVD a ensuite publié des descriptions complètes des vulnérabilités. L'entrée la plus importante liée à l'incident, CVE-2021-30116, concernait l'accès non authentifié aux informations d'identification associées au processus de téléchargement du client VSA et la possibilité de transformer ces informations en une session. L'entrée de la National Vulnerability Database indique maintenant que le problème a été exploité activement, a été corrigé avant la version 9.5.7 et a ensuite été ajouté au catalogue des vulnérabilités exploitées connues de la CISA.

Les informations publiques permettent donc quatre constats, mais elles ne confirment pas toutes les conclusions qui leur sont souvent associées.

Premièrement, Kaseya connaissait l'existence de graves faiblesses de VSA avant le 2 juillet. Deuxièmement, l'entreprise avait corrigé plusieurs des faiblesses signalées et travaillait activement avec les chercheurs. Troisièmement, au moins une vulnérabilité utilisée lors de l'attaque faisait partie de celles divulguées en privé. Quatrièmement, la correction équivalente pour les systèmes sur site n'était généralement pas entre les mains des clients avant le début de l'exploitation criminelle.

Ce que les informations ne montrent pas est tout aussi important. Il n'y a pas de registre interne des risques problème par problème, d'estimation technique, de trace d'escalade exécutive ou de journal de décision expliquant comment Kaseya a hiérarchisé les failles restantes. Il n'y a pas de liste publiée des contrôles provisoires exigés en privé des clients sur site avant qu'un correctif soit disponible.

DIVD a remis à Kaseya une liste des hôtes VSA identifiés le 4 juin, mais les informations publiques n'établissent pas quels opérateurs ont été contactés, ce qui leur a été dit, quand ils ont répondu, ou si Kaseya pouvait vérifier que les interfaces à risque avaient été restreintes. Il n'y a également aucune preuve que Kaseya ait divulgué les détails de la vulnérabilité aux attaquants. La découverte parallèle est tout à fait plausible, et la source de l'exploitation reste non prouvée publiquement.

Cela crée un standard de responsabilité difficile mais nécessaire. Un éditeur ne devrait pas être condamné simplement parce que des criminels ont exploité une faille pendant une divulgation coordonnée de bonne foi. Les défauts logiciels et la redécouverte par des adversaires ne peuvent être éliminés. Pourtant, le privilège et la portée en aval d'un produit devraient affecter l'urgence de la correction. Pour un serveur d'administration à distance exposé sur Internet capable d'exécuter des commandes sur de nombreux réseaux clients, un contournement d'authentification critique est également une urgence de concentration de risque.

Une file de correctifs conçue selon la sévérité ordinaire d'une application peut être trop lente pour un plan de contrôle avec ce rayon de destruction.

Le dilemme de la divulgation était réel. Nommer publiquement une voie d'authentification non corrigée aurait pu accélérer l'exploitation. Un avertissement général aux clients sans suffisamment de détails aurait pu néanmoins orienter les attaquants vers une classe de cibles étroite tout en laissant les opérateurs incertains sur les changements à apporter. DIVD a défendu une divulgation limitée précisément pour cette raison. Mais le secret ne doit pas signifier l'inactivité.

Un éditeur peut contacter en privé les clients exposés identifiables, exiger un accès de gestion derrière un VPN, fournir des règles de filtrage temporaires, augmenter la télémétrie, restreindre les fonctions des serveurs et définir un seuil de migration ou d'arrêt d'urgence. La question sans réponse est de savoir dans quelle mesure cela s'est produit avant le 2 juillet, et non si une preuve de concept publique aurait dû être publiée.

2 juillet: détection, arrêt et confinement incomplet

Le compte-rendu officiel de Kaseya du 5 juillet indique que des sources internes et externes l'ont alertée d'une attaque potentielle vers 14 heures, heure de l'Est, le 2 juillet, et qu'elle a agi dans l'heure. L'entreprise a arrêté son infrastructure SaaS VSA et a commencé à dire aux clients sur site d'éteindre leurs propres serveurs. Sophos a enregistré une prise de conscience de la campagne à 18h00 UTC, soit la même période approximative. Huntress a décrit trois rapports de MSP arrivant à moins d'une demi-heure d'intervalle avant que le lien commun avec VSA ne devienne clair.

La décision d'arrêt mérite d'être saluée. Kaseya n'avait aucune preuve que les clients SaaS étaient compromis, mais elle a retiré le service hébergé par précaution. Elle a également fait appel à Mandiant, contacté le FBI et la CISA, diffusé des indicateurs et publié un outil de détection de compromission le 3 juillet. La déclaration publique du FBI a renforcé l'instruction d'arrêter les serveurs VSA et de signaler les compromissions.

Le guide conjoint CISA-FBI sur l'incident a ajouté des mesures immédiates: utiliser l'outil de détection, appliquer l'authentification multifacteur, restreindre les communications RMM à des paires IP connues, placer les interfaces d'administration derrière un VPN ou un réseau de pare-feu dédié, conserver des sauvegardes hors ligne récupérables et appliquer le principe du moindre privilège.

Ces actions ont limité les dégâts supplémentaires, mais « dans l'heure » ne doit pas être confondu avec un confinement complet. Kaseya pouvait arrêter son propre service SaaS. Elle ne pouvait pas éteindre directement tous les serveurs exploités par les clients. Une instance VSA sur site restait dangereuse jusqu'à ce que le MSP reçoive le message, lui fasse confiance, atteigne la bonne personne un vendredi de week-end férié et termine l'arrêt. Toute procédure malveillante déjà préparée pour exécution devait également être identifiée et effacée avant le redémarrage. La capacité centralisée avait permis un déploiement rapide;

le confinement dépendait d'un relais humain distribué.

La chronologie publique commence également à l'alerte, pas à la première exploitation. Kaseya n'a pas publié l'heure de la première requête malveillante sur l'ensemble des serveurs affectés, la première anomalie de télémétrie interne, le premier événement de chiffrement chez un client, ou l'intervalle entre ces signaux. Elle n'a pas non plus divulgué si sa propre surveillance pouvait distinguer une procédure de masse autorisée d'une procédure créée via une session volée ou fabriquée. Sans ces horodatages, on peut juger la réponse exécutive rapportée après confirmation, mais pas la sensibilité de la détection préventive.

L'expression de Kaseya « couper l'accès au logiciel » était également plus large que la réalité opérationnelle. VSA hébergé est devenu indisponible par l'action de Kaseya. VSA sur site appartenait aux environnements des clients et nécessitait une action du client. La différence est plus qu'une question de formulation. Elle révèle la responsabilité partagée des logiciels d'entreprise auto-hébergés: l'éditeur contrôle le code et la connaissance de la correction; l'opérateur contrôle l'instance en cours d'exécution; les clients en aval peuvent ne pas savoir que le produit de l'une ou l'autre partie gère leurs machines.

Le multiplicateur se trouvait entre l'éditeur et la petite entreprise

Kaseya a d'abord souligné que seule une petite fraction de sa base de clients directs était compromise. Sa déclaration du 5 juillet citait environ 50 clients sur plus de 35 000. La page d'incident ultérieure indiquait moins de 60 clients directs et moins de 1 500 entreprises en aval. Un rapport SOC 3 ultérieur a précisé 57 clients sur site. Reuters a rapporté séparément l'estimation du directeur général de 800 à 1 500 entreprises touchées, tout en notant que Kaseya trouvait difficile d'obtenir un total précis car les entreprises touchées étaient des clients de ses clients.

Tous ces chiffres peuvent être vrais dans leurs définitions. Ils décrivent différents niveaux de l'arbre de dépendance. Un client direct de Kaseya peut exploiter un serveur VSA en tant que MSP. Ce MSP peut gérer des dizaines d'entreprises indépendantes. Chaque entreprise peut avoir de nombreux terminaux. Compter 57 instances client compromises ne dit pas grand-chose sur le nombre d'organisations qui ont perdu des ordinateurs, des capacités de point de vente, des fichiers ou du temps de personnel. Inversement, une entreprise en aval associée à un MSP touché n'a pas nécessairement été chiffrée sur tous les appareils.

Un reporting responsable doit préciser le dénominateur.

Le fait économique le plus important est que VSA a aidé à mutualiser le travail spécialisé. Les petites entreprises achètent des services gérés parce que le personnel informatique interne est coûteux, intermittent et difficile à recruter. Un MSP répartit les ingénieurs, les outils de surveillance, l'automatisation et le pouvoir d'achat sur un portefeuille. Cet arrangement peut améliorer la sécurité. Un fournisseur compétent peut corriger plus rapidement, surveiller plus longtemps et récupérer de manière plus fiable qu'une entreprise de cinq personnes seule.

La mutualisation rend également le risque opérationnel corrélé. Une centaine de petites entreprises peuvent sembler diversifiées par secteur et par géographie, mais si un seul MSP les gère toutes via une seule plateforme administrative, leurs modes de défaillance technique se chevauchent. Le portefeuille présente une exposition commune cachée. Une vulnérabilité au niveau de la plateforme peut anéantir l'hypothèse selon laquelle les entreprises locales échouent indépendamment.

Cette corrélation est rarement visible dans un contrat de service ordinaire. Un petit client peut connaître le nom de son MSP mais pas le produit de gestion à distance, le modèle d'hébergement, l'exposition de l'interface de gestion, les sous-traitants, l'architecture de sauvegarde ou la conception de l'accès privilégié. Même si le produit est nommé, il est peu probable que le client ait l'expertise ou le pouvoir de négociation pour l'auditer. La partie qui subit l'interruption peut donc être à deux pas de la partie qui prend la décision de sécurité logicielle.

C'est le fossé de responsabilité au sein des services gérés. La délégation déplace le travail technique vers des spécialistes, mais elle ne transfère pas automatiquement toutes les pertes, obligations légales, plaintes des clients, obligations salariales ou stocks perdus. La PME fait toujours face à ses employés et à ses clients lorsque les systèmes s'arrêtent. Le MSP fait face au travail de restauration et aux engagements de service contractuels. L'éditeur de logiciels fait face à la correction du produit et à sa réputation.

À moins que les contrats et la conception de la reprise n'attribuent délibérément ces conséquences, la partie la plus exposée opérationnellement peut aussi être la moins informée.

La Suède a rendu la dépendance visible

L'exemple public le plus clair n'était pas un bureau de Kaseya ou un centre d'opérations réseau d'un MSP. C'était une caisse de supermarché. Reuters a rapporté que la chaîne d'épicerie suédoise Coop a fermé tous ses 800 magasins le 3 juillet parce que les systèmes de paiement affectés ne pouvaient pas fonctionner. La chaîne a déclaré qu'un outil de caisse mis à jour à distance avait été touché. Des rapports ultérieurs ont décrit un chemin d'approvisionnement en couches: Coop dépendait de systèmes de paiement gérés par Visma Esscom, qui à son tour utilisait Kaseya.

Ce n'était pas une défaillance de l'approvisionnement alimentaire au sens physique. Les rayons, les bâtiments, le personnel et les produits existaient toujours. L'incapacité à traiter les paiements a transformé une compromission d'administration informatique en un événement de continuité du commerce de détail. Certains magasins ont ensuite utilisé une application alternative de scan et de paiement, mais les techniciens ont également dû se rendre sur place et restaurer les machines de paiement à partir de sauvegardes.

Le rapport de reprise de Reuters a saisi l'asymétrie opérationnelle: l'administration à distance avait évolué efficacement avant l'incident, tandis que la reprise pouvait nécessiter un travail physique sur de nombreux sites.

Coop était une grande organisation en aval très visible. Le même mécanisme est plus rude pour une petite entreprise avec moins d'options. Un cabinet comptable peut reporter certains travaux, mais peut manquer des échéances de paie ou de déclaration. Un cabinet dentaire peut conserver le personnel clinique et l'équipement mais perdre la planification, l'accès à l'imagerie ou les flux de facturation. Un restaurant peut avoir de la nourriture et du personnel mais être incapable d'accepter des paiements normaux. Un fabricant local peut perdre l'expédition, les étiquettes ou les systèmes de support machine.

Ces exemples ne prouvent pas que chacun s'est produit lors de cet incident; ils montrent pourquoi le chiffrement des terminaux a une signification économique différente dans un portefeuille de PME par rapport à ce que suggère un simple décompte d'appareils.

L'effet sur les revenus commence immédiatement, tandis que les coûts de reprise technique s'y ajoutent. Le personnel peut être payé pendant qu'il est inactif. Les propriétaires peuvent avoir à communiquer avec les clients sans données de contact fiables. Les techniciens MSP travaillent de longues heures, triant souvent les clients par sécurité, revenus et état des sauvegardes. La notification à l'assurance, la préservation médico-légale, les conseils juridiques et le matériel de remplacement ajoutent des dépenses.

Un décrypteur peut restaurer des fichiers, mais il ne récupère pas les ventes déjà perdues, le temps du personnel déjà consommé ou la confiance déjà endommagée.

L'incident a ainsi exposé une externalité de continuité de service. Le prix du produit de Kaseya et les frais de service du MSP ont été négociés en amont. Une partie des conséquences négatives est apparue chez des entreprises en aval qui n'ont pas choisi l'architecture VSA et n'ont peut-être jamais vu le nom de Kaseya. La discipline de marché est faible lorsque le porteur ultime du risque ne peut pas observer le contrôle pertinent et n'a aucun moyen pratique de le tarifer.

L'arrêt sécurisé est devenu sa propre panne

L'arrêt préventif du SaaS a empêché une voie de propagation possible, mais il a également supprimé un service de gestion pour des clients que Kaseya disait ne pas être compromis. C'était le bon compromis dans une incertitude aiguë. C'était néanmoins une panne, et elle a duré bien plus longtemps que l'heure de réponse initiale.

La chronologie des mises à jour de l'incident conservée par Kaseya enregistre des objectifs de restauration changeants. Un déploiement SaaS prévu a rencontré un problème d'infrastructure bloquant le 6 juillet. Les délais ont été réinitialisés le 7 juillet. L'entreprise a finalement commencé à restaurer le SaaS et a publié le correctif sur site le 11 juillet; elle a signalé que tous les clients SaaS étaient en ligne au début du 12 juillet. Cela signifie que les clients hébergés non affectés ont perdu la disponibilité de VSA pendant environ neuf jours parce que le service ne pouvait pas encore être déclaré sûr.

La séquence ne doit pas être tournée en dérision comme un simple retard. Redémarrer un plan de contrôle privilégié après une exploitation active nécessite plus que de changer une ligne de code. Kaseya a dû enquêter sur le chemin d'accès, créer et valider une version de sécurité, rechercher des compromissions, se coordonner avec le gouvernement et les spécialistes de la réponse aux incidents, renforcer l'infrastructure, préparer les opérateurs et éviter de réactiver des procédures malveillantes.

Ses mises à jour montrent qu'elle a supprimé certaines fonctionnalités peu utilisées du retour initial, ajouté des vérifications et révisé les manuels opérationnels à mesure que les commentaires des clients révélaient des problèmes pratiques.

En même temps, l'arrêt prolongé est une preuve de la capacité de reprise. Une plateforme peut contenir une vulnérabilité rapidement en devenant indisponible, tout en laissant les clients sans administration essentielle. La haute disponibilité et la reprise sécurisée sont des propriétés distinctes. Si le renforcement d'urgence, la vérification de l'état propre ou le redémarrage progressif ne peuvent pas être effectués rapidement, les clients ont besoin d'un mode opérationnel qui ne dépend pas du plan de contrôle.

La charge de redémarrage sur site était considérable. La chronologie de Kaseya exigeait des opérateurs qu'ils isolent le serveur, exécutent l'outil de détection, corrigent le système d'exploitation, examinent la configuration IIS, déploient un agent de sécurité des terminaux, effacent les procédures en attente, installent la version de sécurité VSA et suivent une liste de contrôle finale. Son guide de renforcement post-incident exigeait un accès entrant restreint, une authentification plus forte et d'autres changements environnementaux. C'étaient des contrôles sensés.

Leur introduction d'urgence montre également que le fonctionnement sécurisé du produit dépendait de la configuration en dehors de l'application et de la capacité du MSP à exécuter un manuel complexe sous pression.

Pour un MSP mature, neuf jours sans la plateforme RMM habituelle peuvent signifier basculer vers d'autres outils distants, des correctifs manuels, une coordination téléphonique, des scripts et des visites sur site. Pour un fournisseur moins mature, la plateforme peut être devenue le modèle opérationnel lui-même. Si l'inventaire des actifs, les informations d'identification, les procédures, les contacts clients et les instructions de reprise sont tous plus facilement accessibles via le système indisponible, la perte de l'outil nuit également à la réponse à sa perte.

Le décryptage était une aide, pas une restauration

Kaseya a annoncé le 22 juillet qu'elle avait obtenu un décrypteur universel d'un tiers et travaillait avec Emsisoft pour aider les victimes. Elle a précisé plus tard que l'outil était efficace pour les fichiers entièrement chiffrés et a déclaré qu'elle n'avait pas payé ni négocié de rançon pour l'obtenir. Ces déclarations apparaissent dans la même chronologie d'incident, et les informations publiques n'établissent pas la source originale de la clé.

Le décrypteur était précieux. Il pouvait réduire la perte de données permanente pour les organisations qui avaient encore des systèmes chiffrés et n'avaient pas terminé une autre voie de reprise. Il était également disponible près de trois semaines après l'attaque. À ce moment-là, certaines entreprises avaient déjà restauré à partir de sauvegardes, reconstruit des appareils, changé de systèmes ou autrement absorbé la partie difficile de la reprise. La rétrospective de Huntress a noté la réaction mitigée: pour certaines victimes, la clé a été une percée;

pour d'autres, elle est arrivée après que la restauration manuelle ou d'autres décisions aient déjà été prises.

Le décryptage n'équivaut pas à un retour en service fiable. Un fichier récupéré peut être intact, mais l'environnement qui a produit la compromission doit encore être nettoyé et corrigé. Les informations d'identification et les relations administratives peuvent devoir être réinitialisées. Les journaux peuvent être incomplets parce que les attaquants ont tenté de les supprimer. Les terminaux restaurés doivent être vérifiés avant d'être reconnectés. Les arriérés, les appels des clients, le rapprochement financier et le travail retardé survivent à l'événement cryptographique.

Cette distinction est importante pour la manière dont les éditeurs décrivent la correction. Une clé universelle est un atout de réponse aux incidents, pas un remboursement de l'interruption d'activité. Une sauvegarde est un contrôle de disponibilité des données, pas la preuve que le processus utilisant les données peut reprendre dans son délai commercial. Un correctif installé ferme les chemins techniques connus, pas le fossé de gouvernance qui a permis à un service privilégié de devenir un point de défaillance commun.

La responsabilité appartient aux contrôles, pas aux slogans

Les attaquants sont responsables du crime. Les autorités publiques ont ensuite rendu cette attribution plus concrète. L' annonce de mise en accusation du ministère américain de la Justice de novembre 2021 alléguait que Yaroslav Vasinskyi avait provoqué le déploiement du code REvil via les fonctionnalités du produit Kaseya sur les terminaux des clients. Le compte-rendu de l'opération GoldDust d'Europol a également lié un suspect à l'attaque de Kaseya et au chiffre allant jusqu'à 1 500 entreprises en aval.

En 2024, après un plaidoyer de culpabilité pour un acte d'accusation en 11 chefs, un tribunal fédéral a condamné Vasinskyi à 13 ans et 7 mois de prison pour ses activités plus larges liées à REvil, selon le ministère de la Justice.

La responsabilité pénale ne règle pas la responsabilité opérationnelle. La gouvernance de la sécurité pose une question différente: quelle partie contrôlait une mesure de protection qui aurait raisonnablement pu empêcher, détecter, limiter ou raccourcir le préjudice? Sur cette base, la responsabilité est répartie mais pas vague.

Kaseya porte la plus grande part de responsabilité au niveau du produit. Elle a conçu et maintenu le logiciel, connaissait les vulnérabilités restantes, contrôlait l'environnement SaaS, a produit les correctifs et comprenait mieux la portée en aval du produit qu'un petit client ne le pouvait. La description positive de la coopération de l'entreprise par DIVD est importante et devrait empêcher une caricature d'inaction totale. Elle ne répond pas à la question de savoir si les objectifs de correction et les protections temporaires de Kaseya étaient adéquats au risque.

Les MSP portent une responsabilité substantielle de déploiement et de continuité. L'exploitation sur site leur a donné le contrôle de l'exposition réseau et du calendrier, même si cela les a laissés dépendants de Kaseya pour la correction du code. Une console d'administration largement ouverte sur Internet a un profil de risque différent de celui d'une console restreinte à un réseau de gestion dédié ou à un VPN. L'authentification multifacteur est importante, mais cette attaque a montré que les vulnérabilités du produit peuvent contourner les hypothèses de connexion sur lesquelles repose l'authentification multifacteur.

La détection indépendante des terminaux, les contrôles d'application, la segmentation du réseau et un moyen de révoquer ou de contenir l'autorité du RMM restent nécessaires.

La responsabilité de la PME est plus étroite mais pas nulle. Externaliser l'informatique n'est pas la même chose qu'externaliser le devoir de l'entreprise de continuer à servir les clients, à payer le personnel, à protéger les dossiers et à communiquer pendant l'interruption. Il est pourtant irréaliste d'exiger qu'un petit client rétro-ingénierie la chaîne d'outils de son MSP.

Son devoir pratique est d'identifier les fonctions critiques de l'entreprise, d'exiger la divulgation des sous-traitants significatifs et des outils privilégiés, de demander des objectifs de reprise, de maintenir des solutions de contournement non numériques lorsque cela est proportionné et de tester si une panne du MSP lui laisse un moyen de fonctionner.

La responsabilité du gouvernement est habilitante et coercitive plutôt qu'opérationnelle. La CISA et le FBI ont diffusé des mesures d'atténuation, se sont coordonnés avec Kaseya et ont encouragé le signalement. L'enquête internationale a finalement abouti à des arrestations et à des poursuites. Ces actions peuvent réduire la liberté des attaquants et aider les victimes, mais aucune agence publique ne peut surveiller chaque file de correctifs d'éditeur ou restaurer chaque caisse locale.

Le rôle durable de l'État est d'établir des canaux de signalement, d'améliorer l'échange de renseignements, de définir des attentes en matière d'approvisionnement, de poursuivre les criminels et de définir des devoirs minimaux lorsque les incitations du marché échouent.

Le contrat devrait exposer l'architecture cachée

L'incident n'a pas créé le concept de responsabilité partagée, mais il a montré à quel point cette expression peut devenir vide lorsque l'architecture sous-jacente est invisible. Un contrat MSP utile devrait convertir la dépendance technique en informations, en autorité et en obligations de reprise mesurables.

Au minimum, le client devrait savoir quels outils de gestion à distance et de sécurité ont un accès privilégié; s'ils sont hébergés par l'éditeur ou exploités par le MSP; quelles interfaces d'administration sont accessibles via Internet; où les journaux d'audit sont conservés; si le fournisseur peut isoler un client du reste; et comment le fournisseur continuera le support essentiel si sa plateforme RMM principale est indisponible. Cela ne nécessite pas la divulgation de détails exploitables à chaque client. Cela nécessite suffisamment d'architecture pour que le client comprenne le risque corrélé.

Les conditions de notification devraient distinguer trois événements: la compromission suspectée du fournisseur ou de l'outil, l'accès confirmé à l'environnement du client et la suspension opérationnelle prise par précaution. Les clients SaaS de Kaseya n'ont pas été signalés comme compromis, mais leur service a été suspendu. Un contrat qui ne déclenche une notification qu'après une compromission confirmée des données du client passe à côté d'un événement de continuité majeur.

Les engagements de reprise nécessitent également plusieurs horloges. Le temps d'accuser réception d'un incident n'est pas le temps de le contenir. Le temps de publier un correctif n'est pas le temps pour un MSP de l'installer. Le temps de décrypter les données n'est pas le temps de reprendre un processus métier. Un accord de service significatif devrait définir des objectifs pour la notification du fournisseur, l'isolation du plan de gestion, la restauration du support à distance critique, le triage des terminaux, la reconstruction propre et le déblayage des arriérés.

Il devrait préciser quelle partie fournit des techniciens lorsque la reprise à distance échoue.

L' avis multinational de 2022 sur la protection des MSP et de leurs clients rend cette répartition explicite. Il recommande que les clients s'assurent que les arrangements contractuels couvrent des contrôles tels que l'accès à distance sécurisé, la surveillance et la journalisation, les plans de réponse aux incidents et de reprise, l'authentification et la gestion des risques de la chaîne d'approvisionnement. Ces directives sont postérieures à l'événement Kaseya et ne constituent pas la preuve d'une obligation contraignante en 2021. C'est une indication utile de ce à quoi une responsabilité partagée mature devrait désormais ressembler.

Les achats doivent également s'interroger sur la concentration. Un fournisseur peut utiliser le même RMM, la même plateforme de sauvegarde, le même fournisseur d'identité et le même agent de sécurité pour chaque client. Cette standardisation fait partie de l'efficacité achetée. Le client doit savoir si une défaillance du plan de contrôle peut désactiver à la fois l'administration et la sauvegarde, si l'accès d'urgence utilise le même système d'identité et si les outils alternatifs sont véritablement indépendants ou simplement un autre module dans la même pile.

La pression sur les prix complique la réponse. Les petites entreprises choisissent les services gérés en partie parce que la redondance est coûteuse. Exiger de chaque MSP qu'il maintienne des plateformes en double et du personnel 24 heures sur 24 pourrait augmenter les coûts au-delà de ce que certains clients peuvent supporter. La responsabilité doit donc être proportionnelle, pas théâtrale. Un fournisseur n'a pas besoin d'une deuxième copie de chaque outil pour prouver sa résilience.

Il a besoin d'un plan de repli documenté pour les fonctions critiques, de sauvegardes testées en dehors de la frontière de confiance du RMM, de contacts clients à jour et d'un plan crédible pour le renfort de main-d'œuvre.

Des contrôles qui peuvent être testés, pas seulement promis

La meilleure question post-incident n'est pas de savoir si un éditeur ou un MSP affirme que la sécurité est importante. C'est de savoir si un évaluateur peut observer un contrôle modifié et le contester. L'événement Kaseya suggère un ensemble pratique de tests.

Réduire l'exposition du plan de gestion.Énumérer chaque serveur RMM et interface d'administration. Montrer quelles adresses peuvent l'atteindre, pourquoi chaque route existe et quand la règle a été examinée pour la dernière fois. L'accès étendu à Internet devrait être une exception avec une propriété explicite. Le placement derrière un VPN seul ne suffit pas si l'identité VPN a un privilège permanent étendu, mais il élimine toute une classe d'accès public non authentifié.

Rendre l'action de masse visible.Une plateforme de gestion à distance devrait distinguer le travail ordinaire d'une commande qui touche des centaines de clients ou de terminaux. Les actions à large diffusion nécessitent une autorisation forte, une origine claire, des limites de débit lorsque c'est opérationnellement possible et des alertes transmises via un canal indépendant de la plateforme utilisée. Une session volée ne devrait pas hériter silencieusement de la portée complète du serveur.

Séparer le plan de gestion de ses preuves.Exporter les journaux d'authentification, de création de procédures, de déploiement de logiciels, de suppression de comptes et de modifications de configuration vers un stockage qu'un attaquant contrôlant VSA ne peut pas effacer. Huntress a observé un comportement visant à supprimer les preuves locales. Si la seule piste d'audit se trouve à côté de l'application privilégiée, la compromission peut détruire à la fois le système et l'explication.

Corriger en fonction de l'autorité et de l'exposition.Les scores de gravité sont des entrées, pas des calendriers. Une faille d'authentification exploitable à distance dans une plateforme qui contrôle des milliers de machines justifie un cycle de décision plus court que le même score dans un outil isolé. Le test est de savoir si l'éditeur peut montrer une escalade documentée, un contrôle temporaire, un propriétaire, une date cible, une carte de l'exposition des clients et l'acceptation par la direction de tout retard.

Vérifier l'avertissement privé.Lors d'une divulgation coordonnée, l'éditeur devrait être en mesure de prouver quels clients exposés identifiables ont reçu une mesure d'atténuation, quand la livraison a réussi et si le contrôle a été mis en œuvre. Le contenu peut rester confidentiel. L'existence et l'achèvement de la campagne devraient être vérifiables après la publication du correctif.

Limiter la propagation d'un client à l'autre.Un MSP devrait démontrer que la compromission de son RMM n'accorde pas automatiquement un mouvement réseau illimité à l'intérieur de chaque client. Les privilèges d'agent, la segmentation du réseau, les contrôles d'application, la séparation des informations d'identification et les limites administratives par client devraient rendre l'outil légitime utile sans le rendre omnipotent.

Récupérer sans la plateforme.Réalisez un exercice dans lequel VSA ou un RMM équivalent est indisponible pendant une semaine. Le MSP peut-il localiser chaque actif géré, contacter chaque client, révoquer les informations d'identification, distribuer un correctif critique, récupérer des sauvegardes propres et prioriser les visites sur site? La PME peut-elle accepter des paiements, communiquer avec les clients, planifier le travail ou traiter les commandes urgentes? Un plan qui nécessite que la console défaillante soit ouverte n'est pas un plan indépendant.

Mesurer la restauration au niveau de la fonction métier.Un terminal décrypté avec succès est un résultat intermédiaire. Le critère d'achèvement devrait être une caisse utilisable, un flux de travail de planification accessible, un grand livre rapproché ou un autre service défini. Ce changement de mesure empêche les équipes techniques de déclarer victoire alors que le client reste opérationnellement fermé.

Ces contrôles s'alignent sur la discipline plus large de la chaîne d'approvisionnement dans NIST SP 800-161 Rév. 1, qui place le risque fournisseur à l'intérieur de la gouvernance d'entreprise, de l'acquisition, de l'évaluation et de la surveillance continue plutôt que de le traiter comme un questionnaire de sécurité ponctuel. La révision finale est postérieure à l'incident, bien que le programme sous-jacent de chaîne d'approvisionnement du NIST et une édition antérieure existaient déjà. Elle doit être utilisée comme un cadre de contrôle prospectif, pas comme un verdict rétroactif.

Ce que l'assurance ultérieure prouve, et ce qu'elle ne prouve pas

Le rapport SOC 3 de Kaseya pour la période se terminant le 31 mai 2022 incluait l'incident de juillet comme une divulgation. Il indiquait que 57 clients sur site étaient touchés, que le processus de réponse avait été invoqué, que des enquêteurs tiers avaient été engagés, que le SaaS avait été arrêté par précaution, que les clients sur site avaient été avertis et que la version du 11 juillet avait commencé la restauration. Le rapport décrivait également les politiques de gestion des changements, de réponse aux incidents, de sauvegarde, d'administration de la sécurité et de surveillance.

C'est une preuve utile d'un processus d'assurance et d'un environnement de contrôle ultérieur. Ce n'est pas un audit médico-légal public de chaque décision pré-incident. Le rapport lui-même note les limites inhérentes des contrôles internes et explique qu'une description de système à usage général peut omettre des aspects importants pour un utilisateur particulier.

Il ne divulgue pas les résultats de l'examen du code source, les niveaux de service de correction des vulnérabilités, la télémétrie exacte qui existait avant le 2 juillet ou les preuves de test montrant qu'un contournement d'authentification ne peut plus produire une exécution de masse.

Cette distinction est importante parce que les certifications sont souvent utilisées comme substituts à des questions difficiles d'approvisionnement. Une opinion d'assurance propre peut soutenir la confiance dans un ensemble défini de critères sur une période définie. Elle ne peut pas prouver qu'aucune vulnérabilité grave n'existe, que chaque paramètre par défaut du produit est sûr ou que l'architecture de reprise d'un client est adéquate.

Un MSP et une PME devraient lire la portée, la période, les exclusions, les contrôles utilisateur complémentaires et le traitement des sous-services au lieu de traiter le rapport comme une garantie de sécurité.

La responsabilité publique serait plus forte avec un rapport post-incident dédié qui relierait chaque mode de défaillance à une correction testée. Kaseya a publié des indicateurs techniques, une chronologie, des guides de renforcement et des documents d'assurance ultérieurs, mais elle n'a pas publié un examen causal complet et indépendant comparable aux rapports post-incident les plus détaillés maintenant publiés après des défaillances majeures de cloud ou de logiciels. L'artefact manquant n'est pas des excuses. C'est la preuve qu'un chemin de récurrence a été identifié, assigné, corrigé et contesté.

Les affirmations qui doivent rester limitées

Plusieurs interprétations populaires vont au-delà des preuves.

Il n'est pas prouvé que Kaseya ait sciemment laissé une faille facilement corrigible ouverte sans agir. DIVD dit le contraire concernant l'engagement et confirme que plusieurs correctifs ont été livrés pendant la fenêtre de divulgation. La critique légitime concerne la priorisation, les mesures de protection provisoires et l'exposition sur site, pour lesquelles le dossier interne n'est pas public.

Il n'est pas prouvé que tous les clients de Kaseya ou un million de machines aient été compromis. L'estimation mûre de Kaseya était de moins de 60 clients directs et de moins de 1 500 entreprises en aval. Les autres décomptes des intervenants reflètent leur propre visibilité et le moment de la mesure. Le nombre total de machines, les paiements de rançon et les pertes économiques complètes restent inconnus.

Il n'est pas prouvé que le VSA SaaS ait été compromis. Kaseya a constamment déclaré n'avoir trouvé aucune preuve de compromission des clients SaaS. Le SaaS a été arrêté préventivement, et la chronologie de DIVD indique que les correctifs pertinents avaient atteint cet environnement avant le 2 juillet. La panne de service subie par les clients SaaS ne doit pas être étiquetée à tort comme un chiffrement des terminaux.

Il n'est pas prouvé qu'une mise à jour logicielle ordinaire de Kaseya ait été empoisonnée à la source. Le meilleur compte-rendu public est l'exploitation de serveurs VSA exploités par les clients, suivie de l'abus des fonctions de déploiement standard. Appeler l'événement une attaque de la chaîne d'approvisionnement est défendable parce que la compromission a voyagé à travers les relations avec les fournisseurs, mais cela ne doit pas impliquer une compromission de construction factuellement différente.

Il n'est pas prouvé que le décrypteur universel ait effacé les pertes des victimes. Kaseya a déclaré qu'il fonctionnait pour les fichiers entièrement chiffrés et qu'aucune rançon n'avait été payée pour l'obtenir. La source de la clé n'a pas été établie publiquement par Kaseya, et le travail de reprise a précédé et suivi son arrivée.

Enfin, l'attribution pénale n'attribue pas la responsabilité civile entre l'éditeur, le MSP et le client. Une poursuite fédérale a établi des conséquences pour la conduite d'un affilié de REvil. Elle n'a pas jugé de l'adéquation du développement logiciel de Kaseya, de la configuration d'un MSP ou du plan de continuité d'un client. Les termes du contrat, la loi applicable, la causalité factuelle, l'assurance et les dommages importeraient dans tout litige spécifique.

Les informations encore manquantes

Un dossier de responsabilité complet inclurait les horodatages de la première exploitation et de la détection; les vulnérabilités exactes enchaînées dans chaque VSA compromis; le nombre de serveurs sondés, pénétrés et utilisés pour le déploiement; la gravité interne et les objectifs de correction attribués après le 6 avril; et les contrôles temporaires proposés avant le 2 juillet. Il montrerait également combien d'hôtes exposés figurant sur la liste de juin de DIVD ont été notifiés en privé et combien ont réduit leur exposition.

Pour l'impact, les données manquantes incluent le nombre total de terminaux chiffrés, la répartition des victimes par pays et par secteur, les temps de récupération médians et extrêmes, les paiements de rançon par les victimes en aval, le succès des sauvegardes, l'interruption d'activité, le travail des MSP, l'indemnisation par l'assurance et l'indemnisation des clients. Le nombre public d'organisations est utile, mais il ne mesure pas l'intensité ou la durée du préjudice.

Pour une correction durable, les lecteurs ont besoin de preuves indépendantes sur les changements de développement sécurisé, les frontières d'authentification et de session, l'autorisation de déploiement de masse, la journalisation inviolable, la détection d'anomalies, les objectifs de correctifs d'urgence, la reprise progressive et les tests continus du produit sur site. Les guides de renforcement et le rapport d'assurance de Kaseya sont des signaux, mais ils ne fournissent pas cette chaîne complète.

Pour le marché des MSP, le dénominateur manquant est structurel. Il n'existe pas d'inventaire public complet des PME qui dépendent de quelles plateformes RMM, du nombre de clients partageant chaque plan de contrôle ou de la fréquence à laquelle les fournisseurs testent le fonctionnement sans elles. Cette opacité rend la concentration systémique difficile à tarifer avant un incident.

Une audience du Congrès américain en 2022 sur les ransomwares et les petites entreprises a placé l'événement Kaseya dans un problème politique plus large: les petites entreprises sont confrontées à une exposition cybernétique sérieuse mais ont moins de ressources pour la prévenir et l'absorber. Le compte-rendu de l'audience n'est pas une source médico-légale pour l'exploitation, et certains documents d'incident qu'il reproduit proviennent d'articles de presse. Sa pertinence politique est le décalage entre la dépendance sociale envers les petites entreprises et leur capacité limitée à auditer des fournisseurs complexes.

La leçon durable concerne le pouvoir délégué

La réponse de Kaseya du 2 juillet a empêché un résultat pire. L'entreprise a arrêté le SaaS malgré l'absence de preuve que les clients hébergés étaient compromis, a averti les opérateurs sur site, a engagé des enquêteurs et le gouvernement, a construit des outils de détection et de reprise, et a finalement livré un correctif et un support de décryptage. Le dossier de DIVD montre que Kaseya n'avait pas ignoré la recherche sous-jacente sur les vulnérabilités. Ces faits appartiennent à tout compte-rendu équitable.

Le même dossier montre pourquoi l'équité ne peut pas s'arrêter à des éloges pour la réponse. Une vulnérabilité connue en privé en avril a été liée à une exploitation avant que les clients sur site n'aient la version pertinente. Un petit groupe d'instances VSA compromises a atteint beaucoup plus d'entreprises en aval. La réponse la plus sûre a désactivé un service de gestion essentiel pour les utilisateurs non affectés. La restauration est passée d'un outil centralisé au travail manuel, à des processus alternatifs, aux sauvegardes et aux visites.

Les preuves publiques restent trop minces pour tester si les contrôles préventifs les plus profonds ont changé.

La signification durable de l'incident n'est pas que l'externalisation ait échoué. Les services gérés restent économiquement nécessaires pour de nombreuses PME et peuvent élever leur niveau de sécurité de base. La leçon est que le pouvoir technique délégué crée un devoir d'exposer et de gouverner la dépendance qui en résulte. Les éditeurs doivent concevoir et corriger en fonction de la portée de leurs outils. Les MSP doivent traiter l'administration à distance comme un système de production à haute conséquence et se préparer à fonctionner sans elle.

Les clients ont besoin de contrats et de plans de continuité qui révèlent les sous-traitants critiques et définissent la reprise en termes commerciaux. Les gouvernements devraient rendre le signalement, les directives de base, les enquêtes et l'application transfrontalière plus efficaces tout en résistant à la fiction selon laquelle chaque petite entreprise peut auditer seule une chaîne d'approvisionnement logicielle.

La gestion à distance fonctionne en rendant un administrateur distant puissant localement. En juillet 2021, ce pouvoir a franchi la frontière de confiance dans la mauvaise direction. La responsabilité signifie s'assurer que la prochaine console compromise rencontre des limites, des preuves indépendantes, une révocation rapide et un chemin de reprise avant de rencontrer chaque client.