Marriott hizo de la base de datos de reservas de Starwood un límite de confianza con terceros

Resumen

• El entorno de reservas de Starwood se vio comprometido a finales de julio de 2014, más de dos años antes de que Marriott completara su adquisición de Starwood el 23 de septiembre de 2016. La presentación de la adquisición de Marriott está disponible enhttps://www.sec.gov/Archives/edgar/data/1048286/000119312516718014/d241360d8k.htm, y el aviso final de la sanción de la ICO del Reino Unido se encuentra enhttps://ico.org.uk/media2/migrated/2618524/marriott-international-inc-mpn-20201030.pdf.
• El problema central de responsabilidad no es si Marriott podría haber conocido todos los hechos ocultos antes del cierre, sino con qué rapidez la autoridad posterior al cierre se convirtió en un control verificado sobre la base de datos de reservas heredada, las credenciales privilegiadas, la supervisión de la base de datos, el inventario criptográfico, los límites de los proveedores de servicios y la eliminación de datos.
• Los reguladores tomaron posteriormente caminos diferentes: la ICO impuso una multa de 18,4 millones de libras por fallos de seguridad durante el período del RGPD, los estados de EE. UU. llegaron a un acuerdo de 52 millones de dólares y la FTC impuso una orden de 20 años. Marriott no admitió responsabilidad en el acuerdo estatal y no apeló la sanción de la ICO.
• El registro respalda la existencia de un riesgo operativo heredado, un descubrimiento tardío, una supervisión incompleta, una protección desigual de los pasaportes, descripciones criptográficas cambiantes y medidas correctivas exigibles. No respalda una cifra precisa de personas únicas afectadas, una identificación pública del atacante ni pruebas de que todos los huéspedes afectados sufrieran un fraude consumado.

La adquisición no es una atestación de seguridad

Adquirir una empresa suele describirse en términos comerciales: marcas, habitaciones, miembros de fidelización, mercados y valor de la transacción. La brecha de Starwood muestra por qué un sistema de datos activo también es un límite de confianza con terceros. Antes del cierre, el comprador puede recibir declaraciones, materiales de debida diligencia, informes de cumplimiento, resúmenes de arquitectura y divulgaciones de brechas. Después del cierre, el comprador hereda la autoridad operativa. La realidad de la seguridad puede quedar rezagada en ambos casos.

Marriott acordó adquirir Starwood en noviembre de 2015 y completó la adquisición el 23 de septiembre de 2016. Starwood se convirtió en una subsidiaria indirecta de su total propiedad. La transacción creó la empresa hotelera más grande del mundo por habitaciones y marcas, con una huella global de reservas descrita en los materiales de adquisición enhttps://www.sec.gov/Archives/edgar/data/1048286/000119312516718014/d241360dex991.htm. Sin embargo, la realidad de seguridad de la base de datos de reservas no era la misma que su valor comercial. Según la ICO, la intrusión posteriormente relacionada con la brecha de reservas comenzó a finales de julio de 2014.

Esa cronología es importante porque Marriott no era propietario de Starwood cuando el atacante entró por primera vez. También importa porque Marriott sí era propietario de la empresa mientras el sistema de reservas comprometido seguía funcionando después del cierre. El entonces director ejecutivo de Marriott declaró ante un subcomité del Senado de Estados Unidos en 2019 que la revisión tecnológica previa al cierre era limitada porque Marriott y Starwood seguían siendo competidores, que Marriott decidió retirar la plataforma de reservas de Starwood y que trasladar 1270 hoteles llevó dos años. El testimonio está disponible enhttps://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Soresnson%20Testimony.pdf. Esas limitaciones son reales. No eliminan la obligación posterior al cierre de verificar el entorno que continuaba procesando datos de los huéspedes.

La distinción es el límite de confianza. Antes de la adquisición, Starwood era un tercero. Después de la adquisición, el sistema de Starwood se convirtió en el sistema operativo heredado de Marriott, incluso si técnicamente estaba separado de la red más amplia de Marriott. La ICO determinó que las redes de Starwood y del resto de Marriott permanecieron segregadas y que el atacante no accedió a los datos procesados únicamente en sistemas que no eran de Starwood. La segregación redujo el alcance del daño. También significó que el sistema heredado podía seguir siendo un lugar separado donde un intruso persistía.

La pregunta de responsabilidad posterior al cierre es, por tanto, basada en pruebas: qué cuentas privilegiadas se revalidaron, qué credenciales de proveedores de servicios se rotaron, qué tablas de la base de datos se supervisaron, qué exportaciones se registraron, qué afirmaciones criptográficas se probaron, qué campos de datos se mapearon, qué copias se retiraron y con qué rapidez la realidad del sistema heredado reemplazó la documentación del vendedor.

La historia oculta chocó con un historial de seguridad conocido

La brecha de reservas de Starwood no debe fusionarse con la brecha anterior de los sistemas de punto de venta de Starwood, pero la brecha anterior pertenece al contexto del riesgo de adquisición. El informe anual de 2015 de Starwood enhttps://www.sec.gov/Archives/edgar/data/316206/000156459016013371/hot-10k_20151231.htmreveló la presencia de malware que afectaba a los sistemas de punto de venta en algunos hoteles y afirmó en ese momento que no había indicios de que los sistemas de reservas o de fidelización se hubieran visto afectados en ese incidente. Esa declaración no reveló al intruso oculto en las reservas. Sí demostró que Starwood había tenido problemas de seguridad recientes que requerían el escrutinio del comprador.

