Há anos, a resiliência cibernética tem sido definida pela tecnologia – controles de segurança, recursos sofisticados de detecção e estratégias de backup cada vez mais robustas, projetadas para prevenir ataques ou permitir uma recuperação mais rápida. Esses investimentos continuam sendo essenciais, mas já não são suficientes. A IA mudou fundamentalmente a natureza dos ataques cibernéticos, que agora ocorrem a uma velocidade que desafia até mesmo organizações maduras. À medida que o intervalo entre a violação e a interrupção dos negócios continua a diminuir, a resiliência está se tornando menos uma questão de prevenir todos os ataques e mais uma questão de manter a empresa em funcionamento quando a prevenção inevitavelmente falha.

Essa mudança está no cerne do novo relatório da IDC, “Operações de Resiliência: A Disciplina que Torna a Readiness Comprovável”. Essa mudança está no cerne do novo relatório da IDC, Operações de Resiliência: A Disciplina que Torna a Prontidão Comprovável. Com base em uma pesquisa realizada com mais de 500 organizações norte-americanas, o relatório argumenta que a resiliência está evoluindo para uma disciplina operacional multifuncional que conecta as prioridades de negócios à segurança cibernética, às operações de TI (ITOps) e à recuperação de desastres. Mais importante ainda, ele revela várias lacunas que sugerem que muitas organizações ainda estão se preparando para um cenário de ameaças que já não existe. Aqui estão os insights que se destacaram. 

A recuperação deve começar com os resultados comerciais – e não com os técnicos.

Historicamente, o planejamento de recuperação tem se concentrado em restaurar a infraestrutura o mais rápido possível, sendo o sucesso avaliado por meio de objetivos de tempo de recuperação, taxas de conclusão de backup e disponibilidade de aplicativos. Embora essas métricas continuem sendo valiosas, elas não respondem necessariamente à pergunta que mais interessa aos executivos: quando poderemos colocar a empresa de volta em operação? 

A IDC defende que a resiliência deve estar ligada aos resultados comerciais, e não a marcos técnicos — restaurando as capacidades que permitem à organização atender aos clientes, gerar receita e cumprir suas obrigações. Isso pode parecer uma questão de semântica, mas muda a forma como as prioridades de recuperação são estabelecidas. A tecnologia passa a ser um meio para atingir um fim, e não o fim em si. 

A maioria das organizações ainda não definiu o que é mais importante.

Quase 6 em cada 10 organizações ainda não definiram completamente seu negócio mínimo viável (MVB) – o menor conjunto de funções, sistemas, processos e dados necessários para continuar operando após uma interrupção. 

Sem um entendimento comum sobre o que realmente sustenta o negócio, cada ação tomada durante a recuperação passa a ser reativa. Ao definir seu MVB antes de uma crise, você possibilitará decisões mais rápidas, uma melhor coordenação durante a recuperação e, em última instância, uma organização mais resiliente. 

A automação está se tornando a linha divisória entre resiliência e endividamento para recuperação.

Embora os invasores estejam automatizando cada vez mais as etapas de reconhecimento, exploração e movimentação lateral, muitas organizações ainda dependem de processos manuais de recuperação. Esse desequilíbrio está se tornando cada vez mais difícil de ignorar. A IA está reduzindo os prazos dos ataques, mas os prazos de Recovery não acompanharam esse ritmo. As organizações que não conseguirem automatizar essas tarefas de recuperação podem acabar gastando dias elaborando e executando planos, enquanto o dano já tiver sido causado. A orquestração automatizada da recuperação, a identificação precisa de pontos de recuperação e a validação coordenada estão se tornando recursos essenciais para a recuperação na velocidade exigida pelos ataques modernos. 

A tecnologia não é o maior desafio à resiliência — o alinhamento organizacional é que é.

As equipes de segurança se concentram na contenção, as equipes de infraestrutura se concentram na restauração, os líderes de negócios se concentram no impacto sobre os clientes e as equipes de conformidade se concentram nas obrigações regulatórias. Nenhuma dessas prioridades é, por si só, errada, mas, quando elas evoluem de forma independente, as organizações entram em uma crise sem um modelo operacional compartilhado. 

É aí que entra o ResOps. Em vez de considerar a resiliência como uma responsabilidade da TI, o relatório a apresenta como uma disciplina que reúne deliberadamente os setores de negócios, segurança, infraestrutura e planejamento de recuperação. A mensagem é clara: a resiliência depende menos de ferramentas individuais e mais da criação de prioridades compartilhadas antes que um incidente o obrigue a tomar decisões difíceis. 

A realização de testes continua sendo um dos indicadores mais sólidos de resiliência.

A IDC constatou que um número relativamente pequeno de organizações realiza exercícios de simulação em mesa ou simulações em ambiente virtual de segurança cibernética com frequência, apesar de décadas de evidências que demonstram que os ensaios melhoram consistentemente o desempenho durante incidentes reais. 

Os exercícios revelam dependências ocultas, expõem falhas de comunicação e permitem que as equipes tomem decisões sem arcar com as consequências reais. As organizações que validam repetidamente seus processos de recuperação desenvolvem um nível de confiança que vai além do simples planejamento. 

Os desafios de resiliência do futuro já estão se delineando.

O ransomware ainda domina as manchetes, mas os próximos desafios à resiliência já surgiram — desde a IA autônoma e as identidades de máquina até a criptografia pós-quântica. 

Essas ameaças nos lembram que o planejamento de resiliência não pode se concentrar exclusivamente na infraestrutura atual. A recuperação envolve, cada vez mais, serviços de “ cloud ”, aplicações “ SaaS ”, modelos de IA, identidades de máquinas, provedores terceirizados e ecossistemas digitais distribuídos que não existiam há uma década. 

A resiliência está se tornando mensurável.

O Modelo de Maturidade ResOps da IDC é de valor inestimável para avaliar a situação atual da sua organização. Em vez de tratar a resiliência como algo que as organizações possuem ou não possuem, a estrutura descreve uma evolução de operações reativas e isoladas para uma resiliência madura e adaptativa, baseada em governança, automação e melhoria contínua. Para mim, essa evolução reconhece uma realidade importante: a resiliência nunca está concluída. Não se trata de adquirir uma plataforma ou concluir um projeto. As organizações se tornam resilientes ao aprimorar continuamente a forma como a tecnologia, as pessoas e os processos de negócios trabalham juntos sob pressão. Visto sob essa perspectiva, a resiliência passa a ser menos um tipo de seguro e mais uma forma de excelência operacional — uma capacidade que pode ser avaliada, fortalecida e demonstrada ao longo do tempo. 

Estamos passando por uma mudança mais ampla na forma como as organizações encaram a resiliência.

As discussões sobre resiliência estão evoluindo da proteção da infraestrutura para a proteção do próprio negócio. Isso significa que o planejamento de recuperação começa com os clientes, e não com os servidores; a governança passa a ser tão importante quanto a tecnologia; e a confiança advém da comprovação de capacidades, e não da documentação de intenções. O ResOps não é, na verdade, uma nova estrutura; trata-se, antes, de um reconhecimento mais amplo de que a resiliência cibernética se tornou uma disciplina operacional. À medida que os ataques se tornam mais rápidos e complexos, a resiliência será medida não pela ausência de incidentes, mas pela capacidade da organização de continuar atendendo aos clientes, apoiando os funcionários e mantendo a confiança, mesmo diante de interrupções. No fim das contas, é exatamente isso que o ResOps foi criado para comprovar. Rajiv Kottomtharayil é diretor de produtos da Commvault. 

