Okta: les artefacts de support, un test de responsabilité de la confiance envers les tiers

Résumé

• Le compromis du système de support d'Okta est devenu un test de responsabilité car les fichiers de cas de support et les artefacts de dépannage peuvent contenir des cookies de session, des jetons, le contexte de l'administrateur et des informations de locataire suffisamment puissants pour affecter les environnements clients, même si le service d'identité de base de production n'est pas lui-même compromis.
• L'avis initial d'Okta d'octobre 2023, lepost sur la cause racine et la correctionde novembre, lamise à jour et les actions recommandéesultérieures, et lanote de clôture d'enquêtede février 2024 constituent le dossier du fournisseur.
• Les rapports clients de1Password,BeyondTrustetCloudflaremontrent comment les artefacts de support ont pu se traduire par un travail de réponse au niveau du locataire et un confinement côté client.
• Leformulaire 8-K, l'annexe 99.2, leformulaire 10-Qet leformulaire 10-Kd'Okta déposés auprès de la SEC importent car la divulgation par une société cotée en bourse a placé l'incident de support dans les relations clients, le risque lié aux fournisseurs tiers et les effets commerciaux.
• La question de la réparation est de savoir si Okta et ses clients peuvent prouver que le traitement des fichiers de cas de support, la rédaction HAR, la liaison de session, le provisionnement du système de support, la notification et la détection client correspondent désormais à l'autorité que les workflows de support des fournisseurs d'identité peuvent accidentellement porter.

Le support fait partie de la frontière d'identité

Les systèmes de support sont souvent traités comme en dehors de la frontière du produit. Ils se situent dans les workflows de service client, les outils de gestion de cas, les pièces jointes de fichiers, les fils de discussion par e-mail et les enregistrements de dépannage. L'incident d'Okta en 2023 a remis en question cette séparation. La société a déclaré dans sonavis du 20 octobrequ'un adversaire avait utilisé un identifiant volé pour accéder au système de gestion des cas de support et consulter les fichiers téléchargés par certains clients dans le cadre de cas de support. Okta a également averti que les fichiers HAR peuvent contenir des données sensibles, y compris des cookies et des jetons de session.

C'est le pivot de la responsabilité. Si un artefact de support contient un cookie ou un jeton de session actif, il peut fonctionner comme une clé même si le service d'identité principal n'a pas été violé. Le workflow de support devient une partie de la frontière de confiance pratique car il reçoit du matériel qui peut représenter une session authentifiée. La frontière n'est pas là où le diagramme du produit le dit. Elle est là où une autorité sensible peut être stockée, consultée, copiée, rejouée ou abusée.

Lepost sur la cause racine et la correctiondu 3 novembre d'Okta décrivait un accès entre le 28 septembre et le 17 octobre, des fichiers associés à 134 clients, cinq sessions clients détournées à l'aide d'artefacts de session provenant de fichiers consultés, un compte de service support compromis et une voie d'exposition probable des identifiants impliquant le profil Google personnel ou l'appareil d'un employé. Cet enregistrement est rédigé par l'entreprise, et la voie la plus probable ne doit pas être surestimée comme une preuve indépendante. Mais le fait clé est direct: Okta a déclaré que des artefacts de session provenant de fichiers de support ont été utilisés pour détourner cinq sessions.

La distinction entre compromission du service de production et compromission des artefacts de support est importante. Okta a déclaré que son service Okta de production n'a pas été compromis. Une analyse responsable devrait préserver cela. Mais le préserver ne minimise pas l'incident. Pour les fournisseurs d'identité, la confiance client inclut les workflows environnants qui gèrent les preuves des locataires, le dépannage des administrateurs, les fichiers de support et les notifications. Un service de production peut rester intact pendant qu'un workflow de support crée toujours un risque pour le locataire.

C'est pourquoi l'incident fait partie d'un enregistrement de frontière de confiance. Les fournisseurs d'identité demandent aux clients de centraliser l'authentification et les décisions d'accès. Le système de support environnant doit être gouverné comme s'il pouvait temporairement détenir des morceaux de cette autorité. Un ticket de support n'est pas seulement une conversation. Il peut devenir un chemin d'accès.

Les fichiers HAR ont fait de la commodité de diagnostic une question de sécurité

Les fichiers d'archive HTTP sont utiles car ils capturent l'activité réseau du navigateur pour le dépannage. Ils peuvent également contenir des informations sensibles. La documentation d'Okta surla génération de fichiers HARavertit les clients de supprimer les données confidentielles ou personnellement identifiables avant d'envoyer un fichier à Okta. La documentation des développeurs de Chrome surl'enregistrement des requêtes réseau dans un fichier HARexplique le comportement d'exportation du navigateur et la gestion actuelle des en-têtes sensibles. Ces sources montrent le compromis de diagnostic: le support peut avoir besoin de suffisamment de détails pour reproduire un problème, mais les mêmes détails peuvent exposer une session.

