pt.pcisecuritystandards.org · Para os fins deste documento, personalização referese à preparação e inscrição de dados - específicos do emissor ou do titular do cartão na

Setor de cartões de pagamento (PCI) Produção e provisionamento de cartões

Requisitos de segurança lógica Versão 2.0 Janeiro de 2017

Requisitos de segurança lógica de produção e provisionamento de cartões PCI, v2.0 Copyright 2013-2017 PCI Security Standards Council, LLC

Janeiro de 2017 Página i

© 2013-2017 PCI Security Standards Council, LLC

Este documento e seu conteúdo não podem ser usados, copiados, divulgados ou distribuídos para qualquer finalidade, exceto em conformidade com os termos e condições do Acordo de Confidencialidade celebrado entre a PCI Security Standards Council LLC e sua empresa. Leia o Contrato de Confidencialidade antes de ler este documento.


Janeiro de 2017 Página ii

Alterações no documento

Data Versão Autor Descrição

Dezembro de 2012

1.x PCI Versão RFC

Maio de 2013 1.0 PCI Primeira versão

Março de 2015 1.1 PCI Melhorias para esclarecimento

Julho de 2016 2.x PCI Versão RFC

Janeiro de 2017 2.0 PCI Adição do provisionamento móvel e outras alterações. Consulte o Resumo das alterações da v1.1 para v2.

PCI Card Production and Provisioning Logical Security Requirements, v2.0 Copyright 2013-2017 PCI Security Standards Council, LLC

January 2017 Page iii

Índice Alterações no documento ............................................................................................................ ii 1 Escopo ..................................................................................................................................... 1

1.1 Finalidade ............................................................................................................................. 1 1.2 Foco ...................................................................................................................................... 1 1.3 Leis e Regulamentações ...................................................................................................... 2 1.4 Prevenção de Perdas ........................................................................................................... 2 1.5 Limitações ............................................................................................................................. 2

2 Funções e responsabilidades ................................................................................................ 3 2.1 Equipe de segurança da informação .................................................................................... 3 2.2 Atribuição de segurança Deveres ........................................................................................ 3

3 Política e procedimentos de segurança ................................................................................ 4 3.1 Política de segurança da informação ................................................................................... 4 3.2 Procedimentos de Segurança .............................................................................................. 4 3.3 Planos de resposta a incidentes e investigações................................................................. 4

4 Segurança de dados ............................................................................................................... 6 4.1 Classificação......................................................................................................................... 6

4.1.1 Dados Secretos ....................................................................................................... 6 4.1.2 Dados Confidenciais ............................................................................................... 6 4.1.3 Dados irrestritos/públicos ........................................................................................ 6 4.1.4 Proteções ................................................................................................................ 7

4.2 Criptografia ........................................................................................................................... 7 4.3 Dados de acesso ao titular do cartão ................................................................................... 7 4.4 Dados de transmissão do titular do cartão ........................................................................... 8 4.5 Dados de retenção e exclusão do titular do cartão .............................................................. 8 4.6 Manuseio da mídia ............................................................................................................... 9 4.7 Personalização sem contato .............................................................................................. 10 4.8 Dados usados para Teste .................................................................................................. 10 4.9 Registros de atividades de provisionamento móvel ........................................................... 10 4.10 Plano de descomissionamento........................................................................................... 11

5 Segurança de rede ................................................................................................................ 12 5.1 Fornecedor típico Rede ...................................................................................................... 12

5.1.1 Emissor/Fonte de dados ....................................................................................... 12 5.1.2 Rede privada (linhas alugadas), internet, POTS .................................................. 12 5.1.3 Produção e provisionamento de cartões DMZ ..................................................... 12 5.1.4 Preparação de dados Rede .................................................................................. 13 5.1.5 Personalização Rede ............................................................................................ 13 5.1.6 Provisionamento móvel Redes ............................................................................. 14

5.2 Requisitos gerais ................................................................................................................ 14 5.3 Dispositivos de rede ........................................................................................................... 15 5.4 Firewalls .............................................................................................................................. 15

5.4.1 Geral...................................................................................................................... 15 5.4.2 Configuração ......................................................................................................... 16

5.5 Software ou programas antivírus........................................................................................ 17 5.6 Acesso remoto .................................................................................................................... 18

5.6.1 Condição das conexões ........................................................................................ 18 5.6.2 Rede Privada Virtual (Virtual Private Network, VPN) ........................................... 19

5.7 Redes Wireless .................................................................................................................. 20 5.7.1 Geral...................................................................................................................... 20 5.7.2 Gestão ................................................................................................................... 20


Janeiro de 2017 Página iii

5.7.3 Requisitos adicionais para usar o Wi-Fi ................................................................ 21 5.8 Testes de segurança e Monitoramento .............................................................................. 22

5.8.1 Vulnerabilidade ..................................................................................................... 22 5.8.2 Penetração ............................................................................................................ 22 5.8.3 Sistemas de detecção de intrusão ........................................................................ 23

6 Segurança do sistema .......................................................................................................... 24 6.1 Requisitos gerais ................................................................................................................ 24 6.2 Gestão da mudança ........................................................................................................... 24 6.3 Gestão de configurações e patches ................................................................................... 25 6.4 Registros de auditoria ......................................................................................................... 26 6.5 Backup e recuperação de redes de provisionamento móvel ............................................. 27 6.6 Design de software e desenvolvimento .............................................................................. 27

6.6.1 Geral...................................................................................................................... 27 6.6.2 Projeto ................................................................................................................... 27 6.6.3 Desenvolvimento ................................................................................................... 27

6.7 Interfaces de uso de serviços da Web para o emissor ...................................................... 28 6.8 Implementação de software ............................................................................................... 28

7 Gerenciamento de usuário e controle de acesso ao sistema ............................................ 30 7.1 Gerenciamento de usuários ............................................................................................... 30 7.2 Controle de senhas ............................................................................................................ 31

7.2.1 Geral...................................................................................................................... 31 7.2.2 Características e uso ............................................................................................ 31

7.3 Bloqueio de sessões .......................................................................................................... 32 7.4 Bloqueio de contas ............................................................................................................. 32

8 Gerenciamento de chave: Dados Secretos ............................................................................ 33 8.1 Princípios gerais ................................................................................................................. 33 8.2 Chaves simétricas .............................................................................................................. 33 8.3 Chaves assimétricas .......................................................................................................... 34 8.4 Administração de segurança de gerenciamento de chaves .............................................. 34

8.4.1 Requisitos gerais ................................................................................................... 35 8.4.2 Gerente de chave .................................................................................................. 35 8.4.3 Principais custodiantes ......................................................................................... 35 8.4.4 PINs de dispositivo de gerenciamento de chaves ................................................ 36

8.5 Geração de chave .............................................................................................................. 36 8.5.1 Transações de chaves assimétricas usadas para pagamento ............................. 37

8.6 Distribuição da chave ......................................................................................................... 37 8.7 Carregamento da chave ..................................................................................................... 38 8.8 Armazenamento da chave .................................................................................................. 39 8.9 Uso da chave ...................................................................................................................... 39 8.10 Backup/Recuperação da chave ......................................................................................... 41 8.11 Destruição da chave ........................................................................................................... 38 8.12 Trilha de auditoria de gerenciamento de chaves ............................................................... 41 8.13 Comprometimento da chave .............................................................................................. 39 8.14 Hardware de segurança de gerenciamento de chaves ...................................................... 40

9 Gerenciamento de chave: Dados Confidenciais ..................................................................... 41 9.1 Princípios gerais ................................................................................................................. 41

10 Distribuição de PIN via métodos eletrônicos .......................................................................... 42 10.1 Requisitos gerais ................................................................................................................ 42

Anexo A: Aplicação de requisitos ................................................................................................ 43 Apêndice B: Exemplos de topologia ......................................................................................... 46


Janeiro de 2017 Página iii

Anexo Normativo A: Tamanhos e pontos fortes mínimos e de equipamentos para algoritmos aprovados ................................................................................................................ 54 Glossário de acrônimos e termos .............................................................................................. 55


Janeiro de 2017 Página 1

1 Escopo

Todos os sistemas e processos de negócios associados com as atividades de segurança lógicas associadas à produção e ao provisionamento de cartões, tais como preparação de dados, pré-personalização, personalização de cartões, geração de PIN, PIN mailers e transportadores de cartões, devem estar em conformidade com os requisitos deste documento. Dependendo dos serviços prestados pela entidade, algumas seções deste documento podem não ser aplicáveis.

Este documento descreve os requisitos de segurança lógica exigidos das entidades que:

Executam serviços de provisionamento de elemento seguro (SE) ou de nuvem;

Gerenciam personalização over-the-air (OTA), gerenciamento de ciclo de vida e preparação de dados de personalização; ou

Gerenciam chaves criptográficas associadas.

Ele não se aplica a provedores que estão realizando apenas a distribuição de elementos seguros.

Onde quer que os requisitos especifiquem a personalização, os requisitos também se aplicam a redes de provisionamento baseadas na nuvem (por exemplo, aquelas para emulação de cartão host). Os sistemas baseados na nuvem diferem daqueles com base na necessidade de uso de um elemento seguro em um dispositivo móvel.

Dentro desses requisitos, toda a documentação citada deve ser validada pelo menos a cada doze meses.

Anexo A: A aplicabilidade dos requisitos faz um refinamento adicional no nível de exigência para cartões físicos e provisionamento móvel.

Embora este documento frequentemente cite o “fornecedor”, a aplicabilidade específica desses requisitos vai até as marcas de pagamento individuais; e a(s) bandeira(s) de pagamento de interesse deve(m) ser contatada(s) quanto à aplicabilidade desses requisitos para qualquer atividade de produção ou provisionamento de cartão.

1.1 Finalidade

Para os fins deste documento, personalização refere-se à preparação e inscrição de dados específicos do emissor ou do titular do cartão na tarja magnética ou no circuito integrado no cartão. O uso subsequente do termo “personalização de cartão” inclui preparação de dados, codificação de tarja magnética, codificação de chip e provisionamento móvel. Os requisitos de segurança física também devem ser cumpridos. Esses requisitos destinam-se a estabelecer níveis mínimos de segurança que os fornecedores devem cumprir na codificação da tarja magnética e na personalização de chip. Entretanto, os requisitos e procedimentos físicos estão fora do escopo deste documento, embora possam ser encontrados separadamente no Requisitos de segurança física de produção e fornecimento de cartões de pagamento (Payment Card Industry, PCI).

1.2 Foco

O desenvolvimento, fabricação, transporte e personalização de cartões de pagamento e seus componentes têm um forte impacto sobre as estruturas de segurança dos sistemas de pagamento, emissores e fornecedores envolvidos em sua emissão. A segurança de dados é o foco principal deste documento. Portanto, os requisitos para acessar, transportar e armazenar dados utilizados durante a produção e o provisionamento de cartões são definidos mais adiante neste documento.



1.3 Leis e Regulamentações

Além dos requisitos lógicos de segurança contidos neste documento, certamente haverá leis e regulamentos regionais e nacionais relevantes, incluindo leis de proteção ao consumidor, acordos trabalhistas, regulamentos de saúde e segurança, etc. Cada organização é individualmente responsável por garantir de forma independente o cumprimento de todas as leis e regulamentos locais. A adesão aos requisitos deste documento não implica em conformidade com as leis e regulamentações locais.

Se qualquer um dos requisitos contidos neste manual estiver em conflito com as leis nacionais, estaduais ou locais, as leis federais, estaduais e locais serão aplicadas.

1.4 Prevenção de Perdas

A conformidade com os requisitos especificados neste manual não garantirá ou implicará na prevenção de qualquer uma ou todas as perdas de produto inexplicadas. Os fornecedores aprovados são responsáveis por evitar tais perdas. Os fornecedores são responsáveis por qualquer perda, roubo, deterioração ou destruição inexplicada de produtos ou componentes de cartões que possam ocorrer enquanto tais produtos estiverem na instalação do fornecedor. Os fornecedores têm a obrigação de contratar seguro de responsabilidade que cobre todos os riscos declarados acima, levando em consideração a localização das instalações, as condições físicas e a segurança das instalações, o número e as obrigações dos funcionários, além da a natureza e volume do trabalho contratado.

1.5 Limitações

Para os fins deste documento, o escopo cobrirá apenas os sistemas e o ambiente usados pelo fornecedor no processo de preparação de dados, pré-personalização e personalização. As atividades de autorização e liquidação de transações são realizadas em redes e sistemas separados do ambiente de produção e provisionamento de cartões e estão fora do escopo deste documento.

As empresas de pagamento são individualmente responsáveis por definir e gerenciar os programas de conformidade associados a esses requisitos. Entre em contato com as empresas de pagamento de interesse para conhecer quaisquer critérios adicionais.



2 Funções e responsabilidades

Esta seção define os requisitos que se aplicam às várias funções e responsabilidades relacionadas ao gerenciamento das políticas e procedimentos de segurança do fornecedor. Esses requisitos estão relacionados à:

Equipe de segurança da informação

Atribuição de obrigações de segurança

2.1 Equipe de segurança da informação a) O fornecedor deve designar, por escrito, um gerente sênior com conhecimento de segurança

adequado para ser responsável pela gestão de segurança das informações do fornecedor e pela segurança da plataforma de provisionamento baseada em nuvem. Esses requisitos referem-se a essa pessoa como o “Diretor de Segurança da Informação” (“CISO”).

b) O CISO deve ser um funcionário do fornecedor.

c) O CISO deve relatar mensalmente à gerência executiva o status atual de conformidade com a segurança e questões que representam riscos potenciais para a organização.

2.2 Atribuição de segurança Deveres a) O CISO deve:

i. Ser responsável pela conformidade com esses requisitos.

ii. Ter autoridade suficiente para aplicar os requisitos deste documento.

iii. Não realizar atividades que tenha a responsabilidade de aprovar.

iv. Designar uma pessoa de apoio que seja qualificada e capacitada para agir em situações críticas de segurança caso o CISO não esteja disponível.

v. Identificar um gerente de segurança de TI (se não for ele próprio) responsável por supervisionar o ambiente de segurança do fornecedor.

b) Quando o backup do CISO está funcionando em nome do CISO, o backup não deve realizar atividades para as quais eles têm responsabilidade de aprovação e não deve aprovar atividades que foram executadas anteriormente.

c) Quando os gerentes tiverem responsabilidades de conformidade de segurança, as atividades para as quais o gerente tem responsabilidade devem ser claramente definidas.

d) A equipe responsável pelas atividades diárias de produção não deve ser responsabilizada pela avaliação da conformidade de segurança das atividades de produção que executam.



3 Política e procedimentos de segurança

3.1 Política de segurança da informação a) O fornecedor deve definir e documentar uma política de segurança da informação (ISP) para as

instalações.

b) A gerência sênior deve revisar e endossar a validade do ISP pelo menos uma vez por ano.

c) O ISP deve incluir um indivíduo nomeado designado como o “responsável pela política” e ser responsável pela gestão e execução dessa política.

d) O fornecedor deve manter as trilhas de auditoria para demonstrar que o ISP e todas as atualizações foram comunicadas e recebidas pela equipe pertinente. A comprovação da análise e aceitação da equipe do ISP deve ser mantida.

3.2 Procedimentos de Segurança

a) O fornecedor deve manter procedimentos para cada função associada ao ISP para controlar a conformidade com esses requisitos.

b) Os procedimentos devem ser documentados e seguidos para controlar a conformidade com estes Requisitos de Segurança. Os procedimentos de segurança devem ser anualmente revisados, validados e, quando necessário, atualizados.

c) Os procedimentos de segurança devem descrever os grupos, funções e responsabilidades de todas as atividades que protegem os dados do portador do cartão.

3.3 Planos de resposta a incidentes e investigações

