No âmbito das atividades profissionais, desenvolvedores, pentesters e especialistas em segurança enfrentam processos como Gestão de Vulnerabilidades (VM) e (Secure) SDLC.
Essas expressões ocultam diferentes conjuntos de práticas e ferramentas utilizadas, as quais estão entrelaçadas, embora seus consumidores sejam distintos.
O progresso técnico ainda não chegou ao ponto de substituir a análise de segurança de infraestrutura e software por uma única ferramenta.
É interessante entender por que isso acontece e quais problemas precisam ser enfrentados.
Processos
O processo de Gestão de Vulnerabilidades ('Vulnerability Management') visa o monitoramento contínuo da segurança da infraestrutura e da gestão de patches.
O processo de SDLC Seguro ('Secure SDLC') destina-se a apoiar a segurança da aplicação durante o desenvolvimento e a operação.
Uma parte semelhante desses processos é o processo de Avaliação de Vulnerabilidades — varrimento de vulnerabilidades.
A principal diferença entre a varredura em VM e SDLC é que, no primeiro caso, o objetivo é descobrir vulnerabilidades conhecidas em software de terceiros ou na configuração. Por exemplo, uma versão desatualizada do Windows ou uma string comunitária padrão para SNMP.
No segundo caso, o objetivo é identificar vulnerabilidades não apenas em componentes de terceiros (dependências), mas, acima de tudo, no código do novo produto.
Isso gera diferenças nas ferramentas e abordagens. A meu ver, a tarefa de encontrar novas vulnerabilidades em uma aplicação é muito mais interessante, uma vez que não se resume a identificar versões, coletar banners, tentar senhas, etc.
Para uma varredura automatizada de vulnerabilidades de aplicações de qualidade, são necessários algoritmos que considerem a semântica da aplicação, sua finalidade e ameaças específicas.
As ferramentas de varredura de infraestrutura, por outro lado, podem muitas vezes ser substituídas por um cronômetro, como disse O sentido é que, estatisticamente, você pode considerar sua infraestrutura vulnerável se não a atualizou, digamos, há um mês.
Ferramentas
A varredura, assim como a análise de segurança, pode ser feita tanto de forma black box quanto white box.
Black Box
No escaneamento black box, a ferramenta deve ser capaz de interagir com o serviço através das mesmas interfaces que os usuários utilizam.
Os scanners de infraestrutura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) procuram portas de rede abertas, coletam "banners", identificam versões de software instalado e buscam em seu banco de dados informações sobre vulnerabilidades nessas versões. Eles também tentam detectar erros de configuração, como senhas padrão ou acesso aberto a dados, e criptografias fracas SSL, entre outros.
Os scanners de aplicações web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) também conseguem identificar componentes conhecidos e suas versões (por exemplo, CMS, frameworks, bibliotecas JS). As etapas principais do scanner incluem crawling e fuzzing.
Durante o crawling, o scanner coleta informações sobre interfaces existentes da aplicação e parâmetros HTTP. Durante o fuzzing, dados mutacionados ou gerados são inseridos em todos os parâmetros detectados com o objetivo de provocar um erro e descobrir uma vulnerabilidade.
Esses scanners de aplicações pertencem às classes DAST e IAST — respectivamente, Dynamic e Interactive Application Security Testing.
White Box
No scan whitebox, as diferenças são maiores.
No processo de VM, os scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) frequentemente recebem acesso aos sistemas, realizando um scan autenticado. Assim, o scanner pode baixar as versões de pacotes instalados e os parâmetros de configuração diretamente do sistema, sem precisar adivinhar através dos banners dos serviços de rede.
O scan se torna mais preciso e completo.
Por outro lado, ao falar sobre o scan whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicações, geralmente se refere à análise estática de código e ao uso de ferramentas apropriadas da classe SAST — Static Application Security Testing.
Problemas
Existem muitos problemas com a varredura! A maioria deles enfrento pessoalmente ao fornecer serviços de construção de processos de escaneamento e desenvolvimento seguro, bem como na realização de análises de segurança.
Destaco 3 principais grupos de problemas, que são confirmados em conversas com engenheiros e gerentes de segurança da informação em diversas empresas.
Problemas de varredura de aplicações web
- Dificuldade de implementação. Os scanners precisam ser configurados e personalizados para cada aplicação, criando um ambiente de teste para os scans e integrando no processo CI/CD, para que sejam eficazes. Caso contrário, tratará-se de um procedimento formal inútil, que só emitirá alarmes falsos.
- Duração da varredura. Os scanners, mesmo em 2019, têm dificuldades em deduplicar interfaces e podem gastar dias escaneando mil páginas com 10 parâmetros em cada uma, considerando-as diferentes, apesar de serem controladas pelo mesmo código. Assim, a decisão de implantar em produção durante o ciclo de desenvolvimento precisa ser rápida.
- Recomendações escassas. Os scanners fornecem recomendações bastante gerais, e nem sempre o desenvolvedor consegue rapidamente entender como reduzir o nível de risco e, principalmente, se isso precisa ser feito imediatamente ou se pode esperar.
- Impacto destrutivo na aplicação. Os scanners podem facilmente realizar um ataque DoS na aplicação, além de podem criar um grande número de entidades ou modificar as existentes (por exemplo, criar dezenas de milhares de comentários em um blog), portanto, não se deve acionar um scan em produção sem pensar.
- Baixa qualidade na detecção de vulnerabilidades. Os scanners normalmente usam um conjunto fixo de cargas úteis (‘payloads’) e podem facilmente perder uma vulnerabilidade que não se encaixa no seu cenário de comportamento conhecido da aplicação.
- Incompreensão das funções da aplicação pelo scanner. Os scanners não sabem o que são ‘internet banking’, ‘pagamento’, ‘comentário’. Para eles, existem apenas links e parâmetros, então uma enorme gama de possíveis vulnerabilidades de lógica de negócios fica completamente descoberta; eles não conseguirão detectar um pagamento duplicado, visualizar dados alheios por ID ou inflacionar o saldo através de arredondamentos.
- Incompreensão da semântica das páginas pelo scanner. Os scanners não conseguem ler FAQs, não reconhecem CAPTCHAs, não conseguem deduzir sozinhos como se registrar, que é necessário fazer logout e como assinar solicitações ao modificar valores dos parâmetros. Como resultado, a maior parte da aplicação pode permanecer completamente não escaneada.
Problemas na varredura do código-fonte.
- Alarmes falsos. A análise estática é uma tarefa complexa, que requer muitos compromissos. Muitas vezes, é necessário sacrificar a precisão, e até mesmo scanners corporativos caros geram uma enorme quantidade de falsos positivos.
- Dificuldade de implementação. Para aumentar a precisão e a abrangência da análise estática, é necessário aprimorar as regras de varredura, e a escrita dessas regras pode ser muito trabalhosa. Às vezes, é mais fácil encontrar todos os locais no código com algum bug e corrigi-los do que redigir uma regra para detectar tais casos.
- Falta de suporte a dependências. Grandes projetos dependem de muitas bibliotecas e frameworks que expandem as capacidades da linguagem de programação. Se na base de conhecimento do scanner não há informações sobre locais perigosos ('sinks') nessas estruturas, isso se tornará um ponto cego, e o scanner não conseguirá entender o código.
- Duração da varredura. Buscar vulnerabilidades no código é uma tarefa complicada em termos de algoritmos. Portanto, o processo pode se prolongar e exigir recursos computacionais significativos.
- Baixa cobertura. Apesar do consumo de recursos e da duração da varredura, os desenvolvedores de ferramentas SAST ainda precisam recorrer a compromissos e não analisam todos os estados em que o programa pode estar.
- Reproduzibilidade das descobertas. Indicar uma linha específica e uma pilha de chamadas que levam à vulnerabilidade é ótimo, mas muitas vezes o scanner não fornece informações suficientes para verificar a vulnerabilidade externamente. Afinal, a falha pode estar em código morto, que é inacessível para um atacante.
Problemas na varredura da infraestrutura.
- Inventário insuficiente. Em grandes infraestruturas, especialmente aquelas geograficamente distribuídas, muitas vezes é mais difícil entender quais hosts precisam ser escaneados. Em outras palavras, a tarefa de varredura está intimamente relacionada à tarefa de gestão de ativos.
- Priorização deficiente. Scanners de rede frequentemente geram muitos resultados com vulnerabilidades que na prática não são exploráveis, mas formalmente têm um alto nível de risco. O consumidor recebe um relatório que é difícil de interpretar, tornando confuso o que deve ser corrigido primeiro.
- Recomendações escassas. Na base de conhecimento do scanner, muitas vezes há apenas informações muito gerais sobre vulnerabilidades e suas correções, então os administradores terão que recorrer ao Google. A situação é um pouco melhor com scanners whitebox, que podem fornecer um comando específico para correção.
- Trabalho manual. Em infraestruturas pode haver muitos nós, e, portanto, potencialmente muitas vulnerabilidades, cujos relatórios precisam ser analisados manualmente a cada iteração.
- Cobertura insuficiente. A qualidade da varredura da infraestrutura depende diretamente do volume da base de conhecimento sobre vulnerabilidades e versões de software. No entanto, , mesmo os líderes de mercado têm uma base de conhecimento não abrangente, e nas bases de soluções gratuitas existem muitas informações que não estão disponíveis para os líderes.
- Problemas com patching. Na maioria das vezes, o patching de vulnerabilidades na infraestrutura é uma atualização de pacote ou uma modificação de arquivo de configuração. Um grande problema aqui é que o sistema, especialmente os legados, pode se comportar de maneira imprevisível após a atualização. Basicamente, será necessário realizar testes de integração em uma infraestrutura ativa em produção.
Abordagens
O que fazer?
Mais detalhes sobre exemplos e como lidar com muitos dos problemas mencionados serão dados nas próximas partes, enquanto isso, indico as principais direções nas quais você pode trabalhar:
- Agregação de várias ferramentas de varredura. Com o uso adequado de múltiplos scanners, é possível aumentar significativamente a base de conhecimento e a qualidade da detecção. É possível encontrar até mais vulnerabilidades do que a soma de todas as scanners executados separadamente, e, ao mesmo tempo, avaliar com mais precisão o nível de risco e oferecer mais recomendações.
- Integração entre SAST e DAST. É possível aumentar a cobertura do DAST e a precisão do SAST através da troca de informações entre eles. A partir do código-fonte, é possível obter informações sobre rotas existentes, e com a ajuda do DAST, verificar se a vulnerabilidade é visível externamente.
- Machine Learning™. Em 2015, eu (e ) falei sobre a aplicação de estatísticas para dar aos scanners a intuição de um hacker e acelerar o seu desempenho. Isso definitivamente é um alimento para o desenvolvimento da análise automática de segurança no futuro.
- Integração de IAST com testes automatizados e OpenAPI. No contexto do pipeline CI/CD, é possível criar um processo de varredura baseado em ferramentas que funcionam como proxy HTTP e testes funcionais que operam via HTTP. Testes e contratos OpenAPI/Swagger fornecem ao scanner as informações ausentes sobre os fluxos de dados, permitindo a varredura do aplicativo em diferentes estados.
- Configuração correta. Para cada aplicativo e infraestrutura, é necessário criar um perfil de varredura apropriado, levando em consideração a quantidade e a natureza das interfaces e as tecnologias utilizadas.
- Customização de scanners. Frequentemente, um aplicativo não pode ser escaneado sem ajustes no scanner. Por exemplo, um gateway de pagamento, onde cada solicitação deve ser assinada. Sem a escrita de um conector para o protocolo do gateway, os scanners irão incessantemente fazer solicitações com a assinatura incorreta. Além disso, é necessário criar scanners especializados para tipos específicos de vulnerabilidades, como
- Gestão de riscos. O uso de diferentes scanners e a integração com sistemas externos, como Gestão de Ativos e Gestão de Ameaças, permitirá usar uma variedade de parâmetros para avaliar o nível de risco, de modo que a gerência consiga obter uma visão precisa da atual situação de segurança do desenvolvimento ou da infraestrutura.
Fique ligado e vamos revolucionar a varredura de vulnerabilidades!
Fonte: habr.com
