La campaña de robo de credenciales de Snowflake y los límites de la responsabilidad compartida

Resumen

• Límite de la campaña confirmado:Mandiant atribuyó una campaña con motivación financiera a UNC5537 y afirmó que todos los incidentes de la campaña que manejó directamente se originaron en credenciales de clientes comprometidas. No encontró evidencia de que el acceso no autorizado a cuentas de clientes proviniera de una violación del entorno empresarial de Snowflake. Snowflake también declaró que no encontró evidencia de una vulnerabilidad, mala configuración o violación de su plataforma que causara la actividad.
• Cadena de control observada:Las cuentas afectadas carecían de autenticación multifactor, conservaban credenciales expuestas en registros históricos de infostealers y carecían de listas de permitidos de red. Luego, los atacantes utilizaron clientes de Snowflake compatibles y operaciones SQL para enumerar datos, organizarlos, comprimirlos y descargarlos. Aproximadamente 165 organizaciones fueron notificadas como potencialmente expuestas; esta no es una cantidad de brechas, personas o registros confirmados.
• Hallazgo sobre la responsabilidad compartida:Los clientes controlaban sus usuarios, roles, rotación de contraseñas, inscripción en MFA, políticas de red, higiene de endpoints y minimización de datos. Snowflake controlaba qué protecciones existían, cómo se presentaban y se establecían por defecto, qué señales entre clientes podía ver la plataforma y con qué rapidez llegaban las advertencias y un comportamiento de referencia más sólido a la base instalada. Esas responsabilidades son concurrentes, no mutuamente excluyentes.
• Hallazgo sobre la soberanía:Elegir una región de Snowflake determina dónde se ubican el almacenamiento y la computación de la cuenta; la documentación de Snowflake indica expresamente que no limita el acceso de los usuarios. En esta campaña, una identidad válida podía convertir un conjunto de datos almacenado regionalmente en una copia descargada. La localidad de los datos sin controles de identidad, salida y evidencia es una decisión de ubicación, no un control de soberanía completo.

No se demostró que la plataforma hubiera sido vulnerada, pero se puso a prueba la relación de servicio

La primera disciplina en este caso es el vocabulario. Una instancia de cliente de Snowflake no es lo mismo que el entorno empresarial propio de Snowflake o la plataforma de producción compartida. Una persona con credenciales válidas podía ingresar a la cuenta de un cliente sin pasar a otro inquilino, explotar una vulnerabilidad de software, obtener una cuenta de administrador del proveedor o romper la infraestructura que separaba a los clientes. La evidencia pública respalda el compromiso de cuentas de clientes. No respalda un compromiso técnico de toda la plataforma.

Elinforme de la campaña UNC5537 de Mandiantes inusualmente directo en ese punto. Para cada incidente asociado con la campaña que Mandiant manejó directamente, la causa raíz fueron credenciales de clientes comprometidas. Su investigación no encontró evidencia de que el acceso no autorizado a cuentas de clientes proviniera de una violación del entorno empresarial de Snowflake. Elaviso de investigación y fortalecimiento de Snowflaketambién separó las cuentas de clientes afectadas de la plataforma de producción y proporcionó a los clientes consultas e indicadores para investigar sus propios entornos. CISA amplificó esa guía en unaalerta del 3 de junio de 2024.

Ese hallazgo negativo importa. Llamar al evento una violación de la plataforma de Snowflake puede implicar que un defecto en el código o la infraestructura compartida abrió todos los inquilinos, o que Snowflake perdió una credencial maestra que desbloqueaba a los clientes. El registro revisado no establece ninguna de las dos cosas. También oscurecería las acciones que los clientes debían tomar de inmediato: identificar a los usuarios que solo utilizan contraseña, rotar credenciales, inspeccionar el historial de inicio de sesión y consultas, restringir redes, reducir privilegios de rol y preservar evidencia.

El error opuesto es tratar la ausencia de una violación de la plataforma como la ausencia de una cuestión de responsabilidad del proveedor. Un servicio en la nube no es simplemente un disco neutral en el que un cliente coloca bits. Snowflake construyó y operó los puntos de autenticación que aceptaron las credenciales, las interfaces que los atacantes utilizaron, el motor de consultas que procesó sus comandos, la telemetría que registró las sesiones y los controles del producto que podrían haber exigido un segundo factor o restringido el origen de la red.

Snowflake también tenía una visibilidad entre clientes que ningún cliente individual podía poseer. El hecho de que un control decisivo fuera configurable por el cliente determina quién tenía el deber operativo de configurarlo. No responde si los valores predeterminados, las advertencias, la detección y la aplicación del proveedor eran proporcionales a la concentración de datos en su servicio.

ElFormulario 10-K de Snowflake para el año fiscal 2025formaliza su posición. Dice que Snowflake es responsable de la seguridad de la plataforma y de la infraestructura de nube subyacente, mientras que los clientes seleccionan y configuran controles para sus entornos. Atribuye el acceso de mayo de 2024 a la falta de cumplimiento de las obligaciones de los clientes, como MFA y políticas de red, al tiempo que registra demandas, investigaciones regulatorias, consultas de legisladores, daños a la reputación y la posibilidad de disputas de indemnización. Esa es una evidencia material de la empresa sobre el modelo declarado de Snowflake y su exposición comercial. No es una adjudicación independiente de que cada responsabilidad o reclamo legal corresponda al lado del cliente.

Por lo tanto, la pregunta útil es más estrecha que "¿Quién fue violado?" y más amplia que "¿De quién fue robada la contraseña?". Es: en cada paso, desde el secreto robado hasta los datos descargados, ¿qué actor podía prevenir, detectar, interrumpir, reconstruir o advertir sobre la acción? La responsabilidad sigue al control sobre esos pasos.

La campaña unió el robo de endpoints antiguos con la autoridad actual en la nube

Mandiant obtuvo por primera vez inteligencia de amenazas en abril de 2024 sobre registros de bases de datos que posteriormente se rastrearon hasta la instancia de Snowflake de una víctima. Esa víctima contrató a Mandiant, que concluyó que el intruso utilizó credenciales previamente robadas por malware infostealer. La cuenta relevante no tenía habilitada la MFA. El 22 de mayo, después de identificar inteligencia que apuntaba a una campaña más amplia, Mandiant contactó a Snowflake y comenzó a notificar a posibles víctimas. Snowflake publicó orientación para la detección y el fortalecimiento de clientes el 30 de mayo.