O fornecedor deve:

a) Ter um plano de resposta a incidentes (IRP) documentado para comprometimento conhecido ou suspeito de quaisquer dados classificados. O IRP deve ser comunicado às partes pertinentes.

b) Garantir que a equipe relate qualquer atividade inesperada ou incomum relacionada ao equipamento de produção e às operações.

c) Relatar por escrito, dentro de 24 horas, qualquer comprometimento de dados confidenciais ou secretos, conhecido ou suspeito, ao Administrador do Programa de Fornecedores (Vendor Program Administrator, VPA) e aos emissores afetados. As incidências confirmadas devem ser relatadas às autoridades competentes mediante confirmação.

A comunicação escrita deve conter informações sobre perda ou roubo, incluindo, entre outras:

i. Nome do emissor

ii. Tipo de dados

iii. Nome e endereço do fornecedor

iv. Identificação da fonte de dados

v. Descrição do incidente, incluindo:

- Data e hora do incidente

- Detalhes de empresas e pessoas envolvidas

- Detalhes da investigação



- Nome, e-mail e número de telefone da pessoa que relatou a perda ou roubo

- Nome, e-mail e número de telefone de um contato para obtenção de informações adicionais (se não for a pessoa que relatou o incidente)

d) Investigar o incidente e fornecer atualizações pelo menos semanalmente sobre o progresso da investigação.

e) Apresentar um relatório final de incidentes fornecendo os resultados da investigação e qualquer remediação.

f) Identificar e preservar registros, documentos, equipamentos e outros itens relevantes específicos que fornecem evidências para a análise forense.



4 Segurança de dados

Os requisitos de segurança de dados nesta seção e em seções incorporadas se aplicam a dados confidenciais e secretos. O fornecedor deve manter procedimentos detalhados relacionados a cada atividade nesta seção.

4.1 Classificação 4.1.1 Dados Secretos

Os ativos de informação classificados como secretos exigem medidas adicionais para proteção contra uso não autorizado ou divulgação que resultaria em dano significativo ao negócio ou exposição legal. Essa classificação é normalmente usada para informações comerciais ou técnicas altamente confidenciais. Dados secretos são dados que, se conhecidos por qualquer indivíduo, resultariam em riscos de comprometimento generalizado de ativos financeiros.

Todas as chaves simétricas (por exemplo, DES triplo, AES) e assimétricas privadas (por exemplo, RSA) exceto chaves usadas apenas para criptografia dos dados do portador do cartão são dados secretos e devem ser gerenciados de acordo com a Seção 8 deste documento, “Gerenciamento de chaves: dados secretos.”

Exemplos:

Chaves de personalização de chip

Chaves e chaves de PIN usadas para gerar CVVs, CVCs, CThs ou

CScs. Pins

4.1.2 Dados Confidenciais Considera-se dados confidenciais todas as informações que possam oferecer ao fornecedor uma vantagem competitiva ou poderiam causar dano comercial ou exposição legal se fossem usadas ou divulgadas sem restrição. Dados confidenciais são dados restritos a indivíduos autorizados. Isso inclui os dados do titular do cartão e as chaves usadas para criptografar dados do titular do cartão. Esses são dados confidenciais e devem ser gerenciados de acordo com a Seção 9 deste documento, “Gerenciamento de chaves: dados confidenciais.”

Exemplos:

PAN, validade, código de serviço, chaves

TLS de nome do titular do cartão

Evidência do fornecedor preservando credenciais

De autenticação de dados para solicitar tokens

Número do diretório do assinante internacional da estação móvel (número usado para identificar um número de telefone celular)

4.1.3 Dados irrestritos/públicos Dados irrestritos/públicos incluem todos os dados não definidos nos termos acima, ou seja, informações desenvolvidas e prontas para disseminação pública, incluindo qualquer informação cuja liberação ao público tenha sido explicitamente aprovada pela gerência. Os controles estão fora do escopo desses requisitos e podem ser definidos pelo fornecedor.



4.1.4 Proteções Devem existir requisitos de segurança documentados que definem os controles de proteção proporcionais ao esquema de classificação.

Todos os dados de pagamento devem ter um proprietário identificável responsável pela classificação e para garantir que os controles de proteção sejam implementados e trabalhados.

4.2 Criptografia

Todos os dados secretos e confidenciais devem ser:

a) Criptografados usando-se algoritmos e tamanhos de chaves conforme descrito no Anexo A Normativo.

b) Criptografados todo o tempo durante a transmissão e o armazenamento.

c) Descriptografado pelo tempo mínimo necessário para a preparação e personalização de dados.

d) O fornecedor só deve descriptografar ou traduzir dados do portador do cartão na preparação de dados ou na personalização ou na rede de provisionamento baseada na nuvem, e não enquanto estiver em uma rede de internet ou pública.

4.3 Dados de acesso ao titular do cartão

O fornecedor deve:

a) Documentar e seguir os procedimentos que descrevem os requisitos de acesso aos dados do fornecedor.

b) Evitar acesso direto aos dados do portador do cartão fora da rede de provisionamento baseada na nuvem ou da rede de personalização.

c) Evitar o acesso físico e lógico fora da área de alta segurança (High Security Area, HSA) às redes de preparação ou personalização de dados.

d) Certificar-se de que o acesso seja baseado na necessidade de saber e que um indivíduo não receba mais do que o acesso suficiente para realizar seu trabalho.

e) Estabelecer a autenticação de usuário adequada antes do acesso.

f) Certificar-se de que sejam produzidas trilhas de auditoria de acesso que forneçam detalhes suficientes para identificar os dados acessados do portador do cartão e o usuário individual que acessa os dados.

g) Certificar-se de que os PANs estejam mascarados quando exibidos ou impressos, a menos que haja uma autorização por escrito do emissor. Quando os PANs são mascarados, apenas os seis primeiros e os quatro últimos dígitos do PAN podem estar visíveis, no máximo. Os requisitos de negócios devem ser documentados e aprovados pelo emissor. Os PANs devem ser criptografados em todos os outros momentos e descriptografados apenas pelo tempo mínimo necessário para o processamento.

h) Aplique medidas apropriadas para garantir que qualquer acesso de terceiros atenda aos seguintes requisitos:

i. O acesso de terceiros ao titular do cartão ou dados de provisionamento baseados na nuvem deve ser baseado em um contrato formal que mencione políticas e padrões de segurança aplicáveis;



ii. O acesso ao titular do cartão ou aos dados de provisionamento com base na nuvem e

as instalações de processamento não devem ser fornecidos até que os controles de acesso apropriados tenham sido implementados e um contrato definindo termos para acesso tenha sido assinado;

i) Certifique-se de que apenas administradores de banco de dados autorizados tenham a capacidade de acessar diretamente os bancos de dados do titular do cartão ou do provisionamento com base na nuvem. Outros acessos e consultas de usuários devem ser feitos via métodos programáticos.

j) Garanta que o acesso direto aos bancos de dados esteja restrito aos administradores autorizados do banco de dados. Os registros de sistemas para o acesso do administrador do banco de dados devem existir e devem ser revisados semanalmente.

k) Certifique-se de que as IDs de aplicativo (programa) usadas nos processos baseados na nuvem sejam usadas apenas para os fins pretendidos e não para acesso individual de usuário.

4.4 Dados de transmissão do titular do cartão

Os requisitos nesta seção aplicam-se aos dados transmitidos para ou a partir do emissor ou processador autorizado.

a) Os procedimentos de transmissão de dados devem incorporar a manutenção de um registro de auditoria de transmissão que inclua, no mínimo:

i. Data e hora da transmissão

ii. Identificação da fonte de dados

b) Os dados transmitidos ou recebidos de uma fonte externa ou transferidos na rede de provisionamento baseada na nuvem devem ser criptografados e descriptografados de acordo com os Requisitos de Criptografia deste documento.

c) O fornecedor deve estabelecer mecanismos que garantam a autenticidade e validar a integridade dos dados transmitidos e recebidos.

d) O fornecedor deve proteger a integridade dos dados do portador do cartão contra modificação e exclusão em todos os momentos.

e) O fornecedor deve aceitar dados apenas de fontes pré-autorizadas.

f) O fornecedor deve registrar e informar as marcas de cartão de todos os emissores que enviam os dados do titular do cartão do fornecedor em texto claro.

g) Se o arquivo não for transmitido com sucesso ou apenas parte dos dados for recebida, o destinatário deverá entrar em contato com o remetente para resolver. O fornecedor deve informar ao emissor ou processador autorizado o mais rapidamente possível que o arquivo não foi recebido com sucesso. Qualquer transmissão de dados incompleta recebida deve ser excluída sob controle duplo e registrada de acordo.

4.5 Dados de retenção e exclusão do titular do cartão

O fornecedor deve:

a) Garantir que os procedimentos da política de retenção de dados do fornecedor e seja documentada e seguida.



b) Excluir os dados do titular do cartão dentro de 30 dias da data em que o arquivo do cartão foi

personalizado, a menos que o emissor tenha autorizado a retenção por um período mais longo, por escrito.

i. Certificar-se de que o período de retenção autorizado não exceda seis meses a partir da data em que o cartão foi personalizado.

ii. Certificar-se de que cada autorização do emissor para reter dados seja válida por não mais do que dois anos.

c) Excluir os dados na máquina de personalização assim que o trabalho for concluído.

d) Confirmar a exclusão dos dados excluídos manualmente, incluindo a aprovação por uma segunda pessoa autorizada.

e) Realizar auditorias trimestrais para garantir que todos os dados além do período de retenção de dados tenham sido excluídos.

f) Certificar-se de que todos os dados secretos ou confidenciais foram removidos irrecuperavelmente antes que a mídia seja usada para qualquer outro fim.

g) Garantir que a destruição da mídia seja realizada de acordo com os padrões do setor (consulte ISO 9564-1: gerenciamento e segurança do número de identificação pessoal) sob controle duplo e a manutenção de um registro assinado confirmando o processo de destruição.

h) Certificar-se de que os dados estejam sempre armazenados dentro da área de alta segurança (HSA).

i) Garantir que os dados retidos por mais de 30 dias após a personalização estejam em conformidade com os seguintes requisitos adicionais. Esses dados devem:

i. Ser removidos do ambiente de produção ativo.

ii. Ser armazenados em um servidor ou mídia separada

iii. Estar acessíveis apenas sob controle duplo.

4.6 Manuseio da mídia a) O fornecedor deve ter uma política de mídia removível documentada que inclua

notebooks, dispositivos móveis e dispositivos de armazenamento removíveis como, por exemplo, dispositivos USB, fitas e discos.

b) Todas as mídias removíveis (por exemplo, dispositivos USB, fitas, discos) dentro da HSA devem ser claramente rotuladas com um identificador exclusivo e deve ser feita a classificação de dados.

c) Todas as mídias removíveis devem ser armazenadas, controladas e rastreadas com segurança.

d) Todas as mídias removíveis na HSA ou no ambiente de provisionamento baseado na nuvem devem estar sob custódia de uma pessoa autorizada, a qual não deve ter capacidade de descriptografar quaisquer dados sensíveis ou confidenciais contidos nessa mídia.

e) Um registro deve ser mantido quando a mídia for removida ou devolvida ao local de armazenamento, ou transferida para a custódia de outra pessoa. O registro deve conter:

i. Identificador exclusivo ii. Data e hora



iii. Nome e assinatura do custodiante atual iv. Nome e assinatura do custodiante do destinatário v. Motivo da transferência

f) As transferências de custódia entre dois indivíduos devem ser autorizadas e registradas.

g) A transferência de mídia removível para e a partir da HSA deve ser autorizada e registrada.

h) Destrua fisicamente qualquer mídia que contenha dados secretos ou confidenciais quando não for possível excluir os dados de forma que não sejam mais recuperáveis.

4.7 Personalização sem contato

Os requisitos de segurança das placas de interface dupla que são personalizados usando a interface de contato são os mesmos que para qualquer outro cartão com chip. Os requisitos nesta seção se aplicam à personalização de cartões com chip através da interface NFC sem contato.

O fornecedor deve:

a) Certificar-se de que os sinais de personalização não podem ser detectados além da HSA.

b) Realizar uma varredura de área ao redor da HSA sempre que o ambiente de personalização for alterado para confirmar que os dados de personalização enviados pela comunicação sem fio não vão além da HSA.

c) Certificar-se de que quando os sinais de personalização são criptografados, eles mantêm conformidade com os padrões de criptografia definidos no Anexo Normativo A. Se os sinais forem criptografados, 4.7 a, b e d neste documento não se aplicam.

d) Realizar uma inspeção manual ou automatizada da área de personalização segura, pelo menos duas vezes por mês, a fim de detectar quaisquer dispositivos de radiofrequência (RF) invasores.

e) Certificar-se de que os cartões personalizados (incluindo rejeitos) sejam armazenados e manuseados como lotes de duas ou mais placas ou incluídos dentro da embalagem protetora que restrinja as emissões de cartão de leitura até que os cartões sejam embalados para distribuição final ou destruição.

4.8 Dados usados para Teste

a) As chaves de teste (não produção) e os dados de teste (não produção) não podem ser usados com equipamentos de produção.

b) Os cartões usados para a validação final do sistema ou aceitação do usuário que usam chaves de produção e/ou dados devem ser produzidos usando-se equipamentos de produção.

4.9 Registros de atividades de provisionamento móvel

O fornecedor deve manter um registro eletrônico para ambos quando os cartões forem provisionados com e sem sucesso. O registro deve ser mantido por no mínimo 45 dias.



4.10 Plano de descomissionamento

a) O fornecedor deve documentar suas políticas e os procedimentos pelos quais os bens associados com as atividades de produção e provisionamento de cartões estejam protegidos em caso de encerramento das atividades de produção.

b) Os procedimentos devem identificar todo armazenamento de dados, materiais de design de cartão, cartões, componentes de cartões, chaves físicas, chaves criptográficas e hardware utilizado para atividades de produção que devem ser protegidos.

c) As expectativas de descarte de cada item identificado devem ser definidas. Por exemplo, os itens podem ser devolvidos ao proprietário, transportados até um usuário autorizado ou destruídos.



5 Segurança de rede

5.1 Fornecedor típico Rede Os requisitos nesta seção não se aplicam a fornecedores que realizam apenas atividades de gerenciamento de chaves ou pré-personalização em um sistema com cabo independente (não conectado a nenhuma rede) e não executam a preparação de dados ou personalização dentro de suas instalações.

Figura 5-1

O diagrama acima mostra uma configuração de rede típica de um ambiente de fornecedor e uma conexão genérica a partir da fonte de dados para as máquinas no chão de produção.

A seguir, uma breve descrição de cada uma das nuvens de rede:

5.1.1 Emissor/Fonte de dados Este é o emissor que possui os dados do titular do cartão ou que o envia ao fornecedor em nome do emissor.

5.1.2 Rede privada (linhas alugadas), internet, POTS Os dados do titular do cartão são geralmente enviados sobre esses três principais tipos de rede para o fornecedor de personalização.

5.1.3 Produção e provisionamento de cartões DMZ Este é o segmento de rede que contém servidores e aplicativos acessíveis por uma rede externa (ou seja, qualquer rede que esteja fora da rede de produção de cartão ou sua DMZ).

a) O DMZ deve ser dedicado às atividades de produção/provisionamento de cartões.

b) A rede de produção e provisionamento de cartões deve ser separada de outras partes da rede de uma organização.

c) Todas as conexões de e para a rede de personalização devem ser através de um sistema na DMZ

d) O DMZ deve estar localizado no espaço de servidor da HSA.

Observação: Os sistemas de preparação de dados e personalização podem estar na mesma rede.



e) O equipamento de infraestrutura DMZ localizado na HSA Server Room deve estar em

