Autenticação multifator para cumprir com o PCI DSS 3.2

Dirk Denayer, 8 de Novembro de 2017

Em 1 de fevereiro de 2018, o Requisito 8.3 do Padrão de Segurança de Dados do Setor de Cartões de Pagamento ( PCI DSS 3.2 ) entra em vigor, tornando obrigatória a autenticação multifatorial para acesso sem console a computadores e sistemas que manipulam dados do titular do cartão e acesso remoto ao CDE (ambiente de dados do titular do cartão). No início deste ano, o PCI Security Standards Council também emitiu orientações para implementações de autenticação multifatorial.

PCI DSS 3.2

O PCI DSS se aplica a todas as entidades envolvidas no processamento de cartões de pagamento, incluindo comerciantes, processadores, adquirentes, emissores e provedores de serviços. Também se aplica a todas as outras entidades que armazenam, processam ou transmitem dados do titular do cartão ou dados confidenciais de autenticação.

Desde o lançamento do PCI DSS, foram realizadas duas versões principais, a versão 2.0 em novembro de 2010 e a 3.0 em outubro de 2013. O sub-release mais recente, versão 3.2, foi publicado em abril de 2016 e apresenta alguns novos requisitos que são considerados práticas recomendadas até 31 de janeiro de 2018, após os quais se tornam requisitos obrigatórios. Essas mudanças garantem que os padrões estejam atualizados com ameaças e mudanças emergentes no mercado. A mudança mais significativa é o requisito 8.3 revisado referente à autenticação multifatorial.

Algumas dessas mudanças ocorrem em resposta a grandes incidentes de hackers nos EUA, incluindo as violações de dados da Target e da Home Depot, onde os hackers obtiveram nomes, números de cartão de crédito e outras informações sobre milhões de pessoas. A Violação de meta em 2013 sozinha comprometeu 40 milhões de informações de cartão de pagamento dos clientes e expôs parcialmente outros 70 milhões. Após uma longa investigação, a Target pagará US $ 18,5 milhões em uma garantia violação de acordo . O varejista gastou US $ 202 milhões em honorários legais e outros custos desde a violação.

Requisito 8.3 e autenticação multifatorial

A primeira alteração no requisito 8.3 é a introdução do termo "autenticação multifatorial" em vez do termo anterior "autenticação de dois fatores", pois dois ou mais fatores podem ser usados. Ao alterar essa terminologia, dois fatores de autenticação se tornam o requisito mínimo.

A segunda e principal mudança é expandir o Requisito 8.3 em dois sub-requisitos, para exigir autenticação multifatorial para todo o pessoal com acesso administrativo que não seja do console e todo o pessoal com acesso remoto ao CDE.

O novo requisito 8.3.1 trata da autenticação multifator para todas as pessoas com acesso administrativo não console ao CDE, onde "acesso não console" refere-se ao acesso lógico que ocorre através de uma rede e não através de uma conexão física direta, incluindo o acesso a dentro de redes internas, bem como acesso de redes externas ou remotas.

O novo requisito 8.3.2 incorpora o antigo requisito 8.3 e aborda a autenticação multifator para todo o pessoal com acesso remoto ao CDE. Esse requisito destina-se a ser aplicado a todo o pessoal - incluindo usuários gerais, administradores e fornecedores (suporte e manutenção) com acesso remoto à rede - onde esse acesso remoto pode levar ao acesso ao CDE.

Diretrizes para autenticação multifatorial

Desde a mudança para o requisito 8.3, o PCI Security Standards Council recebeu várias perguntas sobre como os diferentes fatores devem ser implementados, tanto das organizações que planejam implementar o MFA quanto dos avaliadores de segurança que avaliam as implementações do MFA.

Para responder a essas perguntas, o Conselho publicou Suplemento de informações - Autenticação multifatorial versão 1.0 descrever os princípios e melhores práticas aceitos pelo setor para uma implementação de MFA, incluindo:

  • Definição, independência e proteção dos fatores de autenticação
  • Uso indevido de vários fatores, incluindo autenticação em várias etapas

Na última seção, o Conselho explora cenários comuns de autenticação e considerações para autenticação multifatorial.

Fatores de autenticação

