Snowflake hizo de la reparación verificable la prueba de la responsabilidad compartida en la nube

Resumen

• Mandiant informó que todos los incidentes de la campaña de Snowflake que manejó directamente se remontaron a credenciales de clientes comprometidas y no encontró evidencia de que el acceso no autorizado proviniera de una violación del entorno empresarial de Snowflake. Su informe de campaña está enhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
• La campaña aún puso a prueba la responsabilidad del proveedor porque Snowflake controlaba las superficies de autenticación, las configuraciones predeterminadas del producto, las guías de seguridad, la telemetría de cuentas, las herramientas de políticas de red, las verificaciones del Trust Center y los cambios posteriores a la campaña que ningún cliente individual podría crear por sí mismo.
• La reparación verificable significa un cambio medible: MFA predeterminado para usuarios humanos en cuentas nuevas, reglas de contraseña más estrictas, desactivación automática de contraseñas filtradas, paquetes de evidencia para clientes, controles de origen de red y métricas de adopción que muestren la reducción del riesgo en toda la base instalada.
• La responsabilidad del cliente sigue siendo sustancial. Los clientes controlaban la creación de usuarios, la concesión de roles, la rotación de contraseñas, la inscripción en MFA en cuentas existentes, el acceso de contratistas, las listas de permitidos de red, la minimización de datos, los privilegios de exportación y la preparación para la investigación.

No se demostró que la plataforma hubiera sido vulnerada; se demostró que la línea base era permisiva

La primera disciplina es mantener exacto el perímetro de la campaña. El informe de Mandiant de junio de 2024 indicó que el acceso no autorizado en los incidentes que manejó provino de credenciales de clientes comprometidas y que no encontró evidencia de una violación del entorno empresarial de Snowflake. La guía para clientes de Snowflake, amplificada por CISA enhttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access, también instruyó a los clientes a investigar el acceso no autorizado de usuarios y a fortalecer los controles de identidad y red. El registro revisado no establece un exploit de la plataforma Snowflake, un escape entre inquilinos o el robo de una credencial maestra del proveedor.

Ese hallazgo negativo importa porque da forma a la respuesta inmediata. Un cliente no debería esperar un parche del proveedor si el problema activo es una credencial de usuario válida sin MFA, sin lista de permitidos de red y con privilegios de rol amplios. El cliente necesita rotar credenciales, deshabilitar cuentas, inspeccionar el historial de inicio de sesión y consultas, restringir las redes de origen, revisar los roles, preservar los registros y notificar a las personas afectadas o a los reguladores cuando sea necesario.

El error opuesto es decir que el proveedor no tenía responsabilidad porque el primer secreto pertenecía a los clientes. Snowflake operaba el punto final de autenticación que aceptaba esas contraseñas. Proporcionaba la capacidad de MFA y decidía cuándo cambiar el comportamiento predeterminado. Exponía o retenía campos de telemetría. Proporcionaba controles de política de red y hallazgos del Trust Center. Podía ver señales entre clientes que ningún inquilino individual podía ver. Posteriormente, podía incorporar protección de contraseñas filtradas en el servicio. Eso es un control real, incluso si el cliente era dueño de la cuenta.

La presentación anual del año fiscal 2025 de Snowflake enhttps://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htmestablece la posición de responsabilidad compartida de la empresa y describe las consecuencias legales, regulatorias y de reputación tras la actividad de 2024. Una presentación es una declaración de la empresa, no una adjudicación. Sin embargo, es relevante porque Snowflake misma reveló que la campaña afectó el riesgo empresarial más allá de cualquier inquilino de cliente. La responsabilidad compartida se convirtió en un tema de empresa pública.

El enfoque del artículo no es, por lo tanto, "Snowflake fue violado" o "los clientes fallaron solos". Es la reparación verificable. Después de que una campaña explota un patrón previsible de acceso solo con contraseña, credenciales de infostealer obsoletas y restricciones de red faltantes, el proveedor y los clientes necesitan evidencia de que la próxima campaña similar tendrá menos credenciales viables, menos sesiones solo con contraseña, menos orígenes sin restricciones, mejores alertas y una entrega de evidencia más rápida.

La ruta de la campaña usó funciones ordinarias bajo una identidad hostil

Mandiant describió una cadena práctica. Las credenciales habían sido robadas por malware infostealer de sistemas no propiedad de Snowflake, incluyendo en algunos casos máquinas de contratistas utilizadas para actividades personales. Esas credenciales permanecieron válidas, a veces durante años. Las cuentas carecían de MFA. Las instancias de los clientes carecían de listas de permitidos de red. Los atacantes se conectaron con clientes y herramientas estándar, realizaron reconocimiento, seleccionaron datos, prepararon resultados, comprimieron archivos y los recuperaron.

El patrón utilizó funcionalidad de base de datos soportada bajo una identidad no autorizada.

