Una carta del 17 de julio sobre un sábado de agosto

La carta salió del número 767 de la Quinta Avenida de Nueva York el 17 de julio de 2026. Tiene cuatro páginas, está escrita con claridad y comunica al lector que el 19 de junio de 2026 The Estee Lauder Companies determinó mediante su investigación que, el 9 de agosto de 2025 o en torno a esa fecha, un tercero no autorizado obtuvo acceso al sistema Oracle E-Business Suite y se hizo con información personal de determinadas personas. El sistema, dice la carta, lo utiliza la compañía para la gestión de recursos humanos.

Lea las dos fechas juntas. El acceso ocurrió un sábado de agosto de 2025. La compañía estableció que había ocurrido un viernes de junio de 2026. Entre esos dos hechos median 314 días en los que los datos ya no estaban y nadie lo sabía. La carta no lo esquiva. Enuncia ambas fechas en la misma frase, más franqueza de la que logran la mayoría de las notificaciones.

Estee Lauder hizo lo que hace un respondedor competente en cuanto supo: abrió una investigación con expertos externos, avisó a las autoridades policiales, aplicó salvaguardas adicionales al sistema y ofreció 24 meses de vigilancia de identidad a través de Kroll, con plazo de inscripción hasta el 31 de octubre de 2026. Nada de eso es lo interesante. Lo interesante son los 314 días y de qué estaban hechos.

La velocidad de parcheo nunca fue aquí la variable

La corrección aún no existía. La intrusión encaja con la campaña de explotación masiva contra Oracle E-Business Suite a través de CVE-2025-61882, atribuida después al grupo extorsionador Clop. Oracle publicó la corrección el 4 de octubre de 2025. Cuente hacia atrás hasta el 9 de agosto de 2025 y obtendrá 56 días. El atacante llevaba ocho semanas dentro del edificio antes de que el fabricante enviara la cerradura.

Esto importa por lo que se enseña a la mayoría de los consejos. La diapositiva de seguridad del informe trimestral suele ser una cifra de cumplimiento de parches: porcentaje de parches críticos aplicados dentro del plazo acordado. Es un número real y mide una disciplina real. Y no tuvo la menor influencia en este desenlace. Una compañía con el 100 por cien de cumplimiento y un plazo de 14 días habría sido comprometida exactamente el mismo sábado, porque ese sábado no había nada que aplicar.

Sí, pero la vulnerabilidad era alcanzable. Oracle describió el fallo como algo que permitía a atacantes no autenticados con acceso de red ejecutar código de forma remota sobre HTTP, y afectaba a las versiones 12.2.3 a 12.2.14 de E-Business Suite. Esa es la decisión que sí estaba disponible por anticipado: no con qué rapidez parchea, sino si un módulo de recursos humanos dentro de un ERP debía responder peticiones HTTP desde un segmento de red que un desconocido sin autenticar podía alcanzar. Nadie toma esa decisión durante un incidente. Se toma años antes, casi siempre por quien quería que la integración funcionara el viernes.

Lo que el módulo de recursos humanos guardaba en realidad

La carta enumera lo que obtuvo el tercero: nombres, direcciones postales y de correo electrónico, fechas de nacimiento, números de la seguridad social, números de pasaporte, información de cuentas financieras en forma de números de cuenta bancaria, información de salud e información laboral como evaluaciones de desempeño y datos de nómina. La carta señala que los datos afectados variaron según cada persona.

Esa no es la fama de un sistema de personal. Pida a la mayoría de los directivos que nombren las joyas de la corona y dirán la base de clientes, el código fuente, el libro mayor. El módulo de recursos humanos rara vez figura, porque mentalmente se archiva como herramienta administrativa. En la práctica es el único lugar de casi cualquier compañía donde documentos de identidad, datos bancarios e historiales de salud conviven en un mismo esquema, indexados por número de empleado y conservados una década porque el derecho laboral lo exige.

Conviene enunciar la asimetría sin rodeos. Un registro de cliente filtra una dirección de correo y un historial de compras. Este registro filtra los documentos con los que una persona demuestra que existe. Una contraseña se vuelve a emitir. Volver a emitir un número de pasaporte requiere un Estado.

Los 314 días fueron un problema de detección, no de respuesta

Divida la cronología en los tres tramos que realmente contiene. Del 9 de agosto de 2025 al 19 de junio de 2026 hay 314 días de pérdida no detectada. Del 19 de junio a la carta del 17 de julio de 2026 hay 28 días de investigación, delimitación y revisión jurídica. Y antes de todo ello está la decisión de arquitectura que puso un módulo de ERP alcanzable delante de la red.

Solo dos de los tres están en su mano. Los 28 días son proceso, y el proceso se afina: hoy puede decidir quién redacta la notificación, quién la firma y cuántos días cuesta la revisión jurídica. La arquitectura es capital y tiempo, y ahí reside la palanca de verdad. Los 314 días son el residuo. Son lo que ocurre cuando un sistema es lo bastante importante para guardar pasaportes y lo bastante irrelevante para que nadie lea sus registros.

La conclusión. La detección no es una herramienta que se compra, es consecuencia de lo que usted decidió vigilar, y la vigilancia sigue a la clasificación. Estee Lauder no dejó de reaccionar. Reaccionó a los pocos días de saberlo. El fallo, si la palabra siquiera procede, ocurrió en alguna tarde tranquila en que alguien clasificó un módulo de recursos humanos como de baja criticidad y siguió adelante. Esa decisión fue reversible durante diez meses y gratuita de revertir casi todo ese tiempo.

Tres preguntas para su propio ERP esta semana

Primera, la pregunta de inventario. Liste todo sistema que guarde documentos de identidad, datos bancarios o de salud y que su registro de activos no clasifique hoy como crítico. En la mayoría de las compañías europeas la respuesta incluye al menos un módulo de personal o de nóminas, y a menudo una herramienta antigua de gastos. Esa lista es su verdadero registro de joyas de la corona, y suele ser más corta de lo que se teme y distinta de lo esperado.

Segunda, la pregunta de alcance. Para cada uno de esos sistemas, quién puede alcanzarlo sin autenticarse, y desde dónde. No quién debería. Quién puede. Bajo el RGPD la obligación del responsable recae sobre esos datos con independencia de qué departamento interno lleve el presupuesto, y un plazo de notificación de 72 horas no atiende a que el módulo fuera el proyecto de otro.

Tercera, la pregunta de evidencia. Si alguien alcanzara hoy ese sistema, qué se lo diría, y cuánto tardaría en decírselo. Si la respuesta honesta es un aviso del fabricante o una llamada de la policía, su intervalo de detección para ese sistema se mide en las mismas unidades que el de Estee Lauder, y lo sabe desde que terminó de leer esta frase.

Leer a continuación: OpenSSL lo corrigió en junio y sin ningún CVE  |  Una comisaria frenó un campus de 2 gigavatios