Para el informe de junio, Mandiant y Snowflake habían notificado a aproximadamente 165 organizaciones potencialmente expuestas.

Cada término de esa última oración necesita protección contra la inflación. "Aproximadamente" indica una estimación. "Potencialmente expuestas" describe una población de notificación, no 165 hallazgos forenses completados. "Organizaciones" no significa cuentas, bases de datos, personas o registros. Algunas organizaciones pueden operar múltiples cuentas de Snowflake, y una cuenta puede contener datos sobre una población mucho mayor. El informe no proporciona un total final de la campaña de organizaciones confirmadas, personas afectadas, bytes exportados o pagos de extorsión.

El historial de credenciales explica por qué un inicio de sesión en la nube en 2024 pudo comenzar con una infección de endpoint años antes. Mandiant encontró que la mayoría de las credenciales utilizadas por UNC5537 estaban presentes en la salida histórica de infostealers, siendo la infección asociada más temprana observada en noviembre de 2020. Al menos el 79,7 por ciento de las cuentas aprovechadas por el actor tuvieron exposición previa de credenciales. Ese porcentaje se aplica a las cuentas utilizadas por el actor en la campaña analizada, no a todos los clientes de Snowflake ni a las 165 organizaciones notificadas.

Tres condiciones convirtieron repetidamente los secretos expuestos en acceso efectivo. Las cuentas afectadas no estaban configuradas con MFA. Las contraseñas encontradas en los registros de infostealers permanecieron válidas, a veces durante años. Las instancias de cliente afectadas carecían de listas de permitidos de red que restringieran las conexiones a orígenes de confianza. Ninguna de estas condiciones es una explotación novedosa.

Juntas formaron una ruta de autorización duradera: conocer el localizador de la cuenta, el nombre de usuario y la contraseña aún válida; conectarse desde un sistema controlado por el atacante; recibir una sesión; heredar el rol asignado; consultar lo que ese rol pueda leer.

La dimensión del endpoint también era más distribuida de lo que sugiere la narrativa convencional de la computadora portátil de un empleado. En varias investigaciones, Mandiant encontró la infección de infostealer anterior en sistemas de contratistas que también se utilizaban para actividades personales, incluyendo juegos o descargas pirateadas. Un dispositivo de un contratista puede estar fuera de la flota de endpoints administrados por el cliente mientras transporta credenciales para varios clientes. También puede tener una cuenta administrativa porque a menudo se contrata a especialistas para construir u operar plataformas de datos.

El cliente que creó al usuario sigue siendo responsable de la identidad y sus privilegios, pero la exposición puede ser invisible para las herramientas de endpoint del propio cliente.

Este es un multiplicador de dependencia en la nube. La credencial es robada de un endpoint, quizás fuera de las flotas de Snowflake o del propietario de los datos. La credencial es aceptada por un servicio global. El rol puede llegar a un almacén de datos consolidado que contiene años de registros de varios sistemas empresariales. El atacante ya no necesita comprometer esos sistemas de origen uno por uno. El valor analítico que hacía útil el almacén de datos para el cliente también hizo que el acceso exitoso fuera valioso para un actor de extorsión.

Los atacantes tienen la responsabilidad directa de robar, comprar, probar y usar credenciales; ingresar a los entornos de los clientes sin autorización; tomar datos; e intentar la venta o extorsión. Describir las fallas de control que hicieron posibles esos delitos no diluye esa responsabilidad. Explica por qué la misma técnica criminal tuvo éxito a escala y dónde se puede reducir la recurrencia.

Las funciones compatibles se convirtieron en una vía de exfiltración

La campaña no se detuvo en la autenticación. Mandiant observó acceso a través de Snowsight, SnowSQL, controladores y herramientas de bases de datos. El actor enumeró usuarios, roles, sesiones, nombres de organizaciones, bases de datos, esquemas y tablas. Utilizó operaciones SQL familiares para seleccionar datos, crear etapas temporales, copiar la salida de consultas en archivos comprimidos y recuperar esos archivos en una máquina local. En varios casos, comandos similares aparecieron en diferentes entornos de clientes.

Esa secuencia hace que el incidente sea legible como funcionalidad ordinaria utilizada bajo identidad no autorizada:

1. Un nombre de usuario y contraseña válidos de un cliente establecieron una sesión.
2. La sesión heredó roles y privilegios de objeto asignados por el cliente.
3. El reconocimiento identificó tablas valiosas y etapas disponibles.
4. Las consultas seleccionaron registros que el rol tenía permitido leer.
5. La creación de etapas temporales yCOPY INTOconvirtió los resultados en archivos descargables.
6. GETmovió los archivos a un cliente controlado por el atacante.

Ningún paso en esa cadena requirió que la base de datos funcionara mal. Es por eso que el cifrado en reposo, aunque necesario, no fue el control decisivo. Ladocumentación de cifrado de extremo a extremo de Snowflakeindica que los datos del cliente se cifran en reposo y bajo TLS en tránsito, pero también explica que Snowflake descifra los datos mientras se realizan transformaciones u operaciones de tabla y permite a los usuarios descargar resultados. El cifrado protege los archivos y el transporte de partes que carecen de autorización o claves. No impide que una identidad aceptada con un rol permitido le pida al servicio que devuelva resultados legibles.

El mismo principio se aplica a las claves administradas por el cliente. El control de claves puede abordar escenarios de proveedor, almacenamiento y revocación, pero una cuenta en ejecución debe usar su jerarquía de claves para servir consultas autorizadas. A menos que una política de claves esté conectada a una decisión separada que rechace la sesión u operación, la base de datos no puede distinguir al propietario de la cuenta de un intruso que ha cumplido con la política de autenticación configurada por el propietario.

