SAQ_D_v20_12_2_10_form_PT-BR.pdf

Setor de cartões de pagamento (PCI) Padrão de segurança de dados Questionário de auto-avaliação D e Atestado de conformidade

Todos os outros SAQs - Comerciantes e prestadores de serviços qualificados Versão 2.0 Outubro de 2010

SAQ D do PCI DSS, v2.0, Alterações no documento Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página i

Alterações no documento

Data Versão Descrição

1º de outubro de 2008 1.2 Para alinhar o conteúdo com o novo PCI DSS v1.2 e para

implementar alterações menores observadas desde o original v1.1.

28 de outubro de 2010 2.0 Para alinhar o conteúdo com os novos requisitos e procedimentos de

teste do PCI DSS v2.0.

SAQ D do PCI DSS, v2.0, Índice Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página ii

Índice

Alterações no documento ............................................................................................. i Padrão de segurança de dados do PCI: Documentos relacionados ...................... iv

Antes de você começar ................................................................................................ v Preenchendo o questionário de auto-avaliação....................................................................v Conformidade do PCI DSS – Etapas para preenchimento ...................................................v Orientação para não aplicabilidade de determinados requisitos específicos..................vii

Atestado de conformidade, SAQ D — Versão do comerciante................................. 1

Atestado de conformidade, SAQ D — Versão do prestador de serviços................. 1

Questionário de auto-avaliação D................................................................................ 1 Construir e manter uma rede segura......................................................................................1

Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados ............1 Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e

outros parâmetros de segurança...............................................................4 Proteger os dados do titular do cartão...................................................................................7

Requisito 3: Proteger os dados armazenados do titular do cartão .........................................7 Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e

públicas ...................................................................................................12 Manter um programa de gerenciamento de vulnerabilidades............................................13

Requisito 5: Usar e atualizar regularmente o software ou programas antivírus...................13 Requisito 6: Desenvolver e manter sistemas e aplicativos seguros .....................................13

Implementar medidas de controle de acesso rigorosas.....................................................18 Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a

necessidade de conhecimento para o negócio .......................................18 Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao

computador..............................................................................................19 Requisito 9: Restringir o acesso físico aos dados do titular do cartão..................................22

Monitorar e testar as redes regularmente............................................................................25 Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede

e aos dados do titular do cartão ..............................................................25 Requisito 11: Testar regularmente os sistemas e processos de segurança.........................27

Manter uma política de segurança de informações ............................................................31 Requisito 12: Manter uma política que aborde a segurança das informações para todas as

equipes ....................................................................................................31 Anexo A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada....................................................................................... 35

Requisito A.1: Os provedores de hospedagem compartilhada devem proteger o ambiente de dados do titular do cartão ........................................................................35

Apêndice B: Controles de compensação ........................................................... 37

Anexo C: Planilha dos controles de compensação...................................... 39 Planilha dos controles de compensação – Exemplo completo .........................................40

SAQ D do PCI DSS, v2.0, Índice Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página iii

Apêndice D: Explicação de não aplicabilidade .................................................. 41

SAQ D do PCI DSS, v2.0, Padrão de segurança de dados do PCI: Documentos relacionados Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página iv

Padrão de segurança de dados do PCI: Documentos relacionados

Os documentos a seguir foram criados para auxiliar comerciantes e prestadores de serviços a entenderem o Padrão de segurança de dados do PCI (PCI DSS) e o SAQ do PCI DSS.

Documento Público

Padrão de segurança de dados do PCI: Requisitos e procedimentos da avaliação de segurança

Todos os comerciantes e prestadores de serviços

Navegando pelo PCI DSS: Entendendo o porquê dos requisitos


Padrão de segurança de dados do PCI: Diretrizes e instruções de auto-avaliação


Padrão de segurança de dados do PCI: Questionário A de auto-avaliação e atestado

Comerciantes qualificados1

Padrão de segurança de dados do PCI: Questionário B de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário C-VT de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário C de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário D de auto-avaliação e atestado

Comerciantes e prestadores de serviços qualificados1

Padrão de segurança de dados do PCI e Padrão de segurança de dados de aplicativos de pagamento: Glossário de termos, abreviações e acrônimos


1 Para determinar o Questionário de auto-avaliação adequado, consulte o Padrão de segurança de

dados do PCI: Diretrizes e instruções de auto-avaliação, "Selecionando o SAQ e o Atestado que melhor se aplicam à sua organização".

SAQ D do PCI DSS, v2.0, Antes de você começar Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página v

Antes de você começar

Preenchendo o questionário de auto-avaliação

O SAQ D foi desenvolvido para todos os prestadores de serviços qualificados pelo SAQ e para todos os comerciantes que não se encaixem nas descrições dos SAQs A a C, conforme descrito brevemente na tabela abaixo e integralmente nas Diretrizes e instruções do Questionário de auto-avaliação do PCI DSS.

SAQ Descrição

A Comerciantes do tipo cartão não presente (comércio eletrônico ou pedidos por correio/telefone), todas as funções dos dados do titular do cartão são terceirizadas. Isso nunca se aplica a comerciantes presenciais.

B Comerciantes com máquinas de carbono, sem armazenamento eletrônico dos dados do titular do cartão, ou comerciantes com terminais de discagem independentes, sem armazenamento eletrônico dos dados do titular do cartão

C-VT Comerciantes que usam somente terminais virtuais baseados na Web, sem armazenamento eletrônico dos dados do titular do cartão

C Comerciantes com sistemas de aplicativos de pagamento conectados à Internet, sem armazenamento eletrônico dos dados do titular do cartão

D Todos os outros comerciantes (não incluídos nas descrições dos SAQs A a C acima) e todos os prestadores de serviços definidos por uma bandeira como qualificados para preencherem um SAQ.

O SAQ D se aplica a todos os comerciantes qualificados para preencher o SAQ não incluídos nas descrições dos SAQs A a C acima e todos os prestadores de serviços definidos por uma bandeira como sendo qualificados para preencher o SAQ. Os prestadores de serviços e comerciantes do SAQ D validam a conformidade ao preencherem o SAQ D e o Atestado de conformidade associado. Apesar de várias organizações que preenchem o SAQ D precisarem validar a conformidade com todos os requisitos do PCI DSS, algumas organizações com modelos de negócio bastante específicos podem descobrir que alguns requisitos não se aplicam. Por exemplo: não se espera que uma empresa que não usa tecnologia sem fio de forma alguma valide a conformidade com as seções do PCI DSS que são específicas da tecnologia sem fio. Consulte a orientação abaixo para obter informações sobre a exclusão da tecnologia sem fio e de outros requisitos específicos.

Cada seção deste questionário se concentra em uma área específica de segurança, com base nas exigências do PCI DSS.

Conformidade do PCI DSS – Etapas para preenchimento 1. Avalie seu ambiente quanto à conformidade com o PCI DSS.

2. Preencha o Questionário de auto-avaliação (SAQ D) segundo as instruções do arquivo Diretrizes e instruções do Questionário de auto-avaliação do PCI DSS.

3. Faça uma varredura de vulnerabilidade aprovada com um Fornecedor de varredura aprovado (ASV) do PCI SSC e obtenha a comprovação de uma varredura aprovada com o ASV.

4. Preencha integralmente o Atestado de conformidade.

5. Envie o SAQ, a comprovação de uma varredura aprovada e o Atestado de conformidade, junto com qualquer outra documentação solicitada, ao adquirente (para comerciantes) ou à bandeira de pagamento ou outro solicitante (para prestadores de serviços).

SAQ D do PCI DSS, v2.0, Antes de você começar Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página vii

Orientação para não aplicabilidade de determinados requisitos específicos Exclusão: Se você precisar responder o SAQ D para validar sua conformidade com o PCI DSS, as seguintes exceções podem ser consideradas. Consulte a seção "Não aplicabilidade" abaixo para obter uma resposta adequada do SAQ.

As perguntas específicas relacionadas a dispositivos sem fio só precisarão ser respondidas se houver dispositivos sem fio em algum lugar da sua rede (por exemplo: os Requisitos 1.2.3, 2.1.1 e 4.1.1). Observe que o Requisito 11.1 (uso de um processo para identificar pontos de acesso sem fio não autorizados) deverá ser respondido, mesmo que o dispositivo sem fio não esteja na sua rede, pois o processo detecta intrusos ou dispositivos não autorizados que possam ter sido adicionados sem seu conhecimento.

As questões específicas para aplicativos e códigos personalizados (Requisitos 6.3 e 6.5) só precisarão ser respondidas se sua organização desenvolver seus próprios aplicativos personalizados.

As perguntas dos Requisitos 9.1 a 9.4 só precisarão ser respondidas para instalações com "áreas confidenciais", conforme definido aqui. "Áreas confidenciais" referem-se a qualquer central de dados, sala de servidores ou qualquer área que contenha sistemas que armazenem, processem ou transmitam dados do titular do cartão. Isso exclui as áreas que possuem somente terminais de pontos de vendas, como as áreas dos caixas em uma loja de varejo, mas inclui salas de servidores de back-office de lojas de varejo que armazenam dados do titular do cartão e áreas de armazenamento para grandes quantidades de dados do titular do cartão.

Não aplicabilidade: Este e outros requisitos considerados não aplicáveis ao seu ambiente deverão ser indicados com "N/A" na coluna "Especial" do SAQ. Da mesma forma, preencha a planilha "Explicação de não aplicabilidade" no Anexo D para cada entrada "N/A".

SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 1

Atestado de conformidade, SAQ D — Versão do comerciante Instruções para envio O comerciante deve preencher este Atestado de Conformidade como uma declaração do status de conformidade dele com os Requisitos do padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) e procedimentos da avaliação de segurança. Preencha todas as seções aplicáveis e consulte as instruções de envio em Conformidade do PCI DSS – Etapas para preenchimento, neste documento.

Parte 1. Informações sobre o comerciante e o avaliador de segurança qualificado

Parte 1a. Informações sobre a organização do comerciante Nome da empresa:

DBA(s):

Contato:

Forma de tratamento:

Telefone:

E-mail:

Endereço comercial:

Cidade:

Estado/Província:

País:

CEP:

URL:

Parte 1b. Informações sobre a empresa do assessor de segurança qualificado (se aplicável) Nome da empresa:

Nome do contato principal do QSA:



Telefone:

E-mail:


Cidade:

Estado/Província:

País:

CEP:

URL:

Parte 2. Tipo de negócio do comerciante (assinale todas as alternativas que se aplicam):

Varejo Telecomunicações Gêneros alimentícios e supermercados

Petróleo Comércio eletrônico Pedido por correio/telefone

Outros (especificar):

Listar as instalações e locais incluídos na análise do PCI DSS:

Parte 2a. Relações

Sua empresa se relaciona com um ou mais agentes de terceiros (por exemplo: gateways, empresas de hospedagem na Web, agentes de passagens aéreas, agentes de programas de fidelidade, etc.)?

Sim Não

Sua empresa se relaciona com mais de um adquirente? Sim Não

Parte 2b. Processamento das transações

Como e em qual capacidade seu negócio armazena, processa e/ou transmite dados do titular do cartão?

Forneça as seguintes informações relacionadas aos aplicativos de pagamentos usados pela sua organização:

Aplicativo de pagamento em uso Número da versão

Última validação de acordo com o PABP/PA-DSS


Parte 3. Validação do PCI DSS

Com base nos resultados anotados no SAQ D datado de (data do preenchimento), a (Nome da empresa do comerciante) declara o seguinte status de conformidade (marque um):

Em conformidade: Todas as seções do SAQ do PCI estão preenchidas, todas as perguntas foram respondidas afirmativamente, resultando em uma classificação geral de CONFORMIDADE, e uma varredura de verificação aprovada foi preenchida por um Fornecedor de varredura aprovado do PCI SSC, de forma que a (Nome da empresa do comerciante) demonstrou conformidade integral com o PCI DSS.

