Protocolo Phoenix: Ressurgindo das cinzas após um ataque cibernético

Incidentes cibernéticos envolvem adversários ativos e infecções ocultas. Recovery deve ser cautelosa e verificada para evitar reinfecção. 

É a estrutura de recuperação pós-ataque da Commvault, baseada no Commvault AirGap, na recuperação isolada, em um plano de recuperação cibernética e em testes de caos. 

Muitas não planejam nem praticam a Recovery. Equipes despreparadas costumam tomar medidas fragmentadas que espalham a infecção e atrasam a restauração. 

Os testes de caos simulam a pressão do mundo real, ajudando as equipes a validar processos e melhorar a coordenação antes de um incidente real. 

Eles ajudam a impedir adulterações e possibilitam a análise e a restauração seguras de sistemas limpos, sem o risco de reinfecção. 

Assista ao vídeo aqui para ver a transcrição com marcação de tempo

Bem-vindos à sessão de hoje do podcast SHIFT, intitulada “O Protocolo Phoenix: Como renascer das cinzas
após um ataque cibernético”. 

Sou Chris Dirado e, hoje, estou aqui com Michael Stempf. 

Michael, obrigado por estar aqui hoje; estou realmente ansioso por nossa conversa. 

Obrigado, Chris. 

Quando ocorre um ataque cibernético, a Recovery pode parecer uma tarefa titânica, mas é também um momento para se reconstruir
com mais força. 

Nesta conversa, vamos explorar o Protocolo Phoenix e como nossos quatro pilares aqui na
Commvault podem ajudar você a renascer das cinzas. 

AirGap Protect, Ambiente de Recovery Isolado, um Plano de Recovery Cibernético e, o mais
importante, testes para situações de caos. 

Juntos, veremos como as organizações podem transformar essa crise em uma
oportunidade de renovação e como sair de um ataque mais fortes do que antes. 

Então, Michael, quais são alguns dos erros mais comuns que as organizações cometem ao se recuperarem
de um ataque cibernético? 

Essa é uma pergunta capciosa. 

O problema mais comum que as pessoas enfrentam na Recovery é que elas não se planejam para isso até que a
Recovery precise acontecer. 

É preciso estar preparado, certo? 

O grande evento — gostamos de chamá-lo de “bang” — e as pessoas pensam no que acontece logo após
o evento ter ocorrido. 

Mas se você não planejou, se não treinou, se não desenvolveu aquela resistência mental
de ter passado por isso repetidas vezes e trabalhado com suas equipes, 

para criar uma experiência de integração de equipe em torno disso, você não vai estar preparado. 

Depois do fato, o que temos visto muitas vezes é que as pessoas estão, sinceramente, tentando dar o melhor de si. 

Você terá um administrador do Windows que só quer ajudar e colocar os servidores de volta em
funcionamento; então, ele vai agir por conta própria, fazer “TI paralela” e implementar seus próprios 

sistemas. 

E temos visto repetidamente que, quando fazem esse tipo de coisa, acabam
reinfectando uma nova área na qual o invasor ainda não havia entrado, 

e aí você tem que voltar atrás e lidar com isso de novo. 

Então, você perpetua o problema ao tentar fazer o melhor trabalho possível. 

E, sem essa prática, sem testar em meio ao caos de que você falou,
eles não vão compreender o verdadeiro nível de complexidade e sofisticação que esses 

agentes mal-intencionados lançam contra nós. 

E você levantou um ponto muito bom sobre as pessoas que só estão tentando ajudar, mas
às vezes… 

você sabe, se precipitam, certo? 

Iniciando recuperações antes de estarmos realmente prontos para recuperá-las. 

E sei, pela minha experiência e pela sua também, que já passamos por muitos desses cenários de Recovery
. 

Às vezes, você trabalha 60, 70, 80 horas por semana. 

O pior momento para fazer algo que não vai ter um bom resultado final é quando você já
está no limite e a todo vapor, certo? 

Então, na minha próxima pergunta, quero falar sobre algumas das falácias que são… 

