KASEYA a transformé le retard de détection des services gérés en 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 touchées dépendaient de la notification et de la récupération des MSP bien qu'elles n'exploitent pas directement VSA.
• Les preuves publiques montrent que KASEYA travaillait déjà avec DIVD dans le cadre d'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 de KASEYA après l'alerte, notamment l'arrêt de VSA hébergé, le conseil aux clients sur site d'arrêter leurs serveurs, l'appel à des intervenants, le contact 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 ou sur la rapidité avec laquelle les clients en aval ont reçu des conseils utilisables.
• Le dénominateur des victimes est stratifié. KASEYA a décrit plus tard 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.
• La norme 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 parcouru la chaîne de services

L'incident KASEYA est souvent décrit comme une attaque de ransomware de la chaîne d'approvisionnement. C'est globalement exact, mais l'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 livré une mise à jour malveillante. Lerésumé de l'incident et détails techniquesde KASEYA indique que les attaquants ont exploité des vulnérabilités zero-day dans VSA sur site, contourné l'authentification, exécuté des commandes et utilisé les fonctionnalités standard de VSA pour déployer un ransomware sur les terminaux gérés. Le chemin de confiance passait par l'autorité d'administration, et non par un paquetage 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 (MSP) utilisent ce type d'outils pour inventorier les appareils, effectuer la maintenance, déployer des logiciels et assister 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 moment, les charges utiles ou les signalements 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 l'ensemble de la chaîne.

Lecommuniqué de presse de KASEYA du 5 juillet 2021indique que des sources internes et externes ont alerté l'entreprise d'une attaque potentielle vers 14 h, heure de l'Est, le 2 juillet, et que l'entreprise a agi dans l'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 large: quand le risque est-il devenu connaissable à chaque niveau, et à quelle vitesse l'avertissement est-il passé du premier niveau informé aux entreprises qui allaient perdre leurs systèmes?

Huntress, qui a reçu les premiers signalements de partenaires touchés, a publiéun récapitulatif des événements et des leçons apprises. Leur compte rendu décrit des signalements MSP arrivant à peu près en même temps, le lien commun VSA, la préparation des charges, les actions de nettoyage et la livraison via des fonctions de gestion. Sophos a publié uncompte rendu techniquecontemporain du point de vue des terminaux et de la réponse. Ces récits d'intervenants ne sont pas des décomptes mondiaux de victimes, mais ils montrent pourquoi le retard de détection dans ce cas a été réparti. La première entreprise constatant le chiffrement n'était pas nécessairement celle qui avait l'autorité pour corriger VSA.

Ladéclaration publique du FBI sur l'attaque KASEYAa renforcé l'instruction d'arrêt et a exhorté au signalement. La CISA et le FBI ont publié plus tard des conseils conjoints viacet avis PDF, recommandant l'outil de détection, l'authentification multifacteur, la restriction des communications de gestion à distance, la protection VPN ou pare-feu pour les interfaces administratives, les sauvegardes protégées et le moindre privilège. Ce sont des mesures post-découverte solides. La question non résolue est de savoir combien d'exposition aurait pu être réduite avant que le temps imparti par les criminels ne s'écoule.

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 fournisseur était le vecteur, et où les agences publiques pouvaient transformer les rapports d'incident en avertissement plus large. L'incident a transformé une plateforme de gestion concentrée en un problème de relais.

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

Le dossier pré-exploitation est particulièrement important car il résiste à la fois à la condamnation facile et à l'absolution facile. Ladivulgation limitéede DIVD indique 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. C'est important. Les preuves publiques ne soutiennent pas l'affirmation simple selon laquelle le fournisseur a ignoré les signalements responsables.

Ledossier de castenu par DIVD montre l'autre côté de la chronologie. Le cas impliquait plusieurs vulnérabilités. Certaines ont été corrigées avant juillet. L'environnement hébergé de KASEYA a reçu des correctifs pertinents avant l'attaque. Les serveurs VSA sur site nécessitaient encore une action lorsque l'événement de ransomware a commencé. DIVD a publié plus tard lesdétails complets des vulnérabilités, y compris CVE-2021-30116, et l'entrée CVE-2021-30116du NVD enregistre maintenant que le problème a été exploité dans la nature.

