A cibersegurança é frequentemente uma questão de velocidade: um cibercriminoso cria uma técnica ou código de ataque malicioso, as empresas de cibersegurança reagem à nova ameaça e, se necessário, ajustam e adotam métodos para detetar a ameaça.
Esta abordagem pode exigir a atualização de sistemas de deteção na nuvem e/ou a atualização de dispositivos terminais para fornecer a proteção necessária contra a ameaça. E a rapidez é essencial, uma vez que o setor da cibersegurança está presente para proteger, detetar e responder às ameaças à medida que surgem.
Os processos que as empresas de cibersegurança implementam para evitar conflitos entre uma atualização e o sistema operativo ou outros produtos são normalmente significativos, com ambientes de teste automatizados que simulam cenários reais de diferentes sistemas operativos, diferentes variantes de controladores de sistema, etc.
Nalguns casos, este processo pode ser supervisionado por seres humanos, uma confirmação final de que todos os processos e procedimentos foram seguidos e de que não existem conflitos. Também pode haver terceiros, como um fornecedor de sistema operativo, que testam independentemente do fornecedor de cibersegurança, tentando evitar qualquer falha grave, como a que estamos a assistir hoje.
Num mundo perfeito, uma equipa de cibersegurança testaria uma atualização no seu próprio ambiente assegurando que não há incompatibilidade. Uma vez assegurada a compatibilidade da que a atualização, seria iniciada uma implementação programada da mesma – eventualmente até num departamento de cada vez. Desta forma, reduz-se o risco de qualquer problema significativo para as operações comerciais.
Contudo, este não é nem pode ser o processo para atualizações de produtos de cibersegurança que têm de ser implementadas à mesma velocidade a que uma ameaça é distribuída, normalmente de forma quase instantânea. Se o processo de atualização falhar pode ser catastrófico como aconteceu hoje com uma atualização de software da CrowdStrike, com crashes em sistemas e as operações de infraestruturas inteiras afetadas.
Isto não significa incompetência do fornecedor uma vez que o incidente de hoje podia ter acontecido a qualquer fornecedor de TI. Muitas vezes, o mais provável é que seja um cenário de azar, uma tempestade perfeita de atualizações ou configurações que criam o incidente. Isto, claro, a menos que a atualização tenha sido manipulada por um cibercriminoso, o que parece não ser o caso nesta instância.
É provável que todos os fornecedores de cibersegurança revejam os seus processos de atualização para garantir que não existem lacunas e para ver como podem reforçá-los. Nuno Mendes, CEO da ESET Portugal, reforça que “O que realmente se aprende é que, quando uma empresa alcança uma posição de mercado significativa, o seu domínio pode causar um evento de semi-monocultura globalizado, em que um único problema afeta muitos sistemas, como aconteceu com este incidente da CrowdStrike.”
Qualquer profissional de cibersegurança utiliza termos como “defesa em profundidade” ou “camadas de defesa” referindo-se à utilização de várias tecnologias e, na maior parte dos casos, de vários fornecedores para impedir potenciais ataques, mas também é importante não esquecer a resiliência da arquitetura e a não dependência de um único fornecedor.
Quando chega a altura de atribuir culpas a ESET relembra que se os cibercriminosos e os agentes maliciosos não criassem ciberameaças, não precisaríamos de proteção em tempo real.