Violación de metadatos de Capital One: cuando la configuración en la nube se convirtió en una cadena de responsabilidad

Resumen

• Capital One dijo que un individuo externo explotó una vulnerabilidad de configuración el 22 y 23 de marzo de 2019. Los registros penales y regulatorios describen una cadena de control más larga: un firewall de aplicaciones web mal configurado permitió que los comandos llegaran al entorno de la nube, se obtuvieron credenciales para un rol, esas credenciales podían enumerar y copiar objetos de almacenamiento, y la supervisión no convirtió la actividad sospechosa en contención oportuna.
• La Oficina del Contralor de la Moneda no caracterizó el evento como un error de ingeniería aislado. Sus conclusiones consentidas se remontaron a la migración a la nube del banco en 2015 e identificaron una evaluación de riesgos ineficaz, controles deficientes de seguridad de red y prevención de pérdida de datos, mala disposición de alertas, brechas de auditoría interna y acción ineficaz de la junta para responsabilizar a la gerencia.
• La responsabilidad existió en varios planos sin volverse legalmente intercambiable. Un jurado federal condenó a Paige Thompson por conducta criminal. Capital One aceptó una multa de $80 millones de la OCC sin admitir ni negar los hallazgos de la agencia. Las reclamaciones de los consumidores contra Capital One y Amazon sobrevivieron en parte en la etapa de alegatos y luego se resolvieron, por lo que el caso civil no produjo una asignación de culpa en el juicio entre el banco y el proveedor de la nube.
• La lección de soberanía no es que seleccionar una región de nube doméstica resuelva la protección de datos. Aproximadamente seis millones de personas en Canadá se vieron afectadas, incluidos alrededor de un millón cuyos números de seguro social se vieron comprometidos. La localidad, la retención, los permisos de identidad, el acceso a metadatos, la autoridad de cifrado, el registro y el acceso del regulador a la evidencia deben gobernarse como un sistema único.

Una filtración descrita de manera demasiado limitada

La versión familiar de la filtración de Capital One es compacta: un firewall mal configurado, un atacante accedió a datos en Amazon Web Services y se tomó información relacionada con más de 100 millones de personas. Cada parte de esa frase apunta en la dirección correcta. Sin embargo, como relato de responsabilidad, es demasiado limitado. Hace que el evento parezca una sola mala configuración en el borde de un entorno controlado.

El registro oficial describe algo más estructural. Elanuncio del 29 de julio de 2019 presentado ante la SECdijo que la empresa determinó el 19 de julio que un individuo externo obtuvo información personal después de explotar una vulnerabilidad de configuración específica. Situó el acceso no autorizado material los días 22 y 23 de marzo, dijo que un informe de divulgación responsable llegó el 17 de julio y explicó que la empresa corrigió la configuración y trabajó con las autoridades federales. También dijo que el modelo operativo en la nube ayudó a la empresa a diagnosticar y corregir el problema rápidamente una vez que se conoció.

Ese último punto es importante. Capital One no presentó la nube en sí misma como la causa. La empresa enfatizó que los elementos de infraestructura relevantes podrían existir en la nube o en las instalaciones. La posición es técnicamente defendible: un proxy inverso o un firewall de aplicaciones web puede convertirse en un relé no intencionado en cualquier entorno; las credenciales de servicio pueden ser demasiado poderosas en cualquier entorno; una identidad legítima puede leer datos cifrados en cualquier entorno. Sin embargo, la nube cambia la velocidad, la abstracción y la escala a las que se combinan esas condiciones.

Un comando que cruza un límite de aplicación puede llegar a un servicio de metadatos de instancia. Una credencial temporal puede ejercerse a través de una API desde otro lugar. Un rol de almacenamiento puede enumerar un lago de datos medido mucho más allá del disco de un servidor. La misma automatización que hace eficientes las operaciones en la nube puede hacer eficiente un error de permiso para un intruso.

Lapágina de información del incidenteactual de Capital One establece que aproximadamente 100 millones de personas en Estados Unidos y aproximadamente seis millones en Canadá se vieron afectadas. La categoría de datos más grande fue la información proporcionada por consumidores y pequeñas empresas al solicitar productos de tarjetas de crédito desde 2005 hasta principios de 2019: nombres, direcciones, códigos postales, números de teléfono, direcciones de correo electrónico, fechas de nacimiento e ingresos auto reportados. Partes de los datos de clientes de crédito incluían puntuaciones, límites, saldos, historial de pagos, datos de contacto y fragmentos de datos de transacciones de 23 días entre 2016, 2017 y 2018. La empresa informó que aproximadamente 140,000 números de Seguro Social de EE. UU., aproximadamente 80,000 números de cuentas bancarias vinculadas y aproximadamente un millón de números de seguro social canadienses estaban entre los datos comprometidos. Dijo que los números de cuentas de tarjetas de crédito y las credenciales de inicio de sesión no se vieron comprometidos.

Esas distinciones evitan la exageración, pero no reducen la cuestión de control a un número. Los datos de la aplicación pueden seguir siendo sensibles a la identidad mucho después de una decisión crediticia. Los ingresos, el historial de direcciones, la fecha de nacimiento, el estado crediticio y los identificadores gubernamentales pueden combinarse entre sistemas. Por lo tanto, el evento no solo se trataba de si un bucket era privado.

Se trataba de por qué un rol orientado a la aplicación podía alcanzar el corpus almacenado, por qué una ruta de credenciales en un límite de metadatos local podía convertirse en una ruta de datos externa, por qué la supervisión no cerró la brecha y por qué los datos recopilados durante aproximadamente catorce años permanecieron dentro del conjunto alcanzable.

La cronología y la forma cambiante de la responsabilidad

Las fechas cambian lo que una organización puede esperar razonablemente saber y hacer. La cronología central se puede extraer de las divulgaciones de la empresa, la posterior acusación y condena, las órdenes regulatorias y los registros judiciales sin tratar cada fuente como el mismo tipo de prueba.

El aparente desajuste entre el 12 y el 22 de marzo no es una contradicción que deba forzarse en una sola fecha. Laacusación formal sustitutiva de 2021imputó un período más amplio de acceso no autorizado a computadoras comenzando alrededor del 12 de marzo. El anuncio de Capital One utilizó el 22 y 23 de marzo para el acceso a datos central en su relato del incidente. Una cronología debe preservar esa diferencia entre el curso de conducta imputado y la descripción de la empresa sobre la exfiltración.

