O Processo
Após o reporte de uma vulnerabilidade, através da criação de um Work Item ou envio do Formulário, as vulnerabilidades reportadas passarão por um processo de triagem, para validar a existência dela, o impacto na aplicação vulnerável e se o reporte respeita as diretrizes definidas neste documento. Com o reporte devidamente validado pela equipe da WSS, será aberto por ela uma proposta de correção da vulnerabilidade associada ao repositório que armazena o código da aplicação vulnerável.
As vulnerabilidades podem assumir diferentes estados, representantes do ponto em que elas encontram-se no fluxo de gestão de vulnerabilidades. Abaixo estão descritos todos os estados possíveis de uma vulnerabilidade dentro do Programa de Reporte de Vulnerabilidades.
Criação (NEW):
- Reportada (NEW) - Estado conferido a uma vulnerabilidade quando ela foi reportada por algum dos meios de identificação de vulnerabilidades, no caso do VDP, um colaborador. Este estado ainda não é apto a conferir números da sorte ao profissional.
Em Progresso (DESENV. ou TEST):
- Em validação - Com o reporte de uma vulnerabilidade, inicia-se o processo de validação dela por parte da WSS. Neste processo a WSS irá verificar se o que foi reportado é de fato uma vulnerabilidade, se ela está presente em um código válido e a sua definição de criticidade.
- Necessita de mais informações - É preciso buscar mais informações sobre a vulnerabilidade com a pessoa que realizou o reporte.
- Validada (Pending Report) - Uma vez que a vulnerabilidade seja validada pela WSS Security e sua criticidade seja definida, os números da sorte referentes à vulnerabilidade serão conferidos ao profissional que realizou o reporte.
- Correção atribuída (Reported) - Este estado será atribuído a uma vulnerabilidade a partir do momento em que ela for devidamente validada pela WSS Security, tornando-a apta a receber propostas de correção.
- Bloqueada - Existe algum bloqueio no processo de triagem ou correção da vulnerabilidade. Correção em validação - O envio de uma proposta de correção inicia o processo de validação desta correção, neste processo a WSS irá avaliar se a proposta de fato corrige a vulnerabilidade em questão e se a correção está apta a ser integrada ao código de produção da aplicação vulnerável.
Conclusão (CLOSED):
- Falso Positivo - A vulnerabilidade reportada foi considerada um falso positivo durante o processo de triagem. Este estado será atribuído a vulnerabilidades que não forem consideradas válidas durante o processo de triagem, por não possuírem os requisitos necessários.
- Duplicada - Um reporte para a mesma vulnerabilidade já foi realizado e triado anteriormente.
- Corrigida - A partir do momento em que a proposta de correção de uma vulnerabilidade for validada pela WSS Security, a proposta de correção será aprovada e marcada para compor o código de produção da aplicação. Neste momento, os números da sorte referentes à correção desta vulnerabilidade serão atribuídos ao profissional responsável pela correção.
Os reportes realizados no Azure DevOps devem sempre ser relacionados a uma vulnerabilidade específica. Dessa forma bugs ou problemas não relacionados a segurança de aplicações não serão considerados no processo de validação do reporte. Neste sentido, para auxiliar no envio de um reporte, o VDP define vulnerabilidade como:
Os reportes podem ser criados para qualquer código em produção de todas as aplicações. Visando garantir que todos os reportes de fato indiquem vulnerabilidades e que estas sejam vulnerabilidades válidas, a WSS irá realizar um processo de triagem em todos os reportes, buscando validar os seguintes requisitos:
Requisitos de Vulnerabilidades
O que foi reportado é de fato uma vulnerabilidade, e não um bug ou outro problema com o código.
A vulnerabilidade pode ser explorada por um agente de ameaça.
A vulnerabilidade representa um risco real a Disponibilidade, Integridade e Confidencialidade da aplicação ou seus dados.
A vulnerabilidade possui impacto dentro do contexto da aplicação.
Adicionalmente a estes critérios, os tipos de vulnerabilidades descritos na lista abaixo não serão considerados válidos para o programa, sendo considerados “out-of-scope” para o Programa de Reporte de Vulnerabilidades. Esta definição existe para excluir vulnerabilidades cujos testes podem causar danos inadvertidamente às aplicações, assim como para casos em que a execução da vulnerabilidade em si seja muito simples.
Vulnerabilidades out-of-scope:
Deny of Service - Causar um incidente de indisponibilidade na aplicação devido ao envio de um grande volume de requisições para extrapolar a capacidade computacional da aplicação.
Resultados de escaneamentos de ferramentas automatizadas - Utilizar resultados de ferramentas automatizadas como nmap, OWASP ZAP, Nuclei e etc.
Duplicatas - Para os casos em que mais de um reporte ou proposta de correção forem enviados, o reporte ou proposta que possuir a data e hora mais antiga no Azure DevOps ou Formulário de Reporte de Vulnerabilidades será considerado primeiro para o processo de validação. Caso o reporte ou proposta de correção seja validada com sucesso ela avança para o próximo estado do VDP e caso ele não seja aprovado no processo de validação, o próximo reporte ou proposta mais velha será colocado em validação.
É importante reforçar que todos os testes ou ações realizadas por qualquer participante do Programa de Reporte de Vulnerabilidades devem ser realizados com cuidado, nunca impactando diretamente na Disponibilidade, Integridade e Confidencialidade das aplicações e seus dados, principalmente em casos de aplicações de produção. Todos os testes realizados devem priorizar a saúde das aplicações.
Classificação das Vulnerabilidades
Com a execução do processo de triagem e a validação da vulnerabilidade reportada, a WSS deve classificar a vulnerabilidade em relação a sua criticidade. Esta classificação está diretamente ligada à quantidade de números da sorte que o colaborador receberá dentro do VDP pelo reporte e/ou correção da vulnerabilidade.
Para realizar essa classificação de forma homogênea e garantir a acurácia da classificação, será utilizado o sistema de classificação de vulnerabilidades Common Vulnerability Scoring System Version 3.1. Este sistema permite calcular um valor consistente para diferentes vulnerabilidades conhecidas e é uma ferramenta consolidada no mercado para gestão de vulnerabilidades. A escala de classificação de vulnerabilidades indica a quantidade de números da sorte que um participante do Programa de Reporte de Vulnerabilidades pode ganhar.
Cada vulnerabilidade validada será associada ao colaborador que realizou o seu reporte ou sua correção. Ambos os casos conferem números da sorte para o colaborador que realizou a ação, conforme apresentado na tabela acima.