PCI DSS

O PCI Shield da cside usa controles de client-side security e client-side protection para proteger páginas de pagamento contra Magecart, e-skimming, formjacking e outros ataques que rodam no navegador do cliente. Esta página explica como a cside se alinha aos Requisitos 6.4.3 e 11.6.1 do PCI DSS e como configurar evidências prontas para auditoria.

O que é PCI DSS?

O Payment Card Industry Data Security Standard (PCI DSS) é um conjunto de diretrizes que garante a segurança das transações com cartão em nível global. Criado pelo PCI Security Standards Council, seu objetivo é proteger contra roubo de dados e fraudes em transações com cartões de débito e crédito.

O PCI DSS v4.0.1 introduz dois requisitos que regem os scripts e cabeçalhos entregues ao navegador do portador do cartão nas páginas de pagamento:

• 6.4.3 cobre autorização, integridade e inventário de scripts.
• 11.6.1 cobre a detecção de alterações e adulterações em cabeçalhos HTTP com impacto em segurança e no conteúdo dos scripts das páginas de pagamento.

Você pode ler a especificação completa no site do PCI Security Standards Council.

Dois modos de implantação, ambos em conformidade

A cside oferece dois modos de monitoramento. Ambos atendem a 6.4.3 e 11.6.1. Escolha com base na sua tolerância ao risco e na capacidade de implantar mudanças no código.

Método por varredura (sem alteração de código)

• Executa contêineres completos de navegador (não simples requisições HTTP) duas vezes por dia em todo o site e no fluxo de usuário que leva à página de pagamento.
• Monitora os scripts à medida que o DOM é renderizado por completo, incluindo sub-requisições e recursos carregados tardiamente que scanners HTTP mais simples deixam passar.
• Imita o comportamento de um usuário real para capturar scripts injetados dinamicamente e ativos rotacionados por CDN.

Duas varreduras por dia superam a exigência “pelo menos semanalmente” de 11.6.1 e cumprem a expectativa de inventário periódico de 6.4.3.

Método por script (em tempo de execução, inline)

• Carrega inline na sessão real do usuário e registra cada script e cada ação de script em tempo real na infraestrutura da cside.
• Oferece visibilidade no nível da requisição no painel.
• Permite bloqueio granular: a cside pode bloquear ações específicas ou interromper scripts por completo.
• Integra-se com CSP. A cside também impede que scripts maliciosos injetem diretivas CSP capazes de desabilitar o próprio script da cside, um comportamento que não observamos em nenhuma outra solução do mercado.

Requisito 6.4.3

Todos os scripts das páginas de pagamento que são carregados e executados no navegador do consumidor são gerenciados da seguinte forma…

”É implementado um método para confirmar que cada script está autorizado.”

O PCI DSS permite tanto modelos de autorização prévia quanto posterior. A cside suporta ambos:

• Método por varredura: os scripts encontrados na página de pagamento e no seu fluxo de usuário são exibidos no painel PCI DSS para revisão e autorização por um usuário identificado. O painel e o log de auditoria registram quem autorizou cada script e quando.
• Método por script: além da autorização pelo painel, a cside pode impedir tecnicamente a execução de scripts não autorizados ou de ações específicas em tempo de execução. Isso funciona junto do CSP e continua operando mesmo quando um atacante tenta injetar diretivas CSP para desabilitar a cside.

Decisões de autorização, a identidade de quem autoriza e os carimbos de data e hora são gravados no log de auditoria e podem ser exportados para o seu QSA.

”É implementado um método para garantir a integridade de cada script.”

A cside verifica a integridade em vários eixos, em vez de depender de uma única checagem de hash:

