Gestão de Vulnerabilidades no PCI DSS: Como Proteger o Ambiente de Dados do Portador

Neste artigo:

• O que o PCI DSS exige em gestão de vulnerabilidades
• Requisitos 6 e 11: as bases do programa de vulnerabilidades
• Ciclo de vida de vulnerabilidades no CDE
• Varreduras internas, externas e testes de penetração
• Gestão de patches: SLAs obrigatórios no PCI DSS v4.0
• Como estruturar um programa maduro de VM em conformidade
• Conclusão

O PCI DSS (Payment Card Industry Data Security Standard), em sua versão 4.0, obrigatória desde abril de 2024, não trata a gestão de vulnerabilidades como uma atividade pontual. O padrão exige um programa contínuo, documentado e rastreável, com escopo centrado no Cardholder Data Environment (CDE): todos os sistemas, redes e componentes que tocam dados de cartão.

A lógica por trás dessa exigência é simples: vulnerabilidades não corrigidas são a principal porta de entrada para violações de dados de pagamento. Segundo o Verizon Payment Security Report, falhas conhecidas exploráveis figuram consistentemente entre os vetores mais utilizados em brechas de PCI.

O padrão organiza as exigências de vulnerability management principalmente em dois requisitos:

• Requisito 6: Desenvolver e manter sistemas e software seguros
• Requisito 11: Testar regularmente os sistemas e processos de segurança

Qualquer empresa que busca certificação PCI DSS, seja como merchant ou service provider, precisa demonstrar maturidade operacional em ambas as frentes.

Requisito 6: Segurança no Ciclo de Vida de Software e Sistemas

O Requisito 6 do PCI DSS v4.0 expandiu significativamente o escopo em relação à versão anterior. Além de gerenciar patches de sistemas operacionais e aplicações, as organizações agora precisam:

• Manter um processo formal para identificar e ranquear vulnerabilidades de segurança usando fontes de inteligência confiáveis (NIST NVD, CERT, fornecedores)
• Definir SLAs de remediação por criticidade (crítica, alta, média, baixa)
• Endereçar vulnerabilidades em software desenvolvido internamente via práticas de Secure SDLC, incluindo revisão de código e testes de segurança aplicacional (SAST/DAST)
• Proteger aplicações web voltadas ao público com WAF (Web Application Firewall) ou revisão de código periódica

Requisito 11: Testes Contínuos de Segurança

O Requisito 11 estabelece a cadência de validação técnica do ambiente:

• Varreduras de vulnerabilidades internas: trimestrais e após mudanças significativas
• Varreduras externas por ASV (Approved Scanning Vendor): trimestrais, com nota de aprovação
• Testes de penetração: no mínimo anuais e após mudanças relevantes no ambiente
• Monitoramento de integridade de arquivos (FIM): para detectar alterações não autorizadas em componentes críticos

Um programa eficaz de gestão de vulnerabilidades no contexto PCI não se resume a rodar scans. Ele precisa cobrir todo o ciclo de vida da vulnerabilidade dentro do CDE:

Varreduras por ASV: O que Muda na Prática

As varreduras externas trimestrais por um ASV certificado pelo PCI SSC são obrigatórias para merchants de nível 1 a 4 e service providers. O resultado exigido é uma varredura com status "Clean": sem vulnerabilidades de severidade 4 ou 5 no CVSS sem exceção documentada.

Testes de Penetração Anuais

O Requisito 11.4 exige testes de penetração com metodologia definida (PTES, OWASP, NIST SP 800-115), cobrindo:

• Camada de rede (segmentação do CDE, firewall rules, DMZ)
• Camada de aplicação (OWASP Top 10, lógica de negócio)
• Validação de controles de segmentação de rede (network segmentation testing)

A novidade do v4.0 é que a validação de segmentação passou a ser obrigatória semestralmente para service providers, e não mais apenas anual.

Para organizações que buscam serviços de Pentest especializados em ambientes PCI, a escolha de um parceiro com experiência em CDE é determinante para a qualidade das evidências entregues ao QSA.

O PCI DSS v4.0 define SLAs de remediação que precisam estar formalizados na política de gestão de vulnerabilidades da organização:

Quando a aplicação imediata de patch não é viável por impacto em produção ou indisponibilidade de correção do fornecedor, o PCI DSS aceita controles compensatórios documentados, como isolamento de rede, regras de WAF específicas ou monitoramento intensificado, com prazo definido para remediação definitiva.

Para entender como estruturar uma política de gestão de patches robusta, confira nosso guia sobre gestão de ativos e controles de segurança em conformidade com ISO 27001.

Pessoas, Processos e Tecnologia

Um programa de gestão de vulnerabilidades que satisfaz o PCI DSS e, ao mesmo tempo, entrega valor real de segurança, precisa das três dimensões:

Pessoas:

• Definição de papéis: quem descobre, quem prioriza, quem corrige, quem valida
• Capacitação técnica da equipe em leitura de relatórios de scan e CVSS
• Envolvimento de C-level na aceitação formal de riscos residuais

Processos:

• Política de VM documentada, aprovada e revisada anualmente
• Integração com o processo de gestão de mudanças (Change Management)
• Fluxo de exceções com prazo, responsável e controle compensatório

Tecnologia:

• Scanner de vulnerabilidades com capacidade de varredura autenticada (Tenable, Qualys, Rapid7)
• Integração com CMDB para cobertura completa do inventário de ativos
• Dashboard de métricas: aging, SLA compliance, distribuição por severidade e sistema

Métricas de Maturidade para Apresentar ao Board

Diretores de TI e CISOs precisam traduzir VM para linguagem de negócio. Métricas-chave:

• MTTR (Mean Time to Remediate) por severidade
• SLA Compliance Rate: percentual de vulns fechadas dentro do prazo
• Vulnerability Density: número de vulns por ativo, tendência mês a mês
• Exposure Window: tempo médio que uma vulnerabilidade crítica ficou aberta no CDE

Para organizações que desejam avaliar a maturidade de seu programa de segurança, uma análise de gap em relação ao PCI DSS v4.0 é o ponto de partida recomendado.

A gestão de vulnerabilidades no contexto do PCI DSS vai muito além de rodar um scan trimestral para satisfazer auditores. Organizações que tratam esse programa com seriedade constroem uma capacidade real de reduzir a janela de exposição de seu ambiente de dados do portador e, consequentemente, o risco de violações que podem custar muito mais do que qualquer investimento em segurança.

Com o PCI DSS v4.0 consolidado como padrão obrigatório, as exigências ficaram mais granulares e as evidências mais rigorosas. Empresas que ainda operam com processos ad hoc de patch management ou varreduras sem governança formal enfrentarão dificuldades crescentes nas avaliações com QSAs.

A boa notícia é que um programa maduro de VM, integrado a processos de mudança, sustentado por métricas e apoiado por parceiros especializados, não apenas garante conformidade, mas entrega vantagem competitiva real em um mercado onde a segurança de dados de pagamento é pré-requisito de confiança.

Leia também:

• Pentest em Ambientes PCI DSS: Como Preparar seu CDE
• PCI DSS v4.0: Principais Mudanças e Como se Preparar
• Gestão de Ativos e Controles de Segurança conforme ISO 27001