Le guide des développeurs d'Okta surles cookies de sessionexplique comment les sessions du navigateur fonctionnent dans la plateforme Okta. Lacheatsheet de gestion de sessiond'OWASP et laressource d'implémentation de gestion de sessiondu NIST fournissent le principe général de sécurité: un identifiant de session peut être temporairement équivalent à l'authentification qui l'a créé, de sorte que sa divulgation peut permettre l'usurpation d'identité. Ce sont des sources générales, pas des conclusions de l'incident Okta, mais elles expliquent pourquoi un fichier téléchargé sur le support peut être dangereux.

Le problème n'est pas que les fichiers HAR ne devraient jamais être utilisés. Le problème est que leur risque devrait être traité comme un problème de contrôle de support de première classe. Les clients ont besoin d'avertissements clairs, d'outils de rédaction locaux, d'une sanitation automatisée lorsque c'est possible, de valeurs par défaut de conservation minimale et d'instructions sur quand faire tourner les sessions après le téléchargement.

Les équipes de support ont besoin de workflows qui minimisent la visualisation de contenu sensible, journalisent l'accès aux fichiers et exigent des contrôles plus stricts pour les fichiers provenant de contextes d'administration.

Le post de Cloudflare surl'introduction de HAR Sanitizerest pertinent car il a transformé une leçon côté client en un outil pratique: supprimer les éléments sensibles sélectionnés avant le partage. Cela ne signifie pas qu'un désinfectant peut garantir que toutes les formes d'identifiants sont supprimées, ni que le support n'aura jamais besoin de données sensibles. Cela montre que la rédaction peut être conçue comme un workflow, et non laissée à la mémoire de l'utilisateur.

La leçon plus large est que la commodité de diagnostic emprunte souvent de l'autorité. Un fichier collecté pour résoudre un problème de connexion peut inclure les preuves nécessaires pour usurper cette connexion. Un workflow de support conçu pour la rapidité peut contourner accidentellement la discipline appliquée au chemin d'identité de production. Si l'artefact de dépannage peut déverrouiller un locataire, le processus de téléchargement, le processus de conservation, le processus d'accès au support et les conseils de rotation de session doivent être traités comme des contrôles d'identité.

Les rapports clients ont révélé la forme en aval

Les rapports des clients affectés ont concrétisé l'incident. Lerapport d'incident Oktade 1Password décrivait une activité administrative inattendue, un confinement et des addenda ultérieurs liant l'événement au compromis de support d'Okta. Lerapport de violation de l'unité de support Oktade BeyondTrust décrivait un fichier HAR demandé par le support, le rejeu d'un cookie de session dans les 30 minutes, le refus de la politique de gestion des appareils, l'activité API et une tentative de compte de porte dérobée. Lerapport d'atténuationde Cloudflare décrivait la détection d'un jeton de session administrative lié à un ticket de support Okta et un confinement avant tout impact sur la production ou les clients.

Ces rapports ne sont pas des affirmations universelles sur chaque client Okta. Ce sont des enregistrements primaires pour les environnements clients qui les ont publiés. Leur valeur est qu'ils montrent à quoi ressemblait le risque d'artefact de support du côté du locataire. Les clients ont dû détecter une activité inhabituelle, révoquer des sessions, faire tourner des identifiants, enquêter sur des actions administratives, faire pression sur le fournisseur pour obtenir des informations et décider quoi dire à leurs propres utilisateurs. L'incident n'a pas été contenu uniquement au sein de l'organisation de support d'Okta.

Les rapports clients montrent également l'importance du moment de la notification. Lorsqu'un fournisseur détecte un accès suspect à des artefacts de support, les clients affectés ont besoin de suffisamment d'informations pour agir. Ils ont besoin d'identifiants d'utilisateur, d'identifiants de fichier, d'heures d'accès, d'indicateurs, du risque probable de session et des rotations recommandées. Un avis vague peut laisser les clients soit sous-réagir, soit sur-réagir. Les deux ont un coût. La sous-réaction laisse les sessions exposées. La sur-réaction consomme du temps de sécurité et d'exploitation.

Lerapport d'incident de sécurité de Thanksgiving 2023de Cloudflare fait également partie de la leçon de réparation. Cloudflare a déclaré qu'un jeton d'accès et trois identifiants de compte de service issus de l'exposition d'octobre n'avaient pas été renouvelés et ont ensuite été utilisés dans un incident distinct en novembre affectant les systèmes Atlassian, tout en ne signalant aucun impact client ou réseau mondial. Cela n'attribue pas le compromis de support original d'Okta à l'acteur ultérieur. Cela montre comment une rotation manquée après un incident d'artefact de support peut devenir un risque de suivi.