• Hashing do payload: o corpo de cada script é hasheado. Um novo hash dispara todo o pipeline de análise.
• Pipeline de análise de conteúdo: novos payloads são desofuscados, formatados e avaliados pelo nosso motor de regras proprietário em Rust, por regras Yara, por um LLM local de contexto pequeno, por modelos maiores para análise aprofundada e por uma etapa de revisão humana pela equipe da cside.
• Verificação de metadados de origem: cada origem de script é conferida contra o histórico do emissor SSL (para capturar tentativas de sequestro), o histórico de registro e propriedade do domínio, mudanças nos registros DNS e NS, o status RPKI dos endereços IP resolvedores (para detectar vazamentos BGP) e o DNS reverso para identificar sobreposição de infraestrutura com domínios maliciosos conhecidos.
• Contexto histórico: a cside retém hashes anteriores servidos na mesma URL, permitindo auditar mudanças de integridade entre versões. O painel exibe cada variante de hash e renderiza o payload para inspeção.

”É mantido um inventário de todos os scripts, com justificativa escrita de negócio ou técnica explicando por que cada um é necessário.”

O painel PCI DSS foi desenhado especificamente para esta cláusula:

• Um inventário em tempo real de cada script detectado nas páginas de pagamento, incluindo o objeto pai que provocou o carregamento.
• Justificativas de negócio e técnicas geradas por IA a partir do payload e do comportamento (explicitamente permitido pelo PCI SSC), que um usuário revisa e confirma em seguida.
• Entradas de auditoria por script registrando quem aceitou ou editou cada justificativa, com histórico completo de revisões.
• Payloads formatados com APIs sensíveis do navegador destacadas inline, para que os revisores possam decidir com base em informação.

Requisito 11.6.1

É implantado um mecanismo de detecção de alterações e adulterações…

”Para alertar o pessoal sobre modificações não autorizadas dos cabeçalhos HTTP com impacto em segurança e do conteúdo dos scripts das páginas de pagamento, tal como recebidos pelo navegador do consumidor.”

A cside captura os cabeçalhos e o conteúdo dos scripts como chegam em um navegador real, não como são retornados por uma requisição do lado do servidor. Isso é importante porque muitos sites servem cabeçalhos e scripts diferentes conforme o User-Agent, a impressão TLS, a detecção de bots e o roteamento geográfico.

Cabeçalhos com impacto em segurança monitorados:

• Content Security Policy
• Content Security Policy Report Only
• Report To
• Reporting Endpoints
• Strict Transport Security
• X-Frame-Options
• Cross-Origin Resource Policy
• Cross-Origin Opener Policy
• Cross-Origin Embedder Policy
• Permissions Policy
• X-Content-Type-Options
• X-Permitted-Cross-Domain-Policies
• Referrer Policy
• X-XSS-Protection

A cside trata cada mudança de hash como um novo script. Sempre que o payload muda, o novo hash é desofuscado automaticamente e passa pelo pipeline completo de detecção. Os alertas não são disparados pela mudança em si, mas quando a análise detecta algo fora do padrão.

Concretamente:

• Cada mudança de hash é analisada como um novo script. Novos scripts, scripts removidos, payloads modificados e desvios comportamentais (novos destinos de rede, novas APIs do DOM, novas superfícies de armazenamento acessadas) são todos capturados e avaliados. A detecção não é baseada em assinatura do script pai.
• Os alertas disparam por mau comportamento. Se uma variante de hash se comporta de forma indevida, ou se algo preocupante surge (origens ou payloads conhecidos como maliciosos, tentativas de manipulação de CSP, comportamento de exfiltração, pontuação de ameaça acima do limiar, padrões novos de ofuscação), a cside alerta em tempo real pelos endpoints de notificação configurados.
• O inventário rotineiro é reportado periodicamente. O relatório semanal em PDF (configurável para diário) lista cada script detectado nas páginas de pagamento, cada URL de página de pagamento, cada mudança de cabeçalho de segurança e cada justificativa de negócio com seu autor. Isso atende à cláusula “pelo menos semanalmente” de 11.6.1.

Isso supera o padrão. 11.6.1 exige avaliação periódica; a cside executa análise por hash de forma contínua e adiciona alertas imediatos por cima disso.

