Segurança de Aplicação

Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações

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.

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.

Nova call to action
About author

Articles

Profissional de TI com mais de 20 anos de experiência. Desses, 10 dedicados à cibersegurança. Atualmente trabalhando como consultor em Segurança de Aplicações na Conviso Application Security.
Related posts
Segurança de Aplicação

Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações

Neste artigo, daremos sequência à série de publicações sobre o OWASP SAMM (Software Assurance…
Read more
Segurança de Aplicação

Programa de segurança de aplicações: conheça o AppSec Journey

Primordialmente, a Segurança de Aplicações (AppSec) deve ser integrada em todas as etapas do…
Read more
Segurança de Aplicação

Operações segundo SAMM: Gestão de Ambiente em Segurança de Aplicações

Este artigo faz parte de uma série de publicações feitas com base no projeto SAMM da OWASP, caso…
Read more

Deixe um comentário