Pontos principais

• O ResOps não é um produto tecnológico. Trata-se de uma disciplina operacional multifuncional que ajuda a promover a resiliência cibernética da organização.
• Ela complementa o backup, a recuperação de desastres, a segurança cibernética, a continuidade de negócios e a resposta a incidentes, alinhando essas funções em torno de resultados de recuperação de ponta a ponta.
• O ResOps concentra-se em serviços críticos e nos limites de impacto definidos pela empresa, em vez de componentes isolados da infraestrutura.
• Baseia-se na produção contínua de evidências, incluindo resultados de Recovery testados, indicadores de resiliência de serviços e um inventário próprio de lacunas.
• O ResOps é um processo contínuo. Nem a elaboração de um plano nem a realização de um exercício pontual bem-sucedido são suficientes para estabelecer uma capacidade de recuperação duradoura.

O novo desafio da resiliência

A maioria das organizações investe em segurança cibernética, backup, Recovery de desastres e continuidade de negócios. No entanto, muitos executivos ainda enfrentam três questões críticas: Podemos nos recuperar? Quanto tempo vai demorar a recuperação? E podemos provar isso? Parte do desafio é que a responsabilidade pela resiliência está distribuída entre equipes que, muitas vezes, operam em silos. A equipe de segurança gerencia ameaças. A equipe de TI mantém os sistemas. As equipes de Backup and Recovery restauram dados e infraestrutura. As equipes de continuidade de negócios se concentram em manter a organização em funcionamento. Cada uma desempenha um papel importante, mas a responsabilidade pela recuperação pode permanecer fragmentada.

O ResOps reúne essas funções em torno de prioridades compartilhadas, metas de Recovery e evidências. O resultado é uma maneira mais prática de abordar a resiliência: saber o que é mais importante, entender o que é necessário para recuperá-lo, testar se a recuperação funciona e agir sobre as lacunas encontradas.

O que é ResOps?

O ResOps é a disciplina operacional que reúne segurança, infraestrutura, operações de TI, continuidade de negócios e responsáveis de negócios em torno de serviços críticos, projeto resiliente e validação contínua. Em termos simples, o ResOps ajuda as equipes a se prepararem para interrupções, recuperar serviços críticos dentro das tolerâncias de impacto definidas pela empresa e demonstrar, com base em evidências, que a recuperação funciona.

Quatro características definem o ResOps. Ele é:

1. Multifuncional por natureza. O ResOps conecta responsabilidades distribuídas por meio de um modelo operacional compartilhado, atribuição de responsabilidades e governança executiva.
2. Centrado em serviços críticos. Prioriza os serviços que a organização deve restaurar para entregar valor essencial, atender aos clientes e gerar receita; além de ajudar a cumprir obrigações urgentes de natureza jurídica, regulatória, de segurança e de missão.
3. Validado continuamente. A resiliência é uma postura que as equipes devem exercer e aprimorar — não um estado estabelecido por um teste anual.
4. Medido por meio de evidências. O ResOps produz uma pontuação de postura de resiliência (RPS): uma pontuação por serviço, respaldada por evidências, que mede o grau de recuperabilidade de um único serviço crítico com base em resultados de validação, integridade das dependências e confiança na recuperação sem falhas.

O que não é ResOps?

Não é uma categoria de produto.

Nenhuma plataforma pode criar o ResOps por si só. Tecnologias de proteção de dados, Recovery cibernética, automação, observabilidade e testes podem apoiar a disciplina, mas o ResOps é organizacional. Ele depende de governança, responsabilidade compartilhada, prioridades de negócios, práticas operacionais e um padrão comum de evidências.

Não substitui o Backup and Recovery nem a Recuperação de Desastres.

O ResOps não substitui recursos robustos de Backup and Recovery de desastres: ele depende deles. O backup determina se existem cópias recuperáveis. A Recovery fornece os procedimentos e os recursos técnicos para ajudar a restaurar sistemas e infraestrutura.

Mas, então, o ResOps levanta uma questão mais ampla: o serviço crítico pode retornar de forma completa, limpa e dentro dos limites de tolerância, incluindo suas identidades, aplicativos, dados, infraestrutura, serviços em nuvem, terceiros, pessoas e caminhos de decisão?

Não é apenas outro nome para continuidade de negócios ou resposta a incidentes.

A continuidade dos negócios define como a empresa opera durante interrupções. A resposta a incidentes detecta, contém e gerencia o evento. O ResOps conecta essas disciplinas ao resultado da Recovery. Ele cria um ritmo operacional para que as equipes cheguem a um consenso sobre o que é importante, validem a Recovery em condições realistas, meçam os resultados e corrijam as lacunas reveladas pelos testes.

Não se trata de um exercício de conformidade nem de um projeto pontual.

Um programa maduro de ResOps pode ajudar a gerar evidências para conselhos administrativos, órgãos reguladores, seguradoras, clientes e auditores. Mas a documentação é um subproduto, não o objetivo. O objetivo é a capacidade de recuperação comprovada.

E como sistemas, dependências, ameaças e prioridades de negócios estão em constante mudança, o ResOps nunca está “concluído”. Ele opera continuamente, assim como o planejamento financeiro ou as operações de segurança.

O que muda com o ResOps?

O ResOps muda o foco de verificar se sistemas e processos individuais estão funcionando para verificar se o serviço crítico como um todo pode ser recuperado. Isso muda as perguntas que os líderes podem fazer.

Um backup bem-sucedido é importante. Ter um plano de recuperação também é. Mas nenhum dos dois indica se um serviço crítico pode realmente ser restaurado quando você precisar. O ResOps analisa o panorama geral:

• Conseguimos nos recuperar a partir de um ponto de Recovery verificado e válido?
• Quanto tempo levou?
• Conseguimos recuperar dentro dos limites estabelecidos pela empresa?
• E o que ainda precisa de atenção?

É por isso que o ResOps é importante. Ele oferece às organizações uma maneira de ir além de suposições sobre resiliência, passando para demonstrações programáticas e confiáveis de sua capacidade de recuperação. E isso é feito por meio da produção contínua de evidências e rastreabilidade. Assim, quando ocorre uma interrupção, a questão não é se cada equipe cumpriu sua parte ou quem falhou em qual tarefa. A questão é se a empresa consegue restaurar os serviços críticos dos quais seus clientes dependem.

