Conformidade PCI DSS gratuita vs. paga: o que realmente funciona

Resumo: conformidade gratuita com o PCI DSS 6.4.3 e 11.6.1

• Base gratuita: É possível atingir a base do 6.4.3 e do 11.6.1 a custo zero numa plataforma de monitorização de scripts de nível gratuito. Inventário, fluxo de autorização, deteção de adulteração, evidência pronta para QSA.
• Quando o pago compensa: Os níveis pagos acrescentam bloqueio automatizado, retenção mais longa, alertas mais completos e RBAC. Acima do Nível 3, isso normalmente compensa o investimento.
• Prazo: Ambos são obrigatórios desde 31 de março de 2025. Adiar é um risco de reprovação junto do QSA na próxima avaliação.

Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.

Porque foram estabelecidos estes requisitos

Desde que o JavaScript foi introduzido nos browsers em 2011, a execução do lado do cliente abriu caminho a ataques generalizados de furto de dados de cartões. Atores sofisticados injetam agora scripts maliciosos através de dependências, plugins ou comprometimentos na cadeia de fornecimento, ameaçando a segurança dos dados de cartões de pagamento. Na maioria das vezes, exfiltram dados de pagamento de forma dinâmica, muitas vezes visando apenas uma pequena percentagem de utilizadores para não serem detetados.

A Visa, a Mastercard e a Amex já identificaram os ataques baseados em scripts do lado do cliente como a principal fonte de furto de dados de cartões de crédito. A tokenização ajuda, mas apenas até certo ponto. Se o cliente for comprometido, o ataque continua a ser bem-sucedido.

Por isso, o PCI DSS v4.0 exige, com razão, que as empresas implementem controlos para:

• Impedir a execução de scripts não autorizados (6.4.3)
• Garantir a integridade dos scripts (6.4.3)
• Manter um inventário atualizado de scripts com justificações de negócio (6.4.3)
• Detetar adulterações ou alterações não autorizadas nas páginas de pagamento (11.6.1)

Como alcançar a conformidade com o PCI DSS sem comprar uma solução

Se tiver recursos, capacidade técnica e disponibilidade para manter a ferramenta por conta própria, eis como se pode fazer.

1. Impedir scripts não autorizados (6.4.3)

Para cumprir o requisito de garantir que só scripts autorizados podem carregar e ser executados, é preciso uma camada de aplicação forte. Uma Content Security Policy (CSP) pode servir este propósito, mas tem de ser configurada de forma rigorosa e mantida ativamente.

O que se pode fazer:

• Implementar um cabeçalho CSP rigoroso usando script-src para colocar em lista branca os domínios permitidos.
• Usar nonces ou hashes para permitir explicitamente scripts inline ou dinâmicos.
• Auditar regularmente a política e atualizá-la com qualquer alteração de scripts.

É suficiente para o PCI? Sim, MAS apenas em termos formais. Os scripts dinâmicos NÃO podem ficar totalmente protegidos com a CSP.

A CSP é reconhecida como um controlo válido para autorizar scripts. No entanto, a CSP por si só não regista a intenção. É preciso documentação de apoio que comprove porque é que cada fonte permitida foi autorizada.

MAS, relembre a frase acima:

"Para os comerciantes se qualificarem para o SAQ A, têm de confirmar que o seu site não é suscetível a ataques provenientes de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante"*.

A CSP resolve isto neste contexto? NÃO. Se uma fonte se mantiver igual mas o conteúdo do script entregue mudar, uma CSP NÃO o deteta.

O ataque ao Polyfill em 2024 não teria sido travado por uma CSP. Isto significa, tecnicamente, que o seu site É suscetível a ataques, pelo que precisa de uma ferramenta de segurança para estar totalmente em conformidade. Pode criar uma conta ou marcar uma demonstração para falar connosco.

Considere o seguinte como parte da sua checklist de conformidade PCI:

• Usar CSP com restrições script-src e nonces/hashes.
• A CSP tem de ser atualizada e auditada regularmente.
• Gerir a CSP com cuidado; é frágil e pode quebrar aplicações.

2. Verificar a integridade dos scripts (6.4.3)

Espera-se que seja detetado quando um script foi adulterado. Para scripts estáticos, a Subresource Integrity (SRI) é uma solução padrão. Verifica que apenas os scripts com o hash esperado carregam com sucesso.

O que se pode fazer:

• Adicionar os atributos integrity e crossorigin a cada tag `` de terceiros.
• Obter periodicamente os scripts, calcular o hash e comparar com hashes conhecidos como corretos.

É suficiente para o PCI? Sim, MAS apenas para scripts estáticos. Os scripts dinâmicos NÃO podem ser cobertos apenas com SRI.