um rack dedicado com acesso restrito ao número mínimo de pessoas autorizadas. f) Todos os switches e cabos associados ao equipamento DMZ devem ser armazenados

no mesmo rack com apenas o número mínimo necessário de conexões de cabo entrando/saindo do rack para fornecer conectividade a firewalls.

Os diagramas a seguir ilustram a colocação aceitável da DMZ e firewalls associados:

Figura 5-2

Figura 5-3

5.1.4 Preparação de dados Rede Esta é a rede que contém os servidores onde os dados do titular do cartão são armazenados com personalização pendente. Esta também é a rede onde os dados são preparados e enviados para o chão de produção.

5.1.5 Personalização Rede Esta é a rede que contém as máquinas de personalização de cartões.



5.1.6 Provisionamento móvel Redes O provisionamento de HCE deve estar em sua própria rede, mas o provisionamento baseado em SE não é necessário para ser separado de outras redes de personalização.

Observação: Consulte o Apêndice B para outros exemplos de topologia.

5.2 Requisitos gerais O fornecedor deve:

a) Manter um diagrama de topologia de rede atual que inclua todos os componentes do sistema na rede. O diagrama deve definir claramente os limites de todas as redes.

b) Verificar se o diagrama de topologia de rede foi revisado, está atualizado conforme apropriado e foi verificado pelo menos uma vez por ano e sempre que a configuração da rede for alterada.

c) Garantir que o CISO aceite, por assinatura formal, as implicações de segurança da topologia de rede atual.

d) Documentar o fluxo do titular do cartão e dados de provisionamento baseados na nuvem no ambiente do recebimento/geração até o fim do seu ciclo de vida.

e) Certificar-se de que os sistemas de personalização e preparação de dados estejam em rede(s) dedicada(s) independente(s) do back office (por exemplo, contabilidade, recursos humanos, etc.) e redes conectadas à Internet. Uma LAN virtual (VLAN) não é considerada uma rede separada.

f) Sistemas e aplicativos que compõem a rede de provisionamento baseada na nuvem devem ser segregados física e logicamente de outras redes de fornecedores e redes conectadas à internet. Por exemplo, em um ambiente de fornecedor de cartão tradicional, este pode ser um rack separado em uma sala de servidor, ou em uma entidade somente de provisionamento, alojado em uma sala separada ou gaiola metálica em um data center. Não pode estar no mesmo rack que outros servidores usados para diferentes finalidades.

g) Coloque controles em vigor para restringir, prevenir e detectar acesso não autorizado às redes de personalização e baseadas em nuvem. Acessar de dentro da área de alta segurança qualquer outra coisa que não seja a personalização ou as redes baseadas em nuvem devem ser “somente leitura.”

h) Ser capaz de avaliar imediatamente o impacto se algum dos seus nós mais importantes estiver comprometido.

i) Ter controles em vigor para restringir a permissão de "gravação" para qualquer sistema externo à rede de personalização para apenas funções pré-aprovadas que tenham sido autorizadas pelo VPA, exceto para sistemas no DMZ dedicado. Essas funções de gravação não devem transmitir dados do titular do cartão se isso envolver a gravação direta do sistema contendo as informações.

j) Controle o tempo todo os pontos de conexão físicos que levam à rede de personalização e à rede de provisionamento baseada em nuvem.

k) Evite que os dados sejam adulterados ou monitorados protegendo o cabeamento de rede associado ao movimento de dados de personalização.

l) Transfira os dados e as chaves do emissor necessários para a rede de personalização ou a rede de provisionamento baseada na nuvem por meio de um processo definido e documentado.



m) Garanta a manutenção em vigor de um processo para atualizações e correções e

identificação de sua criticidade, conforme detalhado na Seção 6.3.

n) Tenha capacidade para detectar, isolar e corrigir operações anormais em sistemas de rede de provisionamento baseados em nuvem e em endpoints de rede de provisionamento baseados em nuvem em tempo real, 24 horas por dia, 7 dias por semana.

5.3 Dispositivos de rede Os requisitos nesta seção aplicam-se a todo o hardware (por exemplo, roteadores, controladores, firewalls, dispositivos de armazenamento) que compreenda as redes de preparação de dados e personalização.

O fornecedor deve:

a) Documentar o processo para autorizar todas as alterações aos dispositivos e protocolos de rede.

b) Documentar os ajustes atuais de configuração do dispositivo de rede, as regras definidas e a justificativa para cada dispositivo.

c) Garantir que todos os serviços disponíveis sejam aprovados por um gerente de segurança autorizado.

d) Implementar controles de segurança lógica e física que protejam a integridade dos dispositivos de rede usados.

e) Implementar mecanismos para monitorar efetivamente a atividade nos dispositivos de rede.

f) Implementar patches em conformidade com a Seção 6.3, “Configuração e gerenciamento de patches.”

g) Mantenha uma trilha de auditoria de todas as alterações e a aprovação associada.

h) Implemente IDs exclusivas para cada administrador.

i) Implemente backups de dispositivos de rede (por exemplo, software do sistema, dados de configuração e arquivos de banco de dados) antes de qualquer alteração e armazenar e gerenciar todas as mídias com segurança.

j) Implemente um mecanismo para garantir que apenas alterações autorizadas sejam feitas nos dispositivos de rede.

5.4 Firewalls

Os requisitos nesta seção se aplicam aos firewalls que protegem as redes de preparação de dados e personalização.

5.4.1 Geral O fornecedor deve:

a) Certificar-se de que todos os documentos relacionados às configurações do firewall sejam armazenados com segurança.

b) Implantar um firewall externo fora do HAS para proteger o DMZ do HAS (veja as figuras 2 e 3 acima para configurações aceitáveis).



c) Instale um firewall entre a rede de preparação de dados e a rede de personalização,

a menos que ambos estejam localizados dentro da mesma área ou rede de alta segurança.

d) Implante um firewall entre a rede externa e a DMZ e entre a DMZ e a rede de provisionamento baseada na nuvem.

e) Utilize firewalls fisicamente separados no supracitado.

f) Tenha capacidade para detectar, isolar e corrigir operações anormais em sistemas de rede em tempo real, 24 horas por dia, 7 dias por semana, no firewall externo (DMZ) voltado para fora.

g) Implemente controles adequados do sistema operacional em firewalls.

h) Revise conjuntos de regras de firewall e validar a justificativa de negócios

De suporte: mensalmente, ou

Trimestralmente, com revisão após cada alteração de configuração de firewall. i) Restrinja o acesso físico e lógico a firewalls apenas para aqueles designados que

estão autorizados a realizar atividades de administração de firewall ou roteador.

j) Certifique-se de que o conjunto de regras de firewall seja de tal modo que qualquer servidor que exija apenas conexões de entrada (por exemplo, servidores da web) e esteja proibido de fazer conexões de saída e vice-versa.

k) Garantir que apenas indivíduos autorizados possam executar a administração do firewall.

l) Execute firewalls e roteadores em hardware dedicado. Todos os softwares não relacionados ao firewall, como compiladores, editores e software de comunicação, devem ser excluídos ou desativados.

m) Implemente relatórios diários de análise automatizada para monitorar a atividade do firewall.

n) Use senhas de administrador exclusivas para firewalls usados pelo sistema de personalização e as senhas usadas para outros dispositivos de rede na instalação.

o) Implemente mecanismos para proteger os registros do firewall e do sistema de roteador contra adulteração e procedimentos para verificar a integridade do sistema mensalmente.

p) Permita explicitamente o tráfego de entrada e saída das redes de personalização e provisionamento baseadas em nuvem. Uma regra deve estar em vigor para negar qualquer outro tráfego.

5.4.2 Configuração Os firewalls devem:

a) Ser configurados para permitir acesso à rede apenas aos serviços necessários.

b) Ser reforçados de acordo com as melhores práticas do setor, se o firewall for implementado em um sistema operacional comercial pronto para uso (COTS).

c) Proibir o acesso público direto entre qualquer rede externa e qualquer componente do sistema que armazene dados do titular do cartão.



d) Implementar o mascaramento do IP ou a tradução de endereço de rede (Network

Address Translation, NAT) no firewall entre a DMZ e a personalização e as redes de provisionamento baseadas em nuvem.

e) Se gerenciados remotamente, ser gerenciados de acordo com a Seção 5.6 “Acesso remoto”

f) Ser configurado para negar todos os serviços não expressamente permitidos.

g) Desabilitar todos os serviços, protocolos e portas desnecessários. Os serviços autorizados devem ser documentados com uma justificativa comercial e aprovados pelo gerente de segurança de TI.

h) Desative o roteamento de origem no firewall.

i) Notifique o administrador em tempo real sobre qualquer item que exija atenção imediata.

j) Mantenha padrões de configuração de segurança de linha de base documentados para componentes do sistema com base em padrões de endurecimento do sistema aceitos pelo setor, que incluem, entre outros: o Center for Internet Security (CIS) o International Organization for Standardization (ISO) o Instituto SysAdmin Audit Network Security (SANS) o National Institute of Standards and Technology (NIST).

A configuração básica deve tratar, no mínimo, de: o Segurança de acesso de usuário e grupo o Segurança de arquivos e diretórios o Serviços restritos o Atualização do sistema e padrões de instalação o Software de segurança instalado

k) O fornecedor deve realizar verificações de configurações de segurança da linha básica no ambiente de provisionamento baseado na nuvem: o Mensalmente, ou o Trimestralmente, com revisão após cada alteração de configuração de firewall

5.5 Software ou programas antivírus

O fornecedor deve:

a) Definir, documentar e seguir procedimentos para demonstrar:

o Identificação de alertas de segurança por ex., assinatura de alertas de segurança, como os da Microsoft e do Computer Emergency Response Team, CERT

o Identificação de atualizações de componentes do sistema que afetem a capacidade de suporte e estabilidade de sistemas operacionais, drivers de software e componentes de firmware

o Inventário dos sistemas atuais no ambiente, incluindo informações sobre componentes de software instalados e sobre serviços de execução

b) Implemente softwares antivírus em todos os sistemas normalmente afetados por softwares mal-intencionados por exemplo, computadores pessoais e servidores.



c) Certificar-se de que todos os mecanismos antivírus estejam atualizados, funcionem ativamente e

possam gerar registros de auditoria.

d) Verificar se há atualizações de antivírus pelo menos diariamente e instalar as atualizações de forma consistente com o Gerenciamento de Patches. Deve existir documentação para informar por que nenhuma atualização foi instalada.

5.6 Acesso remoto

Para os fins desta seção, isso se aplica à administração remota pelo fornecedor e não pelas conexões do emissor.

5.6.1 Condição das conexões a) O acesso remoto é permitido apenas para a administração da rede ou dos

componentes do sistema.

b) Não é permitido acesso de fora da instalação ao sistema de acesso ao crachá.

c) O acesso remoto (ou seja, de fora da HSA) para atividades administrativas é permitido apenas de locais predeterminados e autorizados usando sistemas aprovados pelo fornecedor.

d) É proibido acessar o uso de hardware de propriedade pessoal.

e) O acesso remoto não é permitido quando os funcionários qualificados estão temporariamente fora do local e o acesso remoto é uma conveniência.

f) O processo de acesso remoto deve ser totalmente documentado e incluir pelo menos os seguintes componentes:

i. Componentes do sistema para os quais o acesso remoto é permitido

ii. O local a partir da qual o acesso remoto é permitido

iii. As condições sob as quais o acesso remoto é aceitável

iv. Usuários com permissão de acesso remoto

v. Os privilégios de acesso aplicáveis a cada usuário autorizado

g) Todos os privilégios de acesso devem ser validados trimestralmente por pessoa autorizada.

h) O acesso remoto é proibido para qualquer sistema onde os dados de titulares de cartão de texto simples estejam sendo processados.

i) O acesso remoto é proibido para dados do titular do cartão com texto simples, chaves criptográficas de texto simples ou componentes/compartilhamentos com chave de texto simples.

j) O fornecedor deve:

i. Certificar-se de que os sistemas que permitem conexões remotas aceitam conexões somente de sistemas de fonte pré-autorizados.

ii. Garantir que a administração remota seja predefinida e pré-autorizada pelo fornecedor.

iii. Garantir que as mudanças remotas estejam em conformidade com os requisitos de gerenciamento de mudanças, conforme descrito na Seção 6.2, “Gestão da mudança”.



iv. Certificar-se de que todos os locais de acesso remoto estejam incluídos na

avaliação da instalação e atendam a esses requisitos.

v. Seja capaz de fornecer evidência de validação de conformidade para qualquer local de acesso remoto.

k) Garanta que a equipe que não seja do fornecedor realizando a administração remota mantenha o seguro de responsabilidade para cobrir perdas potenciais. Todos os funcionários que executam a administração remota devem atender aos mesmos requisitos de qualificação pré-triagem que os funcionários que trabalham em áreas de alta segurança.

l) Todo o acesso remoto deve usar uma VPN que atenda aos requisitos na seção a seguir.

5.6.2 Rede Privada Virtual (Virtual Private Network, VPN) a) Para acesso remoto, as VPNs devem iniciar do dispositivo de origem (por exemplo, PC

ou dispositivo pronto para uso especificamente projetado para acesso remoto seguro) e terminar no dispositivo de destino ou no firewall de personalização. Se o ponto de terminação for o firewall, ele deve usar IPSec ou pelo menos uma conexão TLS de acordo com o Requisito de Segurança de Dados do PCI 4.1 para o dispositivo de destino.

b) Para acesso remoto aos componentes DMZ, a VPN deve terminar no dispositivo de destino.

c) SSL e TLS 1.0 são expressamente proibidos em conexão com o supracitado.

d) O tráfego na VPN deve ser criptografado usando DES triplo com chaves de pelo menos o dobro de comprimento ou padrão de criptografia avançada (Advanced Encryption Standard, AES).

e) Modificações na VPN devem estar em conformidade com os requisitos de gerenciamento de mudanças, conforme descrito na Seção 6.2, “Gestão da mudança”.

f) Deve haver mecanismos (por exemplo, assinaturas digitais, somas de verificação) para detectar alterações não autorizadas nas configurações de VPN e controle de mudança.

g) A autenticação multifatores deve ser usada para todas as conexões VPN.

h) O acesso deve ser recusado após três tentativas consecutivas de acesso sem sucesso.

i) Os contadores de acesso só devem ser redefinidos por pessoa autorizada após a validação do usuário por outra pessoa autorizada.

j) A conexão deve expirar dentro de cinco minutos se a sessão estiver inativa.

k) O acesso remoto deve ser registrado e o registro deve ser revisado semanalmente quanto a atividades suspeitas. A comprovação da revisão do registro deve ser mantida.

l) O tráfego VPN usando o Internet Protocol Security (IPSec) deve atender aos seguintes requisitos adicionais:

i. O modo túnel deve ser usado, exceto onde a comunicação é host-to-host.

ii. O modo agressivo não deve ser usado para o estabelecimento do túnel.



iii. O método de autenticação do dispositivo deve usar certificados obtidos de

uma autoridade certificadora.

iv. O encapsulamento de segurança de carga (Encapsulating Security Payload, ESP) deve ser usado para fornecer confidencialidade e autenticação de dados.

v. A opção de sigilo encaminhado perfeito (Perfect Forward Secrecy, PFS) de troca de chave da Internet (Internet Key Exchange, IKE) deve ser usada para proteger contra o comprometimento da chave da sessão.

5.7 Redes Wireless


a) Implementar uma política documentada sobre comunicações sem fio e comunicar claramente esta política a todos os funcionários.

b) Não usar comunicações sem fio para a transferência de quaisquer dados de personalização e/ou dados de provisionamento baseados em nuvem.

c) Identificar, analisar e documentar todas as conexões. A análise deve incluir finalidade, avaliação de risco e ação a ser tomada.