Saiba mais

A Commvault publicou o “ResOps: Um Guia Executivo” para oferecer aos CISOs, CIOs e líderes de TI, segurança, resiliência e Risk uma estrutura prática para implementar o ResOps em suas organizações.

Os líderes aprenderão a identificar os serviços mais importantes, validar a Readiness para Recovery com evidências reais e testar continuamente a resiliência. Como resultado, as organizações podem estabelecer um modelo operacional único que une os líderes de segurança, infraestrutura, operações de TI e negócios em torno da capacidade de recuperação baseada em evidências.

Baixe o guia aqui. 

Perguntas frequentes

P: O ResOps é simplesmente um novo nome para Recovery?

R: Não. A recuperação de desastres é uma parte essencial do ResOps, mas o ResOps analisa todo o serviço crítico — incluindo dependências técnicas, de terceiros, humanas e de tomada de decisão — e se ele pode ser recuperado dentro de uma tolerância a impactos definida pela empresa.

P: O ResOps exige a aquisição de uma nova plataforma?

R: Não. A tecnologia pode apoiar o mapeamento, os testes, a Recovery e a coleta de evidências, mas o ResOps começa com a responsabilidade, a governança, as prioridades de negócios e as práticas operacionais.

P: Quem é o responsável pelo ResOps?

R: O ResOps precisa de um líder designado com autoridade multifuncional e apoio da alta administração. Os responsáveis individuais pelos serviços continuam sendo responsáveis por seus respectivos serviços, enquanto as equipes de segurança, TI, continuidade de negócios e negócios contribuem para o resultado compartilhado da Recovery.

P: Como o sucesso do ResOps é medido?

R: O sucesso decorre de evidências atuais de que os serviços críticos podem ser recuperados sem problemas dentro de suas tolerâncias de impacto definidas — e não simplesmente pela conclusão de um plano ou pela execução bem-sucedida de uma tarefa de backup.

A pontuação de postura de resiliência (RPS) também é uma ferramenta de medição útil. Como uma pontuação por serviço, respaldada por evidências, a RPS ajuda a demonstrar o grau de recuperabilidade de um único serviço crítico com base em resultados de validação, integridade das dependências e confiança na recuperação sem falhas.

P: Como as organizações começam a implementar o ResOps?

R: Comece identificando os serviços críticos dos quais a empresa depende, quem é o responsável por eles, de que eles dependem e com que rapidez precisam ser recuperados. A partir daí, as equipes podem validar a Recovery, identificar lacunas e priorizar o trabalho necessário para fortalecer a resiliência.

Michael Thelander é diretor sênior de marketing de produto na Commvault.

Pontos principais

• A resiliência depende da rapidez e da confiança com que a empresa consegue se recuperar – e não apenas da capacidade de impedir todas as ameaças.
• Transforme os planos de recuperação em evidências – resultados comprovados têm mais credibilidade perante conselhos de administração, órgãos reguladores e seguradoras do que metas ou suposições.
• Transforme o ResOps em um modelo operacional compartilhado entre as equipes de segurança, infraestrutura, continuidade de negócios e responsáveis pelos serviços.
• Avalie o que realmente importa: as equipes devem saber se os serviços críticos podem ser restaurados, quanto tempo a Recovery realmente leva e se são capazes de comprovar isso.
• Selecione um ou dois serviços críticos, defina o que constitui uma Recovery bem-sucedida, realize um exercício honesto e documente os resultados.
• Vinte anos na liderança de segurança ensinam uma coisa logo no início: o ataque que você impediu nunca chega à reunião do conselho. Aquele que você não conseguiu impedir é a única história de que todos se lembram. Em algum momento, parei de avaliar minha equipe apenas pelo número de ataques que absorvemos e passei a avaliá-la também pela rapidez com que nos recuperamos.
• É por isso que quero que todos os CISOs, CIOs e membros do conselho que conheço leiam este novo livro, *ResOps: An Executive Guide*. A Commvault patrocinou o livro, mas eu o recomendaria de qualquer maneira.

O muro nunca foi o plano completo

Durante a maior parte da minha carreira, o trabalho consistia em construir muros mais altos. Melhor detecção, controles mais rígidos, resposta mais rápida. Esse trabalho ainda é importante e sempre será. Mas um muro responde apenas a uma pergunta, e não é mais aquela que seu conselho está fazendo.

Em setembro passado, um ransomware forçou a Jaguar Land Rover a interromper a produção global. As linhas de montagem pararam. As cadeias de suprimentos congelaram. O Cyber Monitoring Centre do Reino Unido estimou o custo para a economia em geral em cerca de 1,9 bilhão de libras, e a JLR registrou sua menor produção mensal em 73 anos. A JLR tinha defesas. O que o incidente testou não foi se o muro resistiu. Foi se a empresa conseguiria se recuperar caso ele não resistisse.

Já disse isso antes e continuarei dizendo: a interrupção não é uma questão de “se”, mas de “quando”. Os CISOs que dormem tranquilos à noite não são aqueles que acreditam que podem impedir tudo; são aqueles que treinaram a recuperação tantas vezes que o próprio treino é a garantia.

Três perguntas que faço à minha própria equipe

O livro organiza todo o problema em três perguntas, e passei a iniciar todas as análises de resiliência com elas:

• Se fôssemos atacados hoje à noite, conseguiríamos nos recuperar?
• Quanto tempo isso realmente levaria?
• Será que podemos provar isso, com evidências, para a diretoria?

A maioria das organizações responde às duas primeiras com um plano e à terceira com silêncio. Esse silêncio é a lacuna de resiliência, e ela é maior e mais cara do que a maioria dos executivos imagina.

Provas, não promessas

Aqui está uma distinção que o livro faz melhor do que já ouvi em qualquer outro lugar: um objetivo de tempo de recuperação é uma meta. Ele indica o que você almeja – mas não diz se você vai atingi-la.