Não conformidade: Nem todas as seções do SAQ do PCI estão preenchidas ou algumas perguntas foram respondidas negativamente, resultando em uma classificação geral de NÃO CONFORMIDADE, ou uma varredura de verificação aprovada não foi preenchida por um Fornecedor de varredura aprovado do PCI SSC, de forma que a (Nome da empresa do comerciante) não demonstrou conformidade integral com o PCI DSS.

Data prevista para conformidade:

A entidade que estiver enviando este formulário com um status de Não conformidade talvez tenha de preencher o Plano de ação na Parte 4 deste documento. Verifique junto ao seu adquirente ou às bandeiras de pagamento antes de preencher a Parte 4, já que nem todas as bandeiras de pagamento exigem essa seção.

Parte 3a. Confirmação do status de conformidade O comerciante confirma que:

O Questionário de Auto-avaliação D do PCI DSS, versão (versão do SAQ), foi preenchido segundo as instruções nele contidas.

Todas as informações contidas no SAQ mencionado anteriormente e neste atestado representam adequadamente os resultados de minha avaliação em todos os aspectos materiais.

Eu confirmei com meu fornecedor do aplicativo de pagamento que o aplicativo não armazena dados de autenticação confidenciais após a autorização.

Eu li o PCI DSS e reconheço que sempre devo manter a conformidade total com o PCI DSS.

Não há evidência de armazenamento de dados de tarja magnética (ou seja, rastros)2, dados CAV2, CVC2, CID ou CVV23, ou dados de PIN4 após a autorização da transação em NENHUM sistema revisto durante esta avaliação.

2 Dados codificados na tarja magnética ou dados equivalentes em um chip usados para autorização durante a transação com o

cartão. As entidades não podem manter todos os dados da tarja magnética após a autorização da transação. Os únicos elementos dos dados de rastro que podem ser retidos são o número da conta, a data de vencimento e o nome.

3 O valor de três ou quatro dígitos impresso à direita do painel de assinatura ou na frente do cartão de pagamento usado para verificar transações com cartão não presente.


Parte 3b. Reconhecimento do comerciante

Assinatura do responsável executivo pelo comerciante Data

Nome do responsável executivo pelo comerciante Forma de tratamento

Empresa comerciante representada

Parte 4. Plano de ação para status de não conformidade Selecione o "Status de conformidade" adequado para cada requisito. Se você responder "NÃO" a qualquer um dos requisitos, será necessário informar a data na qual a empresa estará em conformidade com o requisito e uma descrição resumida das ações que estão sendo realizadas para atender ao requisito. Verifique junto ao seu adquirente ou às bandeiras de pagamento antes de preencher a Parte 4, já que nem todas as bandeiras de pagamento exigem essa seção.

Status de

conformidade (selecione um)

Requisito do PCI DSS Descrição do requisito SIM NÃO

Data e ações de correção (se o Status de

conformidade for "Não")

1

Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão

2

Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança

3 Proteger os dados armazenados do titular do cartão

4 Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas

5 Usar e atualizar regularmente o software ou programas antivírus

6 Desenvolver e manter sistemas e aplicativos seguros

7 Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de conhecimento para o negócio

4 Número de identificação pessoal inserido pelo titular do cartão durante uma transação com o cartão e/ou bloqueio de PIN

criptografado dentro da mensagem da transação.


Status de conformidade (selecione um)

8 Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador

9 Restringir o acesso físico aos dados do titular do cartão

10 Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão

11 Testar regularmente os sistemas e processos de segurança

12 Manter uma política que aborde a segurança das informações para todas as equipes


Atestado de conformidade, SAQ D — Versão do prestador de serviços Instruções para envio O prestador de serviços deve preencher este Atestado de conformidade como uma declaração do status de conformidade dele com os Requisitos do Padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) e procedimentos da avaliação de segurança. Preencha todas as seções aplicáveis e consulte as instruções de envio em "Conformidade do PCI DSS – Etapas para preenchimento", neste documento.

Parte 1. Informações do prestador de serviços e do assessor de segurança qualificado Parte 1a. Informações sobre a organização do prestador de serviços

Nome da empresa:

DBA(s):

Contato:


Telefone:

E-mail:


Cidade:

Estado/Província:

País:

CEP:

URL:

Parte 1b. Informações sobre a empresa do assessor de segurança qualificado (se aplicável) Nome da empresa:


Nome do contato principal do QSA:


Telefone:

E-mail:


Cidade:

Estado/Província:

País:

CEP:

URL:

Parte 2. Informações sobre a avaliação do PCI DSS Parte 2a. Prestador de serviços que FOI INCLUÍDO no escopo da avaliação do PCI DSS (marque todas as opções que se aplicam) Provedor de hospedagem segura

3-D Provedor de hospedagem –

Hardware Processamento de

pagamentos – ATM

Gerenciamento de contas Provedor de hospedagem – Web

Processamento de pagamentos – MOTO

Autorização Processamento de emissões Processamento de pagamentos – Internet

Serviços de back-office Programas de fidelidade Processamento de pagamentos – POS

Gerenciamento do faturamento Serviços gerenciados Serviços com pagamento adiantado

Compensação e liquidação Serviços do comerciante Gerenciamento de registros

Preparação de dados Fornecedor/transmissor de redes

Taxas/pagamentos para o governo

Fraude e serviços de cobrança Gateway/switch de pagamento


Listar as instalações e locais incluídos na análise do PCI DSS:


Parte 2b. Se algum serviço listado for fornecido pelo prestador de serviços, mas NÃO ESTIVER INCLUÍDO no escopo da avaliação do PCI DSS, marque-o abaixo:

Provedor de hospedagem segura 3-D

Provedor de hospedagem – Hardware

Processamento de pagamentos – ATM

Gerenciamento de contas Provedor de hospedagem – Web

Processamento de pagamentos – MOTO

Autorização Processamento de emissões Processamento de pagamentos – Internet

Serviços de back-office Programas de fidelidade Processamento de pagamentos – POS

Gerenciamento do faturamento Serviços gerenciados Serviços com pagamento adiantado

Compensação e liquidação Serviços do comerciante Gerenciamento de registros

Preparação de dados Fornecedor/transmissor de redes

Taxas/pagamentos para o governo

Fraude e serviços de cobrança Gateway/switch de pagamento


Parte 2c. Relações

Sua empresa se relaciona com um ou mais prestadores de serviços terceirizados (por exemplo: gateways, empresas de hospedagem na Web, agentes de passagens aéreas, agentes de programas de fidelidade, etc.)?

Sim Não

Parte 2d. Processamento das transações

Como e em qual capacidade seu negócio armazena, processa e/ou transmite dados do titular do cartão?

Aplicativo de pagamento em uso Número da versão

Última validação de acordo com o PABP/PA-DSS

Forneça as seguintes informações relacionadas aos aplicativos de pagamentos usados pela sua organização:

Parte 3. Validação do PCI DSS

Com base nos resultados anotados no SAQ D datado de (data do preenchimento do SAQ), a (Nome da empresa do prestador de serviços) declara o seguinte status de conformidade (marque um):

Em conformidade: Todas as seções do SAQ do PCI estão preenchidas, todas as perguntas foram


respondidas afirmativamente, resultando em uma classificação geral de CONFORMIDADE, e uma varredura de verificação aprovada foi preenchida por um Fornecedor de varredura aprovado do PCI SSC, de forma que a (Nome da empresa do prestador de serviços) demonstrou conformidade integral com o PCI DSS.

Não conformidade: Nem todas as seções do SAQ do PCI estão preenchidas ou algumas perguntas foram respondidas negativamente, resultando em uma classificação geral de NÃO CONFORMIDADE, ou uma varredura de verificação aprovada não foi preenchida por um Fornecedor de varredura aprovado do PCI SSC, de forma que a (Nome da empresa do prestador de serviços) não demonstrou conformidade integral com o PCI DSS.

Data prevista para conformidade: A entidade que estiver enviando este formulário com um status de Não conformidade talvez tenha de preencher o Plano de ação na Parte 4 deste documento. Verifique junto ao seu adquirente ou às bandeiras de pagamento antes de preencher a Parte 4, já que nem todas as bandeiras de pagamento exigem essa seção..


Parte 3a. Confirmação do status de conformidade O prestador de serviços confirma que:

O Questionário de auto-avaliação D, versão (inserir número da versão), foi preenchido segundo as instruções nele contidas.

Todas as informações contidas no SAQ mencionado anteriormente e neste atestado representam adequadamente os resultados de minha avaliação.

Eu li o PCI DSS e reconheço que sempre devo manter a conformidade total com o PCI DSS.

Não há evidência de armazenamento de dados de tarja magnética (ou seja, rastros)5, dados CAV2, CVC2, CID ou CVV26, ou dados de PIN7 após a autorização da transação em NENHUM sistema revisto durante esta avaliação.

Parte 3b. Confirmação do prestador de serviços

Assinatura do responsável executivo pelo prestador de serviços

Data

Nome do responsável executivo pelo prestador de serviços Forma de tratamento

Representante da empresa prestadora de serviços

Parte 4. Plano de ação para status de não conformidade Selecione o "Status de conformidade" adequado para cada requisito. Se você responder "NÃO" a qualquer um dos requisitos, será necessário informar a data na qual a empresa estará em conformidade com o requisito e uma descrição resumida das ações que estão sendo realizadas para atender ao requisito. Verifique junto ao seu adquirente ou às bandeiras de pagamento antes de preencher a Parte 4, já que nem todas as bandeiras de pagamento exigem essa seção.

5 Dados codificados na tarja magnética ou dados equivalentes em um chip usados para autorização durante a transação com o

cartão. As entidades não podem manter todos os dados da tarja magnética após a autorização da transação. Os únicos elementos dos dados de rastro que podem ser retidos são o número da conta, a data de vencimento e o nome.

6 O valor de três ou quatro dígitos impresso à direita do painel de assinatura ou na frente do cartão de pagamento usado para verificar transações virtuais com o cartão.

7 Número de identificação pessoal inserido pelo titular do cartão durante uma transação com o cartão e/ou bloqueio de PIN criptografado dentro da mensagem da transação.


Status de

conformidade (selecione um)

Requisito do PCI DSS Descrição do requisito SIM NÃO

Data e ações de correção (se o Status de

conformidade for "Não")

1

Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão

2

Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança

3 Proteger os dados armazenados do titular do cartão

4 Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas

5 Usar e atualizar regularmente o software ou programas antivírus

6 Desenvolver e manter sistemas e aplicativos seguros

7 Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de conhecimento para o negócio

8 Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador

9 Restringir o acesso físico aos dados do titular do cartão

10 Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão

11 Testar regularmente os sistemas e processos de segurança

12 Manter uma política que aborde a segurança das informações para todas as equipes

SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 1

Questionário de auto-avaliação D

Observação: As perguntas a seguir estão numeradas de acordo com os requisitos e procedimentos de teste do PCI DSS, conforme definido no documento Requisitos do PCI DSS e procedimentos da avaliação de segurança.

Data de preenchimento: Construir e manter uma rede segura Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados

Pergunta do PCI DSS Resposta: Sim Não Especial*

1.1 Os padrões de configuração do firewall e do roteador estão definidos para incluir o seguinte:

1.1.1 Existe um processo formal para aprovar e testar todas as conexões de rede externas e alterações nas configurações do firewall e do roteador?

(a) Existe algum diagrama da rede atual (como um diagrama que mostre o fluxo dos dados do titular do cartão na rede) que documente todas as conexões em relação aos dados do titular do cartão, incluindo as redes sem fio?

1.1.2

