Indústria de pagamentos por cartão dá adeus ao SSL 

Se sua organização pertence a Indústria de Pagamentos por cartão – Payment Card Industry e ainda está usando o protocolo SSL / Early TLS, leia este artigo

Em nota divulgada em 17 de maio de 2018 o PCI Security Standards Council (PCI SSC) publicou pequena revisão do PCI DSS (PCI Data Security Standard), para empresas em todo o mundo salvaguardarem seus os dados do cartão de pagamento antes, durante e após a compra PCI DSS v3.2.1, substitui a versão 3.2 para considerar as datas efetivas de substituição do Secure Socket Layer (SSL).

“Esta atualização foi projetada para eliminar qualquer confusão em torno das datas efetivas para os requisitos do PCI DSS introduzido na v3.2, bem como as datas de migração  do protocolo SSL  para o TLS ”, disse o Chefe de Tecnologia do PCI SSCOficial Troy Leach.

“É extremamente importante que as organizações desativem SSL / TLS inicial e atualizem para um alternativa segura para salvaguardar os seus dados de pagamento. ”

As pequenas alterações no PCI DSS v3.2.1 refletem como os requisitos existentes são afetados uma vez que o datas e prazos de migração SSL / TLS passaram para que as organizações possam relatar com precisão como suas implementações atendem a esses requisitos existentes após 30 de junho 2018. Especificamente, as mudanças incluem:

Atualizações dos requisitos aplicáveis ​​são aplicáveis apenas aos POS (ponto de venda ponto de interação), os terminais e os pontos de ligação dos fornecedores de serviços podem continuar a utilizar o SSL e Early TLS como um controle de segurança após 30 de junho de 2018.

O que acontece em 30 de junho de 2018?

30 de junho de 2018 é o prazo para desabilitar SSL e implementar um protocolo de criptografia mais seguro e o TLS v1.2 é altamente recomendável para atender ao PCI DSS (PCI Data Security Standard) para proteger os dados de pagamento.

O que é SSL/Early TLS?

O Transport Layer Security – TLS é um protocolo criptográfico usado para estabelecer um canal de comunicação seguro entre dois sistemas. Ele é usado para autenticar um ou ambos os sistemas e proteger a confidencialidade e a integridade das informações que passam entre os sistemas.

Foi originalmente desenvolvido como Secure Sockets Layer (SSL) pela Netscape no início dos anos 90. Padronizado pela IETF (Internet Engineering Taskforce).

O TLS passou por várias revisões para melhorar a segurança para bloquear ataques conhecidos e adicionar suporte a novos algoritmos criptográficos, com grandes revisões do SSL 3.0 em 1996, TLS 1.0 em 1990, TLS 1.1 em 2006 e TLS 1.2 em 2008.

Qual é o risco de usar SSL / Early TLS?

Há muitas vulnerabilidades sérias no SSL e no Early TLS que deixaram as organizações não colocadas em risco de serem violadas. As explorações difundidas POODLE e BEAST são apenas alguns exemplos de como os invasores aproveitaram os pontos fracos do SSL e do Early TLS para comprometer as organizações.

De acordo com o NIST, não há correções ou patches que consigam reparar adequadamente o SSL ou o TLS inicial. Portanto, é extremamente importante que as organizações atualizem para uma alternativa segura o mais rápido possível e desativem qualquer fallback para SSL e TLS inicial.

Quem é mais suscetível as vulnerabilidades dos certificados SSL / Early TLS?

Ambientes on-line e de comércio eletrônico usando SSL e TLS inicial são mais suscetíveis às explorações de SSL, mas a data de migração do PCI DSS de 30 de junho de 2018 se aplica a todos os ambientes – exceto para terminais de pagamento (POIs) (e os pontos de terminação SSL / TLS aos quais eles se conectam) que podem ser verificados como não sendo suscetíveis a quaisquer explorações conhecidas para SSL e Early TLS.

Há alguma consideração para os terminais de pagamento (POIs)?

Como os POIs podem não ser tão suscetíveis às mesmas vulnerabilidades conhecidas quanto os sistemas baseados em navegador, após 30 de junho de 2018, os dispositivos POI (e os pontos de término aos quais eles se conectam) podem ser verificados como não sendo suscetíveis a qualquer exploração conhecida.

Se SSL / Early TLS for usado, os PIs e seus pontos de terminação devem ter correções atualizadas e garantir que apenas as extensões necessárias estejam ativadas. Além disso, o uso de conjuntos de codificação fracos ou algoritmos não aprovados – por exemplo, RC4, MD5 e outros – não são permitidos.

O que as organizações devem fazer se a varredura ASV sinalizar a presença de SSL e a varredura falhar?

Entre hoje e 30 de junho de 2018, as organizações que não concluíram a migração devem entregar ao Fornecedor de Varredura Aprovado (ASV) a confirmação documentada de que implementaram um Plano de Mitigação e Migração de Riscos e estão trabalhando para concluir sua migração até a data exigida. O recebimento dessa confirmação deve ser documentado pelo ASV como uma exceção em “Exceções, falsos positivos ou controles de compensação” no Resumo executivo do relatório de varredura do ASV. Migrando do SSL / Early TLS  

O que as organizações podem e devem fazer agora para se protegerem contra vulnerabilidades SSL e TLS iniciantes?

Leva tempo para migrar para protocolos mais seguros e as organizações não devem atrasar:

— Migre para um mínimo de TLS 1.1, preferencialmente TLS 1.2. Embora seja possível implementar contramedidas contra alguns ataques ao TLS, a migração para uma versão posterior do TLS (o TLS 1.2 é altamente recomendável) é o único método confiável para proteção contra as vulnerabilidades atuais do protocolo.

— Patch TLS software contra vulnerabilidades de implementação. Vulnerabilidades de implementação, como o Heartbleed no OpenSSL, podem representar sérios riscos. Mantenha o software TLS atualizado para garantir que ele seja corrigido contra essas vulnerabilidades e tenha contramedidas para outros ataques.

— Configure o TLS de forma segura. Além de fornecer suporte para versões posteriores do TLS, certifique-se de que a implementação do TLS esteja configurada com segurança. Assegure-se de que os conjuntos de criptografia TLS seguros e os tamanhos de chave sejam suportados e desative o suporte para outros conjuntos de criptografia que não são necessários para interoperabilidade. Por exemplo, desabilite o suporte para criptografia fraca “Export-Grade”, que foi a origem da recente vulnerabilidade Logjam.

— Use os recursos do PCI SSC. Visite o site do PCI SSC para obter recursos que podem ajudar com a migração SSL / perguntas frequentes .

Fonte: Com informações de artigos escritos por Laura K. Gray

Diretora de comunicações da PCI Security Standards Council

O PCI Security Standards Council é um fórum global para o setor desenvolver, aprimorar, disseminar e auxiliar no entendimento dos padrões para  a segurança da indústria de Pagamentos por Cartão.