Il n'a pas fallu attendre longtemps pour que 2025 rappelle l'importance de la sécurité de l'identité, avec le Département du Trésor américain notifiant au Congrès qu'un acteur menaçant "parrainé par l'État chinois" avait accédé à ses systèmes en exploitant des vulnérabilités (CVE-2024-12356 et CVE-2024-12686) dans les systèmes de BeyondTrust.
Et si CISA indique que le département du Trésor est la seule agence fédérale à avoir été touchée par cette faille, l'histoire se poursuit. Plus de 13 000 instances des services concernés sont toujours connectées à l'internet et pourraient être vulnérables, rapporte Censys. Depuis la divulgation initiale par le département du Trésor, la CISA a ajouté CVE-2024-12686 à sa base de données. Catalogue des vulnérabilités connues et exploitées, qui demande aux agences fédérales de "sécuriser leurs réseaux contre les attaques en cours ciblant la faille".
Il n'est jamais utile de jouer au quarterback du lundi matin, et c'est particulièrement le cas dans des situations comme celle-ci, lorsque les détails de la brèche sont encore en train d'être révélés. Au lieu de cela, nous pensons qu'il est utile d'examiner les faits relatifs à la violation du département du Trésor et d'expliquer ce que ces faits signifient, selon nous, pour les programmes de cybersécurité des organisations à l'avenir.
Dans son rapport Dans son rapport sur la violation, BeyondTrust note qu'"une analyse des causes profondes d'un problème lié à Remote Support SaaS a identifié qu'une clé API pour Remote Support SaaS avait été compromise". Le rapport indique que la clé API de Remote Support SaaS compromise "permettait de réinitialiser les mots de passe des comptes d'applications locales".
BeyondTrust a pris les mesures nécessaires pour révoquer immédiatement la clé API, probablement pour initier des réinitialisations de mots de passe. Mais la sécurisation des API doit s'inscrire dans une approche beaucoup plus large : les organisations doivent sécuriser l'ensemble du cycle de vie des informations d'identification. Il s'agit d'un problème plus vaste que la simple authentification. Les entreprises doivent prendre en compte le provisionnement, l'enrôlement et la réinitialisation des comptes humains et machine.
Ils doivent également s'assurer que ce que L'accès aux ressources auxquelles les utilisateurs s'authentifient est toujours d'actualité. Je ne devrais pouvoir accéder qu'aux ressources dont j'ai besoin dans un but précis. Tout accès supplémentaire - tout accès que j'ai mais dont je n'ai pas besoin - ne fait que perpétuer le risque.
Les organisations doivent également étendre ce principe aux API. Les utilisateurs et les dispositifs humains ont eu tendance à recevoir toute l'attention en matière de sécurité, négligeant les comptes de service et les API. Les organisations doivent savoir à quoi ces services peuvent accéder et ce qu'ils font avec cet accès. Elles doivent également générer et gérer les API indépendamment pour chaque locataire - avoir des clés API en double est tout aussi risqué et tout aussi mauvais que de partager des mots de passe.
Dans sa lettre au Congrès, le département du Trésor note que "l'auteur de la menace a eu accès à une clé utilisée par le fournisseur pour sécuriser un service basé sur le cloud utilisé pour fournir à distance une assistance technique aux utilisateurs finaux des bureaux départementaux du Trésor (DO)".
Il est difficile d'analyser précisément ce que cela signifie dans ce cas, mais certains éléments me rappellent les attentats de 2023 qui ont coûté 1,5 milliard d'euros à l'Union européenne. MGM Resorts et Groupe Caesars Entertainment des centaines de millions de dollars.
Dans l'attaque du ransomware de Las Vegas et dans celle, plus récente, du département du Trésor, les attaquants ont utilisé une combinaison de services d'assistance et d'API des organisations. La principale différence est que dans le cas des attaques de Las Vegas, les attaquants ont utilisé l'ingénierie sociale pour tromper le service d'assistance informatique et l'amener à réinitialiser un mot de passe.
Les organisations doivent comprendre les risques que peuvent représenter leurs propres services d'assistance. Historiquement, les acteurs de la menace se sont fait passer pour des services d'assistance informatique afin de procéder à l'ingénierie sociale de leurs cibles, et cette tactique semble être en jeu dans l'attaque du département du Trésor.
Ces bureaux sont soumis à une forte pression, disposent d'une grande marge de manœuvre et ne disposent pas toujours d'une documentation complète sur leurs processus ou leurs actions.
Le personnel du service d'assistance peut être en mesure de réinitialiser les mots de passe, de supprimer l'AMF ou de créer de nouveaux comptes. En outre, les services d'assistance peuvent être poussés à agir avant d'avoir examiné le cas comme il se doit ou d'avoir documenté leurs actions.
Pour lutter contre ce phénomène, les dirigeants doivent faire savoir que la sécurité est primordiale, les organisations doivent documenter et utiliser des processus de gestion du changement, et les cas à haut risque doivent nécessiter des communications hors bande pour vérifier que la personne qui demande de l'aide est bien celle qu'elle prétend être. Voir notre webinaire à la demande pour voir comment les organisations peuvent protéger leurs services d'assistance contre les attaques de phishing.
Il est encore trop tôt pour connaître tous les facteurs impliqués dans la violation de données de BeyondTrust. Tout ce que les chercheurs savent pour l'instant, ce sont les deux vulnérabilités que l'entreprise a révélées. Tout le reste - y compris la question de savoir si les vulnérabilités ont été exploitées "comme des jours zéro pour accéder aux systèmes de BeyondTrust ou comme une partie de la chaîne d'attaque pour atteindre les clients", d'après Ordinateur en panne, La question de savoir si son service d'assistance a été piraté et comment elle sécurise ses interfaces de programmation (API) relève encore de la spéculation. Il pourrait y avoir d'autres facteurs que les chercheurs dévoileront avec le temps.
Et c'est bien là le problème. Il y a tellement d'étapes et de composants dans la pile technologique d'une organisation qui peuvent se briser, être négligés, non sécurisés ou mal utilisés. Si les organisations doivent s'efforcer de les sécuriser toutes individuellement, elles doivent également mettre en œuvre un cadre plus large de confiance zéro.
Ne surprovisionnez pas l'accès, donnez la priorité à Secure by Default et Secure by Design, formez vos utilisateurs et supprimez toute confiance implicite dans les utilisateurs, les systèmes et les données. Examinez l'ensemble de vos processus d'entreprise et de vos piles technologiques pour en déceler les faiblesses et ne laissez pas le parfait être l'ennemi du bien : toute amélioration que vous pouvez apporter à votre posture de sécurité - ou toute confiance implicite que vous pouvez supprimer de votre environnement - contribuera grandement à prévenir ou à minimiser une atteinte à la protection des données.
