Dando sequência à série de publicações sobre o framework OWASP SAMM (Software Assurance Maturity Model), neste artigo iremos abordar a prática de Testes de Segurança (Security Testing), dentro do domínio de Verificação (Verification). Caso você ainda não tenha noção sobre a composição e organização do framework, recomendo a leitura do nosso primeiro artigo que explica em mais detalhes neste link.
Você também pode ouvir esse conteúdo:
Analisando a imagem que segue, podemos perceber que o framework OWASP SAMM possui 5 domínios principais, cada qual com 3 diferentes práticas de segurança e essas segmentadas em dois diferentes fluxos A e B, sendo os fluxos divididos em 3 níveis de maturidade em segurança.
Imagem 1: Composição e organização do framework OWASP SAMM 2.0
No caso da prática Testes de Segurança (Security Testing), temos:
- Patamar Escalável – Fluxo A (Scalable Baseline – Stream A)
Este fluxo trabalha a gestão dos testes automatizados. O objetivo é mostrar como a utilização de ferramentas como SCA, SAST, DAST e outros, é importante para cobrir uma vasta área de códigos escritos em diferentes módulos de aplicações.
- SCA (Software Composition Analysis) – Compara toda a estrutura de bibliotecas que compõem o software com uma lista atualizada de bibliotecas reportadas como vulneráveis e recomenda substituições ou atualizações;
- SAST (Static Application Security Test) – É um teste feito nas linhas de código do software, antes das fases de construção e implantação. Faz uma varredura em busca de padrões de código já conhecidos por conterem vulnerabilidades;
- DAST (Dynamic Application Security Test) – É um teste executado com a aplicação já implantada e em funcionamento. A ferramenta dispara várias inserções de códigos maliciosos e observa o seu comportamento para identificar possíveis falhas passíveis de exploração.
O primeiro nível de maturidade é alcançado quando estes testes estão completamente integrados à esteira CI/CD sendo disparados automaticamente a cada alteração liberada no código da aplicação.
As ferramentas automatizadas geralmente podem ser reprogramadas para uma melhor assertividade. De acordo com que vão gerando seus resultados, é possível melhorar seus filtros, tornando-as mais eficientes em suas análises e aumentando assim o nível de maturidade em segurança para o segundo nível.
Em seu nível de maturidade mais elevado, os testes já estão cobrindo todos os módulos da aplicação, são disparados automaticamente e os filtros das ferramentas são constantemente aprimorados, aumentando assim a precisão dos resultados com redução dos falsos positivos.
- Entendimento Profundo – Fluxo B (Deep Understanding – Stream B)
Este é o fluxo do trabalho manual, do profissional de segurança incumbido da tarefa de revisão de código e do pentester. Como a revisão manual é lenta e difícil de escalar, os revisores priorizam os componentes de teste com base em seu risco, mudanças relevantes recentes ou lançamentos importantes futuros.
Exemplos comuns de funcionalidade de alto risco incluem módulos de autenticação, pontos de imposição de controle de acesso, esquemas de gerenciamento de sessão, interfaces externas e validadores de entrada.
O primeiro nível de maturidade em segurança é alcançado quando os profissionais de segurança trabalham nos processos de revisão de código e análise de findings.
Os findings são o pré-estágio de uma vulnerabilidade detectada. É o resultado dos testes automáticos executados pelas ferramentas de automação, e podem ser descartados em seguida como falsos-positivos ou reportados como vulnerabilidades reais.
Para aumentar o nível de maturidade em segurança para o segundo nível, a organização é recomendada a trabalhar com pentesting das aplicações em ambientes de homologação, recomenda-se também a promoção de programas de “bug bounty”, onde a aplicação é exposta e hackers são convidados a atacá-la a fim de descobrirem as vulnerabilidades existentes em troca de prêmios.
No seu estágio mais elevado de maturidade, a organização já possui processos de testes de segurança totalmente integrados à esteira de produção, suas ferramentas de testes são constantemente treinadas e aprimoradas, entregando resultados cada vez mais precisos.
Com isso, os profissionais de segurança conseguem cada vez mais participar dos processos de refinamento de arquitetura segura, aplicação dos requisitos de segurança no desenvolvimento de software e as aplicações são concebidas com uma menor quantidade de bugs e vulnerabilidades desde o princípio.
A Conviso Platform possui todos os recursos necessários para que a gestão dos processos de revisão de código, análise de findings e vulnerabilidades possam tornar-se o mais simples possível, possuindo suas próprias ferramentas de testes automatizados, mas também permitindo a integração com as ferramentas mais utilizadas no mercado.
Na imagem seguinte, podemos ver como a Conviso Platform relaciona as vulnerabilidades reportadas por profissionais de segurança:
Imagem 2: Vulnerabilidades reportadas na Conviso Platform
Conclusão sobre testes de segurança
É possível entendermos então que os processos de testes de aplicações vão muito além de testes automatizados como o SCA, SAST e DAST. Apesar de eles serem uma parte bem importante da empreitada em busca de uma maior maturidade em segurança de aplicações, eles são apenas a metade do processo e não podem ter melhores resultados sem a constante intervenção do trabalho de profissionais especialistas nas áreas de code review e pentesting.
Além disso, toda a cadeia de S-SDLC se beneficia de uma maior integração entre esses processos, criando uma simbiose onde, à medida que uma prática de segurança vai ganhando maturidade, automaticamente criam-se mecanismos que auxiliarão direta ou indiretamente na graduação de outras práticas de segurança referenciadas pelo SAMM.
Série artigos SAMM
- Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
- Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
- Governança segundo SAMM: Educação e Orientação em Segurança de Aplicações
- Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
- Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
- Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
- Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
- Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
- Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
- Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Ambientes em Segurança de Aplicações
- Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações
