Contexto: Panorama de Vulnerabilidades 2024-2025

1. Âmbito e Objetivos

1.1 Âmbito

Esta política aplica-se a [todos os ativos de TI e OT da organização], incluindo:

• Servidores físicos e virtuais ([Windows, Linux, Unix])
• Estações de trabalho e dispositivos móveis
• Aplicações web e APIs
• Infraestrutura de rede ([firewalls, switches, routers])
• Bases de dados e sistemas de armazenamento
• Sistemas SCADA/ICS (se aplicável)
• Serviços cloud ([AWS, Azure, GCP])
• Software de terceiros e dependências

1.2 Objetivos

• Identificação proativa: Descobrir vulnerabilidades antes de serem exploradas
• Avaliação de risco: Priorizar com base em CVSS, exploitabilidade e impacto no negócio
• Remediação atempada: Cumprir SLAs baseados em severidade (Critical: [24-48h], High: [7 dias], Medium: [30 dias])
• Conformidade NIS2: Demonstrar gestão contínua de vulnerabilidades e patch management
• Zero-day readiness: Procedimentos de emergência para vulnerabilidades exploradas ativamente
• Melhoria contínua: Reduzir MTTR (Mean Time To Remediate) e aumentar cobertura de scanning

2. Definições e Terminologia

2.1 Classificação de Severidade (CVSS v3.1)

3. Responsabilidades

3.1 Equipa de Segurança ([CISO/Security Team])

• Gerir plataforma de vulnerability scanning ([Tenable, Qualys, Rapid7])
• Configurar scans automáticos e manter inventário de ativos
• Avaliar e priorizar vulnerabilidades com base em CVSS, EPSS e contexto
• Monitorizar KEV (CISA Known Exploited Vulnerabilities) e zero-days
• Coordenar resposta a vulnerabilidades críticas e emergências
• Reportar métricas mensais (MTTR, patch compliance, CVEs abertos)
• Manter contacto com [CERT nacional/ISACs setoriais]

3.2 Operações de TI ([IT Operations/SysAdmins])

• Aplicar patches dentro dos SLAs definidos por severidade
• Testar patches em ambiente não-produção antes de deployment
• Manter inventário atualizado de sistemas e versões de software
• Implementar mitigações temporárias quando patches não disponíveis
• Documentar razões para desvios aos SLAs de patching
• Executar scans de validação pós-remediação

3.3 Asset Owners ([Departamentos de Negócio])

• Aprovar janelas de manutenção para patching de sistemas críticos
• Validar funcionalidade após aplicação de patches
• Aceitar risco formalmente se patch não puder ser aplicado no SLA
• Reportar sistemas shadow IT para inclusão no inventário

3.4 Gestão de Fornecedores ([Procurement/Vendor Management])

• Garantir SLAs de patching em contratos com fornecedores
• Exigir notificações de CVEs que afetem produtos fornecidos
• Validar processo de disclosure e patch release de fornecedores
• Manter contactos de segurança para coordenação de vulnerabilidades

4. Inventário de Ativos

Manter inventário completo e atualizado é pré-requisito para gestão eficaz de vulnerabilidades.

4.1 Informação Obrigatória por Ativo

• Identificação: Hostname, IP, asset ID único
• Tipo: Servidor, workstation, dispositivo de rede, aplicação
• Criticidade: [Tier 1 (crítico), Tier 2 (importante), Tier 3 (padrão)]
• Owner: Departamento responsável e contacto
• Software: SO, versão, aplicações instaladas, dependências
• Exposição: Internet-facing, internal-only, segmento de rede
• Compliance scope: NIS2, GDPR, PCI-DSS, etc.

4.2 Ferramentas de Descoberta

4.3 Classificação de Criticidade

Ativos são classificados com base em [CIA triad + business impact]:

5. Scanning de Vulnerabilidades

5.1 Tipos de Scanning

5.2 Ferramentas de Scanning

Plataforma principal: [Tenable Nessus / Qualys VMDR / Rapid7 InsightVM]

Ferramentas complementares:

• DAST: [OWASP ZAP, Burp Suite, Acunetix]
• SAST: [SonarQube, Checkmarx, Veracode]
• SCA: [Snyk, WhiteSource, Black Duck]
• Cloud: [Wiz, Prisma Cloud, Defender for Cloud]
• Container: [Trivy, Clair, Anchore]

5.3 Configuração de Scans

5.4 Gestão de Falsos Positivos

Procedimento para análise e supressão de falsos positivos:

1. Validação manual: Analista de segurança confirma se é falso positivo
2. Documentação: Justificação técnica em [ticket system]
3. Aprovação: Security lead aprova supressão
4. Revisão periódica: Revisitar falsos positivos a cada [90 dias]
5. Auditoria: Log de todas as supressões para compliance

6. Avaliação de Risco

Nem todas as vulnerabilidades têm o mesmo risco. Priorização considera múltiplos fatores além de CVSS.

6.1 Fatores de Priorização

6.2 Matriz de Risco

Combinação de likelihood (EPSS + exploit) e impact (CVSS + asset criticality):

6.3 Fontes de Threat Intelligence

Monitorizar para contextualizar risco:

• CISA KEV: Known Exploited Vulnerabilities
• EPSS: Exploit Prediction Scoring System
• NVD: National Vulnerability Database (NIST)
• Vendor advisories: Microsoft, Cisco, Fortinet, etc.
• CERT feeds: [CERT-PT, ENISA]
• Dark web monitoring: [Recorded Future, Flashpoint]

7. Gestão de Patches

7.1 SLAs de Remediação por Severidade

7.2 Processo de Patch Management