você sabe, aquelas em que achamos que estamos protegidos, mas, na verdade, são apenas
falácias e, no fim das contas, não estão nos ajudando de verdade. 

Você poderia me dar alguns exemplos dessas falácias? 

Sim, acho que a primeira e mais importante é que todo mundo tem um plano de recuperação de desastres. 

Eles já os têm há anos. 

E vêm testando-os há anos. 

E um ataque cibernético é apenas mais um tipo de desastre — ou pelo menos é o que acreditam. 

O problema disso é que a recuperação de desastres tem tudo a ver com velocidade e eficiência. 

Certo. 

Seja um desastre natural, 

tornado, furacão, seja lá o que for. 

E não há intenção maliciosa. 

E quando se trata de ataques cibernéticos, velocidade e agilidade significam simplesmente que você vai reinfectar
o ambiente. 

Você precisa ir devagar, precisa ser metódico, precisa levar em conta essa malícia,
a presença do agente mal-intencionado no sistema. 

E, portanto, utilizar um plano que foi projetado especificamente para que você volte a operar o
mais rápido possível só vai causar problemas. 

Então, você precisa desacelerar, respirar fundo. 

Você precisa ter um plano de recuperação cibernética, que talvez, em sua essência, tenha muito do que está presente na
recuperação de desastres, mas o objetivo final é: como eu volto sem problemas, e não como eu volto 

o mais rápido possível. 

Então, esse é realmente o ponto principal. 

Mas há muitos outros aspectos que vêm junto com isso. 

Sabe, antes de mais nada, eu já vi praticamente tudo o que é possível ser destruído em um
ataque cibernético. 

E um dos fatores que levam a isso é que, hoje em dia, tudo está 

tudo vinculado a um sistema de gerenciamento de identidades hoje em dia, como o Active Directory. 

As estatísticas mais recentes do Active Directory mostram que ele está presente em 98% de todas as empresas e é alvo de
92% de todos os ataques cibernéticos. 

Claro, né? 

Você pode acessar qualquer lugar assim que estiver no Active Directory. 

São as chaves do reino. 

Então, uma das coisas que eu sempre recomendo é… bem, retirar sua última linha de defesa, retirar
seu sistema de proteção de dados do Active Directory, 

porque uma das táticas mais comuns dos criminosos cibernéticos é fazer exatamente isso — eles sabem que, se sua proteção
de dados resistir ao ataque, é provável que você não vá pagar. 

É assim que você evita pagar. 

Com certeza. 

Uma das coisas que dizemos é: retire sua proteção de dados do Active Directory, torne-a
autônoma, separe-a e isole-a o máximo possível. 

Assim, por mais que sua empresa seja destruída, ela ainda vai sobreviver. 

Só uma observação rápida: o Michael fez uma boa 

observação sobre um plano de recuperação cibernética. 

Em algumas das sessões que conduzi, percebi que muitas pessoas não tinham planos de recuperação
cibernética. 

Bem, na Commvault, a gente cuida disso pra você. 

Se você acessar nossa plataforma de Readiness e pesquisar por “plano de recuperação cibernética”, poderá
baixar nosso modelo e adaptá-lo às suas necessidades. 

E, como disse o Michael, algumas dessas coisas já estarão no seu plano de recuperação de desastres. 

Vá em frente e use esses elementos, certo? 

Copie e cole. 

Mas ter um plano de Recovery cibernético é realmente o que vai ajudar a tirar você dessa situação quando você
se deparar com um desses cenários. 

Michael, como as expectativas de recuperação mudaram, passando de apenas recuperar dados para recuperar nossos
negócios? 

Boa pergunta. 

Então, sabe, a maioria das pessoas planeja restaurações do tipo um Z, dois Z. 

Tenho alguns arquivos aqui. 

Tenho um servidor aqui. 

E dá para planejar isso, certo? 

É muito matemático, né? 

Para uma recuperação de desastres (DR). 

Tenho um andar. 

Tenho um servidor. 

Tenho um prédio. 

Preciso saber a quantidade de dados que existe, a largura de banda disponível até o próximo 

local, um local geograficamente disperso, e posso simular cenários o dia inteiro com base nisso. 