Os scripts dinâmicos (por exemplo, ferramentas de analytics, executores de testes A/B) mudam frequentemente a cada pedido e vão quebrar a SRI. O PCI espera que reconheça e mitigue esta limitação, evitando scripts dinâmicos ou implementando uma forma de monitorização.

Como monitorizar esses scripts? Isso não é possível sem ferramentas. Ou uma solução paga (como a nossa, aqui na cside 👋), ou uma solução construída por si.

Sem entrar em detalhe, eis como poderia construir a sua própria ferramenta de monitorização:

1. Criar uma lista de URLs de scripts dinâmicos
2. Obter o conteúdo dos scripts
3. Normalizar o payloadRemover timestamps, cache-busters ou cabeçalhos de rastreio de CDN (se necessário).
4. Guardar uma versão limpa do conteúdo para comparação.

Calcular o hash ou fazer diff do resultado

1. Se tiver mudado: registar e alertar.

Alertar sobre alterações inesperadas

1. Enviar um e-mail, por exemplo

Documentar o processo

1. O PCI quer evidência de que está a monitorizar ativamente a integridade dos scripts.
2. Manter registos dessas verificações e de quaisquer ações resultantes.

No entanto, isto é praticamente viável?

Construiria o seu próprio software antivírus, por exemplo? Diríamos que, para a maioria de nós, a resposta é claramente "não". Construir um motor para sinalizar comportamentos maliciosos em JS é algo difícil de fazer e exigirá um conjunto de dados substancial para ser bem-sucedido. Isto vai muito além de uma questão de tempo despendido. É também uma questão de recursos.

Resumo:

• A SRI só funciona para scripts estáticos. Use-a onde for possível.
• A SRI NÃO funciona com scripts que têm payloads variáveis.
• É necessária a monitorização do conteúdo real dos scripts através de ferramentas.

3. Manter um inventário de scripts (6.4.3)

Espera-se que mantenha um inventário de todos os scripts executados na página de pagamento. Isto inclui scripts estáticos e dinâmicos, bem como scripts inline, fontes de terceiros (como gestores de tags ou analytics) e tudo o que seja carregado através de frameworks (como React ou Vue). O PCI quer ver que todos os scripts foram revistos, aprovados e têm uma justificação de negócio ou técnica. Isto a cada 7 dias (base semanal).

O que se pode fazer:

• Criar uma lista com controlo de versões (folha de cálculo ou ficheiro YAML/JSON).
• Incluir: fonte do script, hash esperado (se estático), justificação de negócio/técnica, responsável/equipa.
• Atualizar em cada implementação ou alteração de código (não alterações no código do script) que afete a página de pagamento.

Eis o que deve incluir:

• A fonte ou URL
• Se é estático ou dinâmico
• Um hash (se for estático e a SRI for usada)
• Justificação de negócio/técnica
• Responsável ou equipa responsável
• Notas sobre monitorização (especialmente para scripts dinâmicos)

Guias relacionados

Aprofunde-se no cluster:

• as responsabilidades partilhadas do PCI DSS da Stripe
• as responsabilidades partilhadas do PCI DSS da Adyen
• as responsabilidades partilhadas do PCI DSS do PayPal Braintree
• comparação de soluções para o PCI DSS 6.4.3 e 11.6.1
• vikingcloud-approves-c-sides-security-platform-for-pci-dss-v4-0-1-requirement-6-4-3-and-11-6-1
• como cumprir o PCI DSS 6.4.3
• as atualizações de janeiro de 2025 ao PCI DSS SAQ A, desmistificadas

É suficiente para o PCI? Sim, o PCI não exige mais nada aqui. Uma lista manual é aceitável, desde que seja precisa e mantida. Os scripts dinâmicos continuam a ter de ser listados, mesmo que não seja possível calcular o hash. Nesses casos, o PCI espera que explique por que motivo a SRI não pode ser usada e como o script está a ser monitorizado. NOTA: Isto NÃO significa que possa simplesmente criar um inventário e não agir sobre os pontos acima. É um requisito descrito de forma um pouco mais aberta, que alguns veem como a solução mágica. Não é.

4. Deteção de adulteração e alterações (11.6.1)

O PCI quer que detete alterações não autorizadas na página de pagamento tal como recebida no browser do utilizador. Isto inclui alterações ao conteúdo e aos cabeçalhos HTTP (como CSP, CORS, etc.).

O que se pode fazer:

• Usar um browser headless (por exemplo, Puppeteer) ou curl para obter a página de pagamento em tempo real. Isto vai exigir gastar dinheiro...
• Capturar cabeçalhos e conteúdo HTML.
• Comparar com uma base conhecida como correta e alertar sobre alterações.
• Normalizar a saída se necessário para evitar falsos positivos (especialmente importante para conteúdo dinâmico).
• Documentar que alterações disparam alertas, quem responde e como.

