segurança vs. conformidade com o requisito PCI DSS 8

algumas semanas atrás, eu estava conversando com um dos meus colegas de trabalho sobre toda a conversa de segurança vs. conformidade. Até então, mantive a premissa de que a conformidade faz pouco por segurança. Em resposta à minha declaração, ele fez a pergunta retórica: “onde essas empresas, do ponto de vista da segurança, estariam sem conformidade?”

Sim, a conformidade é o mínimo que você precisa fazer para se defender contra o ataque; no entanto, se você vai reclamar de ter que fazer conformidade, não há nada que o impeça de se concentrar em controles de TI mais fortes.

nesta postagem do blog, quero tirar um momento e discutir algumas das nuances perdidas do requisito 8 do PCI DSS, que é essencialmente focado no gerenciamento de senhas; mas, muitas vezes argumentado, não é seguro o suficiente. Muitas vezes há algumas informações negligenciadas fornecidas lá que eu gostaria de esclarecer. E, ao ficar com o tema, se esses controles não forem fortes o suficiente, fique à vontade para aumentar o nível de controle.

os pontos mais finos do requisito PCI DSS 8

quando examinamos o preâmbulo da Seção 8 do PCI DSS, ele define a aplicabilidade desse requisito. O que é interessante é que esses requisitos de senha não se aplicam a todos os usuários, embora muitos presumam que sim.

aqui está o texto contido na seção nota do preâmbulo:

Nota: Esses requisitos são aplicáveis a todas as contas, incluindo contas de ponto de venda, com recursos administrativos e todas as contas usadas para visualizar ou acessar dados do titular do cartão ou para acessar sistemas com dados do titular do cartão. Isso inclui contas usadas por fornecedores e outros terceiros (por exemplo, para suporte ou manutenção). Estes requisitos não se aplicam às contas utilizadas pelos consumidores (por exemplo, titulares de cartões). No entanto, os requisitos 8.1.1, 8.2, 8.5, 8.2.3 a 8.2.5 e 8.1.6 a 8.1.8 não se destinam a se aplicar a contas de usuário dentro de um aplicativo de pagamento de ponto de venda que só tem acesso a um número de cartão de cada vez, a fim de facilitar uma única transação (como contas de caixa).

em suma, existem inúmeros requisitos de senha que não se aplicam a indivíduos que lidam com um cartão de cada vez, como um caixa e, curiosamente, mesmo possivelmente, a equipe do call center. Se o membro da equipe só tiver a capacidade de inserir dados do titular do cartão e não puder visualizá-los, do ponto de vista do aplicativo, existem vários controles que não são aplicáveis. Esta é uma área onde você pode ir acima e além para aumentar sua postura de segurança. Onde você puder, certifique-se de que esses controles sejam implementados para todos os indivíduos.

embora não seja um requisito do PCI DSS, recomendo que você reserve um tempo e faça uma avaliação formal de risco. Isso garantirá que não implementar esses controles para esse tipo de conta não cause ônus indevido aos seus dados. Você também pode ir além e estabelecer controles para os tipos de contas de usuário acima mencionados aos quais não se aplica.

definir critérios de senha

em seguida, temos linguagem dentro da seção de orientação do Requisito 8.2.3. Especificamente, 8.2.3 afirma:

8.2.3 senhas / senhas devem atender ao seguinte:

  • requer um comprimento mínimo de pelo menos sete caracteres.
  • contêm caracteres numéricos e alfabéticos

Alternativamente, as senhas/senhas devem ter complexidade e força pelo menos equivalentes aos parâmetros especificados acima.

e a seção de orientação deste requisito afirma:

este requisito especifica que um mínimo de sete caracteres e caracteres numéricos e alfabéticos devem ser usados para senhas/senhas. Para os casos em que esse mínimo não pode ser atendido devido a limitações técnicas, as entidades podem usar “força equivalente” para avaliar sua alternativa. Para obter informações sobre variabilidade e equivalência da força da senha (também conhecida como entropia) para senhas/senhas de diferentes formatos, consulte os padrões da indústria (por exemplo, a versão atual do NIST SP 800-63.)

então, o que tudo isso significa? Deixe-me começar dizendo que uma senha de 7 caracteres pode ser comprometida em nenhum momento se o hash tiver sido capturado. Se você não está ciente de como isso se parece, reserve algum tempo para pesquisar tabelas de arco-íris.

eu pessoalmente recomendo senhas de pelo menos 15 caracteres. A razão pela qual há apenas um requisito de 7 caracteres é que o PCI DSS tem que acomodar ambientes e sistemas legados. 7 caracteres são seguros? Eu vou deixar você tomar essa decisão. Mas onde seus sistemas podem suportar mais, não há nada que o impeça de exigir 32 caracteres.

e se sua senha for composta por 32 “1”? Vamos calcular a entropia de senha do que é necessário. Se sua senha tiver 7 caracteres compostos por valores alfa e numéricos, http://passwordstrengthcalculator.com relata que levaria menos de um segundo para quebrar a senha com um super computador com 36,2 bits de entropia. Considerando que uma senha com 32 1 levaria 15.854.896 anos com o mesmo computador com 106 bits de entropia.

portanto, não se trata apenas da composição da senha. Existem vários valores que podem afetar uma senha; no entanto, não se trata de fazer o mínimo, trata-se de fazer o que é necessário para proteger seus ativos de ataques não autorizados.

embora a conformidade não seja igual à segurança, você não precisa fazer o mínimo. Faça sua avaliação de risco e, se um ativo ainda estiver em risco, mesmo com os requisitos mínimos, estará livre para aumentar sua postura de segurança e exigir mais do que apenas o padrão de Conformidade. Toda empresa que já foi violada estava reclamando de alguma coisa. No entanto, eles não eram seguros. Concentre-se na segurança e a conformidade normalmente acontecerá como um biproduto de segurança.

espero que as dicas que forneci aqui ajudem a defini-lo no caminho para a conformidade com o requisito PCI DSS 8. Clique aqui para ver minhas outras postagens do Guia de conformidade PCI.

Deixe uma resposta

O seu endereço de email não será publicado.