Por lo tanto, el diseño de roles controló el radio de acción después del inicio de sesión. Elmodelo de control de acceso actual de Snowflakeadmite controles de acceso basados en roles y discrecionales, propiedad, jerarquía de roles y privilegios de objeto. Una credencial asignada solo a una base de datos o vista estrecha presenta una consecuencia diferente a una que tengaACCOUNTADMIN, uso amplio del almacén de datos o acceso de selección a conjuntos de datos sin procesar. Una cuenta de servicio utilizada por una integración no debe heredar el alcance exploratorio de un administrador humano. El rol temporal de un contratista debe expirar con el compromiso en lugar de permanecer inactivo con una contraseña válida.

Las políticas de protección de datos pueden reducir el resultado incluso cuando un rol está comprometido. Ladocumentación de clasificación de datos sensibles de Snowflakeconecta el descubrimiento de columnas personales y sensibles con políticas de enmascaramiento y acceso a filas. Esa es una descripción de capacidad actual, no evidencia de que cada cliente afectado hubiera clasificado o enmascarado sus datos en 2024. Establece la pregunta de diseño: ¿expuso el cliente tablas históricas completas a identidades que solo necesitaban agregados, particiones recientes, campos tokenizados o vistas aprobadas?

La exportación es en sí misma una función comercial privilegiada y debe gobernarse como tal. Un almacén de datos a menudo necesita descargas masivas para tuberías legítimas, copias de seguridad, entrenamiento de modelos y sistemas posteriores. Una prohibición general rara vez es realista. Pero crear una etapa, descargar un resultado inusualmente grande o usar un cliente y origen de red desconocidos debería ser observable y, para conjuntos de datos de alto riesgo, puede justificar aprobación, límites de tasa, restricciones de destino, elevación de privilegios de corta duración o un rol de exportación separado.

Los comandos de la campaña fueron lo suficientemente normales como para ejecutarse, pero inusuales en el contexto como para merecer una decisión de seguridad rápida.

El cliente era dueño de la configuración; Snowflake era dueño de la línea base

La MFA es la prueba más aguda de responsabilidad compartida porque ambas partes pueden afirmar un hecho verdadero. El administrador del cliente podía y se esperaba que la habilitara. Snowflake había ofrecido MFA desde 2015 y políticas de red desde 2016. Al mismo tiempo, las cuentas exitosas de 2024 podían autenticarse sin MFA, lo que significa que la línea base efectiva del servicio permitía una ruta de solo contraseña para esas cuentas.

La diferencia entre disponibilidad y aplicación no es semántica. Una función de seguridad puede ser gratuita, documentada, recomendada y aún así estar ausente en las sesiones que importan. Los administradores enfrentan integraciones antiguas, usuarios de servicio no interactivos, contratistas, cuentas de emergencia, múltiples clientes y miedo al bloqueo. Esas restricciones explican la fricción en la adopción; no justifican dejar el acceso humano privilegiado dependiente de una contraseña reutilizable.

También le dan al proveedor la información necesaria para construir herramientas de migración, separar identidades humanas y de servicio, y hacer que las excepciones sean explícitas.

Después de la campaña, la dirección pública de Snowflake pasó de la recomendación a valores predeterminados más fuertes. Suanuncio de adhesión al compromiso Secure by Design de julio de 2024enfatizó los controles de políticas de MFA y las verificaciones del Trust Center. En septiembre de 2024, Snowflake dijo quela MFA se aplicaría por defectopara usuarios humanos en cuentas creadas a partir de octubre de 2024, mientras recomendaba SSO con MFA del proveedor de identidad para humanos y autenticación OAuth o de par de claves para servicios. La distinción entre cuentas nuevas y existentes importa. Un valor predeterminado seguro protege la creación futura; no retira automáticamente cada ruta de contraseña heredada en la base instalada.

Snowflake introdujo más tardeProtección de Contraseñas Filtradas, que utiliza fuentes de inteligencia de amenazas para probar contraseñas filtradas reportadas en un proceso que preserva la privacidad y deshabilita una contraseña cuando se confirma que sigue siendo válida. Ese control del lado del proveedor aborda directamente una de las ventajas de UNC5537: credenciales antiguas de infostealers que permanecían utilizables. También es evidencia de que la responsabilidad compartida puede evolucionar. Los clientes aún tienen que administrar identidades y rotaciones, pero el proveedor puede usar inteligencia entre servicios para hacer que una contraseña robada deje de funcionar antes de que cada cliente la encuentre de forma independiente.

Ladocumentación actual de políticas de autenticaciónpermite a los administradores controlar los métodos y clientes permitidos y exigir MFA a nivel de cuenta o usuario. También advierte que las restricciones de tipo de cliente son de "mejor esfuerzo" y no deben ser el único límite de seguridad. Laguía actual de par de clavesofrece a los usuarios de servicio una alternativa a las contraseñas estáticas. Estas páginas describen capacidades disponibles para 2026; no deben leerse retroactivamente como prueba de las características exactas, los valores predeterminados o el estado de aplicación para cada cliente en abril de 2024.

Los estándares ayudan a explicar por qué los valores predeterminados del proveedor pertenecen al análisis. Laguía actual de autenticación y gestión de autenticadores de NISTtrata las contraseñas como no resistentes a la repetición y define la resistencia al phishing como una propiedad del protocolo que no depende de la vigilancia del usuario. Elcompromiso Secure by Design de CISA de 2024identifica específicamente la MFA por defecto, los recordatorios persistentes del producto, el soporte de SSO de base y la publicación de métricas de adopción como formas en que los fabricantes de software pueden aumentar de manera medible el uso de MFA. Snowflake firmó ese compromiso voluntario después de la campaña. El compromiso no es un veredicto legal sobre el diseño de Snowflake en 2024, pero rechaza la idea de que ofrecer una casilla de verificación agota el papel del proveedor.

La línea base responsable distingue los tipos de identidad. Los administradores humanos deben usar MFA resistente al phishing o una identidad federada fuertemente gobernada. Las cargas de trabajo de servicio deben usar credenciales de carga de trabajo que puedan ser delimitadas, rotadas y atribuidas sin pretender que un robot pueda responder a una notificación push. El acceso de emergencia debe ser raro, monitoreado, limitado en el tiempo y probado. Las identidades de contratistas deben tener un propietario, fecha de vencimiento, postura de dispositivo aprobada y sin reutilización de credenciales entre clientes.

