Le plus souvent, la réaction immédiate aux incidents de sécurité tels que les attaques par ransomware qui ont frappé les casinos de Las Vegas au début de l'automne est de chercher la cause. Je comprends cette impulsion. L'impact des attaques - les clients qui ont dû passer à la caisse en utilisant des stylo et papier, jusqu'à $100 millions de pertes pour une seule victime - démontrent le coût élevé des failles de sécurité. Personne ne souhaite être la prochaine victime d'une violation de données.
Mais en matière de cybersécurité, il n'y a généralement pas qu'une seule cause. Dans la plupart des incidents de sécurité, les attaquants tirent parti d'une chaîne de vulnérabilités qui leur donne progressivement plus d'accès et de contrôle sur un environnement. Il n'est pas productif de chercher des causes et des effets lorsqu'il n'y en a généralement pas. Au lieu de cela, les équipes de sécurité doivent examiner leur environnement global, son architecture et les modes de fonctionnement de sa technologie, ainsi que leurs systèmes d'information. processus et culture d'entreprise et les rapprocher de l'architecture zéro confiance.
À l'instar des casinos touchés par ces attaques, les cyberattaques et la cybersécurité ont tendance à jouer avec les probabilités. Ce n'est généralement pas un seul talon d'Achille qui met en péril la cybersécurité d'une organisation. Il s'agit plutôt d'un hasard statistique et de risques qui s'additionnent les uns aux autres. Les équipes de sécurité ne devraient pas chercher une balle d'argent, mais plutôt comprendre les conditions qui peuvent transformer un flocon de neige en avalanche.
Si nous ne connaîtrons probablement jamais toute l'histoire de la manière dont ALPHV / BlackCat ont lancé leurs attaques, nous connaissons certaines des conditions qui les ont aidés à atteindre leurs victimes et la manière dont ces conditions ont créé des risques qui ont favorisé les attaquants.
Dans leur déclaration, ALPHV a déclaré que le casino "a fermé chacun de ses serveurs Okta Sync après avoir appris que nous nous étions cachés sur ses serveurs Okta Agent pour renifler les mots de passe des personnes dont les mots de passe ne pouvaient pas être déchiffrés".
ALPHV a pu le faire grâce à Synchronisation des mots de passe des applications Okta, qui "utilise des API standard pour synchroniser les mots de passe et les applications sur site lorsqu'elles sont disponibles". La documentation du produit continue : "Lorsque l'option Okta to Application - Sync Okta Password est activée, le comportement par défaut est de synchroniser le mot de passe existant. Le mot de passe Okta est le mot de passe utilisé pour se connecter à Okta."
En clair, cela signifie qu'Okta dispose des mots de passe Active Directory de ses utilisateurs. Cela s'explique en grande partie par l'architecture "cloud-first" du fournisseur : la synchronisation des mots de passe facilite leur exécution et permet un déploiement et une mise en œuvre rapides du système MFA.
Si ce choix permet aux organisations de déployer la solution plus rapidement, il s'accompagne de compromis importants en matière de sécurité, qui vont à l'encontre d'un principe fondamental de la cybersécurité : L'évitement des données ou, en d'autres termes, ne pas stocker ou transmettre des données qui n'ont pas besoin d'être stockées ou transmises.
Il s'agit d'une règle de longue date, car si une organisation transmet quelque chose, il est plus facile pour un attaquant de le voler. C'est ce qui s'est passé avec BlackCat et ALPHV : ils ont probablement compromis le serveur sur lequel fonctionnait Okta Agent AD. À partir de là, ils ont pu mettre en place un vampire tap pour copier des mots de passe, injecter une DLL, vider des segments de mémoire ou entreprendre toute autre action. Et c'est bien là le problème : les actions spécifiques entreprises par les attaquants lorsqu'ils se trouvaient sur le serveur compromis n'ont pas vraiment d'importance.
Au lieu de cela, le risque a commencé par le déploiement d'une architecture qui synchronise les mots de passe. Ce choix a créé les conditions qui ont permis à tout le reste de suivre. Cette décision est l'équivalent, en matière de cybersécurité, du choix de construire un édifice sur du sable plutôt que sur un socle rocheux : ce que vous construisez peut tenir, mais pourquoi prendre le risque ?
Les attaques BlackCat / ALPHV soulignent à quel point il est difficile de sécuriser les serveurs. Les mises à jour multiples, les mots de passe d'administrateur et le rejeu de mot de passe constituent une surface d'attaque importante, complexe et fragile. Ce type de configuration favorise généralement les attaquants.
L'autre solution consiste à s'appuyer à la fois sur Secure by Design et Secure by Default. principes, qui donnent la priorité à la sécurité dans toutes les caractéristiques, opérations et processus des produits et rapprochent les organisations de la confiance zéro.
Comme pour beaucoup de choses, la sécurité dès la conception (Secure by Design) et la sécurité par défaut (Secure by Default) sont une question de détails. Il est facile d'affirmer qu'un produit donne la priorité à la sécurité, mais il est difficile de proposer quelque chose qui réponde réellement à ce critère.
RSA développe des solutions de sécurité qui commencent par ces principes. Nous ne synchronisons pas les mots de passe Active Directory ou LDAP, car nous ne disposons pas de ces informations d'identification. Au lieu de cela, nous demandons aux clients de déployer une appliance virtuelle renforcée qui se connecte à leurs référentiels d'utilisateurs sur site et valide les mots de passe en temps réel au lieu de les renifler et de les synchroniser dans le nuage.
Ce choix s'accompagne de quelques compromis : le déploiement d'une appliance virtuelle renforcée et de notre routeur d'identité virtuel demande un peu plus de temps et d'efforts. Mais nos clients et notre équipe estiment que ce coût en vaut la peine, car en ne synchronisant pas les mots de passe, nous réduisons la surface d'attaque au lieu de l'élargir. Si nous ne les synchronisons pas, nous ne pouvons pas les perdre et un attaquant ne peut pas les exploiter. Nous pensons également que les solutions d'autres fournisseurs demandent plus de temps et d'efforts à long terme, car les solutions "plus rapides" entraînent une surface d'attaque beaucoup plus grande avec des frais généraux encore plus importants.
RSA® Serrure mobile, Mobile Lock, qui établit la confiance dans les appareils non gérés et contribue à sécuriser le BYOD, illustre également les principes Secure by Design et Secure by Default. Mobile Lock ne recherche les menaces que lorsque les utilisateurs essaient de s'authentifier à l'aide de RSA Authenticator pour iOS et Android, et ne restreint l'authentification que lorsqu'il détecte une menace. Il n'interroge également que le strict minimum de données pour exécuter ses fonctions, et notre partenaire Zimperium ne voit jamais d'informations personnelles sur les utilisateurs finaux. Les gains de sécurité obtenus en faisant plus - comme analyser continuellement l'appareil d'un utilisateur - seraient minimes, surtout si on les compare à la possibilité pour un pirate de cibler un service d'arrière-plan toujours actif.
Il en va de même pour notre agent d'authentification multifactorielle (MFA). En cas de panne d'Internet, notre agent d'authentification multifactorielle est transféré en toute sécurité vers un déploiement sur site au lieu de rester ouvert ou de passer en mode déconnecté où la validation OTP s'effectue au niveau de l'agent d'authentification multifactorielle lui-même. Cela signifie que les acteurs de la menace ne peuvent pas échapper à l'AMF simplement en se déconnectant de l'internet ou en donnant l'impression que le service de backend de l'AMF est hors ligne. ONG l'année dernière.
La véritable sécurité n'est jamais surdimensionnée : elle repose sur un mélange judicieux de solutions simples lorsque c'est possible et de solutions plus complexes lorsque c'est nécessaire. Chaque composant d'un service doit être conçu de manière à limiter la surface d'attaque dans la mesure du possible. Cela signifie qu'il ne faut collecter que le strict minimum d'informations dont un système a absolument besoin et n'utiliser ces informations qu'en cas de nécessité. Cela signifie également qu'il faut prendre des décisions architecturales qui minimisent la surface d'attaque plutôt que de l'étendre inutilement.
En matière de cybersécurité, il s'agit souvent de jouer avec les probabilités. Améliorez les vôtres en jouant intelligemment et en misant sur des fournisseurs qui placent la sécurité au premier plan.