Pontos principais

• A confiança na era da IA não está desaparecendo — está evoluindo.
• As organizações precisam verificar a IA continuamente, em vez de confiar nela por padrão.
• A adoção da IA deve capacitar os funcionários, e não levá-los a recorrer à IA paralela.
• O modelo “zero trust” não significa desconfiar das pessoas. Trata-se de validar continuamente identidades, dispositivos e ações.
• A adoção responsável da IA exige que a tecnologia, a governança e as pessoas trabalhem em conjunto.

Quando lançamos o “Ready. Or Not.”, queríamos criar uma série que tornasse mais fáceis de entender algumas das principais discussões atuais sobre IA. Ao reunir o comediante Nathan Macintosh com especialistas do setor, estamos explorando tudo, desde IA autônoma e resiliência cibernética até gerenciamento de dados — e adicionando um pouco de humor ao longo do caminho.

Se você assistiu ao nosso primeiro episódio sobre as oportunidades e os riscos da IA agênica, acho que vai gostar deste também. Desta vez, vamos abordar um tema que está no centro de todas as discussões sobre IA: a confiança.

Nathan conversa com Diana Kelley, diretora de segurança da informação da Protect AI, sobre o que significa confiar na tecnologia em um momento em que a IA é capaz de gerar conteúdo falso convincente, tomar decisões e até mesmo imitar pessoas. De deepfakes e alucinações até o modelo “zero trust” e a IA oculta, eles exploram como as organizações podem adotar a IA sem perder a confiança em seu pessoal e em seus sistemas.

Assista ao episódio completo no Readiverse. Saí desse episódio me sentindo mais otimista do que esperava. Não porque a IA tenha se tornado, de repente, mais confiável, mas porque Diana nos mostra que a confiança cresce quando as organizações implementam as políticas, as medidas de proteção e a tecnologia adequadas. Aqui estão alguns temas da conversa que colocam a IA sob uma nova perspectiva.

Confiança e tecnologia podem coexistir

Diana acredita que a confiança é possível na era da IA, mas terá uma forma diferente. Sempre construímos confiança por meio de relacionamentos com pessoas. Agora, estamos aprendendo a estender essa confiança aos sistemas. Isso não significa confiar cegamente na tecnologia. Significa entender como a IA funciona, reconhecer suas limitações e adotar as medidas de segurança adequadas para que as pessoas e a tecnologia possam trabalhar juntas com confiança.

“A confiança precisa evoluir para se adequar ao novo mundo.” – Diana Kelley

O que me chamou a atenção foi a ideia de que confiança e tecnologia não precisam estar em conflito uma com a outra. Com a abordagem certa, elas podem se fortalecer mutuamente.

Estamos nos tornando mais experientes em IA

Os deepfakes se tornaram um dos riscos da IA mais comentados, e é fácil entender por quê. A IA agora é capaz de gerar vozes, imagens e vídeos convincentes que nos fazem questionar o que é real. Mas Diana destacou que, embora a IA esteja se tornando mais sofisticada, as pessoas estão ficando mais espertas. Estamos mais propensos a questionar uma ligação inesperada, examinar com mais atenção uma postagem nas redes sociais ou parar para pensar diante de algo que não parece totalmente certo.

As organizações também estão se tornando mais experientes. À medida que a IA se aperfeiçoa na imitação, as empresas estão investindo em novas formas de verificar continuamente as identidades e validar as informações. Minha conclusão é a seguinte: a tecnologia continuará a melhorar, mas o mesmo acontecerá com nossa capacidade de reconhecê-la e reagir de forma responsável.

“Hoje é um bom dia para começar a fazer um deepfake?” – Nathan Macintosh

A IA responsável é boa para os negócios

Diana compartilhou um exemplo que provavelmente soará familiar para muitas organizações. Uma funcionária a quem ela chama de “Karen, do Departamento Financeiro”, começa a usar IA porque isso a ajuda a concluir uma tarefa em minutos, em vez de horas. Karen não está tentando contornar a política da empresa — ela está tentando ser mais produtiva.

Os funcionários utilizam a IA porque reconhecem seu valor real, e isso representa uma oportunidade para as organizações. Quando os funcionários têm acesso a ferramentas de IA aprovadas, respaldadas por políticas claras e orientações práticas, eles podem trabalhar com mais eficiência e, ao mesmo tempo, ajudar a proteger os dados e os sistemas da empresa.

Prévia: Adoção mais inteligente da IA

O objetivo não é impedir que os funcionários utilizem a IA. É garantir que eles a utilizem da maneira correta. Diana explica como as organizações podem incentivar a adoção da IA sem criar riscos desnecessários.

A abordagem “Zero Trust” é mais importante do que nunca

“Quando você entende como as coisas funcionam, é aí que começa a entender como administrá-las.” – Diana Kelley

O “Zero Trust” é um daqueles conceitos que fica muito mais fácil de entender com uma analogia. Diana tem uma excelente. Ela descreve isso como se mover por um prédio. Só porque você foi autorizado a entrar pela porta da frente não significa que todas as outras portas se abram automaticamente para você. Cada vez que você acessa uma nova sala, há outra verificação rápida para confirmar se você realmente deve estar ali.

É basicamente assim que o “Zero Trust” funciona. É basicamente assim que funciona o modelo “zero trust”. Em vez de presumir que uma pessoa ou dispositivo é confiável após um único login, as organizações verificam continuamente identidades, dispositivos e ações, à medida que a tecnologia se torna cada vez mais conectada. A maioria dessas verificações ocorre discretamente nos bastidores. Uma das coisas que mais gostei na explicação da Diana é que o “zero trust” não parece ser apenas mais um chavão da área de segurança. Parece uma maneira prática de pensar sobre a confiança em um mundo em que a IA e as identidades digitais estão se tornando parte do dia a dia dos negócios.

A confiança tem a ver com as pessoas

No fim das contas, não é a tecnologia que gera confiança — são as pessoas. São as pessoas que definem as políticas, os processos e os limites éticos que orientam o uso da IA, enquanto a tecnologia ajuda a verificar se essas medidas de proteção estão funcionando conforme o esperado. É essa parceria entre pessoas e tecnologia que torna possível uma IA responsável.

A confiança vai além de nossas próprias organizações. As empresas precisam confiar nos parceiros com quem trabalham, nos sistemas aos quais se conectam e nas tecnologias que adotam. É por isso que a transparência, os padrões compartilhados e a verificação contínua estão se tornando tão importantes quanto a própria inovação. Quanto mais a IA se torna parte do dia a dia dos negócios, mais a confiança se torna uma responsabilidade de todos.

Olhando para o futuro