Cada excepción debe aparecer en un tablero cuyo denominador sean todas las identidades, no solo los empleados activos.

La política de red fue una segunda puerta, no un sustituto de la identidad

El tercer factor recurrente de Mandiant fue la ausencia de listas de permitidos de red. Por lo tanto, una credencial válida podía usarse desde infraestructura que no tenía ninguna razón comercial para acceder al almacén de datos del cliente. Las restricciones de red no repararían una contraseña robada, pero podrían hacer que esa contraseña fuera insuficiente desde un origen no confiable.

Ladocumentación actual de políticas de red de Snowflakehace explícito el valor predeterminado: sin una política, los usuarios pueden conectarse desde cualquier computadora o dispositivo. Los clientes pueden permitir o bloquear rangos de IP y puntos de conexión privados, aplicar controles a nivel de cuenta o usuario y restringir el acceso a etapas internas con configuración adicional. La conectividad privada y los controles de acceso público pueden fortalecer aún más las cuentas de alta sensibilidad.

El cliente conoce sus oficinas aprobadas, cargas de trabajo en la nube, VPN, contratistas y puntos de integración, por lo que el cliente debe definir la lista de permitidos utilizable. Snowflake no puede inferir cada origen legítimo sin interrumpir el negocio. Sin embargo, el proveedor controla la accesibilidad predeterminada, la sintaxis de la política, la capacidad de simular un cambio, la protección contra bloqueo, el registro y si se advierte al administrador cuando no existe una política de cuenta.

Una plataforma puede preservar la elección del cliente mientras hace que el acceso público sin restricciones sea una excepción visible y limitada en el tiempo en lugar de un estado estable silencioso.

Las reglas de red también tienen límites. Los atacantes pueden obtener una sesión desde un dispositivo de contratista aprobado, enrutar a través de una VPN corporativa permitida, comprometer una carga de trabajo dentro de la nube permitida o robar un token después de la autenticación. Las grandes empresas pueden tener direcciones de salida cambiantes que dificultan las listas estáticas. La conectividad privada puede excluir herramientas SaaS que no la soportan. Estas son razones para emparejar los controles de red con una identidad sólida y detección de comportamiento, no razones para omitirlos.

La campaña demuestra el valor de las puertas independientes. La rotación de contraseñas habría invalidado las credenciales históricas. La MFA habría requerido otro factor. Una política de red habría rechazado orígenes desconocidos. El menor privilegio habría reducido los datos visibles. Los controles de exportación podrían haber interrumpido la preparación. La detección podría haber acortado el tiempo de permanencia. Ninguna medida única es perfecta; el atacante tuvo éxito donde varias estaban simultáneamente ausentes o permisivas.

Para la responsabilidad, cada puerta necesita un propietario y una medida de efectividad. "Política de red soportada" es un hecho del producto. "Cada cuenta de producción tiene una política probada que cubre el servicio y las etapas internas" es un resultado operativo. "MFA disponible" es un hecho del producto. "Ningún humano privilegiado puede establecer una sesión solo con una contraseña reutilizable" es un resultado. La responsabilidad compartida se vuelve significativa solo cuando ambas partes pueden mostrar los resultados en su límite.

El proveedor vio una campaña que cada cliente solo podía ver como un incidente

Un cliente individual podía inspeccionar sus propios inicios de sesión exitosos y fallidos, clientes, direcciones IP, texto de consulta, roles, etapas y movimiento de datos. Snowflake podía correlacionar patrones entre cuentas: la misma infraestructura, clientes inusuales, reconocimiento repetido, comandos de preparación similares, un aumento en los inicios de sesión solo con contraseña o credenciales coincidentes con fuentes de inteligencia de amenazas. Esta asimetría es la responsabilidad no contractual más importante del proveedor. Se crea al operar el servicio a escala.

Lavista LOGIN_HISTORY actual de Snowflakeretiene un año de intentos de inicio de sesión e incluye usuario, IP de origen, cliente informado, primer y segundo factor, éxito y detalles de riesgo relacionados, con latencia documentada.QUERY_HISTORYretiene un año de actividad de consultas y conecta una consulta con el evento de autenticación, sesión, usuario, rol, texto, bytes de resultado, filas descargadas y bytes enviados por la red. Los clientes empresariales pueden usarACCESS_HISTORYpara reconstruir tablas, vistas, columnas, etapas, políticas y objetos modificados a los que se accedió. Esos esquemas proporcionan la materia prima para una investigación de alta calidad.

El historial sin procesar no es lo mismo que la detección. Un cliente debe otorgar acceso a los analistas, exportar o consultar los datos, comprender el comportamiento normal, escribir alertas, enrutarlas, retenerlas más allá de las ventanas nativas si es necesario y contar con personal de respuesta. Una latencia de telemetría de dos horas puede ser aceptable para una revisión retrospectiva pero demasiado lenta para algunas decisiones de exportación masiva. Un límite de edición Enterprise en el historial de acceso a nivel de columna también puede afectar la precisión con la que un cliente puede delimitar la exposición.

Estos hechos del producto y de operación deben probarse durante la adquisición, no descubrirse después de un robo.

ElTrust Center actual de Snowflakeverifica la inscripción en MFA, la política de red de la cuenta, los roles privilegiados, los usuarios inactivos, los inicios de sesión riesgosos, las direcciones IP inusuales y las grandes transferencias de datos a través de escáneres de seguridad e inteligencia de amenazas. La documentación actual también establece limitaciones: algunos paquetes deben habilitarse; algunas detecciones pueden llegar en una hora; y la existencia de una política configurada no prueba que su contenido logre el objetivo previsto. Una vez más, la capacidad actual no es evidencia de lo que un cliente determinado o Snowflake detectó en la primavera de 2024. Muestra lo que un proveedor puede convertir en producto una vez que se comprende un patrón de falla entre clientes.

El sistema de advertencia debería operar en dos capas. En la capa del inquilino, los clientes necesitan eventos inmediatos y exportables y controles para bloquear o suspender la actividad. En la capa del proveedor, Snowflake necesita análisis de campañas y un proceso practicado para notificar a los clientes con suficiente evidencia para actuar.