”O mecanismo é configurado para avaliar os cabeçalhos HTTP e as páginas de pagamento recebidos.”

A cside avalia os cabeçalhos e o payload como são renderizados no navegador. Quando os cabeçalhos normalmente não estão expostos a um script dentro da página, a cside usa o contexto do navegador para obtê-los. Se suas páginas de pagamento estão atrás de uma VPN ou em ambiente restrito, a cside fornece um IP estático para que o scanner possa alcançá-las.

”As funções do mecanismo são executadas pelo menos semanalmente, ou periodicamente na frequência definida na análise de risco direcionada da entidade (Requisito 12.3.1).”

• O método por varredura é executado duas vezes por dia.
• O método por script é executado continuamente, na sessão real do usuário.
• Por padrão, um relatório semanal em PDF é enviado, resumindo todas as mudanças de cabeçalhos de segurança, cada script detectado nas páginas de pagamento, cada URL de página de pagamento e cada justificativa (incluindo o autor). Essa cadência pode ser aumentada para diária.
• Detecções de scripts maliciosos são alertadas imediatamente, fora do relatório semanal.

Aprovação por QSA

A cside tem uma taxa de aprovação QSA de 100%. Trabalhamos diretamente com grandes bancos, provedores de pagamento e firmas QSA. Um whitepaper assinado pela VikingCloud está disponível no nosso trust center, e a maioria das firmas QSA já revisou a solução.

Onde a cside vai além do requisito

O PCI DSS define um piso, não um teto. As capacidades a seguir extrapolam o que 6.4.3 e 11.6.1 pedem:

• Pipeline de detecção em camadas: regras Yara, motor de regras proprietário em Rust, LLMs de contexto pequeno, LLMs grandes e revisão humana. A maioria dos concorrentes depende apenas de feeds de ameaças de terceiros.
• Checagens de procedência da origem: variações de emissor SSL, histórico de domínio e DNS, validação RPKI e DNS reverso nos IPs resolvedores.
• Resistência à manipulação de CSP: a cside detecta e bloqueia tentativas de scripts maliciosos de injetar diretivas CSP que desativariam o script da cside.
• Visibilidade no nível da requisição: cada sub-requisição feita por um script é registrada com o objeto pai.
• Desofuscação e formatação: o painel exibe a versão legível de cada payload com APIs sensíveis destacadas.
• Pesquisa contínua na web pública: a cside pesquisa sites fora da base de clientes para detectar novos ataques antes que cheguem às páginas de pagamento dos clientes.

Configurando o painel PCI DSS

Navegando até as configurações do PCI DSS

Para acessar o painel PCI DSS, abra o painel e então:

1. Selecione seu domínio na barra lateral
2. Selecione PCI DSS

Adicionando páginas de pagamento

Antes de começar a usar o painel PCI DSS, você precisa identificar suas páginas de pagamento. Isso ajuda a filtrar os dados para você focar em scripts e cabeçalhos relacionados a pagamento.

1. Clique em Add a Payment Page ou em + Add Payment Page
2. Insira a URL da página de pagamento no formato de correspondência por padrões de script

3. Clique em Create

Setup por página vs modal

Há duas opções principais de setup conforme a sua implementação de pagamento:

Setup por página

Use esta opção se suas páginas de pagamento:

• São renderizadas no servidor (SSR)
• São carregadas via recarregamento ou navegação de página
• São isoladas dos scripts presentes durante a navegação no cliente

Esse setup filtra a lista de scripts para mostrar apenas os presentes nas páginas de pagamento designadas.

Setup por modal

Use esta opção se seus formulários de pagamento são implementados como:

• Janelas modais
• Widgets em popup
• Sobreposições de paywall
• Qualquer UI dinâmica em que pagamentos possam ser processados em múltiplas páginas

Esse setup monitora scripts em toda a sua aplicação, já que formulários de pagamento podem aparecer em qualquer página.

