TL;DR

Se lida com dados de cartões de crédito, o PCI DSS é obrigatório. Ponto final. Abrange a forma de proteger os dados do titular do cartão (CHD) e os dados de autenticação sensíveis (SAD) - encriptação, firewalls, controlo de acesso, registo, verificação, tudo.

Se não o fizer, arrisca-se a multas, violações, processos judiciais e a ser excluído pelos processadores de pagamentos. A conformidade não é opcional - é uma questão de sobrevivência.

Resumo do Scorecard do PCI DSS:

• Esforço do programador: Moderado a elevado (requer codificação segura, configuração segura, tratamento cuidadoso dos dados do titular do cartão, adesão aos controlos de acesso, apoio a análises/registos de vulnerabilidades).
• Custo das ferramentas: Moderado a elevado (Firewalls, scanners de vulnerabilidades (scans ASV), monitorização da integridade dos ficheiros, registo/SIEM, ferramentas de encriptação, potencialmente soluções de tokenização/P2PE).
• Impacto no mercado: Crítico (obrigatório para qualquer entidade que trate dados de cartões de pagamento; o incumprimento pode resultar na incapacidade de processar pagamentos com cartão).
• Flexibilidade: Baixa a moderada (os requisitos principais são prescritivos, mas os métodos de implementação específicos podem variar; a v4.0 introduz mais flexibilidade com a "abordagem personalizada").
• Intensidade da auditoria: Elevada (requer validação anual através do Questionário de Auto-Avaliação (SAQ) ou do Relatório de Conformidade (ROC) formal por um Avaliador de Segurança Qualificado (QSA), para além de análises trimestrais de vulnerabilidades).

O que é o PCI DSS?

A Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) é uma norma global de segurança da informação concebida para evitar fraudes com cartões de crédito através de controlos acrescidos relativamente ao manuseamento e armazenamento de dados. Aplica-se a qualquer organização, independentemente da sua dimensão ou localização, que aceite, processe, armazene ou transmita dados do titular do cartão (CHD) ou dados de autenticação sensíveis (SAD).

O CHD inclui o número de conta principal (PAN), o nome do titular do cartão, a data de expiração e o código de serviço. O SAD inclui os dados completos da faixa, os códigos de verificação do cartão (CVV2, CVC2, etc.) e os PINs - o SAD nunca deve ser armazenado após a autorização.

O PCI DSS foi criado pelas principais marcas de cartões de pagamento (Visa, Mastercard, American Express, Discover, JCB) que formaram o PCI Security Standards Council (PCI SSC) para gerir a norma. A conformidade é imposta pelas marcas de cartões individuais e pelos bancos adquirentes, e não diretamente pelo PCI SSC.

A norma está organizada em torno de 6 objectivos que se traduzem em 12 requisitos essenciais (estes permanecem consistentes no conceito para o mais recente PCI DSS v4.0):

1. Criar e manter uma rede e sistemas seguros:
   
   • Req 1: Instalar e manter controlos de segurança da rede (firewalls).
   • Req 2: Aplicar configurações seguras a todos os componentes do sistema.
2. Proteger os dados da conta:
   
   • Req 3: Proteger os dados da conta armazenados (por exemplo, encriptar o PAN).
   • Req 4: Proteger os dados do titular do cartão com criptografia forte durante a transmissão através de redes abertas e públicas.
3. Manter um programa de gestão de vulnerabilidades:
   
   • Req 5: Proteger todos os sistemas e redes contra software malicioso.
   • Req 6: Desenvolver e manter sistemas e software seguros (aplicação de correcções, codificação segura).
4. Implementar medidas rigorosas de controlo de acesso:
   
   • Req 7: Restringir o acesso aos componentes do sistema e aos dados do titular do cartão de acordo com a necessidade de conhecimento da empresa.
   • Req 8: Identificar os utilizadores e autenticar o acesso aos componentes do sistema.
   • Req 9: Restringir o acesso físico aos dados do titular do cartão.
5. Monitorizar e testar regularmente as redes:
   
   • Req 10: Registar e monitorizar todos os acessos aos componentes do sistema e aos dados do titular do cartão.
   • Req 11: Testar regularmente a segurança dos sistemas e redes (análises de vulnerabilidades, testes de penetração).
