2025 no fue un buen año para los clientes de Salesforce. Un grupo criminal lanzó una serie de ataques contra sus clientes, afectando a organizaciones que iban desde gigantes tecnológicos como Google y Cisco hasta marcas de lujo como Chanel y Louis Vuitton. Incluso proveedores de infraestructura crítica como Qantas Airways, FedEx y TransUnion fueron víctimas de los atacantes, conocidos como Scattered LAPSUS$ Hunters, ShinyHunters o variantes similares. El grupo, que parece ser una coalición de miembros de varias otras bandas criminales, habría comprometido a más de 760 organizaciones y aproximadamente 1.5 millones de registros.

Pero Salesforce afirma que no se trata de un problema que ellos mismos hayan creado. ¿Cómo es posible que un ataque se convirtiera en la principal fuente de robo de datos en 2025, sin que el proveedor admitiera responsabilidad alguna?

Es fácil comprender por qué Salesforce se negó a asumir la responsabilidad en este caso. Al parecer, los atacantes no explotaron ninguna vulnerabilidad en la plataforma en línea del proveedor.

En cambio, los atacantes accedieron a los sistemas de Salesforce a través de fallos en la seguridad del cliente, como una gobernanza OAuth inadecuada, la falta de aplicación de la autenticación multifactor (MFA), una deficiente verificación de la integración y la susceptibilidad a la ingeniería social.

Un método típico para obtener acceso consistía en crear una versión falsa de la aplicación Salesforce Data Loader, que los clientes utilizan para descargar sus datos de Salesforce.

La banda Scattered LAPSUS$ utilizó este software falso para enviar un código de dispositivo a los servidores de Salesforce, el cual debía ser ingresado por un usuario de Salesforce. Posteriormente, uno de los miembros de la banda llamaba a la víctima haciéndose pasar por un empleado del servicio de asistencia técnica de su empresa. Le pedían a la víctima que iniciara sesión en Salesforce e ingresara el código del dispositivo, confirmando así, sin saberlo, que la aplicación falsa (de la cual no tenía conocimiento alguno) era legítima. De esta manera, los delincuentes obtenían acceso a los datos confidenciales de Salesforce de la empresa víctima.

Estas fallas en la seguridad del cliente no son anomalías. Gartner predice que el 99% de los fallos de seguridad en la nube hasta 2025 serán culpa del cliente. Un estudio reciente de AppOmni también enseñe que el 70% de los incidentes de SaaS se deben a una combinación de problemas de permisos controlados por el cliente y configuraciones erróneas.

Comprender el modelo de responsabilidad compartida

La preocupación radica en que los clientes de software de proveedores podrían caer en una falsa sensación de seguridad al confiar únicamente en la plataforma del proveedor, especialmente si dicho software está alojado en la nube. Pero, en realidad, la seguridad de la plataforma del proveedor no equivale automáticamente a la seguridad de los datos.

La industria de la nube incluso tiene un término para esto: responsabilidad compartida. Se trata de un entendimiento mutuo sobre dónde termina la responsabilidad del proveedor de servicios/hosting y dónde comienza la del cliente. Muchas empresas parecen no comprenderlo; el 53 % de los encuestados de AppOmni que se declaran seguros en materia de seguridad basan su confianza en la solidez de los controles de sus proveedores. Como evidencian los ataques a Salesforce, incluso quienes lo entienden a menudo no gestionan la seguridad adecuadamente en su propia infraestructura.

Para Salesforce y las plataformas SaaS, el proveedor suele cubrir la infraestructura segura de la plataforma, el código fuente de la aplicación, las garantías de disponibilidad y las funciones de seguridad integradas, como la autenticación multifactor (MFA) y el cifrado. Esto deja a los clientes la responsabilidad de medidas como la gestión de las cuentas de usuario, la aplicación de la MFA y la gestión de los tokens OAuth, la implementación del principio de mínimo privilegio, la gestión de las integraciones de terceros y la configuración adecuada de los ajustes de seguridad.

También es responsabilidad de los usuarios capacitar al personal sobre las amenazas a la seguridad. Dado el componente de ingeniería social que implican estos ataques, este parece haber sido un punto débil. Sin embargo, incluso si los atacantes logran engañar a los usuarios, debería existir un mecanismo para monitorear su actividad y detectar anomalías.

Cómo los marcos de cumplimiento pueden ayudar a prevenir estas infracciones

Estas son debilidades que las normas ISO 27001:2022, SOC 2 y NIS 2 abordan explícitamente mediante el control de acceso, la supervisión de proveedores y los requisitos de gestión de la configuración. Las empresas deberían considerar estas normas operativas para mejorar su posición y evitar convertirse en una marca más en la lista de empresas comprometidas.

Por ejemplo, la serie de control de acceso A.5.15 Requiere establecer políticas de control de acceso documentadas mediante la implementación de los principios de necesidad de conocer y necesidad de usar. El apartado A.5.16 aborda la gestión de identidades, mientras que el apartado A.5.17 explora la gestión de la información de autenticación, lo que exige almacenamiento y transmisión seguros, cifrado en reposo y en tránsito, y rotación periódica.

A.5.18 Cubre los derechos de acceso. Requiere procesos formales para la concesión, modificación y revocación de dichos derechos, con autorización de los propietarios de los activos y revisiones periódicas, al menos anuales. Los responsables de cumplimiento también pueden consultar el apartado A.8.2, que regula los derechos de acceso privilegiados.

Estos controles exigen registros centralizados, auditorías periódicas y la validación de la legitimidad antes de conceder el acceso. Estas son precisamente las medidas que habrían impedido que las víctimas de ingeniería social autorizaran aplicaciones maliciosas.

Esta no es la primera vez que vemos empresas sufrir brechas de seguridad debido a sus propias decisiones de configuración (o al desconocimiento de las mismas). La serie de brechas que afectaron a los clientes de Snowflake en 2024 viene a la mente, originadas por el robo de credenciales y la falta de autenticación multifactor (a pesar de que Snowflake la ofrecía). A medida que las empresas dependen cada vez más del SaaS y depositan sus datos más sensibles en estas infraestructuras, recae sobre ellas la responsabilidad de proteger adecuadamente sus propios accesos digitales a estos sistemas.