d) Use um sistema de detecção de intrusão sem fio (Wireless Intrusion-Detection System, WIDS) capaz de detectar redes ocultas e falsas (spoofed) em todas as redes sem fio autorizadas.

e) Quando usar uma rede sem fio, use o WIDS para realizar varreduras aleatórias dentro da HSA pelo menos mensalmente para detectar redes sem fio invasoras e ocultas.

f) Documente, investigue e aja para resolver quaisquer problemas identificados quando forem detectadas conexões não autorizadas ou possíveis intrusões. A investigação deve ocorrer imediatamente. A resolução deve ocorrer em tempo hábil.

g) Use um dispositivo de leitura capaz de detectar redes sem fio invasoras e ocultas, independentemente de o fornecedor usar ou não uma rede sem fio. As varreduras aleatórias da HSA devem ser conduzidas pelo menos mensalmente.

5.7.2 Gestão Se forem usados canais de comunicação sem fio para transportar quaisquer dados de não personalização dentro do ambiente de personalização, os seguintes requisitos se aplicam:

a) Todas as conexões sem fio devem ser autorizadas pela gerência, com seu propósito, conteúdo e usuários autorizados definidos e validados periodicamente.

b) As redes sem fio só devem ser usadas para a transmissão de dados não titulares do cartão (por exemplo, controle de produção, rastreamento de estoque) e devem ser adequadamente protegidas.

O fornecedor deve ter controles implementados para garantir que as redes sem fio não possam ser usadas para acessar os dados do portador do cartão.

c) O fornecedor deve implantar um firewall para segregar a rede sem fio e a rede cabeada.



d) Todos os gateways sem fio devem ser protegidos com firewalls.

e) Todos os pontos de acesso sem fio devem ser configurados para evitar a administração remota pela rede sem fio.

f) Todo o tráfego sem fio deve ser criptografado com Triple DES ou AES (consulte o Anexo A) e uma chave de criptografia de pelo menos 128 bits, usando WPA, WPA2 ou 802.11x (ou um protocolo equivalente).

A criptografia WEP não deve ser usada e deve ser desativada.

g) O identificador do conjunto de serviços (SSID) não deve ser transmitido.

h) O fornecedor deve alterar todas as configurações de segurança padrão para conexões sem fio, incluindo senhas, SSID, senhas de administrador e strings de comunidade SNMP (Simple Network Management Protocol).

i) O fornecedor deve validar quaisquer pontos de acesso sem fio que contenham memória flash pelo menos uma vez por mês para garantir que o firmware contenha a versão do software autorizado e as atualizações apropriadas.

j) O fornecedor deve desativar o SNMP em todos os pontos de acesso sem fio.

k) Senhas estáticas usadas para unir redes sem fio devem estar em conformidade com os requisitos na Seção 7.2 “Controle de senhas”, mas podem ser compartilhadas com outras pessoas na organização, conforme a necessidade de conhecê-las.

5.7.3 Requisitos adicionais para usar o Wi-Fi Se a rede sem fio usa Wi-Fi com base no IEEE 802.11, o fornecedor deve garantir o atendimento dos seguintes requisitos:

a) O SSID padrão deve ser alterado na instalação e ter pelo menos 8 caracteres.

b) Deve ser mantido um registro de endereços de controle de acesso à mídia e dispositivos associados (incluindo a marca, modelo, proprietário e motivo para acesso), realizando-se uma verificação de endereços de controle de acesso de mídia autorizada no ponto de acesso (AP) pelo menos trimestralmente.

c) Deve-se usar uma lista de controle de acesso (Access-Control List, ACL) baseada no endereço de controle de acesso à mídia deve ser usada para o controle de acesso dos clientes.

d) O Wi-Fi Protected Access (WPA) deve ser ativado se o sistema sem fio for compatível com WPA.

e) As senhas padrão no AP devem ser alteradas. f) O recurso de gerenciamento do AP deve ser desativado na interface sem fio e ser

gerenciado somente pela interface confiável e cabeada.

g) O AP deve ser atribuído a endereços exclusivos de protocolo de Internet (IP) em vez de depender do Host Dinâmico.



5.8 Testes de segurança e Monitoramento

5.8.1 Vulnerabilidade O fornecedor deve:

a) Realizar varreduras externas trimestrais de vulnerabilidades por meio de um fornecedor de varreduras aprovado (Approved Scanning Vendor, ASV) qualificado pelo Conselho de padrões de segurança da Indústria de cartões de pagamento (Payment Card Industry Security Standards Council, PCI SSC).

b) Execute varreduras quanto à presença de vulnerabilidades das redes internas e externas pelo menos trimestralmente e após qualquer mudança significativa na rede (como instalações de novos componentes do sistema, mudanças na topologia da rede, modificações das normas do firewall, aprimoramentos de produtos). As varreduras realizadas após as alterações devem ser realizadas pela equipe interna da empresa.

c) Certifique-se de que todos os resultados das varreduras de vulnerabilidades da rede sejam priorizados e rastreados. A ação corretiva para vulnerabilidades de alta prioridade deve ser iniciada dentro de dois dias úteis.

d) Mantenha evidência de remediação bem-sucedida e disponibilize-a durante as avaliações de conformidade do local, quando solicitado.

5.8.2 Penetração O fornecedor deve:

a) Realizar testes de penetração internos e externos pelo menos uma vez por ano e depois de qualquer alteração significativa na infraestrutura.

i. O teste de penetração interna não deve ser executado remotamente.

ii. Os testes de penetração devem ser realizados na camada de rede e incluem todos os componentes de rede de personalização, bem como sistemas operacionais.

iii. Os testes de penetração devem ser realizados na camada de aplicação e devem incluir:

o Falhas de injeção (por exemplo, injeção de SQL) o Buffer overflow o Armazenamento criptográfico inseguro o Manuseio incorreto de erros o Todas as outras vulnerabilidades de rede descobertas

b) Certifique-se de que todos os achados dos testes de penetração sejam priorizados e rastreados. A ação corretiva para vulnerabilidades de alta prioridade deve ser iniciada dentro de dois dias úteis.

c) Mantenha evidência de remediação bem-sucedida e disponibilize-a durante as avaliações de conformidade do local, quando solicitado.



5.8.3 Sistemas de detecção de intrusão

O fornecedor deve:

a) Usar sistemas de detecção de invasões (intrusion-detection systems, IDS) para análise de tráfego de rede. O IDS pode ser implementado como parte de um sistema de prevenção de intrusão (Intrusion-Prevention System, IPS) se um IPS for usado. Estes devem ser implantados, gerenciados e mantidos em todas as redes de fornecedores não apenas para detecção e prevenção de intrusão, mas também para monitorar todo o tráfego de rede de preparação de dados e de personalização e redes de provisionamento baseadas em nuvem. Isso inclui todo o tráfego gerado por máquinas dentro da rede de personalização. Para redes em que PINs de texto simples atravessam, os sistemas não devem ser configurados para permitir a captura de valores de PIN simples.

b) Certifique-se de que o IDS alerta o pessoal quanto a atividades suspeitas em tempo real.

c) Verifique se o IDS monitora todo o tráfego no perímetro da rede de personalização, bem como em pontos críticos dentro da rede de personalização.



6 Segurança do sistema

6.1 Requisitos gerais O fornecedor deve:

a) Documentar os controles de segurança que protegem os dados do portador do cartão e a rede de provisionamento baseada em nuvem.

b) Certifique-se de que qualquer sistema usado no processo de personalização ou no processo de provisionamento baseado em nuvem seja usado apenas para executar a função para a qual foi projetado ou seja, controle de personalização ou atividades de processo de provisionamento baseadas em nuvem.

c) Altere os parâmetros padrão fornecidos pelo fornecedor antes ou durante a instalação no ambiente de produção.

d) Criptografe o acesso administrativo sem console quando ocorrer de dentro da rede de personalização.

e) Sincronize relógios em todos os sistemas associados com personalização ou redes de provisionamento baseadas em nuvem com uma fonte de tempo externa baseada em Tempo Atômico Internacional ou Coordenada Universal de Tempo (Universal Time Coordinated, UTC).

f) Restrinja e proteja o acesso aos arquivos do sistema durante todo o tempo.

g) Certifique-se de que os sistemas virtuais não abrangem domínios de rede diferentes.

h) Certifique-se de que todos os componentes da rede de personalização residam fisicamente na HSA.

i) Certifique-se de que a impressão de PIN ocorra em uma rede dedicada que seja separada de outras redes por seu próprio firewall ou independente (ou seja, a impressora e o HSM são integrados) ou que a impressora PIN está diretamente conectada ao HSM, que descriptografa os PINs para que não haja interceptação.

j) Certifique-se de que o sistema de controle de acesso do crachá esteja em conformidade com os requisitos de segurança do sistema neste documento.

k) Certificar-se de que o acesso por crachás esteja em conformidade com a Seção 7 deste documento, “Gerenciamento de usuário e Controle de acesso ao sistema”.

6.2 Gestão da mudança O fornecedor deve:

a) Garantir que os procedimentos de controle de mudança abordem, no mínimo:

o Garantir que as solicitações de alterações sejam enviadas por usuários autorizados o Identificação de componentes que serão alterados o Documentação dos procedimentos de impacto e back-out o Atestado de testes bem-sucedidos, quando necessário o Manutenção de uma trilha de auditoria de todas as solicitações de mudança o Registre se a mudança foi ou não bem sucedida



b) Garanta que as mudanças de rede e do sistema sigam um processo documentado de

gerenciamento de mudanças e o processo seja validado pelo menos a cada 12 meses.

c) Garanta que todas as alterações sejam aprovadas pelo CISO ou pessoa autorizada antes da implantação.

d) Garanta que o processo de gestão de mudanças inclua procedimentos para mudanças emergenciais.

e) Implemente a identificação e o controle da versão para todos os softwares e documentos.

f) Certifique-se de que a identificação da versão seja atualizada quando uma alteração for liberada ou publicada.

g) Implemente um processo controlado para a transferência de um sistema do modo de teste para o modo ao vivo e do modo ao vivo para o modo de teste.

h) Certifique-se de que a equipe de desenvolvimento e produção deve aprovar a transferência de um sistema de teste para ao vivo e de ao vivo para teste. Este fechamento deve ser testemunhado sob controle duplo.

6.3 Gestão de configurações e patches

O fornecedor deve:

a) Implementar um procedimento documentado para determinar a disponibilidade de patches e atualizações aplicáveis.

b) Certificar-se de que processos sejam implementados para identificar e avaliar vulnerabilidades de segurança recém-descobertas e patches de segurança de fornecedores de software.

c) Garantir o estabelecimento de padrões de configuração seguros para todos os componentes do sistema.

d) Garantir que os padrões de configuração incluam o fortalecimento do sistema, removendo todas as funcionalidades desnecessárias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores Web desnecessários.

e) Garantir que a configuração de todos os componentes do sistema associados à transmissão, armazenamento e personalização de dados seja validada em relação à configuração mensal autorizada.

f) Garanta que todos os sistemas usados em suporte à personalização ou às redes de provisionamento baseadas em nuvem sejam ativamente assistidos na forma de atualizações regulares.

g) Avaliar e instalar os patches mais recentes relevantes à segurança para todos os componentes do sistema em até 30 dias após sua liberação (se os testes de validação forem aprovados).

h) Verificar a integridade e a qualidade dos patches antes da aplicação, incluindo autenticidade da fonte.

i) Fazer uma cópia de segurança do sistema sendo alterado antes de aplicar qualquer patch. O backup deve ser armazenado com segurança.



j) Implementar patches críticos em todos os componentes do sistema voltados para a Internet em

até 7 dias úteis após a liberação. Quando isso não for possível, o CISO, o gerente de segurança de TI e o diretor de TI devem registrar claramente que compreendem que é necessário um patch crítico e autorizam sua implementação dentro de no máximo 30 dias úteis.

k) Garantir que as implementações de hardware e software de emergência estejam em conformidade com os procedimentos e requisitos de validação estabelecidos para implementações de emergência.

l) Certificar-se de que as implementações de hardware e software de emergência sigam os requisitos de configuração e gerenciamento de patches nesta seção.

6.4 Registros de auditoria

O fornecedor deve:

a) Garantir que existam registros de auditoria para todas as redes e dispositivos de rede no ambiente do fornecedor e para sistemas e aplicativos conectados à rede de provisionamento baseada em nuvem. Isso inclui logs de sistema operacional, registros de software de segurança ou registros de produtos e registros de aplicativos contendo eventos de segurança.

b) Certificar-se de que os registros de auditoria incluam pelo menos os seguintes componentes:

i. Identificação do usuário ii. Tipo de evento iii. Carimbo de data e hora válido iv. Indicação de sucesso ou falha v. Origem do evento vi. A identidade ou o nome dos dados, componentes do sistema ou recursos afetados vii. Acesso aos registros de auditoria viii. Alterações nos privilégios de acesso

c) Garantir que os procedimentos sejam documentados e seguidos para análise do registro de auditoria e relatório de atividades incomuns. As revisões de log podem ser automatizadas ou manuais e devem incluir servidores de autenticação, autorização e diretório. No mínimo, a frequência de revisão do registro deve seguir o seguinte:

o Resposta imediata (em tempo real) a ameaças designadas como alertas para eventos associados de alto risco

o Análise diária dos sistemas IDS e IPS o Revisão semanal para pontos de acesso sem fio e servidores de autenticação o Revisão mensal para roteadores o Revisão mensal de registros de auditoria de conta de usuário para bancos de

dados, aplicativos e sistemas operacionais.

d) Verificar se todos os requisitos de registro do sistema estão sendo atendidos, pelo menos uma vez por mês.

e) Certifique-se de que os registros de todos os sistemas críticos e sistemas de provisionamento baseados em nuvem sejam copiados diariamente, protegidos e retidos por pelo menos um ano. Os registros devem ser acessíveis por pelo menos três meses on-line e um ano off-line.



f) Proteger e manter a integridade dos registros de auditoria contra qualquer forma de modificação.

g) Implementar uma estrutura de registro de incidentes e eventos de segurança para a organização.

6.5 Backup e recuperação de redes de provisionamento móvel a) Os procedimentos de backup e recuperação de provisionamento móvel devem ser

documentados.

b) Os procedimentos devem incluir o backup e a recuperação de hardware e software que suportam a atividade de provisionamento.

c) Os procedimentos devem diferenciar e abordar interrupções de serviços de curto e longo prazo.

d) O fornecedor deve proteger cópias de backup de modificações ou destruição intencional ou não intencional.

e) Os backups, sejam armazenados dentro ou fora da HSA, devem ser criptografados e protegidos como os dados primários, conforme descrito na Seção 4.1, Classificação

f) Devem ser estabelecidos controles para proibir a criação de backups não autorizados.

g) Se os procedimentos de recuperação incluírem um local alternativo de processamento, este deve ser aprovado para provisionamento antes que o serviço de provisionamento possa começar no local alternativo.

6.6 Design de software e desenvolvimento


a) Documentar os processos de projeto, desenvolvimento e manutenção.

b) Garanta que essas atividades sejam baseadas em padrões e segurança do setor, façam parte integrante do processo do ciclo de vida do software. Os aplicativos da Web devem ser desenvolvidos com base em diretrizes de codificação seguras, como: o Guia OWASP, o SANS CWE Top 25 e a Codificação Segura CERT.

c) Documentar todos os componentes do software para cada sistema e descrever a funcionalidade fornecida.

d) Proteja qualquer cópia de backup de software da destruição acidental.

6.6.2 Projeto O fornecedor deve documentar o fluxo de dados de personalização dentro do ambiente desde o recebimento/geração até o fim do ciclo de vida.