La demanda de 2024 de la Comisión Federal de Comercio (FTC) enhttps://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottcomplaint_0.pdfalegó posteriormente fallos más amplios en varias brechas, incluidas debilidades relacionadas con Starwood y Marriott. La demanda se resolvió por consentimiento y no debe considerarse una conclusión judicial. Su valor aquí es mostrar el tipo de temas de control que los reguladores enfatizaron posteriormente: segmentación, controles de acceso, aplicación de parches, autenticación multifactor, supervisión, protección criptográfica, retención de datos y evaluación de entidades adquiridas.

La orden final de la FTC enhttps://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottfinalorder.pdfconvirtió esos temas en obligaciones a largo plazo. Requiere un programa de seguridad, elementos de un programa de privacidad, evaluaciones relacionadas con adquisiciones, análisis de riesgos, controles de acceso, supervisión, pruebas, controles de eliminación y retención, informes a la junta directiva, certificación y evaluación independiente. La orden no prueba todas las alegaciones de la demanda. Muestra lo que los reguladores consideraron un control prospectivo necesario tras el riesgo de brechas heredadas y repetidas.

Para los equipos de transacciones, la lección es práctica. La divulgación de una brecha anterior por parte del vendedor no es un certificado de buena salud para los sistemas adyacentes. Un informe de cumplimiento puede cubrir un entorno y pasar por alto otro. Una declaración de que no se indicó que los sistemas de reservas se vieran afectados en un incidente de punto de venta no prueba que estuvieran limpios de una intrusión separada. El comprador necesita un plan de búsqueda de amenazas y verificación de controles posterior al cierre para los sistemas heredados de alto valor, especialmente cuando la migración llevará años.

La línea temporal: el control empresarial, la detección técnica y la notificación a los huéspedes son relojes diferentes

Al menos cinco fechas anclan el registro. Finales de julio de 2014 marca la entrada del intruso en el entorno de Starwood. El 23 de septiembre de 2016 marca el cierre de la adquisición por parte de Marriott. El 25 de mayo de 2018 marca la aplicabilidad del RGPD para el análisis jurídico de la ICO. El 7 y 8 de septiembre de 2018 marcan la alerta de la base de datos y la escalada a Marriott. El 19 de noviembre de 2018 marca la fecha en que Marriott afirmó que los investigadores descifraron archivos y confirmaron que estaba involucrada información personal de la base de datos de reservas de Starwood.

El aviso de sanción de la ICO reconstruye la entrada a finales de julio de 2014 a través de una shell web en un dispositivo que ejecutaba una aplicación para empleados de Starwood. El atacante utilizó herramientas de acceso remoto, recopiló credenciales, se movió por el entorno y finalmente exportó tablas de la base de datos. El registro público no proporciona una lista completa de equipos, una lista completa de archivos o la vulnerabilidad inicial exacta. Sí establece una presencia no autorizada prolongada antes y después de la adquisición.

El 7 de septiembre de 2018, IBM Guardium generó una alerta después de que una cuenta de administrador consultara el recuento de filas de una tabla protegida de perfiles de huéspedes. Accenture, que gestionaba la base de datos de reservas de huéspedes de Starwood, escaló el incidente a Marriott el 8 de septiembre. Marriott supo que la persona cuyas credenciales se habían utilizado no había realizado la consulta. Ese evento fue la detección de una actividad sospechosa, no el conocimiento inmediato de todos los archivos exportados. Inició el camino de descubrimiento final.

Los días siguientes muestran por qué la alerta, la contención y el alcance son procesos separados. Marriott activó la respuesta a incidentes y contrató a investigadores externos. El 10 de septiembre, según la ICO, otra tabla relacionada con pasaportes se exportó a un archivo de volcado. El 17 de septiembre, los investigadores identificaron un troyano de acceso remoto y bloquearon la actividad de comando y control. En octubre, los investigadores identificaron pruebas que retrotraían el historial de intrusión a 2014. El 13 de noviembre, encontraron rastros de archivos cifrados y eliminados.

El 19 de noviembre, descifraron archivos y confirmaron que contenían información personal de la base de datos de reservas.

Marriott notificó a la ICO el 22 de noviembre y lo divulgó públicamente el 30 de noviembre. El aviso de la empresa enhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-announces-starwood-guest-reservation-database-securityindicaba que la base de datos se encontraba en Estados Unidos y proporcionaba las primeras categorías de campos y estimaciones de la población afectada. Una copia estable de la SEC de la divulgación inicial se encuentra enhttps://www.sec.gov/Archives/edgar/data/1048286/000162828018014745/a2018118k.htm.

La ICO no emitió posteriormente una conclusión definitiva en virtud de los Artículos 33 o 34 contra Marriott, tras considerar el cronograma de investigación y las declaraciones. Ese es un límite legal. No borra la realidad operativa de que la notificación a los clientes dependía de la capacidad de la organización para descubrir, descifrar y clasificar los archivos exportados meses después de la primera alerta.