6. Manter uma política de segurança da informação:
   
   • Req 12: Apoiar a segurança da informação com políticas e programas organizacionais.

A validação da conformidade varia de acordo com o volume de transacções processadas anualmente (Níveis de comerciante 1-4, Níveis de fornecedor de serviços 1-2), desde questionários anuais de autoavaliação (SAQs) a auditorias formais no local por um avaliador de segurança qualificado (QSA), resultando num relatório de conformidade (ROC). Normalmente, são necessárias verificações trimestrais de vulnerabilidades externas por um fornecedor de verificações aprovado (ASV). O PCI DSS v4.0 é a versão atual, com requisitos que se tornam obrigatórios até 31 de março de 2025.

Porque é que é importante?

Para qualquer empresa que toque em dados de cartões de pagamento, a conformidade com o PCI DSS é absolutamente essencial:

• Necessário para a aceitação do cartão: É exigido pelas principais marcas de cartões através de contratos com bancos adquirentes. A não conformidade pode levar à impossibilidade de aceitar pagamentos com cartão.
• Evita violações de dados: A implementação dos controlos do PCI DSS reduz significativamente o risco de violações dispendiosas dos dados do titular do cartão.
• Evita penalizações graves: O não cumprimento pode resultar em multas mensais substanciais por parte dos bancos adquirentes/marcas de cartões (variando de US$ 5.000 a US$ 100.000+ por mês), mesmo que não ocorra nenhuma violação.
• Reduz o impacto da violação: Se ocorrer uma violação, estar em conformidade com o PCI DSS demonstra a devida diligência e pode reduzir potencialmente as coimas, a responsabilidade legal e os custos de indemnização (como taxas de reemissão de cartões).
• Aumenta a confiança do cliente: A conformidade mostra aos clientes que leva a sério a segurança dos seus dados de pagamento, promovendo a confiança e a lealdade.
• Protege a reputação da marca: Uma violação de dados de cartões prejudica gravemente a reputação de uma empresa. O PCI DSS ajuda a evitar isso.
• Fornece uma linha de base de segurança: Oferece uma estrutura de segurança de base sólida que beneficia a postura de segurança geral da organização, não apenas para dados de pagamento.

Ignorar o PCI DSS não é uma opção para as empresas que pretendem aceitar cartões de pagamento.

O que e como implementar (técnica e política)

A implementação do PCI DSS envolve a abordagem dos 12 requisitos principais através de controlos técnicos e políticas/procedimentos documentados. As principais áreas que afectam o desenvolvimento e as operações incluem:

1. Rede segura (Requisitos 1 e 2):
   
   • Implementar e manter firewalls para segmentar o ambiente de dados do titular do cartão (CDE) de outras redes.
   • Utilizar configurações seguras: alterar as predefinições do fornecedor, desativar serviços/portas desnecessários, reforçar os sistemas. Evidências: Conjuntos de regras de firewall, padrões de configuração, diagramas de rede.
2. Proteger os dados do titular do cartão (Requisitos 3 e 4):
   
   • Minimizar o armazenamento: Não armazene os dados do titular do cartão, exceto se for absolutamente necessário. Nunca armazene o SAD após a autorização.
   • Mascarar PAN: mascarar o número de conta principal (PAN) quando apresentado (apenas os primeiros 6/últimos 4 dígitos são visíveis).
   • Encriptar o PAN: tornar ilegível o PAN armazenado utilizando criptografia forte (por exemplo, AES-256) e uma gestão de chaves robusta.
   • Encriptar a transmissão: Encriptar o CHD durante a transmissão através de redes abertas/públicas (utilizar versões TLS fortes, protocolos seguros). Provas: Política de retenção de dados, diagramas de fluxo de dados, configuração de encriptação, procedimentos de gestão de chaves.
3. Gestão de vulnerabilidades (Requisitos 5 e 6):
   
   • Anti-malware: Implementar e atualizar regularmente soluções anti-malware nos sistemas habitualmente afectados por malware.
   • Patching: Implementar um processo para identificar e aplicar prontamente patches de segurança (dentro de prazos definidos para patches críticos).
   • Codificação segura: Desenvolver aplicações de software (internas ou personalizadas) com base em diretrizes de codificação segura (por exemplo, OWASP), formar os programadores, resolver vulnerabilidades de codificação comuns (injeção, XSS, etc.). Elementos de prova: Registos de gestão de patches, política de codificação segura, registos de formação de programadores, resultados do SAST/DAST.