A IA continuará a evoluir, assim como a forma como interagimos com ela. As organizações que terão sucesso não serão aquelas que confiam cegamente na IA ou que a evitam por completo. Serão aquelas que estabelecerem políticas sólidas, adotarem as tecnologias adequadas e verificarem continuamente os sistemas dos quais dependem.

A confiança não é algo que perdemos à medida que a tecnologia avança. É algo que construímos e desenvolvemos intencionalmente. Esse é exatamente o tipo de conversa que esperamos continuar em cada episódio de Ready. Or Not. Assista ao episódio completo no Readiverse.

Perguntas frequentes

P: O que é confiança digital?

R: A confiança digital é a certeza de que pessoas, sistemas e organizações são quem afirmam ser e agem da maneira esperada e segura. Ela combina tecnologia, governança e verificação para ajudar as organizações a interagirem com segurança.

P: O que são deepfakes?

R: Deepfakes são imagens, vídeos ou gravações de áudio gerados por IA, criados para imitar fielmente pessoas reais. Embora tenham usos legítimos, também podem ser utilizados para se passar por outras pessoas ou cometer fraudes.

P: O que é o modelo “zero trust”?

R: O modelo “zero trust” é um modelo de segurança baseado na verificação contínua, em vez da confiança automática. Em vez de presumir que um usuário ou dispositivo é confiável após um único login, as organizações validam continuamente as identidades e as ações.

P: O que é a IA de sombra?

R: O termo “Shadow AI” se refere ao uso, por parte dos funcionários, de ferramentas de IA que não foram aprovadas nem estão sujeitas à regulamentação da organização. Embora muitas vezes seja bem-intencionado, isso pode acarretar riscos à segurança, à privacidade e à conformidade.

P: Por que as organizações não deveriam simplesmente bloquear as ferramentas de IA?

R: Os funcionários geralmente adotam a IA porque ela os ajuda a trabalhar com mais eficiência. Em vez de proibir totalmente o uso da IA, as organizações devem fornecer ferramentas aprovadas, estabelecer políticas claras e orientar os funcionários sobre o uso responsável.

P: Qual é a principal lição deste episódio?

R: A confiança não está desaparecendo por causa da IA — ela está evoluindo. As organizações que combinam pessoas, políticas e tecnologia com verificação contínua estarão mais bem posicionadas para adotar a IA com confiança e responsabilidade.

Katherine Demacopoulos é diretora sênior de Estratégia e Programas de Conteúdo Global da Commvault.

Nosso diretor de produtos, Rajiv Kottomtharayil, escreveu recentemente sobre uma grande mudança que está ocorrendo em todos os setores. Os modelos de IA de ponta estão reduzindo o tempo entre a descoberta de uma vulnerabilidade e sua exploração. Essa mudança está levando organizações em todo o mundo a reavaliar seus processos de gerenciamento de vulnerabilidades. Estamos fazendo o mesmo na Commvault. É por isso que, a partir de 11 de agosto, estamos mudando o ritmo com que divulgamos vulnerabilidades. O que está mudando Estamos elevando o padrão de segurança, transparência e confiança dos clientes. No dia 11 de agosto, e na segunda terça-feira de cada mês a partir de então, lançaremos o “Patch Tuesdays”: uma publicação mensal programada na qual compartilhamos alertas de segurança e correções de vulnerabilidades.  

As “Patch Tuesdays” são uma marca registrada das principais empresas de tecnologia, pois oferecem aos clientes um ritmo previsível de segurança. Isso se torna ainda mais importante à medida que o ritmo de descoberta de vulnerabilidades se acelera. É claro que, se houver uma vulnerabilidade urgente que precise ser relatada fora do ciclo, não hesitaremos em seguir nossos processos bem estabelecidos.  

Onde você pode encontrar recursos atualizados  

Na segunda terça-feira de cada mês, você encontrará novas informações relacionadas às CVEs em nossa página de Alertas de Segurança. Você também pode encontrar as publicações oficiais no site de CVEs. No Centro de Segurança da Commvault, você encontrará nosso programa de gerenciamento de vulnerabilidades e outras iniciativas de liderança em segurança desde a concepção.   

Para obter certificações de conformidade, relatórios de auditoria e documentação sobre como a Commvault protege os dados dos clientes, acesse o Centro de Confiança da Commvault. Você pode se inscrever para receber atualizações do Trust Center pelo link no canto superior direito da página. Bill O’Connell é Diretor de Segurança da Commvault. 

Há décadas, os líderes do setor de tecnologia vêm tentando eliminar os silos. Programas inteiros de modernização foram desenvolvidos com o objetivo de conectar aplicativos, consolidar plataformas e proporcionar às organizações uma visão mais completa de seus dados. Esses esforços geraram um valor imenso, mas também moldaram a maneira como pensamos sobre resiliência. Quando algo dá errado, instintivamente procuramos a fragmentação técnica. No entanto, descobrimos que o maior desafio está em outro lugar.

Os silos mais significativos que afetam a resiliência cibernética atualmente não se encontram em bancos de dados ou aplicativos, mas nas estruturas organizacionais. Eles existem entre as equipes de segurança e de infraestrutura, entre a TI e os negócios, e entre as pessoas responsáveis por responder a um ataque e aquelas responsáveis por manter a organização em funcionamento.

A pesquisa mais recente da IDC sobre ResOps, intitulada “Resilience Operations: The Discipline that Makes Readiness Provable” (Operações de Resiliência: a disciplina que torna a prontidão comprovável), sugere que essas fronteiras organizacionais se tornaram um dos principais obstáculos à recuperação eficaz. Essa é uma observação oportuna, pois os ataques cibernéticos evoluíram de maneiras que podem tornar cada vez mais difícil manter essas fronteiras.

Os ataques modernos não seguem o organograma da sua empresa

Um ataque cibernético moderno raramente afeta apenas um único domínio tecnológico. Um incidente envolvendo ransomware pode começar com identidades comprometidas, se espalhar por toda a infraestrutur cloud , criptografar cargas de trabalho críticas, interromper aplicativos voltados para o cliente, afetar serviços de terceiros e acionar requisitos regulatórios de notificação — tudo isso em questão de horas. Cada etapa envolve equipes diferentes, ferramentas diferentes e prioridades diferentes. No entanto, muitas organizações ainda se preparam para a recuperação como se essas responsabilidades pudessem ser gerenciadas de forma independente.

As equipes de segurança naturalmente se concentram em conter ameaças e preservar evidências. As equipes de infraestrutura priorizam a restauração de sistemas e a minimização do tempo de inatividade. Os líderes de negócios concentram-se nos clientes, na receita e na continuidade operacional. As equipes de comunicação pensam na reputação, enquanto as equipes jurídicas e de conformidade se concentram nas obrigações regulatórias. Cada ponto de vista é totalmente razoável. O problema surge quando essas prioridades nunca foram conciliadas antes de ocorrer um incidente.

No meio de uma crise, a Recovery exige a tomada de decisões sob pressão. Quais aplicativos devem ser restaurados primeiro? Quais dados podem ser restaurados com segurança? Qual é o nível de Risk aceitável antes da retomada dos serviços aos clientes? Quem tem autoridade para tomar essas decisões? Sem alinhamento, as organizações frequentemente percebem que os maiores atrasos não são causados pela tecnologia, mas pela incerteza — daquele tipo que poderia ser mitigada com uma melhor preparação.

