Neste artigo:
- O que o PCI DSS exige de uma operação de segurança
- Requisito 10: monitoramento de logs no CDE
- Requisito 11: detecção de intrusão na prática
- Requisito 12.10: plano de resposta a incidentes
- SOC terceirizado e PCI DSS
- O custo do não cumprimento
- Conclusão
O que o PCI DSS exige de uma operação de segurança
O PCI DSS (Payment Card Industry Data Security Standard) é, entre os frameworks de compliance, um dos mais operacionalmente exigentes para equipes de segurança. Diferente de frameworks orientados a políticas e governança — como a ISO 27001 —, grande parte do que o PCI DSS exige tem entrega técnica direta: logs capturados, alertas disparados, tempo de resposta documentado.
Desde a versão 4.0, publicada em 2022, o padrão ficou mais explícito sobre o que constitui detecção efetiva e o que não passa de monitoramento superficial. Os requisitos com maior impacto direto para o SOC estão concentrados em quatro domínios:
| Requisito | Nome | O que exige |
|---|---|---|
| Req. 10 | Log e monitoramento de acesso | Todo acesso a componentes do sistema e ao CDE deve ser registrado, monitorado e revisado diariamente |
| Req. 11 | Testes de segurança regulares | Varreduras internas e externas, testes de penetração e detecção de pontos de acesso não autorizados |
| Req. 12 | Política de segurança da informação | Política documentada, plano de resposta a incidentes e atribuição formal de responsabilidades |
| Req. 6 | Sistemas e software seguros | Vulnerabilidades identificadas remediadas dentro de janelas definidas, com triagem e priorização contínuas |
Cada domínio tem obrigações que não podem ser atendidas apenas com tecnologia: precisam de processo e capacidade operacional consolidada.
Requisito 10: monitoramento de logs no CDE
O Requisito 10 é onde a maioria das empresas descobre que o que chamava de "monitoramento" era, na prática, armazenamento passivo de logs. O PCI DSS v4.0 exige que logs de todos os componentes no ambiente de dados do cartão (CDE) sejam capturados e revisados diariamente , com atenção específica a eventos anômalos.
Quais eventos precisam ser capturados
Os eventos de captura obrigatória incluem:
- Acesso individual a dados do portador de cartão
- Todas as ações tomadas por usuários com privilégios elevados
- Acessos inválidos e tentativas de autenticação falhas
- Uso de mecanismos de identificação e autenticação
- Inicialização, parada e pausas de logs de auditoria
- Criação e exclusão de objetos no nível do sistema
# Eventos de alta prioridade — revisão obrigatória diária (PCI DSS Req. 10.4.1)
eventos_obrigatorios:
- acesso_dados_portador_cartao # qualquer leitura do CHD
- acao_usuario_privilegiado # root, admin, DBA
- falha_autenticacao # brute force, credential stuffing
- uso_mecanismos_identificacao # MFA, tokens, certificados
- modificacao_objetos_sistema # arquivos, configs, permissões
- falha_nos_logs # req 10.7 — integridade do SIEM
sla_revisao: 24h
retencao_minima: 12 meses # 3 meses imediatamente disponíveis
responsavel: analista_designado_com_documentacao
O Req. 10.7 e a integridade do SIEM
⚠️ Ponto crítico , Req. 10.7
O PCI DSS v4.0 introduziu o Req. 10.7.2 como obrigatório para todos: falhas em controles de segurança críticos precisam ser detectadas, reportadas e respondidas prontamente. Isso inclui falhas em mecanismos de log , o que significa que o SOC precisa monitorar não só os eventos, mas a integridade da própria infraestrutura de coleta.
Para entender como estruturar a coleta e correlação de eventos em conformidade com o PCI DSS, veja nosso guia sobre como implementar um SIEM para ambientes regulados.
Requisito 11: detecção de intrusão na prática
O Requisito 11 é frequentemente interpretado como "fazer pentests anuais", mas vai muito além disso. Para o SOC, as exigências mais operacionalmente intensas estão nas subseções 11.5 e 11.6.
Obrigações do Req. 11 para o SOC
| Sub-req. | Obrigação | Impacto para o SOC | Criticidade |
|---|---|---|---|
| 11.5.1 | IDS/IPS no perímetro e nos pontos críticos | Integração dos alertas de IDS ao SIEM e triagem ativa | Alta |
| 11.5.1.1 | Detecção de mudanças não autorizadas (novo em v4.0) | Monitoramento de integridade de arquivos críticos (FIM) | Alta |
| 11.6.1 | Detecção de mudanças em páginas de pagamento (novo em v4.0) | Monitoramento de scripts em páginas de checkout | Alta |
| 11.3.1 | Varredura de vulnerabilidades interna trimestral | Correlação de resultados com os alertas ativos no SIEM | Média |
| 11.4.1 | Pentest ao menos anual e após mudanças significativas | Validação dos controles de detecção e dos playbooks de resposta | Média |
Req. 11.6.1 e o risco de skimming digital
O Req. 11.6.1 merece atenção especial para quem opera ambientes de e-commerce. A versão 4.0 do PCI DSS passou a exigir que empresas monitorem mudanças não autorizadas em scripts executados em páginas de pagamento , uma resposta direta ao crescimento dos ataques de skimming digital (Magecart e similares).
Esse é um domínio novo para a maioria dos SOCs, que precisam expandir a visibilidade para além do perímetro de rede tradicional. Para entender como estruturar essa cobertura, veja nosso artigo sobre proteção contra ataques de skimming digital em e-commerce.
Requisito 12.10: plano de resposta a incidentes
O Requisito 12.10 exige que toda entidade que processa dados de cartão tenha um plano de resposta a incidentes documentado, testado anualmente e pronto para ativação imediata. A granularidade operacional exigida na v4.0 inclui:
- Papéis e responsabilidades definidos , quem decide sobre contenção, quem notifica as bandeiras, quem comunica clientes afetados
- Procedimentos para ataques a sistemas críticos , incluindo sistemas de autenticação e componentes do CDE
- Cobertura de incidentes de comprometimento de dados de cartão , com SLA de notificação às bandeiras (geralmente 72h após suspeita de comprometimento)
- Processo de análise pós-incidente , documentação de como e por que a intrusão ocorreu, com evidências forenses preservadas
- Monitoramento e resposta 24x7 para incidentes críticos , cobertura contínua que se torna explícita durante auditorias
- Capacidade de preservar evidências forenses , logs não podem ser modificados ou excluídos durante ou após uma investigação
Programas das bandeiras em caso de comprometimento
📌 Nota prática
As bandeiras de cartão (Visa, Mastercard) têm seus próprios programas de resposta a incidentes , VDIP (Visa) e MSC (Mastercard) , que impõem obrigações adicionais em caso de comprometimento suspeito, incluindo a contratação de um Forensic Investigator aprovado (PFI). O SOC precisa estar preparado para apoiar essa investigação com acesso imediato a logs e artefatos forenses.
Para estruturar playbooks alinhados a esses requisitos, consulte nosso material sobre resposta a incidentes em ambientes PCI DSS.
SOC terceirizado e PCI DSS
Terceirizar o SOC não exime a empresa das obrigações do PCI DSS. O QSA (Qualified Security Assessor) vai avaliar se os controles estão ativos e funcionando , não importa quem os opera.
Acesso a logs
SLAs contratuais
Responsabilidades
| Ponto de avaliação | O que o QSA verifica |
|---|---|
| Acesso a logs | A empresa precisa ter acesso aos logs brutos do CDE, não só aos relatórios gerados pelo SOC |
| SLAs contratuais | MTTD e MTTA precisam estar definidos em contrato com valores específicos por criticidade , referências genéricas não são aceitas |
| Responsabilidades | Quem notifica as bandeiras? Quem preserva evidências? Quem aciona o PFI? Isso precisa estar formalmente definido em matriz RACI |
| Testes anuais | O plano de resposta a incidentes precisa ser testado ao menos anualmente , e o SOC terceirizado precisa participar desses exercícios |
O custo do não cumprimento
As consequências do não-cumprimento do PCI DSS vão além das multas diretas. Em caso de comprometimento de dados de cartão, empresas que não podem demonstrar conformidade ativa enfrentam:
- Multas das bandeiras (que podem chegar a US$ 100 mil por mês para infrações graves)
- Aumento imediato nas taxas de processamento
- Obrigação de contratar um PFI às próprias custas
- No limite, perda da capacidade de processar pagamentos com cartão
O que o histórico de incidentes revela é que o gap entre ter um SOC que parece funcionar e ter um SOC que efetivamente atende ao PCI DSS está quase sempre em três pontos: cobertura noturna, qualidade das regras de detecção e capacidade de preservar evidências forenses com integridade. São exatamente esses pontos que aparecem em relatórios pós-incidente de empresas que passavam nas auditorias anuais, mas falharam quando o ataque aconteceu.
Para uma referência oficial sobre os requisitos do PCI DSS v4.0, consulte a documentação do PCI Security Standards Council.
Conclusão
Um SOC que atende ao PCI DSS não é necessariamente o maior ou o mais caro. É o que consegue provar, com evidências auditáveis, que detectou o que precisava detectar, registrou o que precisava registrar e respondeu dentro dos tempos exigidos , inclusive às 3h de um domingo.
A conformidade com o PCI DSS é um processo contínuo, não uma certificação pontual. Isso exige que a operação de segurança esteja estruturada para produzir evidências em tempo real, manter a integridade dos logs e executar playbooks testados quando o incidente ocorre.
Empresas que entendem o PCI DSS como um driver de maturidade operacional , e não apenas como obrigação regulatória , constroem SOCs mais resilientes e reduzem significativamente o impacto financeiro e reputacional de eventuais incidentes.
Leia também:
- Como implementar um SIEM para ambientes regulados PCI DSS
- Proteção contra ataques de skimming digital em e-commerce
- Resposta a incidentes em ambientes PCI DSS: estruturando playbooks