PCI DSS Autoavaliacao PCI

Setor de cartes de pagamento (PCI)
Padro de segurana de dados
Questionrio de auto-avaliao D
e Atestado de conformidade
Todos os outros SAQs - Comerciantes e

prestadores de servios qualificados
Verso 2.0
Outubro de 2010
Alteraes no documento
Data
Verso
Descrio
1 de outubro de
2008
1.2
Para alinhar o contedo com o novo PCI DSS v1.2 e para

implementar alteraes menores observadas desde o original v1.1.
28 de outubro de
2010
2.0
Para alinhar o contedo com os novos requisitos e procedimentos de

teste do PCI DSS v2.0.
SAQ D do PCI DSS, v2.0, Alteraes no documento

Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010
Pgina i
ndice
Alteraes no documento ............................................................................................. i
Padro de segurana de dados do PCI: Documentos relacionados ...................... iv
Antes de voc comear ................................................................................................ v
Preenchendo o questionrio de auto-avaliao .................................................................. v
Conformidade do PCI DSS Etapas para preenchimento .................................................. v
Orientao para no aplicabilidade de determinados requisitos especficos..................vii
Atestado de conformidade, SAQ D Verso do comerciante ................................. 1

Atestado de conformidade, SAQ D Verso do prestador de servios ................. 1
Questionrio de auto-avaliao D................................................................................ 1
Construir e manter uma rede segura ................................................................................... 1
Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados ........... 1
Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e
outros parmetros de segurana ............................................................. 4
Proteger os dados do titular do carto ................................................................................ 7
Requisito 3: Proteger os dados armazenados do titular do carto ........................................ 7
Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas e
pblicas ..................................................................................................12
Manter um programa de gerenciamento de vulnerabilidades ...........................................13
Requisito 5: Usar e atualizar regularmente o software ou programas antivrus...................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 carto de acordo com a
necessidade de conhecimento para o negcio .......................................18
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao
computador ............................................................................................19
Requisito 9: Restringir o acesso fsico aos dados do titular do carto .................................22
Monitorar e testar as redes regularmente ...........................................................................25
Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da rede
e aos dados do titular do carto .............................................................25
Requisito 11: Testar regularmente os sistemas e processos de segurana.........................27
Manter uma poltica de segurana de informaes ...........................................................31
Requisito 12: Manter uma poltica que aborde a segurana das informaes 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 carto .......................................................................35
Apndice B:
Controles de compensao ........................................................... 37
Anexo C:
Planilha dos controles de compensao ...................................... 39
Planilha dos controles de compensao Exemplo completo.........................................40

SAQ D do PCI DSS, v2.0, ndice
Outubro de 2010
Pgina ii
Apndice D:
Explicao de no aplicabilidade .................................................. 41
SAQ D do PCI DSS, v2.0, ndice

Outubro de 2010
Pgina iii
Padro de segurana de dados do PCI: Documentos relacionados

Os documentos a seguir foram criados para auxiliar comerciantes e prestadores de servios a
entenderem o Padro de segurana de dados do PCI (PCI DSS) e o SAQ do PCI DSS.
Documento
Pblico
Padro de segurana de dados do PCI:

Requisitos e procedimentos da avaliao de segurana
Todos os comerciantes e
prestadores de servios
Navegando pelo PCI DSS:

Entendendo o porqu dos requisitos

Diretrizes e instrues de auto-avaliao

Questionrio A de auto-avaliao e atestado
Comerciantes qualificados

Questionrio B de auto-avaliao e atestado

Questionrio C-VT de auto-avaliao e atestado

Questionrio C de auto-avaliao e atestado

Questionrio D de auto-avaliao e atestado
Comerciantes e prestadores
1
de servios qualificados
Padro de segurana de dados do PCI e Padro de segurana

de dados de aplicativos de pagamento:
Glossrio de termos, abreviaes e acrnimos
Para determinar o Questionrio de auto-avaliao adequado, consulte o Padro de segurana de

dados do PCI: Diretrizes e instrues de auto-avaliao, "Selecionando o SAQ e o Atestado que
melhor se aplicam sua organizao".
SAQ D do PCI DSS, v2.0, Padro de segurana de dados do PCI: Documentos relacionados
Outubro de 2010
Pgina iv
Antes de voc comear

Preenchendo o questionrio de auto-avaliao
O SAQ D foi desenvolvido para todos os prestadores de servios qualificados pelo SAQ e para todos os
comerciantes que no se encaixem nas descries dos SAQs A a C, conforme descrito brevemente na
tabela abaixo e integralmente nas Diretrizes e instrues do Questionrio de auto-avaliao do PCI DSS.
SAQ
Descrio
Comerciantes do tipo carto no presente (comrcio eletrnico ou pedidos por

correio/telefone), todas as funes dos dados do titular do carto so terceirizadas.
Isso nunca se aplica a comerciantes presenciais.
Comerciantes com mquinas de carbono, sem armazenamento eletrnico dos

dados do titular do carto, ou comerciantes com terminais de discagem
independentes, sem armazenamento eletrnico dos dados do titular do carto
C-VT
Comerciantes que usam somente terminais virtuais baseados na Web, sem

armazenamento eletrnico dos dados do titular do carto
Comerciantes com sistemas de aplicativos de pagamento conectados Internet,

sem armazenamento eletrnico dos dados do titular do carto
Todos os outros comerciantes (no includos nas descries dos SAQs A a C

acima) e todos os prestadores de servios definidos por uma bandeira como
qualificados para preencherem um SAQ.
O SAQ D se aplica a todos os comerciantes qualificados para preencher o SAQ no includos nas
descries dos SAQs A a C acima e todos os prestadores de servios definidos por uma bandeira como
sendo qualificados para preencher o SAQ. Os prestadores de servios e comerciantes do SAQ D
validam a conformidade ao preencherem o SAQ D e o Atestado de conformidade associado.
Apesar de vrias organizaes que preenchem o SAQ D precisarem validar a conformidade com todos
os requisitos do PCI DSS, algumas organizaes com modelos de negcio bastante especficos podem
descobrir que alguns requisitos no se aplicam. Por exemplo: no se espera que uma empresa que no
usa tecnologia sem fio de forma alguma valide a conformidade com as sees do PCI DSS que so
especficas da tecnologia sem fio. Consulte a orientao abaixo para obter informaes sobre a excluso
da tecnologia sem fio e de outros requisitos especficos.
Cada seo deste questionrio se concentra em uma rea especfica de segurana, com base nas
exigncias do PCI DSS.
Conformidade do PCI DSS Etapas para preenchimento

1. Avalie seu ambiente quanto conformidade com o PCI DSS.
2. Preencha o Questionrio de auto-avaliao (SAQ D) segundo as instrues do arquivo Diretrizes
e instrues do Questionrio de auto-avaliao do PCI DSS.
3. Faa uma varredura de vulnerabilidade aprovada com um Fornecedor de varredura aprovado
(ASV) do PCI SSC e obtenha a comprovao de uma varredura aprovada com o ASV.
4. Preencha integralmente o Atestado de conformidade.
5. Envie o SAQ, a comprovao de uma varredura aprovada e o Atestado de conformidade, junto
com qualquer outra documentao solicitada, ao adquirente (para comerciantes) ou bandeira
de pagamento ou outro solicitante (para prestadores de servios).
SAQ D do PCI DSS, v2.0, Antes de voc comear
Outubro de 2010
Pgina v

Outubro de 2010
Pgina vi
Orientao para no aplicabilidade de determinados requisitos especficos

Excluso: Se voc precisar responder o SAQ D para validar sua conformidade com o PCI DSS, as
seguintes excees podem ser consideradas. Consulte a seo "No aplicabilidade" abaixo para obter
uma resposta adequada do SAQ.
As perguntas especficas relacionadas a dispositivos sem fio s precisaro 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
no autorizados) dever ser respondido, mesmo que o dispositivo sem fio no esteja na sua rede,
pois o processo detecta intrusos ou dispositivos no autorizados que possam ter sido adicionados
sem seu conhecimento.
As questes especficas para aplicativos e cdigos personalizados (Requisitos 6.3 e 6.5) s

precisaro ser respondidas se sua organizao desenvolver seus prprios aplicativos
personalizados.
As perguntas dos Requisitos 9.1 a 9.4 s precisaro ser respondidas para instalaes 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 carto. 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 carto e reas de
armazenamento para grandes quantidades de dados do titular do carto.
No aplicabilidade: Este e outros requisitos considerados no aplicveis ao seu ambiente devero ser
indicados com "N/A" na coluna "Especial" do SAQ. Da mesma forma, preencha a planilha "Explicao de
no aplicabilidade" no Anexo D para cada entrada "N/A".

Outubro de 2010
Pgina vii
Atestado de conformidade, SAQ D Verso do comerciante

Instrues para envio
O comerciante deve preencher este Atestado de Conformidade como uma declarao do status de conformidade
dele com os Requisitos do padro de segurana de dados do setor de cartes de pagamento (PCI DSS) e
procedimentos da avaliao de segurana. Preencha todas as sees aplicveis e consulte as instrues de envio
em Conformidade do PCI DSS Etapas para preenchimento, neste documento.
Parte 1. Informaes sobre o comerciante e o avaliador de segurana qualificado

Parte 1a. Informaes sobre a organizao do comerciante
Nome da empresa:
DBA(s):
Contato:
Forma de
tratamento:
Telefone:
E-mail:
Endereo comercial:
Cidade:
Estado/Provncia:
Pas:
CEP:
URL:
Parte 1b. Informaes sobre a empresa do assessor de segurana qualificado (se aplicvel)
Nome da empresa:
Nome do contato principal
do QSA:
Forma de
tratamento:
Telefone:
E-mail:
Endereo comercial:
Cidade:
Estado/Provncia:
Pas:
CEP:
URL:
Parte 2. Tipo de negcio do comerciante (assinale todas as alternativas que se

aplicam):
Varejo
Telecomunicaes
Gneros alimentcios e supermercados
Petrleo
Comrcio eletrnico
Pedido por correio/telefone
Outros (especificar):
Listar as instalaes e locais includos na anlise do PCI DSS:
Parte 2a. Relaes

Sua empresa se relaciona com um ou mais agentes de terceiros (por exemplo: gateways,
empresas de hospedagem na Web, agentes de passagens areas, agentes de
programas de fidelidade, etc.)?
Sim
No
Sua empresa se relaciona com mais de um adquirente?
Sim
No
Parte 2b. Processamento das transaes

Como e em qual capacidade seu negcio armazena, processa e/ou transmite dados do titular do carto?
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Verso do comerciante
Outubro de 2010
Pgina 1
Fornea as seguintes informaes relacionadas aos aplicativos de pagamentos usados pela sua
organizao:
Aplicativo de pagamento em uso
Nmero da
verso
ltima validao de acordo com o

PABP/PA-DSS
Parte 3. Validao 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 sees do SAQ do PCI esto preenchidas, todas as perguntas foram
respondidas afirmativamente, resultando em uma classificao geral de CONFORMIDADE, e uma varredura
de verificao 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.
No conformidade: Nem todas as sees do SAQ do PCI esto preenchidas ou algumas perguntas foram
respondidas negativamente, resultando em uma classificao geral de NO CONFORMIDADE, ou uma
varredura de verificao aprovada no foi preenchida por um Fornecedor de varredura aprovado do PCI
SSC, de forma que a (Nome da empresa do comerciante) no demonstrou conformidade integral com o PCI
DSS.
Data prevista para conformidade:
A entidade que estiver enviando este formulrio com um status de No conformidade talvez tenha de
preencher o Plano de ao 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
seo.
Parte 3a. Confirmao do status de conformidade

