Kaseya a fait du retard de détection des services gérés un problème de responsabilité en aval

Résumé

• L'incident Kaseya VSA de juillet 2021 a transformé un problème de fournisseur et de prestataire de services gérés en un problème de responsabilité en aval, car de nombreuses entreprises concernées dépendaient des notifications et de la reprise des MSP bien qu'elles n'exploitent pas directement VSA.
• Les preuves publiques montrent que Kaseya travaillait déjà avec DIVD via une divulgation coordonnée avant l'attaque, que plusieurs vulnérabilités avaient été corrigées, et que des systèmes sur site vulnérables existaient encore lorsque les acteurs de REvil ont exploité VSA le 2 juillet 2021.
• Les actions post-alerte de Kaseya, notamment l'arrêt de VSA hébergé, les conseils d'arrêt aux clients sur site, l'appel aux intervenants, les contacts avec les partenaires gouvernementaux et la publication d'un outil de détection, ont été importantes. Elles ne répondent pas à toutes les questions sur la réduction de l'exposition avant l'exploitation ni sur la rapidité avec laquelle les clients en aval ont reçu des conseils utilisables.
• Le dénominateur des victimes est en couches. Kaseya a ensuite décrit moins de 60 clients directement touchés, dont beaucoup de MSP, et moins de 1 500 entreprises en aval. Ces chiffres décrivent différentes positions dans l'arbre de dépendance et ne doivent pas être réduits à un seul nombre.
• Le standard de réparation est l'observabilité: un écosystème de services gérés doit pouvoir montrer qui a été exposé, qui a été averti, qui a arrêté, qui a été chiffré, qui a reçu des instructions de récupération, et si les clients sans contrôle direct sur VSA ont pu voir le risque à temps pour protéger la continuité.

Le retard de détection a traversé la chaîne de services

L'incident Kaseya est souvent décrit comme une attaque de ransomware par chaîne d'approvisionnement. C'est globalement exact, mais cette expression peut masquer le chemin spécifique de la responsabilité. Les archives publiques ne montrent pas que les attaquants ont modifié la version logicielle de Kaseya ou expédié une mise à jour malveillante.

L' aperçu de l'incident et les détails techniques de Kaseya indiquent que les attaquants ont exploité des vulnérabilités zero-day dans VSA sur site, contourné l'authentification, obtenu l'exécution de commandes et utilisé les fonctionnalités standard de VSA pour déployer un ransomware sur les points de terminaison gérés. Le chemin de confiance passait par l'autorité d'administration, et non par un paquet fournisseur empoisonné.

Cette distinction est importante pour la détection et la divulgation. VSA est un logiciel de surveillance et de gestion à distance. Les fournisseurs de services gérés utilisent ces outils pour inventorier les appareils, effectuer la maintenance, déployer des logiciels et soutenir les clients qui manquent souvent de personnel technique à temps plein. Lorsqu'un attaquant contrôle le serveur VSA, l'action malveillante peut ressembler à une action administrative jusqu'à ce que le comportement, le timing, les charges utiles ou les rapports des clients révèlent le contraire.

Le premier avertissement clair peut apparaître chez un MSP, un client en aval, un fournisseur de sécurité, l'éditeur de logiciel ou un partenaire gouvernemental. Aucune de ces positions ne voit toute la chaîne.

Le communiqué de presse de Kaseya du 5 juillet 2021 a indiqué que des sources internes et externes avaient alerté l'entreprise d'une attaque potentielle vers 14h00, heure de l'Est, le 2 juillet et que l'entreprise avait agi en moins d'une heure pour arrêter son environnement VSA hébergé et conseiller aux clients sur site d'arrêter leurs serveurs. Cette action post-alerte a été déterminante. Elle a probablement limité la propagation.

Mais une analyse de la responsabilité en aval pose une question plus longue: quand le risque est-il devenu connaissable à chaque couche, et à quelle vitesse l'avertissement s'est-il déplacé de la première couche qui savait vers les entreprises qui allaient perdre des systèmes?

Huntress, qui a reçu les premiers rapports des partenaires affectés, a publié un récapitulatif des événements et des leçons apprises. Son récit décrivait des rapports MSP arrivant à proximité les uns des autres, le lien VSA commun, la préparation des charges utiles, les actions de nettoyage et la livraison via les fonctions de gestion. Sophos a publié un récit technique contemporain du côté des endpoints et de la réponse. Ces récits d'intervenants ne sont pas des décomptes globaux de victimes, mais ils montrent pourquoi le retard de détection dans ce cas était distribué.

La première entreprise à constater le chiffrement n'était pas nécessairement celle qui avait l'autorité de réparer VSA.