La frontière de support s'étend donc à la réponse aux incidents clients. Un fournisseur contrôle le système de support, mais les clients doivent faire tourner, surveiller et vérifier leurs locataires. Si le fournisseur ne peut pas fournir rapidement des données précises sur les artefacts et l'accès, la réponse client devient une conjecture. C'est un problème de responsabilité du fournisseur, même lorsque le client possède les contrôles côté locataire.

L'exposition plus large du rapport a changé l'économie des abus

Lamise à jour et les actions recommandéesdu 29 novembre d'Okta décrivaient un rapport non filtré téléchargé contenant les noms et adresses e-mail des utilisateurs du système de support dans certaines populations de clients, avec des exclusions de produits et d'environnements. Okta a déclaré que 99,6 % des utilisateurs du rapport n'avaient que leur nom complet et leur adresse e-mail exposés. Cette population est distincte du groupe d'accès aux fichiers de 134 clients et des cinq sessions détournées. Garder ces groupes distincts est essentiel.

Le rapport plus large importait néanmoins car il a changé l'économie des abus. Les noms et adresses e-mail des personnes associées aux systèmes de support peuvent aider les attaquants à cibler les administrateurs, les centres d'assistance, les équipes de sécurité et les rôles de support d'identité. L'alerte de cybersécuritéde la FINRA concernant les potentielles attaques de phishing liées au système de support client Okta avertissait les entreprises membres d'un risque possible de phishing et d'ingénierie sociale. Cette alerte était un conseil sur les risques, pas une preuve que tous les contacts exposés avaient été exploités. Mais elle montre pourquoi les données de contact des utilisateurs de support ne sont pas anodines.

Les contacts de support sont précieux car ils identifient des personnes susceptibles d'avoir un accès, une autorité ou une influence sur les systèmes d'identité. Un e-mail de phishing envoyé à un employé au hasard est une chose. Un message ciblé à un administrateur de support connu après un incident public chez un fournisseur en est une autre. Les données volées peuvent ne pas inclure de mots de passe ou de jetons, mais elles peuvent réduire le coût de recherche de l'attaquant. Dans les systèmes d'identité, réduire le coût de recherche importe.

Leformulaire 8-Ket l'annexe 99.2d'Okta ont placé la mise à jour de novembre dans les canaux de divulgation d'une société cotée en bourse. Cette posture de dépôt ne fait pas de la SEC l'enquêteur des faits. Cela montre qu'Okta a traité la mise à jour comme suffisamment matérielle pour une distribution publique formelle en vertu du règlement FD.

La leçon sur les contacts d'abus est directe. Les listes d'utilisateurs du système de support doivent être traitées comme des cartes opérationnelles sensibles. Elles peuvent ne pas être aussi sensibles que les cookies de session, mais elles identifient les personnes que les attaquants veulent le plus manipuler. Les contrôles d'accès, de conservation, d'exportation et de surveillance autour de ces listes doivent correspondre à leur valeur d'ingénierie sociale.

Note typographique

L'hébergement par un tiers n'a pas déplacé le devoir hors de la frontière d'Okta

Leformulaire 10-Kde l'exercice 2024 d'Okta décrivait le système de support compromis comme hébergé par un fournisseur de services tiers et discutait des risques de supervision des fournisseurs. L'hébergement par un tiers importe car il ajoute une couche de contrôle du fournisseur. Il ne déplace pas la frontière de responsabilité loin d'Okta pour les clients. Les clients ont donné des artefacts au support d'Okta. Okta a sélectionné, configuré, provisionné, surveillé et gouverné le workflow de support qui a traité ces artefacts.

Les systèmes tiers sont normaux dans les opérations cloud modernes. Une entreprise peut raisonnablement utiliser des plateformes de gestion de cas externes, des services de stockage, des outils de communication et des applications de support. La question de responsabilité est de savoir si le fournisseur les gouverne en fonction de la sensibilité des données qu'ils détiennent. Un système de support pour un fournisseur d'identité doit être traité différemment d'une file d'attente de tickets à faible sensibilité. Le risque pour le locataire est différent.

La gouvernance des fournisseurs devrait inclure des comptes de service à privilège minimal, une protection renforcée des identifiants, des contrôles de session, des limites de conservation, une journalisation de l'accès aux fichiers, des contrôles d'exportation, une détection des anomalies et une production rapide de preuves. Elle devrait également inclure une règle claire pour les profils personnels, les navigateurs et les appareils des employés lorsque les identifiants du système de support sont présents.

Le post de novembre d'Okta sur la cause racine discutait d'une voie la plus probable impliquant le profil Google personnel ou l'appareil d'un employé. Que cette voie exacte soit prouvée indépendamment ou non, elle souligne une question de base sur le fournisseur et le point d'extrémité: un identifiant de support peut-il être exposé via des canaux de synchronisation grand public ou d'utilisation personnelle?

