Busca de Vulnerabilidades de Software: O Mínimo Essencial ou o Máximo Luxo?

Olá, Habr! Meu nome é Artem, e sou o chefe do centro de expertise técnica para análise de segurança na AKTIV.CONSULTING. Hoje, quero abordar o tema da busca de vulnerabilidades de software durante a exploração e entender o que isso representa na prática: o mínimo essencial ou o máximo luxo. Nosso foco será o processo 24 do GOST R 56939-2024 para o desenvolvimento seguro de software (BRPO, RBPO, DevSecOps).

Os Três Pilares do Desenvolvimento Seguro de Software (BRPO/RBPO)

Para começar, vamos relembrar os três métodos principais de análise de vulnerabilidades de software: estático, dinâmico e composicional. A análise estática é a análise do código-fonte (teste de "caixa branca"). A análise dinâmica é o pentest clássico, onde testamos uma aplicação já em execução em "caixa preta" ou "caixa cinza". A análise composicional envolve a varredura e a busca por vulnerabilidades nos componentes utilizados, o que permite expandir a superfície de ataque.

No entanto, conhecer esses métodos não é suficiente. É crucial entender quem e como os aplicará na prática, além de decidir o que é melhor usar: scanners de vulnerabilidade automatizados ou especialistas humanos. Vamos investigar.

Busca Automatizada vs. Manual: Como Realizar Análise de Vulnerabilidades de Software

Na minha opinião, nas realidades atuais, a busca automatizada de vulnerabilidades é o mínimo essencial necessário. Há 3-4 anos, para mim, como pentester, essa afirmação seria inaceitável, mas o mundo mudou. Hoje, os scanners de vulnerabilidade evoluíram significativamente, aprenderam a encontrar problemas reais e cobrem uma vasta gama de tarefas. Em um artigo anterior no Habr, fiz uma compilação desses scanners. Qualquer pentester pode utilizá-los ao auditar infraestrutura e o perímetro externo.

No entanto, a configuração precisa das ferramentas é importante, pois o uso inexperiente ou excessivamente intenso pode prejudicar o próprio sistema. Os scanners devem ser usados com cuidado, selecionando os parâmetros corretamente, ou confiando essa tarefa a profissionais.

Idealmente, a busca automatizada de vulnerabilidades deve levar a duas componentes:

1. Pentest Contínuo (Pentest Continuous) Escaneamento regular do sistema ou software de forma automatizada, com a geração de relatórios que mostram a dinâmica (quais novas vulnerabilidades surgiram, quais portas foram abertas, o que mudou no software, etc.).
2. Monitoramento (SOC) Acompanhamento tanto de novas vulnerabilidades quanto daquelas que podem ser usadas para atacar seu software e sistema de informação. Isso fornece um quadro atualizado das ameaças em tempo real.

E se chamamos a busca automatizada de vulnerabilidades de mínimo necessário, a busca manual de vulnerabilidades pode ser considerada o máximo luxo. Há poucos especialistas qualificados no mercado, e o trabalho deles é caro. Esses especialistas são atraídos não para cumprir formalidades, mas para uma verificação real da segurança do software.

Com base na minha experiência, posso dizer que esses especialistas frequentemente encontram o que foi negligenciado, mesmo por clientes que levam a segurança da informação a sério. É importante lembrar que sistemas totalmente protegidos não existem (exceto talvez um computador em um bunker sem internet). A experiência, o pensamento crítico e a perspicácia de um pentester permitem construir cadeias de ataque para alcançar os resultados desejados de acesso à informação ou ao sistema.

Etapas da Análise de Vulnerabilidades de Software: Como o OWASP TOP-10 Pode Ajudar

O processo de teste de vulnerabilidades pode ser dividido em quatro etapas-chave:

• Reconhecimento: Nesta fase, é importante entender o que estamos atacando e encontrar todos os pontos de entrada potenciais, ou seja, expandir a superfície de ataque ao máximo.
• Busca de Vulnerabilidades: Após obter os resultados do reconhecimento, buscamos vulnerabilidades com base nas versões do software, no banco de dados de vulnerabilidades de segurança da informação conhecidas (CVE) e na experiência pessoal.
• Exploração de Vulnerabilidades e Realização de Ataques: Aqui, verificamos as vulnerabilidades encontradas e tentamos explorá-las, ou seja, penetrar profundamente no sistema, expandir para nós adjacentes, aumentar privilégios, etc.
• Relatório: A etapa mais importante, cujo valor reside nas recomendações. O relatório inclui tanto conselhos gerais para melhorar a segurança do software e do sistema de informação quanto medidas específicas para cada vulnerabilidade encontrada.

Para descrever as vulnerabilidades principais, vamos usar o OWASP TOP-10. Embora esta lista de vulnerabilidades tenha sido criada para a web, todos os problemas descritos são característicos para a maioria dos tipos de software:

• A01:2025 Quebra de Controle de Acesso: Problemas relacionados a permissões inadequadas.
• A02:2025 Configuração Incorreta de Segurança: Configurações padrão inseguras ou permissões excessivas.
• A03:2025 Falhas na Cadeia de Suprimentos de Software: Vulnerabilidades introduzidas através de componentes de terceiros ou bibliotecas.
• A04:2025 Falhas Criptográficas: Erros na implementação ou configuração de criptografia, como SSL/TLS.
• A05:2025 Injeção de Código Malicioso: Permite que um atacante execute código não autorizado.
• A06:2025 Design Inseguro: Falhas no design arquitetural que criam vulnerabilidades.
• A07:2025 Falhas de Autenticação: Mecanismos de login fracos ou contornáveis.
• A08:2025 Falhas de Integridade de Software ou Dados: Manipulação de dados ou código sem detecção.
• A09:2025 Falhas de Registro e Monitoramento de Segurança: Incapacidade de detectar ou responder a incidentes.
• A10:2025 Processamento Incorreto de Condições de Exceção: Erros na forma como o software lida com situações inesperadas, que podem levar a vazamentos de memória ou outros acessos não autorizados.

Como Implementar um Processo de Busca de Vulnerabilidades

A implementação de um processo de busca de vulnerabilidades durante a exploração é uma tarefa complexa. Uma das principais dificuldades é comunicar aos desenvolvedores novas responsabilidades e a necessidade dessas ações. Surge a questão: a quem confiar o trabalho de implementação? Existem dois caminhos principais:

Primeiro, o Security Champion: um indivíduo da equipe de desenvolvimento que está interessado em segurança, "apaixonado" por essa ideia. Ele se capacita e implementa processos de proteção na fase de criação do software, buscando minimizar o número de vulnerabilidades. Segundo, consultoria, ou seja, o envolvimento de pentesters externos.

Qual a diferença entre um Security Champion e um pentester? Eles têm mentalidades fundamentalmente diferentes. O pentester gosta de resolver quebra-cabeças, e a busca por vulnerabilidades se transforma para ele em uma missão com elementos destrutivos (encontrar, quebrar, penetrar). O Security Champion, por outro lado, é uma espécie de construtor. Sua tarefa é criar uma "fortaleza" e prevenir vulnerabilidades desde a fase de desenvolvimento.

Nenhuma das abordagens é ideal. O fator humano não pode ser excluído, por isso recomendo usar uma combinação de métodos. Deixe o Security Champion construir os processos dentro da empresa, e os pentesters externos, na fase final, procurem o que foi negligenciado, ajustem o sistema e compartilhem experiência com o especialista interno.

Casos Práticos

Para concluir, apresento alguns exemplos notáveis e ilustrativos da minha prática.

• Caso 1. Implementação de BRPO/RBPO em um grande fornecedor de SZI: O cliente iniciou a implementação dos processos GOST por conta própria, entendendo que o padrão ainda não era obrigatório. Apesar disso, desde a definição da tarefa até a criação do grupo de trabalho, passou-se um tempo considerável. Este caso mostrou que, mesmo com a disposição do negócio, a implementação requer paciência e tempo para resolver questões organizacionais.
• Caso 2. Implementação de desenvolvimento seguro de software após um incidente: Um grande fornecedor começou a implementar processos de BRPO/RBPO apenas após sofrer um incidente real. A situação forçou a empresa a repensar sua abordagem à segurança e demonstrou a importância da SI. No entanto, é melhor não esperar por tal caso e seguir o exemplo do primeiro caso.
• Caso 3. Pentest de um sistema de comércio: Ao testar um grande sistema de comércio, nos deparamos com uma situação interessante. Na primeira varredura e análise, nenhum scanner automatizado encontrou vulnerabilidades. Nem de nível alto, médio ou baixo. O cliente estava confiante em sua proteção e convicto de que não encontraríamos nada. No entanto, na fase de pesquisa manual, descobri cerca de 10 vulnerabilidades de nível médio e baixo. Individualmente, pareciam inofensivas, mas a combinação de cinco delas permitiu construir um vetor de ataque completo e comprometer totalmente o sistema de informação. Este caso demonstra claramente por que é importante prestar atenção a vulnerabilidades de qualquer nível de risco e abordá-las com responsabilidade.

Conclusão

A busca automatizada de vulnerabilidades hoje é o mínimo essencial necessário, que deve ser configurado corretamente e operar continuamente. Mas não se deve confiar apenas em scanners: a busca manual por especialistas experientes continua sendo o máximo luxo, permitindo encontrar o que foi negligenciado. A opção ideal seria combinar a busca automatizada regular com o envolvimento de pentesters para uma análise minuciosa de vulnerabilidades. Essa abordagem abrangente fornecerá a avaliação mais precisa da segurança do seu software. Um guia para análise de segurança pode ser encontrado aqui.