(b) Esse diagrama é mantido atualizado?

(a) Os padrões de configuração incluem requisitos para um firewall em cada conexão da Internet e entre qualquer zona desmilitarizada (DMZ) e a zona da rede interna?

1.1.3

(b) O diagrama da rede atual está de acordo com os padrões de configuração do firewall?

1.1.4 Os padrões de configuração do firewall e do roteador incluem uma descrição dos grupos, funções e responsabilidades para gerenciamento lógico dos componentes da rede?

(a) Os padrões de configuração do firewall e do roteador incluem uma lista documentada dos serviços, protocolos e portas necessárias para os negócios (por exemplo: protocolos HTTP (hypertext transfer protocol) e SSL (Secure Sockets Layer), SSH (Secure Shell) e VPN (Virtual Private Network)?

1.1.5

(b) Todos os serviços, protocolos e portas não seguros são necessários e existem recursos de segurança documentados e implementados para cada um desses itens?

Observação: Os exemplos de serviços, protocolos ou portas não seguros incluem, entre outros, FTP, Telnet, POP3, IMAP e SNMP.

1.1.6 (a) Os padrões de configuração do firewall e do roteador exigem a análise dos conjuntos de regras do firewall e do roteador pelo menos a cada seis meses?



(b) Os conjuntos de regras do firewall e do roteador são analisados pelo menos a cada seis meses?

1.2 As configurações do firewall e do router restringem as conexões entre redes não confiáveis e qualquer sistema no ambiente de dados do titular do cartão, da seguinte forma: Observação: Uma "rede não confiável" é qualquer rede externa às redes que pertencem à entidade em análise e/ou qualquer rede que não seja controlada ou gerenciada pela entidade.

(a) O tráfego de entrada e saída está limitado para o tráfego necessário para o ambiente de dados do titular do cartão e as restrições estão documentadas?

1.2.1

(b) Todos os outros tráfegos de entrada e saída são recusados de forma específica (como ao usar a opção explícita "recusar todos" ou uma recusa implícita após a declaração de permissão)?

1.2.2 Os arquivos de configuração do roteador estão seguros e sincronizados?

1.2.3 Existem firewalls de perímetro instalados entre quaisquer redes sem fio e o ambiente de dados do titular do cartão e esses firewalls estão configurados para recusar ou controlar (se esse tráfego for necessário para fins comerciais) qualquer tráfego a partir do ambiente sem fio no ambiente de dados do titular do cartão?

1.3 A configuração do firewall proíbe o acesso público direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do cartão, da seguinte forma:

1.3.1 Existe uma DMA implementada para limitar o tráfego de entrada somente para componentes do sistema que fornecem serviços, portas e protocolos autorizados acessíveis publicamente?

1.3.2 O tráfego de Internet de entrada está limitado ao endereço IP dentro da DMZ?

1.3.3 As conexões diretas estão proibidas para tráfego de entrada ou saída entre a Internet e o ambiente dos dados do titular do cartão?

1.3.4 A passagem de endereços internos da Internet para a DMZ é proibida?

1.3.5 O tráfego de saída do ambiente de dados do titular do cartão para a Internet está explicitamente autorizado?

1.3.6 A inspeção com status, também conhecida como filtragem de pacote dinâmico, está implementada (ou seja, somente conexões estabelecidas podem entrar na rede)?



1.3.7 Os componentes do sistema que armazenam dados do titular do cartão (como banco de dados) estão localizados em uma zona da rede interna, separada da DMZ e de outras redes não confiáveis?

(a) Existem métodos em vigor para evitar a divulgação de endereços IP privados e de informações de roteamento pra a Internet?

Observação: Os métodos para ocultar o endereço IP podem incluir, entre outros:

• Conversão de endereços de rede (NAT) • Implementação dos servidores contendo dados do

titular do cartão atrás dos servidores de proxy/firewalls ou caches de conteúdo,

• Remoção ou filtragem das propagandas de rota para redes privadas que empregam endereçamento registrado,

• Uso interno do espaço de endereço RFC1918 em vez de endereço registrado.

1.3.8

(b) A divulgação dos endereços IP privados e das informações de roteamento para entidades externas é autorizada?

(a) Existe um software de firewall pessoal instalado e ativo em todos os computadores móveis e/ou de propriedade do funcionário com conectividade direta à Internet (por exemplo: laptops usados pelos funcionários) usados para acessar a rede da empresa?

1.4

(b) O software de firewall pessoal está configurado de acordo com padrões específicos e não pode ser alterado pelos usuários de computadores móveis e/ou de propriedade do funcionário?


Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança


2.1 Os valores-padrão entregues pelo fornecedor são sempre alterados antes de instalar um sistema na rede? Os valores padrão entregues pelo fornecedor incluem, entre outros itens, senhas, strings de comunidade de SNMP (simple network management protocol) e a eliminação de contas desnecessárias.

Para ambientes sem fio conectados ao ambiente dos dados do titular do cartão ou para a transmissão dos dados do titular do cartão, os padrões são alterados da seguinte forma:

(a) As chaves de criptografia padrão são alteradas na instalação e são modificadas sempre que um funcionário que conhece as chaves sai da empresa ou troca de cargo?

(b) As strings de comunidades de SNMP padrão dos dispositivos sem fio são alteradas?

(c) As senhas/frases de senha padrão dos pontos de acesso são alteradas?

(d) O firmware dos dispositivos sem fio é atualizado para ser compatível com a criptografia robusta para autenticação e transmissão em redes sem fio?

2.1.1

(e) Os outros padrões relacionados à segurança do fornecedor de dispositivos sem fio são alterados, se aplicável?

(a) Os padrões de configuração são desenvolvidos para todos os componentes do sistema e estão de acordo com os padrões de fortalecimento do sistema aceitos pelo setor? As fontes para os padrões de fortalecimento do sistema aceitos pelo setor incluem, entre outros, o SysAdmin Audit Network Security (SANS) Institute, o National Institute of Standards Technology (NIST), o International Organization for Standardization (ISO) e o Center for Internet Security (CIS).

(b) Os padrões de configuração do sistema são atualizados quando novos problemas de vulnerabilidade são identificados, conforme definido no Requisito 6.2?

(c) Os padrões de configuração do sistema são aplicados quando novos sistemas são configurados?

2.2

(d) Os padrões de configuração do sistema incluem os seguintes itens:

2.2.1 (a) Somente uma função principal é implementada por servidor para evitar funções que exigem diferentes níveis de segurança coexistindo no mesmo servidor?

(Por exemplo: servidores da Web, servidores de banco de dados e DNS devem ser implementados em servidores separados.)



(b) Se forem usadas tecnologias de virtualização, somente uma função principal está implementada por componente ou dispositivo do sistema virtual?

(a) Somente os serviços, protocolos e daemons necessários, entre outros, são ativados conforme a necessidade para a função do sistema (ou seja, os serviços e protocolos que não são diretamente necessários para a execução da função especificada do dispositivo estão desativados)?

2.2.2

(b) Todos os serviços, daemons ou protocolos não seguros ativos são justificáveis e os recursos de segurança estão documentados e implementados?

(Por exemplo: tecnologias seguras como SSH, S-FTP, SSL ou IPSec VPN são usadas para proteger serviços não seguros como NetBIOS, compartilhamento de arquivos, Telnet, FTP, etc.)

(a) Os administradores do sistema e/ou equipes que configuram os componentes do sistema estão bem-informados sobre as configurações comuns dos parâmetros de segurança para esses componentes do sistema?

(b) As configurações comuns dos parâmetros de segurança estão incluídas nos padrões de configuração do sistema?

2.2.3

(c) As configurações dos parâmetros de segurança estão definidas corretamente nos componentes do sistema?

(a) Todas as funcionalidades desnecessárias como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores da Web desnecessários foram removidas?

(b) As funções ativadas estão documentadas e oferecem suporte para uma configuração segura?

2.2.4

(c) Existem somente funcionalidades registradas presentes nos componentes do sistema?

2.3 Os acessos administrativos fora do console estão criptografados da seguinte forma: Com o uso tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento baseado na Web e outros acessos administrativos fora do console.

(a) Todos os acessos administrativos fora do console são criptografados com criptografia robusta e um método de criptografia robusta é invocado antes da solicitação da senha do administrador?

(b) Os serviços do sistema e os arquivos de parâmetros são configurados para prevenir o uso de Telnet e outros comandos de login remoto inseguros?



(c) O acesso do administrador às interfaces de gerenciamento baseadas na Web é criptografado com uma criptografia robusta?

2.4 Se você for um provedor de hospedagem compartilhada, os sistemas estão configurados para proteger o ambiente de hospedagem e os dados do titular do cartão? Consulte o Anexo A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada para obter informações sobre os requisitos específicos que precisam ser cumpridos.


Proteger os dados do titular do cartão Requisito 3: Proteger os dados armazenados do titular do cartão


3.1 As políticas e procedimentos de retenção e eliminação de dados são implementadas conforme a seguir:

(a) Existem políticas e procedimentos de retenção e eliminação de dados implementadas que incluem requisitos específicos para a retenção dos dados do titular do cartão, conforme necessário para fins comerciais, legais e/ou regulatórios?

Por exemplo: os dados do titular do cartão precisam ser retidos por um período X pelos motivos comerciais Y.

(b) As políticas e os procedimentos incluem itens referentes a eliminação segura dos dados que não são mais necessários por motivos legais, regulatórios ou comerciais, incluindo a eliminação dos dados do titular do cartão?

(c) As políticas e os procedimentos abrangem todo o armazenamento dos dados do titular do cartão?

(d) Os processos e procedimentos incluem ao menos um dos seguintes itens? • Processo programático (automático ou manual) para

remover, ao menos trimestralmente, dados armazenados do titular do cartão que excederem os requisitos definidos pela política de retenção de dados

• Requisitos para uma análise, conduzida ao menos trimestralmente, para verificar se os dados armazenados do titular do cartão não excedem os requisitos definidos na política de retenção de dados.

3.1.1

(e) Todos os dados armazenados do titular do cartão cumprem os requisitos definidos na política de retenção de dados?

(a) Para os emissores e/ou empresas que oferecem suporte para serviços de emissão e armazenam dados de autenticação confidenciais, há justificativa comercial para o armazenamento dos dados de autenticação confidenciais e os dados estão seguros?

(b) Para todas as outras entidades, se dados de autenticação confidenciais forem recebidos e excluídos, existem processos em vigor para excluir os dados com segurança e verificar se os dados podem ser recuperados?

3.2

(c) Todos os sistemas cumprem os seguintes requisitos em relação ao armazenamento de dados de autenticação confidenciais após a autorização (mesmo se criptografados)?



3.2.1 O conteúdo completo de qualquer rastro da tarja magnética (localizada na parte posterior do cartão) ou qualquer dado equivalente presente em um chip ou em qualquer outro lugar, não é armazenado em nenhuma circunstância? Esses dados também são denominados como rastro completo, rastro, rastro 1, rastro 2 e dados da tarja magnética. Observação: No curso normal dos negócios, os seguintes elementos de dados da tarja magnética talvez precisem ser retidos:

O nome do titular do cartão, O número da conta primária (PAN), A data de vencimento e O código de serviço

Para minimizar o risco, armazene somente os elementos de dados conforme necessário para os negócios.

3.2.2 O código ou valor de verificação do cartão (número de três ou quatro dígitos impresso na frente ou atrás do cartão de pagamento) não é armazenado em nenhuma circunstância?

3.2.3 O numero de identificação pessoal (PIN) ou o bloqueio de PIN criptografado não é armazenado em nenhuma circunstância?

3.3 O PAN é mascarado quando exibido (os primeiros seis e quatro últimos dígitos são o número máximo de dígitos a serem exibidos)? Observações:

Este requisito não se aplica aos funcionários e outras partes interessadas que precisam visualizar o PAN completo;

Esse requisito não substitui os requisitos mais rigorosos em vigor quanto às exibições dos dados do titular do cartão – por exemplo, para recebimentos do ponto de venda (POS).



3.4 O PAN é processado para ficar ilegível em qualquer local onde ele esteja armazenado (incluindo repositórios de dados, mídias digitais portáteis, mídias de backup e logs de auditoria) usando qualquer uma das seguintes abordagens?

Hash unidirecional com base na criptografia robusta (o hash deve ser do PAN inteiro)

Truncamento (o hash não pode ser usado para substituir o segmento truncado do PAN)

Tokens e blocos de índice (os blocos devem ser armazenados de forma segura)

Criptografia robusta com processos e procedimentos de gerenciamento-chave associados.

Observação: É um esforço relativamente simples para um indivíduo mal-intencionado reconstituir os dados do PAN original caso ele tenha acesso às versões truncadas e hash do PAN. Quando as versões truncada e hash do mesmo PAN estiverem presentes no ambiente de uma entidade, controles adicionais deverão ser implantados para assegurar que as versões truncada e hash não sejam correlacionadas para reconstituir o PAN original.

Se a criptografia de disco (e não a criptografia do banco de dados no nível de coluna ou de arquivo) for utilizada, o acesso é gerenciado das formas a seguir?

(a) O acesso lógico aos sistemas de arquivos criptografados é gerenciado de forma independente dos mecanismos de controle de acesso nativos do sistema operacional (por exemplo, não usando bancos de dados de conta de usuário local)?

(b) As chaves criptográficas são armazenadas de forma segura (por exemplo, armazenadas em mídias removíveis protegidas adequadamente com controles de acesso robustos)?

3.4.1

(c) Os dados do titular do cartão nas mídias removíveis estão criptografados aonde quer que estejam armazenados?

Observação: Se a criptografia de disco não for usada para criptografar a mídia removível, os dados armazenados nessa mídia deverão ser convertidos em ilegíveis por meio de outro método.

3.5 Alguma chave é usada para proteger os dados do titular do cartão contra divulgação e uso inapropriado das formas a seguir? Observação: Este requisito também se aplica às chaves de criptografia de chaves usadas para proteger as chaves de criptografia de dados. Essas chaves de criptografia de chaves devem ser tão robustas quanto a chave de criptografia de dados.

3.5.1 O acesso às chaves criptográficas está restrito ao menor número necessário de responsáveis pela proteção?



(a) As chaves são armazenadas no formato criptografado e as chaves de criptografia de chaves são armazenadas separadamente das chaves de criptografia de dados?

3.5.2

(b) As chaves criptográficas são armazenadas no menor número possível de locais e formas?

(a) Todos os processos e procedimentos de gerenciamento de chaves das chaves criptográficas usadas para criptografar os dados do titular do cartão estão totalmente documentados e implementados?

(b) Somente para prestadores de serviços: Se as chaves forem compartilhadas com os clientes para transmissão ou armazenamento dos dados do titular do cartão, é fornecida aos clientes uma documentação que inclua uma orientação sobre como transmitir, armazenar e atualizar com segurança as chaves do cliente, de acordo com os Requisitos 3.6.1 a 3.6.8 abaixo?

3.6

(c) Existem processos e procedimentos de gerenciamento de chaves implementados que requerem os itens a seguir?

3.6.1 Os procedimentos de chaves criptográficas incluem a geração de chaves criptográficas robustas?

3.6.2 Os procedimentos de chaves criptográficas incluem a distribuição segura das chaves criptográficas?

3.6.3 Os procedimentos de chaves criptográficas incluem o armazenamento seguro das chaves criptográficas?

3.6.4 Os procedimentos de chaves criptográficas incluem alterações das chaves criptográficas para chaves que alcançaram o final de seu período de criptografia (por exemplo: após um período de tempo definido e/ou após a produção de certa quantidade de texto criptografado por determinada chave), conforme definido pelo fornecedor associado do aplicativo ou pelo proprietário da chave, com base nas melhores práticas e orientações do setor (como a NIST Special Publication 800-57)?

3.6.5 (a) Os procedimentos de chaves criptográficas incluem a inutilização ou substituição (por exemplo: por arquivamento, destruição e/ou revogação) das chaves criptográficas quando a integridade da chave estiver enfraquecida (como a saída de um funcionário com conhecimento de uma chave em texto simples)?

(b) Os procedimentos de chaves criptográficas incluem a substituição de chaves comprometidas conhecidas ou suspeitas?

(c) Se chaves inutilizadas ou substituídas forem mantidas, essas chaves são usadas somente para fins de decodificação/verificação (e não para criptografia)?



3.6.6 Os procedimentos de chaves criptográficas incluem o conhecimento compartilhado e o controle duplo das chaves criptográficas (como a exigência de duas ou três pessoas, cada uma conhecendo somente o seu componente da chave, para reconstituir a chave completa) para operações manuais de gerenciamento de chaves em texto simples? Observação: Os exemplos de operações manuais de gerenciamento de chave incluem, entre outros, geração, transmissão, carregamento, armazenamento e destruição de chaves.

3.6.7 Os procedimentos de chaves criptográficas incluem a prevenção contra a substituição não autorizada de chaves criptográficas?

3.6.8 Os responsáveis pela proteção das chaves criptográficas devem reconhecer formalmente (por escrito ou eletronicamente) que compreendem e aceitam suas responsabilidades de proteção das chaves?


Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas


(a) São utilizadas criptografia robusta e protocolos de segurança como SSL/TLS ou IPSEC para proteger os dados confidenciais do titular do cartão durante a transmissão em redes abertas e públicas?

Os exemplos de redes públicas e abertas que se encontram no escopo do PCI DSS incluem, entre outros, a Internet, tecnologias sem fio, GSM (Global System for Mobile communications) e GPRS (General Packet Radio Service).

(b) Somente chaves e/ ou certificados confiáveis são aceitos?

(c) Os protocolos de segurança foram implementados para usar somente configurações seguras, sem suporte para versões ou configurações inseguras?

(d) A força da criptografia adequada foi implementada para a metodologia de criptografia em uso (verifique as recomendações/melhores práticas do fornecedor)?

4.1

(e) Para implementações de SSL/TLS: • O HTTPS é exibido como parte do Universal Record Locator

(URL) do navegador? • Os dados do titular do cartão são exigidos somente quando

HTTPS é exibido no URL?

4.1.1 As melhores práticas do setor (como a IEEE 802.11i) são usadas para implementar a criptografia robusta para autenticação e transmissão nos dispositivos sem fio que transmitem dados do titular do cartão ou que estão conectados no ambiente de dados do titular do cartão? Observação: O uso de WEP como controle de segurança foi proibido em 30 de junho de 2010.

(a) Os PANs são processados para ficarem ilegíveis ou são protegidos com criptografia robusta sempre que são enviado por meio de tecnologias de envio de mensagens de usuário final (como e-mails, mensagens instantâneas ou bate-papo)?

4.2

(b) Existem políticas em vigor que afirmam que os PANs desprotegidos não são enviados por meio das tecnologias de envio de mensagens de usuário final?


Manter um programa de gerenciamento de vulnerabilidades Requisito 5: Usar e atualizar regularmente o software ou programas antivírus


5.1

Os softwares antivírus estão implementados em todos os sistemas normalmente afetados por softwares mal-intencionados?

5.1.1 Todos os programas antivírus podem detectar, remover e proteger contra todos os tipos conhecidos de softwares mal-intencionados (como vírus, trojans, worms, spywares, adwares e rootkits)?

Todos os software antivírus estão atualizados, funcionando ativamente e gerando logs de auditoria da seguinte forma:

(a) A política de antivírus requer a atualização do software e das definições do antivírus?

(b) A instalação principal do software está ativada para atualizações automáticas e varreduras periódicas?

(c) As atualizações automáticas e as varreduras periódicas estão ativadas?

5.2

(d) Todos os mecanismos de antivírus geram logs de auditoria e os logs são mantidos de acordo com o Requisito 10.7 do PCI DSS?

Requisito 6: Desenvolver e manter sistemas e aplicativos seguros


(a) Todos os componentes e softwares do sistema estão protegidos de vulnerabilidades conhecidas pois têm os patches de segurança mais recentes disponibilizados pelos fornecedores instalados?

6.1

(b) Os patches de segurança críticos são instalados no prazo de um mês após o lançamento?

Observação: Uma empresa talvez considere utilizar uma abordagem baseada nos riscos para priorizar suas instalações de patches. Por exemplo, ao priorizar mais a infra-estrutura crítica (como dispositivos e sistemas disponibilizados ao público e bancos de dados) em vez de dispositivos internos menos críticos, para assegurar que sistemas e dispositivos de prioridade elevada sejam resolvidos em um mês e dispositivos e sistemas menos críticos em três meses.


Pergunta do PCI DSS Resposta: Sim Não Especial* (a) Existe algum processo para identificar novas vulnerabilidades

de segurança descobertas, incluindo a atribuição de uma classificação de risco para tal vulnerabilidade? (No mínimo, as vulnerabilidades críticas de alto risco devem ser classificadas como "Alto".)

Observação: As classificações de risco devem ser baseadas nas melhores práticas do setor. Por exemplo: os critérios para classificação de vulnerabilidades como "Alto" risco podem incluir uma pontuação base no CVSS igual ou superior a 4.0, um patch fornecido pelo fornecedor classificado por ele como "crítico" ou uma vulnerabilidade que afete um componente crucial do aplicativo. A classificação de vulnerabilidades será considerada uma melhor prática até 30 de junho de 2012, quando passará a ser um requisito.

6.2

(b) Os processos de identificação de novas vulnerabilidades de segurança incluem o uso de fontes externas para obtenção de informações sobre vulnerabilidades de segurança?

(a) Os processos de desenvolvimento de software são baseados nos padrões e/ou melhores práticas do setor?

(b) A segurança das informações está incluída no ciclo de vida de desenvolvimento de softwares?

(c) Os aplicativos de software são desenvolvidos de acordo com o PCI DSS (com autenticação e logs seguros, por exemplo)?

6.3

(d) Os processos de desenvolvimento de softwares garantem os itens a seguir?

6.3.1 As contas, os IDs dos usuários e/ou as senhas dos aplicativos personalizados são removidos antes da ativação e distribuição dos aplicativos para os clientes?



6.3.2 Todas as alterações dos códigos do aplicativo personalizado são analisadas (usando processos manuais ou automatizados) antes da liberação para produção ou da distribuição para o cliente para identificar qualquer possível vulnerabilidade no código, conforme os itens a seguir?

• As alterações dos códigos são analisadas por outras pessoas além do autor do código e por pessoas que estão cientes das técnicas de análise dos códigos e das práticas de codificação seguras?

• As análises dos códigos asseguram que o código foi desenvolvido de acordo com as diretrizes de codificação seguras (em conformidade com o Requisito 6.5 do PCI DSS)?

• As correções adequadas são implementadas antes da distribuição?

• Os resultados das análises dos códigos são revisados e aprovados pela gerência antes da distribuição?

Observação: Este requisito referente às análises dos códigos se aplica a todos os códigos personalizados (internos e voltados para o público), como parte integrante do ciclo de vida de desenvolvimento do sistema. As análises dos códigos podem ser realizadas por equipes internas instruídas ou terceiros. Os aplicativos da Web também estão sujeitos a controles adicionais, se forem voltados ao público, para abordar ameaças e vulnerabilidades contínuas após a implementação, conforme definido no Requisito 6.6 do PCI DSS.

6.4 Os processos e procedimentos de controle de alterações foram seguidos para todas as alterações nos componentes do sistema para incluir os itens a seguir?

6.4.1 Os ambientes de desenvolvimento/teste são separados do ambiente de produção, com controle de acesso implementado para obrigar a separação?

6.4.2 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?

6.4.3 Os dados de produção (PANs ativos) não são usados para testes ou desenvolvimento?

6.4.4 As contas e os dados de teste são removidos antes da ativação dos sistemas de produção?

6.4.5 Os procedimentos de controle de alterações para implementação de patches de segurança e modificações de software estão documentados e exigem os itens 6.4.5.1 a 6.4.5.4 abaixo?

(b) Os itens a seguir são executados em todas as alterações?



6.4.5.1 Documentação de impacto

6.4.5.2 Aprovação documentada pelas partes autorizadas

(a) Testes de funcionalidade para verificar se a alteração não tem impacto adverso sobre a segurança do sistema

6.4.5.3

(b) Para alterações do código personalizado, todas as atualizações foram testadas para conformidade com o Requisito 6.5 do PCI DSS antes de serem implantadas na produção?

6.4.5.4 Os procedimentos de reversão estão estão preparados para cada alteração?

(a) Os aplicativos são desenvolvidos com base nas diretrizes de codificação seguras?

(Como o Open Web Application Security Project (OWASP) Guide, SANS CWE Top 25, CERT Secure Coding, etc.)?

(b) Os desenvolvedores estão bem-informados sobre as técnicas de codificação seguras?

6.5

(c) A prevenção contra vulnerabilidades de codificação comuns faz parte dos processos de desenvolvimento de softwares para garantir que os aplicativos não estejam vulneráveis, com a aplicação mínima dos itens a seguir?

Observação: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9 estavam atualizadas de acordo com as melhores práticas do setor, quando esta versão do PCI DSS foi publicada. No entanto, conforme as melhores práticas do setor para o gerenciamento de vulnerabilidades são atualizadas, as melhores práticas atuais precisam ser usadas para estes requisitos.

6.5.1 Falhas na injeção, particularmente na injeção SQL? (Validar a entrada para verificar se os dados do usuário não podem modificar o significado dos comandos e das queries, usar queries parametrizadas, etc.) Também considere as falhas de injeção OS Command Injection, LDAP e Xpath, assim como outras falhas.

6.5.2 Estouro de buffer? (Validar os limites do buffer e truncar as strings de entrada.)

6.5.3 Armazenamento criptográfico não seguro? (Evitar falhas criptográficas.)

6.5.4 Comunicações não seguras? (Criptografar corretamente todas as comunicações autenticadas e confidenciais.)

6.5.5 Manuseio incorreto de erros? (Não divulgar informações através de mensagens de erro.)



6.5.6 Todas as vulnerabilidades classificadas como "Alto" identificadas no processo de identificação de vulnerabilidade (conforme definido no Requisito 6.2 do PCI DSS)? Observação: Este requisito será considerado uma das melhores praticas até 30 de junho de 2012 quando passará a ser um requisito.

Nos aplicativos da Web e nas interfaces dos aplicativos (externos ou internos), as seguintes vulnerabilidades adicionais também são abordadas?

6.5.7 Scripting de site cruzado (XSS). (Validar todos os parâmetros antes da inclusão, utilizar uma saída de contexto confidencial, etc.)

6.5.8 Controle de acesso inapropriado, como referências diretas inseguras a objetos, falhas na restrição do acesso a URLs e diretórios transversais. (Autenticar os usuários e corrigir a entrada adequadamente. Não expor referências a objetos internos aos usuários.)

6.5.9 Falsificação de solicitações de site cruzado (CSRF). (Não responder para credenciais de autorização e tokens enviados automaticamente pelos navegadores.)

6.6 Para aplicativos da Web voltados para o público, as novas ameaças e vulnerabilidades são abordadas continuamente e esses aplicativos estão protegidos contra ataques conhecidos por qualquer um dos métodos a seguir?

Analisando os aplicativos da Web voltados para o público através de ferramentas ou métodos manuais ou automáticos de avaliação de segurança das vulnerabilidades dos aplicativos, conforme os itens a seguir:

o Pelo menos anualmente o Após quaisquer alterações o Por meio de uma empresa especializada na segurança

de aplicativos o Se todas as vulnerabilidades forem corrigidas o Se o aplicativo for reavaliado após as correções

– ou – Instalando um firewall na camada de aplicativo da Web em

todos os aplicativos da Web voltados para o público para detectar e impedir ataques baseados na Web.

Observação: "Uma empresa especializada na segurança de aplicativos" pode ser uma empresa terceirizada ou uma empresa interna, desde que os analisadores sejam especializados na segurança de aplicativos e possam demonstrar que não dependem da equipe de desenvolvimento.


Implementar medidas de controle de acesso rigorosas Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de conhecimento para o negócio


7.1 O acesso aos componentes do sistema e aos dados do titular do cartão é limitado somente àquelas pessoas cuja função requer tal acesso, conforme itens a seguir:

7.1.1 Os direitos de acesso dos IDs dos usuários privilegiados estão restritos ao menor número de privilégios necessários para o desempenho das responsabilidades da função?

7.1.2 Os privilégios são concedidos às pessoas com base na classificação e na atribuição da função (também chamado de "controle de acesso baseado na função" ou RBAC)?

7.1.3 A aprovação documentada (por escrito ou eletronicamente) das partes autorizadas é necessária e especifica os privilégios necessários?

7.1.4 Os controles de acesso são implementados por meio de um sistema de controle de acesso automático?

7.2 Existe um controle de acesso em vigor para sistemas com vários usuários, a fim de restringir o acesso com base na necessidade de conhecimento do usuário, configurado para "negar tudo" a menos que especificamente permitido, conforme os itens a seguir?

7.2.1 Os sistemas de controle de acesso estão implementados em todos os componentes do sistema?

7.2.2 Os sistemas de controle de acesso estão configurados para impor os privilégios concedidos às pessoas com base na classificação e na atribuição da função?

7.2.3 Os sistemas de controle de acesso têm uma configuração padrão "recusar todos"? Observação: Alguns sistemas de controle de acesso são definidos, como padrão, como"permitir todos", permitindo portanto o acesso a menos que/até que uma norma seja redigida para recusá-lo de forma específica.


Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador


8.1 Todos os usuários recebem um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do cartão?

8.2

Além de atribuir um ID exclusivo, um ou mais dos seguintes métodos foi empregado para autenticar todos os usuários?

Algo que você sabe, como uma senha ou frase de senha Algo que você tem, como um dispositivo de token ou um

smart card Algo que você é, como a biométrica

8.3 A autenticação com dois fatores foi incorporada ao acesso remoto (acesso no nível da rede que se origina fora dela) à rede pelos funcionários, administradores e terceiros? (Por exemplo: autenticação remota e serviço de dial-in (RADIUS) com tokens, sistema de controle de acesso ao controlador de acesso ao terminal (TACACS) com tokens ou outras tecnologias que facilitam a autenticação com dois fatores.) Observação: A autenticação de dois fatores exige que dois dos três métodos de autenticação (consulte o Requisito 8.2 do PCI DSS para obter descrições dos métodos de autenticação) sejam usados para autenticação. O uso duplicado de um fator (como o uso de duas senhas separadas) não é considerado uma autenticação com dois fatores.

(a) Todas as senhas são processadas para se tornarem ilegíveis durante a transmissão e o armazenamento em todos os componentes do sistema usando criptografia robusta?

8.4

(b) Somente para prestadores de serviços: As senhas do cliente são criptografadas?

8.5 Existem controles de gerenciamento adequados de autenticação e identificação de usuários em vigor para administradores e usuários que não são clientes em todos os componentes do sistema, conforme a descrição a seguir?

8.5.1 As adições, exclusões e modificações dos IDs, das credenciais e de outros objetos de identificação do usuários são controladas, de forma que os IDs do usuários sejam implementados somente quando autorizados (incluindo usuários com privilégios específicos)?

8.5.2 A identidade do usuário é verificada antes da execução de redefinições de senha nas solicitações do usuário feitas através de métodos não presenciais (como telefone, e-mail ou pela Web)?

8.5.3 As senhas iniciais e as senhas redefinidas são configuradas com um valor exclusivo para cada usuário, cabendo a cada um alterar sua senha imediatamente após o primeiro uso?



8.5.4 O acesso dos usuários desligados da empresa é imediatamente desativado ou removido?

8.5.5 As contas inativas por mais de 90 dias são removidas ou desativadas?

(a) As contas usadas pelos fornecedores para acesso remoto, manutenção ou suporte são ativadas somente durante o período necessário?

8.5.6

(b) As contas de acesso remoto dos fornecedores são monitoradas durante o uso?

8.5.7 Os procedimentos e as políticas de autenticação são transmitidos a todos os usuários que têm acesso aos dados do titular do cartão?

8.5.8 As contas e senhas (ou outros métodos de autenticação) de grupo, compartilhadas ou genéricas, são proibidas conforme os itens a seguir? • Os IDs e as contas de usuários genéricos são

desativadas ou removidas; • Não existem IDs de usuários compartilhados para

atividades de administração do sistema e outras funções críticas; e

• Os IDs de usuários compartilhados e genéricos não são usados para administrar quaisquer componentes do sistema.

(a) As senhas dos usuários são alteradas pelo menos a cada 90 dias?

8.5.9

(b) Somente para prestadores de serviços: As senhas dos usuários que não são clientes são alteradas periodicamente e esses usuários recebem instruções sobre quando e sob quais circunstâncias as senhas devem ser alteradas?

(a) É exigido um comprimento mínimo de senha de pelo menos sete caracteres?

8.5.10

(b) Somente para prestadores de serviços: As senhas dos usuários que não são clientes devem obrigatoriamente seguir o requisito mínimo de tamanho?

(a) As senhas devem conter caracteres numéricos e alfabéticos?

8.5.11

(b) Somente para prestadores de serviços: As senhas dos usuários que não são clientes devem conter caracteres numéricos e alfabéticos?

(a) A pessoa deve escolher uma nova senha que seja diferente das quatro últimas senhas utilizadas?

8.5.12

(b) Somente para prestadores de serviços: As novas senhas dos usuários que não são clientes devem ser diferentes das quatro últimas senhas utilizadas?



(a) As tentativas de acesso repetidas são limitadas, bloqueando o ID do usuários após seis tentativas, no máximo?

8.5.13

(b) Somente para prestadores de serviços: As senhas dos usuários que não são clientes são temporariamente bloqueadas após seis tentativas de acesso inválidas, no máximo?

8.5.14 Após o bloqueio da conta do usuário, a duração do bloqueio está definida para um mínimo de 30 minutos ou até o administrador ativar o ID do usuário?

8.5.15 Se uma sessão ficar ociosa por mais de 15 minutos, o usuário é obrigado a se autenticar novamente (informar novamente a senha, por exemplo) para reativar o terminal ou a sessão?

(a) Todos os acessos a qualquer banco de dados contendo dados do titular do cartão são autenticado? (Incluindo acesso por meio de aplicativos, administradores e todos os outros usuários).

(b) Todos os acessos, consultas e ações dos usuários (como transferências, cópias ou exclusões) nos bancos de dados são feitos somente através de métodos programáticos (como através dos procedimentos armazenados)?

(c) O acesso direto ao usuário ou as consultas aos bancos de dados são restritas aos administradores do banco de dados?

8.5.16

(d) Os IDs dos aplicativos com acesso ao banco de dados só podem ser usados por aplicativos (e não por usuários individuais ou outros processos)?


Requisito 9: Restringir o acesso físico aos dados do titular do cartão


9.1 Existem controles de entrada na instalação adequados em vigor para limitar e monitorar o acesso físico aos sistemas no ambiente de dados do titular do cartão?

(a) Existem câmeras de vídeo e/ou mecanismos de controle de acesso em vigor para monitorar o acesso físico individual nas áreas confidenciais?

Observação: "Áreas confidenciais" referem-se a qualquer central de dados, sala de servidores ou qualquer área que contenha sistemas que armazenem dados do titular do cartão. Isso exclui as áreas nas quais há somente terminais do ponto de venda presentes, como as áreas dos caixas em uma loja de varejo.

(b) As câmeras de vídeo e/ou os mecanismos de controle de acesso estão protegidos contra interceptação ou desativação?

9.1.1

(c) Os dados das câmeras de vídeo e/ou dos mecanismos de controle de acesso são analisados e correlacionados com outras entradas e esses dados são armazenados por pelo menos três meses, a menos que restrito por lei?

9.1.2 O acesso físico aos pontos de rede acessíveis ao público é restrito (por exemplo: áreas acessíveis a visitantes não devem ter portas de rede ativadas a não ser que o acesso à rede seja autorizado explicitamente)? Como alternativa, os visitantes estão sempre acompanhados em áreas com pontos de rede ativos?

9.1.3 O acesso físico ao pontos de acesso sem fio, gateways, dispositivos portáteis, hardwares de comunicação/rede e linhas de telecomunicação é restrito?

9.2 Existem procedimentos implementados para diferenciar facilmente a equipe interna e os visitantes, conforme os itens a seguir? Para as finalidades do Requisito 9, "equipe interna" refere-se a funcionários que trabalham em período integral e meio-período e funcionários, prestadores de serviços e consultores temporários que estão fisicamente presente no endereço da entidade. "Visitante” refere-se a um fornecedor, convidado de um funcionário, equipes de serviço ou qualquer pessoa que precise adentrar as dependências por um breve período, normalmente um dia, no máximo.


Pergunta do PCI DSS Resposta: Sim Não Especial* (a) Os processos e procedimentos de atribuição de crachás para

a equipe interna e para os visitantes incluem os itens a seguir? • Concessão de novos crachás, • Modificação dos requisitos de acesso e • Anulação dos crachás dos membros da equipe interna que

se desligaram da empresa e dos visitantes que encerraram suas atividades.

(b) O acesso ao sistema de crachás é limitado aos funcionários autorizados?

(c) Os crachás identificam claramente os visitantes e diferenciam facilmente os visitantes dos membros da equipe interna?

9.3 Todos os visitantes passam pelos procedimentos a seguir?

9.3.1 Os visitantes devem obter autorização antes de entrar em áreas nas quais os dados do titular do cartão são processados ou mantidos?

(a) Os visitantes recebem um token físico (como um crachá ou dispositivo de acesso) que os identifica e os diferencia dos membros da equipe interna?

9.3.2

(b) O cartão do visitante expira?

9.3.3 Os visitantes devem entregar o token físico antes de sair das dependências ou quando o token expirar?

(a) Existe um log de visitantes em vigor para registrar o acesso físico às dependências, assim como aos ambientes com computador e centrais de dados onde os dados do titular do cartão são armazenados ou transmitidos?

9.4

(b) O log de visitantes contém o nome do visitante, a empresa representada e o membro da equipe interna que está autorizando o acesso físico e esse log é mantido por pelo menos três meses?

(a) Os backups de mídia são armazenados em um local seguro, de preferência em uma área externa, como um local alternativo ou de backup, ou uma área de armazenamento comercial?

9.5

(b) A segurança do local é analisada pelo menos uma vez por ano?

9.6 Todas as mídias estão fisicamente seguras (incluindo, entre outros, computadores, mídias eletrônicas removíveis, recibos em papel, relatórios em papel e faxes)? Para os fins do Requisito 9, "Mídia" refere-se a todas as mídias em papel ou eletrônicas que contêm dados do titular do cartão.

(a) É mantido um controle rigoroso quanto à distribuição interna ou externa de qualquer tipo de mídia?

9.7

(b) Os controles incluem o seguinte:



9.7.1 A mídia é classificada para que a confidencialidade dos dados possa ser determinada?

9.7.2 A mídia é enviada via um mensageiro seguro ou outro método de entrega que possa ser rastreado com precisão?

9.8 Existem logs para rastrear todas as mídias que são movidas de uma área segura, com aprovação da gerência antes da transferência da mídia (especialmente quando a mídia é distribuída para pessoas físicas)?

9.9 É mantido um controle rigoroso sobre o armazenamento e a acessibilidade das mídias?

9.9.1 Os logs de inventário de toda a mídia são mantidos adequadamente e os inventários periódicos das mídias são realizados pelo menos uma vez ao ano?

Todas as mídias são destruídas quando não são mais necessárias por razões corporativas ou legais?

9.10

A destruição é executada da seguinte forma:

(a) Os materiais impressos são fragmentados, incinerados ou reciclados, de forma que os dados do titular do cartão não possam ser reconstruídos?

9.10.1

(b) Os contêineres que armazenam informações são destruídos de forma segura para prevenir o acesso aos conteúdos? (Por exemplo: um contêiner "a ser triturado" tem uma trava que impede o acesso ao seu conteúdo.)

9.10.2 Os dados do titular do cartão nas mídias eletrônicas são excluídos por meio de um programa de limpeza segura, de acordo com os padrões do setor para exclusão segura, ou de outra forma, destruindo fisicamente as mídias (por exemplo, desmagnetizando) para que os dados do titular do cartão não possam ser reconstruídos?


Monitorar e testar as redes regularmente Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da

rede e aos dados do titular do cartão


10.1 Existe algum processo em vigor para vincular todos os acessos aos componentes do sistema (principalmente o acesso realizado com privilégios administrativos como raiz) para cada usuário individual?

10.2 Foram implementadas trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos:

10.2.1 Todos os acessos individuais dos usuários aos dados do titular do cartão?

10.2.2 Todas as ações desempenhadas por qualquer pessoa com privilégios raiz ou administrativos?

10.2.3 Acesso a todas as trilhas de auditoria?

10.2.4 Tentativas de acesso lógico inválidas?

10.2 5 Uso de mecanismos de identificação e autenticação?

10.2.6 Inicialização dos logs de auditoria?

10.2.7 Criação e exclusão de objetos do nível do sistema?

10.3 As seguintes entradas da trilha de auditoria são registradas para todos os componentes do sistema para cada um dos eventos a seguir?

10.3.1 Identificação do usuário?

10.3.2 Tipo de evento?

10.3.3 Data e hora?

10.3.4 Indicação de sucesso ou falha?

10.3.5 Origem do evento?

10.3.6 Identidade ou nome dos dados, componentes do sistema ou recursos afetados?

(a) Todos os relógios e horários dos sistemas críticos estão sincronizados através do uso de uma tecnologia de sincronização e essa tecnologia é mantida atualizada?

Observação: Um exemplo de tecnologia de sincronização de horários é o Network Time Protocol (NTP).

10.4

(b) Os controles a seguir foram implementados para aquisição, distribuição e armazenamento de horários?

10.4.1 (a) Somente os servidores centrais de horário designados recebem sinais de horário de fontes externas e todos os sistemas críticos possuem o mesmo horário correto, com base na hora internacional do relógio atômico (UTC)?



(b) Os servidores centrais de horário designados estão emparelhados para manter o horário preciso e os outros servidores internos recebem o horário somente dos servidores centrais de horário?

Os dados de horário são protegidos conforme a descrição a seguir?

(a) O acesso aos dados de horário é restrito somente às equipes com necessidades comerciais de acesso aos dados de horário?

10.4.2

(b) As alterações nas configurações de horários dos sistemas críticos são registradas, monitoradas e analisadas?

10.4.3

As configurações de horário são recebidas de fontes de horário específicas aceitas pelo setor? (Isso é feito para evitar a alteração do relógio por um indivíduo mal-intencionado). Além disso, essas atualizações podem ser criptografadas com uma chave simétrica e listas de controle de acesso podem ser criadas para especificar os endereços IP das máquinas clientes que receberão as atualizações de horário (para evitar o uso não autorizado dos servidores de horário internos).

10.5 As trilhas de auditoria estão protegidas de forma que não possam ser alteradas, conforme a descrição a seguir?

10.5.1 A visualização das trilhas de auditoria é limitada às pessoas com necessidades relacionadas à função?

10.5.2 Os arquivos de trilha de auditoria estão protegidos contra modificações não autorizadas por meio de mecanismos de controle de acesso, separação física e/ou separação da rede?

10.5.3 O backup dos arquivos de trilha de auditoria é feito imediatamente em um servidor de log centralizado ou em uma mídia que seja difícil de alterar?

10.5.4

Os logs das tecnologias externas (como tecnologias sem fio, firewalls, DNS, e-mail) são transferidos ou copiados em uma mídia ou em um servidor de log centralizado seguro na LAN interna?

10.5.5 São usados softwares de monitoramento da integridade dos arquivos ou de detecção de alterações nos logs para assegurar que os dados do log existentes não possam ser alterados sem gerar alertas (embora os novos dados que estejam sendo adicionados não gerem um alerta)?



10.6 Os logs de todos os componentes do sistema são analisados diariamente e é necessário o acompanhamento das exceções? As análises dos logs incluem aqueles servidores que desempenham funções de segurança como sistema de detecção de invasões (IDS) e servidores de protocolo de autenticação, autorização e inventário (AAA) (como o RADIUS). Observação: Ferramentas de coleta, análise e alerta de logs podem ser usadas para a obtenção da conformidade com o Requisito 10.6.

(a) Existem políticas e procedimentos de retenção de logs de auditoria em vigor que exigem a retenção do histórico das trilhas de auditoria por pelo menos um ano?

10.7

(b) Os logs de auditoria ficam disponíveis por pelo menos um ano e existem processos em vigor para restaurar imediatamente pelo menos os logs dos três últimos meses para análise?

Requisito 11: Testar regularmente os sistemas e processos de segurança

Pergunta do PCI DSS Resposta: Sim Não Especial* (a) Existe um processo documentado implementado para detectar

e identificar trimestralmente os pontos de acesso sem fio? Observação: Os métodos que podem ser usados no processo incluem, entre outros, varreduras de rede sem fio, inspeções físicas/lógicas dos componentes e da infraestrutura do sistema, controle de acesso à rede (NAC) ou IDS/IPS sem fio. Qualquer método usado deve ser suficiente para detectar e identificar qualquer dispositivo não autorizado.

(b) A metodologia é adequada para detectar e identificar qualquer ponto de acesso sem fio não autorizado, incluindo ao menos os itens a seguir? • Cartões WLAN inseridos nos componentes do sistema; • Dispositivos portáteis sem fio conectados aos

componentes do sistema (via USB, etc.); • Dispositivos sem fio conectados a uma porta de rede ou a

um dispositivo de rede.

(c) O processo para identificar pontos de acesso sem fio não autorizados é executado ao menos trimestralmente em todos os componentes do sistema e em todas as instalações?

(d) Se o monitoramento automatizado for utilizado (como IDS/IPS sem fio, NAC, etc.), o monitoramento está configurado para gerar alertas para a equipe?

11.1

(e) O Plano de resposta a incidentes (Requisito 12.9) inclui uma resposta em caso de detecção de dispositivos sem fio não autorizados?



11.2 São executadas varreduras das vulnerabilidades das redes internas e externas pelo menos trimestralmente e após qualquer alteração significativa na rede (como instalações de novos componentes do sistema, alterações na topologia da rede, modificações das normas do firewall, upgrades de produtos) da seguinte forma? Observação: Não será necessário que quatro varreduras trimestrais aprovadas sejam concluídas para a conformidade inicial do PCI DSS se 1) o resultado da varredura mais recente foi uma varredura aprovada, 2) a entidade possuir políticas e procedimentos documentados que exigem varreduras trimestrais e 3) as vulnerabilidades observadas nos resultados da varredura tenham sido corrigidas conforme mostrado em uma nova varredura. Nos anos seguintes após a análise inicial do PCI DSS, quatro varreduras trimestrais aprovadas devem ter ocorrido.