4. Controlo de acesso (requisitos 7, 8 e 9):
   
   • Menos privilégio/Necessidade de saber: Restringir o acesso ao CHD e aos componentes do sistema com base na função e nas permissões mínimas necessárias.
   • IDs únicos e autenticação: Atribuir IDs únicos para acesso; implementar uma autenticação forte (palavras-passe/frases-chave complexas, MFA - especialmente para acesso CDE).
   • Segurança física: Acesso físico seguro aos sistemas de armazenamento/processamento de CHD. Evidências: Políticas de controlo de acesso, configuração RBAC, definições MFA, política de palavras-passe, registos de acesso físico.
5. Monitorização e testes (Requisitos 10 e 11):
   
   • Registo: Implementar um registo de auditoria detalhado para todos os componentes do sistema; controlar o acesso aos recursos da rede e ao CHD. Proteger os registos contra adulteração. Utilizar sincronização de tempo (NTP).
   • Revisão de registos: Rever regularmente os registos para detetar actividades suspeitas.
   • Verificação de vulnerabilidades: Efetuar trimestralmente análises externas de ASV e análises internas de vulnerabilidades. Resolver as vulnerabilidades.
   • Testes de penetração: Efetuar anualmente testes de penetração internos/externos (e após alterações significativas).
   • Deteção/Prevenção de Intrusões: Implementar IDS/IPS.
   • Deteção de alterações: Utilizar a monitorização da integridade dos ficheiros (FIM) para ficheiros críticos. Evidências: Procedimentos de revisão de registos, configuração do SIEM, relatórios de análise ASV, relatórios de pentest, registos FIM.
6. Política de segurança da informação (Req 12):
   
   • Manter uma política global de segurança da informação, revê-la anualmente e distribuí-la ao pessoal relevante.
   • Definir as responsabilidades em matéria de segurança e efetuar uma formação de sensibilização.
   • Implementar um plano de resposta a incidentes e testá-lo. Evidências: Documento de política InfoSec, registos de formação, plano de resposta a incidentes e resultados de testes.

O PCI DSS v4.0 introduz actualizações como requisitos de palavra-passe/MFA mais fortes, maior aplicabilidade dos controlos, novos requisitos para prevenção de phishing e segurança de scripts em páginas de pagamento e permite uma "abordagem personalizada" para cumprir os requisitos em condições específicas, juntamente com a tradicional "abordagem definida".

Erros comuns a evitar

Atingir e manter a conformidade com o PCI DSS é muitas vezes um desafio. Evite estes erros comuns:

1. Definição incorrecta do âmbito: Não identificar com exatidão todos os sistemas, redes e aplicações que armazenam, processam ou transmitem CHD, ou que podem afetar a segurança do CDE. Este é o erro mais crítico.
2. Armazenamento de dados de autenticação sensíveis (SAD): Armazenamento ilegal de CVV2, dados de rastreio completos ou dados de PIN após autorização.
3. Proteção de dados inadequada: Armazenamento de PANs não encriptados, utilização de encriptação/gestão de chaves fraca ou transmissão de CHD através de canais inseguros.
4. Controlo de acesso deficiente: Utilização de credenciais partilhadas/por defeito, falta de MFA para o acesso CDE, não aplicação do privilégio mínimo, não revogação imediata do acesso.
5. Registo e monitorização insuficientes: Não registar eventos relevantes, não rever os registos regularmente ou não proteger os registos contra adulteração.
6. Ignorar a gestão de vulnerabilidades: Saltar análises ASV trimestrais, falhar análises internas, não corrigir rapidamente vulnerabilidades críticas.
7. Práticas de codificação pouco seguras: Desenvolvimento de aplicações com vulnerabilidades comuns (SQLi, XSS) que expõem a CHD.
8. Negligência de políticas e procedimentos: Falta de políticas e procedimentos documentados ou de um plano de resposta a incidentes, ou falta de formação dos funcionários.
9. Conformidade do fornecedor: Assumir que os fornecedores de serviços terceiros estão em conformidade sem verificar ou ter acordos contratuais adequados.
10. Tratar a conformidade como anual: Encarar o PCI DSS apenas como uma auditoria/SAQ anual em vez de um processo de segurança contínuo.