Compare “acreditamos que podemos restaurar o serviço de pagamentos em quatro horas” com “nós o restauramos em 3,2 horas no último trimestre, a partir de um ponto de recuperação limpo e verificado, dentro de uma tolerância de quatro horas”. A primeira frase é um plano. A segunda é uma evidência. Apenas uma delas se sustenta quando seu conselho, seu órgão regulador ou sua seguradora cibernética começarem a fazer perguntas mais difíceis — o que certamente acontecerá.

Chamamos essa disciplina de ResOps, abreviação de operações de resiliência. Não é um produto que você compra nem um fichário que você arquiva. É um modelo operacional que conecta segurança, infraestrutura, continuidade de negócios e os responsáveis pelos negócios que dependem desses serviços, todos trabalhando com base nas mesmas evidências, em vez de planos separados.

A Parte que Deve Preocupar Todo CISO

O livro também menciona algo que eu já sentia há algum tempo e para o qual finalmente encontrei as palavras certas: o paradoxo da IA. A mesma capacidade de IA que nos ajuda a encontrar vulnerabilidades mais rapidamente está ajudando os invasores a diminuir a lacuna entre a descoberta e a exploração com a mesma rapidez, talvez até mais rápido. Encontrar mais problemas não o torna mais seguro se você não conseguir se recuperar daqueles que conseguem passar. A velocidade de detecção nunca foi a linha de chegada. A capacidade de Recovery é que é.

Comece com um serviço

Nada disso exige uma tarefa titânica, e eu estaria mentindo se dissesse que minha própria equipe acertou na primeira tentativa. O livro traça um caminho de 90 dias: escolha um ou dois dos seus serviços mais críticos, defina o que “recuperado” realmente significa para cada um, realize um exercício de Recovery honesto e produza sua primeira evidência concreta. Esse é um projeto que qualquer equipe pode iniciar neste trimestre, incluindo a minha.

Provas em vez de promessas. Readiness em vez de perfeição. Esse é o padrão que exijo da minha equipe, e é o padrão para o qual este livro lhe oferece um caminho concreto.

Adquira aqui o seu exemplar de “ResOps: Um Guia Executivo”.

Perguntas frequentes

P: O que é ResOps?

R: ResOps, abreviação de operações de resiliência, é um modelo operacional que conecta segurança, infraestrutura, continuidade de negócios e responsáveis pelos serviços em torno de práticas de Recovery compartilhadas e baseadas em evidências.

P: Em que o ResOps difere da recuperação de desastres tradicional?

R: A recuperação de desastres tradicional costuma se concentrar em planos e metas técnicas. O ResOps enfatiza a validação contínua, a responsabilidade multifuncional e a comprovação mensurável de que serviços críticos podem ser restaurados dentro dos limites de tolerância da empresa.

P: Por que as evidências de Recovery são importantes?

R: As evidências de Recovery mostram o que uma organização realmente testou e alcançou. Elas ajudam a proporcionar aos conselhos administrativos, órgãos reguladores, seguradoras e líderes empresariais maior confiança do que apenas planos ou metas de recuperação.

P: O que as organizações devem medir em um programa de ResOps?

R: As organizações devem medir se os serviços críticos podem ser restaurados, quanto tempo a recuperação realmente leva, se os pontos de recuperação estão corretos e verificados e se os resultados atendem às tolerâncias de negócios definidas.

P: Quem deve estar envolvido no ResOps?

R: O ResOps deve reunir os responsáveis pela segurança, infraestrutura, continuidade de negócios, aplicativos e serviços, além das partes interessadas da alta administração, para que as prioridades e evidências de Recovery reflitam as necessidades do negócio.

P: Como uma organização pode começar a implementar o ResOps?

R: Comece com um ou dois serviços críticos. Defina o que significa uma recuperação bem-sucedida, realize um exercício de Recovery realista, documente os resultados e use essas evidências para aprimorar o próximo teste.

Bill O’Connell é Diretor de Segurança da Commvault.

Pontos principais 

• O comunicado federal atualizado documenta novas táticas e técnicas do Medusa, além de mais de 500 vítimas em setores de infraestrutura crítica. 
• Os invasores não visam apenas os dados de produção; eles também comprometem backups, sistemas de identidade, virtualização e outros sistemas dos quais as organizações dependem para a recuperação. 
• O comunicado insta as organizações a comprovarem sua resiliência por meio de testes e validação contra comportamentos observados dos atacantes, em vez de presumirem que ela existe apenas com base em planos ou tarefas de backup bem-sucedidas.  

O mais recente comunicado federal sobre o ransomware Medusa foi atualizado por um motivo: o adversário mudou. 

O comunicado federal atualizado, emitido em 18 de agosto de 2026 pelo FBI, pela Agência de Segurança Cibernética e de Infraestrutura (CISA) e pelo Departamento de Saúde e Serviços Humanos dos EUA (HHS), descreve um adversário que recruta novos intermediários de acesso, age mais rapidamente uma vez dentro do sistema e se tornou mais hábil em garantir que os danos causados sejam irreversíveis.  

O ataque não é apenas contra seus dados

Os agentes do Medusa agem rapidamente. Investigadores relatam que esses agentes já aproveitaram exploits recém-anunciados em menos de 24 horas e, em alguns casos, utilizaram exploits até uma semana antes da divulgação pública da vulnerabilidade.

Uma vez dentro do sistema, eles se camuflam usando ferramentas legítimas de gerenciamento remoto, roubo de credenciais e técnicas de “living-off-the-land”. 

Mas a constatação mais significativa do comunicado é que o Medusa ataca o próprio caminho de recuperação.

O comunicado associa essa atividade à técnica T1490 do MITRE ATT&CK, “Inibir a recuperação do sistema”. Ele documenta que o ransomware encerra serviços associados a backups, segurança, bancos de dados, comunicações, compartilhamento de arquivos e sites. Ele também exclui cópias de sombra e desliga e criptografa remotamente máquinas virtuais. 

Se um invasor estiver deliberadamente visando os sistemas, identidades e infraestrutura de que uma organização pode precisar para se recuperar, o problema vai além da proteção de dados, abrangendo a resiliência cibernética e a Recovery cibernética. 

Onde entra o ResOps (Operações de Resiliência)

ResOps não é apenas outro nome para backup. É uma disciplina operacional que reúne segurança, TI, infraestrutura, aplicativos, operações e os negócios em torno de um único resultado: manter os serviços críticos em funcionamento e recuperá-los dentro do prazo que a empresa pode tolerar.

