c4.8 Criar uma equipe de gerenciamento de vulnerabilidades
Neste nível, uma equipe dedicada de gerenciamento de vulnerabilidades é dona do processo: rastrear novas vulnerabilidades, definir critérios de severidade e SLAs de remediação, coordenar as correções e dar a cada equipe visibilidade das vulnerabilidades nas suas cargas.
Guia de implementação
Do que a equipe é dona
Uma equipe de gerenciamento de vulnerabilidades transforma o patch ad-hoc em um processo governado. Suas responsabilidades incluem:
- Rastrear novas vulnerabilidades e emitir advisories às equipes de desenvolvimento.
- Alertar e escalar quando surgem vulnerabilidades críticas, e coordenar a remediação.
- Definir como a severidade é classificada (CVSS, EPSS, SSVC, VPR) e o prazo em que cada severidade deve ser corrigida.
- Conseguir que as equipes de DevOps se comprometam com SLAs de remediação (ou impô-los top-down com o respaldo do CISO/CIO).
- Medir os tempos de remediação e dar a cada equipe —e a cada gestor— dashboards das vulnerabilidades nas suas cargas.
Defina regras de autocorreção vs. escalonamento
Tenha um processo acordado para corrigir desvios. Exemplos para adaptar ao seu setor e apetite de risco:
- Vuln crítica em um SO não produtivo: autoaplicar o patch se não for aplicado em X.
- Vuln crítica em um SO produtivo: escalar se não for aplicado em X.
- Vuln alta/crítica em código: contatar o Security Champion da equipe se não for corrigida em X horas; escalar se não for resolvida no dia.
Dashboards agregados por equipe e por gestor impulsionam o engajamento na correção de vulnerabilidades.
Como validar
- Existe uma equipe dona do gerenciamento de vulnerabilidades com as responsabilidades acima?
- Os critérios de severidade e os SLAs de remediação estão definidos e acordados com o DevOps?
- Existem regras de autocorreção ou escalonamento configuradas para vulnerabilidades que envelhecem?
- Cada equipe tem visibilidade das vulnerabilidades nas suas cargas?
Ameaças atendidas
- A maioria da exploração em larga escala acontece dias ou semanas depois de uma vulnerabilidade ser pública e ainda tem sucesso porque as organizações carecem da equipe, do processo e das ferramentas para aplicar patches a tempo.
- Aplicar patches em tudo imediatamente é impossível em escala e o risco de não aplicar é alto demais, então sem definições baseadas em severidade e SLAs, as vulnerabilidades erradas são corrigidas primeiro — ou tarde demais.