É suficiente para o PCI? Sim, DESDE QUE seja executado regularmente e esteja documentado quais alterações disparam alertas, quem é notificado e qual é o plano de resposta. A cadência exigida é semanal, A MENOS QUE seja justificada de outra forma por uma análise de risco.

Nota sobre páginas dinâmicas: Frameworks renderizadas do lado do cliente (React, Vue, etc.) frequentemente carregam ou alteram o DOM depois do carregamento da página. Se isto não for tido em conta, a monitorização vai sinalizar falsos positivos. Para o PCI, isto é, em princípio, aceitável, DESDE QUE se defina claramente o que de facto se verifica (por exemplo, o cabeçalho CSP, os domínios de scripts externos, seletores DOM-chave) e porquê. Se ainda assim sofrer um ataque, o requisito mantém-se: "Para os comerciantes se qualificarem para o SAQ A, têm de confirmar que o seu site não é suscetível a ataques provenientes de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".

Resumo:

• Usar curl ou browser headless para capturar e comparar cabeçalhos e HTML.
• Normalizar conteúdo dinâmico para reduzir falsos positivos.
• Executar verificações semanalmente (ou com maior frequência consoante o risco).
• Configurar alertas e um processo de resposta documentado.

O que uma auditoria de conformidade com o PCI DSS 4.0.1 verifica para o 6.4.3 e o 11.6.1

Uma auditoria de conformidade com o PCI DSS 4.0.1 para comerciantes de e-commerce examina se o inventário da página de pagamento está completo, se todos os scripts têm uma justificação de negócio ou técnica autorizada, e se o comerciante consegue provar que existe um mecanismo de deteção de alterações a funcionar sobre os cabeçalhos HTTP da página de pagamento pelo menos uma vez a cada sete dias. Os requisitos 6.4.3 e 11.6.1 são as duas cláusulas em que um QSA vai gastar mais tempo nos fluxos card-not-present.

Os artefactos visíveis na auditoria são específicos: uma lista de inventário de scripts com responsável, propósito e hash esperado para cada entrada; aprovações documentadas; e evidência em registos de que o mecanismo de deteção de alterações foi executado na cadência exigida, com alertas a chegar a um canal monitorizado. Se algum destes artefactos estiver em falta ou não puder ser reproduzido a pedido, a auditoria assinalará o 6.4.3 ou o 11.6.1 como não conformes, independentemente da qualidade de qualquer outro controlo.

A cside produz o inventário de scripts automaticamente a partir de dados em tempo real da página de pagamento, mantém hashes e o estado de aprovação, e executa continuamente o ciclo de deteção de alterações do 6.4.3, com um registo de evidência que um QSA pode extrair diretamente.

Os benefícios de negócio da conformidade com o PCI DSS para além de evitar multas

Os benefícios da conformidade com o PCI DSS para além de evitar multas são concretos: estabilidade da relação com o adquirente, confiança das marcas de pagamento e um custo materialmente mais baixo de resposta a incidentes caso ocorra uma violação. Os comerciantes continuamente conformes mantêm a relação com o adquirente fora da fila de escalonamento, retêm o acesso às tarifas de interchange mais baixas oferecidas pelo seu processador e reduzem o volume de trabalho forense que um incidente desencadeia.

Existe também um benefício a jusante para grandes compradores de e-commerce. As equipas de compras empresariais exigem cada vez mais a atestação PCI DSS como pré-requisito de fornecedor. A conformidade contínua significa que o AoC está sempre atualizado quando chega um pedido de compras, em vez de uma correria a cada ciclo anual.

A monitorização contínua da cside mantém a cadeia de evidência do 6.4.3 e do 11.6.1 atualizada em tempo real, o que significa que a janela de preparação para auditoria passa de semanas de recuperação para uma exportação no mesmo dia.

Não conformidade com o PCI DSS e as penalizações que os comerciantes realmente enfrentam

A não conformidade com o PCI DSS acarreta três níveis de penalização que atingem diretamente os comerciantes. As redes de cartões aplicam multas através do adquirente, tipicamente começando em alguns milhares de dólares por mês numa primeira infração e escalando para valores mensais de cinco ou seis dígitos se o comerciante continuar não conforme ao longo dos ciclos de auditoria. O adquirente frequentemente repassa estas multas na íntegra e acrescenta o seu próprio agravamento de serviço.

O segundo nível é o custo ao nível da transação. Um comerciante considerado não conforme no momento de uma violação enfrenta taxas de interchange mais elevadas nas transações seguintes e maior responsabilidade por chargebacks. As penalizações por não conformidade com o PCI DSS somam-se à responsabilidade decorrente da violação ao abrigo da legislação estadual e federal.