Los recuentos y los campos deben mantenerse acotados

El primer aviso de Marriott utilizó un límite superior de hasta aproximadamente 500 millones de huéspedes, con un subconjunto de aproximadamente 327 millones de registros que contenían combinaciones más amplias de campos. Su actualización de enero de 2019 enhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-provides-update-starwood-database-security-incidentredujo el límite superior a aproximadamente 383 millones de registros y advirtió que los duplicados significaban menos huéspedes únicos. La ICO utilizó posteriormente 339 millones de registros de huéspedes a nivel mundial, incluidos 30,1 millones asociados a países del EEE y 7 millones asociados al Reino Unido. El acuerdo multiestatal de 2024 utilizó 131,5 millones de registros de huéspedes asociados a Estados Unidos.

Estas cifras no deben sumarse. Los registros no son personas únicas. Los subconjuntos regionales no son adiciones globales. Las poblaciones de litigios y las poblaciones de reguladores sirven a diferentes propósitos procesales. El informe anual de 2018 de Marriott enhttps://www.sec.gov/Archives/edgar/data/1048286/000162828019002337/mar-q42018x10k.htmactualizó las estimaciones para las categorías de pasaportes y tarjetas de pago y registró los costes del incidente y las recuperaciones del seguro, pero no convirtió cada registro en la misma exposición de datos.

Las combinaciones de campos también variaron. El aviso inicial enumeraba nombres, direcciones postales, números de teléfono, direcciones de correo electrónico, números de pasaporte, información de Starwood Preferred Guest, fechas de nacimiento, sexo, información de llegada y salida, fechas de reserva, preferencias de comunicación y algunos datos de tarjetas de pago. La ICO describió detalles a nivel de tabla, como indicadores VIP, datos de habitaciones y estancias, detalles de vuelos, país y número de pasaporte, estado de facturación y recuentos de adultos o niños en las habitaciones. Algunos campos facilitan el fraude.

Otros ayudan al contacto dirigido. Algunos revelan patrones de viaje o contexto familiar incluso sin credenciales financieras.

La protección de pagos y pasaportes también cambió en la descripción pública. Marriott describió primero algunos números de tarjetas de pago y algunos números de pasaporte como protegidos con cifrado AES-128. En abril de 2024, Marriott actualizó sus páginas del incidente para indicar que los números de tarjeta de pago relevantes y algunos números de pasaporte se habían protegido, en cambio, con SHA-1. La página para consumidores de la FTC enhttps://consumer.ftc.gov/consumer-alerts/2018/12/marriott-data-breachseñaló posteriormente la distinción. La página de funciones hash del NIST enhttps://csrc.nist.gov/Projects/hash-functionsy el aviso de transición de SHA-1 enhttps://www.nist.gov/news-events/news/2022/12/nist-transitioning-away-sha-1-all-applicationsexplican por qué SHA-1 es una función hash y por qué la protección moderna no debería tratarlo como un cifrado ordinario.

La corrección de 2024 no prueba que todos los valores protegidos fueran revertidos o utilizados indebidamente. Sí demuestra un fallo en el inventario criptográfico. Un responsable del tratamiento que maneja datos globales de reservas y pasaportes debería saber qué campos están en texto plano, cifrados, hash, tokenizados o transformados de otra manera; qué algoritmo se aplica; dónde se almacenan las claves o secretos; y cómo se verifican esos hechos antes de la notificación pública. Una corrección de cinco años de cifrado a hash cambia la forma en que las personas afectadas y los reguladores interpretan el riesgo.

Lo que la ICO encontró y lo que no encontró

El aviso final de sanción de la ICO es el registro administrativo público más sólido sobre la brecha de reservas de Starwood. Su alcance era más limitado que la historia completa de 2014-2018. Abordaba el tratamiento de datos por parte de Marriott desde el 25 de mayo de 2018, cuando el RGPD entró en vigor, hasta el 17 de septiembre de 2018, cuando se identificó y contuvo el troyano de acceso remoto. No impuso responsabilidad en virtud del RGPD por el período anterior al RGPD ni decidió que la diligencia previa al cierre de Marriott hubiera sido legalmente inadecuada.

El texto del RGPD enhttps://eur-lex.europa.eu/eli/reg/2016/679/ojexige a los responsables del tratamiento que implementen medidas técnicas y organizativas apropiadas, cuya idoneidad se juzga en función del riesgo, el estado de la técnica, el coste, el contexto y los derechos de las personas. La ICO constató infracciones de los principios de seguridad y del Artículo 32. Sus cuatro conclusiones principales en materia de seguridad se referían a la supervisión insuficiente de las cuentas privilegiadas, la supervisión insuficiente de la base de datos, el control inadecuado de los sistemas críticos y la falta de cifrado de todos los números de pasaporte.

La conclusión sobre las cuentas privilegiadas es importante porque el atacante utilizó credenciales legítimas. Una base de datos o una sesión remota pueden parecer autorizadas si la supervisión se limita a la validez de las credenciales. La conclusión sobre la supervisión de la base de datos es importante porque la alerta que finalmente resultó determinante estaba vinculada a una tabla con relevancia para las tarjetas de pago, mientras que otros datos personales carecían de un sistema de alerta equivalente.

