Testar ou não testar, eis a questão?

0

Vou pedir licença a Shakespeare para provocar uma reflexão filosófica ao chamar atenção para um paradigma que está mudando: se antes as empresas discutiam o que fazer SE fossem atacadas, agora os executivos de negócios e TI estão preocupadas no que fazer QUANDO forem atacados. Veja que a principal mudança no foco do debate é admitir que as defesas de borda, mesmo com o mais alto nível de investimento e complexidade, vão falhar. Não se trata de discutir eficiência, porque muitas soluções de proteção e prevenção são excelentes e dificultam bastante um ataque, mas infelizmente nunca vão ser infalíveis.

Os hackers estão se sofisticando e se financiando por meio de ataques bem-sucedidos. Na teia quase infinita de tecnologia, sempre vai haver uma nova vulnerabilidade e no melhor espírito de "correr atrás" do que o mercado tem de melhor, nem todas as empresas podem investir para estar à frente o tempo todo. Mesmo as que podem, adotar tecnologias e tirar o melhor delas costuma levar algum tempo. No final do dia, quem "corre atrás" sempre chega em segundo e os hackers usam isso a favor deles.

Saindo da filosofia e partindo para a parte prática: Quando foi a última vez que sua empresa fez um teste de recuperação de um incidente? Há quanto tempo você juntou o time e debateu sobre um o plano de recuperação? Quantas vezes você conversou com as áreas de negócio sobre o impacto de um ataque cibernético nas suas áreas?

Se você pensou muito para responder essas perguntas, saiba que você não foi o único. Aliás, isso é mais comum do que se imagina! Manter as empresas funcionando 24×7 no seu melhor jogo, sem falar das demandas por novos projetos que trazem mais receita e reduzem custos para a área de negócios, não são tarefas simples. Então, como justificar testar a empresa para se recuperar de um eventual ataque cibernético?

Cabe também uma ponderação aqui: Muitos anos se passaram quando as empresas descobriram que podiam ser 24×7 com o apoio da tecnologia. Os negócios podiam funcionar e prosperar mesmo quando os escritórios estavam fechados e isso impulsionou o crescimento dos datacenters, tanto que até migraram para a nuvem. Todo esse movimento era lastreado por uma conta de segundos, de maneira bem simplista: quanto dinheiro se podia fazer por segundo? Do outro lado, se uma empresa parasse, quanto se perdia de dinheiro? Uma tragédia que aconteceu em um longínquo dia 11/9 do passado fez com que as empresas reforçassem um velho ditado: "quem tem um, não tem nenhum".  A era da recuperação dos desastres começou com força e muitas empresas se colocaram a fazer a conta de quanto custaria ter outros datacenters disponíveis para se recuperar de uma catástrofe. Nessa conta não entrava apenas a disponibilidade da infraestrutura, mas todo o processo de mover sistemas críticos para uma outra localidade. Tudo isso era fantástico no papel e um outro ditado cabe aqui: todo mundo tem um plano até tomar o primeiro soco.

Muitas empresas descobriram na prática que mover workloads, dados e oferecer acesso a datacenter de contingência traz desafios que não haviam sido previstos. Então, assim como a prática faz a perfeição, era preciso testar. O mercado descobriu então que não adianta apenas ter um plano. Responder para os auditores internos ou para os acionistas que a empresa tem um plano de contingência e nunca tê-lo testado, era o mesmo que dizer que não tinha nada. Novas regulamentações foram criadas para aperfeiçoar essa exigência e muitos testes depois, muitas empresas se tornaram melhores nesse processo.

Voltando aos dias atuais

Para citar um exemplo recente, mais um caso de ataque de ransomware foi divulgado. Aliás, percebi que essa frase infelizmente é atemporal: todos os dias alguma empresa é atacada. A média diária de ataques cresce de modo exorbitante e mais e mais empresas descobrem que o plano de recuperação de desastres não cabe para se recuperar de ataques cibernéticos.

E o que nos torna profissionais? A educação e a experiência permitem que desempenhemos nossa função no dia a dia e sejamos remunerados por isso. Mas como dizer que temos experiência se nunca passamos por um ataque? Nossos times estão sendo treinados para se preparar melhor, mas não esperamos ter que ser atacados frequentemente para termos a experiência de colocar em prática o que aprendemos na sala de aula. Vários clichês se aplicam aqui: "A Teoria é uma coisa, a prática é outra", "a prática leva a perfeição" e "fé não é uma estratégia"… acho que ouvimos isso desde crianças e faz todo sentido aqui.

Minha reflexão e provocação pra você que chegou até aqui: Testar a nossa habilidade de se recuperar de um ataque cibernético ou de um evento digital não planejado (um erro talvez?) deveria ser uma preocupação das empresas? Testar na prática com frequência um plano de recuperação contra um ataque prepararia melhor as empresas para essas eventualidades?

Um dado interessante, a média de uma empresa para se recuperar de um ataque é de 24 dias. Apenas 1/3 desse tempo é gasto recuperando os dados e o restante do tempo, a maior parte, a empresa gasta recuperando as configurações que suportam as aplicações onde os dados vão ser processados. Ou seja, recuperar-se de um ataque cibernético, vai muito além de recuperar dados: por trás da facilidade de fazer negócios existe uma teia imensa de aplicações que dependem umas das outras, configurações de usuários, segurança, permissões e regras de comportamento que precisam estar disponíveis antes dos dados estarem prontos para serem utilizados.

Enquanto esse pensamento se espalha, acrescento que o próximo desafio seria tornar testes de recuperação menos complexos e menos custosos. O Sr. Al Bunte, um dos fundadores da Commvault, repetia uma frase que cada dia faz mais sentido: "Você não deveria gerenciar complexidade com mais complexidade". Testar a recuperação de um ambiente complexo, não deveria ser complexo também, mas esse debate poderia ser incluído nas conversas de arquitetura das aplicações que suportam os negócios. Assim como um arquiteto se preocupa com a manutenção e limpeza das vidraças que ficam no topo dos prédios mais altos e bonitos. Mas repetindo também uma frase comum em TI que "Deus só fez o mundo em 7 dias porque não tinha legado", nem sempre seria possível garantir que por design, toda a plataforma de negócios de uma empresa fosse pensada para todos as possibilidades do futuro.

Então, muitas empresas estão voltando aos seus parceiros de tecnologia para se preparar melhor para se recuperar de ataques com mais eficiência. Essa conversa passa por identificar o que esperar quando o ataque acontecer e buscar melhores práticas para alinhar às expectativas de negócio. O plano criado incluiria também a facilidade de testar esse plano para poder garantir que o planejado será realizado e buscar melhorias e ajustes.

Meu parágrafo final pontua que esses testes, além de necessários, precisam ter custos compatíveis com o esforço. Ou seja, testar o plano de recuperação a um ataque cibernético não deveria ser complexo nem mesmo custoso a ponto de inibir as empresas a fazê-lo. Mais um ponto para a criatividade dos fornecedores e integradores que já estão aptos para ter essa conversa. Acho que se Shakespeare estive entre nós, ele não teria dúvidas: Testar é essencial!

Marcelo Rodrigues, diretor-geral da Commvault no Brasil.

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.