Esa distinción es central para la reparación. El cifrado en reposo no fue la barrera decisiva. La documentación de cifrado de extremo a extremo de Snowflake enhttps://docs.snowflake.com/en/user-guide/security-encryption-end-to-enddescribe el cifrado en reposo y en tránsito, pero también explica que los datos deben ser utilizados durante las operaciones de tabla y pueden ser descargados por usuarios autorizados. Un atacante que satisface la autenticación de la cuenta y hereda un rol puede solicitar al servicio resultados legibles. El cifrado no es un sustituto del aseguramiento de la identidad, el diseño de roles, el control de exportación y la detección.

El control de acceso determinó el radio de explosión después del inicio de sesión. La descripción general del control de acceso de Snowflake enhttps://docs.snowflake.com/en/user-guide/security-access-control-overviewdescribe roles, privilegios, propiedad y jerarquía. Una credencial robada asignada a un acceso restringido es diferente de una asignada a amplios privilegios de lectura o administración de la cuenta. Una cuenta de servicio creada para un pipeline es diferente de un administrador contratista. El privilegio mínimo no es un eslogan; es la diferencia entre una sesión hostil que devuelve una vista y una sesión hostil que recorre las principales tablas del cliente.

La clasificación de datos y el enmascaramiento pueden reducir las consecuencias. La documentación de clasificación de datos sensibles de Snowflake enhttps://docs.snowflake.com/en/user-guide/classify-introconecta el descubrimiento de columnas sensibles con políticas de enmascaramiento y acceso a filas. Esto no prueba que los clientes afectados tuvieran dichos controles. Muestra un camino de reparación: los clientes deben identificar campos personales y regulados, exponer vistas en lugar de tablas sin procesar cuando sea posible, y separar los roles de exportación de los roles de lectura ordinarios.

La ruta de exfiltración observada también convierte la exportación en un control por derecho propio. Las descargas masivas son legítimas en una plataforma de datos. Soportan análisis, copias de seguridad, procesamiento posterior y flujos de trabajo de modelos. Pero una sesión inusual que crea etapas temporales, exporta grandes resultados y los descarga desde un origen desconocido no es simplemente "una consulta". Es un evento de movimiento de datos. La reparación debe hacer que tales eventos sean medibles, atribuibles y, para conjuntos de datos de alto riesgo, interrumpibles.

La disponibilidad de MFA se convirtió en resultados de MFA

MFA estaba disponible antes de la campaña. Las cuentas exitosas en el informe de Mandiant carecían de ella. Esa brecha es el corazón de la disputa de responsabilidad compartida. Un administrador de cliente podía habilitar MFA, y muchos no lo hicieron. Un proveedor puede decir con verdad que el control estaba disponible. Pero un proveedor que ve muchas cuentas de alto valor aún accesibles solo con contraseña no ha logrado el resultado de seguridad, solo ha hecho disponible la configuración.

El anuncio de Snowflake de septiembre de 2024 enhttps://www.snowflake.com/en/blog/multi-factor-identification-default/movió la postura del producto. Dijo que MFA se aplicaría por defecto para los usuarios humanos en cuentas creadas a partir de octubre de 2024 y que los usuarios de servicio no estarían sujetos a ese requisito específico. También anunció requisitos de contraseña más estrictos para contraseñas de usuario recién creadas y modificadas. Esta es una reparación significativa porque cambia la ruta predeterminada para futuras cuentas.

La distinción entre cuentas nuevas y existentes es igualmente significativa. Un valor predeterminado para cuentas futuras no elimina automáticamente todas las rutas de solo contraseña en la base instalada. Los clientes existentes pueden tener usuarios heredados, cuentas de servicio, contratistas, cuentas de emergencia y clientes más antiguos.

Un registro de reparación verificable debería, por lo tanto, medir directamente el riesgo heredado: número y proporción de usuarios humanos sin MFA, usuarios humanos privilegiados sin MFA, usuarios de contraseña con fechas de último inicio de sesión obsoletas, usuarios con credenciales expuestas conocidas, cuentas de servicio que utilizan contraseñas en lugar de autenticación de carga de trabajo más fuerte, y excepciones con propietarios de negocio y fechas de vencimiento.

La documentación de políticas de autenticación de Snowflake enhttps://docs.snowflake.com/en/user-guide/authentication-policiesbrinda a los administradores controles sobre los métodos de autenticación, clientes, proveedores de identidad e inscripción en MFA. Su documentación de autenticación de par de claves enhttps://docs.snowflake.com/en/user-guide/key-pair-authbrinda a las cuentas de servicio una alternativa a las contraseñas estáticas. Estos controles imponen deberes a los clientes, pero también definen la superficie de reparación del proveedor: el producto debe hacer que los buenos patrones sean más fáciles, las malas excepciones visibles y la migración menos arriesgada.

La guía de identidad digital del NIST enhttps://pages.nist.gov/800-63-4/sp800-63b.htmlayuda a establecer el resultado. Las contraseñas no son resistentes a la reproducción. Los métodos resistentes al phishing o vinculados criptográficamente reducen el valor de una contraseña robada. Para los clientes de Snowflake, eso significa que los administradores humanos deben moverse a través de identidad federada o MFA fuerte, mientras que los usuarios de servicio deben usar credenciales de carga de trabajo con alcance que rotan y pueden deshabilitarse sin suplantar a una persona.