6.6.3 Desenvolvimento O fornecedor deve:

a) Certificar-se de que o acesso ao código-fonte para aplicativos usados na rede de personalização seja restrito apenas ao pessoal autorizado.



b) Certifique-se de que o software de personalização desenvolvido internamente registra

qualquer reinicialização (e detalhes associados ao evento de reinicialização).

c) Certifique-se de que o software de personalização desenvolvido internamente impõe autorização na reinicialização.

d) Certifique-se de que existe uma separação das tarefas entre a equipe atribuída aos ambientes de desenvolvimento/teste e a equipe atribuída ao ambiente de produção.

e) Certifique-se de que o código-fonte do software esteja restrito somente a funcionários autorizados. O acesso da equipe ao código-fonte deve seguir um processo documentado. As autorizações e aprovações devem ser documentadas.

6.7 Interfaces de uso de serviços da Web para o emissor

O fornecedor deve garantir que:

a) A autenticação mútua é necessária. Ela deve ser implementada usando-se certificados X.509 de cliente e servidor emitidos e assinados por uma autoridade de certificação confiável (Certificate Authority, CA) ou uma VPN construída de acordo com a Seção 5.6.2.

b) A versão aprovada mais atual do TLS é usada para proteger a conexão e requer os

seguintes padrões mínimos de criptografia. Consulte a seção Anexo Normativo A deste documento para obter os algoritmos aceitáveis e os principais pontos fortes.

o A criptografia mais forte razoável deve ser implementada para o aplicativo, se o suporte do cliente e do servidor for maior do que esses padrões mínimos.

o As implementações não devem permitir renegociação de cifra dentro de uma sessão TLS estabelecida.

o A proteção de integridade deve ser fornecida pelo uso do algoritmo SHA-2 ou superior.

c) Todos os clientes e servidores de serviços da Web expostos a redes não confiáveis são protegidos por uma validação de mensagem de suporte de firewall devidamente configurada.

d) Implemente controles para garantir a integridade da mensagem.

6.8 Implementação de software O fornecedor deve:

a) Estabelecer e manter um processo documentado de liberação de software. A garantia de qualidade deve incluir o teste do código para problemas de segurança antes de qualquer lançamento de software.

b) Para software desenvolvido internamente, verifique se o teste de segurança inclui a verificação de que código temporário, as chaves codificadas e o código suspeito foram removidos.

c) Garantir que toda a implementação do software esteja em conformidade com a Seção 6.2, “Gestão da mudança”.

d) Teste o software antes da implementação para garantir a operação correta.

e) Evite depuração dentro do ambiente de produção.



f) Tenha uma configuração de dispositivo PC predefinida para dispositivos PC usados na HSA.

g) Implemente um processo de aprovação para todos os softwares além da configuração padrão do dispositivo PC para dispositivos PC usados na HSA.

h) Certifique-se de que nenhum software não autorizado possa ser instalado.

i) Garanta que todo o software seja transferido do desenvolvimento para a produção de acordo com o processo de controle de mudança.



7 Gerenciamento de usuário e controle de acesso ao sistema

7.1 Gerenciamento de usuários O fornecedor deve:

a) Garantir que os procedimentos sejam documentados e seguidos pela equipe de segurança responsável pela concessão de acesso às redes, aplicativos e informações do fornecedor.

b) Restringir a aprovação e o nível de acesso à equipe com necessidade comercial documentada antes do acesso ser concedido. No mínimo, as aprovações documentadas devem ser retidas enquanto a conta estiver ativa.

c) Restringir o acesso aos sistemas por ID de usuário exclusiva aos indivíduos que têm necessidade comercial.

d) Conceder aos indivíduos o nível mínimo de acesso suficiente para realização de suas tarefas.

e) Certificar-se de que a autenticação de sistemas requer pelo menos o uso de uma ID e senha exclusivas.

f) Restringir o acesso administrativo ao número mínimo de pessoas necessárias para o gerenciamento do sistema.

g) Certificar-se de que senhas e contas de grupos, compartilhadas e genéricas, sejam desabilitadas onde quer que o sistema ofereça suporte a valores exclusivos.

h) Certificar-se de que as contas administrativas genéricas não poderão ser desativadas; essas contas serão usadas somente quando não for possível usar credenciais de login de administrador exclusivas e apenas em emergências.

i) Certificar-se de que, quando contas administrativas genéricas forem usadas, a senha seja gerenciada sob controle duplo, onde ninguém tenha acesso à senha completa. Cada componente da senha deve estar em conformidade com os requisitos de controle de senha na Seção 7.2 abaixo.

j) Validar todos os acessos do sistema pelo menos trimestralmente.

k) Revalidar o acesso dos funcionários a qualquer sistema após uma mudança de tarefas.

l) Garantir que os controles de acesso impeçam a separação de tarefas.

m) Para provisionamento baseado em nuvem, restrinja o acesso e os privilégios do emissor a apenas dados do próprio titular do cartão.

n) Limitar estritamente o acesso privilegiado ou administrativo e garantir que esse acesso seja aprovado pelo gerente do usuário e o gerente de segurança.

o) Estabelecer a supervisão de gerenciamento de acesso privilegiado para garantir a conformidade com a segregação de tarefas.

p) Certificar-se de que todos os acessos administrativos privilegiados sejam registrados e revisados semanalmente.



7.2 Controle de senhas


a) Implementar uma política e procedimentos detalhados relacionados à gestão, uso, renovação e distribuição de senhas.

b) Implementar procedimentos para lidar com perda, esquecimento e comprometimento de senhas.

c) Distribuir procedimentos e políticas de senha para todos os usuários que tenham acesso às informações de portadores de cartões ou qualquer sistema usado como parte do processo de personalização.

d) Certificar-se de que apenas usuários com privilégios administrativos possam administrar senhas de outros usuários.

e) Não armazenar senhas em texto legível.

f) Alterar todas as senhas padrão.

7.2.2 Características e uso O fornecedor deve garantir que:

a) Os sistemas sejam configurados para que as senhas recém-emitidas e redefinidas sejam configuradas para um valor exclusivo para cada usuário.

b) As senhas recém-emitidas são alteradas no primeiro uso.

c) A senha “First use” expira se não for usada dentro de 24 horas da distribuição.

d) Os sistemas exijam senhas com pelo menos oito caracteres.

e) As senhas tenham uma combinação de pelo menos três entre os seguintes:

i. Letras maiúsculas ii. Letras maiúsculas iii. Números iv. Caracteres especiais

f) As senhas não sejam iguais à ID de usuário.

g) As senhas não sejam exibidas durante a digitação.

h) As senhas sejam criptografadas durante a transmissão e tornadas ilegíveis quando armazenadas.

i) As senhas tenham uma duração máxima de 90 dias e uma duração mínima de um dia.

j) Ao atualizar senhas, o sistema impeça que os usuários utilizem uma senha igual a uma das quatro senhas anteriores.

k) A identidade do usuário é verificada antes da senha do usuário pendente.

l) As credenciais de autenticação para o processo de tokenização são protegidas para evitar divulgação e uso não autorizados.



7.3 Bloqueio de sessões

O fornecedor deve:

a) Aplicar o bloqueio de uma sessão inativa dentro de no máximo 15 minutos. Se o sistema não permitir bloqueio de sessões, o usuário deverá ser desconectado após o período de inatividade.

b) Impor um processo de logout manual onde o equipamento de fabricação e personalização não tenha a capacidade de efetuar o logoff automático de um usuário.

7.4 Bloqueio de contas

a) As contas que estiverem inativas por um período especificado (de no máximo 90 dias) deverão ser removidas do sistema.

b) Os sistemas devem aplicar o bloqueio de uma conta de usuário após, no máximo, seis tentativas de autenticação malsucedidas.

c) As contas bloqueadas só deverão ser desbloqueadas pelo administrador de segurança. Como alternativa, as contas de usuário poderão ser desbloqueadas por meio de mecanismos automatizados de redefinição de senha. Perguntas de desafio com respostas que apenas o próprio usuário saberia responder devem ser usadas. Essas perguntas devem ser elaboradas de forma que as respostas não consistam em informações disponíveis em outro lugar da organização, como os Recursos Humanos.

d) A conta de um usuário deve ser bloqueada imediatamente após o usuário deixar o emprego do fornecedor até ser removida.

e) A conta de um usuário deve ser removida imediatamente se a senha do usuário for conhecida ou suspeita-se que foi comprometida.

f) Os registros de conta de usuário, incluindo, entre outros, os itens a seguir, devem ser revisados pelo menos duas vezes por mês para a atividade de bloqueio suspeito:

i. Acesso remoto

ii. Banco de dados

iii. Aplicativo

iv. OS



8 Gerenciamento de chave: Dados Secretos

8.1 Princípios gerais a) Deve existir uma descrição escrita da arquitetura criptográfica do fornecedor. Em particular,

ela deve detalhar todas as chaves usadas por cada HSM. A descrição da chave deve referir-se ao seu uso.

b) Os princípios de conhecimento dividido e controle duplo devem ser incluídos em todas as principais atividades do ciclo de vida envolvendo componentes essenciais para garantir a proteção das chaves. As únicas exceções a esses princípios envolvem as chaves que são gerenciadas como criptogramas ou armazenadas em um SCD.

c) A implementação eficaz desses princípios deve impor a existência de barreiras além dos controles processuais para evitar que qualquer pessoa obtenha acesso a componentes ou ações essenciais para formar a chave real.

d) Quando componentes ou ações de chave simples passam por um PC ou outro equipamento, este nunca deve estar conectado a nenhuma rede e deve ser desligado quando não estiver em uso. Esses computadores devem ser dedicados, além de reforçados e gerenciados sob controle duplo o tempo todo.

e) As chaves usadas para proteção de material de chaveamento ou outros dados sensíveis devem atender aos requisitos mínimos delineados no Apêndice A.

f) Todas as chaves de criptografia a chave usadas para transmitir ou conduzir outras chaves criptográficas devem ser pelo menos tão fortes quanto a chave que está sendo transmitida ou conduzida.

g) As chaves criptográficas não devem ser codificadas em software.

h) Devem ser mantidas trilhas de auditoria para todas as atividades de gerenciamento de chaves.

i) As atividades de gerenciamento de chaves devem ser realizadas pelo fornecedor ou pela equipe do emissor.

j) As atividades de gerenciamento de chaves só devem ser realizadas por pessoal totalmente treinado e autorizado.

k) Certificados digitais usados em conjunto com produtos ou serviços de provisionamento baseados em nuvem devem ser emitidos por uma Autoridade de Certificação (CA) confiável ou diretamente sob um provedor de aplicativo ou emissor da PKI.

l) Todas as atividades de gerenciamento de chaves devem ser documentadas e todas as atividades envolvendo componentes de chave simples devem ser registradas. O registro deve incluir:

i. Identificação exclusiva da pessoa que realizou cada função

ii. Data e hora

iii. Função

iv. Finalidade

8.2 Chaves simétricas Certifique-se de que as chaves simétricas só existam nos seguintes formulários:

a) Como texto externo dentro da memória protegida de um dispositivo criptográfico seguro

b) Como um criptograma



c) Como dois ou mais componentes de comprimento total (onde cada componente deve ter o mesmo comprimento da chave final) ou como parte de um esquema de compartilhamento “m de n” onde o valor de “m” é no mínimo 2.

i. Os principais componentes de cada guardião específico devem ser armazenados em um recipiente separado e seguro que seja acessível apenas pelo guardião e/ou backup(s) designado(s).

ii. Nenhuma pessoa deve ser capaz de acessar ou usar todos os componentes ou um quórum de compartilhamentos de uma única chave criptográfica secreta.

8.3 Chaves assimétricas

Certifique-se de que:

a) As chaves privadas existem apenas nos seguintes formulários:

i. Como texto externo dentro da memória protegida de um dispositivo criptográfico seguro

ii. Como um criptograma

iii. Como dois ou mais componentes ou como parte de um esquema de compartilhamento “m de n” onde o valor de “m” é no mínimo dois; gerenciado usando os princípios de controle duplo e conhecimento dividido

iv. Os principais componentes de cada guardião específico devem ser armazenados em um recipiente separado e seguro que seja acessível apenas pelo guardião e/ou backup(s) designado(s).

v. Nenhuma pessoa deve ser capaz de acessar ou usar todos os componentes ou um quórum de compartilhamentos de uma única chave criptográfica privada.

b) As chaves públicas devem ter sua autenticidade e integridade asseguradas. Para garantir autenticidade e integridade, a chave pública deve ser criptografada ou, se estiver em forma de texto não criptografado, deve existir apenas em uma das seguintes formas:

i. Dentro de um certificado,

ii. Dentro de um PKCS#10,

iii. Dentro de um SCD ou

iv. Com um código de autenticação de mensagem (Message Authentication Code, MAC) criado com o algoritmo definido na ISO 16609.

c) As chaves assimétricas também seguem:

i. Os requisitos do sistema de pagamento para obter o certificado do emissor

ii. A especificação do sistema de pagamento para chaves assimétricas

8.4 Administração de segurança de gerenciamento de chaves A administração segura de todas as atividades de gerenciamento de chaves desempenha um papel importante em termos de segurança lógica. Os requisitos a seguir referem-se aos procedimentos e atividades para gerenciar chaves e conjuntos de chaves.



8.4.1 Requisitos gerais a) O fornecedor deve definir procedimentos para a transferência de funções de

gerenciamento de chaves entre indivíduos.

b) Todos os equipamentos físicos associados à atividade de gerenciamento de chaves, como chaves físicas, códigos de autenticação, smart cards e outros facilitadores de dispositivo assim como equipamentos além de computadores pessoais devem ser gerenciados seguindo o princípio de controle duplo.

8.4.2 Gerente de chave a) Deve haver um gerente de chave indicado com responsabilidade geral para todas

as atividades relacionadas ao gerenciamento de chaves.

b) O CISO deve aprovar o gerente de chave para a posição dentro do fornecedor. c) O gerente de chave deve:

i. Ter um representante indicado.

ii. Ser responsável por garantir que toda a atividade de gerenciamento de chaves seja totalmente documentada.

iii. Ser responsável por garantir que toda a atividade de gerenciamento de chaves seja realizada de acordo com os procedimentos documentados.

iv. Em colaboração com o departamento de pessoal, examinar todos os responsáveis pela chave para assegurar sua adequação à função.

v. Ser funcionário do fornecedor

d) O gerente da chave deve ser informado imediatamente sobre qualquer violação de segurança ou perda de integridade relacionada às atividades da chave.

e) O gerente da chave deve ser responsável por garantir que:

i. Todos os guardiões de chave foram treinados nas suas responsabilidades, e isso faz parte do treinamento anual de segurança.

ii. Cada custodiante assina uma declaração, ou é legalmente obrigado, reconhecendo que entende suas responsabilidades.

iii. Os responsáveis pela chave que formam o limite necessário para criar uma chave não devem se reportar diretamente ao mesmo gerente. Se o gerente de chave também for um guardião de chave, outros responsáveis pela chave não devem se reportar ao gerente de chave se, junto com o gerente de chave, formassem um limiar para criar uma chave.

f) O gerente de chave não deve ter o direito de substituir operações dos responsáveis pela chave ou realizar atividades para outros guardiões de chaves.

8.4.3 Principais custodiantes a) As funções e responsabilidades dos guardiões de chaves devem ser totalmente

documentadas em um nível suficiente para permitir o desempenho das atividades necessárias, passo a passo.

b) A identidade dos guardiões individuais deve ficar restrita à necessidade e não pode ser disponibilizada em documentação geralmente visível.



Durante a operação, o HSM deve utilizar um algoritmo de segurança que cumpra os requisitos do sistema de pagamento conforme definido no Apêndice A.

c) A adequação do pessoal deve ser revisada anualmente.

