Como parte de suas atividades profissionais, desenvolvedores, pentesters e profissionais de segurança precisam lidar com processos como o Vulnerability Management (VM), (Secure) SDLC.
Sob essas frases, estão ocultos diferentes conjuntos de práticas e ferramentas usadas que estão interligadas, embora seus consumidores sejam diferentes.
O progresso técnico ainda não chegou ao ponto de substituir uma pessoa por uma ferramenta para analisar a segurança da infraestrutura e do software.
É interessante entender por que isso é assim e quais problemas você tem que enfrentar.
Os processos
O processo de gerenciamento de vulnerabilidades destina-se ao monitoramento contínuo da segurança da infraestrutura e do gerenciamento de patches.
O processo Secure SDLC ("ciclo de desenvolvimento seguro") foi projetado para oferecer suporte à segurança do aplicativo durante o desenvolvimento e operação.
Uma parte semelhante desses processos é o processo de Avaliação de vulnerabilidades - avaliação de vulnerabilidades, verificação de vulnerabilidades.
A principal diferença na varredura na VM e no SDLC é que, no primeiro caso, o objetivo é detectar vulnerabilidades conhecidas em software de terceiros ou em uma configuração. Por exemplo, uma versão desatualizada do Windows ou a sequência de comunidades padrão do SNMP.
No segundo caso, o objetivo é detectar vulnerabilidades não apenas em componentes de terceiros (dependências), mas principalmente no código do novo produto.
Isso gera diferenças de ferramentas e abordagens. Na minha opinião, a tarefa de encontrar novas vulnerabilidades no aplicativo é muito mais interessante, pois não se resume a versões de impressão digital, coleta de banners, classificação de senhas etc.
A verificação automatizada de alta qualidade das vulnerabilidades de aplicativos requer algoritmos que levam em consideração a semântica do aplicativo, seu objetivo e ameaças específicas.
O scanner de infraestrutura geralmente pode ser substituído por um temporizador, como
avleonov disse. O ponto é que, puramente estatisticamente, você pode considerar sua infraestrutura vulnerável se não a atualizar, digamos, um mês.
As ferramentas
A digitalização, assim como a análise de segurança, pode ser realizada como uma caixa preta ou branca.
Caixa preta
Ao digitalizar na caixa preta, a ferramenta deve poder trabalhar com o serviço através das mesmas interfaces pelas quais os usuários trabalham.
Os scanners de infraestrutura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose etc.) procuram portas de rede abertas, coletam "banners", determinam versões de software instaladas e procuram informações sobre vulnerabilidades nessas versões em sua base de conhecimento. Eles também tentam detectar erros de configuração, como senhas padrão ou acesso aberto a dados, cifras SSL fracas, etc.
Os scanners de aplicativos da Web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP etc.) também sabem como determinar os componentes conhecidos e suas versões (por exemplo, CMS, estruturas, bibliotecas JS). As principais etapas do scanner são rastejantes e difusas.
Durante o rastreamento, o scanner coleta informações sobre interfaces de aplicativos existentes, parâmetros HTTP. Durante a difusão, todos os parâmetros detectados são substituídos por dados mutados ou gerados para provocar um erro e detectar vulnerabilidade.
Esses scanners de aplicativos pertencem às classes DAST e IAST - Teste de Segurança de Aplicativos Dinâmicos e Interativos, respectivamente.
Caixa branca
As varreduras de caixa branca têm mais diferenças.
Durante todo o processo, os scanners de VM (Vulners, Incsecurity Couch, Vuls, Tenable Nessus etc.) geralmente recebem acesso aos sistemas, realizando uma verificação autenticada. Assim, o scanner pode baixar versões instaladas de pacotes e parâmetros de configuração diretamente do sistema, sem adivinhar sobre os banners dos serviços de rede.
A digitalização é mais precisa e completa.
Se falamos sobre digitalização de caixas brancas (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicativos, geralmente falamos sobre análise de código estático e o uso das ferramentas correspondentes da classe SAST - Static Application Security Testing.
Os problemas
Existem muitos problemas com a digitalização! Eu tenho que lidar com a maioria deles pessoalmente na estrutura de prestação de um serviço para a criação de processos de verificação e desenvolvimento seguro, bem como na realização de trabalhos de análise de segurança.
Vou destacar três grupos principais de problemas, confirmados por conversas com engenheiros e gerentes de serviços de segurança da informação em várias empresas.
Problemas de verificação de aplicativos da Web
- A complexidade da implementação. Os scanners precisam ser implantados, configurados, personalizados para cada aplicativo, alocados um ambiente de teste para varreduras e implementados no processo de CI / CD para serem eficazes. Caso contrário, será um procedimento formal inútil, emitindo apenas falsos positivos
- Duração da digitalização. Os scanners, mesmo em 2019, se saem mal com a desduplicação de interface e podem digitalizar milhares de páginas por 10 dias com 10 parâmetros em cada um, considerando-os diferentes, embora o mesmo código seja responsável por eles. Ao mesmo tempo, a decisão de implantar a produção dentro do ciclo de desenvolvimento deve ser tomada rapidamente
- Recomendações escassas. Os scanners fornecem recomendações bastante gerais, e nem sempre é possível para um desenvolvedor entender rapidamente como reduzir o nível de risco e, o mais importante, se é necessário fazê-lo agora ou não.
- Efeito destrutivo na aplicação. Os scanners podem muito bem executar um ataque de DoS no aplicativo e também podem criar um grande número de entidades ou modificar os existentes (por exemplo, criar dezenas de milhares de comentários em um blog), portanto, não inicie uma varredura sem sentido no prod.
- Detecção de vulnerabilidades de baixa qualidade. Os scanners geralmente usam uma matriz de cargas fixas e podem facilmente ignorar uma vulnerabilidade que não se encaixa no cenário conhecido de comportamento de aplicativos.
- O scanner não entende as funções do aplicativo. Os próprios scanners não sabem o que são “Internet banking”, “pagamento” e “comentário”. Para eles, existem apenas links e parâmetros, para que uma enorme camada de possíveis vulnerabilidades na lógica de negócios permaneça completamente descoberta, elas não tentarão escrever duas vezes, buscar dados de outras pessoas por ID ou aumentar o saldo por meio de arredondamentos.
- Incompreensão do scanner sobre a semântica da página. Os scanners não sabem ler as Perguntas frequentes, eles não sabem reconhecer captchas, eles mesmos não sabem como se registrar e precisam fazer login, que não pode clicar em "sair" e como assinar solicitações ao alterar os valores dos parâmetros. Como resultado, a maioria dos aplicativos pode não ser verificada.
Problemas de digitalização do código fonte
- Falsos positivos. A análise estática é uma tarefa difícil, para resolver a qual é necessário recorrer a muitos compromissos. Muitas vezes, você precisa sacrificar a precisão, e mesmo os scanners corporativos caros produzem uma enorme quantidade de falsos positivos
- A complexidade da implementação. Para aumentar a precisão e a integridade da análise estática, é necessário refinar as regras de varredura, e a gravação dessas regras pode levar muito tempo. Às vezes, é mais fácil encontrar todos os lugares do código com algum tipo de bug e corrigi-los do que escrever uma regra para detectar esses casos
- Falta de suporte à dependência. Projetos grandes dependem de um grande número de bibliotecas e estruturas que expandem os recursos da linguagem de programação. Se a base de conhecimento do scanner não tiver informações sobre "sumidouros" nessas estruturas, isso se tornará um ponto cego e o scanner simplesmente nem entenderá o código
- Duração da digitalização. Encontrar vulnerabilidades no código é uma tarefa difícil em termos de algoritmos. Portanto, o processo pode estar atrasado e exigir recursos computacionais significativos.
- Baixa cobertura. Apesar do consumo de recursos e da duração da verificação, os desenvolvedores das ferramentas SAST ainda precisam recorrer a compromissos e analisar nem todas as condições em que o programa pode estar.
- Reprodutibilidade dos achados. Apontar para uma linha específica e pilha de chamadas que levam a uma vulnerabilidade é bom, mas, na realidade, o scanner geralmente não fornece informações suficientes para verificar se há uma vulnerabilidade externa. Afinal, uma falha também pode estar em código morto, o que é inatingível para um invasor
Problemas de verificação de infraestrutura
- Inventário inadequado. Em grandes infra-estruturas, especialmente separadas geograficamente, geralmente é mais difícil entender quais hosts precisam ser verificados. Em outras palavras, a tarefa de verificação está intimamente relacionada à tarefa de gerenciamento de ativos.
- Má priorização. Os scanners de rede geralmente produzem muitos resultados com desvantagens que não são exploráveis na prática, mas formalmente seu nível de risco é alto. O consumidor recebe um relatório difícil de interpretar e não está claro o que precisa ser corrigido primeiro
- Recomendações escassas. A base de conhecimento do scanner geralmente possui apenas informações muito gerais sobre a vulnerabilidade e como corrigi-la, para que os administradores tenham que se armar com o Google. A situação é um pouco melhor com os scanners de caixa branca que podem emitir um comando específico para corrigir
- Handwork As infra-estruturas podem ter muitos nós, o que significa que há potencialmente muitas deficiências, relatórios nos quais devem ser desmontados e analisados manualmente a cada iteração
- Cobertura ruim. A qualidade da varredura de infraestrutura depende diretamente do volume da base de conhecimento sobre vulnerabilidades e versões de software. Ao mesmo tempo, verifica-se que mesmo os líderes de mercado não possuem uma base de conhecimento abrangente e há muitas informações nos bancos de dados de soluções gratuitas que os líderes não possuem
- Problemas com o patch. O patch mais comum para vulnerabilidades na infraestrutura é atualizar o pacote ou alterar o arquivo de configuração. O grande problema aqui é que o sistema, especialmente o legado, pode se comportar de maneira imprevisível como resultado de uma atualização. Em essência, você terá que realizar testes de integração da infraestrutura viva na produção
As abordagens
Como ser
Vou lhe contar mais sobre exemplos e como lidar com muitos desses problemas nas seguintes partes, mas por enquanto vou indicar as principais áreas em que você pode trabalhar:
- Agregação de várias ferramentas de digitalização. Com o uso correto de vários scanners, é possível obter um aumento significativo na base de conhecimento e na qualidade da detecção. Você pode encontrar ainda mais vulnerabilidades do que todos os scanners lançados separadamente, enquanto é possível avaliar com mais precisão o nível de risco e dar mais recomendações
- Integração do SAST e DAST. Você pode aumentar a cobertura e a precisão do DAST compartilhando informações entre eles. Na fonte, você pode obter informações sobre rotas existentes e, usando o DAST, pode verificar se a vulnerabilidade é visível de fora.
- Machine Learning ™ . Em 2015, falei sobre (e ainda ) sobre o uso de estatísticas para dar aos hackers a intuição dos scanners e acelerá-los. Definitivamente, este é o alimento para o desenvolvimento de futuras análises de segurança automatizadas.
- Integração do IAST com autotestes e OpenAPI. Na estrutura do pipeline de CI / CD, é possível criar um processo de varredura com base em ferramentas que funcionam como proxies HTTP e testes funcionais que trabalham com HTTP. Os testes e contratos OpenAPI / Swagger fornecerão ao scanner as informações ausentes sobre fluxos de dados e possibilitarão a varredura do aplicativo em vários estados
- Configuração correta. Para cada aplicativo e infraestrutura, você precisa criar um perfil de verificação adequado que leve em consideração o número e a natureza das interfaces, tecnologias usadas
- Personalização de scanners. Freqüentemente, um aplicativo não pode ser digitalizado sem finalizar o scanner. Um exemplo é um gateway de pagamento no qual cada solicitação deve ser assinada. Sem escrever um conector no protocolo do gateway, os scanners atendem as solicitações com a assinatura errada. Também é necessário escrever scanners especializados para um tipo específico de falha, como a Referência de objeto direto inseguro
- Gerenciamento de riscos. O uso de vários scanners e a integração com sistemas externos, como Asset Management e Threat Management, permitirá que você use muitos parâmetros para avaliar o nível de risco, para que o gerenciamento possa obter uma imagem adequada do status atual de segurança do desenvolvimento ou infraestrutura
Fique atento e vamos interromper a verificação de vulnerabilidades!