Segurança da Informação

PCI DSS – Saiba o que há de novo no v3.0?

Este artigo incidirá sobre algumas das mudanças e seu impacto sobre o padrão.
O artigo está divido da seguinte forma:

Siglas Significado
E : Esclarecimentos
EN : Exigência Nova

Então, o que há de novo?

A primeira mudança notável foi para remover as colunas de “In Place“, “Not in Place” e “Alvo Data / Comentários” na tabela de exigências.
Este foi substituído por uma coluna “Guidance“, que tem como objetivo ajudar o leitor a compreender melhor a exigência.
Tive o prazer de ver essa mudança, porque não adicionar alguns esclarecimentos necessários para muitos dos requisitos.

Requisito 1

1.1.2/1.1.3 (E): Esclarecido que o diagrama de rede deve incluir e acrescentou nova exigência em 1.1.3 para obter um diagrama atual, que mostra os fluxos de dados do titular do cartão.
Ao definir o ambiente de dados do titular do cartão (CDE) é importante documento que os sistemas estão no escopo e como eles se interconectam.
Um diagrama de rede é uma ótima maneira de fazer isso.
Ao criar diagramas de rede para um empregador anterior, eu freqüentemente andar sala do servidor e traçar fisicamente as conexões de rede, além de utilizar ferramentas de software.
Enquanto isto pode não ser viável em todos os ambientes, posso dizer-lhe que este método se descobrir algumas surpresas ao longo do tempo.
A adição do requisito 1.1.3 é importante porque obriga você a olhar para a forma como os dados se movem ao redor do CDE.
Ao passar por este exercício, você pode descobrir que alguns dados estão sendo copiados para um sistema que, enquanto você pode estar ciente de sua existência, você não sabia que os dados do portador contido.

Requisito 2

2.1 (E): Esclarecido que a exigência de alteração de senhas padrão do fornecedor aplica-se a todas as senhas padrão, incluindo sistemas, aplicativos, software de segurança, terminais, etc e que contas padrão desnecessárias são removidas ou desativadas.

Requisito 3

3.5.2/3.5.3 (E): exigência de Split 3.5.2 em dois requisitos para se concentrar em separado sobre o armazenamento de chaves criptográficas de forma segura (3.5.2), e com o menor número possível de locais (3.5.3). Requisito 3.5.2 também fornece flexibilidade com mais opções para o armazenamento seguro de chaves criptográficas.
Esses dois requisitos foram adicionados alguns orientação necessária sobre o manuseio da chave.
Requisito 3.5.2 ainda fornece alguns exemplos:
• Criptografados com uma chave chave de criptografia que é pelo menos tão forte quanto a chave de criptografia de dados, e que é armazenada separadamente a partir da chave de criptografia de dados
• Dentro de um dispositivo criptográfico seguro (como um módulo de segurança do host (HSM) ou PTS aprovado dispositivo de ponto de interação)
• Como pelo menos dois componentes-chave de corpo inteiro ou partes da chave, de acordo com um método aceito pela indústria
Quando o acima não são necessários, é uma boa prática usar o método de armazenamento de chave mais forte à sua disposição sempre que possível.

Exigência 5

5.1.2 (EN): Nova exigência para avaliar evolução ameaças de malware para quaisquer sistemas não consideradas como sendo geralmente afetada por software malicioso.
5.3 (EN): Nova exigência para garantir que as soluções anti-vírus estão ativamente execução (anteriormente em 5.2), e não pode ser desativado ou alterados pelos usuários, a menos que especificamente autorizado pela Administração com base em cada caso.
Sistemas de avaliação contínua para a vulnerabilidade e a exploração é uma boa prática de segurança.
Eu não estou sugerindo que todos se tornarem um pesquisador vulnerabilidade, mas todo praticante de segurança deve ser bem educado em ameaças de hoje.
Há uma abundância de recursos que estão na vanguarda da descoberta vulnerabilidade. Aqui são três:
1. US-CERT
2. MS-ISAC
3. DFIR
Quanto ao requisito 5.3, que não precisa ser contada.
Se adequadamente implementado e gerenciado, ele pode salvar seus ativos .

Exigência 6

6.5x (EN): vulnerabilidades de codificação comuns nos processos de desenvolvimento de software da seguinte forma:
• Alterado “pré – produção para desenvovimento/teste”
• Desenvolver aplicações baseadas em diretrizes de codificação seguras.
Certifique-se de seus programadores estão mantendo seu conhecimento up-to-date e utilizando as melhores práticas da indústria. Existem alguns grandes recursos disponíveis para eles também.

Exigência 8

8.2.3 (EN): complexidade e requisitos de força de senha mínimos combinados em requisito único e maior flexibilidade de alternativas que atendam à complexidade e resistência equivalente.
8.5.1 (EN):. Novo requisito para prestadores de serviços com acesso remoto às instalações dos clientes, para usar credenciais de autenticação exclusivos para cada cliente efetiva 01 de julho de 2015 *
8.6 (EN): Nova exigência onde outros mecanismos de autenticação são usados (por exemplo, os tokens físicos ou lógicos de segurança, cartões inteligentes, certificados, etc) que os mecanismos devem estar ligados a uma conta individual e assegurar somente o usuário pretendido pode ter acesso com esse mecanismo.
Já dissemos isso antes e vou dizer outra vez usar fortes, únicas e senhas de dois fatores de autenticação , sempre e onde quer que possível.

Requisito 9

9.3 (EN): Nova exigência de controlar o acesso físico a áreas sensíveis para o pessoal no local, incluindo um processo para autorizar o acesso, e revogar o acesso imediatamente após a rescisão.
9.9.x (EN): Novas exigências para proteger os dispositivos que os dados do cartão de pagamento de captura através de interação física direta com o cartão de adulteração.
“Estes são bons requisitos de fato e medidas semelhantes têm reduzido a quantidade de fraude ATM, mas ainda há o elemento humano para dar conta.”

Exigência 11

11.3.4 (EN): Nova exigência, se a segmentação é usado para isolar o CDE a partir de outras redes, para realizar testes de penetração para verificar se os métodos de segmentação são operacionais e eficazes.
Esta é uma adição importante e que eu acredito que deve sustentar a totalidade do documento.
Os controles são postas em prática para garantir violações não ocorrem.
Somente um teste irá validar se esses controles são implementados corretamente e agir conforme o esperado.

Espero que gostem até o próximo post!

Patricia Horta Correia Gonzalez

Profissional com 11 anos em Segurança da Informação e a frente de grandes organizações, englobando forte experiência em projetos para grandes empresas globais: Revisão de Política de Segurança Corporativa Global, Planejamento Estratégico de TI, Contrato de SLA, Auditoria de Sistemas e Infraestrutura de TI, Implementação Seguindo Padrões PMI. Formada em Sistemas de Informação e Pós Graduada em Segurança da Informação.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.