Para quem trabalha em cibersegurança, quando o telemóvel toca a uma sexta-feira costuma significar más notícias. Os cibercriminosos conhecem os nossos ritmos de trabalho e sabem em que dias têm mais probabilidades de êxito. Por isso, muitos ciberincidentes ocorrem às sextas-feiras. E temíamos o pior quando, no dia 19 de julho, o telefone não parava de vibrar.

Aqui começam as boas notícias. Primeiro, o telefone não vibrava por uma chamada do CERT da GMV, o seu serviço de monitorização de segurança e resposta a incidentes 7x24. Recebemos estas chamadas quando há um ciberincidente que está a afetar a própria GMV ou qualquer um dos seus clientes e os nossos colegas do CERT devem avisar que está a ocorrer. Assim, provavelmente não era um incidente grave, o que nos dava tempo para uma resposta mais pensada e mais fácil de aplicar. 

A segunda boa notícia é que a origem do som do telemóvel correspondia às comunicações internas próprias da atividade de um CERT. Isto é, que no fundo estavam a acontecer coisas, mas que estávamos a detetá-las e que teríamos capacidade de resposta precoce se o assunto se agravasse. No entanto, o volume destas comunicações era significativamente alto e merecia a pena investigar. Tratava-se, em todos os casos, de dados muito diferentes dos que o CERT costuma analisar. Alguns equipamentos e serviços que estão a ser vigiados pelo CERT estavam completamente parados. Na verdade, bastantes. Nenhum deles era da GMV, mas de alguns dos seus clientes monitorizados. A equipa do CERT já estava a investigar este ponto para encontrar os padrões de potenciais ataques ou falhas nos sistemas de transferência de informação. 

Enquanto isso, em paralelo, estavam a chegar outras notícias. Os profissionais da cibersegurança referem sempre o valor das redes de colaboração e cooperação. Alguns dos quadros de controlos de segurança mais difundidos estabelecem requisitos específicos para criar, unir e participar nestas redes de colaboração. Na sexta-feira, 19 de julho, estas redes demonstraram o seu valor. Vários grupos de colaboração estabelecidos em redes sociais ferviam de atividade. Tinham sido detetados problemas em servidores e postos de utilizador equipados com o software EDR do fabricante Crowdstrike. Estes equipamentos não respondiam nem estavam ativos. Alguns participantes partilhavam que os equipamentos estavam a apresentar uma das falhas mais temíveis num equipamento Windows, um ecrã azul. Estes ecrãs azuis ocorrem quando o estado de um equipamento Windows é instável e não é possível executar o sistema operativo corretamente. O equipamento é imediatamente parado como medida de segurança, mostrando no ecrã completamente azul uma mensagem de erro com a causa detetada do problema. O que parecia estranho era que estivesse a ocorrer simultaneamente em muitas organizações a nível mundial e em todos os tipos de equipamentos. Aparentemente, todos estes equipamentos tinham instalado o mesmo software EDR. Havia uma pista de investigação clara. 

Felizmente, a teoria confirmou-se rapidamente. O fabricante Crowdstrike comunicava oficialmente às 07:30, hora espanhola, através do seu portal de suporte, a existência de um alerta técnico sobre o seu produto “Falcon Sensor”, que é o agente que implementa em todos os equipamentos que está a proteger. Este alerta técnico indicou a existência de um erro no agente que causava uma falha no sistema Windows e que provocava o ecrã azul.

Através destas redes começaram também a ser difundidas algumas possíveis soluções, aplicando uma solução temporária (um workaround). A solução passava por iniciar o equipamento em modo “À prova de falhas” e, em seguida, eliminar manualmente um ficheiro chamado “C-00000291-*.sys”. A Crowdstrike iria reconhecer que este ficheiro correspondia a uma atualização que tinham realizado às 04:09 UTC (06:09 de Espanha) que continha este ficheiro errado que provocava a falha.

Neste momento, o CERT já estava a trabalhar com os clientes afetados, validando potenciais soluções e adaptando os sistemas de monitorização perante a avalanche de alertas. Eram mais boas notícias no meio de uma sexta-feira com um início tão pouco prometedor: 

• O possível ciberataque deveu-se a uma falha de funcionamento e não à ação de um ataque malicioso, pelo que a resolução do ciberincidente passaria por resolver o erro existente sem ser necessário preocupar-se com a reação do atacante antes das nossas ações de contenção, resposta e recuperação.