Cette séquence crée une norme de responsabilité stricte. Un fournisseur qui travaille avec des chercheurs de bonne foi peut encore faire face à un échec en aval si la correction, la réduction de l'exposition et l'avertissement des 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 corrections avant les détails publics. Elle crée également une période pendant laquelle un petit nombre de personnes savent qu'un produit à haut impact est vulnérable alors que de nombreux opérateurs n'en savent pas assez pour changer de 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 des clients. Si une faiblesse critique d'authentification ou d'autorisation existe sur un serveur VSA exposé à Internet, la conséquence plausible n'est pas seulement la compromission d'un serveur. C'est une action malveillante sur chaque terminal qui fait confiance à ce serveur. Cela signifie que les contrôles intermédiaires doivent être traités comme faisant partie du processus de divulgation, et non comme un durcissement facultatif après un correctif.

Les archives publiques laissent plusieurs questions pré-attaque sans réponse. Quels opérateurs exposés KASEYA a-t-elle contactés en privé avant le 2 juillet? Quelles restrictions intermédiaires exactes étaient requises ou recommandées? Les interfaces de gestion ont-elles été placées derrière des VPN ou des règles de pare-feu dédiées? Les clients à haut risque sur site ont-ils été invités à arrêter leurs serveurs jusqu'à ce qu'un correctif soit disponible? Comment KASEYA a-t-elle vérifié que les systèmes exposés connus changeaient d'état?

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

KASEYA a publié plus tard des avis tels que l'avis important du 4 août 2021et des documents de récupération supplémentaires, tout en fournissant unepage d'outil de détection de compromission. Ces documents faisaient partie du dossier de contrôle post-incident. Ils ne reconstituent pas à eux seuls 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 doit inclure une réduction observable de l'exposition bien avant le titre public.

Le conseil d'arrêt a exposé la fracture entre les installations sur site

KASEYA pouvait arrêter l'environnement qu'elle exploitait. Elle ne pouvait pas arrêter directement chaque serveur VSA exploité par les clients. Cette distinction est au cœur du problème de détection-divulgation. Un produit hébergé donne au fournisseur le 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 d'exécution 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 mis en œuvre un vendredi de week-end férié.

Ce n'était pas un simple inconvénient. Chaque minute dans le relais comptait parce que les attaquants utilisaient des fonctions d'administration de confiance. Un message de KASEYA devait atteindre un responsable 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 des clients, et le MSP devait confirmer que les procédures malveillantes n'étaient pas déjà en file d'attente ou exécutées. Les clients en aval devaient alors savoir si leurs propres systèmes étaient sûrs, chiffrés, déconnectés ou en attente de restauration.

Le relais comprenait des étapes techniques, commerciales et de communication avec les clients.

Lesconseils conjoints CISA-FBIreconnaissaient que la réponse n'était pas seulement « appliquer un correctif ». Ils soulignaient l'arrêt des serveurs VSA, l'exécution de l'outil de détection, la préservation des sauvegardes, la restriction des communications de gestion à distance et l'utilisation du moindre privilège. Ces conseils tenaient compte de 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 nettoyer l'état malveillant ou réduire l'exposition.

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

Ce dénominateur stratifié affecte la qualité de la notification. Un client direct de KASEYA peut recevoir des conseils du fournisseur. Une petite entreprise desservie par un MSP peut recevoir un e-mail, 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 de gouvernement local ou un détaillant peut ne pas connaître du tout le terme VSA. Pourtant, sa continuité dépendait de l'état de VSA et de la réponse du MSP. La partie qui subit les conséquences de l'interruption pourrait être 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 qu'il advient de la surveillance et de 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 conditions, la première conversation claire sur la responsabilité peut avoir lieu après le chiffrement, lorsque toutes les parties sont sous pression et que les faits sont incomplets.

Le dénominateur aval a modifié les dommages

Le nombre de victimes directes de KASEYA était faible par rapport à sa clientèle totale, et KASEYA a souligné à juste titre que tous les clients n'avaient pas été touchés. Ce fait doit être préservé. Il ne doit pas être utilisé pour minimiser la portée opérationnelle de l'événement. L'incident a compté parce que certains clients directs touchés étaient des fournisseurs de services gérés. Un seul MSP peut relier 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 rapport de Reuters selon lequel unecyberattaque contre le fournisseur informatique américain a forcé la chaîne suédoise à fermer 800 magasins. Des rapports ultérieurs ont décrit des entreprises touchées confrontées à une récupération qui pourrait prendre dessemaines. Ces comptes rendus ne doivent pas être traités comme une liste complète des victimes. Ils montrent comment une compromission de gestion à distance peut atteindre des services destinés au public que les consommateurs perçoivent comme des portes fermées, des paiements indisponibles ou des opérations locales interrompues.