La déclaration publique du FBI sur l'attaque ransomware de Kaseya a renforcé l'instruction d'arrêt et encouragé les signalements. CISA et le FBI ont ensuite publié des conseils conjoints via ce PDF d'avis, recommandant l'outil de détection, l'authentification multifacteur, la communication restreinte de la gestion à distance, la protection par VPN ou pare-feu des interfaces administratives, les sauvegardes protégées et le moindre privilège. Ce sont des mesures fortes après la découverte. La question non résolue est de savoir combien d'exposition aurait pu être réduite avant l'expiration du délai criminel.

Le retard de détection ne peut donc pas être mesuré uniquement à l'intérieur de Kaseya. Il doit être mesuré aux points où les MSP pouvaient voir un comportement anormal de VSA, où les entreprises en aval pouvaient reconnaître que l'outil de leur prestataire était le chemin, et où les agences publiques pouvaient transformer les rapports d'incidents en avertissements plus larges. L'incident a transformé une plateforme de gestion centralisée en un problème de relais.

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

Le dossier pré-exploitation est inhabituellement important car il résiste à la fois à la condamnation facile et à l'absolution facile. La divulgation limitée de DIVD a indiqué que le groupe de recherche à but non lucratif avait commencé à examiner VSA en avril 2021 et avait notifié Kaseya le 6 avril. DIVD a déclaré que la réponse de Kaseya avait été rapide et engagée, et que l'entreprise travaillait avec les chercheurs sur les correctifs. Cela compte. Les preuves publiques ne soutiennent pas une simple affirmation selon laquelle le fournisseur a ignoré des rapports responsables.

Le dossier de cas maintenu par DIVD montre l'autre côté du calendrier. L'affaire impliquait plusieurs vulnérabilités. Certaines ont été corrigées avant juillet. L'environnement hébergé de Kaseya a reçu les correctifs pertinents avant l'attaque. Les serveurs VSA sur site nécessitaient encore des actions lorsque l'événement de ransomware a commencé. DIVD a ensuite publié les détails complets des vulnérabilités, y compris CVE-2021-30116, et l'entrée CVE-2021-30116 du NVD enregistre désormais que le problème a été exploité dans la nature.

Cette séquence crée une norme de responsabilité exigeante. Un fournisseur qui travaille de bonne foi avec des chercheurs peut toujours faire face à un échec en aval si la correction, la réduction de l'exposition et l'avertissement aux clients ne devancent pas la redécouverte par l'adversaire. La divulgation coordonnée est conçue pour réduire les dommages en permettant des correctifs avant les détails publics. Elle crée également une période pendant laquelle un petit nombre de personnes savent qu'un produit à haute conséquence est vulnérable alors que de nombreux opérateurs n'en savent pas assez pour modifier leur comportement.

Plus le produit est privilégié, plus cette période doit être courte.

Le rôle de VSA a amplifié l'urgence. Un produit d'administration à distance n'est pas un site de contenu ordinaire. C'est un plan de contrôle pour les machines clientes. Si une faille critique d'authentification ou d'autorisation existe dans un serveur VSA exposé à Internet, la conséquence plausible n'est pas seulement le compromis d'un serveur. C'est une action malveillante sur tous les points de terminaison qui font confiance à ce serveur. Cela signifie que les contrôles provisoires doivent être traités comme faisant partie du processus de divulgation, et non comme un durcissement optionnel après un correctif.

Le dossier public laisse plusieurs questions pré-attaque non résolues. Quels opérateurs exposés Kaseya a-t-il contactés en privé avant le 2 juillet? Quelles restrictions provisoires exactes ont été exigées ou recommandées? Les interfaces de gestion ont-elles été poussées derrière des VPN ou des règles de pare-feu dédiées? Les clients sur site à haut risque ont-ils été invités à arrêter jusqu'à l'arrivée d'un correctif? Comment Kaseya a-t-il vérifié que les systèmes exposés connus avaient changé d'état?

Quelles données télémétriques, le cas échéant, existaient pour distinguer la création suspecte de procédures du travail de gestion à distance ordinaire? Ces questions ne supposent pas la négligence. Elles identifient les preuves nécessaires pour évaluer si les avertissements pré-exploitation correspondaient au rayon d'impact de VSA.

Kaseya a ensuite publié des avis tels que l'avis important du 4 août 2021 et des documents de récupération supplémentaires, tout en fournissant une page d'outil de détection de compromission. Ces documents faisaient partie du dossier de contrôle post-incident. Ils ne reconstruisent pas par eux-mêmes ce qui était possible en juin 2021. La leçon durable est que la divulgation coordonnée pour les logiciels de gestion privilégiés devrait inclure une réduction observable de l'exposition bien avant le titre public.

Les conseils d'arrêt ont exposé le fossé sur site

Kaseya pouvait arrêter l'environnement qu'il exploitait. Il ne pouvait pas arrêter directement chaque serveur VSA exploité par un client. Cette distinction est au cœur du problème de détection-divulgation. Un produit hébergé donne au fournisseur un contrôle opérationnel en cas de crise. Un produit sur site donne au fournisseur la connaissance et l'autorité sur le code, tandis que le service en cours reste sous le contrôle du client ou du MSP. Dans l'événement Kaseya, cela signifiait que le message d'arrêt devait atteindre chaque opérateur sur site, puis être exécuté pendant un vendredi de week-end de vacances.