O comunicado da Medusa nunca usa a palavra ResOps, mas o conceito está presente. Ela recomenda que as organizações exercitem, testem e validem seus programas de segurança em relação aos comportamentos observados de invasores, alinhem as tecnologias de segurança às técnicas de ataque, testem-nas em escala, meçam o desempenho e ajustem pessoas, processos e tecnologias com base nas evidências.

Um backup não prova que esteja livre de ameaças. Um objetivo de tempo de recuperação em uma planilha não prova que a empresa estará operando dentro desse prazo. A resiliência precisa passar da suposição para a evidência. 

Comece pelo negócio, não pelo servidor

A inclusão do HHS no comunicado torna isso especialmente relevante para a área da saúde, um setor que, segundo o FBI, tem sido alvo frequente do Medusa. A discussão sobre Recovery começa com três perguntas: 

• O que precisa continuar funcionando e como seria uma operação mínima viável? 

• Quais identidades, aplicativos, infraestrutura e dados dão suporte a esses serviços? 

• Em quais pontos de Recovery podemos confiar, e o que volta a funcionar primeiro? 

Em um hospital, deixar qualquer uma dessas perguntas sem resposta pode significar um atraso na cirurgia, um farmacêutico que não consegue verificar uma dosagem ou um sistema de diagnóstico no qual um médico não pode confiar. Nenhuma equipe consegue responder a todas essas perguntas sozinha, e é essa lacuna que o ResOps foi projetado para preencher. 

Use o Medusa para testar suas suposições

Use o Medusa como um caso de teste para suposições de Recovery. Um invasor pode acessar os sistemas que dão suporte à Recovery? O que acontece se o Active Directory for comprometido? Você consegue identificar um ponto de Recovery seguro, restaurar serviços críticos na ordem correta e comprovar quanto tempo isso levará? 

Os agentes de ameaças se adaptam quando os defensores se adaptam. Os programas de resiliência precisam funcionar da mesma maneira: continuamente testados, continuamente validados e continuamente aprimorados.

Porque o meio de um incidente é um péssimo momento para descobrir que o plano de recuperação parecia melhor no papel do que funciona na prática. 

Perguntas frequentes

P: O que é o ransomware Medusa? 

R: O Medusa é uma operação de ransomware como serviço identificada pela primeira vez em 2021. Seus desenvolvedores e afiliados utilizam um modelo de dupla extorsão, criptografando sistemas e ameaçando publicar os dados roubados caso o resgate não seja pago. 

P: Por que o comunicado federal sobre o Medusa foi atualizado? 

R: A atualização de agosto de 2026 incorpora conclusões de investigações do FBI tão recentes quanto abril de 2026. Ela amplia as táticas, técnicas, procedimentos, vulnerabilidades exploradas, atividades dos afiliados e indicadores de comprometimento já documentados, além de acrescentar informações do HHS sobre ataques contra o setor de saúde. 

P: Como o Medusa ameaça as capacidades de Recovery de uma organização? 

R: O Medusa pode interromper serviços associados a backups, segurança, bancos de dados, comunicações e outras funções críticas. Ele também pode excluir cópias de sombra, alterar políticas relacionadas à identidade e desligar ou criptografar máquinas virtuais, colocando em risco o próprio processo de recuperação. 

P: O que as organizações devem fazer para ajudar a reduzir o risco do Medusa? 

R: As organizações devem corrigir vulnerabilidades conhecidas imediatamente, segmentar redes, restringir o acesso a serviços remotos, fortalecer a autenticação, monitorar movimentos laterais e aplicar o princípio do privilégio mínimo. Elas também devem manter cópias de recuperação separadas, offline, criptografadas e imutáveis, além de testar regularmente os fluxos de trabalho de restauração. 

P: O que é ResOps e em que difere do backup? 

R: ResOps, ou operações de resiliência, é uma disciplina operacional multifuncional — não um produto de backup. Ela alinha segurança, TI, infraestrutura, aplicativos, operações, continuidade de negócios e responsáveis de negócios em torno da restauração de serviços críticos dentro do nível de interrupção que a empresa pode tolerar. 

P: Como uma organização pode ajudar a comprovar que está pronta para a recuperação? 

R: Comece pelos serviços críticos de negócios, mapeie as identidades, os aplicativos, a infraestrutura, os dados, as pessoas e os terceiros dos quais eles dependem e defina o que constitui uma recuperação bem-sucedida. Em seguida, realize exercícios realistas que identifiquem pontos de recuperação válidos, restaurem os serviços na ordem correta, meçam o tempo real de recuperação e transformem quaisquer lacunas em uma lista de melhorias a serem implementadas. Chris Bevil é gerente principal de marketing de portfólio na Commvault. 

Key Takeaways 

• Roughly 1,200 supposedly isolated agents communicated through an unauthorized message board, and about 700 participated in Hugging Face-related activity. 
• Agents exchanged over 70,000 messages and files, combining discoveries across sessions meant to remain separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

The forensic reports are finally here, and they changed the way I think about this incident. 

About a month ago, I wrote about the OpenAI and Hugging Face security incident because I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.  

At the time, the story sounded fairly straightforward: An AI agent found a way outside the environment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

The Story Is Bigger Than One Rogue Agent 

The forensic reports reveal that about 1,200 agents, supposed to be operating in isolation, discovered a way to communicate through an unauthorized message board. They exchanged more than 70,000 messages and files, and roughly 700 agents participated in activity associated with Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.  

Among the new details: GPT-5.6 Sol agents reproduced an exploit and copied private evaluation data into a public Hugging Face dataset, a concrete escalation beyond what initial reports described. 

The Reward-Hacking Problem 

The independent investigation conducted by METR and Redwood Research, published alongside OpenAI’s own report on August 26, found that agents researched ways to spoof, edit or delete portions of their own evaluation transcripts because they incorrectly believed the grader would inspect how they completed the task. Researchers found successful tool-call spoofing in about 7% of the transcripts they evaluated, though the manipulation they observed was small-scale. 

The finding is not that agents are “deceptive” in a human sense. It is that a sufficiently capable agent can search for ways around controls when those controls stand between it and the outcome it has been optimized to achieve. 

