Segurança

Lidando com vulnerabilidades

Há 45 anos, antes dos computadores pessoais, da world wide web, da Internet como conhecemos hoje e quando os especialistas em computação ainda eram considerados uma espécie de gênios, as pessoas comuns tiveram acesso à ideia de que mesmo uma nave de guerra capaz de destruir planetas com um único tiro poderia ser destruída por uma pequena falha de projeto. O ano era 1977, e adultos e crianças viam nos cinemas a Estrela da Morte ser destruída no primeiro filme de Guerra nas Estrelas (Star Wars). Para quem esqueceu, a vulnerabilidade era um buraquinho de exaustão do reator da nave que permitia sua destruição. Mas a única possibilidade de explorá-la seria jogando duas bombas (tecnicamente dois torpedos de prótons). Tal brecha era desconhecida, pois fora plantada por um engenheiro traidor do Império, e estava documentada em um arquivo guardado na fortaleza em um planeta. Mesmo que Darth Vader a conhecesse, talvez não se preocupasse. Primeiro, era necessário obter os arquivos. Segundo, os torpedos teriam que ser lançados por uma nave atacada por todos os lados contra um alvo extremamente pequeno, tarefa que apenas um Jedi conseguiria executar, em uma época em que eles não existiam mais.

Nas quase cinco décadas seguintes as vulnerabilidades continuaram a ser identificadas e exploradas, seja na vida real ou em filmes como Missão Impossível. O trabalho de corrigi-las é normalmente associado à tarefa de enxugar gelo, o que não deixa de ser verdade, com a exceção de que o “gelo” das vulnerabilidades nunca derrete por completo. Uma grande parte do trabalho inclui conscientizar os usuários sobre elas, e dar-lhes o real entendimento de como lidar com o tema, que naturalmente assusta por estar associado a tecnologias complexas. No entanto, o trabalho não se limita à parte técnica, e inclui também pessoas e processos por eles desenhados e executados. Nestes os humanos são os protagonistas.

O que torna o trabalho complicado é a dura realidade das vulnerabilidades serem inerentes a qualquer sistema, sendo o conceito de sistema aqui utilizado o agrupamento de hardware, software, pessoas e processos que compõem um conjunto com determinado objetivo. Infelizmente, qualquer sistema é livre de vulnerabilidades até que a próxima seja encontrada. Dessa primeira ideia deriva um princípio essencial: a busca de um sistema, seja ele qual for, à prova de brechas é algo utópico, que resultaria em um sistema que nunca seria lançado, simplesmente por ser impossível. Por um lado, todos os componentes devem constantemente buscar por pontos fracos. Por outro, todos devem aprender a conviver com elas. A existência de brechas (ou a possibilidade de que existam) não inviabiliza um sistema. Um bom exemplo é uma vulnerabilidade no chip M1 dos modelos mais novos de computadores Apple, descoberta por pesquisadores do MIT –Massachusetts Institute of Technology (https://bit.ly/3Ozb9EP). Entretanto, a vulnerabilidade exige condições específicas para ser usada, em conjunto com um bug de software. Devem os usuários de modelos Apple com M1 desligar seus computadores? É claro que não. É diferente de um bug de sistema operacional que pode ser facilmente explorado quando estamos conectados à Internet. Dessa forma, a falha, única, não inviabiliza todo o conjunto.

Um dos erros no tratamento de vulnerabilidades é justamente esquecerse do todo. A falha em um único componente pode ser neutralizada por outro componente, e a análise deve ser sempre em conjunto. Até porque o oposto também pode ser verdadeiro. Uma pequena brecha com pouco risco individual pode comprometer todo um sistema, o que a tornaria de alto risco. Um artigo da Cyberis, empresa inglesa de consultoria em segurança da informação, relata como uma vulnerabilidade de baixo risco permitiu em um teste o acesso a servidores de banco de dados (https://bit.ly/ 3yanAkZ). Dessa forma, devemos correr e corrigir todas as vulnerabilidades, mesmo as de baixo risco? Seria o mundo ideal, porém impraticável na vida real das empresas. A solução é priorizá-las, e a visão de todo é somente uma das maneiras de fazê-lo.

Outra forma de priorizar é pelo nível real de risco que uma vulnerabilidade representa, o que pode variar de empresa para empresa e de setor para setor. E nesse trabalho às vezes as aparências enganam. Uma fragilidade considerada de risco médio e complexa para explorar pode ser deixada em segundo plano comparando-a com uma de alto risco e mais fácil de ser explorada. Mas, e se a primeira afeta os computadores de maior importância da companhia enquanto a segunda apenas servidores menos críticos? E se a de médio risco estiver sendo explorada por algum ataque de larga escala ocorrendo em um determinado momento, enquanto a de alto risco está sendo pouco usada por atacantes? Qual devo corrigir primeiro? A conclusão é que o real risco de uma brecha varia, de acordo com o dia e hora, e com o ambiente tecnológico de minha empresa. Fazer esse trabalho de priorização manualmente é virtualmente impraticável, e por isso

Esta seção aborda aspectos tecnológicos da área de segurança da informação. Os leitores podem enviar suas dúvidas para a Redação de RTI, e-mail: inforti@arandanet.com.br.

fabricantes têm investido nos últimos anos em sistemas automatizados de gestão. E aí incorremos em um erro fatal: ignorar as vulnerabilidades de processo e humanas.

Nenhum sistema é unicamente composto de hardware e software. Se o usuário falhar, todo o esforço técnico pode ir por água abaixo. Erros de configuração e uso, credenciais anotadas ou compartilhadas com outras pessoas, processos falhos que deixam brechas, para citar os mais comuns nas últimas décadas, podem ser tão danosos quanto as falhas técnicas. Assim como é impossível eliminar vulnerabilidades técnicas, é impossível eliminar a possibilidade de falhas humanas. Errar é humano, já diz o ditado. Mas como lidamos com sistemas, é possível fazer com que componentes técnicos e humanos se neutralizem, ou ao menos reduzam os danos. Podemos limitar o acesso dos usuários por tecnologias como microssegmentação, reduzindo o dano de um erro humano, assim como podemos emitir alertas para que operadores intervenham quando um software está se comunicando fora de seu padrão habitual. Lidar com vulnerabilidades a partir da visão do todo, ou de sistema, é uma maneira efetiva de reduzir a possibilidade de um impacto significativo em nossas empresas, a não ser que entre os adversários estejam Ethan Hunt e sua equipe de Missão Impossível.

Marcelo Bezerra é gerente técnico de segurança para América Latina da Cisco. Com formação nas áreas de administração e marketing, Bezerra atua há mais de 15 anos em redes e segurança de sistemas. E-mail: marcelo.alonso.bezerra@gmail.com.