La misma disciplina se aplica a los recuentos de población. El anuncio inicial de la empresa utilizó aproximadamente 100 millones de personas afectadas en Estados Unidos y seis millones en Canadá. El administrador del acuerdo de EE. UU. describió posteriormente aproximadamente 98 millones de consumidores estadounidenses en la clase del acuerdo. Ninguna de las cifras debe convertirse silenciosamente en un recuento universal preciso. Pertenecen a diferentes registros, en diferentes etapas, con diferentes definiciones.

Cómo el límite de metadatos se convirtió en un límite de credenciales

La cadena técnica comienza con server-side request forgery, a menudo abreviado como SSRF. En una condición SSRF, un llamador externo induce a un componente del lado del servidor a realizar una solicitud elegida o influenciada por ese llamador. La solicitud se realiza desde la posición de red del servidor, por lo que puede llegar a destinos no disponibles directamente desde Internet público. El problema de seguridad no es simplemente que se aceptó una URL. Es que la aplicación se convierte en un diputado que lleva la intención de un externo a un contexto de red más confiable.

Lapágina del caso de Capital Onedel Departamento de Justicia describe la intrusión como ocurrida a través de un firewall de aplicaciones web mal configurado. La acusación formal sustitutiva, presentada antes del juicio, alegó que Thompson creó y utilizó escáneres para identificar clientes de la nube cuyas configuraciones de firewall de aplicaciones web permitían que comandos externos llegaran y se ejecutaran en sus servidores. Alegó que esos comandos obtuvieron credenciales de seguridad para cuentas o roles de clientes; las credenciales se utilizaron luego para listar buckets de almacenamiento y copiar objetos para los cuales el rol tenía permiso. La acusación utilizó el término neutral "Cloud Computing Company", pero el registro civil público y las presentaciones de la propia Capital One identifican el entorno como AWS.

Un servicio de metadatos de instancia EC2 existe para que el software en una máquina virtual pueda aprender sobre su entorno de ejecución y obtener credenciales temporales asociadas con un rol de identidad adjunto. Esta es una alternativa útil a almacenar claves de acceso de larga duración en archivos. Sin embargo, el diseño asume que el acceso desde la instancia tiene significado. Si un componente orientado a la web puede ser inducido a emitir solicitudes internas arbitrarias, "local a la instancia" ya no es equivalente a "código de carga de trabajo autorizado".

Laexplicación de AWS de IMDSv2 en 2019identifica la dirección de metadatos como un endpoint link-local y explica que los metadatos pueden incluir credenciales temporales para un rol adjunto a la instancia. La versión 2 requiere que el software primero haga una solicitud HTTP PUT para establecer una sesión y recibir un token secreto, luego presente ese token en solicitudes de metadatos posteriores. AWS diseñó el protocolo para agregar resistencia contra firewalls de aplicaciones web abiertos comunes, proxies inversos abiertos, debilidades SSRF y ciertos errores de firewall de capa 3 o traducción de direcciones de red. Los clientes podían exigir la versión 2 o deshabilitar el acceso a metadatos por completo.

El punto analítico importante no es que una revisión del protocolo pruebe retroactivamente un defecto, ni que una configuración del cliente absuelva al diseñador de la plataforma de toda responsabilidad de diseño. Es que una suposición de confianza local puede fortalecerse en más de una capa. Capital One podía restringir el WAF, limitar la salida al endpoint de metadatos, reducir el rol, limitar el almacenamiento alcanzable, detectar uso inusual de la API y reducir los datos retenidos. AWS podía hacer que el protocolo de metadatos fuera menos reutilizable a través de proxies transparentes y rutas SSRF.

La defensa en profundidad reconoce que un error de aplicación no debe madurar automáticamente en una credencial de identidad y que una credencial de identidad no debe madurar automáticamente en una gran exportación de datos.

El firewall de aplicaciones web no fue toda la filtración

Llamar al incidente una mala configuración del firewall puede ocultar tres preguntas separadas. Primero, ¿por qué una solicitud no confiable pudo hacer que el firewall o un componente detrás de él alcanzara un destino interno? Segundo, ¿qué identidad se expuso cuando eso sucedió? Tercero, ¿qué podía hacer esa identidad?

La primera es una pregunta de aplicación y ruta de red. Un firewall de aplicaciones web generalmente se entiende como un control que filtra entradas hostiles antes de que lleguen a una aplicación. En este incidente, la configuración relevante lo convirtió en parte de la ruta hacia los recursos internos. Esa inversión debería cambiar la forma en que los equipos de nube prueban los controles perimetrales. Un WAF no es solo un conjunto de reglas en el perímetro público; es código con un contexto de ejecución, accesibilidad de salida, encabezados, métodos y una identidad adjunta.

La revisión de seguridad debe preguntar qué puede alcanzar e impersonar el control cuando está confundido.

La segunda pregunta se refiere a las credenciales de metadatos. Las credenciales temporales son más seguras que las claves de larga duración incrustadas en aspectos importantes: rotan, expiran y pueden asociarse centralmente con un rol. Pero "temporal" describe la duración, no el privilegio. Si un atacante puede recuperar repetidamente una credencial actual, o puede usar una credencial durante su ventana válida para copiar un gran conjunto de datos, la rotación no previene el daño. Por lo tanto, la higiene de credenciales debe incluir la ruta por la cual se emite la credencial y los permisos que conlleva.

La tercera pregunta es el menor privilegio. La acusación alegó que las cuentas obtenidas tenían el permiso necesario para listar y copiar el almacenamiento objetivo. Laorden de desestimación de septiembre de 2020del tribunal civil registra, como una alegación aceptada para esa etapa procesal, la descripción de Amazon de una mala configuración del firewall a nivel de aplicación agravada por permisos que probablemente eran más amplios de lo previsto. La orden también registra las alegaciones de los demandantes sobre el acceso al almacenamiento y un lago de datos. Esos pasajes no son hallazgos del juicio. Aun así son útiles porque la disposición del tribunal muestra que una intrusión criminal no necesariamente rompió la supuesta cadena causal entre las decisiones de seguridad y el daño al consumidor como cuestión de derecho.