A autenticação multifatorial exige o uso de pelo menos dois dos três fatores de autenticação, conforme descrito no Requisito 8.2 do PCI DSS:

  • Algo que você sabe, como senha, PIN ou resposta a perguntas secretas
  • Algo que você possui, como um dispositivo de token ou cartão inteligente
  • Algo que você é, como um biométrico

O setor já está totalmente ciente dessa definição, mas ainda luta para implementar esses diferentes fatores de autenticação.

O PCI SSC também menciona outros fatores: “Outros tipos de informações, como geolocalização e tempo, podem ser incluídos adicionalmente no processo de autenticação; no entanto, pelo menos dois dos três fatores identificados acima devem sempre ser usados. Por exemplo, dados de geolocalização e tempo podem ser usados para restringir o acesso remoto à rede de uma entidade de acordo com o horário de trabalho de um indivíduo. Embora o uso desses critérios adicionais possa reduzir ainda mais o risco de invasão de conta ou atividade maliciosa, o método de acesso remoto ainda deve exigir autenticação por pelo menos dois dos seguintes fatores: algo que você sabe, algo que você tem e algo que você é. ”

Independência dos fatores de autenticação

O MFA deve ser implementado com mecanismos de autenticação independentes um do outro, para evitar que o acesso a um fator conceda acesso a qualquer outro fator e o comprometimento de um fator não afete a integridade ou a confidencialidade de qualquer outro fator.

Algumas das armadilhas descritas pelo PCI SSC:

  • Primeiro, quando uma combinação de nome de usuário / senha é usada para entrar na rede da empresa, e as mesmas credenciais também dão acesso a uma conta de e-mail para a qual uma senha de uso único é enviada como segundo fator, esses fatores não são independentes. O primeiro fator (nome de usuário/senha) fornece acesso à conta de e-mail e, portanto, o segundo fator.
  • Segundo, "um certificado de software armazenado em um laptop (algo que você possui) protegido pelo mesmo conjunto de credenciais usado para efetuar login no laptop (algo que você conhece) pode não fornecer independência".
  • Terceiro, “a transmissão de uma senha de uso único (OTP) para um smartphone é tradicionalmente considerada um método fora da banda eficaz. No entanto, se o mesmo telefone for usado para enviar o OTP - por exemplo, por meio de um navegador da web - a eficácia do OTP como um fator secundário será efetivamente anulada. ”Ao inserir credenciais pelo mesmo dispositivo que recebe (ou armazena / gera ) como um segundo fator, um hacker que tem controle do dispositivo pode capturar os dois fatores de autenticação.

Proteção de fatores de autenticação

Para evitar qualquer uso indevido dos fatores de autenticação, eles precisam ser protegidos contra acesso e uso não autorizado, conforme definido no Requisito 8 do PCI DSS. Além disso, “onde qualquer elemento de autenticação se baseie em um dispositivo de consumo multifuncional - por exemplo, telefones celulares e tablets - também devem existir controles para reduzir o risco de comprometimento do dispositivo”.

Multipasso vs. multifator

O PCI DSS exige que todos os fatores na autenticação multifatorial sejam verificados juntos, antes de obter acesso ao sistema. Se um usuário puder obter o conhecimento do sucesso ou falha antes que todos os fatores tenham sido enviados, o processo geral de autenticação se tornará uma autenticação de várias etapas e fator único, mesmo que um fator diferente seja usado para cada etapa. Isso não é compatível com o requisito de autenticação multifator.

Cenários de autenticação comuns

Na última seção deste suplemento de informações, o PCI SSC descreve quatro cenários de autenticação multifatorial que esclarecem as diferentes condições dos fatores de autenticação e a melhor forma de implementá-los.

Conclusão

Menos de três meses antes de o Requisito 8.3 do PCI DSS entrar em vigor, é hora de agir. Estou convencido de que Suplemento de informações - Autenticação multifatorial versão 1.0 é um bom ponto de partida enquanto você se prepara para revisar, implementar ou atualizar suas soluções de autenticação multifator.

Dirk Denayer é gerente de soluções de negócios da OneSpan. Ele ingressou na OneSpan em 2016, com 20 anos de experiência em soluções de software de negócios no nível de vendas, marketing e entrega. Antes de ingressar na OneSpan, ele trabalhou na Exact Software, CODA e Unit4.