Una notificación útil incluye identificadores de cuenta y usuario, marcas de tiempo en UTC, infraestructura de origen, factor de autenticación, identificadores de sesión y consulta, comandos, objetos y columnas afectados, acciones de preparación, volumen de transferencia estimado, estado de contención y confianza. "Potencialmente expuesto" es una etiqueta de apertura apropiada solo si va seguida de la evidencia necesaria para resolver el potencial.

La intervención del proveedor también necesita gobernanza. Bloquear automáticamente una sesión de cliente puede interrumpir la producción y puede exceder la autoridad contractual del proveedor. No actuar puede permitir el robo continuado. Por lo tanto, el diseño debe definir los umbrales de riesgo, las suspensiones temporales, los canales de escalamiento del cliente, los contactos de emergencia y un proceso de anulación rápido por adelantado. Los clientes deben designar a personas que puedan recibir una alerta de alta gravedad en cualquier momento y autorizar la suspensión.

El proveedor debe medir el tiempo desde la señal entre cuentas hasta el contacto con el cliente, el tiempo hasta la contención y la proporción de clientes notificados que pueden recuperar un paquete de evidencia completo.

La localidad de los datos no hizo que el acceso fuera local

Snowflake comercializa y documenta la implementación regional porque los clientes tienen requisitos de latencia, resistencia, privacidad, regulación y soberanía. Ladocumentación de regiones compatibles de Snowflakedice que cada cuenta está alojada en una región y que los datos permanecen en esa región a menos que los usuarios los copien, muevan o repliquen explícitamente. La misma página contiene el límite crítico: las regiones dictan dónde se almacenan los datos y se aprovisiona la computación; no limitan el acceso de los usuarios a Snowflake.

Esa distinción convierte la cadena de UNC5537 en un caso de soberanía. Antes de la intrusión, las tablas de un cliente pueden haber sido almacenadas y procesadas en un país seleccionado o en una ubicación de nube regional. Después de una autenticación exitosa, el atacante podía consultar la cuenta regional desde otro lugar, preparar los resultados y descargarlos en un cliente. Mandiant observó el patrón técnico de recuperación local desde etapas temporales.

El registro público de la campaña no establece el país de origen, el país de destino o el estado legal de transferencia para cada víctima, por lo que no se puede respaldar una afirmación universal de transferencia transfronteriza ilegal. Sin embargo, la arquitectura muestra que la localidad de almacenamiento por sí sola no podía hacer cumplir la localidad del usuario.

El intercambio y la replicación entre regiones crean una ruta de movimiento legítima y separada. Laguía de intercambio entre regiones de Snowflakeindica a las organizaciones que confirmen las restricciones legales y regulatorias antes de replicar datos en una región o país diferente. Ese es un movimiento planificado bajo la administración del cliente. La exportación basada en credenciales es diferente: puede crear una copia no controlada fuera del entorno seleccionado sin cambiar la ubicación de la cuenta de origen. Un inventario de datos que solo registre la región de origen seguirá diciendo "UE" o "Canadá" incluso después de que un atacante haya eliminado una copia.

Por lo tanto, la soberanía de datos tiene al menos cuatro capas:

• Ubicación:dónde se aprovisionan los recursos autorizados de almacenamiento y computación.
• Acceso:qué identidades humanas y de máquina pueden conectarse, desde qué dispositivos, redes y jurisdicciones.
• Movimiento:qué consultas, descargas, intercambios, replicaciones, conectores y descargas pueden crear otra copia.
• Evidencia y reparación:si la organización puede probar de dónde se originó el acceso, qué salió, qué personas o registros regulados estuvieron involucrados y con qué rapidez puede contener y notificar.

El proveedor controla partes importantes de las cuatro capas incluso cuando el cliente elige la política. Ofrece regiones y mantiene los datos de la cuenta en ellas. Autentica solicitudes y expone controles de red. Ejecuta comandos de exportación y registra metadatos de consultas. Tiene visibilidad de amenazas entre clientes y puede deshabilitar contraseñas filtradas. El cliente decide su base legal, categorías de datos, roles, orígenes permitidos, enmascaramiento, retención y movimiento aprobado.

Un compromiso de alojamiento regional sin estos controles complementarios puede satisfacer un requisito estrecho de ubicación del centro de datos mientras deja expuesta la autoridad práctica para copiar datos globalmente.

Esta es también la razón por la que el cifrado y la soberanía no deben confundirse. El cifrado puede proteger un objeto almacenado del operador de infraestructura o de un lector de capa de almacenamiento no autorizado. Una aplicación que debe analizar el objeto necesariamente pone los datos a disposición de un contexto de consulta autorizado. Si la garantía de identidad y el alcance del rol son débiles, la localidad criptográfica puede coexistir con la exfiltración operativa.

Las divulgaciones de los clientes muestran diferentes consecuencias, no una violación uniforme

La campaña a menudo se describe a través de nombres de clientes prominentes, pero el registro público de cada cliente tiene su propio alcance, fechas, datos, terminología y confianza. No es seguro transferir los hechos de una empresa a otra o convertir una afirmación de un foro criminal en una población verificada.

ElFormulario 8-K de Live Nation del 31 de mayo de 2024dijo que identificó actividad no autorizada el 20 de mayo en un entorno de base de datos en la nube de terceros que contenía datos de la empresa, principalmente de Ticketmaster. Dijo que el 27 de mayo un actor criminal ofreció a la venta lo que alegaba eran datos de usuarios de la empresa, y que Live Nation estaba notificando a las fuerzas del orden, a los reguladores y a los usuarios según correspondiera. La presentación no nombró a Snowflake, no proporcionó una cantidad confirmada de personas afectadas ni explicó la ruta de autenticación.

Lapágina del incidente de Ticketmaster Canadáofrece un nivel de detalle diferente. Describe el acceso no autorizado a una base de datos en la nube aislada alojada por un proveedor de servicios de datos externo, dice que la base de datos contenía información personal limitada de algunos compradores de boletos norteamericanos y enumera posibles campos que incluyen correo electrónico, número de teléfono, información de tarjeta cifrada y otra información proporcionada por los clientes. Dice que las cuentas de cliente de Ticketmaster no se vieron afectadas. Ese último límite es importante: el compromiso de un almacén de datos back-end no es evidencia de que el atacante haya obtenido el inicio de sesión de Ticketmaster de cada persona o pudiera realizar transacciones a través de la cuenta del consumidor.