O problema com um incidente cibernético é que eu não sei a extensão dele, certo? 

Quantos servidores foram afetados nessa organização? 

Quantos locais foram afetados? 

Tive um cliente que foi atingido. 

Eles tinham 99 locais em todo o mundo, e o invasor destruiu todos os 99 locais em todo o mundo. 

Portanto, todas as cópias dos dados que eles tinham em qualquer lugar foram totalmente destruídas. 

Analisar a situação, projetar uma solução, testá-la e praticá-la são realmente algumas das
coisas mais importantes aqui, então você precisa se certificar de tratar isso de maneira diferente 

que você analise a situação de maneira diferente, e os resultados sempre serão diferentes. 

E você levantou um ponto realmente importante aqui. 

Existem três tipos distintos de operações de Recovery que planejamos corretamente: 

Recuperação operacional, recuperação de desastres e recuperação cibernética. 

Você poderia explicar um pouco mais sobre cada uma delas, em que diferem e como
isso 

realmente impede que os clientes consigam se recuperar em um incidente cibernético? 

Claro. 

Recovery operacional: esse é o caso típico — eu apaguei um arquivo, você tem uma cópia local da qual
pode restaurá-lo, super rápido, fácil de fazer, automatizado na maioria dos casos; basta simplesmente acessar 

e… 

Eu ia dizer que, aqui na Commvault, todos nós temos a capacidade de fazer nossas próprias recuperações em
nossos laptops. 

Tenho certeza de que, na maioria das organizações, é simples, certo? 

Procedimento simples. 

Com certeza. 

Recovery de desastres, no caso de desastres naturais, 

e é muito avançada. 

Fazemos isso há mais de 30 anos, testando trimestralmente na maioria dos locais. 

Na verdade, fizemos isso tantas vezes que as pessoas ficaram preguiçosas com a recuperação de desastres. 

Na verdade, elas nem estão mais testando. 

O que costumam fazer agora é alternar o data center de um local para outro
a cada seis meses e dizer: “Ei, estamos em produção”. 

É um bom teste. 

Mas, no caso desse último, o de segurança cibernética, são necessárias algumas medidas específicas. 

Primeiro, e acho que o mais importante, é uma cópia terciária dos dados. 

Uma terceira cópia dos dados que fica na infraestrutura de terceiros, porque, você sabe, os
invasores vão ter acesso ao AD, vão ter todo o seu ambiente, 

e vão ter todas as suas credenciais na nuvem. 

Portanto, ter apenas essa segunda cópia dos dados — que você normalmente dispersaria
geograficamente — não é proteção suficiente. 

Portanto, você precisa garantir que ela esteja protegida pela infraestrutura de terceiros, que seja
imutável e indelével. 

A indelévelidade impõe essa governança para garantir que 

ninguém, nem mesmo com credenciais de privilégios que possam ter obtido do AD, possa alterar
ou excluir esses dados. 

São esses dados que vão nos salvar quando estivermos sob ataque. 

Sabemos que eles estarão lá quando for necessário, porque, como você disse, não podem ser excluídos, não podem
ser alterados e precisam atender a requisitos rigorosos. 

E, para que um agente mal-intencionado consiga acessá-los, ele não teria apenas que invadir sua
organização, mas também a nossa, certo? 

Portanto, trata-se realmente de um ataque em duas frentes que ele teria que realizar. 

Então, com isso… 

sabemos que podemos ter uma cópia segura e protegida dos dados. 

Para onde devemos restaurar esses dados no caso de um ataque cibernético? 

Esse é o ponto em que ninguém nunca pensa, certo? 

Aproximadamente 17% de todos os ataques são destrutivos, nos quais os invasores invadem o firmware e
a BIOS dos servidores, e não é possível recuperar os dados a partir deles. 

Mas isso está no plano de todo mundo. 

Vou voltar exatamente ao ponto de partida. 

E hoje em dia, embora esses 17% sejam um número relativamente pequeno, a maioria dos CISOs 

— já que não se sabe se foi um ataque destrutivo — pensam: “Tenho que presumir que foi
destrutivo”. 

