Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações

Tiago Zaniquelli

3 anos atrás

A prática gestão de defeitos consiste em coletar, registrar e analisar os defeitos de segurança, além, é claro, de enriquecer essas informações para utilizá-las em tomadas de decisões através de métricas.

O primeiro stream visa um processo de administração e manuseio dos defeitos com a finalidade de assegurar um nível de qualidade quando o software é lançado. Já no segundo stream, a ideia é enriquecer as informações coletadas, derivando assim métricas para tomada de decisões em relação às aplicações e também ao programa de desenvolvimento seguro.

Registrando Defeitos

Os registros de defeitos podem derivar de testes de penetração, resultados de ferramentas de scan, programa de bug bounties, revisão de código, entre outros meios.

A Figura 1 mostra um registro de defeito de SQL Injection. Nesse registro é possível verificar que essa vulnerabilidade está com o status de identificada, então nenhuma ação foi realizada. Outra informação importante é que sua severidade é crítica, além de informações complementares como categorias, padrões e informações adicionais sobre a vulnerabilidade em questão.

É extremamente importante definir regras de acessos às informações de defeitos de segurança de aplicações para mitigar o risco de vazamento e abuso das informações.

*Figura 1 – Registro de um defeito de SQL Injection*

Uma vez que está sendo feito o registro do defeito, pode-se realizar ações conforme o nível de maturidade do OWASP SAMM, por exemplo:

Maturidade 1: classificação rudimentar qualitativa dos defeitos para priorização dos esforços para correção;
Maturidade 2: classificação baseada em probabilidade e impacto do defeito que está sendo explorado, além de introduzir SLAs para correções;
Maturidade 3: implementar alerta automatizado de que uma correção está fora do SLA definido. Assegurar que esses defeitos sejam transferidos automaticamente para uma administração de riscos.
Integrar o sistema de defeito com ferramentas de outras práticas, como:
- build e deployment: falhar o build caso o artefato final for afetado por algum defeito acima da severidade preestabelecida;
- monitoramento: se possível, certifique-se de que o abuso do defeito de segurança no ambiente de produção seja reconhecido e alertado.

Métricas e Feedback na Gestão de Defeitos

Após ser feita a coleta, registro e manuseio dos defeitos de segurança, chegou a hora de enriquecer essas informações transformando-as em métricas. Na Figura 2, que mostra o produto People & Culture da Conviso Platform, é possível ver um módulo de treinamento onde se usa os defeitos registrados. Com isso, é sugerida a linguagem de programação para investir aprendizagem – no caso, Ruby on Rails – e também é mencionada a vulnerabilidade mais comum – no caso, SQL Injection.

Figura 2 – People & Culture – Informações Baseadas no Registro de Defeitos

O SAMM sugere algumas métricas/ações de acordo com sua maturidade, por exemplo:

Maturidade 1 – métricas:
- número total de defeitos x total de atividades de verificação;
- softwares com defeitos;
- categoria dos defeitos;
- severidade dos defeitos;
Maturidade 2 – métricas:
- atividades de verificação x defeitos identificados;
- tipos de severidade identificadas;
- tempo de detecção e tempo de resolução (Figura 3);
- janela de exposição do defeito em produção;
- número de regressões/vulnerabilidades reabertas;
- quantidade de riscos aceitos;
- razão dos incidentes de segurança causados devido a defeitos de segurança desconhecidos ou não documentados;
Maturidade 3: revisitar as métricas reunidas e comparar o esforço necessário para coletar e registrar x o resultado esperado. A ideia é remover métricas que não atendem o resultado esperado.
Agregar a informação com sua threat intelligence e métricas de administração de incidentes e usar os inputs para outras iniciativas como: planejar treinamentos de segurança; melhorar a verificação das atividades de segurança; entre outras.

Conclusão

A gestão de defeitos pode nos trazer muitos insights, desde aplicações que se gasta mais energia devido a sua criticidade, até em relação ao ciclo de desenvolvimento de software seguro como um todo, pois podemos utilizar essas informações para um treinamento mais direcionado, focando, por exemplo, nos pontos nos quais o time mais está errando.

Referências

OWASP SAMM

Registrando Defeitos

Métricas e Feedback na Gestão de Defeitos

Conclusão

Referências

Série artigos SAMM