Lahoja de asuntos parlamentarios de la Oficina del Comisionado de Privacidad de Canadá de octubre de 2025identifica a Snowflake como el proveedor externo utilizado por Ticketmaster, otorga una ventana de incidente del 2 de abril al 18 de mayo de 2024 para Ticketmaster Canadá y dice que estuvo involucrada información personal de millones, incluidos canadienses. También dice que la investigación permanecía abierta y que Ticketmaster Canadá, como controlador de datos bajo PIPEDA, era la entidad bajo investigación. Este es un contexto regulatorio útil, pero no un hallazgo final que resuelva la adecuación de las salvaguardas, el momento de la notificación o la responsabilidad.

ElFormulario 8-K de AT&T del 12 de julio de 2024ilustra por qué los límites de las fuentes importan incluso cuando los incidentes se discuten juntos. AT&T dijo que un actor accedió ilegalmente a un espacio de trabajo de AT&T en una plataforma en la nube de terceros y exfiltró archivos del 14 de abril al 25 de abril. Los archivos contenían registros de interacción de llamadas y mensajes de texto de casi todos los clientes inalámbricos de AT&T y de clientes de operadores de red virtuales móviles relevantes para períodos específicos en 2022 y un día en 2023. AT&T dijo que los archivos no contenían contenido de llamadas o mensajes de texto, números de Seguro Social, fechas de nacimiento u otra información personal tal como AT&T utilizaba ese término. La presentación en sí no nombra a Snowflake o UNC5537. Respalda los hechos del incidente de AT&T, no una atribución de campaña por sí sola.

Estos registros producen cuatro reglas de disciplina. Primero, usar la presentación de un cliente solo para ese cliente. Segundo, distinguir una base de datos, una cuenta organizacional y un inicio de sesión de consumidor. Tercero, distinguir los campos de datos del número de personas representadas por ellos. Cuarto, preservar hechos negativos como "sin contenido de mensajes" o "cuenta de consumidor no afectada" junto con el impacto. La responsabilidad se vuelve menos creíble cuando el análisis expande afirmaciones dramáticas y descarta las limitantes.

Los clientes siguieron siendo responsables de los datos y las identidades que delegaron

El lado del cliente de la responsabilidad compartida es sustancial. La organización creó o aprobó usuarios de Snowflake, seleccionó rutas de autenticación, asignó roles, cargó datos, retuvo historial, eligió una región, habilitó integraciones y decidió qué empleados y contratistas podían consultar el almacén de datos. También mantuvo la relación principal con las personas representadas en sus datos y generalmente retuvo las obligaciones del controlador bajo la ley de privacidad aplicable.

Un cliente podría haber interrumpido la campaña observada en varios puntos. Podría rotar las contraseñas después de la exposición del endpoint, prohibir las cuentas de servicio solo con contraseña, exigir MFA para humanos, federar el acceso a través de un proveedor de identidad gobernado, restringir redes, caducar usuarios contratistas, reducir las concesiones de roles, clasificar y enmascarar campos sensibles, aislar el privilegio de exportación, monitorear el historial de inicio de sesión y consultas y ensayar las notificaciones del proveedor de la nube.

Para conjuntos de datos regulados o de alto impacto, esos son deberes operativos básicos, no mejoras opcionales delegadas a la adquisición.

La gobernanza de endpoints y contratistas merece una atención particular. Un usuario con un rol de alto impacto en la nube no debe autenticarse desde una computadora personal no administrada. Los contratistas deben usar escritorios virtuales controlados por el cliente o dispositivos con monitoreo de endpoints cuando sea factible. Su identidad debe ser única por cliente, vinculada a un patrocinador y caducar automáticamente. La organización debe buscar en las fuentes de exposición de credenciales sus patrones de cuenta de Snowflake y forzar la rotación cuando aparezca evidencia, sin esperar un uso indebido confirmado.

El menor privilegio debe probarse contra los datos, no contra el título del trabajo. "Analista" puede sonar no administrativo mientras retiene acceso de selección a cada fila en una tabla de clientes, empleados o transacciones. Una revisión de roles debe preguntar qué filas y columnas pueden devolverse, si se necesitan identificadores sin procesar, si los conjuntos de resultados masivos pueden escribirse en etapas y si la identidad puede crear nuevas credenciales o integraciones. Las consultas de muestra bajo el rol son una evidencia más sólida que un nombre de rol de apariencia limpia.

Los clientes también son dueños de la preparación para la respuesta. Deben poder mapear un usuario de Snowflake a un empleado o contratista, una consulta a los sujetos de datos afectados y una exportación a una jurisdicción y análisis de notificación. Los historiales nativos de un año pueden ser insuficientes para una retención legal más prolongada o un descubrimiento tardío, por lo que los clientes de alto riesgo deben transmitir eventos relevantes a un almacén de seguridad independiente.

Las alertas del proveedor necesitan una ruta probada hacia el equipo de seguridad del cliente, la oficina de privacidad, el propietario del negocio y el tomador de decisiones ejecutivo.

Laguía de la cadena de suministro del Marco de Ciberseguridad de NISTrecomienda definir y comunicar los requisitos de los proveedores de acuerdo con la criticidad. Aplicado aquí, un cliente de Snowflake debe contratar el tiempo de notificación de incidentes, los campos de evidencia, la retención, la escalación de soporte, el procesamiento regional, la visibilidad de subprocesadores, el aviso de cambio de control y el acceso de aseguramiento. También debe mantener un plan de salida o aislamiento para las funciones de datos cuya pérdida o compromiso sería intolerable. La responsabilidad compartida debe escribirse como interfaces comprobables, no como un párrafo que aparece solo después de un incidente.

Snowflake siguió siendo responsable de la reducción de riesgos a nivel de servicio

Snowflake no controlaba el malware en el dispositivo personal de un contratista ni la decisión del cliente de dejar la MFA deshabilitada. Sí controlaba si una contraseña antigua podía seguir siendo el único factor, si los orígenes sin restricciones eran el valor predeterminado silencioso, si las configuraciones riesgosas producían advertencias persistentes y qué hacía el proveedor después de observar un patrón entre clientes.