Por lo tanto, una revisión efectiva evitaría concluir con "el WAF fue corregido". Reconstruiría el gráfico de privilegios completo: solicitud pública al proxy; proxy al endpoint de metadatos; endpoint de metadatos a sesión de rol; rol al listado de almacenamiento; listado de almacenamiento a lectura de objeto; lectura de objeto a ruta de descifrado; llamada API a salida de red. Cada borde necesita un propietario, una justificación comercial, controles preventivos y telemetría. Eliminar una regla defectuosa detiene la ruta conocida. No establece que la arquitectura de identidad y datos fuera proporcionada.

El cifrado protegió los medios, no el uso indebido autorizado

Capital One dijo que cifraba los datos como práctica estándar y tokenizaba campos seleccionados, especialmente los números de Seguro Social y de cuentas. También dijo que las circunstancias permitieron el descifrado de los datos accedidos, mientras que los datos tokenizados permanecieron protegidos porque la tokenización usaba un método y claves diferentes. Esta es una corrección importante a una afirmación común de que "los datos estaban cifrados" resuelve la cuestión de control.

El cifrado en reposo está diseñado principalmente para proteger los datos cuando los medios de almacenamiento, instantáneas o almacenamiento subyacente se acceden fuera de la ruta de servicio autorizada. Las aplicaciones aún necesitan leer datos. Los sistemas de almacenamiento y gestión de claves en la nube descifran información para identidades que cumplen con la política. Si el atacante adquiere una credencial con la misma autoridad de lectura que la carga de trabajo, el cifrado puede funcionar exactamente como está diseñado mientras libera texto plano a un humano no autorizado que utiliza una identidad de máquina autorizada.

Eso no es un argumento contra el cifrado. Es un argumento para separar autoridades. Un rol expuesto a un control orientado al público no debe conllevar permisos amplios de lectura de datos y uso de claves. Los campos altamente sensibles deben tokenizarse o cifrarse bajo un límite de servicio que la identidad general de lector de almacenamiento no pueda cruzar. Las políticas de claves, políticas de datos y políticas de roles deben revisarse como una sola decisión de autorización. De lo contrario, tres configuraciones individualmente plausibles pueden intersectarse para otorgar acceso que ninguno de sus propietarios pretendía.

El evento también muestra por qué los informes de control deben distinguir entre cobertura y consecuencia. "Cien por ciento de objetos cifrados" puede ser cierto mientras el riesgo de confidencialidad sigue siendo alto. Una métrica más útil para la junta mostraría qué proporción de objetos sensibles puede leer cada rol en tiempo de ejecución, qué identidades pueden invocar el descifrado, si una carga de trabajo orientada al público aparece en esas rutas y con qué frecuencia un rol lee fuera de su prefijo, volumen, región o patrón temporal normal.

La detección falló antes de que la respuesta tuviera éxito

El programa de divulgación responsable de Capital One funcionó una vez que una persona externa lo utilizó. La empresa dijo que recibió un informe el 17 de julio, confirmó la filtración el 19 de julio, corrigió el problema, contactó al FBI, anunció el incidente el 29 de julio y apoyó un arresto rápido. Esos son hechos de respuesta significativos. No responden por qué el sistema de control interno no llevó la actividad de marzo a resolución.

Los hallazgos de la OCC abordan esa brecha a un nivel superior. En laorden de consentimiento de multa civil, el Contralor encontró que Capital One no había establecido una gestión de riesgos de nube adecuada, incluidos controles adecuados de prevención de pérdida de datos y disposición efectiva de alertas. Capital One no admitió ni negó esos hallazgos. "Disposición" es más que generar una alerta. Es el proceso que determina si un evento es benigno, escalado, contenido o cerrado con evidencia.

Los entornos de nube generan abundante telemetría: asunción de roles, uso de metadatos, listado de almacenamiento, lecturas de objetos, direcciones fuente de API, volumen de salida, llamadas denegadas, cambios de política y eventos de clasificación de datos. Más señales no crean automáticamente detección. Un programa puede recopilar todos los eventos relevantes pero fallar si las reglas no correlacionan la secuencia, si los umbrales son insensibles al comportamiento normal de un rol, si las alertas carecen de un propietario responsable o si las razones de cierre no se revisan de forma independiente.

El hecho de que un informe externo llevara al descubrimiento debe registrarse tanto como un éxito de respuesta como un fracaso de aseguramiento. El éxito es que el canal existía, era monitoreado y permitía la acción. El fracaso es que una ruta de acceso de cuatro meses de antigüedad era descubrible a través de actividad pública antes de que los propios controles del banco produjeran una contención final. La divulgación responsable es un sensor externo valioso. No debe contarse como un sustituto de la detección interna de recuperación de credenciales, enumeración inusual de buckets y copia de grandes objetos.

La OCC trató la filtración como un fracaso de la gobernanza de migración

El registro de responsabilidad pública más sólido no es un análisis técnico posterior al incidente. Es el paquete de ejecución de la OCC de 2020. Elanuncio de la multade la agencia dice que el banco no estableció procesos efectivos de evaluación de riesgos antes de mover operaciones tecnológicas significativas a la nube pública y no corrigió las deficiencias de manera oportuna. La agencia impuso una multa de $80 millones, acreditó la notificación y remediación del banco y declaró que la innovación responsable aún requiere una gestión de riesgos sólida y controles internos.

Las conclusiones consentidas son inusualmente específicas. La OCC encontró que alrededor de 2015 el banco no estableció una evaluación de riesgos efectiva antes de la migración. Encontró deficiencias en el diseño e implementación de controles de seguridad de red, prevención de pérdida de datos y disposición de alertas. Encontró que la auditoría interna no identificó numerosas debilidades y brechas de control, no informó efectivamente las debilidades identificadas al Comité de Auditoría, y que la junta no tomó medidas efectivas para responsabilizar a la gerencia por ciertas preocupaciones planteadas por la auditoría.

Capital One aceptó la orden para evitar el costo de los procedimientos y expresamente no admitió ni negó los hallazgos.

Este marco cambia la unidad de responsabilidad. Si el evento fuera una mala regla de WAF creada en 2019, la remediación podría centrarse en el ingeniero, la revisión de cambios y el control inmediato. Si el fracaso relevante comenzó con un modelo operativo evaluado inadecuadamente en 2015, el sistema responsable incluye la gobernanza de migración, el diseño de control en la nube, el desafío de segunda línea, la auditoría interna, los informes de comités, la remediación gerencial y la escalada a la junta.