O comerciante confirma que:
O Questionrio de Auto-avaliao D do PCI DSS, verso (verso do SAQ), foi preenchido segundo as
instrues nele contidas.
Todas as informaes contidas no SAQ mencionado anteriormente e neste atestado representam
adequadamente os resultados de minha avaliao em todos os aspectos materiais.
Eu confirmei com meu fornecedor do aplicativo de pagamento que o aplicativo no armazena dados de
autenticao confidenciais aps a autorizao.
Eu li o PCI DSS e reconheo que sempre devo manter a conformidade total com o PCI DSS.
2
No h evidncia de armazenamento de dados de tarja magntica (ou seja, rastros) , dados CAV2, CVC2,
3
4
CID ou CVV2 , ou dados de PIN aps a autorizao da transao em NENHUM sistema revisto durante
esta avaliao.
Dados codificados na tarja magntica ou dados equivalentes em um chip usados para autorizao durante a transao com o
carto. As entidades no podem manter todos os dados da tarja magntica aps a autorizao da transao. Os nicos
elementos dos dados de rastro que podem ser retidos so o nmero da conta, a data de vencimento e o nome.
O valor de trs ou quatro dgitos impresso direita do painel de assinatura ou na frente do carto de pagamento usado para
verificar transaes com carto no presente.
Nmero de identificao pessoal inserido pelo titular do carto durante uma transao com o carto e/ou bloqueio de PIN
criptografado dentro da mensagem da transao.

Outubro de 2010
Pgina 2
Parte 3b. Reconhecimento do comerciante
Assinatura do responsvel executivo pelo comerciante
Data
Nome do responsvel executivo pelo comerciante
Forma de tratamento
Empresa comerciante representada
Parte 4. Plano de ao para status de no conformidade

Selecione o "Status de conformidade" adequado para cada requisito. Se voc responder "NO" a qualquer um
dos requisitos, ser necessrio informar a data na qual a empresa estar em conformidade com o requisito e uma
descrio resumida das aes que esto 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 seo.
Status de
conformidade
(selecione um)
Requisito do
PCI DSS
Descrio do requisito
Instalar e manter uma configurao de

firewall para proteger os dados do titular
do carto
No usar padres disponibilizados pelo

fornecedor para senhas do sistema e
outros parmetros de segurana
Proteger os dados armazenados do

titular do carto
Criptografar a transmisso dos dados do

titular do carto em redes abertas e
pblicas
Usar e atualizar regularmente o software

ou programas antivrus
Desenvolver e manter sistemas e

aplicativos seguros
Restringir o acesso aos dados do titular

do carto de acordo com a necessidade
de conhecimento para o negcio
Atribuir uma identidade exclusiva para

cada pessoa que tenha acesso ao
computador
SIM
NO

Data e aes de correo

(se o Status de
conformidade for "No")
Outubro de 2010
Pgina 3
Requisito do
PCI DSS
Restringir o acesso fsico aos dados do

titular do carto
10
Acompanhar e monitorar todos os

acessos com relao aos recursos da
rede e aos dados do titular do carto
11
Testar regularmente os sistemas e

processos de segurana
12
Manter uma poltica que aborde a

segurana das informaes para todas
as equipes
Status de
conformidade
(selecione um)


(se o Status de
Outubro de 2010
Pgina 4
Atestado de conformidade, SAQ D Verso do prestador de servios

Instrues para envio
O prestador de servios deve preencher este Atestado de conformidade como uma declarao do status de
conformidade dele com os Requisitos do Padro de segurana de dados do setor de cartes de pagamento (PCI
DSS) e procedimentos da avaliao de segurana. Preencha todas as sees aplicveis e consulte as instrues de
envio em "Conformidade do PCI DSS Etapas para preenchimento", neste documento.
Parte 1. Informaes do prestador de servios e do assessor de segurana qualificado

Parte 1a. Informaes sobre a organizao do prestador de servios
Nome da empresa:
DBA(s):
Contato:
Forma de
tratamento:
Telefone:
E-mail:
Endereo comercial:
Cidade:
Estado/Provncia:
Pas:
CEP:
URL:
Parte 1b. Informaes sobre a empresa do assessor de segurana qualificado (se aplicvel)
Nome da empresa:
Nome do contato principal
do QSA:
Forma de
tratamento:
Telefone:
E-mail:
Endereo comercial:
Cidade:
Estado/Provncia:
Pas:
CEP:
URL:
Parte 2. Informaes sobre a avaliao do PCI DSS

Parte 2a. Prestador de servios que FOI INCLUDO no escopo da avaliao do PCI DSS
(marque todas as opes que se aplicam)
Provedor de hospedagem segura
Provedor de hospedagem
Hardware
Processamento
pagamentos ATM
de
Gerenciamento de contas
Web
Processamento
pagamentos MOTO
de
Autorizao
Processamento de emisses
Processamento
pagamentos Internet
de
Servios de back-office
Programas de fidelidade
Processamento
pagamentos POS
de
Gerenciamento do faturamento
Servios gerenciados
Servios
adiantado
Compensao e liquidao
Servios do comerciante
3-D
Preparao de dados
Fraude e servios de cobrana
Fornecedor/transmissor
com
pagamento
Gerenciamento de registros
de
redes
Taxas/pagamentos
governo
para
Gateway/switch de pagamento

Outubro de 2010
Pgina 1
Listar as instalaes e locais includos na anlise do PCI DSS:

Outubro de 2010
Pgina 2
Parte 2b. Se algum servio listado for fornecido pelo prestador de servios, mas NO ESTIVER
INCLUDO no escopo da avaliao do PCI DSS, marque-o abaixo:
Provedor de hospedagem segura
Hardware
Processamento
pagamentos ATM
de
Gerenciamento de contas
Web
Processamento
pagamentos MOTO
de
Autorizao
Processamento de emisses
Processamento
pagamentos Internet
de
Servios de back-office
Programas de fidelidade
Processamento
pagamentos POS
de
Gerenciamento do faturamento
Servios gerenciados
Servios
adiantado
Compensao e liquidao
Servios do comerciante
3-D
Preparao de dados
Fraude e servios de cobrana
Fornecedor/transmissor
com
pagamento
Gerenciamento de registros
de
redes
Taxas/pagamentos
governo
para
Gateway/switch de pagamento
Parte 2c. Relaes

Sua empresa se relaciona com um ou mais prestadores de servios terceirizados (por
exemplo: gateways, empresas de hospedagem na Web, agentes de passagens areas,
agentes de programas de fidelidade, etc.)?
Sim
No
Parte 2d. Processamento das transaes

Como e em qual capacidade seu negcio armazena, processa e/ou transmite dados do titular do carto?
Aplicativo de pagamento em uso
Nmero da
verso
ltima validao de acordo com o

PABP/PA-DSS
Fornea as seguintes informaes relacionadas aos aplicativos de pagamentos usados pela sua organizao:
Parte 3. Validao 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 servios) declara o seguinte status de conformidade (marque um):
Em conformidade: Todas as sees do SAQ do PCI esto preenchidas, todas as perguntas foram
respondidas afirmativamente, resultando em uma classificao geral de CONFORMIDADE, e uma varredura
de verificao aprovada foi preenchida por um Fornecedor de varredura aprovado do PCI SSC, de forma que a
(Nome da empresa do prestador de servios) demonstrou conformidade integral com o PCI DSS.

Outubro de 2010
Pgina 3
No conformidade: Nem todas as sees do SAQ do PCI esto preenchidas ou algumas perguntas foram
respondidas negativamente, resultando em uma classificao geral de NO CONFORMIDADE, ou uma
varredura de verificao aprovada no foi preenchida por um Fornecedor de varredura aprovado do PCI SSC,
de forma que a (Nome da empresa do prestador de servios) no demonstrou conformidade integral com o PCI
DSS.
Data prevista para conformidade:
A entidade que estiver enviando este formulrio com um status de No conformidade talvez tenha de
preencher o Plano de ao 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 seo..

Outubro de 2010
Pgina 4
Parte 3a. Confirmao do status de conformidade

O prestador de servios confirma que:
O Questionrio de auto-avaliao D, verso (inserir nmero da verso), foi preenchido segundo as
instrues nele contidas.
Todas as informaes contidas no SAQ mencionado anteriormente e neste atestado representam
adequadamente os resultados de minha avaliao.
Eu li o PCI DSS e reconheo que sempre devo manter a conformidade total com o PCI DSS.
5
No h evidncia de armazenamento de dados de tarja magntica (ou seja, rastros) , dados CAV2, CVC2,
6
7
CID ou CVV2 , ou dados de PIN aps a autorizao da transao em NENHUM sistema revisto durante
esta avaliao.
Parte 3b. Confirmao do prestador de servios
Assinatura do responsvel executivo pelo prestador de servios
Data
Nome do responsvel executivo pelo prestador de servios
Forma de tratamento
Representante da empresa prestadora de servios
Parte 4. Plano de ao para status de no conformidade

Selecione o "Status de conformidade" adequado para cada requisito. Se voc responder "NO" a qualquer um
dos requisitos, ser necessrio informar a data na qual a empresa estar em conformidade com o requisito e uma
descrio resumida das aes que esto 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 seo.
Dados codificados na tarja magntica ou dados equivalentes em um chip usados para autorizao durante a transao com o
carto. As entidades no podem manter todos os dados da tarja magntica aps a autorizao da transao. Os nicos
elementos dos dados de rastro que podem ser retidos so o nmero da conta, a data de vencimento e o nome.
O valor de trs ou quatro dgitos impresso direita do painel de assinatura ou na frente do carto de pagamento usado para
verificar transaes virtuais com o carto.
Nmero de identificao pessoal inserido pelo titular do carto durante uma transao com o carto e/ou bloqueio de PIN
criptografado dentro da mensagem da transao.

Outubro de 2010
Pgina 5
Status de
conformidade
(selecione um)
Requisito do
PCI DSS
Instalar e manter uma configurao de

firewall para proteger os dados do titular
do carto
No usar padres disponibilizados pelo

fornecedor para senhas do sistema e
outros parmetros de segurana
SIM
NO

(se o Status de
Proteger os dados armazenados do

titular do carto
Criptografar a transmisso dos dados do

titular do carto em redes abertas e
pblicas
Usar e atualizar regularmente o software

ou programas antivrus
Desenvolver e manter sistemas e

aplicativos seguros
Restringir o acesso aos dados do titular

do carto de acordo com a necessidade
de conhecimento para o negcio
Atribuir uma identidade exclusiva para

cada pessoa que tenha acesso ao
computador
Restringir o acesso fsico aos dados do

titular do carto
10
Acompanhar e monitorar todos os

acessos com relao aos recursos da
11
Testar regularmente os sistemas e

processos de segurana
12
Manter uma poltica que aborde a

segurana das informaes para todas
as equipes

Outubro de 2010
Pgina 6
Questionrio de auto-avaliao D
Observao: As perguntas a seguir esto numeradas de acordo com os requisitos e procedimentos de
teste do PCI DSS, conforme definido no documento Requisitos do PCI DSS e procedimentos da
avaliao de segurana.
Data de preenchimento:
Construir e manter uma rede segura

Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados
Pergunta do PCI DSS
1.1
Resposta:
Sim
No
Especial
Os padres de configurao do firewall e do roteador esto definidos

para incluir o seguinte:
1.1.1
Existe um processo formal para aprovar e testar todas as

conexes de rede externas e alteraes nas configuraes 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 carto na rede)
que documente todas as conexes em relao aos dados
do titular do carto, incluindo as redes sem fio?
(b) Esse diagrama mantido atualizado?
1.1.3
(a) Os padres de configurao incluem requisitos para um

firewall em cada conexo 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 padres
de configurao do firewall?
1.1.4
Os padres de configurao do firewall e do roteador incluem

uma descrio dos grupos, funes e responsabilidades para
gerenciamento lgico dos componentes da rede?
1.1.5
(a) Os padres de configurao do firewall e do roteador