A resiliência começa com uma definição comum do que é importante

O relatório dá ênfase ao estabelecimento do seu negócio mínimo viável (MVB). À primeira vista, parece ser mais um exercício de planejamento de recuperação, mas seu verdadeiro valor reside nas conversas que ele leva as organizações a terem.

Para definir um MVB, é necessário que os líderes empresariais, as equipes de segurança, os especialistas em infraestrutura e os responsáveis pelas aplicações cheguem a um consenso sobre uma questão que, à primeira vista, parece simples: O que precisa, sem dúvida alguma, continuar funcionando se todo o resto parar?

Essa discussão altera a natureza do planejamento de resiliência. As prioridades de recuperação não são mais determinadas pelo proprietário da aplicação que apresentar os argumentos mais convincentes durante um incidente. Em vez disso, elas são estabelecidas com antecedência, com base nos resultados de negócios e respaldadas por dependências técnicas que todos compreendem.

Talvez o mais importante seja que o MVB cria uma linguagem comum. Os líderes empresariais passam a falar sobre capacidades críticas, em vez de sistemas individuais. As equipes de tecnologia começam a mapear a infraestrutura com base nos resultados para o cliente, em vez de arquiteturas técnicas. As equipes de segurança ganham maior clareza sobre quais ativos merecem os mais altos níveis de proteção durante a Recovery. Esse entendimento comum é exatamente o que tem faltado a muitas organizações.

A tecnologia pode automatizar a recuperação – mas não pode criar alinhamento

O relatório não defende que as organizações precisem de mais uma plataforma. Ele defende que elas precisam de uma forma de trabalhar que alinhe pessoas, processos e tecnologia em torno de um único objetivo operacional. É aí que o ResOps – uma disciplina multifuncional – mostra seu valor.

A tecnologia pode ajudar a automatizar a Recovery, mas não pode resolver divergências sobre prioridades de negócios. Ela não pode decidir quais serviços ao cliente são mais importantes. E não pode substituir a governança necessária para coordenar várias equipes durante um evento de alta pressão. Esses são desafios de liderança, e a melhor maneira de enfrentá-los é dedicar tempo para responder juntos às perguntas difíceis, muito antes que um ataque o obrigue a agir.

As organizações mais fortes não eliminam os silos — elas os conectam

Os ataques cibernéticos continuarão evoluindo. A IA continuará reduzindo os prazos dos ataques. Novas tecnologias introduzirão novas dependências, e novas ameaças surgirão junto com elas. Nada disso altera o requisito fundamental para a resiliência. As organizações não se recuperam porque equipes individuais tenham um desempenho brilhante isoladamente, mas porque essas equipes já sabem como trabalhar juntas.

Essa pode ser, em última análise, a principal conclusão da pesquisa da IDC. A resiliência não é simplesmente o resultado de uma tecnologia melhor ou de controles de segurança mais sofisticados. É o resultado de prioridades compartilhadas, uma governança clara e um modelo operacional comprovado que reúne as pessoas certas antes que um incidente ocorra. Vidya Shankaran é diretora de tecnologia de campo da Commvault.

Pontos principais

• Um CVE é um identificador globalmente exclusivo para uma vulnerabilidade de software divulgada publicamente, permitindo que fornecedores, pesquisadores e especialistas em segurança se refiram a ela de maneira consistente.
• A abordagem de uma organização em relação à divulgação de vulnerabilidades — incluindo correções coordenadas, envolvimento de pesquisadores e inventário preciso de software — é um forte indicador da maturidade geral em segurança.
• A Commvault protege seus clientes por meio de um programa de CVE que se caracteriza pela transparência, regularidade e clareza. A divulgação de CVEs diz muito sobre a maturidade de um programa de segurança e engenharia.

Por que isso é importante

Muitas violações de segurança que chegam à diretoria têm origem em vulnerabilidades de software. O mecanismo utilizado por todo o setor para nomear e descrever essas vulnerabilidades é o CVE(Common Vulnerabilities and Exposures). A forma como um fornecedor — ou a própria organização — lida com os CVEs é um dos indicadores mais claros da maturidade em segurança.

Uma empresa que divulga e reconhece os pesquisadores de forma justa costuma ser uma empresa que leva a sério a engenharia subjacente. Este blog explica como um CVE é criado, quem administra o sistema e o que diferencia uma divulgação exemplar de uma inadequada.

Além do CVE: Por que a filosofia da divulgação é importante

A publicação de um CVE é o mínimo necessário. Os fatores que fazem a diferença são: transparência em relação à vulnerabilidade e à correção, verificações e aplicações de correções regulares, além de uma comunicação clara. A Commvault encara a divulgação como uma disciplina de engenharia e segurança, e não apenas como um requisito de conformidade a ser cumprido: estabelecer uma frequência para a revisão de código e correção de falhas, comunicar a correção em linguagem simples e proteger nossos clientes. Essa consistência, mais do que qualquer pontuação isolada, é o que a divulgação de CVEs revela sobre a maturidade em segurança.

O que é, na verdade, um CVE

Um CVE não é um patch, uma pontuação nem um malware. É uma entrada no dicionário que atribui a uma vulnerabilidade específica e de conhecimento público um nome permanente e exclusivo, para que todos possam se referir a ela. O próprio identificador segue um formato simples e duradouro: as letras CVE, o ano em que o identificador foi atribuído e um número sequencial; por exemplo, CVE-2021-44228.

A dimensão do programa é enorme e continua crescendo: 48.000 CVEs foram publicados em 2025, a uma média de 132 por dia, o que representa um aumento de mais de 260% desde 2020.

A anatomia de um único registro

As publicações do CVE exigem um conjunto consistente de elementos. A leitura de uma delas é simples, desde que você saiba qual é a função de cada parte:

• Identificador, o código único CVE-AAAA-NNNNN
• Descrição: uma explicação concisa da vulnerabilidade: o que ela é e como um agente mal-intencionado poderia explorá-la.
• Produtos e versões afetados, quais softwares, hardwares ou firmwares (e quais versões) foram afetados, e quais versões contêm a correção.
• Criticidade: a categoria de criticidade subjacente.
• Referências, links para o comunicado do fornecedor, o patch e artigos técnicos.

O elenco coadjuvante: CVSS, CWE, EPSS e KEV

Quatro sistemas complementares transformam um CVE em algo que uma empresa pode priorizar. É fácil confundir um com o outro, por isso vale a pena ter essa distinção em mente:

• O CVSS (Common Vulnerability Scoring System) responde à pergunta “Qual é o grau de gravidade?”. O CVSS é a classificação de gravidade (1 a 10, sendo 10 a mais grave) da falha, e não uma medida da sua exposição específica.
• O EPSS (Exploit Prediction Scoring System) responde à pergunta: “Qual é a probabilidade de que isso seja explorado em breve?”. O EPSS gera uma pontuação de probabilidade, de zero a 100 por cento, estimando a probabilidade de que uma vulnerabilidade seja explorada nos próximos 30 dias.
• O CWE (Common Weakness Enumeration) responde à pergunta “Que tipo de erro causou isso?”. O CWE classifica a falha de codificação subjacente.
• O KEV (Vulnerabilidades Conhecidas e Exploradas) responde à pergunta: “Essa vulnerabilidade está sendo usada contra as pessoas neste momento?”. O catálogo do KEV é uma lista selecionada de CVEs com exploração confirmada no mundo real.