Pour les petites et moyennes entreprises, les services gérés sont rationnels. Ils donnent accès à une main-d'œuvre spécialisée, à la surveillance, à la gestion des sauvegardes, aux correctifs et au support 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 MSP, un outil à distance, un modèle de sauvegarde et un personnel de récupération. Un événement de ransomware à ce niveau peut faire échouer simultanément de nombreux plans de continuité supposément 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 en contact avec le public dépendent souvent des MSP ou d'un support externalisé similaire. Les citoyens touchés par une interruption ne se soucient pas de savoir si un outil était géré par un employé de l'agence, un contractant, un revendeur ou un éditeur de logiciels. Ils ont besoin que les services soient rétablis. Le chemin de la responsabilité, cependant, passe par ces relations techniques, et des retards peuvent être introduits à chaque passage de relais.

C'est là que la détection et la divulgation deviennent économiques. Une petite entreprise qui apprend rapidement peut déconnecter des 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, la frustration des clients, l'incertitude des rapports réglementaires et la paperasse 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 publié plus tard des conseils plus larges pour protéger les relations entre fournisseurs de services gérés et clients, annoncés par la CISA danscet avis. Ces conseils reflètent un point systémique: la sécurité des MSP n'est pas uniquement le 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 d'application de la loi. Le ministère de la Justice a annoncé en 2021 qu'un ressortissant ukrainien avait étéarrêté et inculpéen lien avec l'attaque de ransomware. Europol a annoncé quecinq affiliés liés à Sodinokibi/REvil avaient été déconnectés. Le ministère de la Justice a annoncé plus tard qu'un affilié de Sodinokibi/REvil avait étécondamnépour un rôle plus large dans un système de 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 les 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, ni 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 viaGovInfoa capté l'inquiétude du public sur les ransomwares, les services critiques et la préparation du secteur privé. La surveillance peut faire émerger des tendances et révéler des besoins politiques. Elle ne peut toujours pas remplacer les preuves au niveau des entités sur les délais de détection, le contenu des notifications, l'exécution des arrêts et la qualité de la restauration.

La normeSP 800-161 Rev. 1du NIST fournit un vocabulaire plus large sur les risques de la chaîne d'approvisionnement. Elle 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 KASEYA montre pourquoi ce vocabulaire doit inclure des 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 des clients 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 stratifiées. KASEYA devrait montrer la remédiation de la sécurité des produits, la maturité de la réception des vulnérabilités, les canaux d'avertissement des clients et les attentes de sécurité par défaut pour les déploiements à haut risque. Les MSP devraient montrer un accès administratif restreint, l'application de l'authentification multifacteur, la segmentation, le moindre privilège, des sauvegardes protégées, des guides de notification aux clients et des exercices sur table incluant la compromission d'outils.

Les clients en aval devraient montrer qu'ils savent quels outils du fournisseur 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 ne supprime le besoin de ces dossiers. Un affilié de ransomware peut être arrêté tandis qu'une entreprise ne dispose toujours pas d'une sauvegarde récupérable. Un fournisseur peut publier un correctif tandis qu'un MSP n'a pas contacté tous ses clients. Un avis gouvernemental peut être correct tandis que la plus petite entreprise touchée ne comprend toujours pas ce qui s'est passé. La responsabilité doit atteindre le niveau où les dommages surviennent.

L'observabilité est la norme de réparation

La question de second plan pour KASEYA n'est pas de savoir si les services gérés sont mauvais. Les services gérés peuvent améliorer la sécurité des organisations qui auraient autrement peu de soutien. La question est de savoir si le risque créé par une 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 à haut risque lorsque les licences et la télémétrie le permettent. Les agences publiques devraient savoir comment contacter les fournisseurs de services critiques lorsqu'un incident MSP menace les services communautaires.

L'observabilité se poursuit avec le chronométrage 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, le premier avis MSP-client, le premier chiffrement en aval, le premier résultat de l'outil de détection et le moment où chaque partie touché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 un retard avant un autre.

L'observabilité nécessite également une discipline de dénominateur. Moins de 60 clients directs, 57 clients sur site, jusqu'à 1 500 entreprises en aval et d'innombrables terminaux 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 des dommages à la continuité. Un décompte de terminaux parle de la 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 tous les détails de l'exploit dans la première heure. Elle a besoin de savoir si l'outil de gestion à distance de son fournisseur a été 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 dommages 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 lorsque la divulgation publique augmenterait le risque, des limites d'exposition par défaut plus strictes, 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 puisse 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 pour les notifications, pas seulement d'un objectif de remédiation. Dans une vulnérabilité logicielle ordinaire, l'opérateur qui reçoit l'avis du fournisseur est souvent la même organisation qui subira les conséquences si le système reste exposé. Dans les services gérés, l'opérateur et le client qui supporte 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 nécessite 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é grave 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éétablie pour « incident de plan de contrôle du fournisseur » qui déclenche les communications avec le client avant même que chaque détail technique ne soit connu.

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

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