incluem uma lista documentada dos servios, protocolos e
portas necessrias para os negcios (por exemplo:
protocolos HTTP (hypertext transfer protocol) e SSL
(Secure Sockets Layer), SSH (Secure Shell) e VPN
(Virtual Private Network)?
(b) Todos os servios, protocolos e portas no seguros so
necessrios e existem recursos de segurana
documentados e implementados para cada um desses
itens?
Observao: Os exemplos de servios, protocolos ou portas
no seguros incluem, entre outros, FTP, Telnet, POP3, IMAP
e SNMP.
1.1.6
(a) Os padres de configurao do firewall e do roteador

exigem a anlise dos conjuntos de regras do firewall e do
roteador pelo menos a cada seis meses?
SAQ D do PCI DSS, v2.0, Questionrio de auto-avaliao

Outubro de 2010
Pgina 1
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(b) Os conjuntos de regras do firewall e do roteador so

analisados pelo menos a cada seis meses?
1.2
As configuraes do firewall e do router restringem as conexes

entre redes no confiveis e qualquer sistema no ambiente de
dados do titular do carto, da seguinte forma:
Observao: Uma "rede no confivel" qualquer rede externa s
redes que pertencem entidade em anlise e/ou qualquer rede que
no seja controlada ou gerenciada pela entidade.
1.2.1
(a) O trfego de entrada e sada est limitado para o trfego

necessrio para o ambiente de dados do titular do carto
e as restries esto documentadas?
(b) Todos os outros trfegos de entrada e sada so
recusados de forma especfica (como ao usar a opo
explcita "recusar todos" ou uma recusa implcita aps a
declarao de permisso)?
1.3
1.2.2
Os arquivos de configurao do roteador esto seguros e

sincronizados?
1.2.3
Existem firewalls de permetro instalados entre quaisquer

redes sem fio e o ambiente de dados do titular do carto e
esses firewalls esto configurados para recusar ou controlar
(se esse trfego for necessrio para fins comerciais) qualquer
trfego a partir do ambiente sem fio no ambiente de dados do
titular do carto?
A configurao do firewall probe o acesso pblico direto entre a

Internet e qualquer componente do sistema no ambiente de dados
do titular do carto, da seguinte forma:
1.3.1
Existe uma DMA implementada para limitar o trfego de

entrada somente para componentes do sistema que
fornecem servios, portas e protocolos autorizados
acessveis publicamente?
1.3.2
O trfego de Internet de entrada est limitado ao endereo

IP dentro da DMZ?
1.3.3
As conexes diretas esto proibidas para trfego de entrada

ou sada entre a Internet e o ambiente dos dados do titular
do carto?
1.3.4
A passagem de endereos internos da Internet para a DMZ

proibida?
1.3.5
O trfego de sada do ambiente de dados do titular do

carto para a Internet est explicitamente autorizado?
1.3.6
A inspeo com status, tambm conhecida como filtragem

de pacote dinmico, est implementada (ou seja, somente
conexes estabelecidas podem entrar na rede)?

Outubro de 2010
Pgina 2
Pergunta do PCI DSS
Resposta:
1.3.7
Os componentes do sistema que armazenam dados do

titular do carto (como banco de dados) esto localizados
em uma zona da rede interna, separada da DMZ e de
outras redes no confiveis?
1.3.8
(a) Existem mtodos em vigor para evitar a divulgao de

endereos IP privados e de informaes de roteamento
pra a Internet?
Sim
No
Especial
Observao: Os mtodos para ocultar o endereo IP

podem incluir, entre outros:
Converso de endereos de rede (NAT)
Implementao dos servidores contendo dados do
titular do carto atrs dos servidores de
proxy/firewalls ou caches de contedo,
Remoo ou filtragem das propagandas de rota para
redes privadas que empregam endereamento
registrado,
Uso interno do espao de endereo RFC1918 em
vez de endereo registrado.
(b) A divulgao dos endereos IP privados e das
informaes de roteamento para entidades externas
autorizada?
1.4
(a) Existe um software de firewall pessoal instalado e ativo em todos

os computadores mveis e/ou de propriedade do funcionrio
com conectividade direta Internet (por exemplo: laptops
usados pelos funcionrios) usados para acessar a rede da
empresa?
(b) O software de firewall pessoal est configurado de acordo com
padres especficos e no pode ser alterado pelos usurios de
computadores mveis e/ou de propriedade do funcionrio?

Outubro de 2010
Pgina 3
Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema

e outros parmetros de segurana
Pergunta do PCI DSS
2.1
Resposta:
Sim
No
Especial
Os valores-padro entregues pelo fornecedor so sempre alterados

antes de instalar um sistema na rede?
Os valores padro entregues pelo fornecedor incluem, entre outros
itens, senhas, strings de comunidade de SNMP (simple network
management protocol) e a eliminao de contas desnecessrias.
2.1.1
Para ambientes sem fio conectados ao ambiente dos dados

do titular do carto ou para a transmisso dos dados do
titular do carto, os padres so alterados da seguinte forma:
(a) As chaves de criptografia padro so alteradas na
instalao e so modificadas sempre que um funcionrio
que conhece as chaves sai da empresa ou troca de
cargo?
(b) As strings de comunidades de SNMP padro dos
dispositivos sem fio so alteradas?
(c) As senhas/frases de senha padro dos pontos de acesso
so alteradas?
(d) O firmware dos dispositivos sem fio atualizado para
ser compatvel com a criptografia robusta para
autenticao e transmisso em redes sem fio?
(e) Os outros padres relacionados segurana do
fornecedor de dispositivos sem fio so alterados, se
aplicvel?
2.2
(a) Os padres de configurao so desenvolvidos para todos os

componentes do sistema e esto de acordo com os padres de
fortalecimento do sistema aceitos pelo setor?
As fontes para os padres 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 padres de configurao do sistema so atualizados quando
novos problemas de vulnerabilidade so identificados, conforme
definido no Requisito 6.2?
(c) Os padres de configurao do sistema so aplicados quando
novos sistemas so configurados?
(d) Os padres de configurao do sistema incluem os seguintes
itens:
2.2.1
(a) Somente uma funo principal implementada por

servidor para evitar funes que exigem diferentes nveis
de segurana coexistindo no mesmo servidor?
(Por exemplo: servidores da Web, servidores de banco de
dados e DNS devem ser implementados em servidores
separados.)

Outubro de 2010
Pgina 4
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(b) Se forem usadas tecnologias de virtualizao, somente

uma funo principal est implementada por componente
ou dispositivo do sistema virtual?
2.2.2
(a) Somente os servios, protocolos e daemons necessrios,

entre outros, so ativados conforme a necessidade para
a funo do sistema (ou seja, os servios e protocolos
que no so diretamente necessrios para a execuo
da funo especificada do dispositivo esto
desativados)?
(b) Todos os servios, daemons ou protocolos no seguros
ativos so justificveis e os recursos de segurana esto
documentados e implementados?
(Por exemplo: tecnologias seguras como SSH, S-FTP, SSL
ou IPSec VPN so usadas para proteger servios no
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 esto beminformados sobre as configuraes comuns dos
parmetros de segurana para esses componentes do
sistema?
(b) As configuraes comuns dos parmetros de segurana
esto includas nos padres de configurao do
sistema?
(c) As configuraes dos parmetros de segurana esto
definidas corretamente nos componentes do sistema?
2.2.4
(a) Todas as funcionalidades desnecessrias como scripts,

drivers, recursos, subsistemas, sistemas de arquivo e
servidores da Web desnecessrios foram removidas?
(b) As funes ativadas esto documentadas e oferecem
suporte para uma configurao segura?
(c) Existem somente funcionalidades registradas presentes
nos componentes do sistema?
2.3
Os acessos administrativos fora do console esto 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 so
criptografados com criptografia robusta e um mtodo de
criptografia robusta invocado antes da solicitao da senha do
administrador?
(b) Os servios do sistema e os arquivos de parmetros so
configurados para prevenir o uso de Telnet e outros comandos de
login remoto inseguros?

Outubro de 2010
Pgina 5
Pergunta do PCI DSS
Resposta:
Sim
No
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

esto configurados para proteger o ambiente de hospedagem e os
dados do titular do carto?
Consulte o Anexo A: Requisitos adicionais do PCI DSS para
provedores de hospedagem compartilhada para obter informaes
sobre os requisitos especficos que precisam ser cumpridos.

Outubro de 2010
Pgina 6
Proteger os dados do titular do carto

Requisito 3: Proteger os dados armazenados do titular do carto
Pergunta do PCI DSS
3.1
Resposta:
Sim
No
Especial
As polticas e procedimentos de reteno e eliminao de dados

so implementadas conforme a seguir:
3.1.1
(a) Existem polticas e procedimentos de reteno e

eliminao de dados implementadas que incluem
requisitos especficos para a reteno dos dados do
titular do carto, conforme necessrio para fins
comerciais, legais e/ou regulatrios?
Por exemplo: os dados do titular do carto precisam ser
retidos por um perodo X pelos motivos comerciais Y.
(b) As polticas e os procedimentos incluem itens referentes
a eliminao segura dos dados que no so mais
necessrios por motivos legais, regulatrios ou
comerciais, incluindo a eliminao dos dados do titular
do carto?
(c) As polticas e os procedimentos abrangem todo o
armazenamento dos dados do titular do carto?
(d) Os processos e procedimentos incluem ao menos um
dos seguintes itens?
Processo programtico (automtico ou manual) para
remover, ao menos trimestralmente, dados
armazenados do titular do carto que excederem os
requisitos definidos pela poltica de reteno de dados
Requisitos para uma anlise, conduzida ao menos
trimestralmente, para verificar se os dados
armazenados do titular do carto no excedem os
requisitos definidos na poltica de reteno de dados.
(e) Todos os dados armazenados do titular do carto
cumprem os requisitos definidos na poltica de reteno
de dados?
3.2
(a) Para os emissores e/ou empresas que oferecem suporte para

servios de emisso e armazenam dados de autenticao
confidenciais, h justificativa comercial para o armazenamento
dos dados de autenticao confidenciais e os dados esto
seguros?
(b) Para todas as outras entidades, se dados de autenticao
confidenciais forem recebidos e excludos, existem processos
em vigor para excluir os dados com segurana e verificar se os
dados podem ser recuperados?
(c) Todos os sistemas cumprem os seguintes requisitos em relao
ao armazenamento de dados de autenticao confidenciais
aps a autorizao (mesmo se criptografados)?

Outubro de 2010
Pgina 7
Pergunta do PCI DSS
3.3
Resposta:
3.2.1
O contedo completo de qualquer rastro da tarja magntica

(localizada na parte posterior do carto) ou qualquer dado
equivalente presente em um chip ou em qualquer outro
lugar, no armazenado em nenhuma circunstncia?
Esses dados tambm so denominados como rastro
completo, rastro, rastro 1, rastro 2 e dados da tarja
magntica.
Observao: No curso normal dos negcios, os seguintes
elementos de dados da tarja magntica talvez precisem ser
retidos:
O nome do titular do carto,
O nmero da conta primria (PAN),
A data de vencimento e
O cdigo de servio
Para minimizar o risco, armazene somente os elementos de
dados conforme necessrio para os negcios.
3.2.2
O cdigo ou valor de verificao do carto (nmero de trs

ou quatro dgitos impresso na frente ou atrs do carto de
pagamento) no armazenado em nenhuma circunstncia?
3.2.3
O numero de identificao pessoal (PIN) ou o bloqueio de

PIN criptografado no armazenado em nenhuma
circunstncia?
Sim
No
Especial
O PAN mascarado quando exibido (os primeiros seis e quatro

ltimos dgitos so o nmero mximo de dgitos a serem exibidos)?
Observaes:
Este requisito no se aplica aos funcionrios e outras partes
interessadas que precisam visualizar o PAN completo;
Esse requisito no substitui os requisitos mais rigorosos em

vigor quanto s exibies dos dados do titular do carto por
exemplo, para recebimentos do ponto de venda (POS).

Outubro de 2010
Pgina 8
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
O PAN processado para ficar ilegvel em qualquer local onde ele

esteja armazenado (incluindo repositrios de dados, mdias digitais
portteis, mdias 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 no 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.
Observao: um esforo relativamente simples para um indivduo
mal-intencionado reconstituir os dados do PAN original caso ele
tenha acesso s verses truncadas e hash do PAN. Quando as
verses truncada e hash do mesmo PAN estiverem presentes no
ambiente de uma entidade, controles adicionais devero ser
implantados para assegurar que as verses truncada e hash no
sejam correlacionadas para reconstituir o PAN original.
3.4
3.4.1
Se a criptografia de disco (e no a criptografia do banco de

dados no nvel de coluna ou de arquivo) for utilizada, o
acesso gerenciado das formas a seguir?
(a) O acesso lgico aos sistemas de arquivos criptografados
gerenciado de forma independente dos mecanismos
de controle de acesso nativos do sistema operacional
(por exemplo, no usando bancos de dados de conta de
usurio local)?
(b) As chaves criptogrficas so armazenadas de forma
segura (por exemplo, armazenadas em mdias
removveis protegidas adequadamente com controles de
acesso robustos)?
(c) Os dados do titular do carto nas mdias removveis
esto criptografados aonde quer que estejam
armazenados?
Observao: Se a criptografia de disco no for usada para
criptografar a mdia removvel, os dados armazenados nessa
mdia devero ser convertidos em ilegveis por meio de outro
mtodo.
Alguma chave usada para proteger os dados do titular do carto
contra divulgao e uso inapropriado das formas a seguir?
Observao: Este requisito tambm 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 to robustas quanto a chave de criptografia de dados.
3.5
3.5.1
O acesso s chaves criptogrficas est restrito ao menor

nmero necessrio de responsveis pela proteo?

Outubro de 2010
Pgina 9
Pergunta do PCI DSS

3.5.2
Resposta:
Sim
No
Especial
(a) As chaves so armazenadas no formato criptografado e

as chaves de criptografia de chaves so armazenadas
separadamente das chaves de criptografia de dados?
(b) As chaves criptogrficas so armazenadas no menor
nmero possvel de locais e formas?
3.6
(a) Todos os processos e procedimentos de gerenciamento de

chaves das chaves criptogrficas usadas para criptografar os
dados do titular do carto esto totalmente documentados e
implementados?
(b) Somente para prestadores de servios: Se as chaves forem
compartilhadas com os clientes para transmisso ou
armazenamento dos dados do titular do carto, fornecida aos
clientes uma documentao que inclua uma orientao sobre
como transmitir, armazenar e atualizar com segurana 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 criptogrficas incluem a

gerao de chaves criptogrficas robustas?
3.6.2

distribuio segura das chaves criptogrficas?
3.6.3
Os procedimentos de chaves criptogrficas incluem o

armazenamento seguro das chaves criptogrficas?
3.6.4
Os procedimentos de chaves criptogrficas incluem

alteraes das chaves criptogrficas para chaves que
alcanaram o final de seu perodo de criptografia (por
exemplo: aps um perodo de tempo definido e/ou aps a
produo de certa quantidade de texto criptografado por
determinada chave), conforme definido pelo fornecedor
associado do aplicativo ou pelo proprietrio da chave, com
base nas melhores prticas e orientaes do setor (como a
NIST Special Publication 800-57)?
3.6.5
(a) Os procedimentos de chaves criptogrficas incluem a

inutilizao ou substituio (por exemplo: por
arquivamento, destruio e/ou revogao) das chaves
criptogrficas quando a integridade da chave estiver
enfraquecida (como a sada de um funcionrio com
conhecimento de uma chave em texto simples)?
(b) Os procedimentos de chaves criptogrficas incluem a
substituio de chaves comprometidas conhecidas ou
suspeitas?
(c) Se chaves inutilizadas ou substitudas forem mantidas,
essas chaves so usadas somente para fins de
decodificao/verificao (e no para criptografia)?

Outubro de 2010
Pgina 10
Pergunta do PCI DSS
Resposta:
3.6.6
Os procedimentos de chaves criptogrficas incluem o

conhecimento compartilhado e o controle duplo das chaves
criptogrficas (como a exigncia de duas ou trs pessoas,
cada uma conhecendo somente o seu componente da
chave, para reconstituir a chave completa) para operaes
manuais de gerenciamento de chaves em texto simples?
Observao: Os exemplos de operaes manuais de
gerenciamento de chave incluem, entre outros, gerao,
transmisso, carregamento, armazenamento e destruio de
chaves.
3.6.7

preveno contra a substituio no autorizada de chaves
criptogrficas?
3.6.8
Os responsveis pela proteo das chaves criptogrficas

devem reconhecer formalmente (por escrito ou
eletronicamente) que compreendem e aceitam suas
responsabilidades de proteo das chaves?

Sim
No
Especial
Outubro de 2010
Pgina 11
Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas

e pblicas
Pergunta do PCI DSS
4.1
Resposta:
Sim
No
Especial
(a) So utilizadas criptografia robusta e protocolos de segurana

como SSL/TLS ou IPSEC para proteger os dados confidenciais do
titular do carto durante a transmisso em redes abertas e
pblicas?
Os exemplos de redes pblicas 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 confiveis so aceitos?
(c) Os protocolos de segurana foram implementados para usar
somente configuraes seguras, sem suporte para verses ou
configuraes inseguras?
(d) A fora da criptografia adequada foi implementada para a
metodologia de criptografia em uso (verifique as
recomendaes/melhores prticas do fornecedor)?
(e) Para implementaes 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 carto so exigidos somente quando
HTTPS exibido no URL?
As melhores prticas do setor (como a IEEE 802.11i) so
usadas para implementar a criptografia robusta para
autenticao e transmisso nos dispositivos sem fio que
transmitem dados do titular do carto ou que esto
conectados no ambiente de dados do titular do carto?
Observao: O uso de WEP como controle de segurana
foi proibido em 30 de junho de 2010.
(a) Os PANs so processados para ficarem ilegveis ou so

protegidos com criptografia robusta sempre que so enviado por
meio de tecnologias de envio de mensagens de usurio final
(como e-mails, mensagens instantneas ou bate-papo)?
(b) Existem polticas em vigor que afirmam que os PANs
desprotegidos no so enviados por meio das tecnologias de
envio de mensagens de usurio final?

Outubro de 2010
Pgina 12
Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: Usar e atualizar regularmente o software ou programas antivrus
Pergunta do PCI DSS
5.1
Sim
No
Especial
Sim
No
Especial
Os softwares antivrus esto implementados em todos os sistemas

normalmente afetados por softwares mal-intencionados?
5.1.1
5.2
Resposta:
Todos os programas antivrus podem detectar, remover e

proteger contra todos os tipos conhecidos de softwares malintencionados (como vrus, trojans, worms, spywares,
adwares e rootkits)?
Todos os software antivrus esto atualizados, funcionando

ativamente e gerando logs de auditoria da seguinte forma:
(a) A poltica de antivrus requer a atualizao do software e das
definies do antivrus?
(b) A instalao principal do software est ativada para
atualizaes automticas e varreduras peridicas?
(c) As atualizaes automticas e as varreduras peridicas esto
ativadas?
(d) Todos os mecanismos de antivrus geram logs de auditoria e os
logs so 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 esto protegidos

de vulnerabilidades conhecidas pois tm os patches de
segurana mais recentes disponibilizados pelos fornecedores
instalados?
(b) Os patches de segurana crticos so instalados no prazo de
um ms aps o lanamento?
Observao: Uma empresa talvez considere utilizar uma
abordagem baseada nos riscos para priorizar suas instalaes de
patches. Por exemplo, ao priorizar mais a infra-estrutura crtica
(como dispositivos e sistemas disponibilizados ao pblico e bancos
de dados) em vez de dispositivos internos menos crticos, para
assegurar que sistemas e dispositivos de prioridade elevada sejam
resolvidos em um ms e dispositivos e sistemas menos crticos em
trs meses.

Outubro de 2010
Pgina 13
Pergunta do PCI DSS

6.2
Resposta:
Sim
No
Especial
(a) Existe algum processo para identificar novas vulnerabilidades

de segurana descobertas, incluindo a atribuio de uma
classificao de risco para tal vulnerabilidade? (No mnimo, as
vulnerabilidades crticas de alto risco devem ser classificadas
como "Alto".)
Observao: As classificaes de risco devem ser baseadas nas
melhores prticas do setor. Por exemplo: os critrios para
classificao de vulnerabilidades como "Alto" risco podem incluir
uma pontuao base no CVSS igual ou superior a 4.0, um patch
fornecido pelo fornecedor classificado por ele como "crtico" ou uma
vulnerabilidade que afete um componente crucial do aplicativo.
A classificao de vulnerabilidades ser considerada uma melhor
prtica at 30 de junho de 2012, quando passar a ser um
requisito.
(b) Os processos de identificao de novas vulnerabilidades de
segurana incluem o uso de fontes externas para obteno de
informaes sobre vulnerabilidades de segurana?
6.3
(a) Os processos de desenvolvimento de software so baseados

nos padres e/ou melhores prticas do setor?
(b) A segurana das informaes est includa no ciclo de vida de
desenvolvimento de softwares?
(c) Os aplicativos de software so desenvolvidos de acordo com o
PCI DSS (com autenticao 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 usurios e/ou as senhas dos aplicativos

personalizados so removidos antes da ativao e
distribuio dos aplicativos para os clientes?

Outubro de 2010
Pgina 14
Pergunta do PCI DSS

6.3.2
6.4
Resposta:
Sim
No
Especial
Todas as alteraes dos cdigos do aplicativo personalizado

so analisadas (usando processos manuais ou
automatizados) antes da liberao para produo ou da
distribuio para o cliente para identificar qualquer possvel
vulnerabilidade no cdigo, conforme os itens a seguir?
As alteraes dos cdigos so analisadas por outras
pessoas alm do autor do cdigo e por pessoas que
esto cientes das tcnicas de anlise dos cdigos e
das prticas de codificao seguras?
As anlises dos cdigos asseguram que o cdigo foi
desenvolvido de acordo com as diretrizes de
codificao seguras (em conformidade com o
Requisito 6.5 do PCI DSS)?
As correes adequadas so implementadas antes
da distribuio?
Os resultados das anlises dos cdigos so
revisados e aprovados pela gerncia antes da
distribuio?
Observao: Este requisito referente s anlises dos cdigos
se aplica a todos os cdigos personalizados (internos e
voltados para o pblico), como parte integrante do ciclo de
vida de desenvolvimento do sistema. As anlises dos cdigos
podem ser realizadas por equipes internas instrudas ou
terceiros. Os aplicativos da Web tambm esto sujeitos a
controles adicionais, se forem voltados ao pblico, para
abordar ameaas e vulnerabilidades contnuas aps a
implementao, conforme definido no Requisito 6.6 do PCI
DSS.
Os processos e procedimentos de controle de alteraes foram

seguidos para todas as alteraes nos componentes do sistema
para incluir os itens a seguir?
6.4.1
Os ambientes de desenvolvimento/teste so separados do

ambiente de produo, com controle de acesso implementado
para obrigar a separao?
6.4.2
Existe uma separao das tarefas entre a equipe atribuda

aos ambientes de desenvolvimento/teste e a equipe atribuda
ao ambiente de produo?
6.4.3
Os dados de produo (PANs ativos) no so usados para

testes ou desenvolvimento?
6.4.4
As contas e os dados de teste so removidos antes da

ativao dos sistemas de produo?
6.4.5
Os procedimentos de controle de alteraes para

implementao de patches de segurana e modificaes
de software esto documentados e exigem os itens
6.4.5.1 a 6.4.5.4 abaixo?
(b) Os itens a seguir so executados em todas as
alteraes?

Outubro de 2010
Pgina 15
Pergunta do PCI DSS
Resposta:
6.4.5.1
Documentao de impacto
6.4.5.2
Aprovao documentada pelas partes autorizadas
6.4.5.3
Sim
No
Especial
(a) Testes de funcionalidade para verificar se a alterao

no tem impacto adverso sobre a segurana do sistema
(b) Para alteraes do cdigo personalizado, todas as
atualizaes foram testadas para conformidade com o
Requisito 6.5 do PCI DSS antes de serem implantadas
na produo?
6.4.5.4
6.5
Os procedimentos de reverso esto esto preparados para

cada alterao?
(a) Os aplicativos so desenvolvidos com base nas diretrizes de

codificao seguras?
(Como o Open Web Application Security Project (OWASP) Guide,
SANS CWE Top 25, CERT Secure Coding, etc.)?
(b) Os desenvolvedores esto bem-informados sobre as tcnicas
de codificao seguras?
(c) A preveno contra vulnerabilidades de codificao comuns faz
parte dos processos de desenvolvimento de softwares para
garantir que os aplicativos no estejam vulnerveis, com a
aplicao mnima dos itens a seguir?
Observao: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9
estavam atualizadas de acordo com as melhores prticas do setor,
quando esta verso do PCI DSS foi publicada. No entanto,
conforme as melhores prticas do setor para o gerenciamento de
vulnerabilidades so atualizadas, as melhores prticas atuais
precisam ser usadas para estes requisitos.
6.5.1
Falhas na injeo, particularmente na injeo SQL? (Validar a

entrada para verificar se os dados do usurio no podem
modificar o significado dos comandos e das queries, usar
queries parametrizadas, etc.)
Tambm considere as falhas de injeo 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 criptogrfico no seguro? (Evitar falhas

criptogrficas.)
6.5.4
Comunicaes no seguras? (Criptografar corretamente

todas as comunicaes autenticadas e confidenciais.)
6.5.5
Manuseio incorreto de erros? (No divulgar informaes

atravs de mensagens de erro.)

Outubro de 2010
Pgina 16
Pergunta do PCI DSS

6.5.6
Resposta:
Sim
No
Especial
Todas as vulnerabilidades classificadas como "Alto"

identificadas no processo de identificao de vulnerabilidade
(conforme definido no Requisito 6.2 do PCI DSS)?
Observao: 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 tambm so
abordadas?
6.6
6.5.7
Scripting de site cruzado (XSS). (Validar todos os parmetros

antes da incluso, utilizar uma sada de contexto confidencial,
etc.)
6.5.8
Controle de acesso inapropriado, como referncias diretas

inseguras a objetos, falhas na restrio do acesso a URLs e
diretrios transversais. (Autenticar os usurios e corrigir a
entrada adequadamente. No expor referncias a objetos
internos aos usurios.)
6.5.9
Falsificao de solicitaes de site cruzado (CSRF). (No

responder para credenciais de autorizao e tokens enviados
automaticamente pelos navegadores.)
Para aplicativos da Web voltados para o pblico, as novas

ameaas e vulnerabilidades so abordadas continuamente e esses
aplicativos esto protegidos contra ataques conhecidos por
qualquer um dos mtodos a seguir?
Analisando os aplicativos da Web voltados para o pblico
atravs de ferramentas ou mtodos manuais ou automticos
de avaliao de segurana das vulnerabilidades dos
aplicativos, conforme os itens a seguir:
o Pelo menos anualmente
o Aps quaisquer alteraes
o Por meio de uma empresa especializada na segurana
de aplicativos
o Se todas as vulnerabilidades forem corrigidas
o Se o aplicativo for reavaliado aps as correes
ou
Instalando um firewall na camada de aplicativo da Web em
todos os aplicativos da Web voltados para o pblico para
detectar e impedir ataques baseados na Web.
Observao: "Uma empresa especializada na segurana de
aplicativos" pode ser uma empresa terceirizada ou uma empresa
interna, desde que os analisadores sejam especializados na
segurana de aplicativos e possam demonstrar que no
dependem da equipe de desenvolvimento.

Outubro de 2010
Pgina 17
Implementar medidas de controle de acesso rigorosas

Requisito 7: Restringir o acesso aos dados do titular do carto de acordo com a
necessidade de conhecimento para o negcio
Pergunta do PCI DSS
7.1
Resposta:
Sim
No
Especial
O acesso aos componentes do sistema e aos dados do titular do

carto limitado somente quelas pessoas cuja funo requer tal
acesso, conforme itens a seguir:
7.1.1
Os direitos de acesso dos IDs dos usurios privilegiados

esto restritos ao menor nmero de privilgios necessrios
para o desempenho das responsabilidades da funo?
7.1.2
Os privilgios so concedidos s pessoas com base na

classificao e na atribuio da funo (tambm chamado de
"controle de acesso baseado na funo" ou RBAC)?
7.1.3
A aprovao documentada (por escrito ou eletronicamente)

das partes autorizadas necessria e especifica os
privilgios necessrios?
7.1.4
Os controles de acesso so implementados por meio de um

sistema de controle de acesso automtico?
7.2
Existe um controle de acesso em vigor para sistemas com vrios

usurios, a fim de restringir o acesso com base na necessidade de
conhecimento do usurio, configurado para "negar tudo" a menos
que especificamente permitido, conforme os itens a seguir?
7.2.1
Os sistemas de controle de acesso esto implementados em

todos os componentes do sistema?
7.2.2
Os sistemas de controle de acesso esto configurados para

impor os privilgios concedidos s pessoas com base na
classificao e na atribuio da funo?
7.2.3
Os sistemas de controle de acesso tm uma configurao

padro "recusar todos"?
Observao: Alguns sistemas de controle de acesso so
definidos, como padro, como"permitir todos", permitindo
portanto o acesso a menos que/at que uma norma seja
redigida para recus-lo de forma especfica.

Outubro de 2010
Pgina 18
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao
computador
Pergunta do PCI DSS
Resposta:
8.1
Todos os usurios recebem um ID exclusivo antes de permitir que

eles acessem os componentes do sistema ou os dados do titular
do carto?
8.2
Alm de atribuir um ID exclusivo, um ou mais dos seguintes

mtodos foi empregado para autenticar todos os usurios?
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 biomtrica
8.3
A autenticao com dois fatores foi incorporada ao acesso remoto

(acesso no nvel da rede que se origina fora dela) rede pelos
funcionrios, administradores e terceiros?
(Por exemplo: autenticao remota e servio 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 autenticao com dois fatores.)
Observao: A autenticao de dois fatores exige que dois dos
trs mtodos de autenticao (consulte o Requisito 8.2 do PCI
DSS para obter descries dos mtodos de autenticao) sejam
usados para autenticao. O uso duplicado de um fator (como o
uso de duas senhas separadas) no considerado uma
autenticao com dois fatores.
8.4
(a) Todas as senhas so processadas para se tornarem ilegveis

durante a transmisso e o armazenamento em todos os
componentes do sistema usando criptografia robusta?
Sim
No
Especial
(b) Somente para prestadores de servios: As senhas do cliente

so criptografadas?
8.5
Existem controles de gerenciamento adequados de autenticao

e identificao de usurios em vigor para administradores e
usurios que no so clientes em todos os componentes do
sistema, conforme a descrio a seguir?
8.5.1
As adies, excluses e modificaes dos IDs, das

credenciais e de outros objetos de identificao do usurios
so controladas, de forma que os IDs do usurios sejam
implementados somente quando autorizados (incluindo
usurios com privilgios especficos)?
8.5.2
A identidade do usurio verificada antes da execuo de

redefinies de senha nas solicitaes do usurio feitas
atravs de mtodos no presenciais (como telefone, e-mail
ou pela Web)?
8.5.3
As senhas iniciais e as senhas redefinidas so configuradas

com um valor exclusivo para cada usurio, cabendo a cada
um alterar sua senha imediatamente aps o primeiro uso?

Outubro de 2010
Pgina 19
Pergunta do PCI DSS
Resposta:
8.5.4
O acesso dos usurios desligados da empresa

imediatamente desativado ou removido?
8.5.5
As contas inativas por mais de 90 dias so removidas ou

desativadas?
8.5.6
(a) As contas usadas pelos fornecedores para acesso

remoto, manuteno ou suporte so ativadas somente
durante o perodo necessrio?
Sim
No
Especial
(b) As contas de acesso remoto dos fornecedores so

monitoradas durante o uso?
8.5.7
Os procedimentos e as polticas de autenticao so

transmitidos a todos os usurios que tm acesso aos dados
do titular do carto?
8.5.8
As contas e senhas (ou outros mtodos de autenticao) de

grupo, compartilhadas ou genricas, so proibidas
conforme os itens a seguir?
Os IDs e as contas de usurios genricos so
desativadas ou removidas;
No existem IDs de usurios compartilhados para
atividades de administrao do sistema e outras
funes crticas; e
Os IDs de usurios compartilhados e genricos no
so usados para administrar quaisquer componentes
do sistema.
8.5.9
(a) As senhas dos usurios so alteradas pelo menos a

cada 90 dias?
(b) Somente para prestadores de servios: As senhas dos
usurios que no so clientes so alteradas
periodicamente e esses usurios recebem instrues
sobre quando e sob quais circunstncias as senhas
devem ser alteradas?
8.5.10
(a) exigido um comprimento mnimo de senha de pelo

menos sete caracteres?
usurios que no so clientes devem obrigatoriamente
seguir o requisito mnimo de tamanho?
8.5.11
(a) As senhas devem conter caracteres numricos e

alfabticos?
usurios que no so clientes devem conter caracteres
numricos e alfabticos?
8.5.12
(a) A pessoa deve escolher uma nova senha que seja

diferente das quatro ltimas senhas utilizadas?
(b) Somente para prestadores de servios: As novas
senhas dos usurios que no so clientes devem ser
diferentes das quatro ltimas senhas utilizadas?

Outubro de 2010
Pgina 20
Pergunta do PCI DSS

8.5.13
Resposta:
Sim
No
Especial
(a) As tentativas de acesso repetidas so limitadas,

bloqueando o ID do usurios aps seis tentativas, no
mximo?
usurios que no so clientes so temporariamente
bloqueadas aps seis tentativas de acesso invlidas, no
mximo?
8.5.14
Aps o bloqueio da conta do usurio, a durao do bloqueio

est definida para um mnimo de 30 minutos ou at o
administrador ativar o ID do usurio?
8.5.15
Se uma sesso ficar ociosa por mais de 15 minutos, o

usurio obrigado a se autenticar novamente (informar
novamente a senha, por exemplo) para reativar o terminal
ou a sesso?
8.5.16
(a) Todos os acessos a qualquer banco de dados contendo

dados do titular do carto so autenticado? (Incluindo
acesso por meio de aplicativos, administradores e todos
os outros usurios).
(b) Todos os acessos, consultas e aes dos usurios
(como transferncias, cpias ou excluses) nos bancos
de dados so feitos somente atravs de mtodos
programticos (como atravs dos procedimentos
armazenados)?
(c) O acesso direto ao usurio ou as consultas aos bancos
de dados so 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 no por
usurios individuais ou outros processos)?

Outubro de 2010
Pgina 21
Requisito 9: Restringir o acesso fsico aos dados do titular do carto

Pergunta do PCI DSS
9.1
Resposta:
Sim
No
Especial
Existem controles de entrada na instalao adequados em vigor

para limitar e monitorar o acesso fsico aos sistemas no ambiente
de dados do titular do carto?
9.1.1
(a) Existem cmeras de vdeo e/ou mecanismos de

controle de acesso em vigor para monitorar o acesso
fsico individual nas reas confidenciais?
Observao: "reas confidenciais" referem-se a qualquer
central de dados, sala de servidores ou qualquer rea que
contenha sistemas que armazenem dados do titular do
carto. 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 cmeras de vdeo e/ou os mecanismos de controle
de acesso esto protegidos contra interceptao ou
desativao?
(c) Os dados das cmeras de vdeo e/ou dos mecanismos
de controle de acesso so analisados e correlacionados
com outras entradas e esses dados so armazenados
por pelo menos trs meses, a menos que restrito por
lei?
9.2
9.1.2
O acesso fsico aos pontos de rede acessveis ao pblico

restrito (por exemplo: reas acessveis a visitantes no
devem ter portas de rede ativadas a no ser que o acesso
rede seja autorizado explicitamente)?
Como alternativa, os visitantes esto sempre
acompanhados em reas com pontos de rede ativos?
9.1.3
O acesso fsico ao pontos de acesso sem fio, gateways,

dispositivos portteis, hardwares de comunicao/rede e
linhas de telecomunicao 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
funcionrios que trabalham em perodo integral e meio-perodo e
funcionrios, prestadores de servios e consultores temporrios
que esto fisicamente presente no endereo da entidade.
"Visitante refere-se a um fornecedor, convidado de um
funcionrio, equipes de servio ou qualquer pessoa que precise
adentrar as dependncias por um breve perodo, normalmente um
dia, no mximo.

Outubro de 2010
Pgina 22
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(a) Os processos e procedimentos de atribuio de crachs para

a equipe interna e para os visitantes incluem os itens a
seguir?
Concesso de novos crachs,
Modificao dos requisitos de acesso e
Anulao dos crachs dos membros da equipe interna que
se desligaram da empresa e dos visitantes que
encerraram suas atividades.
(b) O acesso ao sistema de crachs limitado aos funcionrios
autorizados?
(c) Os crachs 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 autorizao antes de entrar em

reas nas quais os dados do titular do carto so
processados ou mantidos?
9.3.2
(a) Os visitantes recebem um token fsico (como um crach

ou dispositivo de acesso) que os identifica e os
diferencia dos membros da equipe interna?
(b) O carto do visitante expira?
9.3.3
9.4
Os visitantes devem entregar o token fsico antes de sair

das dependncias ou quando o token expirar?
(a) Existe um log de visitantes em vigor para registrar o acesso
fsico s dependncias, assim como aos ambientes com
computador e centrais de dados onde os dados do titular do
carto so armazenados ou transmitidos?
(b) O log de visitantes contm o nome do visitante, a empresa
representada e o membro da equipe interna que est
autorizando o acesso fsico e esse log mantido por pelo
menos trs meses?
9.5
(a) Os backups de mdia so armazenados em um local seguro,

de preferncia em uma rea externa, como um local
alternativo ou de backup, ou uma rea de armazenamento
comercial?
(b) A segurana do local analisada pelo menos uma vez por
ano?
9.6
Todas as mdias esto fisicamente seguras (incluindo, entre

outros, computadores, mdias eletrnicas removveis, recibos em
papel, relatrios em papel e faxes)?
Para os fins do Requisito 9, "Mdia" refere-se a todas as mdias
em papel ou eletrnicas que contm dados do titular do carto.
9.7
(a) mantido um controle rigoroso quanto distribuio interna

ou externa de qualquer tipo de mdia?
(b) Os controles incluem o seguinte:

Outubro de 2010
Pgina 23
Pergunta do PCI DSS
Resposta:
9.7.1
A mdia classificada para que a confidencialidade dos

dados possa ser determinada?
9.7.2
A mdia enviada via um mensageiro seguro ou outro

mtodo de entrega que possa ser rastreado com preciso?
9.8
Existem logs para rastrear todas as mdias que so movidas de

uma rea segura, com aprovao da gerncia antes da
transferncia da mdia (especialmente quando a mdia
distribuda para pessoas fsicas)?
9.9
mantido um controle rigoroso sobre o armazenamento e a

acessibilidade das mdias?
9.9.1
9.10
Sim
No
Especial
Os logs de inventrio de toda a mdia so mantidos

adequadamente e os inventrios peridicos das mdias so
realizados pelo menos uma vez ao ano?
Todas as mdias so destrudas quando no so mais
necessrias por razes corporativas ou legais?
A destruio executada da seguinte forma:
9.10.1
(a) Os materiais impressos so fragmentados, incinerados

ou reciclados, de forma que os dados do titular do
carto no possam ser reconstrudos?
(b) Os contineres que armazenam informaes so
destrudos de forma segura para prevenir o acesso aos
contedos? (Por exemplo: um continer "a ser triturado"
tem uma trava que impede o acesso ao seu contedo.)
9.10.2
Os dados do titular do carto nas mdias eletrnicas so

excludos por meio de um programa de limpeza segura, de
acordo com os padres do setor para excluso segura, ou
de outra forma, destruindo fisicamente as mdias (por
exemplo, desmagnetizando) para que os dados do titular do
carto no possam ser reconstrudos?

Outubro de 2010
Pgina 24
Monitorar e testar as redes regularmente

Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da
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 privilgios administrativos como raiz) para cada usurio
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 usurios aos dados do

titular do carto?
10.2.2
Todas as aes desempenhadas por qualquer pessoa com

privilgios raiz ou administrativos?
10.2.3
Acesso a todas as trilhas de auditoria?
10.2.4
Tentativas de acesso lgico invlidas?
10.2 5
Uso de mecanismos de identificao e autenticao?
10.2.6
Inicializao dos logs de auditoria?
10.2.7
Criao e excluso de objetos do nvel do sistema?
Sim
No
Especial
As seguintes entradas da trilha de auditoria so registradas para

todos os componentes do sistema para cada um dos eventos a
seguir?
10.3.1
Identificao do usurio?
10.3.2
Tipo de evento?
10.3.3
Data e hora?
10.3.4
Indicao 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 relgios e horrios dos sistemas crticos esto

sincronizados atravs do uso de uma tecnologia de
sincronizao e essa tecnologia mantida atualizada?
Observao: Um exemplo de tecnologia de sincronizao de
horrios o Network Time Protocol (NTP).
(b) Os controles a seguir foram implementados para aquisio,
distribuio e armazenamento de horrios?
10.4.1
(a) Somente os servidores centrais de horrio designados

recebem sinais de horrio de fontes externas e todos os
sistemas crticos possuem o mesmo horrio correto, com
base na hora internacional do relgio atmico (UTC)?

Outubro de 2010
Pgina 25
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(b) Os servidores centrais de horrio designados esto

emparelhados para manter o horrio preciso e os outros
servidores internos recebem o horrio somente dos
servidores centrais de horrio?
10.4.2
Os dados de horrio so protegidos conforme a descrio a

seguir?
(a) O acesso aos dados de horrio restrito somente s
equipes com necessidades comerciais de acesso aos
dados de horrio?
(b) As alteraes nas configuraes de horrios dos
sistemas crticos so registradas, monitoradas e
analisadas?
10.4.3
10.5
As configuraes de horrio so recebidas de fontes de

horrio especficas aceitas pelo setor?
(Isso feito para evitar a alterao do relgio por um
indivduo mal-intencionado). Alm disso, essas atualizaes
podem ser criptografadas com uma chave simtrica e listas
de controle de acesso podem ser criadas para especificar os
endereos IP das mquinas clientes que recebero as
atualizaes de horrio (para evitar o uso no autorizado dos
servidores de horrio internos).
As trilhas de auditoria esto protegidas de forma que no possam

ser alteradas, conforme a descrio a seguir?
10.5.1
A visualizao das trilhas de auditoria limitada s pessoas

com necessidades relacionadas funo?
10.5.2
Os arquivos de trilha de auditoria esto protegidos contra

modificaes no autorizadas por meio de mecanismos de
controle de acesso, separao fsica e/ou separao da
rede?
10.5.3
O backup dos arquivos de trilha de auditoria feito

imediatamente em um servidor de log centralizado ou em
uma mdia que seja difcil de alterar?
10.5.4
Os logs das tecnologias externas (como tecnologias sem fio,

firewalls, DNS, e-mail) so transferidos ou copiados em uma
mdia ou em um servidor de log centralizado seguro na LAN
interna?
10.5.5
So usados softwares de monitoramento da integridade dos

arquivos ou de deteco de alteraes nos logs para
assegurar que os dados do log existentes no possam ser
alterados sem gerar alertas (embora os novos dados que
estejam sendo adicionados no gerem um alerta)?

Outubro de 2010
Pgina 26
Pergunta do PCI DSS
Resposta:
10.6
Os logs de todos os componentes do sistema so analisados

diariamente e necessrio o acompanhamento das excees?
As anlises dos logs incluem aqueles servidores que
desempenham funes de segurana como sistema de deteco
de invases (IDS) e servidores de protocolo de autenticao,
autorizao e inventrio (AAA) (como o RADIUS).
Observao: Ferramentas de coleta, anlise e alerta de logs
podem ser usadas para a obteno da conformidade com o
Requisito 10.6.
10.7
(a) Existem polticas e procedimentos de reteno de logs de

auditoria em vigor que exigem a reteno do histrico das
trilhas de auditoria por pelo menos um ano?
Sim
No
Especial
No
Especial
(b) Os logs de auditoria ficam disponveis por pelo menos um ano

e existem processos em vigor para restaurar imediatamente
pelo menos os logs dos trs ltimos meses para anlise?
Requisito 11: Testar regularmente os sistemas e processos de segurana

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?
Observao: Os mtodos que podem ser usados no processo
incluem, entre outros, varreduras de rede sem fio, inspees
fsicas/lgicas dos componentes e da infraestrutura do sistema,
controle de acesso rede (NAC) ou IDS/IPS sem fio.
Qualquer mtodo usado deve ser suficiente para detectar e
identificar qualquer dispositivo no autorizado.
(b) A metodologia adequada para detectar e identificar qualquer
ponto de acesso sem fio no autorizado, incluindo ao menos
os itens a seguir?
Cartes WLAN inseridos nos componentes do sistema;
Dispositivos portteis 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 no

autorizados executado ao menos trimestralmente em todos
os componentes do sistema e em todas as instalaes?
(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 deteco de dispositivos sem fio no
autorizados?

Outubro de 2010
Pgina 27
Pergunta do PCI DSS

11.2
Resposta:
Sim
No
Especial
So executadas varreduras das vulnerabilidades das redes

internas e externas pelo menos trimestralmente e aps qualquer
alterao significativa na rede (como instalaes de novos
componentes do sistema, alteraes na topologia da rede,
modificaes das normas do firewall, upgrades de produtos) da
seguinte forma?
Observao: No ser necessrio que quatro varreduras
trimestrais aprovadas sejam concludas para a conformidade
inicial do PCI DSS se 1) o resultado da varredura mais recente foi
uma varredura aprovada, 2) a entidade possuir polticas 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 aps a anlise inicial do PCI DSS,
quatro varreduras trimestrais aprovadas devem ter ocorrido.
11.2.1
(a) So 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 so executadas por um recurso interno
qualificado ou um terceiro externo qualificado e, caso
aplicvel, h uma independncia organizacional do
responsvel pelo teste (no necessrio que seja um
QSA ou ASV)?
11.2.2
(a) So 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
automtica)?
(c) As varreduras das vulnerabilidades externas trimestrais
so executadas por um Fornecedor de varredura
aprovado (ASV) qualificado pelo Conselho de padres
de segurana do setor de cartes de pagamento (PCI
SSC)?

