Un incident de sécurité récent impliquant la compromission de Salesloft Drift, un outil populaire d'automatisation du marketing, a touché un grand nombre d'Organizations.
Au cours de cet événement, des cybercriminels ont volé et rejoué les tokens OAuth qui connectent l'outil Drift à Salesforce, Google Workspace et de nombreuses autres applications, entraînant une exfiltration massive de données.
Cet incident a eu un impact sur bon nombre de nos pairs technologiques. Ces événements soulèvent naturellement des questions pour nos clients et partenaires : « Okta a-t-il été touché ? » et « Que fait Okta pour protéger nos données ? »
Nous voulons être très clairs : Okta n'a pas été impacté par cet incident.
Notre équipe sécurité a minutieusement examiné nos ressources et a confirmé que, bien que nous ayons observé des preuves de tentatives d'accès à nos ressources à l'aide de tokens volés, nos défenses ont fonctionné comme prévu pour empêcher une brèche.
La défense en pratique : l'impact d'un contrôle unique
Lorsque notre équipe a appris la compromission de Salesloft Drift, nous avons immédiatement examiné nos logs. Nous avons découvert des tentatives d'utilisation d'un token Salesloft Drift en compromission pour accéder à une instance Okta Salesforce. Ces tentatives ont échoué. Lorsque nous avons comparé par la suite ces tentatives aux indicateurs de compromission (IOC) de l' article de blog Google Mandiant, les données ont confirmé que nous étions bien une cible.
Le contrôle le plus important qui a empêché cette brèche était notre mise en œuvre des restrictions d'IP entrantes. Le cybercriminel a tenté d'utiliser un jeton compromis pour accéder à notre instance Salesforce, mais l'attaque a échoué car la connexion provenait d'une adresse IP non autorisée. Cette couche de sécurité s'est avérée essentielle, bloquant la tentative non autorisée à la porte d'entrée avant que tout accès ne puisse être obtenu.
Notre stratégie de sécurité consiste à appliquer ce contrôle fondamental à toutes nos applications SaaS. Cependant, notre capacité à mettre en œuvre cela est souvent limitée, car elle dépend entièrement de la capacité du fournisseur SaaS à offrir cette fonctionnalité. Malheureusement, de nombreux fournisseurs dans le monde du « cloud first » n'offrent pas cette fonctionnalité de sécurité fondamentale, ce qui pose une demande d'authentification majeure pour la protection des systèmes interconnectés.
Pour une application aussi critique que Salesforce, qui supporte cette fonctionnalité, nous avons entrepris l'effort considérable nécessaire pour configurer ces restrictions pour les API et les utilisateurs. Cet investissement délibéré, réalisé dans le cadre de l'Okta Secure Identity Commitment, comprenait le travail visant à garantir que tous les employés d'Okta utilisent un VPN basé sur le cloud avec des nœuds de sortie IP privés afin de créer un réseau d'entreprise de confiance. Cette étape fondamentale garantit que, pour nos applications les plus vitales qui supportent cette fonctionnalité, nous pouvons appliquer la sécurité au niveau du réseau nécessaire pour nous défendre contre ce type d'attaque.
Au-delà des restrictions IP : sécurisation des tokens avec DPoP
Un autre pilier de l'engagement d'Okta en matière d'identité sécurisée était de créer des produits et services d'identité sécurisés de pointe. En conséquence de cet engagement, Auth0 et Okta ont développé le support de DPoP (Demonstrating Proof of Possession) pour les Developer utilisant nos services.
Là où l'autorisation par liste blanche d'IP limite l'utilisation d'un token par IP, DPoP peut restreindre l'utilisation d'un token à un client spécifique. Ce mécanisme de sécurité lie cryptographiquement un token d'accès au client spécifique qui l'a demandé. En termes simples, c'est comme une clé qui est associée de manière unique à sa serrure. Même si un attaquant volait la clé (le token), il ne pourrait pas l'utiliser car elle ne fonctionnerait pas sur sa propre machine (la mauvaise serrure). Ce contrôle empêche la relecture des tokens volés, ce qui était le problème central de cette attaque de la chaîne logistique.
Construire un écosystème SaaS résilient avec IPSIE
Cet incident est un rappel brutal qu'une brèche d'un service peut avoir un effet d'entraînement dans l'écosystème SaaS interconnecté d'aujourd'hui. Pour nous défendre contre cela, nous devons aller au-delà de la sécurisation des applications individuellement et veiller à ce qu'elles fassent toutes partie d'un écosystème de sécurité d'identité unifié. Un tel tissu, construit sur des standards ouverts, est ce qui permet aux Organizations de détecter et de répondre aux menaces basées sur l'identité avec la rapidité et l'ampleur requises.
C'est pourquoi, il y a près d'un an, Okta a annoncé son engagement à promouvoir un nouveau standard industriel appelé Interoperability Profile for Secure Identity in the Enterprise (IPSIE) en partenariat avec d'autres membres de l'OpenID Foundation. IPSIE vise à établir une base de référence pour la sécurité et l'interopérabilité des applications SaaS.
Deux des contrôles fondamentaux qui font partie du framework IPSIE sont particulièrement pertinents pour l'incident Salesloft Drift :
Signaux partagés : Cela permet la communication en temps réel des événements de sécurité entre les applications. Par exemple, si le compte d’un utilisateur est en compromission dans une application, cette information peut être instantanément partagée avec toutes les autres applications connectées, qui peuvent alors prendre des mesures pour protéger les données de l’utilisateur.
Révocation de Token : Cela fournit un moyen standardisé de résilier l'accès aux tokens. Dans le cas de l'incident Salesloft Drift, si un token était connu pour être en compromission, il pourrait être instantanément révoqué dans toutes les applications intégrées, coupant ainsi l'accès de l'attaquant.
Ce ne sont là que quelques exemples des nombreuses façons dont IPSIE contribue à créer un écosystème SaaS plus sûr et plus résilient.
Un appel à l'action pour l'industrie SaaS
L'incident Salesloft Drift est un signal d'alarme pour l'ensemble de l'industrie SaaS. Nous ne pouvons plus nous permettre de cloisonner. Nous devons travailler ensemble pour établir et adopter un ensemble commun de standards de sécurité.
L'avenir de la sécurité SaaS est déjà là, mais elle n'est pas répartie uniformément.
Nous invitons instamment toutes les entreprises SaaS \`{a} se joindre \`{a} nous pour soutenir l'initiative IPSIE (International Public Sector Information Exchange). En travaillant ensemble, nous pouvons rendre l'ensemble de l'écosystème SaaS plus sûr pour tout le monde.
Ce que vous pouvez faire pour protéger votre Organizations
Ce n'est pas seulement un problème que les fournisseurs doivent résoudre ; toutes les Organizations ont un rôle crucial à jouer pour élever le niveau de l'ensemble de l'écosystème. Voici comment vous pouvez agir maintenant :
Demandez l'IPSIE à vos fournisseurs. La sécurité du paysage SaaS interconnecté est une responsabilité partagée. En tant que client, votre voix est le moteur de changement le plus puissant. Interrogez vos fournisseurs sur leur roadmap pour l'adoption de standards ouverts telles que IPSIE. Lorsque les fournisseurs savent que la sécurité et l'interopérabilité sont des critères d'achat clés, ils leur accorderont la priorité. C'est votre demande qui transformera ces standards d'une bonne idée en une réalité à l'échelle de l'industrie.
Mettre en œuvre un écosystème de sécurité des identités. Bien que nous insistions sur l'amélioration des standards à l'échelle de l'industrie, il est impératif que vous agissiez pour sécuriser votre propre environnement numérique. L'époque où l'identité était gérée application par application est révolue. En mettant en œuvre un écosystème de sécurité des identités unifié, vous pouvez intégrer le contrôle des accès, la détection des menaces et la réponse aux menaces, ainsi que la gouvernance dans toutes vos applications et tous vos types d'identités. Cela fournit une couche de défense unique et cohérente, vous permettant de sécuriser de manière proactive vos Organizations de l'intérieur vers l'extérieur.
Pour en savoir plus sur l'IPSIE, veuillez visiter le site Web de l'OpenID Foundation.