Ce n'est pas simplement un inconvénient. Chaque minute dans le relais comptait car les attaquants utilisaient des fonctions d'administration de confiance. Un message de Kaseya devait atteindre un dirigeant ou un administrateur MSP, cette personne devait comprendre que « arrêter VSA » l'emportait sur le coût normal de la désactivation de la gestion client, et le MSP devait confirmer que des procédures malveillantes n'étaient pas déjà en file d'attente ou exécutées. Les clients en aval avaient ensuite besoin de savoir si leurs propres systèmes étaient sûrs, chiffrés, déconnectés ou en attente de restauration.

Le relais contenait des étapes techniques, commerciales et de communication client.

Les conseils conjoints CISA-FBI ont reconnu que la réponse n'était pas seulement « appliquer un correctif ». Ils ont insisté sur l'arrêt des serveurs VSA, l'exécution de l'outil de détection, la préservation des sauvegardes, la restriction de la communication de gestion à distance et l'utilisation du moindre privilège. Ces conseils parlaient à la réalité sur site: un serveur de gestion compromis pouvait rester dangereux même après le premier avis public si les opérateurs redémarraient sans effacer l'état malveillant ou resserrer l'exposition.

Le rapport SOC 3 ultérieur de Kaseya indiquait que 57 clients sur site avaient été affectés. Ce rapport est utile en tant que contexte d'assurance fourni par l'entreprise, mais ce n'est pas un récit d'incident indépendant complet pour chaque entreprise en aval. Reuters, relayé par Investing.com, a rapporté l'estimation du directeur général selon laquelle 800 à 1 500 entreprises avaient été affectées. Ces chiffres ne sont pas interchangeables. L'un compte les clients directs à une couche. L'autre compte les organisations en aval à une autre couche.

Ce dénominateur en couches affecte la qualité des notifications. Un client direct de Kaseya peut recevoir des conseils du fournisseur. Une petite entreprise servie par un MSP peut recevoir un email, un appel téléphonique, un avis sur un portail, ou aucune explication claire jusqu'à ce que les systèmes soient indisponibles. Une épicerie, un dentiste, un bureau gouvernemental local ou un détaillant peut ne pas connaître le terme VSA du tout. Pourtant, sa continuité dépendait de l'état de VSA et de la réponse du MSP. La partie subissant les conséquences de la panique peut être la partie la moins informée de la chaîne.

C'est pourquoi les contrats de services gérés devraient définir les obligations de notification d'urgence avant l'urgence. Les clients devraient savoir quels outils de gestion à distance ont une autorité privilégiée, qui peut les arrêter, ce qui arrive à la surveillance et à la maintenance pendant un arrêt, comment les systèmes clients seront isolés, comment la restauration sera priorisée et comment les preuves seront partagées. Sans ces termes, la première conversation claire sur la responsabilité peut avoir lieu après le chiffrement, lorsque chaque partie est sous pression et que les faits sont incomplets.

Le dénominateur en aval a modifié le préjudice

Le nombre de victimes directes de Kaseya était faible par rapport à sa base totale de clients, et Kaseya a souligné à juste titre que tous les clients n'étaient pas affectés. Ce fait doit être préservé. Il ne doit pas être utilisé pour minimiser la forme opérationnelle de l'événement. L'incident a compté parce que certains clients directs affectés étaient des fournisseurs de services gérés. Un seul MSP peut connecter un plan de contrôle compromis à des dizaines ou des centaines d'entreprises.

Le détaillant suédois Coop est devenu un symbole public de la perte de continuité en aval. Investing.com a relayé un reportage de Reuters selon lequel une attaque cybernétique contre le fournisseur IT américain a forcé la chaîne suédoise à fermer 800 magasins. Des reportages ultérieurs ont décrit des entreprises touchées faisant face à une récupération qui pourrait prendre des semaines. Ces récits ne doivent pas être traités comme une liste complète de victimes.

Ils montrent comment un compromis de gestion à distance peut atteindre des services publics que les consommateurs vivent comme des portes fermées, des paiements indisponibles ou des opérations locales interrompues.

Pour les petites et moyennes entreprises, le service géré est rationnel. Il donne accès à une main-d'œuvre spécialisée, à la surveillance, à la gestion des sauvegardes, aux correctifs et au soutien que de nombreuses petites organisations ne pourraient pas construire seules. La même concentration crée une défaillance corrélée. Un ensemble d'entreprises qui semblent séparées par la géographie et le secteur peuvent partager un seul MSP, un seul outil distant, un seul modèle de sauvegarde et un seul personnel de récupération. Un événement ransomware à cette couche peut faire échouer simultanément de nombreux plans de continuité indépendants.