Outubro de 2010
Pgina 28
Pergunta do PCI DSS

11.2.3
Resposta:
Sim
No
Especial
(a) So executadas varreduras internas e externas aps

qualquer alterao significativa na rede (como
instalaes de novos componentes do sistema,
alteraes na topologia da rede, modificaes das
normas do firewall, upgrades de produtos)?
Observao: As varreduras realizadas aps as alteraes
na rede devem ser desempenhadas pela equipe interna da
empresa.
(b) O processo de varredura inclui novas varreduras at
que:
No existam varreduras com pontuao 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 so executadas por um recurso interno

qualificado ou um terceiro externo qualificado e, caso
aplicvel, h uma independncia organizacional do
responsvel pelo teste (no necessrio que seja um
QSA ou ASV)?
11.3
(a) So realizados testes de penetrao externos e internos pelo

menos uma vez por ano e aps qualquer alterao
significativa na infra-estrutura ou nos aplicativos (como um
upgrade no sistema operacional e a adio 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 so realizados por um recurso interno qualificado
ou um terceiro externo qualificado e, caso seja aplicvel, h
uma independncia organizacional do responsvel pelo teste
(no necessrio que seja um QSA ou ASV)?
Esses testes de penetrao incluem os itens a seguir?
11.4
11.3.1
Testes de penetrao na camada de rede?

Observao: Esses testes devem incluir componentes que
so compatveis com as funes da rede e com os sistemas
operacionais.
11.3.2
Testes de penetrao na camada do aplicativo?

Observao: Os testes devem incluir, no mnimo, as
vulnerabilidades listadas no Requisito 6.5.
(a) Existem sistemas de deteco de invaso e/ou sistemas de

preveno contra invaso em uso para monitorar todo o
trfego no ambiente de dados do titular do carto e nos pontos
crticos do ambiente dos dados do titular do carto?
(b) Os IDS e/ou os IPS esto configurados para alertar as equipes
sobre comprometimentos suspeitos?

Outubro de 2010
Pgina 29
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(c) Todos os mecanismos, diretrizes e assinaturas para deteco

e preveno contra invases esto atualizados?
11.5
(a) Existem ferramentas de monitoramento da integridade dos

arquivos implementadas no ambiente dos dados do titular do
carto?
Os exemplos de arquivos que devem ser monitorados incluem:
Executveis do sistema
Executveis dos aplicativos
Arquivos de configurao e parmetro
Arquivos de log e auditoria, histricos ou arquivados,
armazenados centralmente
(b) As ferramentas esto configuradas para alertar a equipe sobre
a modificao no autorizada de arquivos dos sistemas
crticos e de arquivos de configurao ou de contedo, com
comparao pelo menos uma vez por semana dos arquivos
crticos?
Observao: Para fins de monitoramento da integridade dos
arquivos, os arquivos crticos normalmente so aqueles que no
so alterados com frequncia, mas sua modificao poderia
indicar um comprometimento do sistema ou um risco de
comprometimento. Normalmente, os produtos de monitoramento
da integridade dos arquivos vm pr-configurados com arquivos
crticos para o sistema operacional relacionado. Outros arquivos
crticos, como aqueles dos aplicativos personalizados, devem ser
avaliados e definidos pela entidade (ou seja, o comerciante ou
prestador de servios).

Outubro de 2010
Pgina 30
Manter uma poltica de segurana de informaes

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas
as equipes
Pergunta do PCI DSS
12.1
Resposta:
Sim
No
Especial
Existe uma poltica de segurana estabelecida, publicada, mantida

e disseminada para todas as equipes relevantes?
Para as finalidades do Requisito 12, "equipe" refere-se a
funcionrios que trabalham em perodo integral e meio-perodo,
funcionrios e equipes temporrias, e prestadores de servios e
consultores que "residem" no endereo da entidade ou tm acesso
ao ambiente de dados do titular do carto.
12.1.1
A poltica cumpre todos os requisitos do PCI DSS?
12.1.2
(a) Existe algum processo anual documentado de avaliao

de risco que identifique ameaas e vulnerabilidades,
resultando em uma avaliao de risco formal?
(Os exemplos de metodologias de avaliao de risco
incluem, entre outros, OCTAVE, ISO 27005 e NIST SP 80030.)
(b) O processo de avaliao de risco executado pelo
menos uma vez por ano?
12.1.3
A poltica de segurana das informaes analisada pelo

menos uma vez por ano e atualizada conforme necessrio
para refletir as alteraes nos objetivos de negcios ou no
ambiente de risco?
12.2
So desenvolvidos procedimentos de segurana operacional

diariamente que estejam em conformidade com os requisitos desta
especificao (como procedimentos de manuteno da conta do
usurio e procedimentos de anlise de logs) que incluem
procedimentos tcnicos e administrativos para cada requisito?
12.3
Existem polticas de utilizao para tecnologias crticas (por

exemplo: tecnologias de acesso remoto, tecnologias sem fio, mdia
eletrnica removvel, 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
Aprovao explcita pelas partes autorizadas para uso das

tecnologias?
12.3.2
Autenticao para o uso da tecnologia?
12.3.3
Uma lista de todos esses dispositivos e equipes com

acesso?
12.3.4
Identificao dos dispositivos para determinar o proprietrio,

informaes de contato e a finalidade?
12.3.5
Usos aceitveis das tecnologias?

Outubro de 2010
Pgina 31
Pergunta do PCI DSS
Resposta:
12.3.6
Locais de rede aceitveis para as tecnologias?
12.3.7
Lista dos produtos aprovados pela empresa?
12.3.8
Desconexo automtica das sesses para tecnologias de

acesso remoto aps um perodo especfico de inatividade?
12.3.9
Ativao de tecnologias de acesso remoto para

fornecedores e parceiros de negcio somente quando lhes
for necessrio, com desativao imediata aps o uso?
12.3.10
(a) No acesso da equipe aos dados do titular do carto por

meio de tecnologias de acesso remoto, a poltica
especifica a proibio de cpia, transferncia e
armazenamento dos dados do titular do carto em
discos rgidos locais e mdias eletrnicas removveis,
exceto quando explicitamente autorizado para uma
necessidade comercial definida?
Sim
No
Especial
(b) Para membros da equipe com autorizao adequada, a

poltica exige a proteo dos dados do titular do carto
de acordo com os Requisitos do PCI DSS?
12.4
A poltica e os procedimentos de segurana definem claramente as

responsabilidades quanto segurana das informaes para todas
as equipes?
12.5
A responsabilidade pela segurana das informaes atribuda

formalmente para uma pessoa responsvel pela segurana ou
para outro membro da gerncia que tenha conhecimento sobre
segurana?
As seguintes responsabilidades do gerenciamento da segurana
da informao so atribudas formalmente para as pessoas e para
as equipes que:
12.6
12.5.1
Estabelecem, documentam e distribuem polticas e

procedimentos de segurana?
12.5.2
Monitoram e analisam os alertas e as informaes de

segurana e os distribui para as equipes apropriadas?
12.5.3
Estabelecem, documentam e distribuem procedimentos de

resposta e escalao de incidentes de segurana para
assegurar que todas as situaes sejam abordadas de modo
oportuno e eficiente?
12.5.4
Administram as contas dos usurios, incluindo adies,

excluses e modificaes?
12.5.5
Monitoram e controlam todos os acessos aos dados?
(a) Existe algum programa formal de conscientizao da

segurana em vigor para conscientizar todas as equipes sobre
a importncia da segurana dos dados do titular do carto?
(b) Os procedimentos do programa de conscientizao da
segurana incluem os itens a seguir?

Outubro de 2010
Pgina 32
Pergunta do PCI DSS

12.6.1
Resposta:
Sim
No
Especial
(a) O programa de conscientizao da segurana fornece

vrios mtodos para comunicao da conscientizao e
instruo da equipe (como cartazes, cartas,
memorandos, treinamento baseado na Web, reunies e
promoes)?
Observao: Os mtodos podem variar dependendo da
funo de cada funcionrio e do nvel de acesso aos dados
do titular do carto.
(b) As equipes so instrudas na contratao 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 poltica e os
procedimentos de segurana da empresa?
12.7
Os possveis funcionrios (consulte a definio de "funcionrio" no

Requisito 12.1 acima) so examinados antes da contratao para
minimizar o risco de ataques de fontes internas? (Exemplos de
verificaes da formao incluem o histrico do emprego anterior,
ficha criminal, histrico de crdito e verificaes das referncias.)
Observao: Para a contratao de funcionrios para certas
funes, como os caixas de loja que tm acesso somente a um
nmero do carto por vez ao viabilizar uma transao, este
requisito apenas uma recomendao.
12.8
Se os dados do titular do carto forem compartilhados com

prestadores de servios, existem polticas e procedimentos
mantidos e implementados para gerenciar prestadores de servios,
conforme os itens a seguir:
12.9
12.8.1
mantida uma lista de prestadores de servios?
12.8.2
mantido um acordo por escrito que inclua um

reconhecimento de que os prestadores de servios so
responsveis pela segurana dos dados do titular do carto
que eles possurem?
12.8.3
Existe um processo definido para a contratao dos

prestadores de servios, incluindo uma diligncia devida
adequada antes da contratao?
12.8.4
mantido um programa para monitorar anualmente o status

de conformidade com o PCI DSS dos prestadores de
servios?
Foi implementado um plano de resposta a incidentes para incluir o

seguinte, em preparao a reagir imediatamente a uma violao
no sistema?
12.9.1
(a) Foi criado um plano de resposta a incidentes para ser

implementado em caso de violao do sistema?
(b) O plano aborda, pelo menos:

Outubro de 2010
Pgina 33
Pergunta do PCI DSS
Resposta:
Funes, responsabilidades e estratgias de

comunicao e contato no caso de um
comprometimento, incluindo, no mnimo, a notificao
s bandeiras?
Procedimentos de resposta especficos a incidentes?
Procedimentos de recuperao e continuidade dos

negcios?
Processos de backup dos dados?
Anlise dos requisitos legais para divulgao dos

comprometimentos?
Abrangncia e respostas de todos os componentes

crticos do sistema?
Referncia ou incluso de procedimentos de resposta

a incidentes por parte das bandeiras?
12.9.2
O plano testado pelo menos anualmente?
12.9.3
Equipes especficas so designadas para estarem

disponveis em tempo integral para reagir aos alertas?
12.9.4
O treinamento adequado prestado equipe que

responsvel pela resposta s falhas do sistema?
12.9.5
Os alertas dos sistemas de deteco de invaso, preveno

contra invases e monitoramento da integridade dos
arquivos esto includos 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 lies
aprendidas, para incorporar os desenvolvimentos do setor?

Sim
No
Especial
Outubro de 2010
Pgina 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 carto
Pergunta do PCI DSS
A.1
Resposta:
Sim
No
Especial
O ambiente hospedado e os dados de cada entidade (seja

comerciante, prestador de servios ou outra entidade) esto
protegidos de acordo com os itens A.1.1 a A.1.4, conforme a
descrio a seguir?
O provedor de hospedagem deve cumprir esses requisitos e
todas as outras sees relevantes do PCI DSS.
Observao: Mesmo que o provedor de hospedagem cumpra
esses requisitos, a conformidade da entidade que usa o provedor
de hospedagem no est assegurada. Cada entidade deve estar
em conformidade com o PCI DSS e validar a conformidade,
conforme aplicvel.
A.1.1
A.1.2
Cada entidade executa processos que acessam somente

o ambiente de dados do titular de carto da entidade e
esses processos de aplicativos so executados usando
um ID exclusivo da entidade?
Por exemplo:
Nenhuma entidade no sistema pode usar um ID

de usurio do servidor da Web compartilhado.
Todos os scripts CGI usados por uma entidade

devem ser criados e executados como o ID do
usurio exclusivo da entidade.
Os acessos e privilgios de acesso de cada entidade so

restritos ao seu ambiente prprio de dados do titular do
carto?
(a) Os IDs de usurio dos processos de aplicativos no
so usurios com acesso privilegiado (raiz/admin)?
(b) Cada entidade leu, gravou ou executou somente as
permisses referentes aos arquivos e diretrios que
possui ou para os arquivos de sistema necessrios
(restringidos por meio das permisses do sistema de
arquivo, listas de controle de acesso, chroot, jailshell,
etc.)?
Importante: Os arquivos de uma entidade no podem ser
compartilhados em grupo.
(c) Todos os usurios da entidade no tm acesso de
gravao aos arquivos binrios compartilhados do
sistema?
(d) A visualizao das entradas de log restrita
entidade detentora?
SAQ D do PCI DSS, v2.0, Questionrio de auto-avaliao, Anexo A

Outubro de 2010
Pgina 35
Pergunta do PCI DSS
Resposta:
Sim
No
Especial
(e) Existem restries em vigor para o uso destes

recursos do sistema?
Espao em disco,
Largura de banda,
Memria,
CPU
Isso feito para assegurar que as entidades no possam
monopolizar os recursos do servidor para explorar as
vulnerabilidades (como condies de erro, acelerao e
reinicializao, resultando em excessos de buffer),
A.1.3
A.1.4
Os logs e as trilhas de auditoria esto ativados e so

exclusivos para o ambiente de dados do titular do carto
de cada entidade, alm de estarem em conformidade com
o Requisito 10 do PCI DSS?
O log est ativado conforme a descrio a seguir em cada
ambiente do comerciante e do prestador de servios?
Os logs esto ativados para aplicativos de

terceiros comuns?
Os logs esto ativados por padro?
Os logs esto disponveis para anlise pela

entidade detentora?
As localizaes dos logs so informadas com

clareza entidade detentora?
Existem processos e polticas por escrito ativados para

fornecer uma investigao forense oportuna no caso de
um comprometimento em qualquer comerciante ou
prestador de servios hospedado?
SAQ D do PCI DSS, v2.0, Questionrio de auto-avaliao, Anexo A

Outubro de 2010
Pgina 36
Apndice B: Controles de compensao

Os controles de compensao podem ser considerados na maioria dos requisitos do PCI DSS quando
uma entidade no for capaz de atender a um requisito de forma explcita, conforme informado, devido a
restries de negcios documentadas ou tcnicas legtimas, mas minimizou o risco associado ao
requisito de modo suficiente por meio da implementao de outros controles, incluindo os de
compensao.
Os controles de compensao devem atender aos seguintes critrios:
1. Atender a inteno e o rigor do requisito original do PCI DSS.
2. Fornecer um nvel semelhante de defesa ao requisito original do PCI DSS, como o controle de
compensao que contrabalana o risco de modo suficiente para o qual o requisito original do PCI
DSS tenha sido criado para fornecer uma defesa. (Consulte a seo Navegando no PCI DSS para
obter informaes sobre a inteno de cada requisito do PCI DSS.)
3. Estar "acima e alm" dos outros requisitos do PCI DSS. (Simplesmente estar em conformidade com
os requisitos do PCI DSS no um controle de compensao.)
Ao utilizar o critrio de avaliao "acima e alm" para controles de compensao, considere o
seguinte:
Observao: Os itens nas alternativas a) a c) abaixo so apenas exemplos. Todos os
controles de compensao devem ser analisados e validados quanto suficincia pelo
responsvel pela avaliao que realiza a anlise do PCI DSS. A efetividade de um controle de
compensao depende das especificidades do ambiente no qual o controle est
implementado, dos controles de segurana ao redor e da configurao do controle. As
empresas devem estar cientes de que um determinado controle de compensao no ser
efetivo em todos os ambientes.
a) Os requisitos existentes do PCI DSS NO PODERO ser considerados como controles de
compensao se j tiverem sido exigidos para o item sob anlise. Por exemplo: as senhas para
o acesso administrativo realizado fora do console devem ser enviadas criptografadas para
minimizar o risco de interceptao de senhas administrativas em texto simples. As entidades no
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 no diminuem o risco de interceptao de senhas de texto simples. Alm disso, os outros
controles de senha j so requisitos do PCI DSS referentes ao item sob anlise (senhas).
b) Os requisitos existentes do PCI DSS PODERO ser considerados como controles de
compensao se forem exigidos para outra rea, mas no para o item sob anlise. Por exemplo:
uma autenticao com dois fatores um requisito do PCI DSS para o acesso remoto. A
autenticao com dois fatores a partir da rede interna tambm pode ser considerada um controle
de compensao para o acesso administrativo fora do console quando no houver suporte para
a transmisso de senhas criptografadas. A autenticao com dois fatores poder ser um controle
de compensao aceitvel se (1) atender inteno do requisito original ao abordar o risco de
interceptao 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 compensao. Por exemplo: se uma empresa no for capaz de tornar
os dados do titular do carto ilegveis de acordo com o requisito 3.4 (por exemplo, por meio da
criptografia), um controle de compensao poderia consistir de um dispositivo ou uma
combinao de dispositivos, aplicativos e controles que abordam todos os itens a seguir: (1)
segmentao da rede interna; (2) filtragem de endereo IP ou endereo MAC; e (3) autenticao
com dois fatores dentro da rede interna.
4. Ser proporcional ao risco adicional imposto pelo no cumprimento do requisito do PCI DSS.
SAQ D do PCI DSS, v2.0, Anexo B: Controles de compensao