• Havia um candidato claro a ser a origem do erro: o autor do erro tinha-o reconhecido, tinha oferecido uma explicação que correspondia ao que estávamos a ver na GMV, bem como noutros atores, e tínhamos uma linha de atuação sólida para o resolver.

• Tudo isso tinha ocorrido num período de minutos, pelo que o incidente tinha uma solução rápida. De facto, já estava a começar a ser implementada.

• A comunicação estava a ser clara e fluida, em todos os sentidos, partilhando toda a informação possível, cumprindo os compromissos de confidencialidade aos quais estamos vinculados.

No entanto, nem tudo eram boas notícias. Outras organizações estavam a sofrer o problema de forma intensa, com a prática dos seus sistemas e serviços afetados e com a sua atividade paralisada. Surgiram alguns nomes de organizações destacadas e de operadores de infraestruturas críticas afetados. Um colega da GMV que estava a teletrabalhar comentou à sua família durante o pequeno-almoço que esta seria, provavelmente, a notícia de abertura nos telejornais desse dia. Era claro que o incidente ia ter um impacto na sociedade e não seria pequeno. Efetivamente, a Microsoft declarou que 8,5 milhões de computadores foram afetados pelo bug, com importantes consequências: atrasaram-se voos internacionais e foram interrompidas ligações de transporte público, alguns hospitais foram afetados tendo de cancelar provas médicas e, inclusivamente, algumas operações bancárias e de pagamento não puderam realizar-se...

E enquanto isso, o trabalho para solucionar o ciberincidente ia progredindo. O workaround confirmou-se como efetivo na maioria dos equipamentos. Os clientes da GMV estavam praticamente recuperados. Encontravam-se algumas situações em que era necessário aplicar workarounds alternativos, para casos de equipamentos em que tinha falhado o inicialmente prescrito. Havia equipamentos que estavam a falhar, mas que não tinham exatamente a mesma falha relatada. As organizações analisavam a informação que encontravam e que íamos partilhando. Parecia claro que, apesar de conhecida, em algumas empresas a solução iria demorar dias ou semanas. Colegas moviam fisicamente os equipamentos com USB para aplicar o workaround manualmente. Isso funcionava, mas precisava de tempo.

O resto já é história. Não vale a pena repeti-la.

O que vale a pena é dedicar tempo à análise que realizámos do incidente, como se agiu, como deveríamos ter agido, que ferramentas tínhamos à nossa disposição... E, sobretudo, o que poderíamos melhorar para próximas ocasiões.

A primeira conclusão é a necessidade de ter monitorização de segurança contínua 7x24 através de um serviço de CERT. Extensa, em tempo real, efetiva e rápida. Com pessoas preparadas, formadas e capacitadas para desempenhar este trabalho. E com capacidade de deteção dos eventos relevantes a vários níveis, para poder reagir quando seja necessário, mas também para poder estar prevenidos, se for possível, antes de ser necessário iniciar uma resposta. Sem um CERT ou um SOC competente, nada disso é possível. 

A segunda conclusão está nos nossos planos de resposta a incidentes. Neste caso, não tivemos de executá-lo. Não foi sequer necessário iniciar os procedimentos de escalada. Mas o plano de resposta funcionou com eficácia até onde foi necessário. Perfeito.

A terceira conclusão encontra-se nos nossos planos de continuidade de negócio. O que teria ocorrido se tivéssemos tido uma ampla implementação do software Crowdstrike? Sabemos que o teríamos detetado, mas teria o Plano de Continuidade sabido responder a esse cenário? Teria sido uma resposta eficaz? Existe algo que possamos melhorar? Felizmente, não tivemos de executar o plano, mas pudemos analisá-lo durante o incidente. Por precaução. E acrescentar ao plano algum aspeto adicional que nos dava uma resposta mais rápida, mais eficaz e que teria reduzido o impacto que teríamos sofrido.

Uma sexta-feira que vai ficar para a história. Esperamos que seja pelas lições que aprendemos e pelo aumento da consciencialização das empresas relativamente às suas necessidades de monitorização de segurança e de resposta a incidentes que nos preparem melhor para a próxima crise. 

Mariano J. Benito, Cibersecurity & Privacy Ambassador GMV 

Óscar Riaño, responsável pelo CERT da GMV