El bloqueo de contraseñas filtradas hizo medible la responsabilidad compartida

La reparación más directa del proveedor después de una campaña de credenciales robadas no es un sermón sobre la reutilización de contraseñas. Es hacer que las contraseñas robadas conocidas dejen de funcionar. El anuncio de Snowflake de diciembre de 2024 enhttps://www.snowflake.com/en/blog/leaked-password-protection/dijo que deshabilitaría automáticamente las contraseñas detectadas en la dark web a través de un proceso que preserva la privacidad cuando se confirmara como filtradas y aún válidas. Este control aborda la ventaja central de la campaña: credenciales robadas mucho antes de 2024 seguían siendo aceptadas por el servicio.

La protección de contraseñas filtradas no elimina el deber del cliente. Los clientes aún necesitan seguridad de endpoints, gobernanza de contratistas, rotación de contraseñas, federación, diseño de usuarios de servicio y privilegio mínimo. Pero cambia la división del trabajo. Los clientes individuales a menudo no pueden ver el mercado global de infostealers tan bien como un proveedor de nube. Un proveedor puede comprar o recibir inteligencia de amenazas, hacer coincidir credenciales expuestas de manera controlada y deshabilitar una contraseña antes de que cada cliente lo descubra de forma independiente.

Ese es el tipo de control a nivel de proveedor que convierte la responsabilidad compartida de una cláusula en un comportamiento del sistema.

La pregunta de evidencia es la adopción y el rendimiento. ¿Cuántas contraseñas filtradas válidas se encontraron? ¿Con qué rapidez se deshabilitaron? ¿Cuántas pertenecían a usuarios privilegiados? ¿Cuántas cuentas pasaron de contraseña a acceso de par de claves o federado? ¿Cuántos eventos de deshabilitación de contraseñas generaron fricción de soporte o soluciones alternativas inseguras? ¿Cuántos clientes aún tienen excepciones? Sin métricas, la protección de contraseñas filtradas sigue siendo un buen anuncio. Con métricas, se convierte en reparación verificable.

El compromiso de diseño seguro por defecto de CISA enhttps://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdfenmarca esta distinción. Pide a los fabricantes que vayan más allá de los controles opcionales hacia resultados medibles como MFA por defecto y métricas de adopción. El anuncio de adhesión de Snowflake en julio de 2024 enhttps://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/colocó a la empresa dentro de ese compromiso público. El compromiso es voluntario y no es un veredicto legal sobre la campaña. Es relevante porque identifica el tipo de evidencia que los clientes deberían esperar después del evento.

La política de red fue una segunda barrera

Mandiant identificó la falta de listas de permitidos de red como un factor recurrente. La documentación de políticas de red de Snowflake enhttps://docs.snowflake.com/en/user-guide/network-policiesestablece el valor predeterminado práctico: sin una política, los usuarios pueden conectarse desde cualquier computadora o dispositivo. Los clientes pueden restringir el acceso por ubicaciones de red permitidas o bloqueadas y usar patrones de conectividad privada para límites más fuertes.

El cliente es el actor mejor posicionado para conocer los orígenes legítimos: oficinas, VPNs, cargas de trabajo en la nube, escritorios de contratistas administrados y proveedores de integración aprobados. Snowflake no puede adivinar cada ruta válida sin romper el servicio. Pero Snowflake controla si el acceso público sin restricciones es silencioso o visible. Un programa de reparación verificable debería informar qué cuentas carecen de políticas de red, qué usuarios privilegiados las eluden, si el acceso de etapas internas está cubierto y si las políticas realmente coinciden con los orígenes aprobados por el negocio.

Los controles de red no son suficientes por sí solos. Un atacante puede usar una VPN aprobada, comprometer una máquina de contratista que ya está dentro de una lista de permitidos o robar un token después de la autenticación. Sin embargo, la defensa debe ser en capas. Una contraseña robada, sin MFA, sin restricción de red, rol amplio y exportación no monitoreada es una cadena. Romper cualquier eslabón puede importar. La reparación es el proceso de reducir el número de entornos de clientes donde todos los eslabones permanecen abiertos juntos.

El proveedor también debe hacer segura la gestión de bloqueos. Los administradores pueden evitar las políticas de red porque temen bloquear a usuarios de negocio o trabajos de servicio. La simulación, el despliegue por etapas, los contactos de emergencia, las excepciones temporales y los registros claros reducen ese miedo. Cuanto mejor sea la ruta de migración, más difícil será tratar las políticas faltantes como algo ordinario.

La telemetría es el límite de la evidencia

Después de una campaña de robo de datos, los clientes necesitan más que una garantía general. Necesitan saber quién inició sesión, desde dónde, con qué factor, usando qué cliente, bajo qué rol, qué consultas se ejecutaron, qué objetos se tocaron, qué datos se descargaron, qué etapas se utilizaron y cuántos datos se movieron. La documentación actual de Snowflake describe múltiples vistas que pueden apoyar dicho trabajo.