La continuité du secteur public peut être affectée de la même manière. Les gouvernements locaux, les écoles, les services publics et les agences publiques dépendent souvent des MSP ou d'un soutien externalisé similaire. Les citoyens affectés par les temps d'arrêt ne se soucient pas de savoir si un outil était exploité par un employé de l'agence, un entrepreneur, un revendeur ou un fournisseur de logiciel. Ils ont besoin que les services soient rétablis. Le chemin de la responsabilité, cependant, traverse ces relations techniques, et des retards peuvent être introduits à chaque transfert.

C'est là que la détection et la divulgation deviennent économiques. Une petite entreprise qui apprend rapidement peut déconnecter les systèmes, préserver les sauvegardes, avertir les employés, changer le traitement des paiements, reporter le travail ou appeler les clients. Une entreprise qui n'apprend qu'après le chiffrement a moins de choix. Elle peut faire face à des pertes de ventes, des perturbations de paie, des frustrations clients, une incertitude réglementaire de déclaration et des paperasseries d'assurance.

La même exploitation technique produit des dommages différents selon le moment où la partie en aval reçoit des informations utilisables.

La CISA, la NSA, le FBI et des partenaires internationaux ont ensuite publié des conseils plus larges pour protéger les relations entre les fournisseurs de services gérés et leurs clients, annoncés par la CISA dans cet avis. Ces conseils reflètent un point systémique: la sécurité des MSP n'est pas seulement un problème privé du MSP. C'est un problème de continuité partagé pour les clients qui héritent de sa confiance.

L'action des forces de l'ordre n'a pas remplacé les preuves de réparation

L'incident Kaseya a également produit des dossiers des forces de l'ordre. Le ministère de la Justice a annoncé en 2021 qu'un citoyen ukrainien avait été arrêté et inculpé en lien avec l'attaque ransomware. Europol a annoncé que cinq affiliés liés à Sodinokibi/REvil avaient été démantelés. Le ministère de la Justice a ensuite annoncé qu'un affilié de Sodinokibi/REvil avait été condamné pour un rôle plus large dans le ransomware. Ces dossiers sont importants pour la responsabilité des attaquants.

Ils ne répondent pas aux questions opérationnelles. Les accusations et les condamnations pénales peuvent identifier des acteurs présumés ou condamnés, perturber l'infrastructure, récupérer des preuves et dissuader de futures campagnes. Elles ne prouvent pas quels clients MSP disposaient de sauvegardes adéquates, quels clients ont été informés à temps, quels serveurs VSA étaient exposés avant le 2 juillet, ou si chaque organisation en aval a reconstruit en toute sécurité. La responsabilité des attaquants et la responsabilité des services coexistent car elles concernent des contrôles différents.

La même distinction s'applique à l'attention du Congrès. Le compte rendu de l'audience de la Chambre disponible via GovInfo a capturé l'inquiétude publique concernant les ransomwares, les services critiques et la préparation du secteur privé. La surveillance peut élever les tendances et révéler les besoins politiques. Elle ne peut toujours pas remplacer les preuves au niveau de l'entité concernant les horloges de détection, le contenu des notifications, l'exécution des arrêts et la qualité de la restauration.

Le SP 800-161 Rev. 1 du NIST donne un vocabulaire plus large du risque de chaîne d'approvisionnement. Il traite les fournisseurs, les produits, les services et les contrôles du cycle de vie comme faisant partie de la gouvernance de la cybersécurité. L'incident de Kaseya montre pourquoi ce vocabulaire doit inclure les preuves opérationnelles des services gérés. Une équipe d'approvisionnement ne peut pas simplement demander si un MSP utilise une plateforme de gestion à distance.

Elle devrait demander comment cette plateforme est exposée, comment elle est surveillée, qui peut la désactiver, comment la segmentation client fonctionne, comment les sauvegardes sont isolées, comment les incidents sont signalés et comment les preuves seront partagées.

Les preuves de réparation après Kaseya devraient donc être en couches. Kaseya devrait montrer la correction de la sécurité du produit, la maturité de la gestion des vulnérabilités, les canaux d'avertissement aux clients et les attentes sécurisées par défaut pour les déploiements à haut risque. Les MSP devraient montrer un accès administratif restreint, une application de l'authentification multifacteur, une segmentation, le moindre privilège, des sauvegardes protégées, des playbooks de notification client et des exercices sur table incluant le compromis des outils.

Les clients en aval devraient montrer qu'ils savent quels outils de leur prestataire peuvent administrer leurs systèmes et quelles alternatives de continuité existent si ces outils doivent être arrêtés.

Aucun succès des forces de l'ordre n'élimine le besoin de ces dossiers. Un affilié de ransomware peut être arrêté alors qu'une entreprise manque encore d'une sauvegarde récupérable. Un fournisseur peut publier un correctif alors qu'un MSP n'a pas atteint tous ses clients. Un avis gouvernemental peut être correct alors que la plus petite entreprise concernée ne comprend toujours pas ce qui s'est passé. La responsabilité doit atteindre la couche où le préjudice atterrit.

