Quando foi lançada a versão 3.1 do Padrão de Segurança PCI, o padrão SSL foi descartado. Mas na versão do PCI DSS 3.2, divulgada em abril de 2016, o pessoal do PCI voltou um pouco atrás. Em vez disso, implementações existentes têm prazo até junho de 2018 para remover o SSL e antigos TLS (1.0).
Com isso, os retardatários que ainda utilizam o padrão SSL têm mais tempo para entrar em conformidade. Até que se torne regra, em dois anos, essas empresas devem desenvolver planos de mitigação de riscos e de migração.
Quais são as outras novidades?
Há um novo requisito muito importante na documentação do DDS 3.2.
Autenticação multifator para acesso administrativo
Anteriormente, havia o requisito de duplo fator de autenticação, mas apenas para acessos remotos. A versão 3.2 do PCI DSS agora obriga as empresas a levar a autenticação de contas privilegiadas mais a sério.
Nas seções 8.3.1 e 8.3.2, existe o requisito de autenticação de múltiplos fatores – dois ou mais – para todos os acessos administrativos non-console e todos os acessos remotos, independentemente quem o faça, administrador ou não.
O requisito 8.3.1 sobre o acesso administrativo non-console é um grande acordo.
Entendemos que o Conselho do PCI está lendo as manchetes e sabe que os hackers cercam os perímetros por meio de ataques de phishing, estabelecem um escudo remoto e buscam as credenciais com privilégios. Em outras palavras, é fácil para os criminosos cibernéticos se passarem por administradores internos usando um escudo.
Com outro fator de autenticação, os administradores terão que provar, por exemplo, que têm a parte privada de um par de chaves ou o acesso a um gerador de identidade em seus smartphones. Os fatores usados atualmente não são explicitamente mencionados.
Obviamente, isso é algo que os atacantes não podem simular. Pelo menos não com muita facilidade.
As empresas têm até janeiro de 2018 para implementarem o requisito 8.3.1. Nesse meio tempo, funciona como “melhor prática”.
Para saber mais, leia o nosso white paper