Le système de support a également besoin d'un modèle de notification différent. Si un attaquant accède à des artefacts téléchargés par les clients, le fournisseur doit savoir quel client, quel fichier, quel cas, quel utilisateur, quelle heure d'accès et quelle action recommandée. Si la journalisation du système ne capture pas certaines routes de navigation, comme Okta l'a décrit dans son récit de cause racine, l'enquête peut initialement manquer des événements. Ce n'est pas simplement un défaut de journalisation. Cela affecte directement la vitesse de confinement du client.

La couche tierce augmente donc, plutôt que de diminuer, le besoin de preuves de gouvernance du fournisseur. Les clients ne peuvent pas inspecter directement le fournisseur de support du fournisseur. Ils comptent sur Okta pour gérer cette relation. Si le fournisseur de support ou le workflow de support touche les artefacts du locataire, le fournisseur doit aux clients la preuve que le système délégué est gouverné comme faisant partie de la frontière de confiance d'identité.

La détection doit relier les cas de support aux événements du locataire

Le post de sécurité d'Okta surles événements de connexion et de récupération dans le journal système Oktaexplique comment les clients peuvent rechercher par utilisateur, IP, ID de session externe, authentification, MFA, réinitialisation de mot de passe et événements de récupération. Ce guide est utile car il pointe vers le type de corrélation dont les clients avaient besoin pendant l'incident de support. Un artefact de cas de support, un identifiant de session, une IP suspecte et une action administrative doivent être connectables rapidement.

Les clients ne devraient pas avoir à déduire manuellement chaque connexion. Si un artefact de support est consulté dans un système du fournisseur, le fournisseur devrait pouvoir dire au client quelle session ou quel compte côté locataire pourrait être à risque, dans la mesure du possible. Le client devrait ensuite pouvoir rechercher cette session dans les journaux, la révoquer, faire tourner les identifiants associés et vérifier les modifications administratives. Les preuves du fournisseur et la télémétrie côté client doivent se rencontrer.

C'est particulièrement important pour les fournisseurs d'identité car le rayon d'explosion du client peut être large. Une session d'administrateur peut créer des comptes, modifier les paramètres MFA, altérer les politiques, ajouter des applications, extraire la configuration ou préparer une persistance. Une politique de gestion des appareils peut bloquer une tentative de rejeu, comme BeyondTrust l'a décrit, mais le client doit encore enquêter sur les tentatives de pivot. L'absence de compromission totale réussie ne signifie pas qu'il n'y a pas eu de charge de réponse.

La détection devrait également tenir compte du temps. Les artefacts de session expirent, mais pas toujours instantanément. Certains cookies ou jetons peuvent rester utiles assez longtemps pour être rejoués. Certains contrôles clients lient les sessions à des appareils ou des réseaux. D'autres non. Certains clients ont des journaux premium; d'autres ont une conservation plus courte. Les actions recommandées par le fournisseur devraient être réalistes à travers les niveaux de maturité des clients.

L'incident plaide également pour un durcissement par défaut des sessions. La liaison de session, des durées de vie plus courtes pour les sessions administratives, la réauthentification pour les actions sensibles, la MFA résistante au phishing, les vérifications d'état des appareils et l'alerte sur les anomalies de session liées au support peuvent toutes réduire la valeur d'un artefact de support volé. Ces contrôles n'éliminent pas le risque de support, mais ils réduisent la fenêtre pendant laquelle les fichiers de support peuvent être abusés.

La divulgation par une société cotée en bourse a montré les dommages à la confiance commerciale

Leformulaire 10-Q pour le trimestre clos le 31 octobre 2023d'Okta est important car il a cadré les effets de l'incident sur la réputation, les relations clients, les résultats financiers et les passifs potentiels. C'est plus qu'un langage de valeurs mobilières. Cela reconnaît qu'un fournisseur d'identité vend la confiance en tant que partie du produit. Un compromis du système de support nuit à cette confiance même si le service de base reste opérationnel.

L'impact sur le marché d'un incident d'identité n'est pas seulement l'attrition immédiate ou le coût de l'incident. Les clients peuvent réévaluer les pratiques de support, la gestion des jetons, les journaux des locataires, le risque fournisseur, les conditions de renouvellement et les fournisseurs d'identité alternatifs. Les équipes de sécurité peuvent passer du temps à prouver que leur locataire n'a pas été compromis. Les auditeurs peuvent demander des preuves. Les régulateurs peuvent s'attendre à une gestion plus stricte des risques fournisseurs.

Les interactions de support peuvent devenir plus lentes car les clients sont plus prudents sur ce qu'ils téléchargent.

Le langage sur le risque lié aux fournisseurs tiers dans le formulaire 10-K place l'événement dans un cadre de gouvernance plus large. Si les systèmes de support sont hébergés par des fournisseurs de services tiers, le propre programme de risque du fournisseur d'identité doit inclure ces systèmes. Les clients ne peuvent pas accepter une frontière de produit qui exclut le workflow de support même qu'on leur demande d'utiliser lorsque le produit échoue.