Portanto, a maioria das empresas não tem um plano em que haja 50 servidores à disposição,
prontos para uso. 

E, portanto, no ambiente atual, você deve ter um ambiente de Recovery isolado. 

Primeiro, é um local seguro para onde eu possa recuperar os dados; segundo, é um local que eu possa colocar
em produção e no qual eu tenha certeza de que o invasor não está presente. 

Portanto, como uma dessas áreas-chave de que você falou anteriormente, 

um ambiente de recuperação isolado — que chamamos de “sala limpa” — é essencial para a resiliência cibernética
. 

Claro, então agora temos uma boa situação: sabemos que temos cópias dos nossos dados, seguras e protegidas, e agora
temos um local onde podemos armazenar esses dados; e, como você mencionou anteriormente, podemos limpar 

e depurar esses dados antes de transferi-los para a produção. 

E uma das Features que, na minha opinião, aqui na Commvault não recebe o devido destaque é a nossa
portabilidade “any-to-any”, certo? 

Porque, como você disse, pode ocorrer um ataque destrutivo no local; bem, agora você precisa se
adaptar, certo? 

Você precisa… 

precisa ir para outro lugar; quanto tempo leva para conseguir um novo hardware? 

Talvez seis semanas? 

Você não pode ficar parado por seis semanas sem servidores de produção. 

Você pode migrar suas cargas de trabalho para o provedor de nuvem de sua escolha ou para um hipervisor diferente, e
isso realmente lhe dá a flexibilidade necessária para se recuperar após um desses ataques. 

Na verdade, essa é uma das principais vantagens da
Commvault em relação aos concorrentes, que nunca é realmente mencionada: o fato de que já fazemos “any-to-any” há anos. 

Então, se você quisesse… 

ter um ambiente VMware local e depois migrá-lo para o ambiente AWS EC2, tudo
é feito automaticamente. 

Isso acontece durante a restauração, e eu não preciso me preocupar com nada. 

E a variedade de opções de “any-to-any” que oferecemos entre
diferentes plataformas é absolutamente incrível e simplesmente supera qualquer outro na indústria. 

É, a gente realmente oferece aos nossos clientes todas as opções que eles poderiam querer, né, quando se
trata disso? 

Com certeza. 

Tudo bem, então vamos mudar de assunto. 

Que tipo de desafios você está observando com mais frequência atualmente em relação a esses ataques cibernéticos? 

O principal problema é a falta de preparação. 

É lidar com isso como se fosse um desastre. 

Quando se fala em Recovery de desastres e em se recuperar disso, normalmente se conta
com um administrador de backup, certo? 

E essa pessoa, nesse caso, 

eu sempre digo que ela é considerada uma divindade, certo? 

Quando se trata da parte da Recovery de desastres, é tipo: “não chegue perto dessa pessoa,
não se aproxime dela, apenas entregue comida e bebida de vez em quando e deixe-a em paz”, 

porque ela já vem elaborando o plano há muito tempo. 

E tudo era responsabilidade dela. 

O problema é que essa pessoa quase não tem responsabilidade em um ataque cibernético. 

Ela não pode simplesmente começar a recuperar os dados, porque isso desencadearia uma fase de reinfecção. 

Você precisa trabalhar com suas equipes de segurança, de TI, do departamento jurídico e de comunicação;
todas essas pessoas precisam trabalhar juntas, e elas nunca trabalharam juntas antes. 

E eu sempre gosto de brincar dizendo que, provavelmente, a última vez que sua equipe de segurança e sua equipe
de TI se reuniram foi quando jogaram uma contra a outra em alguma partida de beisebol em um 

evento. 

Elas estão sempre uma contra a outra, nunca no mesmo time. 

Mas quando ocorre um incidente cibernético, se eu for o responsável pelo backup, eu… 

não tenho autoridade para fazer uma Recovery até que alguém da área de segurança me diga para
fazê-la. 

E o pessoal de segurança não pode fazer o que precisa até que alguém da área de TI tome
a iniciativa. 

Então, é essa ideia de freios e contrapesos, que é um conceito totalmente estranho em qualquer Recovery de dados
antes de incidentes cibernéticos. 