La conclusión sobre el control de sistemas críticos es importante porque los sistemas capaces de acceder a grandes repositorios de datos personales deberían contar con controles de hardening y ejecución. La conclusión sobre los pasaportes es importante porque millones de números de pasaporte no estaban cifrados y ninguna evaluación de riesgos documentada justificaba la protección desigual.

La ICO también eliminó o no finalizó varias cuestiones que a menudo se difuminan en los relatos públicos. Eliminó el punto sobre la autenticación multifactor incompleta de la sanción final tras considerar la dependencia de Marriott de las garantías y los informes de cumplimiento de tarjetas de pago. No emitió una conclusión definitiva sobre la notificación de brechas en virtud del Artículo 33 ni una conclusión definitiva sobre la notificación individual en virtud del Artículo 34. Reconoció que la diligencia profunda previa al cierre puede verse limitada en una adquisición entre competidores. Estos límites no hacen que la brecha sea pequeña.

Hacen que el registro legal sea preciso.

Marriott respondió a la decisión final de la ICO enhttps://marriott.gcs-web.com/news-releases/news-release-details/marriott-international-update-conclusion-uk-ico-investigation, declarando que no apelaría y sin admitir responsabilidad alguna. La postura de no admisión es procesal. Coexiste con las conclusiones administrativas definitivas de la ICO.

Confianza en los proveedores de servicios y la plataforma

La base de datos de reservas de Starwood no era una única aplicación interna propiedad de un solo equipo y gestionada por él. Accenture administraba la base de datos de reservas de huéspedes de Starwood, Guardium generó la alerta clave, las operaciones hoteleras alimentaban los registros de reservas, los procesos de fidelización y del centro de contacto dependían de la plataforma, y Marriott tenía que mantener la continuidad del negocio mientras migraba los hoteles. Eso convierte al sistema en un límite de confianza de plataforma, no simplemente en una base de datos.

La gestión por parte de terceros cambia la cuestión de la evidencia. Un responsable del tratamiento puede externalizar la operación, pero aún necesita pruebas de registro, escalado, revisión de accesos privilegiados, control de cambios, supervisión de exportaciones, retención y respuesta a incidentes. Un proveedor de servicios gestionados puede ver una alerta antes que el responsable del tratamiento. El responsable del tratamiento aún necesita suficiente contexto para decidir si los datos de los huéspedes están en riesgo y si han comenzado las obligaciones de notificación.

La secuencia de septiembre de 2018 muestra que una cadena de alertas puede funcionar y aun así dejar el alcance sin resolver durante semanas.

El acuerdo estatal anunciado por Connecticut enhttps://portal.ct.gov/ag/press-releases/2024-press-releases/multistate-settlement-with-marriott-for-data-breach-of-starwood-guest-reservation-databasey la sentencia registrada en Vermont enhttps://ago.vermont.gov/sites/ago/files/documents/2024.10.09%20Marriott%20Judgment%20VT%20and%20Appendix%20final.pdfmuestran cómo las autoridades estatales de EE. UU. trasladaron esa lección a requisitos. El acuerdo incluía controles de seguridad a largo plazo, evaluación de entidades adquiridas, obligaciones relacionadas con franquiciados y proveedores de servicios, asistencia al consumidor y un pago. También incluía la no admisión de responsabilidad. Las medidas cautelares son importantes porque tratan la adquisición y los límites con terceros como obligaciones de control continuas en lugar de problemas puntuales en el cierre.

La orden final de la FTC añade otra capa de límite de confianza. Cubre no solo el incidente de las reservas de Starwood, sino un conjunto más amplio de alegaciones de seguridad de Marriott y Starwood. Sus disposiciones sobre adquisiciones son centrales aquí: un comprador debe evaluar y abordar los riesgos de las empresas adquiridas e integrarlas en un programa de seguridad. Ese es exactamente el problema que reveló la base de datos de Starwood. El sistema puede estar segregado, programado para su retirada y ser comercialmente necesario. Sigue conteniendo datos de los huéspedes bajo el control del comprador.

La localidad de los datos era solo un hecho

El aviso inicial de Marriott decía que la base de datos de reservas de huéspedes de Starwood se encontraba en Estados Unidos. Era un dato útil sobre el almacenamiento. No respondía a quiénes eran los huéspedes, qué hoteles y franquiciados introducían registros en la base de datos, dónde accedían a ella el personal y los proveedores de servicios, qué reguladores tenían autoridad, qué copias existían o dónde residían posteriormente los archivos exportados y las imágenes forenses.

La ICO contabilizó registros asociados al EEE y al Reino Unido porque las personas y el contexto del tratamiento eran relevantes según la legislación europea. Los estados de EE. UU. contabilizaron los registros asociados a Estados Unidos para su acuerdo. La declaración de privacidad actual de Marriott enhttps://www.marriott.com/about/privacy.midescribe las transferencias globales, los mecanismos de transferencia, la seguridad y los compromisos de retención en el negocio actual. No es una prueba de la arquitectura de Starwood de 2014-2018, pero ilustra por qué un grupo hotelero global no puede tratar una única ubicación de base de datos como la respuesta completa de gobernanza.