Configure usando um seletor CSS que identifique o seu modal ou formulário de pagamento.

Exemplo de seletor:

#pay

O painel exibirá todos os scripts que possam interagir com o formulário de pagamento quando ele estiver ativo.

Perguntas frequentes

O que os Requisitos 6.4.3 e 11.6.1 do PCI DSS exigem?

O Requisito 6.4.3 do PCI DSS exige que scripts de páginas de pagamento sejam autorizados, verificados quanto à integridade, inventariados e justificados. O Requisito 11.6.1 exige detecção de alterações e adulterações em cabeçalhos HTTP com impacto em segurança e no conteúdo de scripts de páginas de pagamento conforme recebido pelo navegador do consumidor.

Como client-side security protege páginas de pagamento?

Client-side security protege páginas de pagamento monitorando os scripts que executam no navegador, detectando mudanças não autorizadas e alertando quando o comportamento de um script sugere roubo de dados ou adulteração. A cside adiciona visibilidade em runtime para que equipes vejam quais scripts de terceiros carregam, quais requisições fazem e se interagem com fluxos sensíveis de checkout.

Como a cside lida com Magecart, e-skimming e formjacking?

A cside analisa payloads de scripts, sub-requisições, metadados de origem e comportamento em runtime em busca de sinais de Magecart, e-skimming, formjacking e ataques semelhantes baseados no navegador. Quando a cside detecta comportamento malicioso, ela pode alertar sua equipe e, no modo script, bloquear o script ou ações específicas.

Apenas o modo de varredura é suficiente para PCI DSS?

Sim. O método de varredura foi desenhado para atender às expectativas de inventário periódico e detecção de alterações em PCI DSS 6.4.3 e 11.6.1. O método por script adiciona monitoramento contínuo em runtime e bloqueio para equipes que querem client-side protection mais forte do que o mínimo de conformidade.

Como os relatórios da cside ajudam QSAs e evidências de auditoria?

Os relatórios da cside mostram URLs de páginas de pagamento, scripts detectados, alterações de cabeçalhos, decisões de autorização, justificativas de negócio, autores e carimbos de data e hora. Isso dá aos QSAs evidência de que scripts de páginas de pagamento são rastreados e revisados, sem depender de capturas de tela ou planilhas manuais.

A cside impõe controles de script ou apenas monitora?

Ambos, dependendo do modo. O método por script pode bloquear scripts e ações específicas em tempo de execução e também bloqueia tentativas de injeção de CSP voltadas a desativar o monitor. O método por varredura é, por desenho, apenas monitoramento. O PCI DSS permite explicitamente scanners de pós-autorização, e o PCI SSC confirmou isso diretamente.

Quão em tempo real é a detecção?

O método por script roda inline na sessão do usuário e envelopa a maioria das APIs do navegador para observar como os scripts modificam o DOM, de modo que a análise acontece enquanto os scripts executam. O mesmo hash de payload não é analisado duas vezes porque não agrega valor de segurança. O 11.6.1 não exige monitoramento de 100% das sessões; avaliação periódica é suficiente, e a cside atende tanto o critério periódico quanto o contínuo.

Como a cside lida com ataques novos ou ofuscados?

A detecção não é baseada em assinatura do script pai. A cside registra cada sub-requisição feita por um script, desofusca payloads antes da avaliação e executa análise aprofundada por IA em tudo que cruza o limiar de risco. Payloads novos e zero-day são um alvo específico de desenho. Veja Detecção de Ameaças para o pipeline completo de detecção.

Como as justificativas de negócio são rastreadas?

O painel PCI DSS registra cada justificativa na interface e no log de auditoria, incluindo quem a redigiu ou editou e quando. As justificativas geradas por IA são explicitamente permitidas pelo PCI SSC e são apresentadas ao revisor para confirmação, em vez de aceitas automaticamente.

Páginas relacionadas

• Detecção de Ameaças
• Detecção de Vulnerabilidades
• Logs de Auditoria
• Notificações