La divulgation publique devrait donc être évaluée en fonction de sa précision opérationnelle. Okta a-t-il clairement identifié les populations affectées? A-t-il séparé l'accès aux fichiers de l'exposition des rapports? A-t-il fourni des indicateurs et des actions recommandées? A-t-il mis à jour le périmètre lorsque le rapport non filtré a été reconstitué? A-t-il expliqué la réparation sans exagérer? Le dossier public contient plusieurs mises à jour, ce qui est bien. La question de responsabilité est de savoir si chaque mise à jour est arrivée assez tôt et était suffisamment détaillée pour que les clients puissent agir.

Le cas montre également comment la divulgation peut mûrir. Un avis initial peut être incomplet. Une analyse ultérieure de la cause racine peut corriger ou élargir les faits. Une note de clôture peut résumer une enquête externe. Les dépôts de sociétés cotées en bourse peuvent discuter du risque commercial. Les clients doivent comprendre quel document fait quel travail. Un avis sur un blog n'est pas un rapport médico-légal complet; un dépôt n'est pas une liste d'indicateurs spécifiques au locataire; une note de clôture n'est pas une preuve de chaque action client.

Les artefacts de support ont besoin de contrôles de cycle de vie

La réparation la plus pratique est un cycle de vie des artefacts de support. Avant le téléchargement, les clients devraient recevoir des instructions claires et de préférence des outils pour supprimer les informations sensibles. Pendant le téléchargement, le système de support devrait classer l'artefact, restreindre l'accès et avertir si des jetons ou secrets probables apparaissent. Pendant le traitement du support, les visualisations et téléchargements de fichiers devraient être journalisés et les accès anormaux devraient alerter. Après la résolution, les artefacts devraient expirer ou être supprimés selon une politique de conservation.

Si un artefact est accédé pendant un incident, les clients devraient recevoir des conseils d'action précis.

Ce cycle de vie devrait être plus strict pour le support des fournisseurs d'identité que pour de nombreux autres services d'assistance. Un fournisseur d'identité se trouve près des clés de l'accès à l'entreprise. Les artefacts de support peuvent inclure des sessions d'administrateur, la configuration du fournisseur d'identité, les connexions d'application, les détails des utilisateurs et les traces de dépannage. Traiter ces artefacts comme des pièces jointes ordinaires invite à un décalage entre la sensibilité et le contrôle.

Les clients ont également besoin de leur propre cycle de vie. Ils devraient éviter de télécharger des captures de session d'administrateur en direct dans la mesure du possible, utiliser des exportations HAR sanitaires, créer des sessions de test de courte durée pour le dépannage, révoquer les sessions après le partage et documenter quels identifiants ou jetons pourraient apparaître dans les fichiers de support. Ils devraient faire de la rotation des artefacts de support un élément standard de la réponse aux incidents, et non une réflexion après coup.

Mais la discipline client ne peut pas remplacer la conception du fournisseur. Un fournisseur ne peut pas supposer que chaque client sanitisera parfaitement sous pression. Le workflow devrait être résistant aux erreurs humaines. Si un client télécharge un fichier avec un cookie de session actif, le système devrait réduire les dommages grâce à une conservation courte, un accès restreint, une rédaction, une détection et un avis rapide. Dans la sécurité du support, « lire l'avertissement » ne suffit pas.

Le dossier de réparation devrait inclure des preuves mesurables: moins de personnes ayant accès aux fichiers de support, des contrôles de compte de service plus forts, une couverture de journalisation améliorée, des sauvegardes automatisées d'exportation de rapports, une conservation plus courte des artefacts, des rapports d'impact spécifiques aux clients, des recommandations sur les risques de session et des procédures de notification testées. Une affirmation publique selon laquelle la sécurité du support s'est améliorée est plus faible qu'une liste de catégories de contrôle concrètes.

La réparation de la frontière de confiance doit être visible pour les clients

Lanote de clôture d'enquêtede février 2024 d'Okta indiquait que Stroz Friedberg avait terminé son enquête, n'avait trouvé aucune preuve au-delà des activités précédemment déterminées, et faisait référence à des rapports d'impact personnalisés, des notifications aux régulateurs et aux forces de l'ordre, un examen du provisionnement et de la conservation du système de support, et des contrôles ultérieurs. Cette clôture est significative, mais le dossier public externe reste borné car le rapport médico-légal complet n'a pas été publié à l'URL de clôture.

La réparation visible par les clients est donc essentielle. Les entreprises n'ont pas besoin de chaque détail sensible de l'infrastructure de support d'Okta. Elles ont besoin de suffisamment de preuves pour évaluer le risque fournisseur: quelles familles de contrôle ont changé, quelles actions clients sont recommandées, comment les artefacts de support sont conservés, comment les exportations sont gouvernées, comment les comptes de service sont protégés, comment l'accès aux fichiers est journalisé, et à quelle vitesse un accès futur aux artefacts sera signalé.