11.2.1 (a) São executadas varreduras das vulnerabilidades internas trimestrais?

(b) O processo de varredura interna trimestral inclui novas varreduras até que os resultados aprovados sejam obtidos ou todas as vulnerabilidades definidas como "Alto", conforme definido no Requisito 6.2 do PCI DSS, estejam solucionadas?

(c) As varreduras são executadas por um recurso interno qualificado ou um terceiro externo qualificado e, caso aplicável, há uma independência organizacional do responsável pelo teste (não é necessário que seja um QSA ou ASV)?

(a) São executadas varreduras das vulnerabilidades externas trimestrais?

(b) Os resultados da varredura externa trimestral cumprem os requisitos do Guia do programa ASV (por exemplo: nenhuma vulnerabilidade classificada com valor superior a 4.0 pelo CVSS e nenhuma falha automática)?

11.2.2

(c) As varreduras das vulnerabilidades externas trimestrais são executadas por um Fornecedor de varredura aprovado (ASV) qualificado pelo Conselho de padrões de segurança do setor de cartões de pagamento (PCI SSC)?


Pergunta do PCI DSS Resposta: Sim Não Especial* (a) São executadas varreduras internas e externas após

qualquer alteração significativa na rede (como instalações de novos componentes do sistema, alterações na topologia da rede, modificações das normas do firewall, upgrades de produtos)?