Si la compromission est confirmée, la notification devrait indiquer quels systèmes sont affectés, ce que fait le fournisseur, ce que le client doit faire et quelles preuves doivent être préservées.

La deuxième notification devrait cartographier la dépendance. De nombreux clients ne connaissent pas les noms des produits derrière les services gérés. Une entreprise peut comprendre « notre fournisseur informatique 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 d'administration si le MSP ne nomme pas le plan de contrôle impliqué.

Les contrats devraient spécifier quand l'identité du produit peut être divulguée aux clients en cas d'urgence 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, la surveillance de routine, le déploiement de logiciels, le support à distance et certaines fonctions de réponse de sécurité peuvent être altérés. 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 des délais prévus. Une instruction d'arrêt qui protège la sécurité peut encore nuire à la continuité si personne n'explique les conséquences sur le 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é changés, si les conseils des forces de l'ordre ou de la CISA sont pertinents et si le fournisseur a utilisé l'outil de détection de KASEYA ou d'autres preuves d'intervention. Un client qui ne reçoit que « nous y travaillons » ne peut pas prendre ses propres décisions juridiques, d'assurance et de clientèle.

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 fournisseur, 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 des services gérés est délégué; la responsabilité ne peut 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é délicate: une action de sécurité peut être une action perturbatrice pour les affaires. Arrêter une plateforme de gestion à distance peut réduire la portée des attaquants, mais peut également supprimer le principal moyen du MSP pour soutenir les clients. Si le MSP n'a pas préautorisé qui peut prendre cette décision, la réponse peut s'enliser au pire moment possible.

La préautorisation devrait spécifier qui peut désactiver l'outil, sous quel seuil de preuve et comment les clients sont informés. Elle devrait également spécifier quelles fonctions restent disponibles après l'arrêt. Les techniciens peuvent-ils encore aider les clients par téléphone? Peuvent-ils utiliser un accès à distance alternatif? L'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 fournisseur ne se reconnectent?

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

La même logique s'applique au fournisseur. Pour un produit comme VSA, l'arrêt de l'environnement hébergé du fournisseur est sous le 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 présentent un risque élevé avant qu'un correctif ne soit prêt, il a besoin d'un modèle d'escalade privé: démarchage direct, avis de gravité élevée, suivi des cas de support et vérification lorsque cela est possible.

L'objectif n'est pas de culpabiliser les 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 aux ransomwares 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 isolées ou autrement protégées, car une compromission de la gestion peut menacer la récupération autant que la production.

Les clients ne devraient pas avoir à 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 dont elles disposent sur la résilience.

L'arrêt préautorisé aide également les assureurs et les régulateurs. Un client qui peut montrer qu'un fournisseur a suivi un guide d'arrêt et de notification documenté est dans une position différente d'un client qui reconstitue les décisions à partir d'e-mails éparpillés. La preuve d'une action préautorisée n'élimine pas les dommages, mais elle montre une gouvernance. Elle peut également réduire les litiges entre le fournisseur, le MSP, le client, l'assureur et les forces de l'ordre après l'événement.

Le dossier KASEYA montre qu'une action rapide après alerte est précieuse. La prochaine norme devrait avancer la décision et la rendre plus automatique lorsque le rayon d'action est clair. Un plan de contrôle de gestion à distance devrait être conçu pour tomber en panne fermée, avec un chemin connu pour fonctionner en mode réduit. Si l'arrêter 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 joue l'outil.

Les preuves en aval font partie du dossier produit

Les éditeurs de logiciels se concentrent naturellement sur les clients directs, mais les conséquences d'un produit de services gérés s'étendent à travers la base de clients de ces clients. Cela signifie que les preuves en aval font partie du dossier produit. Un fournisseur peut ne pas connaître chaque terminal ou chaque entreprise desservie par un MSP, mais il devrait concevoir les rapports d'incident 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 terminaux ont reçu des charges? Quels terminaux é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 a besoin de 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 précis, cet horodatage ancre l'enquête sur le terminal, la sélection des sauvegardes, les décisions de paie et la notification aux clients. Si le MSP ne peut pas fournir le moment, le client peut devoir traiter une période plus large comme suspecte, augmentant les coûts.