O que os auditores/QSAs podem perguntar (foco no desenvolvedor)

Uma auditoria de Avaliador de Segurança Qualificado (QSA) para o PCI DSS investigará as práticas de desenvolvimento relacionadas com o Requisito 6 (Sistemas e Software Seguros):

• (Req 6.2) "Descreva os seus processos de ciclo de vida de desenvolvimento de software seguro (SSDLC)".
• (Req. 6.2.1) "Como é que o software personalizado e por medida é desenvolvido com base nas normas do sector e/ou no PCI DSS (por exemplo, diretrizes de codificação segura como a OWASP)?"
• (Req 6.2.2) "Como é que os programadores recebem formação em técnicas de codificação segura?" (Mostrar registos de formação)
• (Req 6.2.3) "Como é que as alterações de código são revistas para detetar vulnerabilidades de segurança antes de serem lançadas?" (Descrever o processo de revisão do código)
• (Req 6.2.4) "Como é que assegura a separação de tarefas entre os ambientes de desenvolvimento/teste e de produção?"
• (Req 6.3) "Como identificar e inventariar o software personalizado e sob medida?"
• (Req 6.4 - v4.0) "Como é que gere os scripts das páginas de pagamento para garantir a integridade e autorizar os scripts?" (Relevante para programadores Web)
• (Req. 6.5 - v3.2.1 / vários na v4.0) "Como se protege contra vulnerabilidades de codificação comuns, como falhas de injeção, excessos de memória, armazenamento criptográfico inseguro, XSS, etc.? (É necessário mostrar exemplos de código, utilização de ferramentas - SAST/DAST)
• (Req 3) "Mostrar como os dados sensíveis (PAN) são protegidos no armazenamento (encriptação, hashing, truncagem) dentro da aplicação."
• (Req 4) "Demonstrar como os dados sensíveis são encriptados durante a transmissão."
• (Req 8) "Como é que a aplicação impõe a complexidade da palavra-passe e os requisitos MFA?"

As QSA necessitam de provas de processos documentados, formação de programadores, adesão a normas de codificação segura, revisões de código, resultados de testes de segurança (SAST/DAST) e configuração segura na aplicação.

Ganhos rápidos para as equipas de desenvolvimento

Os programadores podem contribuir significativamente para a conformidade com o PCI DSS:

1. NUNCA armazenar DAU: garantir que o código nunca regista, armazena ou retém CVV2, dados de rastreio ou PINs após a autorização.
2. Minimizar o manuseamento de CHD: Se possível, utilize processadores/gateways de pagamento de terceiros que mantenham o CHD totalmente fora dos seus sistemas (reduzindo o âmbito). Se tiver de o tratar, minimize o local onde flui e é armazenado.
3. Noções básicas de codificação segura: Foco na prevenção das 10 principais vulnerabilidades OWASP, especialmente injeção (SQLi, injeção de comando) e Cross-Site Scripting (XSS), através de validação de entrada e codificação de saída.
4. Parametrize as consultas ao banco de dados: Utilize sempre instruções preparadas ou consultas parametrizadas para evitar a injeção de SQL.
5. Encriptar/Hash/Tokenizar PAN: Se armazenar PAN, utilize uma encriptação forte e padrão (AES-256) com uma gestão de chaves adequada ou considere soluções de tokenização. Não crie a sua própria criptografia.
6. Utilizar TLS forte: Assegurar que todas as transmissões de CHD utilizam versões actuais e seguras de TLS e conjuntos de cifras fortes.
7. Implementar a validação de entradas: Validar rigorosamente todas as entradas dos utilizadores ou sistemas externos.
8. Aplicar cabeçalhos de segurança: Utilizar cabeçalhos de segurança HTTP (como Content-Security-Policy) para mitigar XSS e outros ataques do lado do cliente, especialmente importantes para o Req 6.4 na v4.0.

Ignorar isto e... (Consequências do incumprimento)

Ignorar o PCI DSS pode ser financeiramente prejudicial e devastador para a reputação:

• Multas mensais: Os bancos adquirentes cobram multas pesadas por não conformidade, normalmente variando de US$ 5.000 a US$ 100.000+ por mês, aumentando com base no nível de conformidade e na duração da não conformidade.
• Aumento das taxas de transação: Os bancos podem aumentar as taxas de transação para os comerciantes não conformes.
• Sanções da marca do cartão: As marcas de cartões podem impor diretamente sanções adicionais.
• Cessação do processamento de cartões: Os bancos podem revogar totalmente a capacidade de aceitar cartões de pagamento, encerrando efetivamente os fluxos de receitas de pagamento com cartão.
• Custos da violação de dados: Se a não conformidade conduzir a uma violação, os custos disparam. Isto inclui investigações forenses, custos de substituição de cartões ($3-5+ por cartão), monitorização de crédito para as vítimas, honorários legais, multas regulamentares (por exemplo, RGPD, se aplicável) e potenciais acções judiciais.
• Danos à reputação: A divulgação pública de um incumprimento ou de uma violação dos dados do cartão prejudica gravemente a confiança dos clientes e a imagem da marca.
• Maior escrutínio: Após a não conformidade ou uma violação, as organizações enfrentam um escrutínio mais intenso por parte dos bancos e das marcas de cartões.

FAQ

Quem precisa de estar em conformidade com o PCI DSS?

Qualquer organização que aceite, processe, armazene ou transmita dados de titulares de cartões das principais marcas de cartões (Visa, Mastercard, American Express, Discover, JCB). Isto inclui comerciantes, fornecedores de serviços (como processadores de pagamentos, fornecedores de alojamento) e instituições financeiras.

Qual é a diferença entre o PCI DSS v3.2.1 e a v4.0?

O PCI DSS v4.0 é a versão mais recente, substituindo a v3.2.1 (que se aposenta em 31 de março de 2024, embora os novos requisitos da v4.0 sejam práticas recomendadas até 31 de março de 2025). As principais alterações na v4.0 incluem requisitos actualizados de palavra-passe/MFA, aplicabilidade mais ampla dos controlos de segurança, novos requisitos direcionados para ataques de phishing e skimming no comércio eletrónico, orientações mais claras e a introdução de uma "abordagem personalizada" como forma alternativa de cumprir os objectivos dos requisitos, juntamente com a tradicional "abordagem definida".

O que são os níveis de comerciante / níveis de fornecedor de serviços?

Estas categorizam as organizações com base no volume anual de transacções com cartões que processam. O nível 1 (maior volume) tem os requisitos de validação mais rigorosos (ROC anual por QSA, verificações trimestrais por ASV). Os níveis 2, 3 e 4 têm volumes progressivamente mais baixos e normalmente são validados por meio de SAQs anuais e varreduras ASV trimestrais.

O que é um QSA e um ASV?

Um QSA (Qualified Security Assessor) é um indivíduo certificado pelo PCI SSC para realizar avaliações do PCI DSS no local e produzir Relatórios de Conformidade (ROCs) para comerciantes/prestadores de serviços de Nível 1. Um ASV (Approved Scanning Vendor) é uma organização certificada pelo PCI SSC para realizar as verificações trimestrais de vulnerabilidade de rede externa necessárias.

O que é o ambiente de dados do titular do cartão (CDE)?

O CDE compreende as pessoas, os processos e a tecnologia que armazenam, processam ou transmitem dados do titular do cartão ou dados de autenticação confidenciais. Definir com exatidão o âmbito do CDE é o primeiro passo fundamental para a conformidade com o PCI DSS, uma vez que os requisitos se aplicam principalmente a este ambiente. A segmentação da rede pode ser usada para reduzir o escopo do CDE.

Podemos armazenar o código CVV2?

Não. Os Dados de Autenticação Sensíveis (SAD), que incluem o código de verificação do cartão de 3 ou 4 dígitos (CVV2, CVC2, CID, CAV2), dados completos da banda magnética e PINs, nunca devem ser armazenados após a autorização da transação estar concluída. O armazenamento do SAD é uma violação grave da conformidade.

A conformidade com o PCI DSS é legalmente exigida?

Embora o PCI DSS seja uma norma do sector criada pelas marcas de cartões, a conformidade é normalmente exigida contratualmente através de acordos entre os comerciantes, os bancos adquirentes e as marcas de cartões. O incumprimento viola estes contratos, conduzindo a sanções aplicadas pelos bancos/marcas. Pode também sobrepor-se aos requisitos legais, como o RGPD, se estiverem em causa dados pessoais.