OpenAI calls the incident a “warning shot.” I think that is a fair description. 

What Happens When Containment Fails 

Most of the conversation about this incident will rightly focus on alignment, sandboxing and monitoring. But there’s a resilience question underneath it: If 700 agents can find a side door around containment, what’s the plan for when a single compromised workload does the same in your environment? 

OpenAI’s own conclusion points at the answer: Security architecture should assume an individual workload or compute node eventually can be compromised. That means air-gapped, immutable recovery data, and a way to validate what you’re restoring before it touches production again. 

But immutability alone does not prove the data was clean when it was captured. If the data was already compromised at the time of capture, immutability preserves the compromise just as faithfully as it preserves anything else. 

The practical version of that question is simple to ask and hard to answer: If this happened to us, could we prove which recovery point predates the compromise? 

We cover this operating model under ResOps (resilience operations) on the Readiverse. 

The Lesson for Every Organization 

OpenAI has since tightened workload and network isolation, expanded monitoring, and revised its model-development practices. The lesson applies beyond OpenAI: Contain the impact, preserve what you can trust, and prove you can recover before you need to. 

FAQs 

Q: What was the OpenAI-Hugging Face incident? 

During internal cybersecurity evaluations, OpenAI agents bypassed controls intended to isolate them, accessed the internet and reached third-party systems, including Hugging Face. The activity was driven primarily by an internal research model operating with reduced safeguards. 

Q: How did supposedly isolated agents communicate? 

A: They discovered an unauthorized message board in shared infrastructure. About 1,200 agents used it to exchange more than 70,000 messages and files, allowing information and tactics to carry across sessions that were designed to remain independent. 

Q: Were the agents instructed to attack Hugging Face? 

A: No. They were attempting to complete a difficult cybersecurity benchmark. When the intended route appeared blocked, some agents searched for alternative ways to achieve the evaluated outcome, and that activity expanded beyond the environment’s intended boundaries. 

Q: What does “reward hacking” mean in this context? 

A: Reward hacking occurs when an agent finds an unintended way to satisfy a metric or obtain a desired result without completing the task as intended. Investigators found agents researching ways to spoof tool calls and alter or delete portions of evaluation transcripts because they believed the grader might inspect their process. 

Q: Why are immutable backups not enough on their own? 

A: Immutability prevents stored data from being altered, but it does not prove the data was clean when it was captured. If a backup already contains compromised data, immutability preserves that compromise. Organizations therefore need isolated copies, trustworthy recovery points and validation before restoration. 

Q: What should organizations do differently after this incident? 

A: Strengthen workload and network isolation, restrict unnecessary internet and credential access, monitor agent behavior and escalation signals, and assume that prevention may fail. Pair those controls with air-gapped, immutable recovery data and a tested process for identifying and validating a clean recovery point. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Pontos principais

• A validade dos certificados diminuirá de 398 para 47 dias até março de 2029, com a “reutilização da validação de domínio” reduzida para apenas 10 dias, tornando a renovação manual obsoleta e necessitando do Gerenciamento Automático do Ciclo de Vida do Certificado (CLM).
• Operações do tipo “Harvest Now, Decrypt Later” (Colete agora, descriptografe depois) já estão em andamento para armazenar dados com longa validade para futura descriptografia usando computadores quânticos, o que significa que há uma ameaça imediata aos dados criptografados e confidenciais que têm retenção de longo prazo.
• O inventário de certificados e criptografia é fundamental para as empresas começarem a construir agora, já que um inventário contínuo e automatizado é o primeiro passo rumo à resiliência cibernética de longo prazo e à agilidade criptográfica.

O problema oculto nos bastidores

A maioria das redes corporativas modernas depende de uma camada oculta composta por certificados digitais e criptografia que a maioria das pessoas nunca vê. Essa camada verifica a confiabilidade das máquinas e protege os fluxos de dados, mas, com as identidades de máquinas agora superando as identidades humanas em uma proporção de mais de 80 para 1 na empresa média, de acordo com a pesquisa sobre identidade de máquinas da CyberArk, pode ser fácil subestimar a importância da camada criptográfica e de certificados.

Uma maneira útil de pensar sobre um certificado digital é considerá-lo um crachá de identificação para uma máquina. Se o crachá for válido, as portas se abrem automaticamente e ninguém pensa nisso, mas no momento em que o crachá expira ou está mal configurado, a porta para de abrir, independentemente de quão legítima seja a máquina por trás dela. Um único certificado expirado pode derrubar sites, interromper as APIs que permitem que os aplicativos se comuniquem entre si, interromper transações e gerar violações de conformidade, tudo isso enquanto corrói a confiança do usuário.

Durante anos, as organizações gerenciaram certificados manualmente, mas duas mudanças tornarão impossível continuar fazendo isso manualmente. Primeiro, a validade máxima dos certificados públicos de Transport Layer Security (TLS) — o protocolo que protege seu navegador — está sendo reduzida para apenas 47 dias até 2029. Segundo, a eventual chegada de computadores quânticos poderosos o suficiente para quebrar a criptografia atual está forçando uma transição para a criptografia pós-quântica. Essas duas questões apontam para a mesma solução: uma abordagem governada, automatizada e criptograficamente ágil para o gerenciamento do ciclo de vida dos certificados (CLM).

O roteiro por trás da redução da validade dos certificados

A janela operacional para certificados TLS públicos vem se estreitando há uma década. No início de 2023, o Google publicou pela primeira vez seu roteiro “Moving Forward, Together” (Avançando, Juntos), que propunha reduzir a validade dos certificados de 398 dias para 90 dias, na esperança de impulsionar o setor rumo à automação. A Apple acelerou esse cronograma em outubro de 2024 ao apresentar uma proposta preliminar ao CA/Browser Forum, o órgão do setor onde autoridades certificadoras e fabricantes de navegadores estabelecem regras comuns. A proposta da Apple, endossada pela Sectigo, pelo Google Chrome e pela Mozilla, foi aprovada em abril de 2025 como a Proposta SC-081v3.

