Apagão cibernético: "Não há como evitar que pane volte a acontecer", diz comitê gestor da internet

Diretor-presidente do Núcleo de Informação e Coordenação do Ponto BR, afirma que esse tipo de apagão deve acontecer "de tempos em tempos", mas pode ser minimizado

Mais cedo ou mais tarde um apagão cibernético como a que paralisou aviões, sistemas bancários e até rede de televisão nesta sexta-feira (19) deve voltar a acontecer.

O prognóstico que pode ser não muito animador é de Demi Getschko, diretor-presidente do Núcleo de Informação e Coordenação do Ponto BR (NIC.br) e representante de notório saber em Internet do Comitê Gestor da Internet no Brasil (CGI.br).

Em entrevista ao Globo, ele diz que os "bugs", a expressão para falhas ou erros em softwares, acontecem "de tempos em tempos", mas poderiam ser minimizados com testes em ambientes controlados.

O cientista que é considerado um dos "pais" da internet no Brasil avalia que a falha da empresa de cibersegurança CrowdStrike é um sinal do "risco que corremos" em viver em um mundo baseado em tecnologias complexas.

Por isso, afirma, é preciso ter racionalidade — e talvez não confiar na invencibilidade de sistemas que podem afetar grandes operações.

Uma das lições desse episódio, na opinião do cientista, é que esses sistemas de segurança cibernética precisam passar sempre por “salas de teste” antes de começarem a rodar.

Ele explica ainda que as características desses sistemas, que ficam de forma “íntima” ligados aos sistemas operacionais, ajudam a entender porque o estrago dessa falha foi tão grande e critica a concentração do mercado de tecnologia em poucas empresas globais.

Por que o apagão tomou essa proporção?
Qualquer software pode ter "bugs" de tempos em tempos. Nesse caso, aparentemente, veio de uma atualização que não foi bem pensada. Mas o fato é que a falha mora na parte central do sistema, portanto é mais complicada de ser corrigida.

Do que sabemos até aqui, foi um erro operacional, de desenvolvimento. Obviamente, eliminá-lo pode ser trabalhoso. E o defeito que ele apresenta é uma bloqueio geral, o que é bastante ruim. Se fosse somente uma não funcionalidade do antivírus, seria mais simples.

O grave nesse caso é que deixou de funcionar o sistema hospedeiro (o Windows).

Foi um erro também da Microsoft?
Os programas de segurança (como o da CrowdStrike) são muito íntimos da máquina, eles conhecem todos os detalhes porque precisam analisar se há algo estranho "morando" lá dentro, se há alguma invasão.

O programa precisa ter privilégios no sistema operacional para conhecer suas entranhas. E o fabricante do sistema operacional (Microsoft) deu esses privilégios. Por isso é mais grave. É algo que está intimamente ligado ao sistema operacional.

O efeito tão vasto poderia ter sido evitado?
Para sistemas grandes, como banco ou companhia aérea, seria interessante não colocar nada em produção antes de um mini teste original, porque erros acontecem. O que se recomendaria nesses casos é que antes de implementar algo em produção a empresa o coloque em um ambiente restrito para checar se não há um efeito colateral estranho.

Deveria ficar em uma espécie de 'antesala' da operação para, depois de aprovado, ser colocado no ar. Colocar no ar imediatamente o que chegou é ter uma confiança cega e absoluta, mas problemas acontecem.

Como será a retomada dos sistemas afetados?
Pelo que foi divulgado (pela Crowdstrike) o problema na atualização foi encontrado e, teoricamente, as empresas têm a solução a mão.

O que preocupa um pouco mais é que o usuário individual vai ter que fazer o que se chama de "bootar" a máquina (inicializar ou reiniciar o sistema operacional) de modo seguro e remover o arquivo defeituoso. Esse é um trabalho manual.

O que esse caso nos diz sobre a dependência global a poucas empresas de tecnologia?
Esse é um fato. Dependemos de poucas empresas. Sempre que possível, o ideal é não colocar todos os ovos na mesma cesta. Mas isso é difícil de fazer, já que temos poucas empresas que dominam o mercado. Vou dar um exemplo particular.

Nós, no NIC.BR, usamos um software de código aberto (que pode ser modificado pelo usuário), em que pelo menos você tem uma alternativa diferente. Uma centralização em que você depende de um ponto único de falha, quando essa falha acontecer, você não tem como se livrar dela.

Quando você tem um único provedor de acesso a internet, por exemplo, você vai ficar sem acesso a rede se ele cair.

O que sempre insistimos aqui no NIC é que uma instituição qualquer que se conecte consiga ganhar o status de sistema autônomo onde ele tem alternativas de saída. Porque se dar um problema em um sistema, a rede é dinamicamente ajustável e configurável. Ele não é um pedaço da rede mãe porque é autônomo.

Quais lições desse caso?
É preciso que haja mais cuidado ao colocar algo em produção. Mas não há como evitar que isso aconteça de tempos em tempos. Espero que não em dimensões tão grandes quanto essas, mas certamente mais cedo ou mais tarde algo desse tipo vai voltar a acontecer.

Esse caso nos mostra que, em um mundo baseado em tecnologias complexas e cada vez mais longe do nosso entendimento, há que se ter um uso racional delas e saber do risco que corremos. Nós dependemos delas e nós temos pouquíssimo controle sobre elas.

Então o máximo que podemos tentar fazer é não cair cegamente em qualquer alteração imediata e se possível testá-la antes em um ambiente restrito. Mas é preciso saber que isso pode acontecer. Por artifícios maliciosos de hackers ou por erros humanos, que é o que parece ter acontecido nesse caso.