LOGIN_HISTORY enhttps://docs.snowflake.com/en/sql-reference/account-usage/login_historyproporciona intentos de inicio de sesión con IP de origen, cliente, éxito e información del factor. QUERY_HISTORY enhttps://docs.snowflake.com/en/sql-reference/account-usage/query_historyproporciona actividad de consultas, usuario, rol, texto de consulta, tamaño del resultado, filas descargadas y bytes enviados por la red. ACCESS_HISTORY enhttps://docs.snowflake.com/en/sql-reference/account-usage/access_historypuede ayudar a reconstruir el acceso a objetos y columnas para ediciones elegibles. La documentación del Trust Center enhttps://docs.snowflake.com/en/user-guide/trust-center/overviewdescribe verificaciones de postura y detecciones para MFA, políticas de red, inicios de sesión riesgosos, direcciones IP inusuales y transferencias grandes.

Esas son capacidades. La capacidad no es prueba de preparación para la investigación. Los clientes deben tener derechos para consultar las vistas, exportarlas a un almacenamiento de seguridad duradero, comprender la latencia y retención, y correlacionarlas con datos del proveedor de identidad, endpoint y ticketing. Las diferencias de edición pueden cambiar la precisión del alcance a nivel de campo. Las vistas del proveedor pueden tener retrasos que afectan la contención activa. El texto de la consulta por sí solo puede no decirle a un equipo de privacidad qué individuos estaban representados a menos que el cliente tenga mapas de datos.

La reparación verificable debería, por lo tanto, incluir paquetes de evidencia. Cuando Snowflake notifica a un cliente potencialmente expuesto, el cliente debería recibir identificadores de cuenta, usuarios, marcas de tiempo, redes de origen, estado del primer y segundo factor, identificadores de cliente, identificadores de sesión y consulta, roles, objetos tocados, nombres de etapa, volumen de descarga, confianza y contención recomendada. Una etiqueta como "potencialmente expuesto" es aceptable como apertura, pero debe ir seguida de suficientes datos para que el cliente decida si la información personal estuvo involucrada.

La intervención del proveedor también necesita autoridad previa. Un proveedor de nube puede ver actividad sospechosa antes que un cliente, pero bloquear automáticamente una sesión puede interrumpir la producción. No actuar puede permitir el robo. La reparación debería definir umbrales para la suspensión temporal, contactos de emergencia con el cliente, preservación de evidencia y anulación. Los clientes deben designar contactos de seguridad que puedan actuar a cualquier hora. Snowflake debería medir el tiempo desde la señal entre clientes hasta la notificación al cliente y el tiempo desde la notificación hasta la contención.

La localidad de datos se detuvo en el acceso

La elección de región de Snowflake puede importar para la latencia, resiliencia, privacidad y adquisiciones. La documentación de regiones soportadas enhttps://docs.snowflake.com/en/user-guide/intro-regionsdice que una cuenta está alojada en una región y que los datos permanecen allí a menos que los usuarios los copien, muevan o repliquen explícitamente. También establece el límite clave: la elección de región no limita el acceso del usuario a Snowflake.

La campaña convirtió ese límite en un problema de soberanía. Las tablas de un cliente pueden haber estado almacenadas en una región aprobada. Una identidad válida aún podía conectarse desde otro lugar, consultar los datos, descargarlos a una etapa y descargar una copia. La ubicación de la cuenta de origen no impidió el acceso remoto o la exportación. El registro público de la campaña no establece los países de origen y destino para cada víctima, por lo que no se puede sustentar una conclusión legal transfronteriza universal. La lección arquitectónica permanece: la localidad de almacenamiento no es localidad de acceso.

La guía de intercambio entre regiones de Snowflake enhttps://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.htmladvierte a los clientes que confirmen las restricciones legales y regulatorias antes de replicar datos a otra región o país. Esa guía se refiere al movimiento aprobado. La exportación impulsada por credenciales es diferente porque puede crear una copia no controlada fuera de la región seleccionada sin cambiar la región de la cuenta de origen. Un inventario de datos que registra solo la región de origen puede ser preciso y aún así incompleto después de una exportación.

Por lo tanto, la reparación de la soberanía de datos necesita cuatro capas: dónde se alojan los datos autoritativos, qué identidades pueden conectarse desde qué dispositivos y jurisdicciones, qué funciones de movimiento pueden crear copias y qué evidencia existe después de un incidente. Snowflake controla las ofertas de regiones, autenticación, herramientas de red, mecánicas de exportación y telemetría. Los clientes controlan la base legal, los campos de datos, las concesiones de roles, las aprobaciones de movimiento y el análisis de notificaciones. Ambas partes necesitan evidencia en su límite.

Los casos de clientes muestran consecuencias, no un recuento maestro único

La forma pública de la campaña fue influenciada por las divulgaciones de las empresas afectadas. Cada registro debe permanecer dentro de sus propios hechos.