Le standard de responsabilité durable n'est pas qu'aucun workflow de support ne puisse jamais être compromis. Il est que les workflows de support ne devraient pas porter silencieusement l'autorité du locataire sans contrôles proportionnés à cette autorité. Si le support doit recevoir des artefacts puissants, le workflow devrait minimiser, rédiger, lier, expirer, surveiller et notifier. Si un système de support tiers héberge ces artefacts, la gouvernance du fournisseur devrait être visible pour les clients dans les documents de confiance et les rapports d'incident.

L'incident d'Okta appartient également à l'économie plus large du risque de contacts d'abus. Une liste d'utilisateurs de support, un administrateur connu, un incident récent et une marque de fournisseur de confiance peuvent être combinés dans du phishing ou de l'ingénierie sociale. Le système de support ne détient pas seulement des fichiers. Il détient une carte des personnes qui interagissent avec l'infrastructure d'identité. Cette carte devrait être protégée car les attaquants la prisent.

La leçon finale est que la frontière d'identité suit l'autorité, pas la marque. Si un fichier de dépannage peut devenir une session, si un compte de support peut consulter ce fichier, si un système de cas tiers peut le stocker, et si un client doit faire tourner après y avoir accédé, alors le support fait partie de la surface de contrôle d'identité. Le dossier de réparation doit rendre cela suffisamment visible pour que les clients puissent faire confiance à la prochaine demande de support.

Les rapports d'impact devraient être utiles aux défenseurs, pas seulement complets pour les avocats

Lanote de clôture d'enquêtede février 2024 d'Okta faisait référence à des rapports d'impact personnalisés pour les clients et partenaires. Ce type de rapport n'est précieux que s'il aide les défenseurs à agir. Un avis juridique indiquant qu'un client a été affecté peut être formellement important, mais une équipe de sécurité a besoin de détails opérationnels: quel cas, quel fichier, quel artefact, quel utilisateur de support, quelle heure d'accès, quelle session possible, quelles rotations recommandées, et quels indicateurs vérifier dans les journaux du locataire.

Les rapports clients de1Password,BeyondTrustetCloudflaremontrent le niveau de spécificité que les défenseurs ont dû reconstituer. Ils ont dû relier un ticket de support Okta à une activité administrative inattendue, un fichier HAR, un jeton de session, une gestion des appareils, des tentatives API ou des étapes de confinement. Plus le rapport d'impact du fournisseur est précis, moins chaque client doit déduire sous pression.

Un rapport d'impact de fournisseur d'identité devrait séparer au moins cinq catégories. Premièrement, l'exposition des fichiers: quels artefacts téléchargés par le client ont été consultés ou téléchargés. Deuxièmement, le risque de session: si ces artefacts contenaient plausiblement des cookies ou jetons actifs. Troisièmement, l'exposition de la liste de contacts: si les noms ou e-mails des utilisateurs de support sont apparus dans des rapports plus larges. Quatrièmement, l'activité observée du locataire: si les preuves du fournisseur ou du client montrent un rejeu de session, une action administrative ou une tentative de pivot.

Cinquièmement, l'action client recommandée: quelles sessions, identifiants, contacts de support ou journaux nécessitent un examen.

Ces catégories ne devraient pas être floues. Un client dont les noms de contact sont apparus dans un rapport fait face à un risque de phishing. Un client dont le fichier HAR a été consulté fait face à un possible risque de session. Un client avec des preuves de rejeu de session fait face à une urgence de réponse aux incidents. Un client avec les trois a besoin d'une réponse différente d'un client avec seulement une exposition de contact de support. La précision réduit à la fois la sous-réaction et la perturbation inutile.

Le rapport devrait également être utilisable par machine dans la mesure du possible. Les équipes de sécurité peuvent agir plus rapidement si les indicateurs, les ID de session externes, les identifiants d'utilisateur, les numéros de cas, les hachages de fichiers, les adresses IP et les horodatages arrivent dans des formats structurés qu'elles peuvent rechercher. Les PDF manuels peuvent satisfaire les attentes de notification, mais ils ralentissent les défenseurs qui doivent interroger les journaux. L'incident de support a montré que la réponse côté client dépend du conditionnement des preuves par le fournisseur.

La gestion des artefacts de support devrait être conçue pour des clients imparfaits

Les avertissements sont nécessaires mais insuffisants. La documentation d'Okta surla génération de fichiers HARavertit les utilisateurs de supprimer les données confidentielles ou personnellement identifiables avant d'envoyer des fichiers. La documentation du navigateur surl'enregistrement des requêtes réseau dans HARexplique le comportement d'exportation actuel. Ce sont des contrôles utiles, mais de vrais clients téléchargent des fichiers sous pression temporelle, tout en dépannant des problèmes d'accès confus, souvent avec des administrateurs essayant de restaurer le service. Un modèle de sécurité de support qui dépend d'une rédaction manuelle parfaite échouera tôt ou tard.