É, e sabe, o que eu acho engraçado é que… pense na última vez que você interagiu
com um administrador de backup, certo? 

Provavelmente foi algo como: “Ei, perdi um e-mail ou uma planilha”, e o que eles fizeram? 

Eles restauraram em questão de minutos, certo? 

Agora, voltando ao que você disse, eles não podem fazer isso. 

Eles não podem simplesmente fazer isso porque você não sabe o que foi comprometido. 

Você não sabe se eles afetaram uma dúzia de servidores, se afetaram todo o ambiente ESX, e você
não pode simplesmente começar a restaurar as coisas, porque isso só vai te levar de volta ao ponto de partida. 

Isso realmente precisa ser um esforço em equipe, certo? 

Todo mundo precisa finalmente se unir, trabalhar em conjunto e colaborar para que a organização
volte a funcionar. 

Concordo. 

Então, quais são algumas das principais lições que as organizações aprenderam depois de passarem por um
ataque cibernético? 

As lições aprendidas variam. 

São as mais diversas. 

Acho que o mais importante é que — e isso geralmente ocorre após o segundo ataque, já que
é muito comum ver até cerca de quatro ataques por ano — isso não é algo que se possa realmente planejar. 

Você não vai conseguir criar cenários que vão se desenrolar exatamente como você
imagina quando esse evento cibernético acontecer. 

Existem tantas variáveis diferentes. 

A questão é a seguinte: na Recovery, é muito fácil se planejar para um tornado. 

Um tornado provavelmente vai destruir um prédio. 

Uma enchente pode destruir… 

talvez os andares inferiores de um prédio, mas isso é planeável, é ensaiável, eu posso entrar em ação e fazer
isso. 

No caso dos ataques cibernéticos, há tantas formas diferentes pelas quais eles podem atacar. 

Tantas maneiras diferentes de invadir, tantas maneiras de destruir informações. 

Caramba, hoje em dia, nem se trata mais tanto de ransomware, certo? 

Temos ataques acontecendo simplesmente porque alguém quer derrubar um concorrente, ou um
governo quer derrubar outro governo. 

Isso é pura intenção maliciosa, sem nenhum retorno financeiro, a não ser destruir
o inimigo. 

É difícil se preparar para isso. 

Claro. 

E, portanto, o que precisamos fazer é realmente levar em conta essa teoria do caos quando realizamos nossos testes. 

Uma das coisas que costumo fazer sempre que participo desses testes é que eles
sempre têm uma lista pré-definida do que foi atacado, certo? 

Eles sempre sabem exatamente quais servidores, e o que é ótimo é que sempre têm todos os
responsáveis por esses servidores nas reuniões conosco. 

Com certeza. 

E uma das coisas que sempre gosto de fazer é escrever os nomes dos servidores no verso
de cartas de baralho, 

e jogo essas cartas contra a parede; as que caírem com a face para cima são as
que acabaram de ser atingidas. 

Então, essa é uma ótima maneira de trazer essa metodologia do caos para cá, para que você possa testar. 

E depois de ter testado de tantas maneiras caóticas diferentes, não vou dizer que você está
preparado para esse ataque, mas você tem uma ideia e uma compreensão de qual será o impacto 

e, então, como você pode se recuperar melhor. 

É, e você sabe qual é o seu ponto de virada, certo? 

Ei, se eu souber que, se X acontecer, vou mudar para Y, certo? 

Se eu souber que, se fizer Y e não der certo, vou mudar para Z. 

E acho que não dá para estar preparado para todos esses cenários, mas quanto mais deles você estiver
preparado para quando isso realmente acontecer, é essa memória muscular, certo? 

Tipo, ei, eu sei que vamos conseguir fazer isso porque me preparei para isso, me
preparei para todas essas situações. 

Sei que, há alguns anos, o FBI costumava dizer: “Ei, se você sofrer um ataque cibernético,
precisa seguir este conjunto de procedimentos”. 

E, um ano depois, eles mudaram para: 

quando você for alvo de um ataque cibernético, precisa fazer isso. 