Observação: As varreduras realizadas após as alterações na rede devem ser desempenhadas pela equipe interna da empresa.

(b) O processo de varredura inclui novas varreduras até que: • Não existam varreduras com pontuação maior do

que 4.0 pelo CVSS (para varreduras externas), • Um resultado aprovado seja obtido ou todas as

vulnerabilidades definidas como "Alto", conforme definido no Requisito 6.2 do PCI DSS, estejam solucionadas (para varreduras internas)?

11.2.3

(c) As varreduras são executadas por um recurso interno qualificado ou um terceiro externo qualificado e, caso aplicável, há uma independência organizacional do responsável pelo teste (não é necessário que seja um QSA ou ASV)?

(a) São realizados testes de penetração externos e internos pelo menos uma vez por ano e após qualquer alteração significativa na infra-estrutura ou nos aplicativos (como um upgrade no sistema operacional e a adição de uma sub-rede ou de um servidor da Web ao ambiente)?

(b) As vulnerabilidades observadas foram corrigidas e os testes foram repetidos?

(c) Os testes são realizados por um recurso interno qualificado ou um terceiro externo qualificado e, caso seja aplicável, há uma independência organizacional do responsável pelo teste (não é necessário que seja um QSA ou ASV)?

11.3

Esses testes de penetração incluem os itens a seguir?