La presentación de Live Nation de mayo de 2024 enhttps://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htmdijo que la compañía identificó actividad no autorizada en un entorno de base de datos en la nube de terceros que contenía principalmente datos de Ticketmaster y que un actor criminal ofreció posteriormente supuestos datos de usuarios de la compañía a la venta. La presentación no nombró a Snowflake ni proporcionó un recuento confirmado de personas afectadas.

La página de incidentes de Ticketmaster Canadá enhttps://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incidentdescribió una base de datos en la nube de terceros aislada, campos posibles para algunos compradores de boletos norteamericanos y el límite de que las cuentas de clientes de Ticketmaster no se vieron afectadas. El comisionado de privacidad de Canadá identificó posteriormente a Snowflake como el proveedor de Ticketmaster en una sesión informativa parlamentaria enhttps://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/, al tiempo que indicaba que la investigación seguía abierta y que Ticketmaster Canadá seguía siendo el controlador bajo revisión.

La presentación de AT&T de julio de 2024 enhttps://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htmdescribió acceso no autorizado a un espacio de trabajo de AT&T en una plataforma de nube de terceros y la exfiltración de registros de interacciones de llamadas y mensajes de texto. La presentación no nombró a Snowflake. Es útil para comprender un incidente divulgado de espacio de trabajo en la nube de terceros y sus límites de campo, no como atribución independiente.

Estos ejemplos no crean un recuento de personas a nivel de campaña. Las aproximadamente 165 organizaciones potencialmente expuestas de Mandiant son una población de notificación, no un recuento confirmado de víctimas, registros o individuos afectados. Cada cliente tenía diferentes datos, roles, retención, regiones y deberes de notificación. La reparación verificable debe ayudar a cada cliente a definir sus propios hechos en lugar de hacer que un solo número a nivel de plataforma haga todo el trabajo.

Una nota tipográfica para paquetes de evidencia

Cuando los clientes reciben evidencia de seguridad en la nube de alta gravedad, el diseño puede decidir si la persona correcta actúa rápidamente. Una tabla de sesiones, factores, roles, objetos y transferencias debe ser legible bajo presión. El siguiente bloque tipográfico pertenece al cuerpo público porque el diseño de la evidencia es parte de la reparación.

La tipografía es el arte y la técnica de organizar los tipos para que el lenguaje escrito sea legible, fácil de leer y visualmente atractivo. Implica seleccionar tipos de letra, tamaños de punto, longitudes de línea, espaciado entre líneas y espaciado entre letras.

• La tipografía se originó con la invención de los tipos móviles por Johannes Gutenberg en el siglo XV.
• Los elementos clave incluyen la selección de fuentes, el kerning, el tracking y el interlineado.
• Una buena tipografía mejora la legibilidad y transmite un estado de ánimo o tono en el diseño.

Para los clientes de Snowflake, la evidencia legible significa marcas de tiempo en una sola base de tiempo, etiquetas claras de usuario y rol, separación de la actividad confirmada de la sospecha, estado de MFA visible y vínculos directos entre consultas, etapas, volumen de transferencia y almacenes de datos afectados. Una exportación densa de registros puede ser completa pero inutilizable. Un paquete de evidencia conciso puede ser la diferencia entre una decisión de contención rápida y un análisis de privacidad retrasado.

Responsabilidad por control práctico

Los atacantes controlaron la actividad criminal: usar credenciales robadas, entrar en entornos de clientes, preparar datos, llevárselos e intentar la venta o extorsión. Son responsables de esa conducta.

Los clientes controlaron muchas barreras fallidas. Crearon usuarios, asignaron roles, decidieron si los usuarios humanos podían iniciar sesión solo con contraseñas, retuvieron credenciales obsoletas, permitieron el acceso de contratistas, dejaron algunas cuentas sin políticas de red, concedieron acceso a los datos y gobernaron las exportaciones. Un cliente cuyo almacén de alto valor aceptó una contraseña antigua desde un origen desconocido sin MFA o roles restringidos no puede transferir toda la responsabilidad al proveedor.

Snowflake controló la línea base y las herramientas de reparación. Controló si los nuevos usuarios humanos tenían MFA por defecto, si las contraseñas filtradas se deshabilitaban del lado del proveedor, si las configuraciones riesgosas aparecían en el Trust Center, qué campos de telemetría estaban disponibles, cómo se notificaba a los clientes, cómo se redactaba la guía y con qué rapidez se enviaban los controles posteriores a la campaña. Un proveedor que ve el mismo patrón en todos los inquilinos tiene el deber de reducir el patrón a escala, no solo de decirle a cada cliente que lea el manual.

Los proveedores de identidad, contratistas y propietarios de endpoints controlaron las condiciones adyacentes. Los dispositivos de contratistas utilizados en todos los clientes pueden propagar un incidente de infostealer a varios inquilinos de la nube. Los proveedores de identidad pueden aplicar factores más fuertes y acceso condicional. Los endpoints administrados pueden mantener las credenciales fuera de las máquinas personales. Esos actores importan, pero no borran los deberes del cliente y del proveedor sobre la cuenta de Snowflake en sí.