La soberanía de los datos en un sistema de reservas tiene varias capas. La localidad de almacenamiento pregunta dónde se encuentran la base de datos principal, las réplicas, las copias de seguridad, las exportaciones, los registros y las imágenes forenses. La localidad de acceso pregunta qué empleados, contratistas, operadores hoteleros y proveedores de servicios pueden acceder a los datos y desde dónde. La localidad legal sigue a los huéspedes, hoteles, responsables del tratamiento, encargados del tratamiento, acuerdos de franquicia y alcance regulatorio.

La localidad comercial sigue el significado de una estancia: fechas de viaje, acompañantes, indicadores VIP, detalles de aerolíneas, necesidades de habitación y destino.

La brecha de Starwood muestra que una base de datos ubicada en Estados Unidos puede crear igualmente una exposición regulatoria global y un daño global a los clientes. También muestra por qué la diligencia en la adquisición debe mapear las copias y el acceso, no solo el almacenamiento principal. Un comprador que sabe dónde se encuentra el sistema principal pero no quién puede exportar las tablas o qué campos de pasaporte están protegidos tiene conocimiento de la ubicación sin conocimiento del control.

Economía del contacto abusivo en los datos de viaje

Los datos expuestos no necesitaban incluir contraseñas o números de tarjeta completos para reducir el coste del abuso. Un registro de reserva puede hacer que un mensaje sea creíble. Puede mencionar una marca de hotel, una fecha de estancia, una relación de fidelización, un destino de viaje, un detalle de vuelo, una preferencia de habitación, una pista sobre la composición familiar o una preferencia de comunicación. Ese contexto ayuda a un estafador a sonar menos genérico.

La guía de phishing de CISA enhttps://www.cisa.gov/sites/default/files/2024-02/Update%20to%20Phishing%20General%20Security%20Postcard_01.01.2024.pdfdescribe el phishing dirigido como el uso de información clave sobre una persona. El consejo para consumidores de la FTC sobre Marriott enhttps://consumer.ftc.gov/consumer-alerts/2018/12/marriott-data-breachadvirtió a los consumidores sobre estafas que podrían explotar la brecha. La guía de IdentityTheft.gov enhttps://www.identitytheft.gov/databreachproporciona pasos generales de respuesta para la información personal expuesta. Estas fuentes no prueban que un huésped específico sufriera una estafa concreta. Respaldan la vía de riesgo creada por las categorías de datos.

Los datos de viaje también tienen un contexto personal más allá del fraude. Las fechas de llegada y salida pueden revelar ausencia del hogar, viajes de negocios, viajes médicos, visitas familiares o relaciones. Los números de pasaporte son identificadores duraderos. La información de fidelización puede conectar estancias a lo largo del tiempo. Un indicador VIP o una solicitud de habitación pueden revelar expectativas de servicio o circunstancias familiares. La economía del contacto abusivo pertenece, por tanto, al análisis de impacto incluso cuando no se demuestre un fraude con tarjetas.

La cuestión de la minimización de datos es la siguiente: ¿cuánto tiempo deben permanecer los datos de reservas antiguas en los sistemas activos? ¿Qué campos son necesarios después del check-out, después de la acreditación de puntos de fidelización, después de los plazos de disputa, después de los períodos fiscales o después de las retenciones legales? ¿Qué campos pueden tokenizarse, enmascararse, eliminarse o separarse? Las copias de seguridad y las exportaciones necesitan la misma lógica de retención que la producción.

De lo contrario, una base de datos heredada puede conservar datos porque sigue siendo operativamente conveniente, no porque cada campo siga siendo necesario.

Una nota tipográfica para los registros de riesgo heredado

Los registros de seguridad de los sistemas adquiridos deben ser legibles a la vez para ejecutivos, ingenieros, abogados, proveedores de servicios y reguladores. Los hallazgos densos pueden ocultar brechas decisivas. Se incluye el siguiente bloque tipográfico porque la presentación del riesgo heredado afecta a si los responsables del control ven lo que debe cambiar.

La tipografía es el arte y la técnica de organizar los tipos para que el lenguaje escrito sea legible, legible y visualmente atractivo. Implica seleccionar tipografías, tamaños de punto, longitudes de línea, interlineado 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 el estado de ánimo o el tono en el diseño.

Para una adquisición, los registros legibles significan un mapa de límites de una página que separe los hechos conocidos, las declaraciones del vendedor, las afirmaciones no verificadas, las pruebas requeridas, las acciones sobre credenciales, las copias de datos, el estado criptográfico, las obligaciones de los proveedores de servicios y las fechas de retirada. Si esos elementos están enterrados en documentos de transacción y exportaciones de herramientas, la organización puede creer que ha aceptado el riesgo sin saber qué riesgo aceptó.

Responsabilidad mediante el control práctico

El atacante controló la intrusión no autorizada, la persistencia, el uso indebido de credenciales y la exportación de datos. Ningún registro público revisado aquí identifica al atacante ni determina un motivo o afiliación estatal. La responsabilidad del acceso delictivo recae en el actor o actores que lo llevaron a cabo.