E agora, neste ano, eles dizem: “Pela quantidade de vezes que você vai sofrer um ataque cibernético
, precisa estar pronto, precisa estar preparado”. 

Você poderia falar um pouco mais sobre como é essa preparação nesse contexto? 

Sim, isso acontece com frequência, e acho que o mais importante na preparação é mudar
sua mentalidade. 

E a mentalidade muda: não se trata de
“se”, “quando” ou “com que frequência”, mas sim de realmente assumir que já sofri uma violação. 

Sabe, sempre gostamos de brincar dizendo que existem dois tipos de empresas neste mundo. 

Aquelas que sabem que já sofreram uma violação e aquelas que não sabem que já sofreram uma violação. 

E, embora isso não seja totalmente verdade — quer dizer, sejamos honestos —, no ano passado, nos Estados Unidos, apenas 60% das empresas sofreram
uma violação, certo? 

Então você tinha uma chance, tinha 40% de chance de não ter sofrido uma violação, mas isso foi em um
ano. 

Sim, sorte. 

Mas se você adotar a mentalidade de que vou partir do princípio de que houve uma violação, 

quando eu for trabalhar amanhã, vou tomar decisões diferentes. 

Vou encarar as coisas de maneira diferente, vou analisá-las de maneira diferente e, com sorte, vou
dar início a essa experiência de formação de equipe, envolvendo o departamento de TI e o jurídico, e 

discutindo assuntos que normalmente eu não teria discutido com eles. 

Então, sabe, é engraçado, você mesmo disse que 60% das organizações já sofreram violações. 

A questão é a seguinte: li uma estatística outro dia de que, em 2025, ocorrerá um ataque cibernético a cada
14 segundos. 

Esse número me parece absurdo. 

Outro número realmente impressionante é que o crime cibernético deve atingir US$ 10,5
trilhões este ano. 

Então, embora possam ter sido apenas 60% das organizações nos Estados Unidos, não se chega
a US$ 10 trilhões sem ter todo mundo como alvo, certo? 

Não é como se eles estivessem visando apenas 1% das grandes corporações, certo? 

Eles estão mirando em todo mundo. 

Para colocar isso em perspectiva: US$ 10 trilhões, se você analisar isso do ponto de vista do PIB dos
países ao redor do mundo, seria o terceiro maior país do mundo. 

Isso é inacreditável. 

Crime cibernético: o terceiro maior país do mundo. 

Isso é inacreditável. 

Ok, acho que é hora de mudar de assunto agora, certo? 

Então, já falamos bastante sobre os aspectos negativos, sobre as dificuldades. 

Vamos falar sobre como reduzir esse prazo de 24 dias. 

Vamos falar sobre o que os clientes podem fazer não só para se recuperar desses ataques, mas também para reagir
e, quem sabe, sair ainda mais fortes. 

É o que chamamos de nossos quatro pilares. 

Isso é muito importante. 

Então, antes de mais nada, você precisa ter uma cópia terciária dos dados na infraestrutura de
terceiros. 

Assim, você terá uma cópia limpa e confiável, imutável e indelével. 

É preciso ter um local para restaurá-la, que seja um ambiente de Recovery isolado. 

Chamamos o nosso de “sala limpa”. 

Isso permite que você, hum, faça testes, o que é o mais importante. 

Não vamos reduzir os 24 dias, mesmo aplicando esses métodos, se não fizermos os
testes com eles. 

Portanto, você precisa ter um local para realizar os testes, pois não é possível interromper a produção. 

Também é possível fazer análises forenses nesse local. 

Muitas vezes, digamos que você nem esteja sofrendo um ataque, mas tenha adquirido uma nova
ferramenta de segurança cibernética e queira testá-la em sua organização. 

Você não quer simplesmente soltar algum malware na sua organização e ver como a ferramenta o detecta. 

E você também não quer entrar em um ambiente estéril que não se pareça nem um pouco
com a sua produção. 

Então, com o Commvault Cleanroom, consigo recuperar meu ambiente para um local seguro, 

e posso soltar um malware lá para ver como a segurança cibernética se comporta. 