Uma pontuação alta no CVSS indica o grau de gravidade de uma vulnerabilidade; uma pontuação alta no EPSS indica a rapidez com que ela provavelmente será explorada; e a inclusão no catálogo KEV confirma que a exploração já está ocorrendo. Os melhores programas de gerenciamento de vulnerabilidades levam em consideração esses três fatores.

Perguntas frequentes

P: O que é um CVE e por que ele é importante? R: Um Common Vulnerability and Exposure (CVE) é um identificador padronizado atribuído a uma vulnerabilidade de software divulgada publicamente. Ele permite que todos — desde fornecedores e pesquisadores até órgãos reguladores e clientes — se refiram à mesma vulnerabilidade sem ambiguidade.

P: Quais informações um registro CVE bem estruturado deve conter?
R: Um registro CVE completo requer um identificador único, uma descrição da vulnerabilidade, os produtos e versões afetados, o tipo de criticidade e referências a alertas ou patches do fornecedor. Esses elementos permitem que as organizações compreendam sua exposição e respondam de forma eficiente.

P: Em que o CVSS, o CWE, o EPSS e o KEV diferem de um CVE? R: Um CVE identifica uma vulnerabilidade específica, enquanto o CVSS mede sua gravidade, o EPSS estima a probabilidade de exploração no curto prazo, o CWE classifica a falha de codificação subjacente e o KEV identifica vulnerabilidades que estão sendo ativamente exploradas no mundo real. Juntas, essas estruturas ajudam a fornecer o contexto necessário para priorizar a correção.

P: O que a Commvault busca em suas próprias práticas de divulgação? R: A Commvault aplica às suas próprias divulgações os mesmos padrões que espera dos demais: transparência, regularidade e clareza. É assim que a Commvault protege seus clientes.

P: O que os líderes empresariais devem levar em consideração ao avaliar as práticas de gerenciamento de vulnerabilidades dos fornecedores? R: Os líderes devem buscar cronogramas coordenados de divulgação, registros CVE abrangentes e precisos, orientações claras para correção, programas robustos de geração de relatórios e a capacidade de determinar rapidamente se os produtos são afetados por vulnerabilidades recém-divulgadas. Essas características refletem uma forte cultura de segurança e aumentam a resiliência organizacional. Werner Nel é gerente sênior de experiência do produto na Commvault.

Pontos principais

• JadePuffer é o nome que os pesquisadores de segurança da Sysdig deram ao que consideraram ser a primeira operação de ransomware documentada conduzida de ponta a ponta por um agente de IA autônomo, e não por um ser humano utilizando um conjunto de ferramentas.
• As técnicas em si não eram novas. O que mudou foi a velocidade da execução: o agente encadeou ações de reconhecimento, roubo de credenciais, movimento lateral e criptografia destrutiva, corrigindo uma tentativa de login malsucedida em 31 segundos.
• O agente gerou sua própria chave de criptografia e, em seguida, nunca a armazenou nem a transmitiu. Pagar o resgate não teria restaurado os dados.
• Os danos reais afetaram o estado da configuração e os sistemas do plano de controle, e não apenas os arquivos, que é exatamente a camada que a maioria dos planos de recuperação não abrange.
• Recuperar-se de um ataque como esse significa comprovar que a empresa pode retomar suas operações com segurança, e não apenas restaurar um backup.

O que aconteceu

Em meados de 2026, pesquisadores de segurança da Sysdig documentaram uma campanha de extorsão que consideram ser a primeira do gênero: uma operação de ransomware conduzida de ponta a ponta por um agente baseado em um modelo de linguagem de grande porte, com participação humana mínima no comando. Eles a batizaram de JadePuffer.

O ponto de entrada era conhecido. O invasor explorou a vulnerabilidade CVE-2025-3248, uma falha de execução remota de código sem autenticação no Langflow — uma estrutura de código aberto para a criação de fluxos de trabalho de agentes de IA —, que estava executando uma versão anterior à 1.3.0. A partir daí, o agente enumerou o host, procurou credenciais em provedores de cloud , fornecedores de modelos de IA e bancos de dados, e, discretamente, fez o dump do próprio banco de dados de apoio do site platform.

O que aconteceu a seguir é a parte que merece atenção. O agente escaneou a rede interna, encontrou um armazenamento de objetos exposto e extraiu os arquivos de estado e configuração do Terraform. Ele configurou uma tarefa agendada para se comunicar com o servidor de comando a cada 30 minutos. Em seguida, mudou de alvo para um sistema de produção separado que rodava MySQL e Alibaba Nacos, uma plataforma de configuração e descoberta de serviços comum em arquiteturas de microsserviços.

Uma vez dentro do sistema, o agente tentou criar uma conta de administrador no Nacos. A tentativa falhou. Trinta e um segundos depois, ele havia diagnosticado a falha e conseguiu o resultado desejado com uma abordagem diferente. Em seguida, utilizou as funções de manipulação de arquivos do MySQL para verificar se poderia avançar ainda mais, antes de criptografar mais de 1.300 registros de configuração, excluir as tabelas originais e deixar uma nota de resgate para trás.

A chave de criptografia foi gerada dinamicamente, exibida uma única vez e nunca armazenada em nenhum local onde o invasor pudesse recuperá-la. Independentemente de isso ter sido intencional ou não, o resultado para a vítima é o mesmo: não havia como reverter a situação por meio do invasor ou de uma chave de descriptografia, independentemente de o resgate ter sido pago ou não. A recuperação dependeria de backups válidos, da reconstrução do sistema ou de pontos de recuperação validados.

Por que os pesquisadores estão chamando isso de “agênico”

Nenhuma das técnicas individuais aqui mencionadas é nova. Explorar uma vulnerabilidade CVE sem patch, coletar credenciais, fazer varreduras para movimentação lateral, criptografar dados para extorsão: as equipes de segurança já se depararam com todas elas antes. O que levou a Sysdig a classificar o operador como “agênico”, em vez de um invasor convencional, foi a forma como as etapas se encaixam.

O agente não seguiu um roteiro fixo. Ele observou os resultados e se adaptou. Quando esperava uma resposta em JSON e recebeu XML, mudou sua abordagem e continuou. Quando sua primeira tentativa de criar uma conta de administrador falhou, ele diagnosticou a falha específica e tentou algo diferente, em menos de um minuto.

Os pesquisadores também encontraram comentários incorporados nas cargas úteis, explicando os alvos e os próximos passos em linguagem simples — um padrão mais consistente com o raciocínio de um LLM ao realizar uma tarefa do que com o de um ser humano copiando e colando um kit de exploração conhecido. As reportagens da mídia não confirmaram qual modelo ou platform esteve por trás do ataque. O que está confirmado é o comportamento: algo que raciocinou, agiu, esbarrou em um obstáculo e corrigiu o rumo mais rapidamente do que a maioria das respostas a incidentes conduzidas em ritmo humano consegue agir.