Le troisième problème est la garde des preuves. Les journaux peuvent se trouver sur le serveur VSA, chez le MSP, sur les terminaux, dans les outils de sécurité et chez le fournisseur. Pendant un événement de ransomware, certaines preuves peuvent être supprimées, chiffrées, écrasées ou déconnectées. Un produit mature devrait rendre les actions administratives à fort impact suffisamment durables pour que les intervenants puissent reconstituer ce qui s'est passé même si le serveur de gestion est compromis. Cela ne nécessite pas de publier de la télémétrie sensible au monde. Cela nécessite de concevoir pour la reconstruction d'incident.

Le quatrième problème est le langage adapté au 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 en raison de preuves manquantes, restauré à partir de la sauvegarde, identifiants changés, ou toujours en cours d'enquête.

« Inconnu » est acceptable lorsque c'est vrai; prétendre savoir ne l'est pas.

Le cinquième problème est une 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 l'entrée. L'exposition Internet ou la segmentation d'un MSP peut aggraver les dommages. Les sauvegardes faibles d'un client peuvent prolonger 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 les dommages. 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é touchés si le rôle économique du produit est d'administrer de nombreuses autres 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, terminaux et services. L'événement KASEYA est devenu un jalon parce que toutes ces couches ont compté en même temps.

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

De nombreux clients de services gérés n'achètent pas directement KASEYA VSA. Ils achètent des résultats: des ordinateurs portables corrigés, une messagerie fonctionnelle, des imprimantes accessibles, des serveurs surveillés, un support technique et une récupération après une panne. Le produit de gestion à distance est caché derrière la promesse de service. Cette invisibilité peut être efficace en temps normal, mais lors d'un incident de ransomware, elle laisse le client sans carte. Un client ne peut pas évaluer 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 fournisseurs privilégiés même s'ils ne publient pas chaque configuration sensible. Le client devrait savoir si le MSP utilise des logiciels de surveillance et de gestion à distance, de détection et de réponse sur les terminaux, des consoles de sauvegarde, des courtiers de bureau à distance, des moteurs de script, une administration des identités 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 la compromission d'un outil sera gérée. Le MSP avertira-t-il le client si un outil fournisseur privilégié est activement exploité? Qui décide de déconnecter les agents du fournisseur? Le client recevra-t-il une liste des terminaux affectés? Dans quel délai le MSP fournira-t-il des faits écrits pour l'examen de l'assurance et des aspects juridiques? Quelles preuves seront conservées? Quel support reste disponible si l'outil est désactivé? Ces conditions transforment une relation de confiance vague en un modèle opérationnel responsable.

Une petite entreprise peut ne pas avoir le poids pour négocier chaque clause. C'est pourquoi les normes du secteur, les conseils publics, les assureurs et les modèles d'approvisionnement comptent. Si de nombreux clients posent les mêmes questions, les MSP peuvent élaborer des réponses reproductibles. Si aucun client ne demande, 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, preuves et récupération. Le client n'a pas besoin du code d'exploitation ou des mots de passe administratifs. Il a besoin de savoir ce qui peut arriver à son entreprise si l'outil du fournisseur est compromis et ce que le fournisseur est obligé de faire ensuite.

Note sur la typographie

La typographie est l'art et la technique d'arranger les caractères pour rendre le langage écrit lisible, compréhensible et visuellement attrayant. Elle implique la sélection des polices de caractères, des tailles de points, des longueurs de ligne, de l'interlignage et de l'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés incluent le choix de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Inconnues résiduelles

Les archives publiques n'établissent pas chaque demande d'exploitation, chaque MSP affecté, chaque impact sur les entreprises en aval ou chaque horodatage de notification aux clients. Elles ne prouvent pas que les attaquants ont eu connaissance des vulnérabilités grâce au processus de divulgation coordonnée. La découverte parallèle est plausible et ne doit pas être transformée en une accusation non étayée. Elles ne divulguent pas chaque contrôle intermédiaire avant l'attaque ni chaque opérateur contacté avant le 2 juillet. Elles ne valident 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 solide responsabilité des services gérés.

Les faits connus les plus solides suffisent: des chercheurs avaient signalé en privé de graves faiblesses de VSA; des correctifs étaient en cours; le service hébergé avait reçu des 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 publié des instructions urgentes d'arrêt et de récupération; et les entreprises en aval ont subi des dommages qui provenaient 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 en danger, chaque partie qui en subira les conséquences peut-elle voir suffisamment, 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.