Outubro de 2010
Pgina 37
O responsvel pela avaliao deve analisar os controles de compensao por completo durante cada
avaliao anual do PCI DSS para validar se cada controle de compensao 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 compensao permaneam efetivos aps a concluso da avaliao.
SAQ D do PCI DSS, v2.0, Anexo B: Controles de compensao

Outubro de 2010
Pgina 38
Anexo C: Planilha dos controles de compensao

Use esta planilha para definir os controles de compensao com relao a qualquer requisito no qual a
opo "SIM" tenha sido assinalada e os controles de compensao tenham sido mencionados na coluna
"Especial".
Observao: Somente as empresas que realizaram uma anlise dos riscos e tm restries de negcios
documentadas ou tecnolgicas legtimas podem considerar o uso dos controles de compensao para
atingir a conformidade.
Nmero e definio do requisito:
Informaes necessrias
1. Restries
Listar as restries que impossibilitam a

conformidade com o requisito original.
2. Objetivo
Definir o objetivo do controle original;

identificar o objetivo atendido pelo
controle de compensao.
3. Risco identificado
Identificar qualquer risco adicional

imposto pela ausncia do controle
original.
4. Definio dos
controles de
compensao
Definir os controles de compensao e

explicar como eles abordam os
objetivos do controle original e o
aumento dos riscos, caso haja algum.
5. Validao dos
controles de
compensao
Definir como os controles de