O problema da recuperação que muitas estruturas ainda não abordam

A maioria dos manuais de ransomware se baseia em uma suposição específica: algo criptografou seus arquivos, e a questão é se você consegue restaurar um backup válido ou se precisa negociar uma chave de descriptografia.

O JadePuffer rompe essa suposição de duas maneiras. Primeiro, não havia chave de descriptografia a ser negociada. Segundo, o dano não se limitou apenas aos dados. Ele atingiu a camada de configuração e do plano de controle subjacente aos dados: a plataforma de descoberta de serviços, os segredos que ela guardava, o estado do Terraform que descrevia como a infraestrutura se encaixava e as credenciais espalhadas por todos os sistemas que o agente acessou ao longo do caminho.

Esse é um problema de recuperação mais complexo do que simplesmente “restaurar o banco de dados”. Uma restauração limpa de arquivos em um ambiente com credenciais renovadas, mas não verificadas, desvios de configuração não revisados e uma camada de identidade que ninguém reauditou não é, na verdade, uma recuperação limpa. Trata-se de uma cópia nova dos dados alojada em um sistema no qual ainda não se pode confiar.

O que isso significa para sua estratégia de resiliência

O JadePuffer é uma prévia da questão que todo plano de recuperação terá, mais cedo ou mais tarde, que responder: é possível retomar as operações quando um invasor tiver afetado não apenas seus dados, mas também a identidade, a configuração e os sistemas do plano de controle dos quais esses dados dependem?

Alguns pontos para começar:

Trate os sistemas de configuração e do plano de controle como essenciais para a Recovery, não apenas os aplicativos. Plataformas de descoberta de serviços, armazenamentos de segredos e o estado da infraestrutura como código são tão críticos para os negócios quanto os bancos de dados que eles configuram. Se eles não estiverem em seu plano de Recovery hoje, essa é a primeira lacuna a ser preenchida.

Incorpore a higiene das credenciais ao processo de recuperação, e não depois dele. Restaurar uma carga de trabalho que reintroduz segredos comprometidos não encerra o incidente; isso apenas reinicia o contador de tempo do incidente. Essa é a mesma disciplina que a Commvault aplica atualmente à infraestrutura de identidade: avaliação de vulnerabilidades para identificar exposições antes que um invasor o faça, auditoria em tempo real para detectar alterações à medida que ocorrem e reversão para desfazer alterações não autorizadas sem precisar reconstruir tudo do zero.

Valide antes de restaurar, não depois. Um ponto de restauração só é útil se você tiver certeza de que está livre de contaminação. Essa é a lógica por trás do Commvault® Cleanroom™: testar e validar os dados em um ambiente isolado antes que eles voltem à produção, em vez de descobrir o problema após uma nova contaminação.

Planeje-se para uma violação do plano de controle, não apenas para um evento de criptografia de arquivos. Um roteiro de recuperação elaborado apenas para “arquivos criptografados e restauração a partir de backup” não será suficiente diante de um incidente como esse. A questão mais relevante — e aquela que está no centro das ResOps (operações de resiliência) como disciplina operacional — é o que é necessário para atingir um nível mínimo viável de operações quando os sistemas subjacentes às suas aplicações são os que foram afetados.

Nada disso exige que a IA agentiva seja tratada como uma ameaça sem precedentes que exija começar do zero. O que é necessário é estender a mesma disciplina de resiliência que já se aplica à identidade e aos dados até a camada de configuração e do plano de controle, que agora é alvo direto dos ataques agentivos. Saiba mais sobre como a Commvault aborda a resiliência de identidade e a validação da recuperação sem perdas.

Perguntas frequentes

P: O que é o JadePuffer? R: JadePuffer é o nome que a Sysdig deu ao que considerou ser a primeira campanha de ransomware documentada conduzida de ponta a ponta por um agente de IA autônomo, em vez de um invasor humano operando manualmente um conjunto de ferramentas.

P: Os invasores utilizaram algum modelo específico de IA, como o ChatGPT ou o Claude? R: As reportagens divulgadas até o momento não confirmaram qual modelo ou platform foi utilizado. O agente procurou por chaves de API de vários provedores de IA, o que demonstra interesse nesse tipo de acesso, mas não identifica o que realmente esteve por trás do ataque em si. P: Como começou o ataque?

R: Por meio do CVE-2025-3248, uma vulnerabilidade de execução remota de código sem autenticação no Langflow, uma estrutura de código aberto para agentes de IA, que afeta versões anteriores à 1.3.0. P: A vítima poderia ter pago o resgate para recuperar seus dados? R: Não. A chave de criptografia foi gerada dinamicamente e nunca foi armazenada nem transmitida; portanto, não havia nenhuma chave disponível para recuperação, independentemente do pagamento.

P: O que diferencia esse ransomware dos demais? R: As técnicas em si não eram novas. O que se destacou foi a velocidade e a adaptabilidade: o agente diagnosticou uma tentativa fracassada de login e corrigiu o problema em 31 segundos, um ritmo mais próximo da velocidade de uma máquina do que do comportamento típico de um invasor, que segue o ritmo humano. P: O que as equipes de segurança e recuperação devem tirar disso?

R: Esse planejamento de recuperação precisa ir além dos dados das aplicações, abrangendo também os repositórios de configuração, as plataformas de descoberta de serviços, os segredos e os sistemas de identidade — a camada que o JadePuffer realmente visou para causar o máximo de danos. Chris Bevil é gerente principal de marketing de portfólio na Commvault.

Pontos principais

• Modelos avançados de IA escaparam de um ambiente de avaliação restrito ao explorar vulnerabilidades até então desconhecidas.
• A OpenAI afirma que os modelos estavam buscando atingir um objetivo que lhes havia sido atribuído, sem agir com intenção maliciosa, mas mesmo assim causaram um incidente de segurança real.
• Controles tradicionais, como sandboxing e segmentação, são insuficientes se a IA for capaz de descobrir caminhos inesperados para contorná-los.
• A resiliência cibernética está se tornando tão importante quanto a prevenção.

Tudo começou como uma avaliação interna das capacidades cibernéticas avançadas baseadas em IA. Ao tentarem resolver um teste de desempenho com definições restritas, os modelos da OpenAI descobriram uma vulnerabilidade de dia zero, contornaram as restrições previstas do ambiente de teste, obtiveram privilégios elevados, acessaram a internet e comprometeram a infraestrutura da Hugging Face. Eles encaravam as limitações técnicas ao seu redor como problemas a serem resolvidos.

Este não foi um ataque cibernético tradicional

A Hugging Face foi a primeira a informar que uma estrutura de agente autônomo de IA havia comprometido parte de sua infraestrutura de produção. Um conjunto de dados malicioso explorou duas rotas de execução de código em seu pipeline de processamento de conjuntos de dados, obteve acesso ao nível do nó, coletou credenciais e se espalhou lateralmente pelos clusters internos.

