Procedimento de Identificação e Classificação de Vulnerabilidades de Segurança

Modificado em Seg, 31 Mar, 2025 na (o) 11:16 AM

                     

 

 

1.    DEFINIÇÃO DE FONTES EXTERNAS 

As fontes primárias para informações de vulnerabilidade serão o NIST (National Institute of Standards and Technology), MITRE e o OWASP Top Ten.

Os analistas de segurança devem se inscrever em listas de discussão, RSS feeds e alertas dessas organizações para garantir atualizações regulares.

 

2.    COLETA AUTOMATIZADA DE INFORMAÇÕES 

Implementação de ferramentas automatizadas que varrem e identificam vulnerabilidades, baseando-se nas fontes definidas, para reduzir a dependência de verificações manuais e garantir uma coleta mais abrangente e atualizada.

 

3.    AVALIAÇÃO INTERNA COM FERRAMENTAS SAST E DAST 

Antes de migrar qualquer código para um ambiente de homologação ou produção, as ferramentas de Análise Estática de Segurança (SAST) serão usadas para identificar vulnerabilidades potenciais no código.

Posteriormente, após a implantação em um ambiente de teste, uma ferramenta DAST avaliará a aplicação em tempo de execução para identificar falhas que podem não ser aparentes apenas pelo código fonte.

 

4.    CLASSIFICAÇÃO DE RISCO 

Baseado na pontuação CVSS obtida, a vulnerabilidade será classificada em uma das seguintes categorias:

 

0.1 - 3.9: Baixo risco

4.0 - 6.9: Risco médio

7.0 - 8.9: Alto risco

9.0 - 10.0: Risco crítico 

Sendo:

Crítico: Vulnerabilidades que representam uma ameaça imediata, têm potencial de impacto extremamente alto e podem comprometer a integridade, disponibilidade ou confidencialidade de sistemas vitais da WisePay;

Alto: Vulnerabilidades que têm potencial de alto impacto, podem ser facilmente exploradas e/ou afetam sistemas críticos da WisePay;

Médio: Vulnerabilidades que têm um impacto moderado e/ou exigem condições específicas para serem exploradas;

Baixo: Vulnerabilidades que têm um impacto menor e/ou são menos prováveis de serem exploradas.

  

5.    REGISTRO E DOCUMENTAÇÃO 

Todas as vulnerabilidades identificadas devem ser registradas em um sistema de gerenciamento de vulnerabilidades dedicado ou, se não disponível, em uma planilha segura.

Informações essenciais, como data de descoberta, fonte, descrição, classificação de risco e medidas tomadas devem ser documentadas.

 

6.    COMUNICAÇÃO 

O time de segurança da WisePay deve informar imediatamente as equipes relevantes sobre vulnerabilidades classificadas como alto risco.

Para vulnerabilidades de médio e baixo risco, uma comunicação regular deve ser estabelecida para garantir que as equipes relevantes estejam cientes e possam tomar as medidas apropriadas.

 

7.    IMPLEMENTAÇÃO DE CORREÇÕES 

Com base na pontuação obtida, as implementações de correção obedecerão os critérios:

 

Baixo risco (0.1 - 3.9)

 

Ação: Programar correção.

SLA: 60 dias.

Descrição: A vulnerabilidade deve ser corrigida na próxima atualização ou ciclo de manutenção planejado.

 

Risco médio (4.0 - 6.9)

 

Ação: Correção prioritária.

SLA: 30 dias.

Descrição: A vulnerabilidade deve ser corrigida dentro de um mês, priorizando-a em relação a outros trabalhos de manutenção.

 

Alto risco (7.0 - 8.9)

 

Ação: Ação imediata.

SLA: 7 dias.

Descrição: A correção deve ser aplicada imediatamente, dentro de uma semana após a identificação, devido ao alto potencial de exploração e impacto.

Risco crítico (9.0 - 10.0)

 

Ação: Correção de emergência.

SLA: 48 horas.

Descrição: A vulnerabilidade deve ser corrigida em um período de tempo extremamente curto, dada a gravidade e o risco significativo para a organização.

 

 

8.    REVISÃO E MELHORIA CONTÍNUA 

A cada seis meses, deve-se revisar e avaliar o processo para identificar áreas de melhoria.

Ajustes e refinamentos serão feitos nesse processo com base no feedback e nas lições aprendidas durante os ciclos anteriores.

 

Histórico de Versões:

Versão:

Data de aprovação:

Histórico:

Aprovado por:

001

31/10/2023

Elaboração do documento

Pedro Pontes

002

31/10/2023

Inclusão da nova classe de risco: ‘Crítico’

Pedro Pontes

003

01/11/2023

Inclusão de SLAs para resolução de vulnerabilidades

Pedro Pontes

004

17/09/2024

Revisão

Pedro Pontes


 

 

Este artigo foi útil?

Que bom!

Obrigado pelo seu feedback

Desculpe! Não conseguimos ajudar você

Obrigado pelo seu feedback

Deixe-nos saber como podemos melhorar este artigo!

Selecione pelo menos um dos motivos

Feedback enviado

Agradecemos seu esforço e tentaremos corrigir o artigo