Starwood controlaba el entorno cuando se produjo el compromiso inicial. Era propietaria u operaba los sistemas, las credenciales y la supervisión que permitieron al atacante entrar y persistir antes de la adquisición de Marriott. También arrastró al acuerdo el historial de la brecha anterior en el punto de venta. Eso no prueba que Starwood supiera del intruso en las reservas. Significa que el entorno oculto era el objeto de confianza del lado del vendedor.

Marriott controlaba el entorno posterior al cierre y el plan de migración. Una vez que fue propietaria de Starwood, controlaba si se restablecían las credenciales heredadas, se supervisaban las cuentas privilegiadas, se ampliaban las alertas de la base de datos, se endurecían los sistemas críticos, se evaluaban los campos de pasaportes, se verificaban las afirmaciones criptográficas y se aceleraba o mitigaba la retirada del sistema. Marriott también controlaba la notificación a los clientes y las actualizaciones públicas tras el descubrimiento. Su control estaba limitado por la continuidad del negocio y la escala, pero no era inexistente.

Los proveedores de servicios controlaban las operaciones gestionadas, las alertas y el escalado en su ámbito. El papel de Accenture en la gestión de la base de datos y el escalado de la alerta de Guardium muestra por qué las operaciones de terceros deben tener umbrales de incidentes claros, transferencia de pruebas y autoridad del responsable del tratamiento. Un proveedor de servicios puede ser un detector temprano. El responsable del tratamiento debe decidir aún la notificación, el alcance y la remediación.

Los reguladores controlaban la corrección exigible. La sanción de la ICO, el acuerdo estatal y la orden de la FTC tradujeron las lecciones de seguridad en obligaciones. No prueban todas las reclamaciones privadas. Sí dejan claro que la adquisición no congela la responsabilidad en el estado del conocimiento previo al cierre. La propiedad conlleva el deber de probar y mejorar los controles heredados.

Los huéspedes controlaban muy poco. Reservaban habitaciones, se unían a programas de fidelización, proporcionaban datos de pasaporte y contacto y confiaban en las operaciones hoteleras. Podían supervisar las tarjetas o responder a los avisos a posteriori. No podían inspeccionar la supervisión de la base de datos de Starwood, rotar las credenciales privilegiadas, verificar las declaraciones de cifrado o acelerar la retirada del sistema. Esa asimetría es la razón por la que esto pertenece a un registro de responsabilidad.

Lo que requeriría una integración verificable

La lección de reparación no es «nunca adquiera sistemas heredados». Es que la integración de adquisiciones debe incluir la búsqueda de la verdad en materia de seguridad con pruebas.

Un comprador debe clasificar los sistemas heredados de alto riesgo antes del cierre y luego comenzar inmediatamente la verificación posterior al cierre: restablecimiento de identidades privilegiadas, revisión del acceso de los proveedores de servicios, búsqueda en endpoints y servidores, registro de exportaciones de la base de datos, comparación de la cobertura de controles, inventario criptográfico, revisión de la retención de datos, mapeo de copias de seguridad y evaluación del riesgo de migración.

Para una base de datos de reservas, las pruebas deben ser a nivel de campo y a nivel de copia. ¿Qué tablas contienen números de pasaporte? ¿Cuáles contienen restos de tarjetas de pago? ¿Cuáles contienen acompañantes de viaje, niños, identificadores de fidelización y preferencias de comunicación? ¿Qué campos están en texto plano, cifrados, hash o tokenizados? ¿Qué aplicaciones pueden solicitarlos? ¿Qué usuarios pueden exportarlos? ¿Qué registros muestran copias completas de las tablas? ¿Qué copias de seguridad los conservan? ¿Qué propósito legal o comercial justifica su retención?

En cuanto a la confianza en terceros, el comprador debe saber qué proveedores gestionan el sistema, qué alertas reciben, qué umbrales requieren escalado, qué registros conservan, qué credenciales poseen, cómo se rigen los subcontratistas y cómo puede obtener pruebas el responsable del tratamiento tras una sospecha de brecha. Un informe de proveedor no es suficiente si no puede vincularse al sistema y las categorías de datos específicos.

Para la notificación, la organización debería poder producir una explicación específica para el huésped: qué campos, qué período de tiempo, qué fuente de registro, qué medidas de protección, qué incertidumbre queda y qué actualizaciones se producirán. Puede ser necesario un aviso amplio al principio, pero cabe esperar correcciones posteriores cuando cambien los recuentos, los campos o los hechos criptográficos.

La retirada no es lo mismo que la eliminación del riesgo

El plan de Marriott de retirar la plataforma de reservas de Starwood era comercial y operativamente significativo. La retirada puede ser un control sólido: reduce la superficie de ataque activa, obliga a migrar a una plataforma mejor gobernada y puede acabar con la dependencia de credenciales y herramientas heredadas. Pero la retirada no es una eliminación instantánea del riesgo. Un sistema programado para su cierre puede seguir siendo altamente sensible mientras aún procesa reservas, da soporte a hoteles y contiene registros históricos.

La migración de dos años descrita por Marriott creó un período de transición. Durante ese período, la plataforma heredada todavía necesitaba supervisión, hardening, revisión de credenciales, registro de exportaciones y minimización de datos. Una fecha de retirada no justifica controles más débiles antes de que llegue la fecha. En algunos casos, puede crear el riesgo opuesto: los equipos pueden dudar en invertir en controles para un sistema que esperan desmantelar, mientras que los atacantes se benefician de la ventana restante.