O terceiro nível é a penalização estratégica. A não conformidade persistente pode levar à perda dos direitos de processamento de cartões ou à inclusão na lista MATCH, o que restringe a capacidade do comerciante de obter processamento de pagamentos junto de outros adquirentes.

A cside reduz tanto o risco de não conformidade como o custo de preparação para auditoria, mantendo os controlos 6.4.3 e 11.6.1 num estado continuamente verificável.

Uma checklist concisa de conformidade com o PCI DSS 4.0.1 para o 6.4.3 e o 11.6.1

Uma checklist de conformidade com o PCI DSS 4.0.1 para os requisitos de página de pagamento 6.4.3 e 11.6.1 é curta, mas rigorosa. Percorra-a por ordem antes de uma auditoria:

1. Inventário completo de scripts. Todos os scripts que carregam na página de pagamento estão listados com fonte, propósito, responsável de negócio e hash esperado quando o script é estático.
2. Aprovação documentada por script. Cada entrada tem uma decisão de aprovação registada por uma pessoa responsável e um registo temporal de revisão dentro do último ciclo de revisão.
3. Mecanismo de deteção de alterações instalado. Uma ferramenta ou processo deteta alterações não autorizadas aos cabeçalhos HTTP e ao conteúdo de scripts na página de pagamento e consegue produzir evidência das execuções.
4. Cadência semanal comprovada. A evidência em registos mostra que o mecanismo de deteção de alterações foi executado pelo menos a cada sete dias durante todo o período de auditoria.
5. Encaminhamento de alertas verificado. Os alertas são encaminhados para um canal monitorizado com um caminho de escalonamento para a segurança ou engenharia.
6. Evidência de teste em condições reais. Uma alteração de teste numa página de pagamento fora de produção foi detetada e alertada dentro da janela exigida.
7. Controlos compensatórios documentados, se usados. Qualquer desvio da abordagem padrão está documentado com a justificação do controlo compensatório.

A cside produz os itens 1 a 6 como evidência contínua, pelo que a auditoria passa a ser uma revisão do sistema em funcionamento, e não uma reconstrução a posteriori.

Então, é possível fazer isto "de graça"?

Sim, mais ou menos. Mas é praticamente impossível.

É tecnicamente possível, mas prática E estruturalmente frágil. Mais importante ainda, é bastante provável que gaste mais dinheiro, tempo e recursos do que optando por uma solução paga.

Seria preciso:

• Escrever as suas próprias ferramentas ou scripts
• Construir o seu próprio método para analisar scripts — isto é dispendioso e, como empresa que não é de segurança, provavelmente não terá acesso aos dados ou às competências necessárias para o fazer. Construiria o seu próprio antivírus?
• Monitorizar a integridade dos scripts manualmente
• Manter um inventário de scripts com disciplina
• Normalizar e comparar páginas dinâmicas sem se afundar em falsos positivos

E, mais importante ainda: É preciso provar que o seu site não é suscetível a ataques do lado do cliente, tal como exigido explicitamente na atualização de janeiro do PCI DSS.

Uma CSP não vai travar ataques à cadeia de fornecimento. Uma SRI não é compatível com scripts dinâmicos. E uma verificação básica com curl não protege contra exfiltração seletiva e sensível ao contexto.

Se optar pelo caminho de fazer você mesmo: Documente tudo, automatize onde puder e prepare-se para a sobrecarga. E, se possível, construa as suas próprias ferramentas. Mas, acima de tudo, calcule o seu tempo e recursos (humanos ou outros) e faça as contas. É provável que esteja melhor servido optando por uma solução paga.

Se procura estar completamente em conformidade e em segurança, foi exatamente para isso que construímos a cside. Pode marcar uma demonstração aqui ou criar uma conta para estar em conformidade já hoje.

Compreender especificamente o PCI 11.6.1

Enquanto o 6.4.3 se foca no inventário e na justificação de scripts, o PCI DSS 11.6.1 foca-se em detetar alterações não autorizadas a scripts e a cabeçalhos de segurança HTTP nas páginas de pagamento.

O PCI 11.6.1 exige que:

• Monitorize o conteúdo e a configuração de todos os scripts em execução nas páginas de pagamento
• Deteta adulteração, injeção ou modificação não autorizada em tempo útil
• Alerte o pessoal apropriado quando são detetadas alterações não autorizadas

A palavra "útil" é intencionalmente deixada à interpretação do QSA, mas é geralmente entendida como deteção dentro de minutos a horas após a alteração. Verificações semanais ou mensais não satisfazem o 11.6.1. A monitorização contínua da cside dispara alertas em tempo real à medida que as alterações ocorrem, dando à sua equipa de segurança a janela de resposta que a conformidade exige.