Les systèmes de support devraient supposer que des artefacts sensibles seront téléchargés. Cette hypothèse change la conception. La page de téléchargement peut avertir et analyser. Le stockage de fichiers peut restreindre l'accès et réduire la conservation. L'outil de cas peut empêcher les exportations de rapports larges d'inclure des champs sensibles par défaut. Le workflow de support peut exiger une approbation élevée avant de télécharger des fichiers qui semblent contenir du matériel de session. Le portail client peut recommander une révocation automatique de session après certains types de téléchargement.

Le fournisseur peut faire de la collecte sanitisée le chemin par défaut plutôt qu'un plus optionnel.

Les clients devraient également concevoir pour l'imperfection. Une équipe de sécurité peut créer une identité de dépannage avec des privilèges limités, capturer des fichiers HAR à partir de flux de test au lieu de sessions d'administrateur en direct, révoquer les sessions après le téléchargement et étiqueter les cas de support qui incluent des artefacts sensibles. Elle peut exiger que les employés enregistrent quels identifiants ou jetons ont pu apparaître dans un fichier de support. Elle peut examiner les pièces jointes des cas de support lors de la réponse aux incidents.

Ces étapes n'éliminent pas les devoirs du fournisseur, mais elles réduisent la valeur d'une exposition accidentelle.

LeHAR Sanitizerde Cloudflare illustre la direction à suivre: rendre le partage plus sûr plus facile avant que le fichier n'atteigne le fournisseur. L'outil lui-même n'est pas une réponse universelle, et certains dépannages peuvent nécessiter des données que la rédaction supprime. Le principe plus large est ce qui importe. La gestion des artefacts de support devrait être un workflow conçu avec des valeurs par défaut sûres, pas un test de mémoire pour les administrateurs.

Si les workflows de support des fournisseurs d'identité sont conçus pour des clients imparfaits, l'incident est moins susceptible de dégénérer. Un client peut faire une erreur sans transformer un ticket de support en un chemin d'accès au locataire. Un fournisseur peut recevoir des données de diagnostic utiles sans conserver une autorité en direct plus longtemps que nécessaire. Voilà à quoi devrait ressembler une sécurité de support proportionnée.

La carte de support est un actif d'ingénierie sociale

L'exposition du rapport de novembre décrite par Okta dans samise à jour et actions recommandéesdoit être comprise comme une carte. Les noms et adresses e-mail des utilisateurs du système de support identifient des personnes qui interagissent avec l'infrastructure d'identité, ouvrent des cas de support et peuvent avoir des connaissances privilégiées. L'alerte de cybersécuritéde la FINRA avertissait les entreprises membres d'un risque possible de phishing et d'ingénierie sociale lié aux données de support exposées. Ce risque n'est pas théorique dans l'abstrait; il découle de l'information de rôle elle-même.

Les cartes de support peuvent être combinées avec des actualités publiques de violations. Un attaquant peut écrire un message plausible faisant référence à un problème de support Okta, une revue de locataire, une rotation de session ou une demande de validation de sécurité. Le destinataire peut être exactement la personne qui s'attendrait à une telle communication. C'est le problème d'économie des contacts d'abus: même des enregistrements à faible contenu peuvent devenir puissants lorsqu'ils identifient la bonne cible au bon moment.

La réponse de contrôle devrait inclure une hygiène de communication. Les fournisseurs devraient donner aux clients des canaux vérifiés, des avis signés lorsque approprié, des domaines d'expéditeur clairs et des conseils sur la façon dont le support ne demandera jamais certains identifiants. Les clients devraient avertir les populations de support et d'administration que des messages à thème d'incident peuvent arriver. Les centres d'assistance devraient être informés sur la façon de valider les demandes des fournisseurs.

Les équipes de sécurité devraient surveiller les domaines imitant et le harvesting ciblé d'identifiants après une exposition de contacts de support.

Cette couche de réparation reçoit souvent moins d'attention que les jetons de session car elle est moins technique. Elle importe néanmoins. Une session compromise peut créer un accès immédiat; une carte de support peut ensemencer la prochaine tentative d'intrusion. La meilleure réponse aux incidents traite les deux comme faisant partie de la même frontière de confiance. Si les attaquants savent qui appeler ou phisher, la sécurité du support n'a pas complètement récupéré.

Les examens des risques fournisseurs devraient tester le plan de support

Les examens des risques fournisseurs en entreprise se concentrent souvent sur les contrôles produit: disponibilité, chiffrement, MFA, traitement des données, certifications et réponse aux incidents. L'incident d'Okta suggère que les examens des fournisseurs d'identité devraient tester explicitement le plan de support. Où les cas de support sont-ils hébergés? Qui peut accéder aux pièces jointes? Combien de temps les fichiers sont-ils conservés? Les rapports sont-ils exportables? Les comptes de service sont-ils protégés par une MFA résistante au phishing? Les profils de navigateur personnels des employés sont-ils interdits?

