Implementando SLAs de Remediação de Vulnerabilidades

Visão Geral

SLAs de remediação de vulnerabilidades definem prazos obrigatórios para correção ou mitigação de vulnerabilidades identificadas com base na severidade, criticidade do ativo e disponibilidade de exploração. Programas de SLA eficazes promovem responsabilidade, garantem prazos de remediação consistentes e fornecem KPIs mensuráveis para a maturidade do gerenciamento de vulnerabilidades.

Quando Usar

• Ao implantar ou configurar capacidades de implementação de SLAs de remediação de vulnerabilidades em seu ambiente
• Ao estabelecer controles de segurança alinhados aos requisitos de conformidade
• Ao construir ou melhorar a arquitetura de segurança para este domínio
• Ao realizar avaliações de segurança que exigem esta implementação

Pré-requisitos

• Programa de varredura de vulnerabilidades produzindo descobertas regulares
• Inventário de ativos com classificações de criticidade
• Sistema de tickets (Jira, ServiceNow, etc.) para rastreamento de remediação
• Patrocínio executivo para aplicação de SLA
• Acordo multifuncional das operações de TI, desenvolvimento e segurança

Conceitos Principais

Componentes do Framework de SLA

1. Classificação de Severidade: Pontuação base CVSS + contexto de ameaça (EPSS, KEV)
2. Nivelamento de Ativos: Criticidade de negócios e nível de exposição
3. Prazos de Remediação: Dias máximos para remediar por categoria
4. Processo de Exceção: Aprovação documentada para extensões de SLA
5. Procedimentos de Escalonamento: Ações quando os SLAs são violados
6. Métricas e Relatórios: KPIs para rastreamento de conformidade

Matriz de SLA Recomendada

Aceleradores de SLA (Reduzem o SLA em 50%)

• Código de exploração publicamente disponível
• Exploração ativa observada em campo (CISA KEV)
• Ativo voltado para a Internet afetado
• Pontuação EPSS > 0.5 (probabilidade de exploração de 50%)
• Violação anterior por tipo de vulnerabilidade semelhante

Fluxo de Trabalho

Etapa 1: Definir Níveis de Ativos

Tier 1 (Critical Assets):
- Customer-facing production systems
- Payment processing infrastructure
- Domain controllers and identity systems
- Core network infrastructure (firewalls, routers)
- Databases containing PII/PHI/PCI data

Tier 2 (Important Assets):
- Internal production applications
- Email and collaboration systems
- Development/staging environments with production data
- Backup and recovery infrastructure
- VPN and remote access gateways

Tier 3 (Standard Assets):
- End-user workstations
- Development/test environments
- Print servers and peripheral management
- Non-critical internal tools

Etapa 2: Estabelecer Documento de Política de SLA

Seções chave a serem incluídas:

• Propósito e escopo
• Papéis e responsabilidades (matriz RACI)
• Definições de severidade e método de cálculo
• Prazos de remediação por severidade e nível de ativo
• Processo de solicitação de exceção e autoridade de aprovação
• Procedimentos de escalonamento para violações de SLA
• Métricas, cadência de relatórios e governança
• Cronograma de revisão e atualização da política

Etapa 3: Integrar com o Sistema de Tickets

# ServiceNow / Jira integration for automatic ticket creation
# See process.py for full implementation

# Key fields for remediation tickets:
# - Vulnerability ID (CVE/Plugin ID)
# - Affected host(s)
# - Severity (CVSS + contextual factors)
# - Asset tier
# - SLA deadline (calculated from discovery date)
# - Assignment group
# - Remediation instructions
# - Verification criteria

Etapa 4: Configurar Cadeia de Escalonamento

SLA Status          Action                          Notify
───────────────────────────────────────────────────────────
75% elapsed         Warning email                   Asset owner
100% elapsed        SLA breach notification          Manager + CISO
100% + 7 days       Executive escalation             VP/CTO
100% + 30 days      Risk acceptance required          CISO approval
100% + 90 days      Compensating controls mandatory   Board report

Etapa 5: Estabelecer Processo de Exceção

Razões válidas para exceção:

• O sistema não pode ser corrigido sem tempo de inatividade significativo (janela de manutenção agendada)
• Nenhuma correção do fornecedor disponível (aplicar controles compensatórios)
• A correção quebra a funcionalidade crítica (exigir resultados de teste como evidência)

…