Pontos principais
- A Frontier AI está reduzindo os prazos para correção de vulnerabilidades; a prevenção por si só já não é mais suficiente para garantir a segurança.
- A pergunta que conselhos de administração, órgãos reguladores e seguradoras estão fazendo agora não é “Temos cópias de segurança?”, mas “Podemos provar que somos capazes de recuperar os dados sem erros?”.
- Backups não significam recuperação: uma cópia indica que os dados existem, mas não se eles estão em bom estado ou se podem ser restaurados.
- O Tempo Médio de Recuperação após a Limpeza (MTCR) deve se tornar um indicador medido continuamente e levado em conta pela diretoria – e não uma estimativa teórica.
- Um ambiente de recuperação isolado — sem conexão com a rede externa, imutável, reforçado e com identidades isoladas — é o padrão básico, e não um recurso avançado.
- O que é considerado “limpo” continuará mudando à medida que os modelos de IA se tornarem cada vez mais capazes de identificar vulnerabilidades que os seres humanos não conseguem prever.
Passei grande parte da minha carreira administrando sistemas de produção. Conheço os ambientes de backup por dentro, aqueles nos quais os clientes realmente confiam. Sei que os planos de recuperação são coisas que só revelam suas fraquezas quando algo já deu errado. Essa experiência muda a maneira como você pensa sobre a resiliência cibernética.
À primeira vista, Backup and Recovery parecem fáceis de gerenciar. Proteja os dados, armazene cópias, documente o manual de procedimentos, teste quando puder, restaure quando for necessário. Mas qualquer pessoa que já tenha operado esses ambientes em grande escala conhece a dura realidade: é na Recovery que as suposições são postas à prova. E, neste momento, muitas organizações estão operando com base em suposições que já não se aplicam mais. Durante anos, a segurança funcionou segundo uma sequência já conhecida: identificar a vulnerabilidade, corrigi-la, fortalecer o ambiente e monitorar as atividades. Esse modelo ainda é importante. Mas a janela de oportunidade da qual ele depende está se fechando.
A IA de ponta transformou a velocidade da descoberta de vulnerabilidades, da construção de caminhos de ataque e da geração de exploits. Modelos como o Claude Mythos e o GPT-5.5-Cyber já demonstraram como isso funciona, até o momento em testes controlados de acesso antecipado que ainda dependiam da expertise humana e apresentavam taxas significativas de falsos positivos, mas a trajetória é inconfundível. À medida que o acesso se amplia, essa mesma capacidade passa para as mãos dos invasores.
Em apenas um mês, a Palo Alto Networks divulgou 26 CVEs, representando 75 problemas subjacentes, após adotar modelos de IA de ponta para a análise de código, em comparação com seu volume habitual de menos de cinco CVEs por mês. Pesquisadores também estão alertando que a descoberta assistida por IA está reduzindo drasticamente as janelas de correção, com algumas explorações surgindo agora poucos minutos após a divulgação. Quando a janela de correção desaparece, a lógica da correção deixa de funcionar. A prevenção não pode arcar sozinha com todo o peso da Readiness.
A prevenção ainda é importante, mas não define mais a Readiness. Os clientes com quem converso não estão perguntando se precisam de mais controles. Eles já sabem que precisam. Estão perguntando se seus negócios podem se recuperar completamente quando esses controles falham, quando os invasores agem mais rápido do que os ciclos de correção ou quando a violação já está presente há mais tempo do que qualquer um imaginava.
Essa é agora a questão que conselhos de administração, órgãos reguladores e seguradoras estão levantando. Eles já foram além da pergunta “Temos cópias de segurança?” e passaram a se concentrar em algo mais relevante: “Podemos provar que somos capazes de recuperar os dados sem erros?” Essa evidência começa com uma distinção que a maioria das organizações ainda não compreende corretamente: backups não são sinônimo de recuperação.
Um backup indica que existe uma cópia. Ele não informa se os dados estão corretos, se as dependências dos aplicativos estão intactas, se os serviços de identidade podem ser restaurados com segurança ou se a sequência de recuperação ainda reflete o ambiente atual. Já analisei planos que pareciam completos até que alguém tentasse executá-los. O manual de procedimentos estava lá, mas desatualizado. A restauração funcionou, mas levou três vezes mais tempo do que o estimado. O sistema voltou a funcionar, mas os aplicativos a jusante não conseguiam se conectar. Nada disso é incomum. É exatamente o que os testes reais deveriam revelar. O problema é que a maioria das organizações descobre essas lacunas durante um incidente real. O indicador mais importante quando algo dá errado é a rapidez com que você consegue retornar a um estado comprovadamente estável. É por isso que o Tempo Médio para Recuperação Completa (MTCR) precisa se tornar um número levado em conta pela diretoria — não uma estimativa teórica em um plano, mas um tempo medido e validado.
O alvo em movimento: o que está seguro hoje pode não estar amanhã
Com os modelos da Frontier AI, a resposta sincera é a seguinte: não é possível garantir que todas as vulnerabilidades serão detectadas e corrigidas a tempo. Os invasores que utilizam esses mesmos modelos estão descobrindo e encadeando exploits mais rapidamente do que qualquer programa de correção consegue, de forma realista, acompanhar. Isso não é uma falha da sua equipe de segurança. É a nova dinâmica do cenário de ameaças.
O que você pode controlar é sua capacidade de recuperação. Isso significa um Ambiente de Recuperação Isolado – backups isolados da internet, inacessíveis a partir da rede de produção e protegidos contra o movimento lateral que caracteriza uma violação sofisticada. Significa imutabilidade e bloqueio de conformidade, de modo que nenhuma credencial, por mais privilegiada que seja, possa reduzir o tempo de retenção ou excluir dados fora de um processo autorizado. E significa ResOps na prática: não apenas fazer backup de dados, mas testar continuamente a Recovery, automatizar a validação de integridade e medir seu MTCR – o tempo validado para retornar a um estado conhecido como bom.
Mas eis a parte que a maioria das organizações ainda não está levando em conta: o que conta como “limpo” não é uma linha fixa. À medida que os modelos de IA se tornam mais capazes, eles encontrarão cada vez mais vulnerabilidades que a mente humana simplesmente não consegue antecipar, novas rotas de ataque, implantes dormentes e corrupções sutis incorporadas muito antes da detecção. Um ponto de recuperação considerado “limpo” pelos padrões atuais pode conter comprometimentos que a análise forense assistida por IA do futuro virá a revelar. Isso significa que sua definição de “limpo” deve evoluir continuamente. O MTCR não é um número que você define de uma vez por todas. É uma disciplina que você mantém, revisitando o que significa “limpo”, atualizando seus critérios de validação e tratando a resiliência como um padrão dinâmico, em vez de uma certificação que você obtém uma única vez.
Então, o que é um bom MTCR? Com base no que vi funcionar na prática, a meta mínima viável para toda a sua empresa — o menor conjunto de sistemas que permite que você continue operando, que defino com precisão a seguir — deve ser inferior a seis horas. Seis horas são alcançáveis com a arquitetura certa: um IRE pronto para ser executado, uma sequência de Recovery pré-validada e manuais de procedimentos que sejam executáveis, em vez de apenas legíveis. Se o seu MTCR atual é medido em dias, a lacuna está quase sempre em um desses três aspectos.
Quatro passos para manter a resiliência na era da IA de ponta
Aceitar que a prevenção por si só não é suficiente é o ponto de partida. A partir daí, o trabalho se torna específico. É nisso que recomendo que as organizações se concentrem.
1. Avalie seus riscos reais de recuperação.
A maioria das avaliações de risco de recuperação faz as perguntas erradas. “Existem backups?” não é a mesma coisa que “Conseguimos recuperar os dados sem problemas?”. As perguntas mais difíceis são: os sistemas críticos podem ser restaurados sem reintroduzir a ameaça? Os ambientes de recuperação estão isolados dos sistemas de produção comprometidos? Os planos de recuperação estão alinhados às dependências atuais — e não à arquitetura de dois anos atrás?
Em um ambiente de vulnerabilidades em rápida evolução, a lacuna entre “temos backups” e “podemos recuperar” é onde as organizações são prejudicadas. Avaliar essa lacuna com honestidade, antes que um incidente force a questão, é por onde o planejamento de resiliência deve começar. Essa avaliação precisa incluir uma análise de impacto nos negócios: quais sistemas têm uma janela de recuperação medida em minutos, quais em horas e quais podem esperar um dia. Sem essa classificação por níveis, todos os sistemas parecem igualmente urgentes durante um incidente, e nada é restaurado com rapidez suficiente.
2. Torne a recuperação isolada e o isolamento físico a regra — e não a exceção.
Se você ainda considera cópias isoladas e imutáveis como um recurso avançado, em vez de um requisito padrão, essa suposição não se sustenta mais. Quando o tempo de exploração se reduz a minutos, você precisa de opções alternativas que estejam estruturalmente separadas dos planos de identidade, rede e gerenciamento de produção — isoladas lógica ou fisicamente, imutáveis e sem nenhum caminho ativo de volta à produção que um invasor possa seguir.
O objetivo não é apenas a proteção contra a ameaça atual, mas também garantir opções confiáveis de recuperação caso uma vulnerabilidade que você ainda não tenha corrigido seja explorada. Isso já acontece hoje. Esteja preparado para isso. O isolamento só é válido se a infraestrutura ao seu redor for fortalecida. Isso significa uma infraestrutura de backup em sistemas operacionais fortificados, não em imagens genéricas, e, idealmente, em servidores físicos que resistam a um ataque na camada do hipervisor. Isso significa que as chaves de criptografia devem ser armazenadas fora da plataforma de backup, em um cofre externo com acesso “just-in-time” e sem dependência do Active Directory de produção. E significa tratar seu domínio de backup como um domínio de identidade separado: sem confiança no Active Directory de produção, autenticação multifatorial (MFA) obrigatória e autorização de várias pessoas para operações destrutivas. Nada disso é incomum; é a base para que seu ambiente se recupere em um ambiente não comprometido.
Igualmente importante é a questão de saber do que você está se recuperando. Dados do setor sobre resposta a incidentes indicam consistentemente que o tempo médio de permanência de uma violação está na faixa de semanas, não de dias. Isso significa que suas cópias de recuperação precisam remontar a um ponto suficientemente distante para encontrar um ponto genuinamente limpo, não apenas o backup de ontem. Sistemas críticos exigem múltiplas cópias geograficamente separadas, incluindo pelo menos uma cópia imutável e outra que esteja totalmente offline. A política de retenção não é uma decisão relacionada ao custo de armazenamento. É uma decisão de segurança.
3. Saiba quais são os sistemas sem os quais a empresa não pode funcionar – e recupere-os em primeiro lugar.
A maioria das organizações descobre sua sequência de recuperação durante um incidente. É por isso que as primeiras 24 a 48 horas não são dedicadas à restauração dos sistemas, mas sim a decidir o que é realmente importante. As organizações sabem que precisam restaurar as plataformas de identidade, os sistemas de cobrança, os bancos de dados operacionais e a infraestrutura central. O que muitas vezes ainda não foi mapeado é a ordem, as dependências entre esses sistemas e os aplicativos a jusante que não podem funcionar até que serviços específicos estejam de volta ao ar.
Isso se torna mais complexo à medida que a IA passa a fazer parte das operações comerciais. Pipelines de dados, repositórios de modelos, bancos de dados vetoriais, fluxos de trabalho baseados em agentes — esses elementos são agora dependências operacionais, e não apenas infraestrutura técnica. Se seu plano de Recovery não levar isso em conta, suas estimativas de tempo de Recovery provavelmente estarão erradas. Definir o que significa operar como uma empresa minimamente viável (o menor conjunto de sistemas necessário para manter os negócios em funcionamento) e construir a Recovery com base nessa definição não é um exercício teórico. É a resposta prática à pergunta que toda equipe executiva fará durante um incidente: O que devemos restaurar primeiro?
Na minha experiência ajudando clientes durante incidentes ativos, as primeiras 12 horas respondem a essa pergunta, quer você tenha se planejado para isso ou não – o que for recuperado nesse intervalo torna-se, por padrão, seu MVC. As organizações que se recuperam mais rapidamente decidiram com antecedência: elas sabiam exatamente quais sistemas precisavam estar de volta em 12 horas e haviam validado que poderiam fazer isso. Se o seu MVC não couber em 12 horas, ele não é o seu MVC, é uma lista de desejos. O trabalho consiste em continuar reduzindo até que o que restar possa ser realisticamente restaurado nesse intervalo e, então, testá-lo até que você possa comprovar isso.
4. Automatize a resiliência e realize testes continuamente — e não apenas de acordo com um cronograma fixo.
Um plano de recuperação que se limita a um documento e é revisado anualmente não constitui capacidade de recuperação. Trata-se de uma hipótese que nunca foi testada na prática. O problema com os testes baseados em calendário é o que fica de fora entre os ciclos. Os ambientes mudam constantemente: novas cargas de trabalho, dependências atualizadas, infraestrutura que se desviou do que o manual de operações descreve. Quando o teste anual é executado, ele está validando um instantâneo de um ambiente que já não existe. Em um cenário de ameaças em que a exploração pode ocorrer poucos minutos após a divulgação, esse atraso é inaceitável. A verificação de ameaças, a identificação de pontos de recuperação limpos, a restauração levando em conta as dependências e a orquestração da recuperação precisam ser automatizadas e executadas continuamente. Não porque a automação seja uma prática recomendada, mas porque a alternativa manual não consegue acompanhar o ritmo acelerado em que as coisas acontecem atualmente. Os testes contínuos também dependem da detecção contínua. Os testes contínuos também dependem da detecção contínua. Não é possível selecionar um ponto de recuperação seguro se você não souber quando a invasão começou. É por isso que a detecção de ameaças, a varredura de anomalias nos dados de backup e a análise do ponto de recuperação precisam se complementar: a detecção indica quais cópias são anteriores à invasão, e essa determinação define a partir de qual ponto você realmente fará a recuperação. Sem essa conexão, você estará restaurando para uma data que espera que seja segura, em vez de uma que tenha sido verificada; e, em um cenário de ameaças de IA de ponta, a esperança não é uma estratégia de recuperação.
O que os testes contínuos revelam é diferente do que os testes anuais detectam. Os testes programados tendem a confirmar que o plano funciona em condições controladas. Os testes contínuos identificam a dependência que sofreu alterações no mês passado, a sequência de recuperação que falha quando uma carga de trabalho específica é adicionada e o serviço de identidade cuja restauração leva o dobro do tempo previsto na estimativa. Essas são as falhas que fazem a diferença durante um evento real, e a única maneira de identificá-las antes que ocorra um incidente é realizar testes constantemente.
Os testes também precisam ocorrer no ambiente correto. Um teste de recuperação executado na infraestrutura de produção não indica se você conseguirá se recuperar quando a produção estiver comprometida. Os testes em ambiente isolado — que validam a restauração em um ambiente totalmente isolado, sem conectividade com a produção — são a maneira de confirmar se suas cópias de backup são realmente utilizáveis em condições de incidente. Isso inclui a recuperação de serviços de identidade, gerenciamento de chaves externas e aplicativos de Nível 0 de forma isolada, com contas de emergência dedicadas que existem fora do seu diretório normal.
O que torna os testes diários viáveis é a “validação de restauração”, um tipo de recuperação que simula todo o caminho de restauração para cada ativo crítico sem afetar o ambiente de produção. Sua plataforma de backup deve oferecer suporte a isso de forma nativa; se ela não for capaz de executar diariamente um teste de recuperabilidade automatizado e sem interrupções em todo o seu MVC, você não saberá, na verdade, se seus backups funcionam. Na Commvault, essa restauração é realizada em seus grupos de ativos críticos, com relatórios automatizados sobre o status de recuperação de cada sistema protegido.
O mesmo se aplica aos seus manuais de procedimentos. Um manual de procedimentos que fica em um documento do Word ou PDF é um manual de referência, não uma ferramenta operacional — ele pressupõe que alguém tenha tempo, clareza e acesso para lê-lo sob pressão. Os verdadeiros manuais de procedimentos são scripts digitais que executam a sequência de Recovery e validam cada etapa, confirmando que o aplicativo realmente funciona antes de prosseguir: não “o serviço foi iniciado”, mas “o aplicativo respondeu corretamente a uma transação sintética”. Os Runbooks Commvault Cleanroom foram criados para isso — fluxos de trabalho executáveis que conduzem uma recuperação de ponta a ponta em um ambiente isolado, sem que um ser humano precise interpretar um documento a cada etapa.
Um último ponto que raramente é incluído nos planos de recuperação até que seja tarde demais: durante um incidente grave, sua própria infraestrutura de comunicações corporativas pode estar comprometida ou indisponível. E-mail, Teams e Slack funcionam na mesma infraestrutura que os invasores têm como alvo. Saiba com antecedência quais canais alternativos sua equipe usará para se coordenar e certifique-se de que esses canais sejam testados juntamente com seus procedimentos técnicos de Recovery. Saiba mais com Bill O’Connell, diretor de segurança da Commvault, sobre as quatro etapas essenciais para a resiliência na era da IA.
A resiliência é uma disciplina operacional, não um projeto
As organizações que resistirão às ameaças de ponta aceleradas pela IA são aquelas que tratam a resiliência como uma disciplina operacional — MTCR mensurado, validação contínua e uma capacidade de recuperação comprovada, e não apenas presumida. O problema não é que os ataques estejam ficando mais rápidos. É que a recuperação ainda não conseguiu acompanhar esse ritmo e, até que isso aconteça, a equação não bate.
Perguntas frequentes
P: O que é o Tempo Médio para Recuperação Limpa (MTCR) e por que ele é importante?
R: O MTCR mede a rapidez com que uma organização pode retornar a um estado verificado e comprovadamente íntegro após um ataque cibernético — não apenas restaurar dados, mas confirmar que eles estão limpos e que as dependências das aplicações estão intactas. Deve ser uma métrica no nível da diretoria, com um tempo medido e validado, e não uma estimativa teórica enterrada em um plano de Recovery. A meta para um MVC bem arquitetado — abrangendo todos os sistemas de identidade, aplicativos críticos e Readiness do ambiente isolado — é inferior a seis horas.
P: O que é um Ambiente Isolado de Recovery e como ele difere de um backup padrão?
R: O Ambiente Isolado de Recovery (IRE) é uma cópia imutável e completamente isolada dos dados críticos, estruturalmente separada das redes de produção, dos sistemas de identidade e dos planos de gerenciamento. Um backup padrão indica que existe uma cópia. Um IRE indica que a cópia está protegida contra o mesmo ataque que atingiu seu ambiente de produção.
P:
Como sabemos se realmente podemos recuperar os dados hoje?
R: A única resposta honesta vem dos testes, não da documentação. Se você não puder apontar uma Recovery recente e validada da sua empresa que seja minimamente viável — idealmente, um teste automatizado diário —, então você não sabe, está apenas supondo. Uma resposta defensável para o conselho é um MTCR mensurado e respaldado por validação contínua, não um plano de recuperação que pareça completo no papel.
P: O que os órgãos reguladores e as seguradoras cibernéticas esperam atualmente?
R: O padrão passou de “Vocês têm backups?” para “Vocês podem provar que conseguem se recuperar de forma limpa e com que rapidez?”. Os órgãos reguladores esperam cada vez mais uma capacidade de recuperação comprovável e resiliência testada; as seguradoras, cada vez mais, definem o preço da cobertura — e pagam indenizações — com base em evidências de backups isolados e imutáveis e tempos de recuperação validados. Um MTCR medido e uma cadência de testes documentada estão se tornando requisitos básicos para ambos. Rajiv Kottomtharayil é diretor de produto da Commvault.