Por outro lado, se você for atacado — como aconteceu comigo uma vez, quando não foi um
ataque destrutivo, recebemos autorização, pudemos prosseguir e recuperar os dados, e o governo dos 

interveio e disse: “Vocês não podem fazer a recuperação agora”. 

Nunca vimos esse agente mal-intencionado e nunca vimos esse tipo de ataque. 

Então, eles queriam fazer sua própria análise forense. 

Só rapidinho: qual era o SLA deles nesse caso? 

É, eles estouraram o… 

É, claro, né? 

Não há SLA quando o governo está envolvido. 

Não, de jeito nenhum. 

Levamos duas semanas. 

Duas semanas para o governo fazer a pesquisa. 

Então, não teria sido ótimo se eu tivesse o Commvault Cleanroom e pudesse restaurar
essas máquinas naquele ambiente e dizer: “Ei, levem o tempo que precisarem. 

Vão em frente e façam suas avaliações, resolvam suas questões. 

Nós vamos voltar ao trabalho. 

É, incrível. 

Muito incrível. 

Então, eu tenho dados em boas condições. 

Tenho um local seguro para onde posso levar os dados. 

A próxima e mais importante coisa é o plano de recuperação cibernética, sobre o qual já conversamos, o que
é ótimo. 

Ele vai detalhar tudo, mas há algumas coisas que precisam constar nesse plano de recuperação cibernética
que, naturalmente, são muito difíceis de obter. 

Então, isso envolve a descoberta de todo o mapeamento das suas aplicações. 

Se eu estiver restaurando apenas alguns arquivos de um servidor de arquivos, isso não me importa muito. 

Se eu estiver restaurando, digamos, o Epic para um ambiente de saúde, e ele tiver 32
servidores diferentes que interagem entre si, e 

eu tiver que restaurá-los todos. 

Preciso colocá-los todos de volta em um estado consistente. 

E espero que você tenha feito a análise para descobrir isso, para realizar o mapeamento de suas aplicações. 

Existem algumas ferramentas que ajudam nisso, mas, para ser sincero, é um processo muito difícil
. 

É, como você descobre que 32 servidores alimentam uma máquina, né? 

E a maioria das pessoas pensa: “Bem, a gente sabe porque vamos restaurar nossos servidores de nível um
”. 

Bem, o problema é que um servidor de nível um só funciona se você tiver vários servidores de nível três
e nível quatro que estejam, de fato, alimentando-o com os dados 

dos quais ele precisa. 

E, portanto, a única maneira de fazer isso é com essa quarta etapa, que é o teste com caos. 

Tenho que entrar na sala limpa. 

Preciso garantir que estou fazendo as Recuperações, randomizá-las, ver o que acontece, ver o que funciona
e o que não funciona depois dessa randomização. 

Tudo bem, talvez apenas 32 máquinas tenham sido afetadas, mas vou ter que restaurar 142
por causa de todas as dependências existentes. 

Essas são, na verdade, as quatro coisas: o isolamento físico, a sala limpa ou ambiente de Recovery
isolado, 

um plano de recuperação cibernética e, por fim, testar tudo isso, porque um plano de recuperação cibernética não passa de um
pedaço de papel até que você realmente o coloque à prova. 

Com certeza, é isso mesmo. 

É só um documento até que você o coloque à prova. 

E alguns dos testes que eu recomendaria que os clientes fizessem são, por exemplo, exercícios simulados
: reunir-se na sala de reuniões e discutir o que aconteceria se fôssemos atingidos por um ransomware, o que 

vamos fazer em primeiro, segundo e terceiro lugar? 

Quando é que vamos, de fato, acionar nosso plano de recuperação cibernética? 

Mas eu iria um passo além também, certo? 

Você realmente quer fazer uma recuperação cibernética prática. 

Com certeza. 

Ei, eu tenho esse recurso chamado AirGap Protect, tenho esse chamado Cleanroom; agora
vamos colocar em prática — a prova está no resultado, certo? 

Vamos garantir que possamos recuperar essas cargas de trabalho dessa cópia terciária de dados para o
Cleanroom, porque esse é o verdadeiro teste, certo? 