compensao foram validados e
testados.
6. Manuteno
Definir o processo e os controles

implementados para manter os
controles de compensao.
SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensao

Explicao
Outubro de 2010
Pgina 39
Planilha dos controles de compensao Exemplo completo

Use esta planilha para definir os controles de compensao com relao a qualquer requisito no qual a
opo "SIM" tenha sido assinalada e os controles de compensao tenham sido mencionados na coluna
"Especial".
Nmero do requisito: 8.1 Todos os usurios so identificados com um nome de usurio exclusivo
antes de permitir que eles acessem os componentes do sistema ou os dados do titular do carto?
Informaes necessrias
Explicao
1. Restries
Listar as restries 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 no pode gerenciar o login
"raiz" nem possvel registrar todas as
atividades "raiz" por usurio.
2. Objetivo
Definir o objetivo do controle

original; identificar o objetivo
atendido pelo controle de
compensao.
O objetivo de exigir logins exclusivos duplo.

Primeiro, no considerado aceitvel, da
perspectiva de segurana, compartilhar
credenciais de login. Segundo, ter logins
compartilhados impossibilita afirmar em
definitivo quem responsvel por uma
determinada ao.
3. Risco identificado
Identificar qualquer risco

adicional imposto pela
ausncia do controle
original.
O risco adicional ocorre no sistema de