Essa redução ocorre em fases. O prazo máximo anterior de 398 dias já caiu para 200 dias em março de 2026, com o máximo sendo reduzido para 100 dias em março de 2027 e, finalmente, para 47 dias em março de 2029. Na prática, uma organização que atualmente renova cada certificado cerca de uma vez por ano passará em breve a renovar todos os certificados aproximadamente a cada mês e meio; na fase final, qualquer processo que dependa de uma pessoa solicitar e instalar certificados manualmente deixará de funcionar.

Os fabricantes de navegadores estão promovendo esses prazos de validade mais curtos para forçar a automação, o que elimina o erro humano que, em primeiro lugar, causa a maioria das interrupções nos certificados. Eles também permitem que toda a web adote novos padrões criptográficos em semanas, em vez de anos, já que os certificados antigos são descartados rapidamente. Além disso, ajudam a reduzir a dependência de sistemas de revogação legados, que apresentam problemas de desempenho e privacidade. Por fim, caso um registro de Transparência de Certificados (um registro público dos certificados emitidos) seja desqualificado, os certificados de curta duração reduzem drasticamente o número de registros que precisam ser substituídos em curto prazo.

O desafio da validação

Embora o limite de 47 dias ganhe destaque nas manchetes e chame a atenção, a mudança mais disruptiva talvez seja o que acontecerá com a Validação de Controle de Domínio (DCV). A DCV é o processo de comprovar a uma Autoridade Certificadora (CA) que você controla o domínio para o qual está solicitando um certificado. Historicamente, uma vez que uma organização comprovasse a propriedade, a CA podia reutilizar essa comprovação por até 398 dias; porém, de acordo com a norma SC-081v3, o prazo de reutilização se reduz para 200 dias em 2026 e para apenas 10 dias até março de 2029.

Isso cria um verdadeiro desequilíbrio, pois mesmo uma organização que automatize totalmente a instalação de certificados ficará paralisada se não puder comprovar novamente a propriedade do domínio a cada 10 dias. Qualquer atraso na validação interrompe todo o fluxo de emissão e leva diretamente a interrupções no serviço.

A solução prática para esse problema é adotar o protocolo ACME (Automatic Certificate Management Environment) com validação automatizada via API DNS-01, de modo que a comprovação da propriedade ocorra programaticamente, em vez de depender de uma pessoa.

A ameaça quântica e o cronograma

Enquanto a validade dos certificados diminui, os algoritmos dentro desses certificados enfrentam uma ameaça quântica. A Infraestrutura de Chave Pública (PKI) tradicional depende da criptografia assimétrica para proteger assinaturas digitais, trocas de chaves e conexões TLS. Um computador quântico suficientemente potente, executando o algoritmo de Shor, poderia quebrar esses sistemas completamente. Esperar até que a computação quântica seja poderosa o suficiente para descriptografar não é uma opção viável; como escreveu Vidya Shankaran, CTO de Campo da Commvault: “a data exata do Q-Day pode permanecer incerta. A direção em que estamos caminhando, porém, não é.”

Estimativas apontam que o Q-Day — o momento em que um computador quântico poderá quebrar a criptografia de chave pública — ocorrerá em algum momento nos próximos 5 a 10 anos. No entanto, seria um erro tratar isso como um problema futuro. Os agentes mal-intencionados já estão conduzindo operações do tipo “Colher Agora, Descriptografar Depois” (HNDL), interceptando e armazenando tráfego criptografado hoje com a intenção de descriptografá-lo assim que a computação quântica amadurecer. Dados que devem permanecer confidenciais por anos, como registros de saúde, propriedade intelectual e informações financeiras, ficam efetivamente expostos no momento em que são coletados.

O Governo Federal dos EUA reagiu de forma adequada: em junho de 2026, a Casa Branca emitiu a Ordem Executiva 14412, intitulada “Protegendo a Nação contra Ataques Criptográficos Avançados”, que estabelece prazos bem antes da meta original do NIST para 2035: os sistemas federais de alto valor devem adotar o estabelecimento de chaves pós-quânticas até o final de 2030 e assinaturas digitais pós-quânticas até o final de 2031.

Apesar dessa urgência, o progresso efetivo em direção à criptoagilidade em nível corporativo tem sido lento. O relatório “DigiCert Quantum Readiness Outlook” constatou que mais da metade das organizações pesquisadas espera que a criptografia assimétrica clássica seja quebrada dentro de cinco anos; no entanto, apenas 7% implantaram criptografia quântica segura ou híbrida em seus conjuntos de certificados, e o nível geral de Readiness melhorou em apenas 2 pontos percentuais no último ano.

Por que a agilidade criptográfica é importante?

A ponte mais prática entre a criptografia clássica e a pós-quântica é o certificado composto híbrido, que combina um algoritmo clássico (RSA ou ECC) com um algoritmo pós-quântico (ML-DSA, o esquema padronizado de assinatura baseado em rede) dentro de um único certificado X.509. A combinação de ambos em um único certificado foi projetada para que o certificado permaneça válido enquanto qualquer um dos algoritmos for seguro, o que é essencial, já que os algoritmos pós-quânticos são novos e ainda não resistiram a inúmeras tentativas de ataque como o RSA resistiu.

No entanto, as chaves e assinaturas pós-quânticas têm vários kilobytes, em vez de algumas centenas de bytes, o que aumenta a latência da rede, acarreta riscos de fragmentação de pacotes durante o handshake TLS e adiciona sobrecarga computacional que pode exigir atualizações de hardware para dispositivos com recursos limitados. É exatamente por isso que a agilidade criptográfica é importante; as organizações precisam da capacidade de testar, implantar e alternar algoritmos sem precisar reestruturar sua infraestrutura subjacente toda vez que os padrões evoluem.

Gerenciamento automatizado do ciclo de vida de certificados

O gerenciamento manual de certificados não é apenas ineficiente; é um verdadeiro risco operacional. Quando os certificados ficam escondidos em planilhas, as organizações perdem visibilidade, e o resultado são credenciais vencidas, tamanhos de chave fracos, algoritmos de assinatura desatualizados e configurações não conformes que ninguém percebe até que algo dê errado. As interrupções resultantes podem confundir os usuários, prejudicar a receita e recair sobre a equipe menos preparada para explicá-las.

Uma plataforma completa de CLM lida com isso ao longo de todo o ciclo de vida de um certificado:

• Descoberta: varredura contínua de ambientes em nuvem, data centers, contêineres e domínios externos para localizar todos os certificados em uso.
• Monitoramento: acompanhamento em tempo real de datas de validade, algoritmos, força das chaves e conformidade com a política de segurança.
• Validação: utilização de integração direta por API com CAs públicas e privadas, ao mesmo tempo em que automatiza a validação e as aprovações de domínios
• Instalação: implantação programática de certificados e chaves renovados por meio do ACME ou de APIs seguras, sem intervenções manuais.
• Revogação: é necessário executar uma revogação rápida e orientada por políticas para que um certificado comprometido possa ser substituído ou revogado em todos os lugares de uma só vez, em vez de ser procurado máquina por máquina.

Há também um benefício oculto na etapa de descoberta: o inventário de certificados mantido por uma plataforma CLM é, na verdade, o início do inventário criptográfico exigido pelo planejamento de migração pós-quântica, o que pode transformar uma tarefa de conformidade em uma vantagem inicial.

Identidades não humanas e IA autônoma

O problema de escala é agravado pela forma como as aplicações modernas são construídas. Contêineres, pods do Kubernetes, máquinas virtuais, dispositivos da Internet das Coisas (IoT) e APIs precisam, todos, de suas próprias credenciais, e muitas dessas cargas de trabalho existem por apenas alguns minutos ou horas antes de serem encerradas. Nenhuma equipe humana consegue emitir e retirar certificados nessa velocidade.

Para acompanhar esse ritmo alucinante, agentes de IA podem ser utilizados para descobrir, emitir, renovar e gerenciar certificados de forma autônoma, mantendo-se dentro das restrições existentes, como políticas de segurança, controle de acesso baseado em função (RBAC) e trilhas de auditoria centralizadas. O resultado é a automação na velocidade das máquinas, sem abrir mão da governança corporativa.

Por onde começar

1. O primeiro passo rumo à agilidade e resiliência criptográficas em toda a empresa é organizacional, e não técnico. Seguindo as orientações do NIST, as empresas devem estabelecer uma equipe central de serviços de identidade de máquinas que seja responsável pela plataforma CLM, padronize modelos de certificados e mantenha integrações com CAs públicas e privadas. Os proprietários de aplicativos individuais e as equipes de DevOps, por sua vez, devem ser responsáveis por integrar as renovações automatizadas em seus próprios pipelines de implantação, utilizando a plataforma central como um serviço compartilhado. Essa divisão mantém a governança consistente ao mesmo tempo em que elimina as transferências manuais que causam interrupções.
2. As organizações devem substituir as técnicas e os fluxos de trabalho de validação manuais pelo ACME e pela validação automatizada DNS-01 agora, bem antes que a janela de 10 dias para a DCV chegue, ao mesmo tempo em que descontinuam todos os processos manuais de renovação e validação ao longo do caminho.
3. 1. 1. Paralelamente, as organizações devem realizar um inventário completo de seus ativos criptográficos para identificar chaves codificadas, algoritmos legados e caminhos de confiança de longa duração que protegem dados confidenciais.
      2. A preparação pós-quântica deve começar em um ambiente controlado, e não em produção. Um laboratório de testes dedicado deve ser estabelecido para permitir que as equipes testem certificados compostos híbridos e atualizações cripto-ágeis em um ambiente de teste. Ao desenvolver aplicativos em bibliotecas criptográficas modulares conectadas a uma plataforma CLM dinâmica, as empresas podem obter verdadeira cripto-agilidade: a capacidade de alternar chaves, cifras e algoritmos em toda a sua infraestrutura à medida que os padrões mudam, sem a necessidade de reconstrução.

O fio condutor que une todas as recomendações é o inventário. A etapa de descoberta de uma plataforma CLM não é um trabalho repetitivo antes da solução real; é a mesma disciplina de que as organizações precisarão em todas as camadas da Readiness para a era quântica. Certificados são identidades não humanas, e as mesmas perguntas se aplicam a contas de serviço, agentes de IA, dependências de código aberto e aos algoritmos embutidos no código das aplicações: o que temos, o que isso protege e o que é mais importante para os negócios?

As organizações que desenvolverem essa capacidade de inventário agora, começando pelos certificados, acharão o restante da transição muito menos assustador, pois a priorização se torna um cálculo, em vez de um palpite. Tratar os próximos anos como uma janela de planejamento, em vez de um período de carência, ajudará as organizações a fazer essa transição em seus próprios termos, em vez de deixar que uma interrupção tome a decisão por elas.

Caitlin Dodson é estagiária do verão de 2026 na FCTO – Américas, na Commvault.

Pontos principais

• Substitua afirmações subjetivas sobre “facilidade de uso” por um índice mensurável de proteção de dados: capacidade protegida dividida pelo número de administradores em tempo integral.
• A medição da capacidade protegida por ETI oferece uma visão mais significativa da eficiência operacional do que métricas tradicionais, como o número de tarefas de backup por administrador.
• O índice de proteção de dados deve ser usado como referência antes da migração de uma plataforma e medido novamente após a migração para validar as melhorias operacionais.
• Fatores como ambientes multicloud, requisitos de Recovery cibernética e obrigações de conformidade podem influenciar o índice, portanto, ele deve ser avaliado dentro do contexto de cada ambiente.
• As organizações devem solicitar que os fornecedores se comprometam com resultados operacionais mensuráveis, em vez de confiar em alegações qualitativas sobre simplicidade.

Todas as avaliações de fornecedores das quais participei acabam chegando ao mesmo beco sem saída. Um lado diz que a plataforma é simples de operar. O outro lado diz que a plataforma deles é mais simples.

Ninguém consegue provar nenhuma das duas alegações, então a conversa se desvia para a demonstração, a ligação de referência, a intuição no ambiente. Não é assim que você deve tomar uma decisão que determinará como sua equipe passará os próximos cinco anos.

Já administrei ambientes de proteção de dados em produção. Vi equipes ficarem sobrecarregadas com ferramentas fragmentadas que prometiam automação e, em vez disso, geravam tickets.

“Complexidade reduzida” não é uma sensação na qual você deva acreditar cegamente. É algo que você deve ser capaz de calcular.

A métrica que faltava ao setor