11.3.1 Testes de penetração na camada de rede? Observação: Esses testes devem incluir componentes que são compatíveis com as funções da rede e com os sistemas operacionais.

11.3.2 Testes de penetração na camada do aplicativo? Observação: Os testes devem incluir, no mínimo, as vulnerabilidades listadas no Requisito 6.5.

(a) Existem sistemas de detecção de invasão e/ou sistemas de prevenção contra invasão em uso para monitorar todo o tráfego no ambiente de dados do titular do cartão e nos pontos críticos do ambiente dos dados do titular do cartão?

11.4

(b) Os IDS e/ou os IPS estão configurados para alertar as equipes sobre comprometimentos suspeitos?



(c) Todos os mecanismos, diretrizes e assinaturas para detecção e prevenção contra invasões estão atualizados?

(a) Existem ferramentas de monitoramento da integridade dos arquivos implementadas no ambiente dos dados do titular do cartão?

Os exemplos de arquivos que devem ser monitorados incluem: • Executáveis do sistema • Executáveis dos aplicativos • Arquivos de configuração e parâmetro • Arquivos de log e auditoria, históricos ou arquivados,

armazenados centralmente

11.5

(b) As ferramentas estão configuradas para alertar a equipe sobre a modificação não autorizada de arquivos dos sistemas críticos e de arquivos de configuração ou de conteúdo, com comparação pelo menos uma vez por semana dos arquivos críticos?