Los reguladores, aseguradoras y equipos de adquisiciones controlan los incentivos. La guía de cadena de suministro del NIST enhttps://csrc.nist.gov/pubs/sp/1305/finalapoya la definición de requisitos de proveedores proporcionales a la criticidad. Para un almacén de datos, eso significa que los contratos y renovaciones deberían solicitar métricas de adopción de MFA, respuesta a contraseñas filtradas, campos de paquetes de evidencia, garantías de retención, tiempos de notificación, escalación de soporte y controles de movimiento regional. Un cuestionario de seguridad que solo pregunta si MFA existe es demasiado superficial después de esta campaña.

Qué probaría una reparación duradera

El registro de reparación debería incluir al menos diez resultados.

Primero, todos los nuevos usuarios humanos tienen MFA por defecto o acceso federado más fuerte, y la base instalada muestra una proporción creciente de cuentas humanas y humanas privilegiadas protegidas. Segundo, los usuarios de servicio se alejan de las contraseñas estáticas hacia credenciales de par de claves, OAuth u otras credenciales de carga de trabajo con alcance y rotación. Tercero, la protección de contraseñas filtradas informa eventos de deshabilitación confirmados y el tiempo medio para deshabilitar. Cuarto, la cobertura de políticas de red aumenta, especialmente para cuentas privilegiadas y etapas internas.

Quinto, los hallazgos del Trust Center no solo se muestran, sino que se remedian con propietarios de excepciones y fechas de vencimiento. Sexto, la retención y exportación de telemetría son suficientes para el descubrimiento tardío y el alcance de la privacidad. Séptimo, las detecciones de grandes descargas y orígenes inusuales se ajustan y enrutan a personas que pueden actuar. Octavo, las notificaciones del proveedor incluyen evidencia concreta de sesión, consulta, rol, objeto y transferencia. Noveno, los clientes afectados pueden mapear consultas a personas y categorías de datos regulados.

Décimo, los contratos de clientes y las revisiones de renovación incorporan evidencia en lugar de confiar en la redacción de responsabilidad compartida.

El litigio puede influir en el registro, pero no debe reemplazar la evidencia de control. La orden en etapa de alegatos en el litigio multidistrito de Snowflake enhttps://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdfpermitió que ciertas acusaciones procedieran mientras las trataba bajo estándares procesales. Eso no es un hallazgo final de responsabilidad. Muestra que los tribunales pueden examinar los valores predeterminados del proveedor, la previsibilidad y la causalidad incluso cuando la historia pública comienza con credenciales de clientes.

El problema de la base instalada

Los valores predeterminados seguros son más efectivos en el momento de la creación. Son más difíciles en una base instalada donde los clientes ya tienen automatización, usuarios de servicio, contratistas, proveedores de identidad, clientes antiguos y cuentas de emergencia. El cambio a MFA por defecto de Snowflake para nuevas cuentas fue un paso material, pero el riesgo de la campaña residía en gran medida en cuentas existentes con hábitos existentes. Por lo tanto, la reparación verificable necesita una historia de migración para la base instalada, no solo una historia para nuevas cuentas.

El problema de la base instalada tiene varias capas. Primero, los usuarios humanos antiguos aún pueden autenticarse directamente con contraseñas porque la federación nunca se completó. Segundo, los usuarios privilegiados pueden tener excepciones porque los administradores temen el bloqueo. Tercero, los usuarios de servicio pueden estar mal clasificados como humanos o los humanos pueden usar credenciales de estilo de servicio. Cuarto, los contratistas pueden conservar el acceso después de que un proyecto termina. Quinto, las cuentas inactivas aún pueden tener roles que alcanzan datos confidenciales.

Sexto, las integraciones pueden fallar si las reglas de contraseñas o las políticas de red cambian repentinamente.

El proveedor puede reducir esta fricción sin hacerse cargo del inquilino del cliente. Puede mostrar a los administradores una lista priorizada de identidades riesgosas, divididas por privilegio y alcance de datos. Puede proporcionar políticas de simulación que muestren quién sería bloqueado por MFA o restricciones de red. Puede requerir propietarios de excepciones y fechas de vencimiento. Puede distinguir las cuentas de emergencia de las cuentas heredadas ordinarias. Puede proporcionar ayudas de migración para usuarios de servicio que se mueven a patrones de par de claves u OAuth.

Puede enviar recordatorios de producto repetidos vinculados a riesgos reales en lugar de banners genéricos.

Los clientes entonces tienen que actuar. Un cliente que recibe un panel que muestra usuarios privilegiados solo con contraseña y los deja sin cambios durante meses es dueño de ese riesgo residual. Un cliente que no puede decir si una cuenta de contratista aún es necesaria tiene una falla de gobernanza de identidad. Un cliente que permite que una cuenta de servicio lea tablas completas sin procesar porque "el pipeline solía necesitarlo" tiene un alcance de rol excesivo. La responsabilidad compartida se vuelve concreta cuando el proveedor muestra la evidencia y el cliente la remedia o registra una excepción responsable.