La responsabilidad del proveedor en este caso tiene seis partes.

Línea base segura.El acceso humano privilegiado no debe depender únicamente de una contraseña reutilizable. Las identidades de servicio deben tener un tipo separado y métodos sin contraseña admitidos. Los nuevos valores predeterminados deben llegar a las cuentas existentes de alto riesgo mediante la aplicación por etapas, excepciones explícitas y ayuda para la migración en lugar de proteger solo a los nuevos inquilinos.

Visibilidad de la configuración.El proveedor debe mostrar a los administradores de seguridad un denominador completo: humanos sin MFA, usuarios de servicio heredados con contraseñas, cuentas inactivas, usuarios sin restricciones de red, roles privilegiados y cuentas que permiten el ingreso público. Los hallazgos deben ser visibles a nivel de organización y exportables para auditoría.

Detección entre clientes.La infraestructura reutilizada, las credenciales filtradas, los clientes inusuales, las secuencias de reconocimiento, la creación de etapas temporales y las grandes exportaciones pueden formar una señal de campaña. El proveedor debe detectar en la capa de servicio, contactar a las posibles víctimas y definir cuándo la actividad de alta confianza desencadena un bloqueo temporal.

Telemetría procesable.Los clientes necesitan evidencia de autenticación, consulta, objeto, etapa y transferencia con suficiente retención y baja latencia para contener un robo activo. La evidencia de mayor fidelidad no debe volverse no disponible precisamente donde el servicio almacena los datos de mayor impacto.

Advertencia y coordinación.Una alerta al cliente debe moverse a través de una ruta de emergencia conocida y llevar evidencia, no solo consejos para revisar registros. El proveedor debe rastrear el reconocimiento, la contención y la exposición recurrente, y debe apoyar las solicitudes de las fuerzas del orden y los reguladores sin colapsar observaciones inciertas en recuentos de víctimas confirmadas.

Verificación posterior al incidente.Las características y los valores predeterminados anunciados necesitan medidas de adopción y efectividad. Los cambios posteriores de Snowflake hacia la MFA por defecto, la desactivación de contraseñas filtradas, los hallazgos del Trust Center y los tipos de identidad más fuertes abordan la ruta observada. La pregunta de responsabilidad restante es la cobertura: qué usuarios y clientes están realmente protegidos, qué excepciones permanecen y con qué frecuencia un control detiene un intento real o simulado.

Esta asignación no convierte a Snowflake en el controlador de datos de cada conjunto de datos del cliente, ni hace que el proveedor sea responsable de cada configuración del cliente. Reconoce que una empresa de nube se beneficia de concentrar datos y operar un límite de seguridad. La escala crea deberes que solo el proveedor puede realizar, especialmente la correlación entre inquilinos y la ingeniería de línea base.

Los litigios posteriores ponen a prueba el mismo límite sin resolverlo aún

Snowflake y las empresas afectadas enfrentaron litigios civiles consolidados después de los incidentes. En unaorden judicial federal del 29 de octubre de 2025, el Distrito de Montana sostuvo que los demandantes de instituciones financieras habían alegado suficientemente ciertas teorías de negligencia contra Snowflake y Ticketmaster para sobrevivir a las mociones de desestimación. El tribunal consideró que la MFA por defecto alegada y la previsibilidad eran relevantes para el deber, el incumplimiento y la causalidad en esa etapa procesal.

Esa orden no es un fallo de juicio que determine que Snowflake o Ticketmaster fueron negligentes. En una moción de desestimación, el tribunal evalúa si las alegaciones bien fundamentadas plantean una reclamación plausible; no resuelve pruebas en disputa, determina el mecanismo final del incidente para cada demandante ni asigna daños. Snowflake disputó las acusaciones y argumentó que los fallos de los clientes al implementar MFA, políticas de red y otras salvaguardas causaron el daño.

La orden es significativa porque muestra que describir la MFA como una configuración del cliente no puso fin automáticamente a todas las reclamaciones de deber del proveedor. No es un sustituto del registro de méritos final.

La investigación de privacidad canadiense conllevó una asignación diferente. La OPC dijo que Ticketmaster Canadá seguía siendo el controlador y era la entidad bajo investigación, mientras que la oficina contactó a Snowflake para obtener información. Eso refleja un principio de privacidad común: subcontratar el almacenamiento no subcontrata el deber del controlador de proteger y notificar. No significa que el proveedor de servicios no tenga deberes contractuales, técnicos o legales propios.

El propio 10-K de Snowflake reconoció numerosas demandas, investigaciones regulatorias y consultas de legisladores, pero no informó una asignación universal final de responsabilidad. A la fecha de publicación, las fuentes públicas revisadas aquí no respaldan declarar que Snowflake fue exonerado legalmente, que cada cliente tuvo la culpa legal o que un tribunal o regulador final ha adoptado la asignación operativa de este artículo.

La responsabilidad operativa puede evaluarse antes de la responsabilidad legal final. ¿Era previsible el acceso solo con contraseña? Sí. ¿Podía el cliente exigir MFA y políticas de red? Sí. ¿Podía Snowflake diseñar valores predeterminados y detectar actividad entre clientes? Sí. ¿Los delincuentes explotaron intencionalmente la ruta resultante? Sí. Esas proposiciones pueden coexistir. La ley de agravios, contratos, privacidad y valores puede asignar consecuencias de manera diferente según la jurisdicción y el demandante, pero la ingeniería no debe esperar a que una consigna gane.

Una prueba medible de responsabilidad compartida

La respuesta más sólida no es otro diagrama con "cliente" en un lado y "proveedor" en el otro. Es un conjunto de controles cuya cobertura y comportamiento ante fallas puedan demostrarse.

Los directorios deben recibir resultados en lugar de inventarios de funciones. Las medidas útiles incluyen el porcentaje de usuarios humanos protegidos por MFA resistente al phishing, el número de usuarios de servicio capaces de usar contraseña, la antigüedad de cada excepción de emergencia, el porcentaje de cuentas con políticas de red probadas, el número de identidades de contratistas privilegiadas vencidas, el tiempo medio para alertar sobre orígenes desconocidos, el tiempo para suspender una sesión de alta confianza y el tiempo para producir un paquete de exposición a nivel de campo.