d) Eles devem ser funcionários do fornecedor e nunca funcionários ou consultores temporários.

e) Eles devem receber uma lista de responsabilidades e assinar uma declaração confirmando suas responsabilidades para proteger os principais componentes, ações ou outros materiais de chaveamento confiados a eles.

f) Apenas os guardiões de chaves totalmente treinados e seus backups podem participar de atividades de gerenciamento de chaves.

g) Devem existir barreiras físicas para garantir que nenhum custodiante de chave tenha acesso a componentes ou compartilhamentos suficientes para formar a chave simples.

8.4.4 PINs de dispositivo de gerenciamento de chaves Em relação a PINs e senhas usadas com dispositivos de gerenciamento de chaves:

a) Se os PINs ou as senhas forem armazenados, uma cópia de qualquer PIN ou senhas, usados para acessar qualquer dispositivo necessário a qualquer atividade de gerenciamento de chaves, devem ser armazenados com segurança (para possibilitar sua recuperação).

b) Apenas as pessoas que precisam de acesso a um dispositivo devem ter acesso ao PIN ou à senha desse dispositivo.

c) Deve haver uma política definida para PINs e senhas necessários para acessar dispositivos de gerenciamento de chaves. Esta política deve incluir o comprimento e a combinação de caracteres de tais PINs e senhas e a frequência de mudança.

d) Todos os equipamentos associados à atividade de gerenciamento de chaves, como chaves de latão e smart cards, não devem ser controlados ou estar com pessoas que possam usar esses tokens para permitir a atividade de gerenciamento de chaves sob controle único. Esses tokens devem ser protegidos de forma semelhante aos componentes principais, incluindo o uso de registros de controle de acesso quando removidos ou colocados em armazenamento seguro.

8.5 Geração de chave

a) Gere chaves e chaves de componentes usando um processo aleatório ou pseudo-aleatório (conforme descrito na ISO 9564-1 e ISO 11568-5) que seja capaz de satisfazer os testes estatísticos do National Institute of Standards and Technology (NIST) PUB 800-22.

b) A geração de chaves deve ocorrer em um módulo de segurança de hardware (HSM) que atingiu a aprovação PCI ou a certificação FIPS 140-2 Nível 3 ou superior para segurança física.

c) Os cabos devem ser inspecionados para garantir que não seja possível divulgar uma chave não criptografada ou componente ou compartilhamento de chave.

d) Use os princípios de conhecimento dividido e controle duplo durante a geração de quaisquer chaves criptográficas no componente ou no formulário de compartilhamento.



e) Os componentes de chave, se impressos, devem ser criados de tal forma que não permita

compactação ou observação durante o processo por outro que não o custodiante da chave autorizada. Além disso, os principais componentes não podem ser observados nos documentos finais sem evidência de adulteração.

f) Destruir imediatamente qualquer resíduo do processo de impressão ou geração que possa revelar um componente para que uma pessoa não autorizada não possa obtê-lo.

g) Certifique-se de que uma chave gerada não seja a qualquer momento observável ou acessível de outra forma em texto por qualquer pessoa durante o processo de geração.

h) Os componentes ou ações principais devem ser colocados em envelopes pré-serializados e invioláveis quando não estiverem em uso pelo custodiante da chave autorizado.

8.5.1 Transações de chaves assimétricas usadas para pagamento a) Adote o algoritmo de chave pública e garanta que o comprimento dos pares de

chaves RSA do emissor usados para processamento de transações de pagamento esteja de acordo com os requisitos do sistema de pagamento.

b) Assegure que a geração de pares de chaves assimétricas garanta o segredo da chave privada e a integridade da chave pública.

c) Crie e gerencie chaves assimétricas em conformidade com os requisitos do sistema de pagamento para obter o certificado do emissor.

8.6 Distribuição da chave

a) As chaves devem ser distribuídas apenas em seus formulários permitidos. b) Quando transmitidos eletronicamente, as chaves e os principais componentes ou

compartilhamentos devem ser criptografados antes da transmissão, seguindo todos os requisitos de gerenciamento de chaves documentados nesta seção.

c) Certifique-se de que componentes ou compartilhamentos de chaves privadas ou secretas e dados de digitação que sejam enviados como texto externo atendam aos seguintes requisitos:

i. Use diferentes canais de comunicação, como serviços de courier diferentes. Não é suficiente enviar componentes ou compartilhamentos essenciais para uma chave específica em dias diferentes usando o mesmo canal de comunicação.

ii. Um formulário de duas partes que identifica o remetente e os materiais enviados deve acompanhar os dados digitados.

iii. O formulário deve ser assinado pelo remetente e exigir que o destinatário devolva uma parte do formulário ao originador.

iv. Os principais componentes ou compartilhamentos devem ser colocados em envelopes pré-serializados e invioláveis para envio.

d) Os principais componentes ou ações devem ser recebidos apenas pelo responsável autorizado, que deve:

i. Inspecionar e garantir que nenhum tenha sido adulterado com o pacote de remessa. Se houver sinais de adulteração, considere a chave comprometida e siga o documento de procedimentos de comprometimento de chave do fornecedor.



ii. Verifique o conteúdo do pacote com o formulário em duas partes anexado.

iii. Devolva uma parte do formulário ao remetente do componente ou compartilhe, confirmando o recebimento.

iv. Armazenar o componente ou compartilhar de acordo com a política de armazenamento de chaves do fornecedor.

e) Antes que as entidades aceitem um certificado, elas devem garantir que conhecem sua origem e usar os métodos projetados para validar o status do certificado. Isso inclui o período válido de uso e o status de revogação, se disponível.

8.7 Carregamento da chave

Os requisitos a seguir referem-se ao carregamento de componentes/compartilhamentos de chave criptográfica de texto simples em HSMs:

a) Qualquer hardware usado na função de carregamento de chaves deve ser dedicado, controlado e mantido em um ambiente seguro sob controle duplo. Em vigor a partir de janeiro de 2018, todos os dispositivos de carregamento recém-implantados devem ser SCDs, aprovados pelo PCI ou com certificação FIPS 140-2 Nível 3 ou superior para segurança física.

b) Antes de carregar chaves (ou componentes/compartilhamentos), os dispositivos criptográficos, cabeamento e componentes de papel alvo devem ser inspecionados quanto a qualquer sinal de violação que possa revelar o valor da chave transferida (ou componentes/compartilhamentos).

c) Tokens, PROMs ou outros mecanismos de componente/ações importantes usados para carregar chaves (ou componentes/compartilhamentos essenciais) devem estar apenas na posse física do custodiante designado (ou seu backup) e apenas pelo tempo mínimo prático.

d) Em relação aos principais dispositivos de transferência:

i. Qualquer dispositivo usado para transferir chaves entre o dispositivo criptográfico que gerou a(s) chave(s) e os dispositivos criptográficos que usarão essas chaves, deve ser um dispositivo criptográfico seguro.

ii. Após carregar uma chave ou componentes de chave no dispositivo de destino, o dispositivo de transferência principal não deve reter nenhuma informação residual que possa revelar o valor do material de chaveamento transferido.

e) Todas as principais atividades de carregamento devem estar sob o controle do gerente de chave.

f) Controlar e manter qualquer token, memória somente leitura programável apagável eletronicamente (Electronically Erasable Programmable Read-Only Memory, EEPROM), chaves físicas ou outros dispositivos de componente/compartilhamento de chave usados para carregar chaves em um ambiente seguro sob controle duplo.

g) Certifique-se de que o processo de carregamento de chaves não divulgue qualquer parte de um componente/compartilhamento de chave a pessoa não autorizada.

h) Se o componente/compartilhamento de chave estiver em forma legível por humanos, certifique-se de que ele esteja visível apenas em um ponto no tempo até o custodiante da chave e somente durante o tempo necessário para carregar a chave.



i) No carregamento de chaves ou componentes/compartilhamentos de chave, incorpore um

mecanismo de validação para garantir a autenticidade das chaves e certifique-se de que não foram adulteradas, substituídas ou comprometidas. Se usado para este fim, os valores de verificação da chave e de componentes de chave não devem ser o comprimento total da chave ou seus componentes. A validação deve ser realizada sob controle duplo. O resultado do processo (com ou sem sucesso) deve ser relatado ao gerente de chave.

j) Quando a chave ou seus componentes/compartilhamentos tiverem sido carregados e validados como operacionais:

i. Destrua ou exclua com segurança os materiais de carregamento de chaves, conforme definido na Seção 8.11, “Destruição de chaves”; ou

ii. Armazene-as com segurança de acordo com esses requisitos se estiver preservando as chaves ou componentes/compartilhamentos para carregamento futuro.

8.8 Armazenamento da chave

Os requisitos a seguir referem-se ao armazenamento seguro de chaves secretas, chaves privadas e seus componentes ou compartilhamentos de chaves.

a) Os componentes/compartilhamentos de chave devem ser armazenados em envelopes pré-serializados e invioláveis em locais separados e seguros (como, por exemplo, cofres).

b) Esses envelopes não podem ser removíveis sem detecção.

c) Deve-se manter e auditar um inventário do conteúdo dos cofres de armazenamento de chaves a cada trimestre.

d) Quando um componente/compartilhamento de chave secreta ou privada for armazenado em um token (por exemplo, um cartão de circuito integrado) e um código de acesso (por exemplo, um número de identificação pessoal (PIN)) ou um mecanismo de controle de acesso similar é usado para acessar aquele token que o proprietário do tom (ou designado) deve ter permissão de posse do token e seu código de acesso correspondente.

e) Certifique-se de que os registros de acesso incluem, no mínimo, o seguinte:

i. Data e hora (entrada/saída)

ii. Nomes e assinaturas dos principais custodiantes envolvidos

iii. Finalidade do acesso

iv. Número de série do envelope (entrada/saída) f) Mantenha os registros de acesso e destruição para chaves mestre até que os cartões usando

chaves protegidas por essas chaves mestras não estejam mais em circulação.

8.9 Uso da chave a) Cada chave deve ser usada apenas para uma finalidade e não compartilhada entre

sistemas de pagamento, emissores ou zonas criptográficas, por exemplo:

i. As chaves privadas devem ser usadas apenas para criar assinaturas digitais OU para realizar operações de descriptografia. Chaves privadas nunca devem ser usadas para criptografar outras chaves.



ii. O uso das chaves de assinatura RSA (privadas) deve ser proibido para a criptografia de

dados ou de outra chave, e o uso das chaves de criptografia RSA (pública) de forma semelhante deve ser proibido.

iii. As chaves públicas devem ser usadas apenas para verificar a assinatura digital OU executar operações de criptografia.

iv. As chaves de criptografia de chaves nunca devem ser usadas como chaves de trabalho (chaves de sessão) e vice-versa.

b) As chaves de transporte usadas para criptografar outras chaves para transporte (por exemplo, KEK, ZCMK) devem ser exclusivas por zona de chave estabelecida e, opcionalmente, exclusivas por emissor dentro dessa zona. Essas chaves só devem ser compartilhadas entre as duas entidades de comunicação e não devem ser compartilhadas com nenhuma organização de terceiros.

c) O HSM deve aplicar uma separação de chaves para evitar que sejam usadas para fins diferentes daqueles para os quais foram destinados.

d) Todas as chaves secretas e privadas devem ter uma data de validade predefinida, portanto devem ser retiradas do uso. Nenhuma chave deve ser usada por um período maior do que a vida útil designada para ela. As chaves do emissor não devem ser usadas por mais tempo do que a data de validade especificada pelo emissor.

e) Não deve haver processo que, uma vez implantado, faça com que a vida útil de uma chave possa ser estendida além de sua vida útil originalmente designada.

f) O fornecedor deve:

i. Proibir que as chaves sejam compartilhadas ou substituídas entre os sistemas de produção e teste.

ii. Proibir o uso das chaves usadas para pilotos (ou seja, produção limitada) por exemplo, por meio de tempo, capacidades ou volume) para a implantação completa do produto, a menos que as chaves tenham sido gerenciadas para o mesmo nível de conformidade de segurança necessário para a produção.

iii. Certifique-se de que as chaves usadas para prototipagem (ou seja, usando cartões para prova de conceito ou processo onde as chaves de produção não forem usadas) não sejam usadas na produção.

iv. Certifique-se de que a vida útil das chaves usadas para criptografar outras chaves seja menor do que o tempo necessário para realizar uma busca exaustiva do espaço principal. Apenas algoritmos e comprimentos de chave estipulados no Anexo Normativo A deste documento serão permitidos.

v. Certifique-se de que existam chaves privadas e secretas no número mínimo de locais compatíveis com a operação efetiva do sistema.

vi. Não use as principais variantes, exceto dentro do dispositivo com a chave original.

vii. Use apenas chaves privadas para decifrar ou criar assinaturas digitais; chaves públicas só devem ser usadas para cifrar ou verificar assinaturas.

viii. Mantenha um inventário de chaves sob sua gestão para determinar quando uma chave não é mais necessária; por exemplo, poderia incluir etiqueta/nome, data de entrada em vigor, data de validade, finalidade/tipo chave, comprimento de chave, etc.

g) Todas as chaves de derivação devem ser exclusivas por emissor.

h) As chaves IC devem ser exclusivas para IC.

i) As chaves de transporte usadas para provisionamento móvel devem ser exclusivas por dispositivo.



8.10 Backup/Recuperação da chave

Não é necessário ter cópias de backup de componentes, compartilhamento ou chaves da chave. No entanto, se forem usadas cópias de reserva, é preciso atender aos requisitos abaixo:

a) Garantir que o backup e a recuperação da chave façam parte dos planos de recuperação/retomada de negócios da organização.

b) Exigir no mínimo duas pessoas autorizadas para permitir a recuperação das chaves.

c) Todas as políticas e procedimentos relevantes que se aplicam às chaves de produção também devem se aplicar às chaves de reserva.

d) O fornecedor deve proibir o carregamento de chaves de reserva em um dispositivo defeituoso até a confirmação do motivo da falha e a correção do problema.

e) O backup das chaves deve cumprir a Política de Segurança da Informação.

f) Todo o acesso aos locais de armazenamento de backup deve ser testemunhado e registrado sob controle duplo.

8.11 Destruição da chave

Os seguintes requisitos relacionados à destruição de chaves simples, componentes e compartilhamentos devem ser atendidos:

a) Destruir imediatamente os componentes/compartilhamentos de chave que não são mais necessários após o carregamento e a validação bem-sucedidos como operacionais.

b) Quando um dispositivo criptográfico (por exemplo, HSM) é desativado, quaisquer dados armazenados e quaisquer chaves criptográficas residentes devem ser excluídos ou então destruídos.

c) Destruir com segurança todas as cópias de chaves que não são mais necessárias para a produção ou provisionamento de cartões.

d) Todo processo de destruição de chaves deve ser registrado e o registro deve ser mantido para verificação.

e) Destruir chaves e componentes/compartilhamentos de chaves para que não seja possível recuperá-los por meios físicos ou eletrônicos.

f) Se uma chave que reside dentro de um HSM não puder ser destruída, o próprio dispositivo deve ser destruído de forma a garantir que seja irrecuperável.

g) Destrua todos os componentes/compartilhamentos de chave impressa mantidos em papel por meio de combustão, redução a pasta ou trituramento. Não é suficiente triturar.

h) As chaves armazenadas eletronicamente devem ser sobrescritas com dados aleatórios no mínimo três vezes ou destruídas por esmagamento para que não possam ser remontadas.

i) Destrua todos os componentes da chave sob presença dupla com declarações apropriadas de sua destruição assinadas pelo respectivo custodiante de chave.