Un plan de retirada seguro debe tener hitos más allá de «dejar de usar el sistema para operaciones comerciales». Debe identificar las copias de seguridad, las réplicas, las exportaciones, las imágenes forenses, las cuentas de administrador, las cuentas de servicio, el acceso de proveedores, las claves de cifrado, los almacenes de registros, las fuentes de datos y las copias posteriores. Debe decidir qué debe conservarse por razones legales o comerciales y qué debe eliminarse o transformarse. Debe verificar que las credenciales desmanteladas no puedan seguir accediendo a los archivos.

Debe preservar las pruebas necesarias para litigios o revisión regulatoria sin dejar datos innecesarios expuestos.

El caso Starwood muestra por qué esto es importante. Según se informa, la base de datos de reservas activa se retiró a finales de 2018, pero la investigación de la brecha, las acciones regulatorias, las demandas colectivas, los acuerdos estatales, la orden de la FTC y la corrección criptográfica continuaron durante años. Un sistema puede salir de producción y seguir siendo central para la responsabilidad. El registro de lo que contenía, quién accedió a él, cómo estaba protegido y cómo se manejaron las copias se convierte en la base probatoria para cada procedimiento posterior.

La retirada también interactúa con los derechos de los huéspedes. Si un huésped pregunta qué datos estuvieron involucrados, la respuesta no puede desaparecer con la antigua plataforma. Si un regulador pregunta por qué se retuvo un campo o cómo se protegió, la organización necesita registros después de la migración. Si una empresa corrige posteriormente una descripción criptográfica, debe comprender el comportamiento de las aplicaciones antiguas y los valores almacenados lo suficientemente bien como para explicar la corrección. El desmantelamiento sin conservar las pruebas de control puede dificultar la búsqueda posterior de la verdad.

La administración criptográfica es un control de gestión

La corrección de AES a SHA-1 se trata a menudo como una nota técnica al pie. Se entiende mejor como una señal de control de gestión. La criptografía protege a las personas solo cuando la organización sabe qué protección se está aplicando realmente. Ese conocimiento tiene que sobrevivir a fusiones, operaciones de proveedores, aplicaciones heredadas, avisos públicos y litigios.

Un inventario criptográfico a nivel de campo debería responder a varias preguntas. ¿Qué campo está protegido? ¿La transformación es cifrado reversible, hash unidireccional, tokenización, enmascaramiento, truncamiento u otro método? ¿Qué algoritmo y modo se utilizan? ¿Hay sales o claves presentes? ¿Dónde se almacenan las claves o secretos? ¿Qué aplicación puede solicitar el valor original? ¿Qué registros muestran el uso? ¿Qué versiones antiguas utilizaban un método diferente? ¿Qué avisos o políticas describen la protección? ¿Quién tiene autoridad para certificar la declaración antes de que se publique?

En un sistema adquirido, estas respuestas pueden estar dispersas en documentos del vendedor, código, configuraciones de la base de datos, notas de proveedores, memoria de los desarrolladores y antiguos informes de cumplimiento. El comprador debe asumir que las etiquetas pueden ser incorrectas hasta que se prueben. «Protegido» no es suficiente. «Cifrado» no es suficiente. Un nombre de campo que termine en token o hash no es suficiente. Las pruebas requieren la inspección de los valores almacenados, las llamadas a la aplicación, los servicios de claves y las rutas de recuperación.

La conclusión sobre los números de pasaporte refuerza el mismo punto. La cuestión no era solo que millones de números de pasaporte no estuvieran cifrados. Era que Marriott carecía de una evaluación de riesgos documentada que explicara por qué algunos números de pasaporte recibían un trato diferente al de otros. La protección selectiva puede ser racional. Puede reflejar limitaciones heredadas, necesidades comerciales o una migración por fases. Pero debe estar documentada y revisada frente a las consecuencias de la exposición. De lo contrario, la protección desigual parece un accidente en lugar de una decisión basada en el riesgo.

La administración criptográfica también afecta a la calidad de la notificación. Si una organización dice a las personas que el valor de su tarjeta o pasaporte estaba cifrado, la persona puede inferir razonablemente un riesgo diferente que si el valor estuviera hash con SHA-1 o sin cifrar. Si la organización cambia posteriormente esa descripción, la corrección debe decir qué cambió, qué valores se ven afectados, qué significa para el uso indebido y qué incertidumbre queda. Eso no es meramente higiene comunicativa. Es parte de la administración responsable de los datos de identidad.

El manual de adquisiciones debe nombrar lo desconocido

La cultura de las transacciones premia la confianza. La integración de la seguridad necesita una lista de desconocidos. El comprador debe saber qué partes del entorno heredado están verificadas, cuáles son declaradas por el vendedor, cuáles se asumen para la continuidad del negocio y cuáles permanecen sin probar. Un registro de riesgos que etiquete un desconocido como un riesgo aceptado es más sólido que un memorando de diligencia que oculte lo desconocido tras garantías amplias.