Snowflake debe publicar el progreso agregado donde pueda hacerlo sin exponer a los clientes. El compromiso de CISA contempla explícitamente estadísticas de adopción por usuario y tipo de MFA. Una declaración de que la MFA está disponible es menos informativa que la distribución de inicios de sesión solo con contraseña a lo largo del tiempo. Una declaración de que el Trust Center está habilitado es menos informativa que cuántos hallazgos críticos permanecen abiertos más allá de un período definido.

Una declaración de que se notificó a clientes sospechosos es menos informativa que la latencia de notificación y la integridad del paquete de evidencia.

Los clientes deben exigirse el mismo rigor. Un proveedor no puede salvar a una organización que crea roles amplios, ignore hallazgos, conserve antiguos usuarios contratistas y no tenga a nadie que responda al contacto de emergencia. El propósito de valores predeterminados más fuertes no es transferir la propiedad de la seguridad del cliente a Snowflake. Es hacer que las omisiones predecibles tengan menos probabilidades de convertirse en un robo masivo de datos.

Lo que el registro público aún no establece

La evidencia es lo suficientemente sólida como para reconstruir un patrón de campaña, pero no cada incidente de víctima.

El registro público no identifica a todas las organizaciones notificadas, no confirma que las 165 sufrieran acceso no autorizado ni proporciona un total final de campaña de personas, tablas, registros o bytes descargados afectados. No muestra qué víctimas pagaron demandas de extorsión o si se produjo la eliminación prometida.

No publica el tipo de usuario, la jerarquía de roles, el historial de MFA, la configuración de red, el propietario del endpoint, la secuencia de sesiones, las columnas accedidas o el volumen de exportación para cada organización. Los hallazgos sobre dispositivos de contratistas de varias investigaciones no deben asignarse a cada víctima. La estadística del 79,7 por ciento de exposición de credenciales no debe convertirse en un porcentaje de víctimas.

No establece una vulnerabilidad de software, escape entre inquilinos, compromiso de la plataforma de producción de Snowflake, robo de una credencial maestra del proveedor o acceso a todos los clientes de Snowflake. El uso observado de clientes y comandos compatibles es evidencia de abuso de credenciales, no prueba de que el código del producto fuera explotado.

No prueba que los datos regionales cruzaran una frontera nacional en cada incidente. La arquitectura permitía el acceso remoto y la descarga local; el análisis legal de transferencia requeriría hechos de origen, destino, sujeto de datos, contrato y jurisdicción para cada cliente.

No permite que los posibles campos de Ticketmaster, el alcance de los detalles de llamadas de AT&T o cualquier recuento de foro criminal se generalicen a otros clientes. La presentación de Live Nation no nombró a Snowflake. La presentación de AT&T no nombró a Snowflake ni a UNC5537. La asociación externa puede ser relevante para una investigación adicional, pero las presentaciones deben citarse por lo que realmente establecen.

Finalmente, la documentación actual de Snowflake no prueba el funcionamiento de los controles en abril y mayo de 2024. La MFA por defecto posterior, la protección de contraseñas filtradas, la detección del Trust Center, las políticas de autenticación y los cambios de identidad pueden reducir la recurrencia, pero la evidencia pública de adopción, cobertura de excepciones, rendimiento de detección y efectividad independiente sigue siendo más limitada que las descripciones de funciones.

La responsabilidad compartida debe sobrevivir al momento en que se ignora una recomendación

La campaña de Snowflake no se entiende mejor como una contienda entre dos historias absolutas. Una historia dice que la plataforma fue hackeada y solo el proveedor falló. La evidencia no la respalda. La otra dice que los clientes perdieron contraseñas y, por lo tanto, la pregunta sobre el proveedor está cerrada. Eso es técnicamente incompleto.

UNC5537 encontró una unión escalable entre el compromiso del endpoint y la concentración en la nube. Las contraseñas históricas permanecieron válidas. Las identidades humanas y de servicio no siempre estaban separadas. Faltaban las puertas de MFA y red. Las funciones de consulta y preparación admitidas movieron datos rápidamente. El proveedor podía ver un patrón entre inquilinos, mientras que cada cliente solo veía su propia cuenta. Una región de almacenamiento elegida podía mantener los datos de origen en su lugar incluso cuando una sesión autenticada creaba una copia no controlada en otro lugar.

Los clientes tenían el deber más claro de gobernar sus usuarios, roles, endpoints, contratistas y datos. Snowflake tenía el deber más claro de asegurar y observar el límite del servicio, hacer que las protecciones de alto valor fueran fáciles y cada vez más inevitables, detectar el comportamiento de campaña y proporcionar evidencia. Los atacantes tenían la responsabilidad directa de los actos criminales. Los reguladores y tribunales deben evaluar los deberes legales sobre los hechos y la ley aplicables a cada organización. Estas asignaciones se superponen porque los controles se superponen.

La dirección del producto posterior a la campaña reconoce implícitamente la brecha entre la capacidad y el resultado. La MFA por defecto para nuevos usuarios humanos, la desactivación de contraseñas filtradas, una política de autenticación más sólida, la migración de usuarios de servicio y los hallazgos del Trust Center acercan la seguridad a la línea base del proveedor. No borran la responsabilidad del cliente. Hacen que el sistema compartido dependa menos de que cada administrador encuentre y habilite cada opción correcta antes de que se pruebe una contraseña robada.

Esa es la prueba duradera de responsabilidad para una plataforma de datos en la nube. Supongamos que un cliente pasará por alto una advertencia, un dispositivo de contratista estará infectado, una credencial seguirá siendo válida y un atacante utilizará funciones ordinarias del producto. Luego pregunte si el valor predeterminado bloquea el inicio de sesión, otra puerta rechaza el origen, el rol revela poco, la exportación desencadena una intervención y la evidencia llega al cliente a tiempo.

La responsabilidad compartida es creíble solo cuando el servicio sigue siendo defendible después del error predecible de una de las partes, y cuando ambas partes pueden probar lo que hicieron antes y después de él.