1. Notificação: Patch Tuesday (Microsoft), vendor advisories, CVE feeds
2. Avaliação: Severidade, aplicabilidade, dependências
3. Teste: Deploy em ambiente de [dev/staging]
   • Validação funcional (smoke tests)
   • Verificação de compatibilidade
   • Performance testing (se aplicável)
4. Aprovação: Change Advisory Board para sistemas críticos
5. Deployment: Faseado (pilot → produção)
   • Fase 1: [10% dos sistemas]
   • Fase 2: [50% após 24h]
   • Fase 3: [100% após 48h]
6. Validação: Re-scan para confirmar remediação
7. Documentação: Tickets fechados, métricas atualizadas

7.3 Patch Sources e Ferramentas

7.4 Exceções e Desvios

Quando patches não podem ser aplicados no SLA:

1. Justificação técnica: Incompatibilidade, impacto em produção, etc.
2. Mitigação compensatória: Implementar controlos alternativos
   • WAF rules para aplicações web
   • Firewall rules para bloquear vetores de ataque
   • IDS/IPS signatures
   • Desativar funcionalidade vulnerável
   • Segmentação de rede adicional
3. Aceitação de risco: Asset owner assina aceite formal
4. Prazo de resolução: Definir data limite para patch ou descomissionamento
5. Revisão periódica: Exceções revistas mensalmente

8. Resposta a Zero-Days

Vulnerabilidades exploradas ativamente antes de patch estar disponível requerem resposta de emergência.

8.1 Definição de Zero-Day (para esta política)

• CVE com exploit ativo confirmado (KEV listing)
• Sem patch oficial disponível do vendor
• Afeta sistemas da organização (confirmado via inventário)

8.2 Procedimento de Emergência

1. T+0h - Alerta: Notificação de zero-day (CERT, vendor, SIEM alerts)
   • Equipa de segurança notificada via [PagerDuty/Slack/SMS]
   • CISO informado
   • Incident response ativado
2. T+1h - Assessment: Avaliar impacto
   • Identificar ativos afetados (query no CMDB/scanner)
   • Determinar exploitabilidade e vetores de ataque
   • Verificar se já há comprometimento (SIEM/EDR logs)
3. T+2h - Contenção: Mitigações imediatas
   • Opção 1: Desativar serviço/funcionalidade vulnerável
   • Opção 2: Isolar sistemas afetados (VLAN separada)
   • Opção 3: Bloquear vetores de ataque (firewall, WAF)
   • Opção 4: Aplicar workaround do vendor (se disponível)
4. T+4h - Validação: Confirmar eficácia das mitigações
   • Tentar exploit em ambiente de teste
   • Validar que controlos bloqueiam ataque
   • Monitorização reforçada (SIEM alerts, threat hunting)
5. T+24h - Patch: Aplicar patch oficial quando disponível
   • Teste acelerado (skip full regression)
   • Emergency change approval
   • Deploy prioritário
6. T+48h - Normalização: Restaurar operações
   • Remover mitigações temporárias
   • Re-scan para validar remediação
   • Post-incident review

8.3 Contactos de Emergência

8.4 Exemplos Históricos de Zero-Days

9. Reporting e Métricas

9.1 KPIs Obrigatórios

9.2 Dashboards e Visualizações

Plataforma de reporting: [PowerBI / Tableau / Kibana]

Dashboards obrigatórios:

• Executive Dashboard: Visão geral de risco, tendências, conformidade
  • Risk score total e evolução
  • Top 10 CVEs por risco
  • Patch compliance por severidade
  • MTTR trends
• Operational Dashboard: Trabalho diário
  • Vulnerabilidades abertas por severidade
  • SLA violations
  • Scan status por ativo
  • Patch deployment progress
• Compliance Dashboard: NIS2 requirements
  • Coverage de ativos críticos
  • Tempo médio de resposta a CVEs críticos
  • Exceções e risk accepts pendentes
  • Auditoria de supressões

9.3 Relatórios Periódicos

9.4 Alertas Automáticos

Configurar notificações automáticas para eventos críticos:

• CVSS ≥9.0: Email imediato a [security-team@empresa.pt]
• KEV listing: SMS/PagerDuty para on-call engineer
• SLA breach: Notificação a asset owner e CISO
• Scan failures: Alerta após [3 falhas consecutivas]
• Patch failures: Ticket automático para IT Ops

10. Coordenação com Fornecedores

10.1 Responsabilidades dos Fornecedores

Todos os contratos de software/hardware devem incluir cláusulas de vulnerability management:

• CVE notifications: Notificar em [24h] após publicação de CVE que afete produto fornecido
• Patch SLAs: Compromisso de disponibilizar patches em:
  • Critical: [48h-7d]
  • High: [14-30d]
• Workarounds temporários: Fornecer mitigações enquanto patch não disponível
• Security advisories: Publicar informação técnica detalhada (CVSS, vetores, remediação)
• Coordinated disclosure: Notificar clientes antes de disclosure público (quando possível)
• End-of-life policy: Clarificar suporte de segurança para versões legacy

10.2 Vendor Risk Assessment

Avaliar fornecedores com base em histórico de vulnerabilidades:

10.3 Contactos de Segurança por Fornecedor

Manter lista atualizada de PSIRTs (Product Security Incident Response Teams):

10.4 Escalation com Fornecedores

Procedimento quando fornecedor não cumpre SLAs de patching:

1. T+0: Contactar PSIRT via email/portal (registar ticket)
2. T+24h: Follow-up se sem resposta + notificar account manager
3. T+48h: Escalation a VP/Director level do fornecedor
4. T+72h: Considerar mitigações compensatórias ou substituição de produto
5. T+7d: Revisão contratual e avaliação de breach de SLA

Aprovação e Controlo de Versões

Histórico de Revisões