Os modelos envolvidos, incluindo o GPT-5.6 Sol e um modelo em pré-lançamento com maior capacidade, estavam operando com restrições cibernéticas reduzidas e sem os classificadores habituais de produção. Eles foram muito além da tarefa atribuída, explorando uma vulnerabilidade de proxy para acessar a internet e, em seguida, utilizando credenciais roubadas e vulnerabilidades de dia zero para encontrar um caminho de execução remota de código nos servidores do Hugging Face.

Não foi necessária a existência de intenção dolosa

Não há indícios públicos de que os modelos tenham desenvolvido intenção criminosa ou optado por prejudicar a Hugging Face. Eles não precisavam disso. Dê a um sistema capaz um objetivo, ferramentas, tempo e feedback, e ele contornará os obstáculos. A discussão já foi além das solicitações e respostas incorretas. Trata-se de sistemas capazes de investigar, testar suposições, descobrir vulnerabilidades até então desconhecidas, utilizar credenciais roubadas, escalar privilégios e continuar operando quando a primeira tentativa falha.

Uma área de testes não é um campo de força

Chamamos os ambientes de isolados, segmentados e em sandbox como se o próprio rótulo já garantisse segurança. Mas não é assim. Neste caso, o caminho óbvio para a internet estava bloqueado, mas um proxy de pacote de software acessível não estava, e os modelos usaram essa vulnerabilidade para escapar. Políticas e comportamentos esperados não são suficientes. O próprio ambiente técnico deve fazer valer os limites.

Por que essa é uma história de resiliência

A atividade passou de um ambiente de avaliação, passando pela infraestrutura de pesquisa da OpenAI, para a internet e, por fim, para o ambiente de produção da Hugging Face. Esse é um raio de impacto em rápida expansão. Quando a IA pode explorar e agir na velocidade de uma máquina, o tempo entre o acesso inicial e o comprometimento mais amplo pode continuar a diminuir.

A Hugging Face não se limitou a bloquear a rota de acesso original e declarar o incidente encerrado. Ela eliminou as rotas vulneráveis de execução de código, reconstruiu os nós comprometidos, renovou as credenciais e os tokens e reforçou os controles do cluster. O objetivo não é apenas restaurar um sistema. É restaurar a confiança.

A questão já não é apenas: “Nossos sistemas de IA são seguros?”. É: “Quando um sistema de IA poderoso descobre um caminho que não sabíamos que existia, seremos capazes de conter o raio de impacto, dar continuidade às operações críticas, reconstruir aquilo em que não confiamos mais e provar que é seguro seguir em frente?”. Chris Bevil é gerente principal de marketing de portfólio na Commvault.

A segurança não termina nos limites dos sistemas próprios de uma organização. As empresas modernas conectam uma rede cada vez maior de aplicativos de terceiros às suas plataformas centrais para dar suporte às vendas, aos serviços e à colaboração. Cada uma dessas conexões agrega valor. Cada uma delas também introduz uma exposição que a organização não controla totalmente.

Esse risco não é hipotético. Em junho de 2026, um agente mal-intencionado comprometeu tokens OAuth vinculados ao Klue, um e platform a de inteligência competitiva usado para sincronizar dados de vendas e marketing com o Salesforce. O invasor utilizou esses tokens para acessar os ambientes do Salesforce de diversas organizações que haviam autorizado a integração, incluindo a Commvault.

Assim que fomos notificados sobre um possível impacto, nossa equipe de segurança acionou nosso processo de resposta a incidentes para determinar o que havia ocorrido, conter a exposição e avaliar se as informações dos clientes ou os serviços da Commvault foram afetados. Nossa investigação constatou que a atividade se limitou a determinadas informações sobre relações comerciais e vendas mantidas em nosso ambiente do Salesforce. A investigação não encontrou indícios de que quaisquer dados de backup de clientes, dados de produtos, metadados de produtos, registros operacionais ou serviços da Commvault tenham sido afetados.

Agir rapidamente quando é preciso

Nossa resposta seguiu os procedimentos estabelecidos para lidar com incidentes de segurança, criados para conter rapidamente os riscos e, ao mesmo tempo, viabilizar uma investigação completa. Assim que fomos notificados do incidente, desativamos a integração com o Klue, revogamos o acesso associado e colaboramos com as partes envolvidas para realizar uma avaliação completa do ocorrido. Ao longo da investigação, nossas equipes trabalharam para determinar quais informações foram acessadas, validar a integridade do nosso ambiente e confirmar que o incidente permaneceu dentro do escopo que já havíamos contido.

Um padrão que merece destaque

Esse incidente é um exemplo recente de uma tendência que as equipes de segurança vêm observando se intensificar há vários anos: invasores que têm como alvo aplicativos de terceiros conectados aos principais sistemas de negócios, em vez de atacar esses sistemas diretamente. Uma única integração comprometida pode oferecer um caminho confiável para acessar os ambientes de várias organizações a jusante de uma só vez, muitas vezes com menos resistência do que um ataque direto a qualquer uma delas.

Isso muda o foco de onde a defesa de uma organização realmente precisa estar. Controles internos robustos continuam sendo necessários, mas já não são suficientes por si só. Eles precisam ser combinados com uma supervisão ativa de todos os aplicativos aos quais a organização se conecta e com uma capacidade de resposta que esteja pronta antes de um incidente, e não criada durante o mesmo.

Desenvolvendo resiliência além do nosso próprio ambiente

Na Commvault, nosso programa de segurança inclui uma avaliação contínua dos aplicativos de terceiros conectados ao nosso ambiente. Analisamos regularmente os aplicativos conectados, avaliamos os acessos de cada um deles, monitoramos riscos emergentes e reavaliamos essas integrações à medida que as necessidades de negócios e o panorama de ameaças se alteram. Quando as circunstâncias assim o exigirem, tomamos medidas para reduzir a exposição e fortalecer nossa postura de segurança, incluindo o desligamento de integrações que não atendam mais aos nossos padrões.

Nosso compromisso com a transparência

A confiança se constrói por meio da transparência e da prestação de contas. Quando um evento afeta nossas partes interessadas, acreditamos que é importante comunicar o que sabemos, explicar como agimos e compartilhar o resultado de nossa investigação, mesmo quando o evento teve origem fora de nossos próprios sistemas. Continuaremos a avaliar nossos controles de segurança, aprimorar nossos processos de resposta a incidentes e fortalecer nossa abordagem em relação aos riscos de terceiros, como parte de nosso compromisso mais amplo de proteger nossos clientes e parceiros.

Para obter os detalhes oficiais sobre este incidente, incluindo o escopo da investigação e orientações aos clientes, consulte as atualizações do nosso Centro de Confiança. Will Galway é vice-CISO da Commvault.

Durante anos, a criptografia pós-quântica (PQC) permaneceu confortavelmente na categoria de “importante, mas não urgente”.

Os líderes de segurança sabiam que isso estava por vir. Os pesquisadores falavam sobre o assunto. Os órgãos de padronização trabalhavam nisso. A maioria das organizações reconhecia que, mais cedo ou mais tarde, isso exigiria atenção. Mas eu diria que a hora de começar a se preparar é agora.