Começamos a usar um índice simples internamente e com os clientes: a capacidade total protegida dividida pelo número de funcionários em tempo integral necessários para operá-la. Chamamos isso de índice de alavancagem da proteção de dados.

Capacidade Protegida (PB) / FTEs = Índice de Alavancagem da Proteção de Dados

É isso. Sem perguntas de pesquisa sobre satisfação. Sem adjetivos. Um número, calculado a partir de dados que você já possui.

Veja por que isso é mais importante do que as métricas que substitui. Calcular o número de tarefas de backup por pessoa fazia sentido há uma década, quando uma tarefa representava uma unidade discreta de esforço manual. Isso não reflete como as plataformas modernas operam hoje, em que a automação absorve o trabalho rotineiro e um único administrador pode ser responsável por petabytes, e não pelo número de tarefas.

Medir tarefas por pessoa em um ambiente automatizado não diz nada sobre se a automação está realmente funcionando.

Como isso funciona na prática

Um esclarecimento antes do número, pois isso costuma confundir as pessoas. Capacidade protegida significa o tamanho total, não compactado e não desduplicado, dos aplicativos que estão sendo protegidos, e não o disco físico por trás deles.

Essa distinção é importante porque é o ponto principal. O próprio ambiente de produção da Commvault protege 42,39 PB de dados de aplicativos em 9,26 PB de disco físico, o que representa uma economia de espaço de 81,91% graças à deduplicação e à compactação.

A proporção não é apenas uma medida de quantos petabytes uma pessoa pode supervisionar. É uma medida de quanto a arquitetura está fazendo o trabalho antes mesmo que o número de funcionários entre em cena.

Com isso em mente: a Commvault opera seu próprio ambiente de backup de produção com 42,39 PB de capacidade protegida utilizando apenas dois FTEs. Isso representa uma relação de 21,20 PB por FTE. Os benchmarks do setor para plataformas modernas geralmente variam entre 5 e 25 PB por FTE, dependendo da complexidade do ambiente; portanto, esse número está na faixa mais alta do que é possível alcançar atualmente.

Índice de alavancagem da proteção de dados = 42,39 PB / 2 FTEs = 21,20 PB por FTE

Quero ser direto sobre o que esse número não representa. Ele não leva em conta uma infraestrutura multicloud, requisitos de recuperação cibernética ou um mix de aplicativos com alta exigência de conformidade — fatores que reduzirão o índice por razões que nada têm a ver com a qualidade da plataforma.

Um índice isoladamente não é um veredicto. Um índice medido antes e depois de uma migração, sim.

Esse é o caso de uso real. Estabeleça uma linha de base para seu ambiente atual com suas ferramentas atuais. Defina um índice-alvo com base em suas projeções de crescimento e na capacidade de sua equipe. Em seguida, exija que seu fornecedor cumpra essa meta após a conclusão da implementação, não apenas durante o ciclo de vendas.

A implicação no nível da diretoria

Se você é quem aprova a migração para uma nova plataforma, não estão apenas pedindo que confie que a nova plataforma seja mais fácil de operar. Estão pedindo que você invista em um resultado operacional específico. Uma meta de índice de proteção de dados oferece uma maneira de incluir esse resultado no caso de negócios e verificá-lo 12 meses depois.

Essa é a mesma disciplina que aplicamos ao tempo médio de recuperação limpa (MTCR). A capacidade de recuperação não é algo que se alega, é algo que se mede e se remedeia até que o número revele a verdade. A eficiência operacional merece o mesmo padrão.

O Desafio

Peça ao seu fornecedor atual o índice de alavancagem do seu próprio ambiente hoje. Se ele não puder fornecê-lo, isso diz algo sobre o quanto ele entende o que “fácil de gerenciar” significa para sua equipe.

E se você estiver avaliando uma nova plataforma, não aceite “mais fácil de usar” como resposta. Pergunte a qual índice eles se comprometerão e pergunte novamente após o primeiro ano.

Perguntas frequentes

P: O que é o índice de alavancagem de proteção de dados?

R: A relação de proteção de dados mede a quantidade de capacidade de dados protegidos gerenciada por cada administrador em tempo integral. Ela oferece uma maneira objetiva de avaliar a eficiência operacional, em vez de depender de impressões subjetivas sobre a usabilidade da plataforma.

P: Por que essa métrica é mais útil do que o número de tarefas de backup por administrador?

R: As plataformas modernas de proteção de dados automatizam grande parte do trabalho rotineiro que antes exigia esforço manual. Como resultado, contar as tarefas de backup não reflete mais a verdadeira carga de trabalho nem a eficiência de uma equipe de operações.

P: O que significa “capacidade protegida” nesse cálculo?

R: A capacidade protegida refere-se ao tamanho total, sem compressão e sem deduplicação, dos dados de aplicativos que estão sendo protegidos. Essa medida reflete a carga de trabalho real gerenciada pela plataforma, em vez do armazenamento físico consumido após a otimização.

P: Uma relação de alavancagem mais alta sempre indica uma plataforma melhor?

R: Não necessariamente. A complexidade do ambiente, incluindo implantações em múltiplas nuvens, requisitos de resiliência cibernética e obrigações regulatórias, pode reduzir a relação mesmo quando a plataforma apresenta bom desempenho. A métrica é mais valiosa ao comparar o mesmo ambiente antes e depois de uma migração.

P: Como as organizações devem utilizar a taxa de alavancagem de proteção de dados durante as avaliações de fornecedores?

R: As organizações devem estabelecer uma linha de base com base em seu ambiente atual, definir uma relação-alvo alinhada ao crescimento futuro e solicitar que os fornecedores se comprometam a alcançar melhorias mensuráveis após a implementação. Essa abordagem muda o foco da conversa de alegações de marketing para resultados comerciais verificáveis.

P: Qual é o valor comercial mais amplo dessa métrica?

R: O índice de alavancagem de proteção de dados permite que os executivos quantifiquem os ganhos esperados de eficiência operacional e os incluam na justificativa de investimento em uma plataforma. Ele também fornece uma referência que pode ser analisada após a implantação para confirmar se os resultados prometidos foram alcançados.

Rajiv Kottomtharayil é diretor de produtos da Commvault.