Laorden de cese y desistimientode la OCC acompañante hizo operativo ese perímetro más amplio. Exigió un comité de cumplimiento de al menos tres directores, planes de acción correctiva por escrito, mejoras en la evaluación de riesgos tecnológicos, gestión de riesgos de operaciones en la nube, gestión de riesgos independiente, pruebas de control y auditoría interna. El plan de nube debía abordar la seguridad perimetral, la identificación y protección de información sensible, la prevención y detección de divulgación no autorizada, y la gestión de configuración para objetos contenerizados. La gestión de riesgos independiente debía definir un universo integral de riesgos y controles y desafiar la evaluación de primera línea del riesgo cibernético inherente y residual.

Los requisitos de pruebas de control de la orden son especialmente importantes. Capital One debía desarrollar un inventario de controles de nube relevantes, conciliar un plan de pruebas basado en riesgos con ese inventario, rastrear brechas, remediarlas o aceptar formalmente el riesgo.

La auditoría interna debía validar la integridad y precisión del inventario de activos tecnológicos, dispositivos configurables y software de la gerencia; mapear su universo de auditoría a las preocupaciones del examen; incorporar lecciones del análisis de causa raíz de la filtración; revisar la cobertura de auditoría; evaluar la experiencia del personal; y mejorar la presentación de informes al Comité de Auditoría.

Estas obligaciones responden a un error recurrente de gobernanza de la nube. Una empresa puede tener un catálogo de controles y un plan de auditoría pero carecer de una relación confiable entre ellos. El catálogo de controles contiene lo que la gerencia cree que existe. El inventario de activos contiene lo que los equipos creen que operan. El universo de auditoría contiene lo que la auditoría espera revisar. Si esos conjuntos no están conciliados, un rol orientado al público, una ruta de metadatos, un bucket de almacenamiento o un motor de configuración pueden quedar entre modelos de propiedad.

La orden de la OCC exigía evidencia de que los conjuntos están alineados.

La responsabilidad de la junta es evidencia, no frecuencia de reuniones

Ladeclaración de poder de 2020de Capital One dice que la gerencia informó rápidamente el incidente a la junta después del descubrimiento el 19 de julio. Miembros independientes de varios comités y la junta completa se reunieron más de 20 veces con respecto al incidente y la respuesta. La junta contrató expertos externos, recibió informes sobre la causa raíz y la remediación, aumentó la supervisión y asignó al Comité de Riesgos el papel principal en la revisión de la gobernanza cibernética mejorada. La gerencia estableció un comité senior para problemas cibernéticos empresariales y escalada.

Esas son respuestas de gobernanza legítimas, pero el número de reuniones no puede probar que un control funcione. Los hallazgos de la OCC se centraron en el período anterior a la filtración, cuando supuestamente las debilidades de auditoría no se sacaron a la superficie de manera efectiva y la gerencia no fue responsabilizada por algunas brechas abiertas. Por lo tanto, la comparación útil no es "pocas reuniones antes, muchas reuniones después". Es si la información que llegaba a los directores cambió de informes de actividad a evidencia de control.

La orden de la OCC definió qué debería respaldar esa evidencia. Se requería que los directores aseguraran una acción correctiva oportuna, verificaran que las acciones fueran efectivas, aseguraran personal y sistemas suficientes, responsabilizaran a la gerencia, exigieran informes adecuados y oportunos y abordaran el incumplimiento. La junta podía confiar en la gerencia, los comités y terceros, pero la confianza no eliminaba el deber de asegurar la acción correctiva.

Para un riesgo de metadatos y almacenamiento en la nube, un paquete de calidad para la junta debería responder preguntas concretas. ¿Cuántas cargas de trabajo accesibles desde Internet pueden acceder a metadatos de instancia? ¿Cuántas requieren el protocolo de sesión más fuerte? ¿Cuáles pueden deshabilitar los metadatos por completo? ¿Cuántos roles orientados al público pueden listar o leer almacenes de objetos sensibles? ¿Cuál es el volumen máximo de datos que cada rol puede recuperar en una vida útil de credencial? ¿Qué controles impiden que los datos salgan de una red o región aprobada?

¿Cuántas alertas se cerraron sin evidencia corroborante? ¿Qué problemas de auditoría de nube han superado las fechas objetivo y qué ejecutivo aceptó el riesgo residual?

Ninguna de esas preguntas pide a los directores configurar un firewall. Preguntan si la gerencia puede demostrar el límite operativo que afirma. Esa es la distinción entre administración y supervisión. Los directores no necesitan conocer cada parámetro de API, pero necesitan un sistema de informes que haga visibles las combinaciones peligrosas antes de que un investigador externo lo haga.

La responsabilidad compartida es un mapa de control, no una exención de responsabilidad

AWS describe la seguridad en la nube como compartida entre el proveedor y el cliente. Bajo elmodelo de responsabilidad compartida de AWS, AWS protege la infraestructura que ejecuta los servicios en la nube, mientras que los deberes del cliente varían según la selección del servicio e incluyen comúnmente datos del cliente, identidad y acceso, software de aplicación, configuración del sistema operativo, configuración del firewall, opciones de cifrado y protección del tráfico. Para un servicio de infraestructura como EC2, el cliente controla sustancialmente más de la pila operativa de lo que lo haría en un servicio completamente gestionado.

El modelo es útil porque previene un error de categoría: alquilar computación no convierte al proveedor en el operador de los permisos de aplicación del cliente. Pero el diagrama es solo el comienzo de la gobernanza. Muchos controles importantes cruzan la línea. El proveedor diseña el servicio de metadatos; el cliente decide si y cómo usarlo. El proveedor proporciona la maquinaria de políticas de identidad; el cliente define roles y permisos. El proveedor produce registros; el cliente los habilita, retiene, enruta e investiga.

El proveedor ofrece opciones de región; el cliente selecciona regiones y arquitecturas que satisfagan obligaciones legales. El proveedor hace posibles configuraciones predeterminadas más seguras; el cliente debe migrar las cargas de trabajo existentes y hacerlas cumplir.

Ladeclaración de computación en la nube de la FFIEChace explícita la consecuencia para el sector financiero. La gerencia no debe asumir que existen controles de seguridad y resiliencia simplemente porque los sistemas operan en un entorno de nube. La declaración dice que los contratos deben identificar las responsabilidades de las partes, pero las instituciones financieras siguen siendo responsables de la operación segura y sólida y el cumplimiento. Destaca la gobernanza, la arquitectura de nube, la identidad, la gestión de datos, la gestión de vulnerabilidades, la supervisión, la respuesta a incidentes, la continuidad del negocio y la auditoría como prácticas conectadas.