Observação: Para fins de monitoramento da integridade dos arquivos, os arquivos críticos normalmente são aqueles que não são alterados com frequência, mas sua modificação poderia indicar um comprometimento do sistema ou um risco de comprometimento. Normalmente, os produtos de monitoramento da integridade dos arquivos vêm pré-configurados com arquivos críticos para o sistema operacional relacionado. Outros arquivos críticos, como aqueles dos aplicativos personalizados, devem ser avaliados e definidos pela entidade (ou seja, o comerciante ou prestador de serviços).


Manter uma política de segurança de informações Requisito 12: Manter uma política que aborde a segurança das informações para todas

as equipes


12.1 Existe uma política de segurança estabelecida, publicada, mantida e disseminada para todas as equipes relevantes? Para as finalidades do Requisito 12, "equipe" refere-se a funcionários que trabalham em período integral e meio-período, funcionários e equipes temporárias, e prestadores de serviços e consultores que "residem" no endereço da entidade ou têm acesso ao ambiente de dados do titular do cartão.

12.1.1 A política cumpre todos os requisitos do PCI DSS?

(a) Existe algum processo anual documentado de avaliação de risco que identifique ameaças e vulnerabilidades, resultando em uma avaliação de risco formal?

(Os exemplos de metodologias de avaliação de risco incluem, entre outros, OCTAVE, ISO 27005 e NIST SP 800-30.)

12.1.2

(b) O processo de avaliação de risco é executado pelo menos uma vez por ano?

12.1.3

A política de segurança das informações é analisada pelo menos uma vez por ano e atualizada conforme necessário para refletir as alterações nos objetivos de negócios ou no ambiente de risco?

12.2 São desenvolvidos procedimentos de segurança operacional diariamente que estejam em conformidade com os requisitos desta especificação (como procedimentos de manutenção da conta do usuário e procedimentos de análise de logs) que incluem procedimentos técnicos e administrativos para cada requisito?

12.3 Existem políticas de utilização para tecnologias críticas (por exemplo: tecnologias de acesso remoto, tecnologias sem fio, mídia eletrônica removível, laptops, tablets, dados pessoais/assistentes digitais (PDAs), uso de e-mail e uso da Internet) desenvolvidas para definir o uso adequado dessas tecnologias para todas as equipes que requerem:

12.3.1 Aprovação explícita pelas partes autorizadas para uso das tecnologias?

12.3.2 Autenticação para o uso da tecnologia?

12.3.3 Uma lista de todos esses dispositivos e equipes com acesso?

12.3.4 Identificação dos dispositivos para determinar o proprietário, informações de contato e a finalidade?

12.3.5 Usos aceitáveis das tecnologias?



12.3.6 Locais de rede aceitáveis para as tecnologias?

12.3.7 Lista dos produtos aprovados pela empresa?

12.3.8 Desconexão automática das sessões para tecnologias de acesso remoto após um período específico de inatividade?

12.3.9 Ativação de tecnologias de acesso remoto para fornecedores e parceiros de negócio somente quando lhes for necessário, com desativação imediata após o uso?

(a) No acesso da equipe aos dados do titular do cartão por meio de tecnologias de acesso remoto, a política especifica a proibição de cópia, transferência e armazenamento dos dados do titular do cartão em discos rígidos locais e mídias eletrônicas removíveis, exceto quando explicitamente autorizado para uma necessidade comercial definida?

12.3.10

(b) Para membros da equipe com autorização adequada, a política exige a proteção dos dados do titular do cartão de acordo com os Requisitos do PCI DSS?

12.4 A política e os procedimentos de segurança definem claramente as responsabilidades quanto à segurança das informações para todas as equipes?

A responsabilidade pela segurança das informações é atribuída formalmente para uma pessoa responsável pela segurança ou para outro membro da gerência que tenha conhecimento sobre segurança?

12.5

As seguintes responsabilidades do gerenciamento da segurança da informação são atribuídas formalmente para as pessoas e para as equipes que:

12.5.1 Estabelecem, documentam e distribuem políticas e procedimentos de segurança?

12.5.2 Monitoram e analisam os alertas e as informações de segurança e os distribui para as equipes apropriadas?

12.5.3 Estabelecem, documentam e distribuem procedimentos de resposta e escalação de incidentes de segurança para assegurar que todas as situações sejam abordadas de modo oportuno e eficiente?

12.5.4 Administram as contas dos usuários, incluindo adições, exclusões e modificações?

12.5.5 Monitoram e controlam todos os acessos aos dados?

(a) Existe algum programa formal de conscientização da segurança em vigor para conscientizar todas as equipes sobre a importância da segurança dos dados do titular do cartão?

12.6

(b) Os procedimentos do programa de conscientização da segurança incluem os itens a seguir?


Pergunta do PCI DSS Resposta: Sim Não Especial* (a) O programa de conscientização da segurança fornece

vários métodos para comunicação da conscientização e instrução da equipe (como cartazes, cartas, memorandos, treinamento baseado na Web, reuniões e promoções)?

Observação: Os métodos podem variar dependendo da função de cada funcionário e do nível de acesso aos dados do titular do cartão.

12.6.1

(b) As equipes são instruídas na contratação e depois pelo menos uma vez ao ano?

12.6.2 Os membros da equipe devem reconhecer, pelo menos uma vez por ano, que leram e compreenderam a política e os procedimentos de segurança da empresa?

12.7 Os possíveis funcionários (consulte a definição de "funcionário" no Requisito 12.1 acima) são examinados antes da contratação para minimizar o risco de ataques de fontes internas? (Exemplos de verificações da formação incluem o histórico do emprego anterior, ficha criminal, histórico de crédito e verificações das referências.) Observação: Para a contratação de funcionários para certas funções, como os caixas de loja que têm acesso somente a um número do cartão por vez ao viabilizar uma transação, este requisito é apenas uma recomendação.

12.8 Se os dados do titular do cartão forem compartilhados com prestadores de serviços, existem políticas e procedimentos mantidos e implementados para gerenciar prestadores de serviços, conforme os itens a seguir:

12.8.1 É mantida uma lista de prestadores de serviços?

12.8.2 É mantido um acordo por escrito que inclua um reconhecimento de que os prestadores de serviços são responsáveis pela segurança dos dados do titular do cartão que eles possuírem?

12.8.3 Existe um processo definido para a contratação dos prestadores de serviços, incluindo uma diligência devida adequada antes da contratação?

12.8.4 É mantido um programa para monitorar anualmente o status de conformidade com o PCI DSS dos prestadores de serviços?

12.9 Foi implementado um plano de resposta a incidentes para incluir o seguinte, em preparação a reagir imediatamente a uma violação no sistema?

(a) Foi criado um plano de resposta a incidentes para ser implementado em caso de violação do sistema?

12.9.1

(b) O plano aborda, pelo menos:



Funções, responsabilidades e estratégias de comunicação e contato no caso de um comprometimento, incluindo, no mínimo, a notificação às bandeiras?

Procedimentos de resposta específicos a incidentes?

Procedimentos de recuperação e continuidade dos negócios?

Processos de backup dos dados?

Análise dos requisitos legais para divulgação dos comprometimentos?

Abrangência e respostas de todos os componentes críticos do sistema?

Referência ou inclusão de procedimentos de resposta a incidentes por parte das bandeiras?

12.9.2 O plano é testado pelo menos anualmente?

12.9.3 Equipes específicas são designadas para estarem disponíveis em tempo integral para reagir aos alertas?