j) Uma pessoa que não seja um guardião de chave para qualquer parte dessa chave deve testemunhar a destruição e também assinar as declarações de destruição de chaves, que são mantidas indefinidamente. (Esta pessoa também pode cumprir a exigência de presença dupla acima mencionada ou ser uma terceira pessoa para a atividade.)



8.12 Trilha de auditoria de gerenciamento de chaves

a) Os registros de gerenciamento de chaves devem conter, no mínimo, para cada atividade registrada:

i. A data e a hora em que a atividade ocorreu

ii. A medida tomada (por exemplo, se foi geração de chaves, distribuição de chaves ou destruição de chaves)

iii. Nome e assinatura da pessoa que realiza a medida (pode ser mais de um nome e assinatura se a responsabilidade for dividida)

iv. Assinatura do gerente de chave ou CISO

v. Número de envelope principal pré-serializado, se aplicável

b) Os registros de gerenciamento de chaves devem ser retidos pelo menos durante a vida das chaves às quais se relacionam.

c) O fornecedor deve proibir o acesso aos registros de gerenciamento de chaves por qualquer pessoal fora do gerente de chave ou pessoas autorizadas.

d) Qualquer instalação para redefinir o gerador de número de sequência ou outros mecanismos como carimbos de data e hora no HSM deve ser restrita.

e) O CISO ou um indivíduo autorizado deve investigar todas as falhas de validação do registro de auditoria.

f) Durante o processo de personalização, deve ser mantido um registro eletrônico para identificar quais chaves foram usadas.

g) O fornecedor deve garantir que a exclusão de qualquer trilha de auditoria seja impedida.

8.13 Comprometimento da chave Os requisitos a seguir referem-se aos procedimentos para lidar com qualquer comprometimento de chave conhecido ou suspeito. A menos que seja estabelecido de outra forma, às chaves de propriedade do fornecedor são aplicáveis as seguintes regras:

a) O fornecedor deve definir procedimentos que incluam o seguinte:

i. Quem deve ser notificado no caso de um comprometimento importante? No mínimo, isso deve incluir o CISO, o gerente de chave, o gerente de segurança de TI e o VPA

ii. As medidas a serem tomadas para proteger e/ou recuperar software e/ou hardware do sistema, chaves simétricas e assimétricas, assinaturas geradas anteriormente e dados criptografados

iii. Uma investigação sobre a causa do comprometimento, incluindo uma análise documentada de como e por que o evento ocorreu e os danos sofridos.

iv. Que o fornecedor removerá do uso operacional todas as chaves comprometidas dentro de um período predefinido e fornecerá um meio de migrar para novas chaves.

v. Quando as chaves forem de propriedade do emissor, este deve ser notificado imediatamente para mais instruções.

b) Certifique-se de que a chave de substituição não seja uma variante da chave comprometida.



c) Quando houver suspeita de um comprometimento importante, mas ainda não

comprovado, o gerente da chave deve ter a capacidade de ativar os procedimentos de substituição da chave de emergência.

d) Em caso de comprometimento de chave conhecido ou suspeito, todas as instâncias da chave devem ser imediatamente revogadas, dependendo do resultado da investigação. Chaves comprometidas conhecidas devem ser substituídas.

e) Todas as chaves criptografadas com uma chave que foi revogada também devem ser revogadas.

f) Caso uma KEK tenha sido comprometido, todas as chaves criptografadas com a KEK devem ser substituídas.

g) Caso um MDK tenha sido comprometido, todas as chaves derivadas daquela chave mestre devem ser substituídas.

h) O VPA do sistema de pagamento deve ser notificado dentro de 24 horas a partir de um comprometimento conhecido ou suspeito.

i) Os itens de dados que foram assinados usando uma chave que foi revogada (por exemplo, um certificado de chave pública) devem ser retirados assim que possível e substituídos quando uma nova chave for habilitada.

8.14 Hardware de segurança de gerenciamento de chaves

a) Todas as atividades de gerenciamento de chaves devem ser realizadas usando-se um HSM.

b) Quando em seu estado operacional normal:

i. Todos os mecanismos responsivos a violações de HSM devem ser ativados. ii. Todas as chaves físicas devem ser removidas. iii. Todos os dispositivos desnecessários conectados externamente devem ser

removidos (como um terminal do operador).

c) Os HSms usados para gerenciamento de chaves ou usados para a proteção de dados confidenciais devem ser aprovados pelo PCI ou certificados para FIPS 140-2 Nível 3, ou superior.

d) Os HSMs devem ser colocados em serviço somente se houver garantia de que o equipamento não esteja sujeito a modificação, substituição ou adulteração não autorizada. Isso requer proteção física do dispositivo até o ponto de inserção ou inspeção de chave.

e) O processo de instalação e comissionamento do HSM deve ser documentado e registrado.

f) Quando um HSM é retirado de serviço permanentemente ou para reparo, todas as chaves operacionais devem ser excluídas do dispositivo antes da sua remoção.

g) O processo de remoção para o reparo ou descomissionamento do HSM deve ser documentado e registrado.

h) O HSM deve estar sob controle físico duplo o tempo todo.



9 Gerenciamento de chave: Dados Confidenciais 9.1 Princípios gerais

a) As chaves de criptografia de chaves devem atender aos tamanhos mínimos, conforme delineado no Anexo Normativo A.

b) Todas as chaves de criptografia a chave usadas para transmitir ou conduzir outras chaves criptográficas devem ser pelo menos tão fortes quanto a chave que está sendo transmitida ou conduzida.

c) As chaves criptográficas não devem ser codificadas em software.

d) Devem ser mantidas trilhas de auditoria para todas as atividades de gerenciamento de chaves.

e) As atividades de gerenciamento de chaves devem ser realizadas pelo fornecedor ou pela equipe do emissor.

f) As atividades de gerenciamento de chaves só devem ser realizadas por pessoal totalmente treinado e autorizado.

g) O fornecedor deve gerar chaves e componentes de chave usando um processo aleatório ou pseudo-aleatório.

h) Antes que o fornecedor aceite uma chave, ele deve ter certeza de sua origem.

i) As chaves devem ser armazenadas de forma a preservar sua integridade.

j) As chaves devem ser usadas apenas para um propósito e não compartilhadas entre zonas criptográficas.

k) Todas as chaves secretas e privadas devem ter uma data de validade predefinida, portanto devem ser retiradas do uso. Nenhuma chave deve ser usada por um período maior do que a vida útil designada para ela. As chaves do emissor não devem ser usadas por mais tempo do que a data de validade especificada pelo emissor.

l) Não deve haver processo que, uma vez implantado, faça com que a vida útil de uma chave possa ser estendida além de sua vida útil originalmente designada.

m) O fornecedor deve proibir que as chaves sejam compartilhadas ou substituídas entre os sistemas de produção e teste.

n) O fornecedor deve ter certeza de que a vida útil das chaves usadas para criptografar outras chaves é menor do que o tempo necessário para realizar uma busca exaustiva do espaço da chave.

o) O fornecedor deve garantir que existam chaves no número mínimo de locais compatíveis com a operação efetiva do sistema.

p) O fornecedor deve garantir que as chaves estejam acessíveis apenas ao número mínimo de pessoas necessárias para a operação efetiva do sistema.

q) O fornecedor deve ter um processo documentado para lidar com um comprometimento da chave conhecido ou suspeito que inclua a revogação da chave.

r) No caso do comprometimento de uma chave, todas as instâncias da chave devem ser revogadas.

s) Todas as chaves criptografadas com uma chave que foi revogada também devem ser revogadas.

t) Caso uma KEK tenha sido comprometido, todas as chaves criptografadas com essa KEK devem ser substituídas.



10 Distribuição de PIN via métodos eletrônicos

10.1 Requisitos gerais Os seguintes requisitos se aplicam para a distribuição de PINs via métodos eletrônicos:

a) O sistema de distribuição de PIN não deve se comunicar com nenhum outro sistema onde os dados associados ao titular do cartão sejam armazenados ou processados.

b) O sistema de distribuição de PIN deve ser executado em um computador dedicado e ser isolado de qualquer outra rede por um firewall dedicado.

c) O sistema de distribuição de PIN não deve executar nenhuma outra função além da distribuição do PIN e qualquer sessão estabelecida durante a distribuição (por exemplo, uma chamada telefônica, um e-mail ou uma mensagem SMS) deve ser encerrada assim que o PIN tiver sido enviado.

d) Durante a transmissão e o armazenamento no sistema de distribuição de PIN, todos os valores de PIN e autenticação devem ser criptografados usando-se algoritmos e tamanhos de chave conforme indicado no Anexo Normativo A.

e) A comunicação do PIN ao titular do cartão só deve ocorrer após a verificação do valor de identificação e do valor de autenticação associado.

f) Os valores de identificação e autenticação não devem revelar o número da conta.

g) O valor de autenticação deve ser diferente do valor de identificação e não deve ser facilmente associado ao titular do cartão.

h) O valor de autenticação deve ser comunicado ao titular do cartão de tal forma que o acesso por qualquer pessoa diferente seja detectado.

i) O valor de autenticação deve ser restrito ao sistema de distribuição de PIN e não pode ser acessado por nenhum outro sistema.

j) O PIN só deve ser distribuído em resposta ao recebimento de valores válidos de identificação e autenticação.

k) O sistema de distribuição de PIN deve ser capaz de identificar o titular do cartão a partir do valor de identificação na solicitação e a solicitação deve conter o valor de autenticação do titular do cartão.

l) O sistema de distribuição não deve ter qualquer forma de associar um valor de identificação ou valor de autenticação com o nome, endereço ou número de conta de um titular de cartão específico.

m) O sistema de distribuição de PIN deve limitar o número de tentativas para obter um PIN e após exceder este limite deve alertar o fornecedor para que tome mais medidas, conforme definido pelo emissor.

n) O PIN só deve ser descriptografado imediatamente antes de ser passado para o canal de distribuição final (por exemplo, o telefone ou sistema de e-mail).

o) O sistema de distribuição de PIN não deve conter nenhum outro dado do titular do cartão (por exemplo, PAN, nome do titular do cartão).

p) A associação do PIN a uma conta específica no sistema de distribuição não deve ser possível.

q) O valor de identificação, o PIN e o valor de autenticação não devem ser registrados e sim excluídos imediatamente após a confirmação da entrega bem-sucedida.

r) Se o PIN não for entregue ao titular do cartão, ele deve ser excluído do sistema após um período fixo, que pode ser designado pelo emissor.



Anexo A: Aplicação de requisitos

Requisitos de segurança lógica

Requisito

Cartões físicos Provisionamento

móvel

Condições SE HCE

Seção 2 Funções e responsabilidades

Todas X X X Todos os requisitos aplicáveis

Seção 3 Política e procedimentos de segurança


Seção 4 Segurança de dados

4.1 X X X

4.2 X X X

4.3 X X X

4.4 X X X

4.5 X X X

4.6 X X X

4.7 X

4.8 X X X

4.9 X X

Seção 5 Segurança de rede


Seção 6 Segurança do sistema

6.1 X X X

6.2 X X X

6.3 X X X

6.4 X X X

6.5 X X

6.6 X X X

6.7 X X

6.8 X X X



Requisitos de segurança lógica

Requisito

Cartões físicos Provisionamento

móvel

Condições SE HCE

Seção 7 Gerenciamento de usuário e controle de acesso ao sistema


Seção 8 Gerenciamento de chaves: Dados Secretos


Seção 9 Gerenciamento de chaves: Dados Confidenciais


Seção 10 Distribuição de PIN via métodos eletrônicos




Firewall

Emissor/ Fonte de

dados

Apêndice B: Exemplos de topologia Exemplo B1

FORNECEDOR

Preparação de dados

Personalização de

cartão

Firewall Firewall

Outra(s) rede(s) de fornecedor(es)



Exemplo B2

FORNECEDOR

Rede externa

(DMZ)

Firewall

Preparação e cartão de dados Personalização

Emissor/ Fonte de

dados

Firewall

Outra(s) rede(s) de

fornecedor(es)



Exemplo B3

FORNECEDOR


Firewall

Firewall

HCE Provisionamento

Cartão

Firewall

Internet

Firewall

Outra(s) rede(s) de

fornecedor (es)



Exemplo B4

FORNECEDOR

Outra(s) rede(s) de

fornecedor(es)

Firewall

Firewall

Preparação e cartão de dados Personalização

Emissor/ Fonte de

dados

Rede voltada para a Internet

(DMZ)

Firewall

HCE Provisiona

Exemplo B5



FORNECEDOR

L Voltada para a internet

Rede (DMZ)

Firewall

Personalização de cartão


Emissor/Fonte de dados

Firewall

Outra(s) rede(s) de

fornecedor(es)



Exemplo B6

FORNECEDOR

- c


HCE Provisionamento

- - I

I Rede voltada

para a Internet (DMZ)

Firewall

Outra(s) rede(s) de

fornecedor(es)

Firewall

Personalização de cartão



Exemplo B7

FORNECEDOR

Rede voltada para a Internet

(DMZ)

Firewall

Preparação de dados: Personalização de cartão , e provisionamento OTA

Provisionamento de HCE

Internet

Firewall



■ 1 --■

Exemplo B8

FORNECEDOR OTA

Firewall

Rede voltada para o exterior

(DMZ)

,

., . _ --·

HCE Provisionamento

Firewall

Cart

I

Personalização Preparação de dados

Emissor/ Fonte de

dados

Internet

Firewall

Outra(s) rede(s) de

fornecedor (es)



Anexo Normativo A: Tamanhos e pontos fortes mínimos e de equipamentos para algoritmos aprovados

A seguir estão os principais tamanhos e parâmetros de chave para o(s) algoritmo(s) em questão que deve(m) ser usado(s) em conexão com o transporte, troca ou estabelecimento de chaves e para proteção de dados:

Algoritmo

DES

RSA

Curva elíptica

DSA

AES

Tamanho mínimo da chave no número de bits:

112 1024 160 1024/160 128

As chaves de criptografia de chaves devem ter força pelo menos igual ou maior do que qualquer chave que estejam protegendo. Isso se aplica a todas as chaves de criptografia de chaves usadas para a proteção de chaves secretas ou privadas que são armazenadas ou chaves usadas para criptografar qualquer chave secreta ou privada para carregamento ou transporte. Para fins desta exigência, os algoritmos e tamanhos de chaves por linha a seguir são considerados equivalentes.

Algoritmo

DES

RSA

Curva elíptica

DSA/D-H

AES


112 1024 160 1024/160


168 2048 224 2048/224


3072 256 3072/256 128


7680 384 7680/384 192


15360 512 15360/512 256

DES refere-se a chaves TDES com bits sem paridade. O tamanho da chave RSA refere-se ao tamanho do módulo. O tamanho da chave da curva elíptica refere-se à ordem mínima do ponto base na curva elíptica; esta ordem deve ser ligeiramente menor do que o tamanho do campo. Os tamanhos de chave DSA referem-se ao tamanho do módulo e ao tamanho mínimo de um grande subgrupo.

Para implementações de Diffie-Hellman:

As entidades devem gerar e distribuir com segurança os parâmetros de todo o sistema: gerador g, número principal p e parâmetro q, o grande fator principal de (p - 1). O parâmetro p deve ter pelo menos 2048 bits de comprimento e o parâmetro q deve ter pelo menos 224 bits de comprimento. Cada entidade deve gerar uma chave privada x e uma chave pública y usando os parâmetros de domínio (p, q, g,). Cada chave privada deve ser estatisticamente única, imprevisível e criada usando um gerador de número aleatório aprovado, conforme descrito neste documento.

As entidades devem autenticar as chaves públicas Diffie-Hellman usando DSA, um certificado ou MAC simétrico (com base no TDES) ver ISO 16609 Bancário Requisitos para autenticação de mensagens usando técnicas simétricas; O método 3 deve ser usado).



Glossário de acrônimos e termos