Por lo tanto, la responsabilidad compartida debe traducirse en una matriz de control lo suficientemente precisa para ser probada. Para cada control, la matriz debe identificar quién lo diseña, quién lo configura, quién lo opera, quién recibe una alerta, quién valida la efectividad, qué evidencia se retiene y quién actúa cuando falta la evidencia. Una etiqueta como "responsabilidad del cliente" no es un propietario de control.

En un banco grande, "cliente" puede significar ingeniería de plataforma, equipos de aplicación, seguridad en la nube, gobernanza de datos, ingeniería de identidad, riesgo empresarial, auditoría interna, legal o un proveedor. La ambigüedad dentro de la organización del cliente puede ser más peligrosa que la ambigüedad entre el cliente y el proveedor.

Tampoco un diagrama de responsabilidad compartida decide la responsabilidad civil. Los términos del contrato, las representaciones, el diseño técnico, las obligaciones de notificación, la causalidad, la ley estatal y los hechos probados son importantes. El modelo puede guiar la operación esperada, pero no es una asignación judicial de culpa y no debe presentarse a una junta como si fuera una indemnización.

Responsabilidad penal, regulatoria y exposición civil

El registro público respalda varias formas de responsabilidad, cada una con un estatus legal diferente.

La responsabilidad penal es la más clara. Elanuncio de sentencia del Departamento de Justiciaestablece que un jurado federal encontró a Thompson culpable de fraude electrónico, cinco cargos de acceso no autorizado a una computadora protegida y daño a una computadora protegida. Los fiscales demostraron que escaneó cuentas de nube en busca de malas configuraciones, las usó para obtener datos y potencia informática, y accedió a más de 30 entidades. Fue sentenciada a tiempo cumplido y cinco años de libertad condicional. Esa conducta criminal adjudicada no debe suavizarse como un descubrimiento accidental.

La responsabilidad regulatoria se centró en el banco. La orden de multa de la OCC es una orden de consentimiento final, pero Capital One no admitió ni negó los hallazgos del Contralor. Elanuncio de ejecución coordinada de la Reserva Federaldijo que la sociedad holding debía mejorar la gestión de riesgos, la gobernanza, la ciberseguridad y los controles de seguridad de la información. Laorden de consentimiento de la Reserva Federaladjunta requería que la junta matriz usara sus recursos para asegurar que los bancos cumplieran con las órdenes de la OCC y presentara un plan escrito para la supervisión de la junta.

La exposición civil fue más amplia pero menos concluyente sobre la culpa final. Los consumidores demandaron a Capital One y Amazon bajo teorías de negligencia, contrato, enriquecimiento injusto, notificación y protección al consumidor. En septiembre de 2020, el tribunal de distrito concedió algunas partes de las mociones de desestimación de los demandados y denegó otras. La mayoría de las reclamaciones por negligencia sobrevivieron, mientras que las reclamaciones por negligencia de Washington y varias teorías de negligencia per se fueron desestimadas.

El tribunal concluyó en esa etapa que la conducta criminal de Thompson no necesariamente sustituía la supuesta negligencia de los demandados. Debido a que una moción de desestimación acepta las alegaciones bien formuladas como verdaderas, la decisión estableció que las reclamaciones podían continuar; no estableció que Capital One o Amazon hubieran cometido los actos alegados.

El caso terminó en un acuerdo en lugar de un juicio de fondo. Laorden de aprobación finalaprobó un fondo no reversionario de $190 millones, servicios de defensa y restauración de identidad y compromisos de prácticas comerciales. El acuerdo resolvió las reclamaciones contra Capital One y Amazon. La aprobación significó que el tribunal encontró la resolución negociada justa, razonable y adecuada según las reglas de acciones de clase. No asignó un porcentaje de responsabilidad por la filtración entre el banco, AWS y el atacante.

Esta distinción importa porque la frase "¿quién fue responsable?" puede invitar a una respuesta falsa. Thompson fue condenada por actos criminales. Capital One incurrió en sanciones regulatorias basadas en hallazgos consentidos y aceptó deberes correctivos. Capital One y Amazon enfrentaron reclamaciones civiles que sobrevivieron en parte y fueron resueltas. Los cambios de diseño posteriores del proveedor son relevantes para la prevención pero no son admisiones de culpa legal. Cada declaración tiene una fuente y una postura procesal. Combinarlas en un solo veredicto generalizado sería inexacto.

IMDSv2 y la gobernanza de configuraciones predeterminadas más seguras

AWS introdujo IMDSv2 en noviembre de 2019, menos de cuatro meses después de que Capital One revelara la filtración. Elaviso de lanzamiento de AWSlo describió como defensa en profundidad contra el acceso no autorizado a metadatos. Los clientes podían exigir el método de solicitud mejorado en instancias nuevas o en ejecución o desactivar el acceso a metadatos. La versión 1 permaneció disponible por compatibilidad.

El token de sesión de IMDSv2 crea fricción contra varias rutas de diputado confundido. Un proxy que reenvía solicitudes GET simples puede no permitir el PUT inicial. Un proxy inverso que inserta un encabezado de reenvío puede ser rechazado para la creación de tokens. Un token está vinculado a la instancia y no puede simplemente reproducirse desde una máquina arbitraria. Los límites de salto pueden restringir hasta dónde viaja una respuesta de metadatos a través de las capas de red. Estos son controles de protocolo valiosos porque reducen la consecuencia de errores de aplicación y proxy.

No eliminan la necesidad del menor privilegio. Si un código hostil se ejecuta realmente en una instancia, puede ser capaz de realizar el intercambio de tokens como lo haría un código legítimo. Si un SSRF vulnerable permite métodos y encabezados arbitrarios, la protección puede ser menos completa. Si el rol adjunto puede leer un lago de datos innecesario, la consecuencia residual sigue siendo alta. Por lo tanto, el endurecimiento de metadatos es una capa en una secuencia, no un reemplazo del diseño de roles, control de salida, segmentación de datos y supervisión.