L'observabilité est le standard de réparation

La question de la deuxième lentille pour Kaseya n'est pas de savoir si le service géré est mauvais. Le service géré peut améliorer la sécurité pour les organisations qui autrement auraient peu de soutien. La question est de savoir si le risque créé par l'administration concentrée est observable par les parties qui en dépendent. Un plan de contrôle caché crée une responsabilité cachée.

L'observabilité commence par la connaissance des actifs. Chaque client devrait savoir quels outils distants peuvent exécuter des commandes, déployer des logiciels, réinitialiser des identifiants ou accéder à des systèmes sensibles. Le MSP devrait savoir quels serveurs et locataires ont cette autorité. Le fournisseur devrait savoir quels clients exploitent des versions exposées et à haut risque lorsque les licences et la télémétrie le permettent. Les agences publiques devraient savoir comment atteindre les fournisseurs de services critiques lorsqu'un incident MSP menace les services communautaires.

L'observabilité se poursuit avec le timing des événements. Un dossier d'incident utile identifierait la première exploitation connue, la première alerte interne, le premier rapport client, la première instruction d'arrêt du fournisseur, la première notification MSP-à-client, le premier chiffrement en aval, le premier résultat de l'outil de détection et le moment où chaque partie concernée a atteint une récupération stable. Sans ces horodatages, les dirigeants peuvent louer une action rapide après un point tout en manquant le retard avant un autre.

L'observabilité nécessite également une discipline du dénominateur. Moins de 60 clients directs, 57 clients sur site, jusqu'à 1 500 entreprises en aval et d'innombrables points de terminaison gérés sont des décomptes différents. Ils décrivent différentes unités de responsabilité. Un décompte de clients directs parle de l'exposition du fournisseur. Un décompte d'entreprises en aval parle de préjudice de continuité. Un décompte de points de terminaison parle de charge de travail technique. Les mélanger obscurcit où la réparation a réussi ou échoué.

Enfin, l'observabilité nécessite un langage orienté client. Une petite entreprise n'a pas besoin de chaque détail d'exploitation dans la première heure. Elle a besoin de savoir si l'outil de gestion à distance de son prestataire était impliqué, si ses systèmes doivent être déconnectés, si les sauvegardes sont sûres, si les fichiers sont chiffrés, si les paiements peuvent continuer, si les employés doivent cesser d'utiliser certains appareils et quand la prochaine mise à jour arrivera. La qualité de la notification du MSP fait partie du profil de préjudice de l'incident du fournisseur car le produit du fournisseur a permis la portée du MSP.

L'événement Kaseya a montré qu'une plateforme de gestion à distance peut concentrer à la fois l'efficacité et la fragilité. La tâche de responsabilité après 2021 est de conserver l'efficacité tout en rendant la fragilité visible. Cela signifie des avertissements privés plus rapides là où la divulgation publique augmenterait le risque, des limites d'exposition par défaut plus fortes, des contrats clients qui nomment les dépendances de gestion à distance et des plans de récupération qui supposent que l'outil préféré du MSP peut lui-même devenir indisponible ou hostile.

La chaîne de notification a besoin de son propre objectif de niveau de service

L'incident montre pourquoi la sécurité des services gérés a besoin d'un objectif de niveau de service de notification, pas seulement d'un objectif de correction. Dans une vulnérabilité logicielle ordinaire, l'opérateur qui reçoit l'avis du fournisseur est souvent la même organisation qui souffrira si le système reste exposé. Dans le service géré, l'opérateur et le client supportant le risque peuvent être différents. Le MSP peut recevoir l'avertissement du fournisseur; la petite entreprise peut ne recevoir que la conséquence. Cet écart a besoin d'une norme mesurable.

Un objectif de notification devrait commencer par la classification. Si un outil de gestion à distance peut exécuter des commandes, déployer des logiciels, modifier les paramètres de sécurité ou toucher aux sauvegardes dans les environnements clients, alors une vulnérabilité sérieuse dans cet outil n'est pas un ticket de routine. C'est un événement de risque client. Le MSP devrait avoir une catégorie pré-écrite pour « incident de plan de contrôle du prestataire » qui déclenche des communications client même avant que chaque détail technique ne soit connu.

Le message peut être délimité et prudent, mais il ne devrait pas attendre que le chiffrement soit visible chez le client.

La première notification n'a pas besoin d'exposer les détails d'exploitation qui aideraient les attaquants. Elle devrait dire aux clients ce qui importe opérationnellement: une plateforme de gestion privilégiée est en cours d'examen d'urgence; l'accès du prestataire peut être restreint; certaines tâches de maintenance peuvent être suspendues; les clients devraient préserver les sauvegardes et éviter de redémarrer les machines affectées sans instructions; les contacts urgents et le timing de la prochaine mise à jour sont disponibles.

