Gestão de vulnerabilidades é o processo utilizado pela empresa para avaliar, pontuar e reportar as vulnerabilidades presentes no ambiente de modo a corrigi-las e tornar a empresa mais segura.

Gestão de vulnerabilidades é um processo implementado por muitas empresas hoje em dia, e em constante crescimento, impulsionado pela LGPD (Lei Geral de Proteção de Dados) e por ataques de grupos hackers que vem aumentando muito no Brasil ultimamente. Com meus 10 anos de experiência na área de segurança da informação, dedicados à segurança ofensiva, balizam a minha opinião de que alguns pontos do processo de gestão de vulnerabilidade precisam ser desmistificados.

A Gestão de vulnerabilidades em sua origem tinha como objetivo identificar vulnerabilidades existentes através de scans automatizados que varrem portas, protocolos e serviços procurando por exploits ou vulnerabilidades conhecidas, mas que, com o tempo esse modelo tornou-se um pouco defasado…, mas por que será? Simples, atualmente temos tantos processos, mas TANTOS que apenas o scan tradicional de vulnerabilidades ficou ineficiente, hoje possuímos DAST, IaaS (Cloud Conformity), SAST, PENTEST. Como trabalhar com todas essas siglas e ter entregáveis?

Processo de gestão de vulnerabilidades antigo

O processo de Gestão de Vulnerabilidade nas empresas, além de uma política exigida por padrões de mercado, por exemplo o PCI-DSS, deve estar inserido na cultura corporativa e possuir um modelo único a se trabalhar. A cultura de gestão de vulnerabilidades vai além da área de segurança da informação, sendo imprescindível em outras áreas, principalmente para os que executam funções de devs, sysadmins, redes, a colaboração entre as áreas deve ser mútua. É recomendável que o processo de Gestão de vulnerabilidade se segmentado em Tipo de teste, Tempo de correção das vulnerabilidades encontradas e modelo de report apresentado, sendo necessário que este processo seja pode ser muito bem estruturado e seguido.

“Mas Thiago, isso significa que esse modelo irá funcionar para a minha empresa?”

Não necessariamente, mas se você utilizar essas 3 frentes já será um excelente passo para executar o trabalho com clareza e gerar indicadores que justifiquem, se necessário, investimento na área.

Mapa mental com as frentes do processo de gestão de vulnerabilidade

Tipo de teste – Segmentar os tipos de testes por tipo de avaliação e entregáveis. Isso facilita muito quando o ambiente passa por uma avaliação 360 (Scan de infra e rede + DAST + SAST + Pentest) porque após toda essa bateria de testes as vulnerabilidades precisam ser segmentadas e direcionadas para as equipes responsáveis (infraestrutura, redes, Desenvolvimento, arquitetura, segurança da informação) e para falar a língua de cada área se faz necessário desmembrar os “achados”. Um pentest possui um tipo de entregável que não é apresentado pelo SAST que não é apresentado pelo Scan de vulnerabilidades tradicional.

“Mas vulnerabilidade é vulnerabilidade não?”

Não, quando estamos falando de resolução das vulnerabilidades podemos falar desde atualização de middleware (JBoss, Apache, IIS etc.) quanto correção de código em nível de aplicação e “descer” o nível para explicarmos que o campo de um formulário não está sanitizando os inputs e isso pode direcionar a uma injeção de código que leve acesso ao banco de dados. Para isso, é necessário segmentar o tipo do teste e seus entregáveis. Durante a realização dos testes é sempre bom frisar a necessidade e apoio das áreas responsáveis pelos sistemas, em alguns casos, precisamos de credenciais, liberação em regras em dispositivos como firewall, criação de rotas de acesso ou até ser uma regra de exceção no IPS. Cada teste tem sua finalidade e modo de execução então é sempre bom termos apoio das áreas principalmente de desenvolvimento.

Mapa mental com tipo de testes