Los valores predeterminados también tienen una dimensión temporal. En 2019, los clientes tenían que elegir y hacer cumplir el método más fuerte después de que estuviera disponible. AWS anunció posteriormente unahoja de ruta de IMDSv2 por defectoque movió los inicios rápidos de la consola y los tipos de instancia recién lanzados hacia la versión 2, mientras mantenía opciones de compatibilidad. Esa progresión ilustra un dilema de gobernanza de plataforma. Un cambio obligatorio inmediato puede romper software existente; la opcionalidad prolongada deja suposiciones antiguas en su lugar. Los proveedores deben hacer que la migración sea medible, proporcionar cumplimiento a nivel de cuenta, exponer el uso restante de la versión 1 y establecer una dirección clara. Los clientes deben tratar las actualizaciones de seguridad opcionales como decisiones de riesgo con propietarios y plazos, no como un backlog de funciones.

Para las juntas, la lección es preguntar sobre la deuda predeterminada. ¿Cuántas cargas de trabajo aún dependen de un modo de metadatos heredado? ¿Por qué? ¿Qué se rompería si se deshabilitara? ¿Qué aplicaciones no pueden tolerar un límite de salto más bajo? ¿Qué política organizacional impide nuevas excepciones? ¿Cómo sabe la empresa que una cuenta adquirida o un entorno de desarrollo no ha derivado? Una función segura que está disponible pero no medida produce menos aseguramiento que un programa de migración vinculado a inventario y cumplimiento.

La localidad de datos no contuvo el acceso lógico

La filtración afectó a personas a ambos lados de la frontera entre EE. UU. y Canadá. LaOficina del Comisionado de Privacidad de Canadáabrió una investigación después de que Capital One informara que seis millones de canadienses se vieron afectados, incluidos algunos cuyos números de seguro social habían sido accedidos. Lapágina de incidente canadiensede Capital One proporcionó avisos y soporte específicos por país. El impacto transfronterizo convierte la localidad de una pregunta abstracta de adquisición de nube en una pregunta de responsabilidad.

Las fuentes revisadas aquí no establecen la región exacta de AWS de cada objeto afectado, ni muestran que los registros canadienses se mantuvieran en una región canadiense separada. Esa ausencia debe preservarse. Sería irresponsable inferir una ubicación de almacenamiento a partir de la nacionalidad de un titular de datos o de una marca global de nube. Lo que el registro establece es que un incidente afectó a grandes poblaciones gobernadas por diferentes sistemas legales y regulatorios.

AWS dice en susmateriales de privacidad de datosque los clientes controlan el contenido del cliente y que los deberes del proveedor y del cliente siguen el modelo de responsabilidad compartida. Sumarco de soberanía digitalactual enfatiza la elección del cliente sobre dónde se ejecutan las cargas de trabajo, el acceso a los datos, la resiliencia y el control. Esas capacidades son relevantes, pero una selección de región no es un resultado completo de soberanía.

La localidad responde dónde está configurado un servicio para almacenar o procesar datos bajo operación normal. La seguridad también debe responder quién puede hacer que el servicio los divulgue, dónde se pueden ejercer las credenciales, a dónde van los registros y las copias de seguridad, cómo se controla el acceso de soporte y si los datos exportados pueden cruzar el límite seleccionado. En la cadena de Capital One, una credencial de API fue más consecuente que la proximidad física a un disco. Una vez que se aceptó un rol como autorizado, el almacenamiento podía entregar objetos a través de la interfaz del servicio.

Una región doméstica no habría prevenido, por sí sola, esa ruta lógica.

Por lo tanto, los controles de soberanía necesitan al menos cuatro capas. La primera es la ubicación: regiones aprobadas, configuraciones de replicación, copias de seguridad, análisis, recuperación ante desastres y servicios de soporte. La segunda es la autoridad: identidades, uso de claves, acceso a metadatos y políticas que restringen las llamadas por red, cuenta, organización o región. La tercera es la observabilidad: registros retenidos en una cuenta controlada de forma independiente, evidencia de transferencias entre regiones, alertas para ubicaciones fuente inusuales y registros disponibles para los reguladores relevantes.

La cuarta es la salida y continuidad: la capacidad de exportar datos y registros en forma utilizable, revocar el acceso del proveedor, rotar claves y operar un acuerdo de recuperación probado si una región, proveedor o mecanismo de transferencia legal deja de estar disponible.

El incidente también muestra que la geografía de los titulares de datos puede importar incluso cuando la geografía de la infraestructura es incierta. Los reguladores canadienses, las personas afectadas, las prácticas de notificación y las necesidades de remediación de identidad no desaparecieron porque Capital One tenga su sede en Estados Unidos. Un programa de nube multinacional debe mapear los conjuntos de datos a las personas y obligaciones que representan, no solo a la cuenta y región en que los ingenieros los ven.

La retención convirtió una ruta de acceso en un dossier histórico

Capital One dijo que la categoría afectada más grande incluía datos de aplicaciones desde 2005 hasta principios de 2019. Ese lapso cambia el análisis de riesgo. Una solicitud de crédito tiene un propósito inmediato: evaluar la elegibilidad, cumplir con la ley, prevenir el fraude y establecer una cuenta. Con el tiempo, parte de la información puede seguir siendo necesaria para el servicio, retenciones legales, deberes regulatorios, gobernanza de modelos, resolución de disputas o análisis de fraude. Pero la necesidad debe demostrarse por campo, propósito y período.

La retención a menudo se trata como un programa de privacidad separado de la seguridad en la nube. La filtración muestra por qué esa separación es artificial. La cantidad y antigüedad de los datos accesibles por un rol comprometido determinan el impacto. Un calendario de eliminación perfecto no puede evitar que un atacante lea registros actuales, pero puede evitar que un evento de credencial exponga catorce años de historial de aplicaciones. Del mismo modo, clasificar un campo como sensible tiene poco efecto si ninguna política de almacenamiento, límite de clave, rol de acceso o trabajo de eliminación cambia debido a la clasificación.

El control adecuado no es simplemente "eliminar datos antiguos". Es un ciclo de vida defendible: identificar el propósito de la recopilación; especificar la base legal y comercial para la retención; separar los datos operativos activos de los archivos restringidos; minimizar los campos; tokenizar los identificadores duraderos; hacer cumplir la eliminación; conservar solo los registros sujetos a una excepción documentada; y probar si los datos eliminados también abandonan réplicas, conjuntos de datos derivados, cachés, instantáneas y copias de desarrollo. Cada excepción debe tener un propietario y una revisión de vencimiento.

