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
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, Alterações no documento
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página i
Í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
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página ii
Apêndice D:
Explicação de não aplicabilidade .................................................. 41
SAQ D do PCI DSS, v2.0, Índice
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página iii
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.
1
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
Todos os comerciantes e
prestadores de serviços
Padrão de segurança de dados do PCI:
Diretrizes e instruções de auto-avaliação
Todos os comerciantes e
prestadores de serviços
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
Comerciantes qualificados1
Padrão de segurança de dados do PCI:
Questionário C-VT de auto-avaliação e atestado
Comerciantes qualificados1
Padrão de segurança de dados do PCI:
Questionário C de auto-avaliação e atestado
Comerciantes qualificados1
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
Todos os comerciantes e
prestadores de serviços
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, Padrão de segurança de dados do PCI: Documentos relacionados
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página iv
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
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página v
SAQ D do PCI DSS, v2.0, Antes de você começar
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página vi
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, Antes de você começar
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página vii
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):
Forma de
tratamento:
Contato:
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:
Forma de
tratamento:
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 1
Telefone:
E-mail:
Endereço comercial:
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
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 2
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,
3
4
CID ou CVV2 , ou dados de PIN 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.
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 3
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
4
Descrição do requisito
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
SIM
NÃO
Data e ações de correção
(se o Status de
conformidade for "Não")
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.
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 4
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
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 5
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):
Forma de
tratamento:
Contato:
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:
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 1
Nome do contato principal
do QSA:
Forma de
tratamento:
Telefone:
E-mail:
Endereço comercial:
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 –
Hardware
Processamento
pagamentos – ATM
de
Provedor de hospedagem –
Web
Processamento
pagamentos – MOTO
de
Autorização
Processamento de emissões
Processamento
pagamentos – Internet
de
Serviços de back-office
Programas de fidelidade
Processamento
pagamentos – POS
de
Gerenciamento do faturamento
Serviços gerenciados
Serviços
adiantado
Compensação e liquidação
Serviços do comerciante
Provedor de hospedagem segura
3-D
Gerenciamento de contas
Preparação de dados
Fraude e serviços de cobrança
Fornecedor/transmissor
com
pagamento
Gerenciamento de registros
de
redes
Taxas/pagamentos
governo
para
o
Gateway/switch de pagamento
Outros (especificar):
Listar as instalações e locais incluídos na análise do PCI DSS:
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 2
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 –
Hardware
Processamento
pagamentos – ATM
de
Provedor de hospedagem –
Web
Processamento
pagamentos – MOTO
de
Autorização
Processamento de emissões
Processamento
pagamentos – Internet
de
Serviços de back-office
Programas de fidelidade
Processamento
pagamentos – POS
de
Gerenciamento do faturamento
Serviços gerenciados
Serviços
adiantado
Compensação e liquidação
Serviços do comerciante
Provedor de hospedagem segura
3-D
Gerenciamento de contas
Preparação de dados
Fraude e serviços de cobrança
Fornecedor/transmissor
com
pagamento
Gerenciamento de registros
de
redes
Taxas/pagamentos
governo
para
o
Gateway/switch de pagamento
Outros (especificar):
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
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 3
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..
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 4
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.
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 5
Status de
conformidade
(selecione um)
Requisito do
PCI DSS
Descrição do requisito
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
SIM
NÃO
Data e ações de correção
(se o Status de
conformidade for "Não")
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, Atestado de conformidade, Versão do comerciante
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 6
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
1.1
Resposta:
Sim
Não
Especial*
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?
1.1.2
(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?
(b) Esse diagrama é mantido atualizado?
1.1.3
(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?
(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?
1.1.5
(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)?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 1
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(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.
1.2.1
(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?
(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.3
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?
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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 2
Pergunta do PCI DSS
Resposta:
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?
1.3.8
(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?
Sim
Não
Especial*
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.
(b) A divulgação dos endereços IP privados e das
informações de roteamento para entidades externas é
autorizada?
1.4
(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?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 3
Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema
e outros parâmetros de segurança
Pergunta do PCI DSS
2.1
Resposta:
Sim
Não
Especial*
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.
2.1.1
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?
(e) Os outros padrões relacionados à segurança do
fornecedor de dispositivos sem fio são alterados, se
aplicável?
2.2
(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?
(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.)
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 4
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(b) Se forem usadas tecnologias de virtualização, somente
uma função principal está implementada por componente
ou dispositivo do sistema virtual?
2.2.2
(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)?
(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.)
2.2.3
(a) Os administradores do sistema e/ou equipes que
configuram os componentes do sistema estão beminformados 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?
(c) As configurações dos parâmetros de segurança estão
definidas corretamente nos componentes do sistema?
2.2.4
(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?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 5
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(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.
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 6
Proteger os dados do titular do cartão
Requisito 3: Proteger os dados armazenados do titular do cartão
Pergunta do PCI DSS
3.1
Resposta:
Sim
Não
Especial*
As políticas e procedimentos de retenção e eliminação de dados
são implementadas conforme a seguir:
3.1.1
(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.
(e) Todos os dados armazenados do titular do cartão
cumprem os requisitos definidos na política de retenção
de dados?
3.2
(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?
(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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 7
Pergunta do PCI DSS
3.3
Resposta:
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?
Sim
Não
Especial*
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).
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 8
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
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.
3.4
3.4.1
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)?
(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.
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
3.5.1
O acesso às chaves criptográficas está restrito ao menor
número necessário de responsáveis pela proteção?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 9
Pergunta do PCI DSS
3.5.2
Resposta:
Sim
Não
Especial*
(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?
(b) As chaves criptográficas são armazenadas no menor
número possível de locais e formas?
3.6
(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?
(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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 10
Pergunta do PCI DSS
Resposta:
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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Sim
Não
Especial*
Outubro de 2010
Página 11
Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas
e públicas
Pergunta do PCI DSS
4.1
Resposta:
Sim
Não
Especial*
(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)?
(e) Para implementações de SSL/TLS:
•
•
4.1.1
4.2
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?
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)?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 12
Manter um programa de gerenciamento de vulnerabilidades
Requisito 5: Usar e atualizar regularmente o software ou programas antivírus
Pergunta do PCI DSS
5.1
Sim
Não
Especial*
Sim
Não
Especial*
Os softwares antivírus estão implementados em todos os sistemas
normalmente afetados por softwares mal-intencionados?
5.1.1
5.2
Resposta:
Todos os programas antivírus podem detectar, remover e
proteger contra todos os tipos conhecidos de softwares malintencionados (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?
(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
Pergunta do PCI DSS
6.1
Resposta:
(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?
(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.
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 13
Pergunta do PCI DSS
6.2
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.
(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?
6.3
(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)?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 14
Pergunta do PCI DSS
6.3.2
6.4
Resposta:
Sim
Não
Especial*
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.
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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 15
Pergunta do PCI DSS
Resposta:
6.4.5.1
Documentação de impacto
6.4.5.2
Aprovação documentada pelas partes autorizadas
6.4.5.3
Sim
Não
Especial*
(a) Testes de funcionalidade para verificar se a alteração
não tem impacto adverso sobre a segurança do sistema
(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
6.5
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?
(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.)
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 16
Pergunta do PCI DSS
6.5.6
Resposta:
Sim
Não
Especial*
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.6
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.)
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.
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 17
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
Pergunta do PCI DSS
7.1
Resposta:
Sim
Não
Especial*
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.
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 18
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao
computador
Pergunta do PCI DSS
Resposta:
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
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.
8.3
8.4
Sim
Não
Especial*
(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?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 19
Pergunta do PCI DSS
Resposta:
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?
8.5.6
(a) As contas usadas pelos fornecedores para acesso
remoto, manutenção ou suporte são ativadas somente
durante o período necessário?
Sim
Não
Especial*
(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.
8.5.9
(a) As senhas dos usuários são alteradas pelo menos a
cada 90 dias?
(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?
8.5.10
(a) É exigido um comprimento mínimo de senha de pelo
menos sete caracteres?
(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?
8.5.11
(a) As senhas devem conter caracteres numéricos e
alfabéticos?
(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?
8.5.12
(a) A pessoa deve escolher uma nova senha que seja
diferente das quatro últimas senhas utilizadas?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 20
Pergunta do PCI DSS
8.5.13
Resposta:
Sim
Não
Especial*
(a) As tentativas de acesso repetidas são limitadas,
bloqueando o ID do usuários após seis tentativas, no
máximo?
(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?
8.5.16
(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?
(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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 21
Requisito 9: Restringir o acesso físico aos dados do titular do cartão
Pergunta do PCI DSS
9.1
Resposta:
Sim
Não
Especial*
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?
9.1.1
(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?
(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.2
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?
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.
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 22
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?
9.3.2
(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?
(b) O cartão do visitante expira?
9.3.3
9.4
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?
(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?
9.5
(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?
(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.
9.7
(a) É mantido um controle rigoroso quanto à distribuição interna
ou externa de qualquer tipo de mídia?
(b) Os controles incluem o seguinte:
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 23
Pergunta do PCI DSS
Resposta:
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
9.10
Sim
Não
Especial*
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?
A destruição é executada da seguinte forma:
9.10.1
(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?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 24
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
Pergunta do PCI DSS
Resposta:
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.3
10.4
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?
Sim
Não
Especial*
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).
(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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 25
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(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?
10.4.2
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?
(b) As alterações nas configurações de horários dos
sistemas críticos são registradas, monitoradas e
analisadas?
10.4.3
10.5
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).
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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 26
Pergunta do PCI DSS
Resposta:
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.
10.7
(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?
Sim
Não
Especial*
Não
Especial*
(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
11.1
Resposta:
Sim
(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?
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 27
Pergunta do PCI DSS
11.2
Resposta:
Sim
Não
Especial*
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)?
11.2.2
(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)?
(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)?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 28
Pergunta do PCI DSS
11.2.3
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)?
(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)?
11.3
(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)?
Esses testes de penetração incluem os itens a seguir?
11.4
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?
(b) Os IDS e/ou os IPS estão configurados para alertar as equipes
sobre comprometimentos suspeitos?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 29
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(c) Todos os mecanismos, diretrizes e assinaturas para detecção
e prevenção contra invasões estão atualizados?
11.5
(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
(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).
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 30
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
Pergunta do PCI DSS
12.1
Resposta:
Sim
Não
Especial*
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?
12.1.2
(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 80030.)
(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?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 31
Pergunta do PCI DSS
Resposta:
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?
12.3.10
(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?
Sim
Não
Especial*
(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?
12.5
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?
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.6
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?
(b) Os procedimentos do programa de conscientização da
segurança incluem os itens a seguir?
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 32
Pergunta do PCI DSS
12.6.1
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.
(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.9
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?
Foi implementado um plano de resposta a incidentes para incluir o
seguinte, em preparação a reagir imediatamente a uma violação
no sistema?
12.9.1
(a) Foi criado um plano de resposta a incidentes para ser
implementado em caso de violação do sistema?
(b) O plano aborda, pelo menos:
SAQ D do PCI DSS, v2.0, Questionário de auto-avaliação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 33
Pergunta do PCI DSS
Resposta:
ƒ
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
Copyright 2010 PCI Security Standards Council LLC
Sim
Não
Especial*
Outubro de 2010
Página 34
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
Pergunta do PCI DSS
A.1
Resposta:
Sim
Não
Especial*
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
A.1.2
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?
(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
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 35
Pergunta do PCI DSS
Resposta:
Sim
Não
Especial*
(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),
A.1.3
A.1.4
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?
•
As localizações dos logs são informadas com
clareza à entidade detentora?
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, Questionário de auto-avaliação, Anexo A
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 36
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
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 37
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 B: Controles de compensação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 38
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
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
Copyright 2010 PCI Security Standards Council LLC
Explicação
Outubro de 2010
Página 39
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.
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.
Manutenção
SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensação
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 40
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 do PCI DSS, v2.0, Anexo D: Explicação de não aplicabilidade
Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Página 41