12.9.4 O treinamento adequado é prestado à equipe que é responsável pela resposta às falhas do sistema?

12.9.5 Os alertas dos sistemas de detecção de invasão, prevenção contra invasões e monitoramento da integridade dos arquivos estão incluídos no plano de resposta a incidentes?

12.9.6 Existe algum processo em vigor para modificar e aprimorar o plano de resposta a incidentes, de acordo com as lições aprendidas, para incorporar os desenvolvimentos do setor?

SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação, Anexo A Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 35

Anexo A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada

Requisito A.1: Os provedores de hospedagem compartilhada devem proteger o ambiente de dados do titular do cartão


A.1 O ambiente hospedado e os dados de cada entidade (seja comerciante, prestador de serviços ou outra entidade) estão protegidos de acordo com os itens A.1.1 a A.1.4, conforme a descrição a seguir? O provedor de hospedagem deve cumprir esses requisitos e todas as outras seções relevantes do PCI DSS. Observação: Mesmo que o provedor de hospedagem cumpra esses requisitos, a conformidade da entidade que usa o provedor de hospedagem não está assegurada. Cada entidade deve estar em conformidade com o PCI DSS e validar a conformidade, conforme aplicável.

A.1.1 Cada entidade executa processos que acessam somente o ambiente de dados do titular de cartão da entidade e esses processos de aplicativos são executados usando um ID exclusivo da entidade? Por exemplo:

• Nenhuma entidade no sistema pode usar um ID de usuário do servidor da Web compartilhado.

• Todos os scripts CGI usados por uma entidade devem ser criados e executados como o ID do usuário exclusivo da entidade.

Os acessos e privilégios de acesso de cada entidade são restritos ao seu ambiente próprio de dados do titular do cartão?

(a) Os IDs de usuário dos processos de aplicativos não são usuários com acesso privilegiado (raiz/admin)?

(b) Cada entidade leu, gravou ou executou somente as permissões referentes aos arquivos e diretórios que possui ou para os arquivos de sistema necessários (restringidos por meio das permissões do sistema de arquivo, listas de controle de acesso, chroot, jailshell, etc.)?

Importante: Os arquivos de uma entidade não podem ser compartilhados em grupo.

(c) Todos os usuários da entidade não têm acesso de gravação aos arquivos binários compartilhados do sistema?

A.1.2

(d) A visualização das entradas de log é restrita à entidade detentora?

SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação, Anexo A Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 36


(e) Existem restrições em vigor para o uso destes recursos do sistema? • Espaço em disco, • Largura de banda, • Memória, • CPU

Isso é feito para assegurar que as entidades não possam monopolizar os recursos do servidor para explorar as vulnerabilidades (como condições de erro, aceleração e reinicialização, resultando em excessos de buffer),

Os logs e as trilhas de auditoria estão ativados e são exclusivos para o ambiente de dados do titular do cartão de cada entidade, além de estarem em conformidade com o Requisito 10 do PCI DSS? O log está ativado conforme a descrição a seguir em cada ambiente do comerciante e do prestador de serviços?

• Os logs estão ativados para aplicativos de terceiros comuns?

• Os logs estão ativados por padrão?

• Os logs estão disponíveis para análise pela entidade detentora?

A.1.3

• As localizações dos logs são informadas com clareza à entidade detentora?

A.1.4 Existem processos e políticas por escrito ativados para fornecer uma investigação forense oportuna no caso de um comprometimento em qualquer comerciante ou prestador de serviços hospedado?

SAQ D do PCI DSS, v2.0, Anexo B: Controles de compensação Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 37

Apêndice B: Controles de compensação Os controles de compensação podem ser considerados na maioria dos requisitos do PCI DSS quando uma entidade não for capaz de atender a um requisito de forma explícita, conforme informado, devido a restrições de negócios documentadas ou técnicas legítimas, mas minimizou o risco associado ao requisito de modo suficiente por meio da implementação de outros controles, incluindo os de compensação. Os controles de compensação devem atender aos seguintes critérios:

1. Atender a intenção e o rigor do requisito original do PCI DSS.

2. Fornecer um nível semelhante de defesa ao requisito original do PCI DSS, como o controle de compensação que contrabalança o risco de modo suficiente para o qual o requisito original do PCI DSS tenha sido criado para fornecer uma defesa. (Consulte a seção Navegando no PCI DSS para obter informações sobre a intenção de cada requisito do PCI DSS.)

3. Estar "acima e além" dos outros requisitos do PCI DSS. (Simplesmente estar em conformidade com os requisitos do PCI DSS não é um controle de compensação.)

Ao utilizar o critério de avaliação "acima e além" para controles de compensação, considere o seguinte:

Observação: Os itens nas alternativas a) a c) abaixo são apenas exemplos. Todos os controles de compensação devem ser analisados e validados quanto à suficiência pelo responsável pela avaliação que realiza a análise do PCI DSS. A efetividade de um controle de compensação depende das especificidades do ambiente no qual o controle está implementado, dos controles de segurança ao redor e da configuração do controle. As empresas devem estar cientes de que um determinado controle de compensação não será efetivo em todos os ambientes.

a) Os requisitos existentes do PCI DSS NÃO PODERÃO ser considerados como controles de compensação se já tiverem sido exigidos para o item sob análise. Por exemplo: as senhas para o acesso administrativo realizado fora do console devem ser enviadas criptografadas para minimizar o risco de interceptação de senhas administrativas em texto simples. As entidades não podem usar outros requisitos de senha do PCI DSS (bloqueio de intruso, senhas complexas, etc.) para compensar a falta de senhas criptografadas, uma vez que os outros requisitos de senha não diminuem o risco de interceptação de senhas de texto simples. Além disso, os outros controles de senha já são requisitos do PCI DSS referentes ao item sob análise (senhas).

b) Os requisitos existentes do PCI DSS PODERÃO ser considerados como controles de compensação se forem exigidos para outra área, mas não para o item sob análise. Por exemplo: uma autenticação com dois fatores é um requisito do PCI DSS para o acesso remoto. A autenticação com dois fatores a partir da rede interna também pode ser considerada um controle de compensação para o acesso administrativo fora do console quando não houver suporte para a transmissão de senhas criptografadas. A autenticação com dois fatores poderá ser um controle de compensação aceitável se (1) atender à intenção do requisito original ao abordar o risco de interceptação de senhas administrativas em texto simples e (2) for configurada de modo adequado e em um ambiente seguro.

c) Os requisitos existentes do PCI DSS podem ser combinados com novos controles para se tornarem um controle de compensação. Por exemplo: se uma empresa não for capaz de tornar os dados do titular do cartão ilegíveis de acordo com o requisito 3.4 (por exemplo, por meio da criptografia), um controle de compensação poderia consistir de um dispositivo ou uma combinação de dispositivos, aplicativos e controles que abordam todos os itens a seguir: (1) segmentação da rede interna; (2) filtragem de endereço IP ou endereço MAC; e (3) autenticação com dois fatores dentro da rede interna.

4. Ser proporcional ao risco adicional imposto pelo não cumprimento do requisito do PCI DSS.

SAQ D do PCI DSS, v2.0, Anexo B: Controles de compensação Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 38

O responsável pela avaliação deve analisar os controles de compensação por completo durante cada avaliação anual do PCI DSS para validar se cada controle de compensação aborda adequadamente o risco para o qual o requisito do PCI DSS original foi elaborado, de acordo com os itens 1 a 4 acima. Para manter a conformidade, os processos e controles devem estar implementados para assegurar que os controles de compensação permaneçam efetivos após a conclusão da avaliação.

SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensação Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 39

Anexo C: Planilha dos controles de compensação Use esta planilha para definir os controles de compensação com relação a qualquer requisito no qual a opção "SIM" tenha sido assinalada e os controles de compensação tenham sido mencionados na coluna "Especial".

Observação: Somente as empresas que realizaram uma análise dos riscos e têm restrições de negócios documentadas ou tecnológicas legítimas podem considerar o uso dos controles de compensação para atingir a conformidade.

Número e definição do requisito:

Informações necessárias Explicação

1. Restrições Listar as restrições que impossibilitam a conformidade com o requisito original.

2. Objetivo Definir o objetivo do controle original; identificar o objetivo atendido pelo controle de compensação.

3. Risco identificado Identificar qualquer risco adicional imposto pela ausência do controle original.

4. Definição dos controles de compensação

Definir os controles de compensação e explicar como eles abordam os objetivos do controle original e o aumento dos riscos, caso haja algum.

5. Validação dos controles de compensação

Definir como os controles de compensação foram validados e testados.

6. Manutenção Definir o processo e os controles implementados para manter os controles de compensação.

SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensação Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 40

Planilha dos controles de compensação – Exemplo completo Use esta planilha para definir os controles de compensação com relação a qualquer requisito no qual a opção "SIM" tenha sido assinalada e os controles de compensação tenham sido mencionados na coluna "Especial".

Número do requisito: 8.1 — Todos os usuários são identificados com um nome de usuário exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do cartão?

Informações necessárias Explicação

1. Restrições Listar as restrições que impossibilitam a conformidade com o requisito original.

A empresa XYZ utiliza Servidores Unix independentes sem LDAP. Sendo assim, cada um deles requer um login "raiz". A empresa XYZ não pode gerenciar o login "raiz" nem é possível registrar todas as atividades "raiz" por usuário.

2. Objetivo Definir o objetivo do controle original; identificar o objetivo atendido pelo controle de compensação.

O objetivo de exigir logins exclusivos é duplo. Primeiro, não é considerado aceitável, da perspectiva de segurança, compartilhar credenciais de login. Segundo, ter logins compartilhados impossibilita afirmar em definitivo quem é responsável por uma determinada ação.

3. Risco identificado Identificar qualquer risco adicional imposto pela ausência do controle original.

O risco adicional ocorre no sistema de controle de acesso ao não assegurar que todos os usuários tenham um ID exclusivo e possam ser monitorados.

4. Definição dos controles de compensação

Definir os controles de compensação e explicar como eles abordam os objetivos do controle original e o aumento dos riscos, caso haja algum.

A empresa XYZ solicitará que todos os usuários efetuem login nos servidores a partir dos seus desktops usando o comando SU. Esse comando permite que um usuário acesse a conta "raiz" e desempenhe ações na conta "raiz", mas possa efetuar login no diretório de log do SU. Nesse caso, as ações de cada usuário podem ser monitoradas por meio da conta do SU.

5. Validação dos controles de compensação

Definir como os controles de compensação foram validados e testados.

A empresa XYZ demonstra ao responsável pela avaliação o comando SU que está sendo executado e que as pessoas que estão usando o comando efetuaram login para identificar que o indivíduo está desempenhando ações com privilégios raiz.

6. Manutenção Definir o processo e os controles implementados para manter os controles de compensação.

A empresa XYZ documenta os processos e procedimentos para assegurar que as configurações do SU não sejam modificadas, alteradas ou removidas para permitir que os usuários individuais executem comandos raiz sem serem monitorados ou efetuarem login individualmente.

SAQ D do PCI DSS, v2.0, Anexo D: Explicação de não aplicabilidade Outubro de 2010 Copyright 2010 PCI Security Standards Council LLC Página 41

Apêndice D: Explicação de não aplicabilidade Se "N/A" ou "Não aplicável" tiver sido inserido na coluna "Especial", use esta planilha para explicar por que o requisito relacionado não se aplica à sua organização.

Requisito Motivo pelo qual o requisito não se aplica

Exemplo: 9.3.1

Os visitantes não pode entrar em áreas onde os dados do titular do cartão são processados ou guardados.

SAQ_D_v20_12_2_10_form_PT-BR.pdf

Documents

Transcript of SAQ_D_v20_12_2_10_form_PT-BR.pdf