A Pomelo recentemente renovou sua certificação PCI-DSS na última versão, a 4.0. Foi uma conquista que demonstrou nosso compromisso com a segurança dos dados e nossa capacidade de nos adaptarmos aos requisitos de segurança cada vez mais exigentes definidos pelo setor de pagamentos.
A nova versão da norma foi lançada globalmente em março de 2022 e será obrigatória somente em março de 2025 – espera-se que as instituições responsáveis consigam se adaptar aos novos requisitos dentro desse período.
Vamos conferir a seguir os detalhes técnicos dessa nova versão da PCI-DSS e como conseguimos ser uma das primeiras empresas da América Latina a obtê-la.
O que muda na versão 4.0 da PCI-DSS?
O mundo mudou muito desde o lançamento da versão anterior da PCI-DSS, 3.2.1, lançada em 2018. Com o crescimento das operações online, impulsionado pela pandemia e pela expansão das soluções em nuvem, foram reforçados e melhorados os controles com a mais nova edição, na qual foram adicionados 63 novos pontos de verificação, somando um total de 423 controles, distribuídos em 12 áreas temáticas e 3 anexos. Todos eles, em conjunto, buscam elevar o nível geral de segurança de todas as entidades abrangidas pelos regulamentos.
Isso significa que a obtenção da certificação, que mesmo em sua versão anterior já era complexa, ficou ainda mais difícil. Por isso trazemos alguns dos desafios que enfrentamos para chegar à versão mais recente do PCI-DSS.
Desafios do PCI-DSS 4.0 que resolvemos
Análise GAP
A primeira etapa antes de poder realizar a certificação foi fazer uma análise minuciosa para avaliar se era realmente possível tocar a nova versão em um prazo razoável – ou se seria preferível ficar com a 3.2.1 e aproveitar os prazos vigentes –, devido ao esforço envolvido.
Dessa forma, foi possível identificar os pontos que exigiam maior dedicação, calcular o esforço para cumpri-los e, em seguida, elaborar um cronograma distribuído em marcos e seus respectivos entregáveis, confirmando o resultado final no período previsto.
CDE: testes de alcance e segmentação
Os ajustes feitos tanto no requisito 1 quanto no apêndice A1 se concentram na revisão e na definição explícita do escopo da chamada zona CDE (Card Data Environment). Ou seja, o segmento de rede onde se concentram os dados do cartão e, consequentemente, onde se consolida a grande maioria dos controles e ferramentas a serem implantados ao longo dos pontos seguintes.
Inicialmente, a equipe de DevSecOps atualizou e documentou detalhadamente o relacionamento e os componentes do CDE. Esse escopo foi então verificado por um fluxograma desenvolvido em conjunto pelas equipes de Payment Processor e Issuing, validando que as informações afetadas fluíam exclusivamente dentro das contas estabelecidas.
Uma vez definidos os limites desse segmento, a equipe de Platform Solutions desenvolveu uma extensa série de testes técnicos, demonstrando que a separação entre eles é realizada de forma concreta e robusta, gerando evidência empírica que ressalta a solidez dos controles implementados.
Criptografia de dados de autenticação confidenciais (SAD)
Entre os novos requisitos da versão 4.0, talvez o controle mais complexo seja o definido no requisito 3, em que os requisitos técnicos são estendidos ao nível de criptografia, abrangendo todo o ciclo de vida dos dados SAD (Sensitive Authentication Data), tanto antes do processamento quanto durante o transporte e em repouso.
Para atender a esses requisitos, a equipe da Platform Solutions (mais uma vez!) implementou uma versão aprimorada do gateway de solicitação do cliente. Foi incorporada uma criptografia em nível de carga útil com suporte de algoritmos RSA, que, complementada com as implementações de MTLS (em nível de transporte) e AES 256 (em nível de banco de dados), atinge o nível suficiente e necessário que satisfaz esses pontos.
Anti-malware
O requisito 5 incorpora novos pontos relacionados a políticas anti-malware em vários componentes do ambiente, tanto no nível da estação de trabalho quanto na prevenção de pessoas (anti-phishing), além de um aumento na frequência dos controles.
A equipe do Access Response assumiu todo o escopo e conseguiu cumprir a tarefa ajustando as funcionalidades do mecanismo anti-phishing e da solução de detecção e resposta de endpoint (EDR), bem como ajustando o cronograma das revisões que vinham fazendo desde o ciclo anterior.
Autenticação forte
O oitavo requisito reforça vários controles em relação à autenticação:
- O número mínimo de caracteres exigidos para senhas aumentou de 8 para 12.
- A autenticação de dois fatores torna-se obrigatória para ambientes e ações críticas.
O modelo Zero Trust (leia o conteúdo em espanhol) implementado pela equipe de Access Response foi ideal para atender a esses requisitos. Além disso, a incorporação de uma ferramenta DAST (Teste Dinâmico de Segurança de Aplicativos) abrange outro requisito novo e muito específico: garantir que não haja senhas codificadas a nível de código.
Varredura de vulnerabilidade autenticada
O requisito 11 exige que as varreduras de vulnerabilidade sejam conduzidas com usuários autenticados, o que não era um requisito na versão anterior.
Esse ajuste foi imediatamente incorporado pela equipe de Platform Solutions em seu cronograma de testes e esquema de testes, após uma avaliação prévia completa de sua viabilidade técnica.
E fomos com tudo!
Além dos desafios mencionados acima, há novos recursos importantes a serem observados sobre essa nova versão, que também abordamos para estar em cumprimento adequado. Estes são alguns deles:
- Inventário de certificados digitais: Uma nova adição ao requisito 4 exige o detalhamento dos certificados digitais usados na solução. Para cumprir o requisito, a equipe de Governança, Risco e Conformidade (GRC) pesquisou e listou os certificados associados ao ambiente CDE, incluindo o domínio, a entidade emissora e a data de validade.
- Revisões periódicas de usuários: Vale a pena observar que o requisito 7 aumenta o nível e a frequência das revisões das permissões e funções dos usuários associados ao CDE. Mais uma vez, a equipe de Access Response implementou uma matriz ampliada e aprimorada das funções designadas a cada usuário afetado, gerando as evidências necessárias.
- Prevenção e detecção de intrusões: Um controle que antes era levantado como sugestão, a partir desta versão passa a ser obrigatório: a necessidade de ter uma ferramenta de prevenção e detecção de intrusões. Desde o início, a Pomelo conta com essas soluções como parte do conjunto de ferramentas gerenciadas pela equipe de DevSecOps, e por isso não foi necessário fazer nenhuma alteração.
- Formalizar políticas de criptografia: Embora a versão anterior mencionasse vários controles relacionados ao uso de criptografia robusta, a nova versão do padrão exige, no ponto 12, a necessidade de documentá-los detalhadamente, explicando seu escopo, versão e modalidade. A equipe de GRC tinha a tarefa de documentar e consolidar em um único documento todas as ferramentas usadas na Pomelo que contribuem para o uso de soluções de criptografia – incluindo módulos de segurança de hardware (HSM) e repositórios seguros.
- Conscientização e gerenciamento de incidentes: Além da criptografia, o requisito 12 também acrescenta novas especificações sobre o treinamento e a orientação da equipe envolvida no gerenciamento operacional do CDE, em áreas como Gerenciamento de Incidentes e Tratamento de Incidentes. A equipe de GRC usou as funcionalidades da ferramenta de e-learning e a documentação de apoio para comprovar a conformidade exigida.
- Análise de risco focalizada: Por fim, o 12º requisito reformula as condições necessárias para a realização da Análise de Risco, com foco nos riscos inerentes à operação do negócio e que, consequentemente, afetam a EDC. A metodologia implementada pela equipe do GRC para realizar essa pesquisa foi modificada e ajustada para abranger o que foi definido nessa nova versão.
- Monitoramento e controle: Complementando a análise inicial de GAP, a equipe do GRC desenvolveu um painel extenso e detalhado que reflete o status de conformidade dos 423 pontos da versão 4.0, a fim de monitorar o progresso, as evidências e até mesmo os desvios, fechando o ciclo de controle até a próxima instância de certificação.
Esta foi só uma amostra parcial de alguns pontos de interesse do padrão 4.0 e como os resolvemos com a Pomelo. Para ver os detalhes completos das alterações introduzidas por esta versão, consulte a lista detalhada no link oficial do PCI Council!