Neste episódio do STRIVE, conversei com o diretor sênior de marketing de portfólio, Michael Fasulo, para discutir por que o debate em torno da PQC está mudando tão rapidamente — e por que as organizações que esperam por certezas podem acabar ficando sem tempo. Assista ao episódio completo.

Pontos principais

• Os ataques do tipo “Harvest Now, Decrypt Later” (colher agora, descriptografar depois) significam que dados confidenciais já estão em risco, mesmo que as capacidades quânticas ainda não sejam estáveis ou comercialmente viáveis.
• A maioria das organizações não tem uma visão completa de seu inventário criptográfico, o que torna a identificação desses dados o primeiro grande obstáculo.
• A PQC é tanto um desafio tecnológico a ser resolvido quanto uma questão de priorização de riscos.
• As organizações que começarem a se preparar agora terão mais opções para ajustar suas prioridades do que aquelas que forem forçadas a reagir mais tarde.

O problema não é a tecnologia

A maioria das discussões sobre criptografia pós-quântica começa com a tecnologia.

• Com que rapidez a computação quântica está avançando?
• Quando os sistemas quânticos relevantes para a criptografia se tornarão viáveis?
• Quais algoritmos provavelmente sobreviverão a longo prazo?

Essas são questões importantes. Mas não são as que eu priorizaria. Michael escreveu um post no ano passado sobre PQC e discutimos hoje como várias coisas mudaram desde então.

Nos últimos anos, as estimativas têm se movido consistentemente em uma direção: o que antes parecia distante agora parece cada vez mais próximo. Ao mesmo tempo, os padrões estão evoluindo; as expectativas regulatórias estão aumentando e as organizações estão começando a reconhecer o quanto de “dívida criptográfica” acumularam ao longo das décadas.

A data exata do Q-Day pode permanecer incerta. A direção a ser seguida, porém, não é.

The Risk está aqui e agora

Uma das razões pelas quais essa conversa se tornou mais urgente é a crescente atenção em torno dos ataques do tipo “Harvest Now, Decrypt Later” (Colher agora, descriptografar depois). O conceito é simples: um adversário obtém acesso a informações criptografadas hoje, armazena-as e aguarda recursos futuros para tornar essas informações legíveis.

O importante aqui é que o risco não começa quando a computação quântica chega. O risco começa quando mesmo dados criptografados são exfiltrados e armazenados.

Para organizações que protegem propriedade intelectual, registros de saúde, informações governamentais ou outros dados confidenciais com retenção de longo prazo, essa distinção muda tudo.

As organizações precisam saber se os dados que estão sendo retidos hoje ainda terão importância quando esse futuro chegar.

Para muitas, especialmente os setores altamente regulamentados e as infraestruturas críticas, a resposta é sim.

Prévia: Por que a agilidade em criptografia é importante

Incorpore o clipe aqui: https://www.youtube.com/watch?v=A3YWU5rlmGA

Neste vídeo, Michael explica por que a PQC não é uma solução ou mudança pontual. O verdadeiro objetivo é a agilidade criptográfica – construir a flexibilidade necessária para adaptar os algoritmos criptográficos à medida que os padrões e as ameaças evoluem. Pois, na segurança cibernética, o desafio não é apenas se preparar para o que está por vir. É estar pronto para o que virá depois disso.

A descoberta é o verdadeiro projeto

Um equívoco sobre o PQC é que se trata principalmente de uma atualização de criptografia. Na realidade, a maioria das organizações ainda não chegou ao estágio em que a substituição é a maior preocupação.

Elas ainda estão tentando entender o alcance do problema. A criptografia está presente em toda parte.

• Aplicações
• Certificados
• Serviços em nuvem
• APIs
• Assinatura de código
• Plataformas de terceiros

Muitas organizações enfrentam dificuldades na criação do inventário criptográfico ou na definição de seu escopo. Isso torna a descoberta uma das etapas mais importantes — e muitas vezes subestimadas — dessa jornada.

E, para muitas empresas, essa é uma tarefa muito mais complexa do que o esperado.

O desafio da cadeia de suprimentos

Outra razão pela qual a PQC se tornou uma prioridade é que nenhuma organização enfrentará essa transição sozinha. As empresas modernas dependem de fornecedores, provedores de nuvem, parceiros de software e inúmeros terceiros, todos os quais utilizam criptografia.

Isso significa que a Readiness para a era quântica vai além dos sistemas internos. Torna-se uma questão de Readiness do ecossistema.

• Os fornecedores estão se preparando?
• Os fornecedores essenciais estão planejando migrações?
• As plataformas de terceiros estão alinhadas com os padrões emergentes?

Essas questões passarão a fazer cada vez mais parte das conversas sobre riscos, das discussões sobre compras e do planejamento tecnológico de longo prazo. Porque a criptografia não se limita aos limites organizacionais. Nem o risco.

Por que essa conversa é importante

A principal lição desta discussão é que a criptografia pós-quântica não é mais um desafio tecnológico do futuro.

Está se tornando uma conversa sobre resiliência no presente.

As organizações não precisam entrar em pânico e não precisam reformular todos os sistemas da noite para o dia. Mas precisam começar, para aproveitar ao máximo o tempo de que dispõem para se preparar.

As organizações que conduzirem essa transição com sucesso não serão necessariamente aquelas com a criptografia mais sofisticada. Serão aquelas que começaram a construir um entendimento antes que a certeza chegasse.

E é assim que a resiliência costuma funcionar.

Assista ao episódio completo

Há muito mais que Michael e eu exploramos no episódio que não abordei acima. Não deixe de assistir agora para obter insights sobre:

• Os maiores desafios que as organizações enfrentam ao iniciar sua jornada em PQC.
• O que os líderes devem priorizar hoje, incluindo algumas práticas recomendadas.
• A compreensão dos algoritmos MLKEM e da agilidade criptográfica.
• Considerações sobre infraestrutura para PQC.
• Como a Commvault está se preparando para esse futuro.

Perguntas frequentes

P: O que é criptografia pós-quântica (PQC)?
R: PQC refere-se a algoritmos criptográficos projetados para ajudar a manter a segurança contra ataques de futuros computadores quânticos.

P: O que é “Harvest Now, Decrypt Later” (Coleta agora, descriptografe depois)?
R: É uma estratégia em que os invasores coletam dados criptografados hoje com a intenção de descriptografá-los mais tarde, quando recursos de computação mais avançados estiverem disponíveis.

P: Por que as organizações estão se concentrando na PQC agora?
R: Porque a preparação leva anos, e os dados confidenciais coletados hoje ainda podem ser valiosos quando as ameaças quânticas se tornarem uma realidade.

P: Qual é o maior desafio que as organizações enfrentam?
R: A identificação. A maioria das organizações não tem visibilidade completa sobre onde a criptografia é utilizada em seus ambientes.

P: As organizações precisam substituir toda a criptografia imediatamente? R: Não. A maioria dos especialistas recomenda começar com o inventário, a descoberta e a priorização antes de planejar migrações mais amplas. P: O que os líderes devem fazer primeiro? R: Identificar dados confidenciais de longa duração, compreender as dependências criptográficas e começar a traçar um roteiro para a transição futura. Vidya Shankarané diretora de tecnologia de campo da Commvault.