Posso restabelecer minha empresa. 

E isso me leva à minha próxima pergunta: como as empresas estão determinando o que vão
restaurar em segundo e terceiro lugares? 

Já ouvi muito esse termo, “viabilidade mínima”, sendo usado por aí. 

Presumo que isso seja diferente para cada organização. 

Como isso se encaixa nesses quatro pilares? 

É diferente para cada organização, certo, dependendo do setor em que você
atua. 

E a única maneira de descobrir isso é por meio de testes. 

Sem isso, não dá para saber. 

Muitas vezes as pessoas acham que entendem o que precisa ser feito, onde e como. 

E sem esses testes, que fizemos durante anos para recuperação de desastres, já temos o
processo. 

Só que ainda não o aplicamos. 

Quero dizer, o mais incrível é o seguinte. 

Durante anos, 30 anos, realizamos testes trimestrais de Recovery de desastres e planos de Recovery de desastres
, mas menos de 1% de todas as empresas que já existiram declararam um 

desastre e, como dissemos antes, 60% de todas as empresas nos Estados Unidos sofreram uma violação de segurança no ano
passado e ninguém está testando para isso. 

Ninguém está testando porque é algo avançado, certo? 

É preciso um doutorado para entender a diferença entre recuperação cibernética e recuperação de desastres — algo que qualquer um consegue
fazer hoje em dia. 

Claro. 

É, e é quase como se a gente pensasse: “Ei, como eu vou saber o que estou testando em um evento de Recovery
cibernética?”, certo? 

E acho que, sabe, nossos clientes aqui na Commvault têm muita sorte. 

Lançamos agora esse novo serviço, o Guardian, e, olha, a gente entende que isso
não acontece da noite para o dia, né? 

Se quiséssemos ser resilientes a ataques cibernéticos amanhã, seríamos, mas não é tão fácil assim,
certo? 

É uma jornada. 

Leva tempo. 

Em muitos cenários, na maioria das vezes você vai precisar de ajuda. 

E acho que esse novo serviço tem como objetivo realmente ajudar os clientes 

a dar o próximo passo nessa jornada de resiliência cibernética. 

Bem, e por meio do nosso Readiverse — já que muitas pessoas não sabem como conduzir um
exercício de simulação adequado —, agora oferecemos tanto uma vertente executiva quanto uma técnica para um 

exercício de simulação sobre eventos cibernéticos. 

Mas, como você disse, esse é apenas o primeiro passo. 

Agora você precisa realmente colocar isso em prática. 

Nas forças armadas, chamávamos isso de ciclo OODA: Observar, Orientar, Decidir e Agir. 

E o que isso faz é uma repetição pela qual você passa, 

testando constantemente algo, avaliando-o, alterando-o e testando-o novamente. 

E, dessa forma, você fica mais preparado quando algo realmente acontece. 

Bem, você já passou por tantos ciclos de testes, mudanças e maneiras de fazer as coisas
que, para você, isso é quase mais um teste. 

Claro. 

E é assim que você realmente se recupera, certo? 

Então, com esses quatro pilares: a proteção por intervalo de ar, a sala limpa, seu plano de Recovery cibernético e,
por fim, os testes em condições de caos, certo? 

E nós temos… 

nos alinhamos perfeitamente a eles, como você disse. 

Temos cópias seguras e protegidas dos nossos dados. 

Temos o local para onde nossos dados serão restaurados. 

Ora, se você precisar de um plano de recuperação cibernética, baixe-o do Readiverse, como mencionei
, e adapte-o às suas necessidades. 

E, por último, mas não menos importante, se precisar de alguma ajuda ao longo do caminho, contamos com o Serviço Guardian para te ajudar
. 

Michael, obrigado pelo seu tempo hoje. 

Foi realmente esclarecedor. 

Obrigado, Chris. 

E isso encerra nossa conversa sobre o Protocolo Phoenix e como os quatro
pilares de resiliência cibernética da Commvault realmente ajudam os clientes a renascer das cinzas após um 

ataque cibernético.