La arquitectura de datos también debe reducir la agregación. Un rol único no debería obtener acceso a un corpus histórico amplio simplemente porque un trabajo de procesamiento alguna vez lo necesitó. La partición por propósito, sensibilidad, período de tiempo y jurisdicción le da a la política de acceso algo significativo que hacer cumplir. Sin esos límites, el menor privilegio se ve obligado a operar al nivel de un bucket o lago de datos muy grande, y la diferencia entre "puede ejecutar esta aplicación" y "puede leer la historia de esta institución" se vuelve peligrosamente pequeña.

La dependencia de la nube incluye la dependencia de la evidencia

Capital One no solo estaba alquilando discos remotos. Como cualquier gran cliente de la nube, dependía de la semántica de identidad definida por el proveedor, el comportamiento de metadatos, el registro de API, las construcciones de región, los controles de almacenamiento, la disponibilidad del servicio, la documentación y la capacidad del proveedor para preservar y explicar la evidencia. Esa es una dependencia más amplia que el tiempo de actividad.

El incidente de 2019 no causó una interrupción pública prolongada de los servicios bancarios principales de Capital One. El problema de continuidad fue la confidencialidad y la confianza. La empresa tuvo que investigar un gran entorno de nube, identificar registros afectados, notificar a personas en dos países, trabajar con las autoridades y reguladores, proporcionar monitoreo, defenderse de litigios y remediar controles mientras continuaba operando.

Esto es continuidad bajo evidencia comprometida: los servicios pueden permanecer disponibles mientras la institución debe determinar si sus registros, procesos de identidad y comunicaciones con los clientes aún pueden ser confiables.

ElFormulario 10-K de 2019de Capital One informó $72 millones de gastos incrementales de respuesta y remediación en 2019, compensados por $34 millones de recuperaciones de seguros. La empresa esperaba estar en el extremo inferior de su rango previamente anunciado de $100 millones a $150 millones para elementos de ajuste total del incidente, con algunos costos extendiéndose más allá de 2019. Advirtió sobre intervención regulatoria, litigios, costos de remediación, daño reputacional y pérdida de confianza. Esas cifras precedieron a la multa de $80 millones de la OCC y al posterior fondo de liquidación colectiva de $190 millones, y no deben sumarse casualmente porque el seguro, el momento, el alcance de la liquidación y el tratamiento contable difieren.

La dependencia de la evidencia debe planificarse contractual y técnicamente. Un cliente regulado necesita registros con campos y retención adecuados, notificación oportuna de eventos del proveedor, cooperación con la recolección forense, deberes de preservación, información sobre la región y los subprocesadores, acceso a informes de control, comunicación de vulnerabilidades y un proceso para solicitudes gubernamentales y regulatorias. También necesita su propia copia de los registros críticos en una cuenta de seguridad que la carga de trabajo comprometida no pueda alterar.

Un tablero del proveedor que dice que el servicio operó normalmente no establece que las identidades de los clientes estuvieran correctamente delimitadas.

La planificación de salida pertenece al mismo paquete. Concentrar datos y políticas de identidad en un solo proveedor puede mejorar la estandarización y la visibilidad, pero también puede dificultar la migración. Una prueba de salida debe medir cuánto tiempo lleva inventariar datos, reproducir la política de acceso, exportar claves o volver a cifrar, transferir registros, reconstruir la detección, satisfacer las restricciones de localidad y demostrar la eliminación en el proveedor anterior. La implementación multinube no es automáticamente más segura; duplicar controles inmaduros puede duplicar la incertidumbre.

El objetivo es la portabilidad creíble de datos y evidencia, no un recuento decorativo de proveedores.

Lo que los acuerdos resolvieron y lo que dejaron abierto

El acuerdo colectivo de consumidores es sustancial, pero su significado debe establecerse cuidadosamente. El acuerdo creó un fondo de $190 millones para pérdidas de bolsillo elegibles, tiempo perdido, servicios de defensa de identidad, servicios de restauración, notificación y administración, y honorarios aprobados por el tribunal. También incluyó compromisos de prácticas comerciales. La orden de aprobación final consideró el acuerdo justo, razonable y adecuado y desestimó con perjuicio las reclamaciones de consumidores liberadas.

El acuerdo no estableció que cada alegación en la demanda enmendada fuera cierta. No convirtió los antecedentes de la moción de desestimación en hallazgos después de la evidencia. No determinó que el diseño de metadatos de AWS causara un porcentaje específico del daño o que la configuración de Capital One causara el resto. No borró la responsabilidad criminal de Thompson y no desplazó los hallazgos y órdenes regulatorias separadas de la OCC.

Esta asignación no resuelta es en sí misma una lección de gobernanza. Las empresas no pueden esperar a que un tribunal asigne un porcentaje ordenado antes de mejorar un control compartido. Un proveedor de plataforma puede no tener responsabilidad adjudicada y aun así agregar un protocolo más seguro. Un cliente puede disputar los hallazgos del regulador y aun así aceptar una orden y revisar los controles. Una junta puede reservar defensas legales mientras trata los hechos operativos como urgentes. La postura legal y la postura de remediación pueden diferir sin contradicción.

La OCC anunció posteriormente quedio por terminada la orden de cese y desistimiento de 2020efectiva el 31 de agosto de 2022. La terminación es un punto final importante para esa orden en particular. No cancela la multa, reescribe los hallazgos históricos ni prueba que el riesgo de la nube se haya vuelto estático. Indica que la orden formal ya no estaba pendiente. Una junta madura debe convertir el inventario de control, las pruebas, la auditoría y las disciplinas de informes de la orden en gobernanza normal en lugar de dejar que expiren con la supervisión regulatoria.

Un paquete de evidencia para riesgos de metadatos, identidad y localidad

El registro de Capital One respalda un paquete de evidencia práctico para organizaciones que ejecutan cargas de trabajo sensibles en la nube pública.

Mapa de rutas públicas a autoridad interna.Inventaríe cada proxy, balanceador de carga, WAF, puerta de enlace de API y aplicación accesible desde Internet. Para cada uno, muestre los destinos de salida, la accesibilidad de metadatos, las identidades adjuntas, los métodos y encabezados permitidos, y la máxima autoridad de datos alcanzable a través de esa identidad. Pruebe la ruta desde la perspectiva de un atacante, no solo contra el diagrama de arquitectura previsto.