Tempo de Correção – Quanto tempo é necessário para corrigir uma vulnerabilidade crítica? Se formos olhar a recomendação do CISA (CyberSecurity & Infraestructure Security Agency) para sistemas expostos para internet a correção seria de 15 dias após a detecção da vulnerabilidade crítica e 30 para vulnerabilidades de severidade alta. Esse tempo é aceitável para a equipe de desenvolvimento que possui “um time enxuto” responsável pela aplicação?
Considerando as demandas do negócio (que não tem fim) pode não ser suficiente ou como diria um jargão antigo “um pratinho vai cair”, o problema desses pratinhos caírem é que vai precisar de mais uma pessoa na equipe só para “varrer” esse chão cheio de prato quebrado… Ter um balanço entre as entregas solicitadas e a correção das vulnerabilidades é algo difícil de ser executado e boas práticas são realmente boas a serem seguidas, fugir um pouco da regra é bom, mas tudo ser exceção é um problema. A sua área tem de recurso humano e computacional suficiente para validar em paralelo? Lembre-se que o rapaz de SI que faz o processo de gestão de vulnerabilidade está ali pra facilitar e ajudar você, então se tiver dúvidas ou quiser discutir a resolução da vulnerabilidade é responsabilidade dele te “guiar” pelo melhor caminho, seja para mitigar ou corrigir a vulnerabilidade.

Vulnerabilidades que ultrapassam o tempo acordado podem gerar as famigeradas cartas de risco, um diretor ou presidente ter que assinar uma carta dessa, meu amigo Dev, não é uma coisa que você vai gostar de presenciar. Para que a carta de risco não seja realidade para você, me ajuda, se ajuda, nos ajudem a correr atrás do prazo, a responsabilidade da resolução é sua e isso não vai mudar, a diferença é ter a equipe de SI próxima para apoiar nessas situações.

Mapa mental – Tempo de correção

Modelo de report – Nos reports, as áreas solucionadoras devem ser sempre direcionadas a sua resolução e o seu risco, de forma resumida, como resolver esse problema e se alguém descobrir e explorar essa vulnerabilidade, o que vai me dar mais dor de cabeça? Os relatórios tradicionais apresentam as informações abaixo:

• Nome da Vulnerabilidade
• Severidade
• Local onde identificada a vulnerabilidade
• Link de referência sobre a vulnerabilidade
• Como resolver a vulnerabilidade

Essas informações são suficientes para as equipes?
Não!

Mas porque não?

Porque se temos um ambiente com muitas vulnerabilidades vira um CAOS gerenciar isso, então como podemos fazer? Parte da equipe responsável por executar os scans ou testes, montam um plano de remediação de vulnerabilidades, que é uma avaliação feita nas vulnerabilidades que foram encontradas com o objetivo de identificar a ação que após executada resolva a maior quantidade de vulnerabilidades possível. Por exemplo, um plano de remediação, em um Scan de vulnerabilidade identifica 80 vulnerabilidades, dessas, 50 estão relacionadas a versão do PHP e 30 são do Sistema Operacional (Windows Server 2008), então como exemplo podemos ter a tabela abaixo como plano de remediação:

Mapa mental – Modelo de report

Hoje existem no mercado ferramentas de scans que já realizam esse tipo plano de forma automática (Tenable, Rapid7, Outpost, etc.) assim como também existem ferramentas que servem para isso como o Faraday que consegue receber informações de scans como do Tenable e gerar não só esses planos como pontuação de risco executivo, etc. Mas e agora? Fiz o plano de remediação, entreguei o relatório as áreas solucionadoras, o que faço? Acompanha a resolução podendo ser através de chamados no ITSM, através de e-mail (não recomendo a empresas grandes), ou indicadores caso consiga conectar os resultados a um painel e apresentar isso a diretoria e presidência de sua empresa.

Em uma empresa que tem em seu processo a realização de pentest interno ou externo é sempre bom ter os indicadores da quantidade de testes, vulnerabilidades encontradas, resolução das vulnerabilidades e segmentar isso em uma apresentação anual ao corpo diretivo agrega valor a todas as áreas assim como justifica investimento. Apenas um “hands up” pentest em sua grande maioria não vem com plano de remediação, então se você responsável por fazer o repasse do resultado que tal colocar o que aprendeu aqui em prática?

Hoje você realiza gestão de vulnerabilidades em sua empresa? Utiliza outro método? Comenta e me chama para discutirmos o que seria um plano interessante. Estou sempre disposto a novas ideias, assim como discutir temas como esse. 😊

Referências:

https://www.cisa.gov/publication/remediate-vulnerabilities-internet-accessible-systems

Imagens em melhor definição abaixo:

Views: 708