El registro de reparación debería separar tres estados: remediado, excepcionado y desconocido. Remediado significa que la condición de riesgo desapareció. Excepcionado significa que un propietario de negocio la aceptó con controles compensatorios y una fecha para revisión. Desconocido significa que nadie ha asumido la responsabilidad. Un programa maduro impulsa el recuento desconocido hacia cero. La tranquilidad pública a menudo omite esta distinción; la reparación verificable depende de ella.

La evidencia del cliente debe conectar los registros técnicos con las personas

Snowflake puede exponer una rica telemetría técnica, pero la respuesta legal y de privacidad requiere un puente desde los objetos técnicos hasta las personas y obligaciones. Un identificador de consulta, nombre de rol o ruta de etapa es solo el comienzo. El cliente debe saber qué tabla contenía qué campos personales, qué titulares de datos estaban representados, qué reglas de país o estado aplican, qué deberes de notificación contractual existen y qué sistemas posteriores recibieron copias. Sin ese puente, el cliente puede saber que los bytes salieron pero no saber a quién notificar.

Ese puente debe prepararse antes de un incidente. Los propietarios de datos deben mantener inventarios de campos para datos regulados, propósito comercial, período de retención, política de enmascaramiento y rutas de exportación aprobadas. Los equipos de seguridad deben saber dónde se retienen los registros de Snowflake fuera de la plataforma y durante cuánto tiempo. Los equipos de privacidad deben poder solicitar una lista de tablas afectadas y recibir un mapeo a categorías de personas y campos. Los equipos legales deben saber qué regiones y contratos de clientes se adjuntan a esos registros.

La evidencia del proveedor puede facilitar esto. Si una notificación incluye los roles exactos, objetos, etapas y volumen, el cliente puede evitar una búsqueda amplia y lenta. Si el proveedor también etiqueta si MFA estaba presente, si el origen era inusual y si la protección de contraseñas filtradas deshabilitó posteriormente la credencial, el cliente puede entender la causa y la contención. Si el proveedor solo da consejos generales, el cliente debe reconstruir la evidencia mientras el reloj para la notificación y la respuesta a la extorsión ya está corriendo.

La campaña también expuso una cuestión de retención para la telemetría misma. Los historiales nativos pueden cubrir un año, pero las disputas legales, el descubrimiento tardío y las consultas de los reguladores pueden extenderse más. Los clientes de alto riesgo deben transmitir registros a un almacén de seguridad independiente con retención alineada con sus obligaciones. Un proveedor debe hacer que dicha exportación sea práctica y documentada. El cliente debe probar que funciona reconstruyendo periódicamente una ruta de acceso de muestra desde el inicio de sesión hasta la consulta y la categoría de datos.

La reparación no puede basarse en la vergüenza del cliente

Después de una campaña de credenciales, es tentador tratar a los clientes sin MFA como la lección de la historia. Eso es parcialmente cierto y aún insuficiente. Avergonzar públicamente a los clientes no deshabilita las contraseñas filtradas, rediseña los valores predeterminados ni entrega paquetes de evidencia. Incluso puede hacer que los clientes oculten configuraciones débiles hasta que un incidente obligue a la divulgación.

El mejor modelo es el endurecimiento progresivo. El proveedor comienza con visibilidad, luego valores predeterminados más fuertes, luego advertencias dirigidas, luego gobernanza de excepciones, luego aplicación para categorías de riesgo donde la consecuencia lo justifica. Los clientes reciben tiempo de migración y herramientas, pero también pierden la capacidad de dejar brechas de alto riesgo invisibles. Los equipos de adquisiciones luego solicitan métricas de adopción y recuentos de excepciones, no solo listas de características.

Este enfoque reconoce que las plataformas en la nube son sistemas operativos compartidos para datos empresariales. Un proveedor que hace un valor predeterminado más seguro puede aumentar brevemente la fricción del cliente, pero también reduce el grupo de objetivos disponibles para los grupos criminales. Un cliente que acepta la aplicación puede necesitar actualizar scripts o identidades, pero gana una historia más sólida para reguladores, aseguradoras y titulares de datos. La reparación funciona cuando ambas partes pueden señalar condiciones cambiadas, no mensajes cambiados.

Las adquisiciones deben exigir telemetría de reparación

Un comprador de una plataforma de datos de alto valor debe tratar la telemetría posterior a la campaña como un requisito de adquisición. La pregunta no es solo si el proveedor ahora ofrece MFA, políticas de red, controles de contraseñas filtradas y hallazgos del Trust Center. La pregunta es si el comprador puede recibir evidencia de que esos controles están activos, completos y probados en la propia cuenta del comprador. La disponibilidad de características es lenguaje de proveedor. La cobertura de control es lenguaje operativo.