Haga medible la postura de metadatos.Registre si se necesitan metadatos, si se pueden deshabilitar, qué versión del protocolo se requiere, el límite de salto, las restricciones del firewall local, las implicaciones de los contenedores y las llamadas heredadas observadas. Haga cumplir el estado preferido a nivel de organización o cuenta. Las excepciones deben identificar el software dependiente, el propietario del riesgo, los controles compensatorios y la fecha de eliminación.

Calcule el radio de explosión de credenciales.Para cada rol en tiempo de ejecución, enumere los prefijos de almacenamiento, bases de datos, colas, secretos, operaciones de claves y acciones administrativas a las que puede acceder. Estime cuántos datos sensibles podrían leerse dentro de una vida útil de credencial y desde qué ubicaciones de red. Pruebe los permisos efectivos, incluyendo la intersección de políticas de identidad, recurso, clave, endpoint y organización.

Separe el acceso al almacenamiento de la autoridad de descifrado.El cifrado no debe colapsar en el mismo rol que se expone a través de la ruta de la aplicación. Utilice tokenización o un servicio distinto para campos de identidad duraderos. Alerte cuando una identidad orientada al público invoque operaciones de clave o lea una clase de datos fuera de su propósito limitado.

Controle los datos por propósito y jurisdicción.Etiquete y divida los datos según la sensibilidad, el propósito, el período de retención y la población afectada. Haga cumplir las regiones aprobadas para el almacenamiento principal, réplicas, análisis, copias de seguridad y recuperación. Registre cualquier servicio que mueva necesariamente contenido o datos de soporte. Pruebe la denegación entre regiones y cuentas, no solo la ubicación configurada.

Sea dueño del rastro de auditoría.Enrute los eventos de identidad, metadatos, almacenamiento, clave, red y pérdida de datos a un entorno de registro administrado de forma independiente. Proteja los registros de los roles de carga de trabajo. Correlacione la recuperación de credenciales, las operaciones de listado, las lecturas de objetos, el descifrado y la salida. Mida si las alertas se investigan hasta una conclusión basada en evidencia, no solo si se generan.

Concilie el universo de control.El catálogo de control en la nube de la gerencia, el inventario de activos, el inventario de configuración, el catálogo de datos, el registro de riesgos y el universo de auditoría deben tener identificadores comunes. La auditoría interna debe probar la integridad en lugar de muestrear solo de la lista de la gerencia. Los activos y controles no coincidentes deben informarse como cobertura desconocida.

Escale hallazgos repetidos y vencidos.Una brecha de configuración con una fecha de remediación incumplida debe aparecer junto con las rutas de identidad y datos que deja expuestas. Los informes a la junta deben nombrar al ejecutivo responsable, los controles compensatorios, el método de validación y la fecha límite. El cierre debe requerir evidencia independiente de que la condición de riesgo cambió.

Realice ejercicios de respuesta transfronteriza.Un simulacro de filtración debe identificar qué poblaciones y reguladores están implicados, qué registros muestran ubicación y acceso, cómo se entregarán los avisos específicos por país y cómo funciona la restauración de identidad para diferentes identificadores gubernamentales y sistemas de crédito. La organización debe poder explicar dónde se mantenían los datos afectados sin reconstruir la respuesta durante la crisis.

Preserve la cooperación del proveedor y los derechos de salida.Los contratos y procedimientos operativos deben asegurar acceso oportuno a registros, apoyo forense, aviso de incidentes, preservación de evidencia, compromisos de región, transparencia de subprocesadores y certificación de eliminación. Los equipos deben probar periódicamente la exportación de datos, políticas, claves y evidencia de auditoría a un entorno de recuperación utilizable.

Este paquete es exigente porque el riesgo es combinatorio. El WAF puede cumplir con su línea base. El servicio de metadatos puede operar como está documentado. El rol puede tener una razón de negocio. El bucket puede ser privado. Los objetos pueden estar cifrados. Los registros pueden existir. Sin embargo, la intersección aún puede permitir que una solicitud pública se convierta en una exportación autorizada. La responsabilidad pertenece a las intersecciones.

La prueba duradera

La filtración de Capital One sigue siendo un caso útil de responsabilidad en la nube porque resiste dos historias fáciles. La primera dice que la nube pública causó la filtración. Eso ignora la configuración controlada por el cliente, los permisos, la arquitectura de datos, la supervisión y los hallazgos directos de la OCC sobre el programa de riesgo en la nube del banco. La segunda dice que la responsabilidad compartida puso el asunto completamente en el cliente.

Eso trata un diagrama del proveedor como el fin del análisis de diseño y pasa por alto el valor de defensas más fuertes del servicio de metadatos, configuraciones predeterminadas más seguras, telemetría del proveedor y evidencia contractual.

El mejor relato sigue la cadena. Un control orientado al público podía retransmitir una solicitud no intencionada. La solicitud alcanzó un límite de confianza de metadatos. La identidad temporal resultante tenía suficiente autoridad para listar y copiar información almacenada. El cifrado no impidió que una credencial aceptada como autorizada leyera datos. La supervisión interna no produjo contención oportuna. Un horizonte de retención prolongado agrandó el corpus expuesto. El mismo evento alcanzó a personas bajo regímenes de privacidad de EE. UU. y Canadá.

La auditoría y los informes a la junta no habían forzado la resolución de las brechas de control en la nube más amplias identificadas por el regulador.

La responsabilidad luego se separó por foro. El atacante fue condenado. Los reguladores bancarios impusieron obligaciones consentidas y una multa a Capital One. Los consumidores persiguieron tanto a Capital One como a Amazon; las reclamaciones sobrevivieron en parte y se resolvieron sin una asignación de culpa en el juicio. AWS introdujo un protocolo de metadatos más defensivo. Capital One describió remediación, supervisión mejorada de la junta y asumió costos sustanciales de respuesta, ejecución y liquidación.

Para las juntas futuras, la pregunta decisiva no es si el proveedor de nube está certificado, el bucket está cifrado o la regla del firewall ha sido corregida. Es si la institución puede probar que ninguna ruta no confiable puede obtener una identidad de carga de trabajo con autoridad desproporcionada; que el uso inusual de esa identidad será detectado y resuelto; que los datos alcanzables están limitados por propósito, tiempo y jurisdicción; y que la evidencia del proveedor y del cliente puede unirse lo suficientemente rápido para gobernar el riesgo.

Esa prueba es el significado práctico de la responsabilidad compartida. Sin ella, la responsabilidad simplemente se divide en papel mientras el riesgo permanece conectado en producción.