Si le compromis est confirmé, la notification devrait dire quels systèmes sont affectés, ce que fait le prestataire, ce que le client devrait faire et quelles preuves devraient être préservées.

La deuxième notification devrait cartographier la dépendance. De nombreux clients ne connaissent pas les noms de produits derrière le service géré. Une entreprise peut comprendre « notre prestataire IT gère les correctifs » mais pas « VSA peut exécuter des commandes sur chaque poste de travail ». Pendant un incident, cette ignorance devient un problème de continuité. Un client ne peut pas expliquer l'événement à ses propres employés, assureur, clients, régulateur ou conseil si le MSP ne nomme pas le plan de contrôle impliqué.

Les contrats devraient préciser quand l'identité du produit peut être divulguée aux clients pendant les urgences et combien de détails doivent être partagés.

La troisième notification devrait traiter des opérations commerciales. Si un MSP arrête VSA, les fonctions de surveillance de routine, de déploiement de logiciel, de support à distance et certaines réponses de sécurité peuvent être altérées. Les clients doivent savoir quel support reste disponible. Ils ont besoin de numéros de téléphone alternatifs, de canaux de tickets, de règles d'accès d'urgence et de délais attendus. Une instruction d'arrêt qui protège la sécurité peut encore nuire à la continuité si personne n'explique la conséquence du service.

La quatrième notification devrait documenter les preuves et la récupération. Le client devrait savoir si ses appareils ont été chiffrés, si des procédures suspectes ont été exécutées, si les sauvegardes ont été touchées, si les identifiants ont été révoqués, si les forces de l'ordre ou les conseils de la CISA sont pertinents, et si le prestataire a utilisé l'outil de détection de Kaseya ou d'autres preuves d'intervenant. Un client qui ne reçoit que « nous travaillons dessus » ne peut pas prendre ses propres décisions juridiques, d'assurance et clients.

Cette chaîne de notification devrait être chronométrée. Le MSP peut promettre une notification initiale au client dans un nombre défini de minutes après un événement confirmé de plan de contrôle du prestataire, un suivi à chaque intervalle défini et un dossier de clôture écrit après la récupération. Le calendrier variera selon le client et la gravité, mais le principe ne devrait pas. Le risque de service géré est délégué; la responsabilité ne peut pas l'être.

L'arrêt pré-autorisé est un contrôle de gouvernance

L'instruction de Kaseya d'arrêter les serveurs VSA sur site a exposé une vérité gênante: une action sécuritaire peut être une action perturbatrice pour l'entreprise. Arrêter une plateforme de gestion à distance peut réduire la portée de l'attaquant, mais peut aussi supprimer le principal moyen du MSP de soutenir les clients. Si le MSP n'a pas pré-autorisé qui peut prendre cette décision, la réponse peut stagner au pire moment.

La pré-autorisation devrait préciser qui peut désactiver l'outil, sous quel seuil de preuve, et comment les clients sont informés. Elle devrait également préciser quelles fonctions restent disponibles après l'arrêt. Les techniciens peuvent-ils encore soutenir les clients par téléphone? Peuvent-ils utiliser un accès à distance alternatif? Cet accès alternatif est-il plus ou moins sécurisé? Quels environnements clients sont trop sensibles pour des outils distants d'urgence? Quels clients nécessitent une approbation écrite avant que les agents du prestataire ne se reconnectent?

Ces détails semblent fastidieux jusqu'à ce qu'une attaque un vendredi après-midi les rend urgents.

La même logique s'applique au fournisseur. Pour un produit comme VSA, l'arrêt hébergé du fournisseur est sous contrôle direct de l'entreprise, mais les opérateurs sur site ont besoin de seuils clairs. Un fournisseur peut recommander ou exiger l'arrêt dans les conditions de support, mais l'exécution appartient aux clients. Si le fournisseur sait que certains déploiements sur site exposés à Internet sont à haut risque avant qu'un correctif ne soit prêt, il a besoin d'un modèle d'escalade privé: sensibilisation directe, avis de haute gravité, suivi des tickets de support et vérification lorsque possible.

L'objectif n'est pas de faire honte aux clients. C'est de réduire le nombre de plans de contrôle exposés avant que les criminels n'agissent.

L'autorité d'arrêt interagit également avec les sauvegardes. La réponse au ransomware dépend de sauvegardes récupérables et protégées, mais de nombreux MSP gèrent les sauvegardes via le même écosystème administratif qui soutient le service de routine. Si le plan de contrôle est suspect, les intervenants doivent savoir si les consoles de sauvegarde, les identifiants, le stockage et les procédures de restauration sont indépendants. Les conseils CISA-FBI ont souligné les sauvegardes cloisonnées ou autrement protégées car un compromis de gestion peut menacer à la fois la récupération et la production.