controle de acesso ao no assegurar que
todos os usurios tenham um ID exclusivo e
possam ser monitorados.
4. Definio dos
controles de
compensao
Definir os controles de
compensao 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

usurios efetuem login nos servidores a partir
dos seus desktops usando o comando SU.
Esse comando permite que um usurio
acesse a conta "raiz" e desempenhe aes na
conta "raiz", mas possa efetuar login no
diretrio de log do SU. Nesse caso, as aes
de cada usurio podem ser monitoradas por
meio da conta do SU.
5. Validao dos
controles de
compensao
Definir como os controles de

compensao foram
validados e testados.
A empresa XYZ demonstra ao responsvel

pela avaliao o comando SU que est sendo
executado e que as pessoas que esto
usando o comando efetuaram login para
identificar que o indivduo est
desempenhando aes com privilgios raiz.
6.
Definir o processo e os
controles implementados
para manter os controles de
compensao.
A empresa XYZ documenta os processos e

procedimentos para assegurar que as
configuraes do SU no sejam modificadas,
alteradas ou removidas para permitir que os
usurios individuais executem comandos raiz
sem serem monitorados ou efetuarem login
individualmente.
Manuteno
SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensao

Outubro de 2010
Pgina 40
Apndice D: Explicao de no aplicabilidade

