0
0
Em pouco menos de um ano, as organizações terão que cumprir vários novos requisitos sob a versão 4.0 do Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS).
Sobre o PCI DSS
O PCI DSS compreende 12 requisitos para proteger os dados do cartão de pagamento e mudou muito pouco nos últimos dez anos. Mas, após três anos de consultas, passou agora por uma revisão substancial.
A versão mais recente – 4.0 – foi lançada em março de 2022 e atualmente coexiste com a versão 3.2.1. Ele apresenta 63 alterações, 13 das quais se tornam obrigatórias em abril de 2024, quando a v3.2.1 é aposentada, com as organizações obrigadas a cumprir totalmente todas as alterações até março de 2025.
A V4.0 coloca muito mais ênfase na implementação de processos que são mantidos como parte da cultura de negócios como de costume, em vez de com o objetivo de passar por uma avaliação anual, de acordo com o Relatório de Segurança de Pagamento da Verizon 2022. Mas o que significam os novos requisitos na prática e como as empresas podem começar a fazer a transição?
Adaptação às novas tecnologias
O PCI DSS 4.0 apresenta quatro mudanças principais:
A terminologia foi atualizada em relação aos controles de segurança de rede para suportar uma gama mais ampla de tecnologias que podem ser usadas para atender aos objetivos de segurança tradicionalmente atendidos pelos firewalls.
Isso reflete um afastamento das redes tradicionais baseadas em servidor e parametrizadas em direção a arquiteturas distribuídas, como tecnologias em nuvem e sem servidor, bem como arquitetura de rede de confiança zero (ZTNA) e vê o padrão procurar acomodar os mecanismos de controle específicos desses novos ambientes, suportando pagamentos via móvel e IoT, por exemplo. Dito isto, o padrão sempre se esforçou muito para permanecer neutro em tecnologia, então o objetivo aqui é ser abrangente enquanto se move com os tempos.
O requisito 8 foi expandido para incluir a implementação da autenticação multifator (MFA) para todos os acessos ao ambiente de dados do titular do cartão (CDE)
Isso essencialmente impede que os componentes do sistema sejam acessados sem um fator adicional de autenticação, pois todas as contas devem ter a MFA habilitada, não apenas aquelas usadas para administração. O mesmo requisito também agora se alinha com a orientação de senha descrita nas Diretrizes de Identidade Digital do NIST. As senhas devem observar um comprimento mínimo de 12 caracteres, observar um nível mínimo de complexidade e ser alteradas anualmente ou em caso de suspeita de comprometimento. Além disso, as organizações devem documentar e revisar conjuntos de criptografia e protocolos que estão usando no ambiente de dados do titular do cartão.
Essas etapas de autenticação e acesso apontam para o padrão que se move em direção ao conceito de confiança zero, em que as redes operam com o princípio de “nunca confiar, sempre verificar”. Em uma ZTNA, toda solicitação de acesso é considerada potencialmente hostil e, portanto, precisa ser autenticada, autorizada e continuamente validada, o que significa que mecanismos de proteção, como o MFA, se tornarão padrão.
There’s increased flexibility for organizations to demonstrate how they are using different methods to achieve the security objectives
Organizations can now use either the “defined” or “customized” approach or a mix of the two to suit their environments. They can even split requirement clauses, so that part of the requirement is met with the defined approach and others with the customized approach, provided the requirement is met.
Embora nem todos os requisitos possam ser atendidos usando a abordagem personalizada, isso promete fornecer às organizações muito mais flexibilidade e autonomia. É provável que se revele particularmente útil para aqueles que anteriormente tinham de utilizar controlos compensatórios e justificá-los. A personalização substituiu efetivamente esses controles de compensação, o que é um passo positivo, pois eles tendem a ser considerados como uma correção de curto prazo. Aqueles que optarem pela abordagem personalizada precisarão de um avaliador de segurança qualificado (QSA) para aprovar a sustentabilidade de seus controles.
As organizações sempre usaram predominantemente a abordagem definida e é provável que isso continue, porque poucos podem dedicar tempo e recursos para elaborar controles sob medida. Mas enquanto anteriormente a abordagem definida se concentrava na organização provando que seus sistemas de controle eram eficazes e sustentáveis, independentemente do resultado do controle, isso agora foi revertido.
Antes, se eles tivessem tomado as medidas necessárias, a organização seria considerada como tendo cumprido o requisito, mesmo que o resultado fosse insatisfatório. Tudo isso mudou na v4.0, pois agora é possível usar abordagens de segurança que podem diferir daquelas especificadas no padrão, desde que a organização possa provar que a implementação atende à intenção e aborda o risco associado ao requisito. Desta forma, o processo torna-se muito mais orientado para o resultado.
A adição de análises de risco direcionadas permite às entidades a flexibilidade de definir com que frequência realizam determinadas atividades, conforme melhor adequado às suas necessidades de negócios e exposição ao risco.
Por exemplo, não há mais a necessidade de alterar senhas ou frases a cada 90 dias se a empresa puder analisar dinamicamente a postura de segurança das contas e as organizações agora puderem criar seus próprios mecanismos de autenticação, desde que atendam aos requisitos.
Também houve algum cruzamento quando se trata dos requisitos que se aplicam aos provedores de serviços versus aqueles que se aplicam aos comerciantes.
Os provedores de serviços agora também devem observar controles específicos para criptografia, gerenciamento de senhas, penetração externa para provedores multilocatários e são obrigados a usar sistemas de detecção/prevenção de intrusão (IDS/IPS). Eles devem reavaliar esses sistemas a cada seis meses, realizar revisões após mudanças organizacionais significativas e atender às solicitações de informações dos clientes para atender ao requisito de manter um programa para monitorar a conformidade do provedor de serviços.
Por outro lado, uma estipulação anteriormente aplicável apenas aos prestadores de serviços foi agora estendida para incluir os comerciantes, que é a necessidade de responder prontamente a falhas de quaisquer controles de segurança críticos. E todas as organizações devem ter procedimentos de resposta a incidentes para lidar com a detecção de vazamento de PAN.
Como fazer a transição
Com tantas mudanças a serem consideradas, é imperativo que as organizações comecem a abordar a conformidade agora, realizando uma avaliação de lacunas para determinar onde elas não estão em conformidade. Isso pode ser usado para ajudar a decidir se é do interesse da organização buscar uma abordagem definida, personalizada ou híbrida.
Isso, é claro, dependerá em grande parte do tempo e dos recursos que o negócio tem, mas também de sua complexidade, pois haverá mais avaliações ao seguir a rota personalizada para mostrar que os resultados foram atendidos e os controles são sustentáveis.
O Payment Card Industry Security Standards Council (PCI SSC) produziu orientações atualizadas para a Abordagem Priorizada, o que pode ajudar aqui. Originalmente projetado para abordar as principais áreas de risco, ele identifica efetivamente quais requisitos devem ser abordados primeiro usando seis marcos.
Com relação aos novos requisitos, as organizações devem procurar priorizar as mudanças com base em quanto tempo eles acham que levará para alcançar a conformidade. Portanto, faz sentido olhar para a criptografia (3.3.2 e 3.3.3), a proteção do pessoal contra ataques de phishing (5.4.1), o gerenciamento de scripts de pagamento nos navegadores do cliente (6.4.3) e o comprimento da senha (8.3.6) e as taxas de atualização de 90 dias (8.3.10.1).
O requisito 11 também contém vários elementos novos, como a verificação de vulnerabilidades internas com autenticação (11.3.1.2), o suporte a testes de penetração externos de provedores de serviços multilocatários (11.4.7) e as técnicas IDS/IPS (11.5.1.1). Além disso, foram incluídos mecanismos para detectar alterações em cabeçalhos HTTP e páginas de pagamento voltados para o cliente (11.6.1) e, da mesma forma, o requisito 12 requer uma avaliação de risco direcionada (12.3) e documentar e confirmar o escopo do PCI DSS pelo menos anualmente ou em qualquer alteração significativa (12.5.2).
O relatório da Verizon (citado acima) também revela as 20 maiores lacunas de controle experimentadas pelas organizações em 2020 e isso também deve ajudar a orientar o esforço e os recursos.
As quatro maiores lacunas foram todas em relação ao Requisito 11 no que diz respeito ao exame e implementação de mudanças de testes de penetração, execução de varreduras internas e externas trimestralmente, revisão e tratamento de varreduras de vulnerabilidades internas e inspeção de configurações de firewall e roteador. Portanto, essas áreas também podem justificar a priorização.
Fazendo PCI DSS BAU
Todas as mudanças provavelmente serão exigentes e exigirão gerenciamento de projetos significativo, por isso faz sentido planejá-las agora mês a mês para cumprir o prazo. A implementação de controles de segurança em conformidade hoje permitirá que a organização passe por um ciclo de avaliação, praticando efetivamente a conformidade para a coisa real, enviando projetos de controle para avaliadores de segurança interna (ISAs) e QSAs com o objetivo de obter um relatório sobre conformidade (ROC) e, se aprovado, um atestado de conformidade (AOC).
É importante ressaltar que o PCI DSS v4.0 enfatiza ainda mais que a conformidade é um processo contínuo e que requer monitoramento e avaliação contínuos. Ele procura fazer com que esses processos se tornem não orientados para a conformidade, mas para o business as usual e incorporados nos processos do dia-a-dia da organização.
Como mostra o relatório da Verizon, as empresas ainda não estão fazendo esse gerenciamento diário, então precisarão abordar a v4.0 culturalmente e do ponto de vista tecnológico. Talvez isso marque o maior desvio do padrão original de todos: a necessidade de adotar uma nova mentalidade que se concentre na segurança de dados, em vez de ser simplesmente orientada para a conformidade.
FONTE: HELPNET SECURITY