Para una plataforma de reservas global, los desconocidos deben incluir las copias de datos, las cuentas privilegiadas, el acceso de los proveedores de servicios, los sistemas de cara al exterior, los artefactos de brechas antiguas, el software sin soporte, las lagunas de registro, el estado criptográfico y la retención. Cada desconocido debe tener un propietario y una fecha. Algunos se resolverán con la migración. Otros necesitarán controles compensatorios mientras el sistema permanezca activo. Algunos pueden volverse inaceptables una vez que el comprador comprenda el volumen de datos.

Este enfoque también protege al comprador de una falsa retrospectiva. Reconoce que no todos los hechos pueden conocerse antes del cierre. A continuación, crea la obligación posterior al cierre de reducir la incertidumbre. El fallo no es la incapacidad de saberlo todo el primer día. El fallo es permitir que la incertidumbre del primer día se convierta en la incertidumbre del segundo año mientras el sistema heredado sigue albergando datos de los huéspedes.

La calidad de la notificación depende de la calidad de la integración

La notificación a los clientes se trata a menudo como un problema de plazos legales. El incidente de Starwood muestra que la calidad de la notificación depende de la calidad de la integración mucho antes de que se confirme la brecha. Si la organización no sabe qué tablas contienen qué campos, cómo se asignan los duplicados a las personas, cuántos números de pasaporte están en texto plano, qué valores están protegidos y qué registros pertenecen a qué regiones, entonces la notificación será amplia, tardía, corregida o las tres cosas.

El primer aviso de Marriott utilizó límites superiores prudentes porque los investigadores todavía estaban clasificando los registros y los duplicados. Eso puede ser inevitable en un sistema heredado de gran tamaño. Pero la lección de control a largo plazo es que los catálogos de datos de los huéspedes ya deberían existir para los sistemas de alto riesgo. Deberían describir la finalidad del campo, la sensibilidad, la región, la retención, el estado criptográfico, los roles de acceso y las rutas de exportación. Deberían conciliarse con el contenido real de la base de datos, no solo con la documentación de la aplicación.

Esto también afecta a los reguladores. Un regulador que evalúe el momento o la adecuación de la notificación necesita saber cuándo tuvo conocimiento el responsable del tratamiento de que estaban involucrados datos personales y qué hechos estaban razonablemente disponibles. Si el propio proceso de integración del responsable del tratamiento no puede distinguir una tabla de cuentas de una tabla de pasaportes o un registro duplicado de un huésped único, entonces el análisis jurídico se enreda con la deuda técnica. Una mejor integración reduce tanto la confusión del incidente como la incertidumbre jurídica posterior.

El mismo principio se aplica a las correcciones públicas. La actualización de SHA-1 de 2024 de Marriott era materialmente diferente de la descripción original del cifrado. Una corrección años después puede ser el acto responsable una vez que se conoce un hecho, pero también muestra que la cadena de pruebas original no era lo suficientemente sólida. Un programa de seguridad posterior a la adquisición debería incluir una regla que exija que las descripciones criptográficas públicas sean verificadas por los responsables técnicos antes de la notificación y revisadas periódicamente si cambian las pruebas heredadas.

Dependencia de la nube en el sector hotelero

El manifiesto clasifica este caso en parte como una dependencia de servicios en la nube porque la plataforma de reservas funcionaba como infraestructura compartida para un negocio hotelero global, aunque no fuera una nube pública en el sentido moderno. Hoteles, centros de contacto, servicios de fidelización, proveedores de servicios gestionados y equipos corporativos dependían todos de la disponibilidad e integridad de una plataforma central. Esa plataforma concentraba datos de muchas propiedades y jurisdicciones.

Esta dependencia es la razón por la que la brecha afectó a más que al propietario corporativo. Franquiciados, hoteles gestionados, huéspedes, equipos de tarjetas de pago, titulares de pasaportes, miembros de fidelización, reguladores y proveedores de servicios tenían todos un interés en el mismo sistema heredado. Un hotel local no podía inspeccionar la supervisión de la base de datos. Un huésped no podía saber si los campos de pasaporte estaban cifrados. Un proveedor de servicios podía escalar una alerta, pero solo el responsable del tratamiento podía coordinar la notificación a los huéspedes y la respuesta global.

Para la planificación de adquisiciones, el control práctico es el mapeo de dependencias. ¿Qué funciones de negocio se detienen si se aísla la plataforma de reservas heredada? ¿Qué hoteles siguen dependiendo de ella? ¿Qué fuentes de datos continúan durante la migración? ¿Qué terceros pueden acceder a ella? ¿Qué compromisos con los clientes dependen de ella? Un comprador que solo mapea los componentes tecnológicos se pierde la presión empresarial que puede mantener vivo un sistema de riesgo. Un comprador que mapea las dependencias puede justificar controles compensatorios mientras avanza la migración.

La evaluación final es de alto impacto y alta confianza. Marriott heredó una plataforma de reservas activa y comprometida. Ese hecho no convierte a Marriott en el intruso original ni prueba que pudiera haber conocido todos los detalles antes del cierre. Sí hace a Marriott responsable del período posterior al cierre en el que controló el sistema adquirido, procesó datos de los huéspedes y tuvo que convertir la confianza en terceros en un control verificado. Una adquisición puede comprar una marca de la noche a la mañana. No puede comprar la certeza. La certeza tiene que construirse, probarse y demostrarse.