El registro de adquisición debe solicitar un informe de cobertura de identidad, que incluya usuarios humanos, usuarios privilegiados, usuarios de servicio, cuentas inactivas, contratistas externos, estado de federación, estado de MFA y excepciones de contraseña. Debe solicitar cobertura de red por cuenta, clase de usuario, etapas internas y puntos finales privados. Debe preguntar si la protección de contraseñas filtradas está habilitada, qué avisos de eventos produce y cómo se refleja una contraseña deshabilitada en los registros de auditoría.

Debe preguntar qué hallazgos del Trust Center están disponibles en el nivel contratado y cuánto tiempo se retiene el historial relevante.

Los términos de incidentes deben ser igualmente concretos. Una cláusula de notificación genérica es débil después de esta campaña. Los clientes necesitan plazos para la notificación de alta gravedad, campos de evidencia que se incluirán, contactos de emergencia, escalación de soporte, preservación de registros y cooperación en el alcance de los titulares de datos. Un cliente que posee datos personales regulados debe requerir paquetes de evidencia de muestra antes de la renovación, no después del robo.

Un ejercicio de simulación puede probar si el proveedor y el cliente pueden pasar de un inicio de sesión sospechoso al análisis de campos afectados dentro de la ventana necesaria.

Esto no traslada todo el trabajo a Snowflake. El cliente debe mantener sus propios mapas, retener registros y conocer sus obligaciones de privacidad. Pero el proveedor controla muchos hechos necesarios para que el mapa sea utilizable. Un proceso de adquisición que solo pide atestaciones perderá el problema operativo. Un proceso que pide telemetría de reparación revelará si la responsabilidad compartida está lista para la próxima campaña.

La misma evidencia debería aparecer en las renovaciones. Si un cliente permanece en acceso basado en contraseñas un año después de la campaña, la renovación debe forzar una excepción nominada o una migración financiada. Si un cliente no puede recibir detalles a nivel de ACCESS_HISTORY debido a la edición, la renovación debe documentar si esa limitación es aceptable para los datos almacenados. Si las políticas de red están ausentes, la renovación debe identificar claramente el bloqueador operativo. La reparación debe revisarse antes de que la influencia desaparezca en otro período de contrato.

La evidencia de renovación también debe separar el cambio de plataforma del cambio de inquilino. Snowflake puede enviar un valor predeterminado más fuerte, pero la cuenta del cliente aún puede contener usuarios solo con contraseña, roles amplios, contratistas obsoletos y etapas no revisadas. El comprador debe solicitar el libro de excepciones de la propia cuenta, no solo la hoja de ruta del producto del proveedor. Esa distinción evita una deriva familiar posterior al incidente: el proveedor anuncia un control, los clientes asumen que el riesgo se ha movido y la base instalada permanece materialmente expuesta.

Para las juntas directivas y los equipos de privacidad, ese registro a nivel de inquilino es el puente entre la reparación técnica y la confianza legal. Una afirmación de que "MFA está disponible" no responde si la cuenta afectada lo usó. Una afirmación de que "existen políticas de red" no responde si la credencial robada podía alcanzar los datos desde un origen inusual. Una afirmación de que "la telemetría se retiene" no responde si la organización puede mapear consultas a campos regulados. La reparación verificable vive en esas respuestas específicas de la cuenta.

Qué no inferir

Un relato restringido debe evitar cuatro saltos. Primero, la campaña no prueba que la plataforma de producción de Snowflake fuera vulnerada. Segundo, no prueba que todas las organizaciones notificadas perdieran datos. Tercero, no prueba que todos los clientes afectados tuvieran los mismos campos, personas o deberes legales. Cuarto, los cambios de producto posteriores a la campaña no prueban por sí mismos negligencia antes de los cambios. Los productos de seguridad evolucionan después de los incidentes por muchas razones, incluyendo mejor inteligencia de amenazas y estándares cambiantes.

Al mismo tiempo, la restricción no requiere silencio sobre el deber del proveedor. Un proveedor puede estar libre de un hallazgo de violación de plataforma y aún ser responsable del diseño predeterminado, la calidad de la telemetría y las advertencias entre clientes. Un cliente puede tener la culpa de controles de identidad débiles y aún necesitar los datos del proveedor para investigar. Una orden de litigio puede ser no definitiva y aún mostrar que el MFA por defecto y la previsibilidad serán examinados. La responsabilidad equilibrada mantiene todas esas proposiciones vivas a la vez.

La evaluación final es de alto impacto y alta confianza. La evidencia confirmada respalda una campaña de credenciales de clientes, no una violación de la plataforma Snowflake. Pero la evidencia también muestra por qué los valores predeterminados del proveedor, la telemetría y la automatización de seguridad entre clientes son parte de la responsabilidad. La responsabilidad compartida es creíble solo cuando ambas partes pueden mostrar las barreras que cerraron. Después de esta campaña, la prueba de Snowflake no es si puede decir que MFA existía.

Es si menos contraseñas robadas pueden convertirse en sesiones, menos sesiones pueden alcanzar datos amplios y más clientes pueden probar exactamente qué sucedió antes de que los datos salgan.