Se "N/A" ou "No aplicvel" tiver sido inserido na coluna "Especial", use esta planilha para explicar por
que o requisito relacionado no se aplica sua organizao.
Requisito
Motivo pelo qual o requisito no se aplica
Exemplo:
9.3.1
Os visitantes no pode entrar em reas onde os dados do titular do carto so

processados ou guardados.
SAQ D do PCI DSS, v2.0, Anexo D: Explicao de no aplicabilidade

Outubro de 2010
Pgina 41

PCI DSS Autoavaliacao PCI

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PCI DSS Autoavaliacao PCI

Enviado por

Direitos autorais:

Formatos disponíveis

Setor de cartes de pagamento (PCI)

Padro de segurana de dados

Todos os outros SAQs - Comerciantes e

Para alinhar o contedo com o novo PCI DSS v1.2 e para

Para alinhar o contedo com os novos requisitos e procedimentos de

SAQ D do PCI DSS, v2.0, Alteraes no documento

Atestado de conformidade, SAQ D Verso do comerciante ................................. 1

Controles de compensao ........................................................... 37

Planilha dos controles de compensao ...................................... 39

Planilha dos controles de compensao Exemplo completo.........................................40

Explicao de no aplicabilidade .................................................. 41

SAQ D do PCI DSS, v2.0, ndice

Padro de segurana de dados do PCI: Documentos relacionados

Padro de segurana de dados do PCI:

Navegando pelo PCI DSS:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI:

Padro de segurana de dados do PCI e Padro de segurana

Para determinar o Questionrio de auto-avaliao adequado, consulte o Padro de segurana de

Antes de voc comear

Comerciantes do tipo carto no presente (comrcio eletrnico ou pedidos por

Comerciantes com mquinas de carbono, sem armazenamento eletrnico dos

Comerciantes que usam somente terminais virtuais baseados na Web, sem

Comerciantes com sistemas de aplicativos de pagamento conectados Internet,

Todos os outros comerciantes (no includos nas descries dos SAQs A a C

Conformidade do PCI DSS Etapas para preenchimento

SAQ D do PCI DSS, v2.0, Antes de voc comear

Orientao para no aplicabilidade de determinados requisitos especficos

As perguntas especficas relacionadas a dispositivos sem fio s precisaro ser respondidas se

As questes especficas para aplicativos e cdigos personalizados (Requisitos 6.3 e 6.5) s

SAQ D do PCI DSS, v2.0, Antes de voc comear

Atestado de conformidade, SAQ D Verso do comerciante

Parte 1. Informaes sobre o comerciante e o avaliador de segurana qualificado

Parte 2. Tipo de negcio do comerciante (assinale todas as alternativas que se

Gneros alimentcios e supermercados

Pedido por correio/telefone

Parte 2a. Relaes

Sua empresa se relaciona com mais de um adquirente?

Parte 2b. Processamento das transaes

ltima validao de acordo com o

Parte 3. Validao do PCI DSS

Parte 3a. Confirmao do status de conformidade

SAQ D do PCI DSS, v2.0, Atestado de conformidade, Verso do comerciante

Parte 3b. Reconhecimento do comerciante

Assinatura do responsvel executivo pelo comerciante

Nome do responsvel executivo pelo comerciante

Empresa comerciante representada

Parte 4. Plano de ao para status de no conformidade

Instalar e manter uma configurao de

No usar padres disponibilizados pelo

Proteger os dados armazenados do

Criptografar a transmisso dos dados do

Usar e atualizar regularmente o software

Desenvolver e manter sistemas e

Restringir o acesso aos dados do titular

Atribuir uma identidade exclusiva para

SAQ D do PCI DSS, v2.0, Atestado de conformidade, Verso do comerciante

Data e aes de correo

Restringir o acesso fsico aos dados do

Acompanhar e monitorar todos os