Les clients ne devraient pas découvrir pendant un incident que le plan de sauvegarde du MSP dépend de l'outil compromis. Un contrat de services gérés devrait décrire si les sauvegardes sont logiquement et administrativement séparées, à quelle fréquence les restaurations sont testées, qui peut autoriser la restauration et ce qui se passe si l'environnement de gestion du MSP est hors ligne. Pour les petites entreprises, ce langage contractuel peut être la seule visibilité pratique qu'elles ont sur la résilience.

L'arrêt pré-autorisé aide également les assureurs et les régulateurs. Un client qui peut montrer qu'un prestataire a suivi un playbook d'arrêt et de notification documenté est dans une position différente d'un client qui reconstruit les décisions à partir d'emails épars. Les preuves d'action pré-autorisée n'éliminent pas le préjudice, mais elles montrent la gouvernance. Elles peuvent également réduire les litiges entre fournisseur, MSP, client, assureur et forces de l'ordre après l'événement.

Le dossier Kaseya montre qu'une action rapide post-alerte est précieuse. La prochaine norme devrait pousser la décision plus tôt et la rendre plus automatique là où le rayon d'impact est clair. Un plan de contrôle de gestion à distance devrait être conçu pour échouer en mode fermé, avec un chemin connu pour fonctionner en mode réduit. Si son arrêt nécessite un débat personnalisé à chaque fois, alors le modèle économique n'a pas pleinement intégré le rôle de sécurité que l'outil joue.

Les preuves en aval font partie du dossier produit

Les fournisseurs de logiciels se concentrent naturellement sur les clients directs, mais les conséquences d'un produit de service géré s'étendent à travers la base de clients de ces clients. Cela signifie que les preuves en aval appartiennent au dossier produit. Un fournisseur peut ne pas connaître chaque point de terminaison ou chaque entreprise servie par un MSP, mais il devrait concevoir le signalement des incidents pour préserver la chaîne de dépendance aussi loin que raisonnablement possible.

Le premier problème de preuve est l'identité de la chaîne affectée. Quel client Kaseya exploitait l'instance VSA affectée? Ce client était-il un MSP? Quels environnements clients cette instance VSA gérait-elle? Quels agents se sont connectés pendant la fenêtre d'exposition? Quelles procédures ont été exécutées? Quels points de terminaison ont reçu des charges utiles? Quels points de terminaison étaient hors ligne et plus tard à risque lors de la reconnexion? Sans cette chaîne, les décomptes deviennent ambigus et la récupération devient inégale.

Le deuxième problème est le temps. Une entreprise en aval doit savoir quand ses systèmes ont été touchés, pas seulement quand le fournisseur a découvert l'incident. Si une procédure malveillante s'est exécutée à un moment spécifique, cet horodatage ancre l'investigation des points de terminaison, la sélection des sauvegardes, les décisions de paie et la notification client. Si le MSP ne peut pas fournir le timing, le client peut devoir traiter une période plus large comme suspecte, augmentant les coûts.

Le troisième problème est la conservation des preuves. Les journaux peuvent résider sur le serveur VSA, chez le MSP, sur les points de terminaison, dans les outils de sécurité et chez le fournisseur. Pendant un événement ransomware, certaines preuves peuvent être supprimées, chiffrées, écrasées ou déconnectées. Un produit mature devrait rendre les actions administratives à haute conséquence suffisamment durables pour que les intervenants puissent reconstruire ce qui s'est passé même si le serveur de gestion est compromis. Cela n'exige pas de publier des données télémétriques sensibles au monde.

Cela exige de concevoir pour la reconstruction d'incident.

Le quatrième problème est le langage prêt pour le client. Une entreprise en aval peut avoir besoin de faire un rapport à un régulateur, un conseil scolaire, un maire, un propriétaire, un assureur ou un client. Elle ne peut pas simplement transmettre un bulletin technique du fournisseur si le bulletin ne dit pas si son propre environnement a été affecté. Les MSP devraient convertir les preuves du fournisseur en déclarations spécifiques au client: dans le périmètre, hors périmètre, chiffré, non chiffré, inconnu par manque de preuves, restauré à partir de sauvegardes, identifiants révoqués, ou toujours en cours d'investigation.

« Inconnu » est acceptable quand c'est vrai; faire semblant de savoir ne l'est pas.

Le cinquième problème est l'allocation équitable. Si le fournisseur, le MSP et le client contribuent tous au risque final, le dossier de preuves devrait permettre cette allocation. Une vulnérabilité du fournisseur peut créer une entrée. Une exposition Internet ou un manque de segmentation du MSP peut aggraver le préjudice. Des sauvegardes faibles du client peuvent allonger la récupération. Inversement, un avertissement du fournisseur, un arrêt du MSP et un plan de continuité du client peuvent tous réduire le préjudice. La responsabilité devrait être suffisamment granulaire pour créditer et blâmer les bons contrôles.

