Uma carta de 17 de julho sobre um sábado de agosto

A carta saiu do número 767 da Fifth Avenue, em Nova Iorque, a 17 de julho de 2026. Tem quatro páginas, está escrita com clareza e informa o leitor de que a 19 de junho de 2026 a The Estee Lauder Companies determinou, através da sua investigação, que a 9 de agosto de 2025 ou por essa altura um terceiro não autorizado obteve acesso ao sistema Oracle E-Business Suite e recolheu informação pessoal de determinadas pessoas. O sistema, diz a carta, é usado pela empresa para a gestão de recursos humanos.

Leia as duas datas em conjunto. O acesso ocorreu a um sábado de agosto de 2025. A empresa estabeleceu a uma sexta-feira de junho de 2026 que tinha ocorrido. Entre esses dois factos estão 314 dias em que os dados já tinham saído e ninguém sabia. A carta não foge disso. Enuncia ambas as datas na mesma frase, o que é mais franqueza do que a maioria das notificações consegue.

A Estee Lauder fez o que faz quem responde com competência assim que sabe: abriu uma investigação com peritos externos, avisou as autoridades, aplicou salvaguardas adicionais ao sistema e ofereceu 24 meses de vigilância de identidade através da Kroll, com prazo de adesão até 31 de outubro de 2026. Nada disso é a parte interessante. A parte interessante são os 314 dias, e de que eram feitos.

A rapidez da correção nunca foi aqui a variável

A correção ainda não existia. A intrusão enquadra-se na campanha de exploração em massa contra a Oracle E-Business Suite através do CVE-2025-61882, mais tarde atribuída ao grupo de extorsão Clop. A Oracle publicou a correção a 4 de outubro de 2025. Conte para trás até 9 de agosto de 2025 e obtém 56 dias. O atacante esteve dentro do edifício oito semanas antes de o fabricante expedir a fechadura.

Isto importa por causa do que é mostrado à maioria dos conselhos. O diapositivo de segurança de um dossiê trimestral é habitualmente um número de conformidade: percentagem de correções críticas aplicadas dentro do prazo acordado. É um número verdadeiro e mede uma disciplina verdadeira. E não teve a menor influência neste desfecho. Uma empresa com 100 por cento de conformidade num prazo de 14 dias teria sido comprometida exatamente no mesmo sábado, porque nesse sábado não havia nada para aplicar.

Sim, mas a vulnerabilidade era alcançável. A Oracle descreveu a falha como permitindo a atacantes não autenticados com acesso de rede executar código remotamente sobre HTTP, afetando as versões 12.2.3 a 12.2.14 da E-Business Suite. Essa é a decisão que estava realmente disponível de antemão: não a rapidez com que atualiza, mas se um módulo de recursos humanos dentro de um ERP devia sequer responder a pedidos HTTP a partir de um segmento de rede alcançável por um desconhecido sem autenticação. Ninguém toma essa decisão durante um incidente. Toma-se anos antes, em regra por quem queria a integração a funcionar até sexta-feira.

O que o módulo de recursos humanos guardava na verdade

A carta enumera o que o terceiro obteve: nomes, moradas postais e endereços eletrónicos, datas de nascimento, números de segurança social, números de passaporte, informação de contas financeiras sob a forma de números de conta bancária, informação de saúde e informação laboral como avaliações de desempenho e dados de vencimento. A carta nota que os dados afetados variaram para cada pessoa.

Não é essa a fama de um sistema de pessoal. Peça à maioria dos dirigentes que nomeie as joias da coroa e dirão a base de clientes, o código-fonte, o razão. O módulo de recursos humanos raramente entra na lista, porque está mentalmente arrumado como ferramenta administrativa. Na prática é, em quase todas as empresas, o único sítio onde documentos de identidade, dados bancários e registos de saúde coexistem num mesmo esquema, indexados por número de trabalhador e conservados uma década porque o direito do trabalho assim o exige.

Vale a pena dizer a assimetria sem rodeios. Um registo de cliente deixa sair um endereço eletrónico e um historial de compras. Este registo deixa sair os documentos com que uma pessoa prova que existe. Uma palavra-passe volta a emitir-se. Voltar a emitir um número de passaporte exige um Estado.

Os 314 dias foram um problema de deteção, não de resposta

Divida a cronologia nos três intervalos que realmente contém. De 9 de agosto de 2025 a 19 de junho de 2026 são 314 dias de perda não detetada. De 19 de junho à carta de 17 de julho de 2026 são 28 dias de investigação, delimitação e revisão jurídica. E antes de tudo isso está a decisão de arquitetura que colocou um módulo de ERP alcançável à frente da rede.

Só dois dos três dependem de si. Os 28 dias são processo, e o processo afina-se: hoje pode decidir quem redige a notificação, quem a assina e quantos dias custa a revisão jurídica. A arquitetura é capital e tempo, e é aí que está a alavanca a sério. Os 314 dias são o resíduo. São o que acontece quando um sistema é suficientemente importante para guardar passaportes e suficientemente irrelevante para que ninguém leia os seus registos.

A conclusão. A deteção não é uma ferramenta que se compra, é consequência daquilo que decidiu vigiar, e a vigilância segue a classificação. A Estee Lauder não deixou de reagir. Reagiu poucos dias depois de saber. A falha, se a palavra sequer se aplica, deu-se numa tarde calma em que alguém classificou um módulo de recursos humanos como pouco crítico e seguiu em frente. Essa decisão foi reversível durante dez meses e gratuita de reverter durante quase todos eles.

Três perguntas a fazer ao seu próprio ERP esta semana

Primeiro, a pergunta de inventário. Liste todo o sistema que guarde documentos de identidade, dados bancários ou de saúde e que o seu registo de ativos hoje não classifique como crítico. Na maioria das empresas europeias a resposta inclui pelo menos um módulo de pessoal ou de vencimentos, e muitas vezes uma antiga ferramenta de despesas. Essa lista é o seu verdadeiro registo de joias da coroa, e costuma ser mais curta do que se receia e diferente do que se esperava.

Segundo, a pergunta de alcance. Para cada um desses sistemas, quem consegue alcançá-lo sem se autenticar, e a partir de onde. Não quem deve. Quem consegue. Ao abrigo do RGPD, a obrigação do responsável recai sobre esses dados independentemente de que departamento interno detém o orçamento, e um prazo de notificação de 72 horas não se importa que o módulo fosse o projeto de outra pessoa.

Terceiro, a pergunta de prova. Se alguém alcançasse hoje esse sistema, o que lho diria, e quanto tempo demoraria a dizer. Se a resposta honesta for um aviso do fabricante ou um telefonema das autoridades, então o seu intervalo de deteção para esse sistema mede-se nas mesmas unidades que o da Estee Lauder, e sabe-o desde que acabou de ler esta frase.

Leia a seguir: A OpenSSL corrigiu em junho e sem qualquer CVE  |  Uma comissária travou um campus de 2 gigawatts