Les clients peuvent-ils obtenir des journaux d'accès au niveau des fichiers lors d'un incident? Les artefacts de support sont-ils analysés ou sanitisés?

Leformulaire 10-Kd'Okta discutait de l'hébergement tiers du système de support et du contexte de risque fournisseur. Les clients devraient transformer ce risque général en diligence spécifique. Un système de cas tiers n'a pas besoin d'être nommé publiquement pour que les clients demandent si ses contrôles correspondent à la sensibilité des artefacts qu'il stocke. Pour un fournisseur d'identité, l'assurance du plan de support devrait être aussi routinière que l'assurance du plan produit.

L'examen devrait également demander comment le fournisseur notifiera les clients. Les clients affectés recevront-ils une communication directe? Recevront-ils des indicateurs spécifiques au locataire? Le fournisseur identifiera-t-il si les fichiers téléchargés contenaient du matériel de session possible? Les clients auront-ils suffisamment de temps pour faire tourner avant que les détails publics ne créent un risque de phishing? L'exposition plus large de la liste de contacts sera-t-elle séparée de l'exposition des artefacts? Ce sont des questions de préparation aux incidents, pas seulement des questions d'avis juridique.

Pour les clients, l'examen devrait également produire des engagements internes. Si le fournisseur dit que les fichiers HAR peuvent être sensibles, le client devrait définir qui peut les télécharger. Si le fournisseur dit que les sessions devraient être révoquées après le téléchargement, le client devrait automatiser cette étape. Si le fournisseur dit que les listes d'utilisateurs de support peuvent créer un risque de phishing, le client devrait maintenir une liste des rôles d'administration et de support qui nécessitent une sensibilisation ciblée après les incidents.

Le résultat devrait être un playbook de plan de support. Il devrait dire aux administrateurs comment collecter en toute sécurité des données de diagnostic, comment les soumettre, quoi faire tourner après, comment valider les communications du fournisseur et comment rechercher dans les journaux si le fournisseur signale un accès au système de support. Sans ce playbook, chaque incident de support commence par l'improvisation.

Les clients ont besoin de répétition avant le prochain incident de support

L'incident Okta montre également que les clients doivent répéter la réponse aux artefacts de support avant qu'un avis du fournisseur n'arrive. Une équipe de sécurité devrait pouvoir répondre rapidement à des questions simples. Quels employés ouvrent des cas de support avec le fournisseur d'identité? Quels comptes ont l'autorisation de télécharger des fichiers de diagnostic? Où sont stockées les copies de ces fichiers en interne? Qui peut révoquer les sessions après le téléchargement? Quels journaux peuvent montrer l'utilisation d'un ID de session externe?

Qui décide s'il faut faire tourner les identifiants de compte de service liés au dépannage?

Le guide d'Okta surles événements du journal systèmedonne aux clients des concepts de recherche, mais un concept n'est pas un plan de réponse. Un client devrait tester si son équipe peut trouver les événements pertinents, les interpréter et les relier à un cas de support. Il devrait tester si les administrateurs de support savent comment créer des preuves sanitaires. Il devrait tester si une session privilégiée peut être révoquée rapidement sans désactiver l'accès commercial nécessaire.

La répétition réduit également la dépendance aux actualités publiques. En 2023, certains rapports clients décrivaient la découverte ou l'escalade d'activités suspectes avant que l'explication publique du fournisseur ne soit complète. Ce n'est pas inhabituel dans les incidents cloud. Les clients peuvent voir des symptômes de locataire avant de recevoir un récit complet du fournisseur. Un playbook répété les aide à agir sur leurs propres preuves tout en demandant au fournisseur de la précision.

L'exercice devrait inclure les communications. Si un artefact de support a pu exposer une session d'administrateur, qui informe les propriétaires d'application? Qui avertit le centre d'assistance du phishing? Qui informe les dirigeants? Qui détermine si les utilisateurs finaux sont affectés? Un compromis du système de support peut sembler étroit, mais la réponse touche l'exploitation de l'identité, le juridique, les communications, le risque fournisseur et les propriétaires métier. Pratiquer ce transfert fait partie de la transformation du support en une frontière de confiance gouvernée.

Le standard pratique est modeste mais exigeant: aucun client ne devrait apprendre comment les fichiers HAR, les cookies de session, les utilisateurs de support et les journaux de locataire se connectent pour la première fois lors d'un incident actif chez un fournisseur. Le support d'identité est trop proche de l'autorité de l'entreprise pour cela.

Le dossier de répétition devrait être conservé avec les documents de risque fournisseur afin que le prochain incident de support commence avec des propriétaires nommés et des actions testées.