C'est pourquoi les preuves en aval font partie du dossier produit. Il ne suffit pas que le fournisseur sache combien de clients directs ont été affectés si le rôle économique du produit est d'administrer beaucoup plus d'organisations. La gouvernance du produit devrait anticiper l'arbre de dépendance. Les modèles d'incident, la télémétrie, l'escalade du support et les déclarations publiques devraient préserver les dénominateurs par couche: clients directs, MSP, organisations en aval, points de terminaison et services. L'événement Kaseya est devenu un jalon parce que ces couches comptaient toutes à la fois.

Les contrats devraient exposer le plan de contrôle caché

De nombreux clients de services gérés n'achètent pas Kaseya VSA directement. Ils achètent des résultats: des ordinateurs portables corrigés, des emails fonctionnels, des imprimantes accessibles, des serveurs surveillés, un support de helpdesk et une récupération après panne. Le produit de gestion à distance est caché derrière la promesse de service. Cette dissimulation peut être efficace en temps normal, mais pendant un incident ransomware, elle laisse le client sans carte. Un client ne peut pas juger le risque de continuité s'il ne sait pas quels systèmes extérieurs peuvent administrer son environnement.

Les contrats devraient donc nommer les catégories d'outils privilégiés du prestataire même s'ils ne publient pas chaque configuration sensible. Le client devrait savoir si le MSP utilise un logiciel de surveillance et de gestion à distance, une détection et réponse des points de terminaison, des consoles de sauvegarde, des courtiers de bureau à distance, des moteurs de scripts, une administration d'identité ou des portails de gestion cloud. Pour chaque catégorie, le client devrait savoir si l'outil peut déployer des logiciels, exécuter des commandes, réinitialiser des comptes, accéder aux sauvegardes ou modifier les contrôles de sécurité.

Ce n'est pas de la curiosité. C'est un registre de dépendances.

Le contrat devrait également dire comment le compromis de l'outil sera géré. Le MSP informera-t-il le client si un outil privilégié du prestataire est en cours d'exploitation active? Qui décide de déconnecter les agents du prestataire? Le client recevra-t-il une liste des points de terminaison affectés? À quelle vitesse le MSP fournira-t-il des faits écrits pour l'examen de l'assurance et juridique? Quelles preuves seront conservées? Quel support reste-t-il si l'outil est désactivé? Ces termes transforment une relation de confiance vague en un modèle opérationnel responsable.

Une petite entreprise peut ne pas avoir le levier pour négocier chaque clause. C'est pourquoi les normes industrielles, les conseils publics, les assureurs et les modèles d'approvisionnement comptent. Si de nombreux clients posent les mêmes questions, les MSP peuvent construire des réponses reproductibles. Si aucun client ne pose de questions, le plan de contrôle reste invisible jusqu'à ce qu'un incident l'expose. L'événement Kaseya devrait rendre l'administration invisible plus difficile à vendre.

Cela ne signifie pas que chaque MSP doit divulguer des détails internes sensibles à chaque client. L'architecture de sécurité peut être décrite au bon niveau: autorité, dépendance, notification, preuve et récupération. Le client n'a pas besoin du code d'exploitation ou des mots de passe d'administration. Il a besoin de savoir ce qui peut arriver à son entreprise si l'outil du prestataire est compromis et ce que le prestataire est obligé de faire ensuite.

Note typographique

Inconnus résiduels

Le dossier public n'établit pas chaque demande d'exploitation, chaque MSP affecté, chaque impact commercial en aval, ni chaque horodatage de notification client. Il ne prouve pas que les attaquants ont appris les vulnérabilités à partir du processus de divulgation coordonnée. La découverte parallèle est plausible et ne devrait pas être convertie en accusation non étayée. Il ne divulgue pas chaque contrôle provisoire pré-attaque ni chaque opérateur contacté avant le 2 juillet. Il ne valide pas indépendamment l'efficacité de chaque contrôle ultérieur de Kaseya ou des MSP.

Ces limites ne rendent pas l'incident inconnaissable. Elles définissent les preuves encore nécessaires pour une responsabilité solide des services gérés. Les faits les plus solides sont suffisants: des chercheurs avaient signalé en privé de graves faiblesses de VSA; des correctifs étaient en cours; le service hébergé avait reçu les correctifs pertinents; les systèmes sur site restaient exposés; les attaquants ont utilisé l'autorité de VSA pour distribuer un ransomware; Kaseya et ses partenaires ont émis des conseils urgents d'arrêt et de récupération;

et les entreprises en aval ont subi des préjudices provenant souvent d'outils qu'elles n'exploitaient pas directement.

La question de responsabilité est donc pratique. Lorsqu'un plan de contrôle de services gérés est à risque, chaque partie qui en subira les conséquences peut-elle en voir assez, assez tôt, pour agir? En juillet 2021, la réponse était inégale. Certains acteurs ont agi rapidement une fois l'attaque connue. De nombreuses organisations en aval dépendaient encore de la détection de quelqu'un d'autre, de la décision d'arrêt de quelqu'un d'autre et de l'explication de quelqu'un d'autre. C'est le problème de responsabilité en aval que Kaseya a rendu visible.