Acrônimos

Acrônimo Termo Acrônimo Termo

ANSI American National Standards Institute IVR Resposta de voz interativa

AP Ponto de acesso KEK Chave de criptografia de chave



Termos

Termo Definição Acesso remoto Acesso a uma rede específica de uma rede diferente.

Administrador do Programa de Fornecedores (Vendor Program Administrator, VPA)

Pessoa ou equipe de contato do sistema de pagamento que gerencia a conformidade dos fornecedores com os requisitos de segurança definidos neste documento.

Agência Um fornecedor que executa a personalização de cartões e/ou preparação de dados.

Aleatório O processo de gerar valores com um alto nível de entropia e que satisfaça várias qualificações, usando meios criptográficos e baseados em hardware.

Arquivo de personalização

Um arquivo criado pelo emissor ou pelo processador do emissor que tem todas as informações necessárias para personalizar um cartão.

Assimétrico

Na criptografia, “assimétrica” implica o uso de duas chaves diferentes: uma chave pública e uma chave privada.

Autenticação Um processo criptográfico que valida a fonte e a integridade dos dados. Exemplos incluem Autenticação dinâmica de dados, Autenticação de dados estáticos, Autenticação de cartão on-line e Autenticação de emissor on-line.

Autoridade certificadora

Uma administração central confiável que emite e revoga certificados de acordo com uma política anunciada e está disposta a garantir as identidades daqueles a quem emite certificados e sua associação com uma determinada chave.

Autoridade de Certificação Confiável (CA)

Um CA comercial ou um PKI operado pelo fornecedor. Se o PKI for operado pelo fornecedor, o CA deve ter sido validado para cumprir um padrão do setor, como ETSI TS 101 456: Assinaturas e infraestruturas eletrônicas (ESI); requisitos da política para autoridades de certificação que emitem autoridades qualificadas.

Cartão com chip

Cartão ou dispositivo com um circuito ou chip integrado que transmite informações a um terminal de ponto de transação. Cartões com chip oferecem mais recursos graças à combinação do significativo poder de computação e grande armazenamento de dados.

Chave da sessão

Uma chave estabelecida por um protocolo de gerenciamento de chaves, que fornece serviços de segurança aos dados transferidos entre as partes. Uma única execução de protocolo pode estabelecer várias chaves de sessão por exemplo, uma chave de criptografia e uma chave MAC.

Chave de arquivo mestre (MFK)

Esta é uma chave simétrica usada para criptografar outras chaves criptográficas que devem ser armazenadas fora do módulo de segurança de hardware (HSM).

Chave de criptografia Um valor usado em um algoritmo criptográfico para criptografia ou descriptografia.

Chave de derivação principal (MDK)

Chave mestre usada para derivar as chaves usadas para o processamento associado com autenticação de cartão, autenticação de emissor e processamento de disputa.



Termo Definição

Chave de trabalho Uma chave usada para processar criptograficamente a transação. Uma chave de trabalho é às vezes chamada de chave de dados, chave de comunicação, chave de sessão ou chave de transação.

Chave de troca de chave (KEK)

Chave usada para criptografar e descriptografar outras chaves durante o transporte entre entidades em uma zona da chave ou dentro de uma determinada entidade. Também pode ser usada para armazenamento local de chaves. Também conhecida como chave de criptografia ou chave de criptografia.

Chave Mestra de Controle de Zona

Uma chave de criptografia de chave usada para criptografar outras chaves transmitidas entre nós em uma zona da chave.

Chave mestre local (LMK) Ver Chave de arquivo mestre.

Chave privada

Uma chave criptográfica, usada com um algoritmo criptográfico de chave pública, que está exclusivamente associada a uma entidade e não é pública. No caso de um sistema de assinatura assimétrica, a chave privada define a transformação da assinatura. No caso de um sistema de criptografia assimétrico, a chave privada define a transformação de decifração.

Chave pública

Uma chave criptográfica, usada com um algoritmo criptográfico de chave pública, exclusivamente associada a uma entidade, e que pode ser tornada pública. No caso de um sistema de assinatura assimétrica, a chave pública define a transformação de verificação. No caso de um sistema de diferenciação assimétrica, a chave pública define a transformação de diferenciação. Uma chave que é “conhecida publicamente” não está necessariamente disponível globalmente. A chave só estará disponível para todos os membros de um grupo pré-especificado.

Chave secreta

Uma chave criptográfica, usada com um algoritmo criptográfico de chave secreta que está exclusivamente associado a uma ou mais entidades e não deve ser tornada pública. Um algoritmo criptográfico de chave secreta (simétrico) usa uma única chave secreta para criptografia e descriptografia. O uso do termo “secreta” não implica um nível de classificação; ao invés disso, o termo implica a necessidade de proteger a chave de divulgação ou substituição.

Chaves de aplicativo Chaves usadas pelo aplicativo do emissor. As chaves de aplicativo incluem o MDK e as chaves que podem ser derivadas do MDK a ser carregado nas fichas durante a personalização.

Chaves de personalização

As chaves (carregadas no chip durante a pré-personalização) são usadas para fornecer autenticação e confidencialidade durante a personalização e para bloquear e desbloquear o chip antes e depois da personalização. As chaves são derivadas das Chaves Mestre do emissor. As chaves mestras podem pertencer ao emissor ou ao fornecedor.

Chip O circuito integrado embutido em um cartão plástico projetado para executar funções de processamento ou memória. Consulte também Cartão com chip.



Termo Definição

Chip/circuito integrado Um cartão ou dispositivo incorporado com um chip de circuito integrado que comunica informações a um terminal de ponto de transação.

Chip/circuito integrado Um componente eletrônico projetado para executar funções de processamento ou memória.

Código de autenticação de mensagem (MAC)

Um valor gerado criptograficamente a partir de alguns dados usando o triplo DES no modo CBC.

Compartilhamento de chave (secreta)

Um de pelo menos dois parâmetros relacionados a uma chave criptográfica gerada de tal forma que um quórum de tais parâmetros possa ser combinado para formar a chave criptográfica, mas de modo que menos do que um quórum não forneça nenhuma informação sobre a chave.

Componente de chave

Um de pelo menos dois parâmetros tendo as características (por exemplo, formato, aleatoriedade) de uma chave criptográfica que é combinada com um ou mais parâmetros semelhantes, por exemplo, por meio de adição de módulo-2, para formar uma chave criptográfica.

Comunicação de campo próximo

Uma tecnologia sem fio de curto alcance que permite troca de dados ao longo de uma distância inferior a 10 cm. Também chamada de "sem contato".

Conhecimento compartilhado

Uma condição em que duas ou mais pessoas possuem separadamente e confidencialmente a custódia de componentes de uma única chave que individualmente não transmitem nenhum conhecimento sobre a chave criptográfica resultante.

Controle duplo

Um processo de utilização de duas ou mais pessoas separadas operando juntas para proteger funções ou informações sensíveis em que nenhuma pessoa é capaz de acessar ou utilizar os materiais, por exemplo, uma chave criptográfica.

COTS COTS (Commercial off-the shelf, pela sigla em inglês) são dispositivos comerciais vendidos no varejo (para consumidores), como celulares e tablets.

Dados do titular do cartão

No mínimo, os dados do titular do cartão consistem no PAN completo. Os dados do proprietário do cartão também podem aparecer na forma do PAN completo mais qualquer um dos seguintes: nome do proprietário do cartão, data de expiração e/ou código de serviço.

Dados sensíveis Dados que devem ser protegidos contra divulgação não autorizada, alteração ou destruição, especialmente PINs de texto simples e chaves criptográficas, e incluem características de projeto, informações de status e assim por diante.

Decifrar, descriptografar Para produzir texto simples a partir de dados criptografados.

Dispositivo de criptografia segura (Secure Cryptographic Device, SCD)

Um conjunto de hardware, software e firmware que implementa processos de criptografia (incluindo algoritmos de criptografia e geração de chave) e fica contido em um limite de criptografia definido.



Termo Definição

Dispositivo de gerenciamento de chaves

Um dispositivo usado em qualquer lugar no ciclo de vida principal para o gerenciamento de chaves. Pode ou não ser um SCD. Quando necessário no documento, deve ser um SCD. Exemplos incluem dispositivos usados para carregamento de chaves ou geração de chaves.

EEPROM Memória somente leitura programável eletronicamente apagável.

Elemento seguro

Módulo inviolável em um dispositivo móvel capaz de hospedar/incorporar aplicativos de forma segura. Um elemento seguro pode ser parte integrante do dispositivo móvel ou pode ser um elemento removível inserido no dispositivo móvel para uso.

Emissor Uma entidade licenciada pelo esquema de pagamento para emitir cartões e entrar em um relacionamento contratual com o titular do cartão.

Emulação do cartão host (HCE)

Tecnologia que permite que um dispositivo execute a função de um cartão de pagamento em um dispositivo habilitado para comunicação por campo de proximidade (Near Field Communication, NFC) ou via aplicativos sem o uso de um elemento seguro.

Fornecedor A entidade legal e suas instalações associadas que são aprovadas pelo esquema de pagamento.

Geração de chave Criação de uma nova chave para uso subsequente.

Gerenciamento de chave

As atividades envolvendo o manuseio de chaves criptográficas e outros parâmetros de segurança relacionados (por exemplo, vetores de inicialização, contadores) durante todo o ciclo de vida das chaves, incluindo sua geração, armazenamento, distribuição, carregamento e uso, exclusão, destruição e arquivamento.

Identificador de Conjunto de Serviços (SSID)

SSID é uma sequência de 32 caracteres que identifica exclusivamente uma LAN sem fio (WLAN). O SSID é o nome da rede sem fio.

Inicialização do chip Ver Pré-personalização.

Injeção SQL

A injeção SQL é uma técnica de injeção de código que explora uma vulnerabilidade de segurança no software de um site. Isso é feito incluindo partes de instruções SQL em um campo de entrada de formulário na Web em uma tentativa de obter o site para passar um comando SQL recém-formado para o banco de dados (por exemplo, despejar o conteúdo do banco de dados para o invasor).

International Organization for Standardization (ISO)

A agência internacional especializada que estabelece e publica padrões técnicos internacionais.

Material de criação de chaves

Os dados (por exemplo, chaves e vetores de inicialização) necessários para estabelecer e manter relações de chaveamento criptográfico.



Termo Definição

Módulo de segurança de hardware

Um HSM é um tipo de SCD, um dispositivo de hardware físico e logicamente protegido que fornece um conjunto seguro de serviços criptográficos. Inclui o conjunto de hardware, firmware, software ou alguma combinação que implementa lógica criptográfica, processos criptográficos ou ambos, incluindo algoritmos criptográficos.

OTA Over-the-air (OTA) é qualquer processo que envolva a transferência de dados (incluindo aplicativos) para o dispositivo móvel ou qualquer componente dentro do dispositivo móvel por uma rede de telefonia celular.

OTI Over-the-Internet (OTI): Uma conexão remota de um domínio de segurança no elemento de segurança a um servidor de back-end, usando TLS por HTTP.

Padrão de criptografia avançada (AES)

O Advanced Encryption Standard (AES), também conhecido como Rijndael, é uma cifra de bloco adotado como um padrão de criptografia pelo governo dos EUA. Ele foi analisado extensivamente e agora é usado em todo o mundo, assim como o caso com seu antecessor, o Data Encryption Standard (DES).

Padrão de criptografia de dados A metodologia chave simétrica definida na ANSI X.3.92.

Padrão de criptografia de dados triplos (Triple Data Encryption Standard, TDES)

Um algoritmo especificado em ISO/IEC 18033-3: Tecnologia da informação Técnicas de segurança Algoritmos de criptografia Parte 3: Codificar cifras.

Personalização

O processo de aplicação da conta e, quando exigido para o produto, dados específicos do titular ao cartão, vinculando o cartão de forma exclusiva a uma determinada conta. Inclui a codificação da tarja magnética, gravação em relevo do cartão (se aplicável) e carregamento de dados no chip. A personalização usa tecnologias como: a) Gravação em relevo b) Gravação a laser c) Transferência térmica d) Impressão com entalhe

Pesquisa de site sem fio

Um processo que usa software e ferramentas para analisar a saída de RF de uma área específica e ajustar a colocação do ponto de acesso e a saída de intensidade do sinal para otimizar o sinal de RF para uma área específica. Os aplicativos de pesquisa de local sem fio levam em conta materiais de construção, plantas baixas, janelas e portas, móveis e outros dados físicos e eletrônicos para determinar a força de um sinal dentro e além da área de cobertura desejada e para avaliar a colocação e os parâmetros do(s) ponto(s) de acesso.

PIN Um número de identificação pessoal que identifica um titular do cartão em uma solicitação de autorização.

Preparação de dados Processo pelo qual os dados do titular do cartão são gerenciados e processados pelo fornecedor para uso subsequente no processo de personalização.



Termo Definição

Pré-personalização (Inicialização do chip)

Processo de substituição de uma chave de transporte em um chip por uma chave específica do emissor e (opcionalmente) ativação do aplicativo.

PROM Memória Programável Somente Para Leitura.

Protocolo de gerenciamento de rede simples (SNMP)

Um Protocolo Padrão da Internet para gerenciar dispositivos em redes IP, como roteadores, switches, servidores, estações de trabalho, impressoras e racks de modem.

Provisionamento móvel

A personalização (provisionamento) de um dispositivo comercial vendido no varejo (commercial off-the-shelf, COTS), como telefone celular equipado com NFC com as informações relevantes da conta do titular do cartão. As informações são transmitidas para o dispositivo por um processo chamado provisionamento over-the-air (OTA) ou, alternativamente, over-the-internet (OTI).

Provisionamento na nuvem Preparo e entrega de dados de emulação do cartão host a um dispositivo.

Pseudorandom O processo de geração de valores com um alto nível de entropia e que satisfazem várias qualificações, usando meios criptográficos e outros meios sem hardware.

Rede de escritório Uma coleção de sistemas usados para fins administrativos e removida do ambiente de produção.

Rede Privada Virtual (Virtual Private Network, VPN)

Uma tecnologia que estende uma rede remota (virtual) para o sistema de origem de inicialização VPN. Após a conexão bem-sucedida, o gateway padrão do sistema de origem aponta para a rede remota (virtual). Produtos baseados em padrões atuais do setor, como protocolos IPsec ou OpenVPN, são tecnologias de VPN aceitáveis.

Segregação de tarefas Ato de dividir as etapas de uma função entre diferentes indivíduos, de forma a impedir que um único indivíduo seja capaz de subverter o processo.

Simétrico Na criptografia, onde a mesma chave é usada para criptografia e descriptografia.

Texto Ver Texto simples.

Texto simples Informações em um estado compreensível e significativo. Algo não criptografado.

Troca de chaves O processo de importação, exportação e distribuição de chaves criptográficas usando procedimentos formalizados para garantir a segurança e a integridade dessas chaves.

Valor de autenticação Os dados que o sistema de distribuição de PIN usa para autenticar o titular do cartão

Valor de verificação

Um valor computado que é o resultado de passar um valor de dados através de um algoritmo não reversível. Os valores de verificação são geralmente calculados usando-se uma transformação criptográfica, que leva como entrada uma chave secreta e uma sequência arbitrária e fornece um valor de verificação criptográfico como saída. O cálculo de um valor de verificação correto sem conhecimento da chave secreta não deve ser viável.



Termo Definição

Variante de uma chave Uma nova chave formada por um processo (que não precisa ser secreto) com a chave original, de modo que um ou mais bits sem paridade da nova chave diferem dos bits correspondentes da chave original.

Documents

pt.pcisecuritystandards.org · Para os fins deste documento, personalização referese à preparação e inscrição de dados - específicos do emissor ou do titular do cartão na