SAQ D v20 12 2 10 Form PT-BR PDF

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 1 de outubro de 2008 28 de outubro de 2010 Verso 1.2 2.0 Descrio Para alinhar o contedo com o novo PCI DSS v1.2 e para implementar alteraes menores observadas desde o original v1.1. 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: Anexo C:
Controles de compensao ........................................................... 37 Planilha dos controles de compensao ...................................... 39
Planilha dos controles de compensao Exemplo completo .........................................40

SAQ D do PCI DSS, v2.0, ndice Copyright 2010 PCI Security Standards Council LLC Outubro de 2010 Pgina ii
Apndice D:
Explicao de no aplicabilidade .................................................. 41
SAQ D do PCI DSS, v2.0, ndice Copyright 2010 PCI Security Standards Council LLC
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 Padro de segurana de dados do PCI: Requisitos e procedimentos da avaliao de segurana Navegando pelo PCI DSS: Entendendo o porqu dos requisitos Padro de segurana de dados do PCI: Diretrizes e instrues de auto-avaliao Padro de segurana de dados do PCI: Questionrio A de auto-avaliao e atestado Padro de segurana de dados do PCI: Questionrio B de auto-avaliao e atestado Padro de segurana de dados do PCI: Questionrio C-VT de auto-avaliao e atestado Padro de segurana de dados do PCI: Questionrio C de auto-avaliao e atestado Padro de segurana de dados do PCI: Questionrio D de auto-avaliao e atestado Padro de segurana de dados do PCI e Padro de segurana de dados de aplicativos de pagamento: Glossrio de termos, abreviaes e acrnimos Pblico Todos os comerciantes e prestadores de servios Todos os comerciantes e prestadores de servios Todos os comerciantes e prestadores de servios Comerciantes qualificados1 Comerciantes qualificados1 Comerciantes qualificados1 Comerciantes qualificados1 Comerciantes e prestadores de servios qualificados1 Todos os comerciantes e prestadores de servios
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".
Outubro de 2010 Pgina iv
SAQ D do PCI DSS, v2.0, Padro de segurana de dados do PCI: Documentos relacionados Copyright 2010 PCI Security Standards Council LLC
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 A 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 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.
C-VT C D
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 Copyright 2010 PCI Security Standards Council LLC Outubro de 2010 Pgina v
SAQ D do PCI DSS, v2.0, Antes de voc comear Copyright 2010 PCI Security Standards Council LLC
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".
SAQ D do PCI DSS, v2.0, Antes de voc comear Copyright 2010 PCI Security Standards Council LLC
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:
SAQ D do PCI DSS, v2.0, Atestado de conformidade, Verso do comerciante Copyright 2010 PCI Security Standards Council LLC
Outubro de 2010 Pgina 1
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 Petrleo Outros (especificar): Listar as instalaes e locais includos na anlise do PCI DSS: Telecomunicaes Comrcio eletrnico Gneros alimentcios e supermercados Pedido por correio/telefone
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.)? Sua empresa se relaciona com mais de um adquirente? Sim No Sim No
Parte 2b. Processamento das transaes

Como e em qual capacidade seu negcio armazena, processa e/ou transmite dados do titular do carto? 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. No h evidncia de armazenamento de dados de tarja magntica (ou seja, rastros)2, dados CAV2, CVC2, 3 4 CID ou CVV2 , ou dados de PIN aps a autorizao da transao em NENHUM sistema revisto durante esta avaliao.
2
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.
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 1 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 SIM NO
Data e aes de correo (se o Status de conformidade for "No")
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.
Status de conformidade (selecione um) 8 Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador Restringir o acesso fsico aos dados do titular do carto Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto Testar regularmente os sistemas e processos de segurana Manter uma poltica que aborde a segurana das informaes para todas as equipes
10
11
12
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:
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:
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 3-D Gerenciamento de contas Autorizao Servios de back-office Gerenciamento do faturamento Compensao e liquidao Preparao de dados Fraude e servios de cobrana Outros (especificar): Provedor de hospedagem Hardware Provedor de hospedagem Web Processamento de emisses Programas de fidelidade Servios gerenciados Servios do comerciante Fornecedor/transmissor redes Gateway/switch de pagamento de Processamento pagamentos ATM Processamento pagamentos MOTO Processamento pagamentos Internet Processamento pagamentos POS Servios adiantado com de de de de
pagamento
Gerenciamento de registros Taxas/pagamentos governo para o
Listar as instalaes e locais includos na anlise do PCI DSS:
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 3-D Gerenciamento de contas Autorizao Servios de back-office Gerenciamento do faturamento Compensao e liquidao Preparao de dados Fraude e servios de cobrana Outros (especificar): Provedor de hospedagem Hardware Provedor de hospedagem Web Processamento de emisses Programas de fidelidade Servios gerenciados Servios do comerciante Fornecedor/transmissor redes Gateway/switch de pagamento de Processamento pagamentos ATM Processamento pagamentos MOTO Processamento pagamentos Internet Processamento pagamentos POS Servios adiantado com de de de de
pagamento
Gerenciamento de registros Taxas/pagamentos governo para o
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 SAQ D do PCI DSS, v2.0, Atestado de conformidade, Verso do comerciante Copyright 2010 PCI Security Standards Council LLC Outubro de 2010 Pgina 3
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. 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..
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. No h evidncia de armazenamento de dados de tarja magntica (ou seja, rastros)5, dados CAV2, CVC2, CID ou CVV26, ou dados de PIN7 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.
Status de conformidade (selecione um) Requisito do PCI DSS 1 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 SIM NO
Data e aes de correo (se o Status de conformidade for "No")
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 Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto Testar regularmente os sistemas e processos de segurana Manter uma poltica que aborde a segurana das informaes para todas as equipes
10
11
12
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? (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? (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?
1.1.2
1.1.5
SAQ D do PCI DSS, v2.0, Questionrio de auto-avaliao Copyright 2010 PCI Security Standards Council LLC
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.2.2 1.2.3 Os arquivos de configurao do roteador esto seguros e sincronizados? 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?
1.3
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? O trfego de Internet de entrada est limitado ao endereo IP dentro da DMZ? As conexes diretas esto proibidas para trfego de entrada ou sada entre a Internet e o ambiente dos dados do titular do carto? A passagem de endereos internos da Internet para a DMZ proibida? O trfego de sada do ambiente de dados do titular do carto para a Internet est explicitamente autorizado? A inspeo com status, tambm conhecida como filtragem de pacote dinmico, est implementada (ou seja, somente conexes estabelecidas podem entrar na rede)?
1.3.2 1.3.3
1.3.4 1.3.5 1.3.6
Pergunta do PCI DSS 1.3.7
Resposta:
Sim
No
Especial*
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? (a) Existem mtodos em vigor para evitar a divulgao de endereos IP privados e de informaes de roteamento pra a Internet? 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.3.8
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?
Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana
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.)
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?
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.
Proteger os dados do titular do carto

Requisito 3: Proteger os dados armazenados do titular do carto
Pergunta do PCI DSS 3.1 3.1.1 Resposta: Sim No Especial*
As polticas e procedimentos de reteno e eliminao de dados so implementadas conforme a seguir: (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)?
Resposta:
Sim
No
Especial*
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. 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? O numero de identificao pessoal (PIN) ou o bloqueio de PIN criptografado no armazenado em nenhuma circunstncia? 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).
3.2.2
3.2.3
3.3
Pergunta do PCI DSS 3.4
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.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.
3.5
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.1 O acesso s chaves criptogrficas est restrito ao menor nmero necessrio de responsveis pela proteo?
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 3.6.2 3.6.3 3.6.4 Os procedimentos de chaves criptogrficas incluem a gerao de chaves criptogrficas robustas? Os procedimentos de chaves criptogrficas incluem a distribuio segura das chaves criptogrficas? Os procedimentos de chaves criptogrficas incluem o armazenamento seguro das chaves criptogrficas? 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)? (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)?
3.6.5
Resposta:
Sim
No
Especial*
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. Os procedimentos de chaves criptogrficas incluem a preveno contra a substituio no autorizada de chaves criptogrficas? Os responsveis pela proteo das chaves criptogrficas devem reconhecer formalmente (por escrito ou eletronicamente) que compreendem e aceitam suas responsabilidades de proteo das chaves?
3.6.7
3.6.8
Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas
(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 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.
4.2
(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?
Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: Usar e atualizar regularmente o software ou programas antivrus
Pergunta do PCI DSS 5.1 5.1.1 Resposta: Sim No Especial*
Os softwares antivrus esto implementados em todos os sistemas normalmente afetados por softwares mal-intencionados? 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)?
5.2
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

(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.
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?
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.
6.4
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? Existe uma separao das tarefas entre a equipe atribuda aos ambientes de desenvolvimento/teste e a equipe atribuda ao ambiente de produo? Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento? As contas e os dados de teste so removidos antes da ativao dos sistemas de produo? 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?
6.4.2
6.4.3 6.4.4 6.4.5
Pergunta do PCI DSS 6.4.5.1 6.4.5.2 6.4.5.3 Documentao de impacto
Resposta:
Sim
No
Especial*
Aprovao documentada pelas partes autorizadas (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. Estouro de buffer? (Validar os limites do buffer e truncar as strings de entrada.) Armazenamento criptogrfico no seguro? (Evitar falhas criptogrficas.) Comunicaes no seguras? (Criptografar corretamente todas as comunicaes autenticadas e confidenciais.) Manuseio incorreto de erros? (No divulgar informaes atravs de mensagens de erro.)
6.5.2 6.5.3 6.5.4 6.5.5
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.5.7 Scripting de site cruzado (XSS). (Validar todos os parmetros antes da incluso, utilizar uma sada de contexto confidencial, etc.) 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.) Falsificao de solicitaes de site cruzado (CSRF). (No responder para credenciais de autorizao e tokens enviados automaticamente pelos navegadores.)
6.5.8
6.5.9
6.6
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.
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
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? 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)? A aprovao documentada (por escrito ou eletronicamente) das partes autorizadas necessria e especifica os privilgios necessrios? Os controles de acesso so implementados por meio de um sistema de controle de acesso automtico? 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 7.2.2 Os sistemas de controle de acesso esto implementados em todos os componentes do sistema? Os sistemas de controle de acesso esto configurados para impor os privilgios concedidos s pessoas com base na classificao e na atribuio da funo? 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.
7.1.2
7.1.3
7.1.4 7.2
7.2.3
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador
Todos os usurios recebem um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do carto? 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 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. (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? (b) Somente para prestadores de servios: As senhas do cliente so criptografadas?
8.2
8.3
8.4
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)? 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)? 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?
8.5.2
8.5.3
Pergunta do PCI DSS 8.5.4 8.5.5 8.5.6
Resposta:
Sim
No
Especial*
O acesso dos usurios desligados da empresa imediatamente desativado ou removido? As contas inativas por mais de 90 dias so removidas ou desativadas? (a) As contas usadas pelos fornecedores para acesso remoto, manuteno ou suporte so ativadas somente durante o perodo necessrio? (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? 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. (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.8
8.5.9
8.5.10
(a) exigido um comprimento mnimo de senha de pelo menos sete caracteres? (b) Somente para prestadores de servios: As senhas dos 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? (b) Somente para prestadores de servios: As senhas dos 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?
Resposta:
Sim
No
Especial*
(a) As tentativas de acesso repetidas so limitadas, bloqueando o ID do usurios aps seis tentativas, no mximo? (b) Somente para prestadores de servios: As senhas dos 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? 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? (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)?
8.5.15
8.5.16
Requisito 9: Restringir o acesso fsico aos dados do titular do carto

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.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? 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.
9.1.3
9.2
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 9.3.1 Todos os visitantes passam pelos procedimentos a seguir? Os visitantes devem obter autorizao antes de entrar em reas nas quais os dados do titular do carto so processados ou mantidos? (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. (a) mantido um controle rigoroso quanto distribuio interna ou externa de qualquer tipo de mdia? (b) Os controles incluem o seguinte:
9.3.2
9.7
Pergunta do PCI DSS 9.7.1 9.7.2 9.8
Resposta:
Sim
No
Especial*
A mdia classificada para que a confidencialidade dos dados possa ser determinada? A mdia enviada via um mensageiro seguro ou outro mtodo de entrega que possa ser rastreado com preciso? 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)? mantido um controle rigoroso sobre o armazenamento e a acessibilidade das mdias?
9.9 9.9.1
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
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?
Monitorar e testar as redes regularmente

Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto
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? Foram implementadas trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos: 10.2.1 10.2.2 10.2.3 10.2.4 10.2 5 10.2.6 10.2.7 Todos os acessos individuais dos usurios aos dados do titular do carto? Todas as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos? Acesso a todas as trilhas de auditoria? Tentativas de acesso lgico invlidas? Uso de mecanismos de identificao e autenticao? Inicializao dos logs de auditoria? Criao e excluso de objetos do nvel do sistema?
10.2
10.3
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 10.3.2 10.3.3 10.3.4 10.3.5 10.3.6 Identificao do usurio? Tipo de evento? Data e hora? Indicao de sucesso ou falha? Origem do evento? Identidade ou nome dos dados, componentes do sistema ou recursos afetados?
10.4
(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)?
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 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).
10.5
As trilhas de auditoria esto protegidas de forma que no possam ser alteradas, conforme a descrio a seguir? 10.5.1 10.5.2 A visualizao das trilhas de auditoria limitada s pessoas com necessidades relacionadas funo? 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? 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? 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? 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)?
10.5.3
10.5.4
10.5.5
Resposta:
Sim
No
Especial*
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. (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? (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?
10.7
Requisito 11: Testar regularmente os sistemas e processos de segurana

(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?
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)?
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.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. Testes de penetrao na camada do aplicativo? Observao: Os testes devem incluir, no mnimo, as vulnerabilidades listadas no Requisito 6.5.
11.3.2
11.4
(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?
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).
Manter uma poltica de segurana de informaes

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes
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 12.1.2 A poltica cumpre todos os requisitos do PCI DSS? (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? 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 12.3.2 12.3.3 12.3.4 12.3.5 Aprovao explcita pelas partes autorizadas para uso das tecnologias? Autenticao para o uso da tecnologia? Uma lista de todos esses dispositivos e equipes com acesso? Identificao dos dispositivos para determinar o proprietrio, informaes de contato e a finalidade? Usos aceitveis das tecnologias?
12.3
Pergunta do PCI DSS 12.3.6 12.3.7 12.3.8 12.3.9 Locais de rede aceitveis para as tecnologias? Lista dos produtos aprovados pela empresa?
Resposta:
Sim
No
Especial*
Desconexo automtica das sesses para tecnologias de acesso remoto aps um perodo especfico de inatividade? Ativao de tecnologias de acesso remoto para fornecedores e parceiros de negcio somente quando lhes for necessrio, com desativao imediata aps o uso? (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? (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.3.10
12.4
A poltica e os procedimentos de segurana definem claramente as responsabilidades quanto segurana das informaes para todas as equipes? 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.5.1 12.5.2 12.5.3 Estabelecem, documentam e distribuem polticas e procedimentos de segurana? Monitoram e analisam os alertas e as informaes de segurana e os distribui para as equipes apropriadas? 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? Administram as contas dos usurios, incluindo adies, excluses e modificaes? Monitoram e controlam todos os acessos aos dados?
12.5
12.5.4 12.5.5 12.6
(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?
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. 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.8.1 12.8.2 mantida uma lista de prestadores de servios? 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? Existe um processo definido para a contratao dos prestadores de servios, incluindo uma diligncia devida adequada antes da contratao? mantido um programa para monitorar anualmente o status de conformidade com o PCI DSS dos prestadores de servios?
12.8
12.8.3
12.8.4
12.9
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:
Pergunta do PCI DSS
Resposta:
Sim
No
Especial*
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 12.9.3 12.9.4 12.9.5
O plano testado pelo menos anualmente? Equipes especficas so designadas para estarem disponveis em tempo integral para reagir aos alertas? O treinamento adequado prestado equipe que responsvel pela resposta s falhas do sistema? 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? 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?
12.9.6
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 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.
A.1.2
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 Copyright 2010 PCI Security Standards Council LLC
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 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? A.1.4 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 Copyright 2010 PCI Security Standards Council LLC
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 Copyright 2010 PCI Security Standards Council LLC
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 Copyright 2010 PCI Security Standards Council LLC
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 2. Objetivo Listar as restries que impossibilitam a conformidade com o requisito original. Definir o objetivo do controle original; identificar o objetivo atendido pelo controle de compensao. Identificar qualquer risco adicional imposto pela ausncia do controle original. Definir os controles de compensao e explicar como eles abordam os objetivos do controle original e o aumento dos riscos, caso haja algum. Definir como os controles de compensao foram validados e testados. Definir o processo e os controles implementados para manter os controles de compensao. Explicao
3. Risco identificado
4. Definio dos controles de compensao 5. Validao dos controles de compensao 6. Manuteno
SAQ D do PCI DSS, v2.0, Anexo C: Planilha dos controles de compensao Copyright 2010 PCI Security Standards Council LLC
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 1. Restries Listar as restries que impossibilitam a conformidade com o requisito original. Explicao 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. 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. 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. 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. 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. 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.
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. Definir os controles de compensao e explicar como eles abordam os objetivos do controle original e o aumento dos riscos, caso haja algum.
4. Definio dos controles de compensao
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 Copyright 2010 PCI Security Standards Council LLC
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 Exemplo: 9.3.1 Motivo pelo qual o requisito no se aplica 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 Copyright 2010 PCI Security Standards Council LLC

SAQ D v20 12 2 10 Form PT-BR PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SAQ D v20 12 2 10 Form PT-BR PDF

Caricato da

Copyright:

Formati disponibili

Setor de cartes de pagamento (PCI) Padro de segurana de dados

Todos os outros SAQs - Comerciantes e prestadores de servios qualificados

Outubro de 2010 Pgina i

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

Controles de compensao ........................................................... 37 Planilha dos controles de compensao ...................................... 39

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

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

Outubro de 2010 Pgina iii

Padro de segurana de dados do PCI: Documentos relacionados

Antes de voc comear

Conformidade do PCI DSS Etapas para preenchimento

Outubro de 2010 Pgina vi

Orientao para no aplicabilidade de determinados requisitos especficos

Outubro de 2010 Pgina vii

Atestado de conformidade, SAQ D Verso do comerciante

Nome do contato principal do QSA:

Outubro de 2010 Pgina 1

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

Parte 2a. Relaes

Parte 2b. Processamento das transaes

Outubro de 2010 Pgina 2

Parte 3. Validao do PCI DSS

Parte 3a. Confirmao do status de conformidade

Outubro de 2010 Pgina 3

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

Data e aes de correo (se o Status de conformidade for "No")

Outubro de 2010 Pgina 4

Outubro de 2010 Pgina 5

Atestado de conformidade, SAQ D Verso do prestador de servios

Parte 1. Informaes do prestador de servios e do assessor de segurana qualificado

Outubro de 2010 Pgina 1

Nome do contato principal do QSA:

Parte 2. Informaes sobre a avaliao do PCI DSS

Gerenciamento de registros Taxas/pagamentos governo para o

Listar as instalaes e locais includos na anlise do PCI DSS:

Outubro de 2010 Pgina 2

Gerenciamento de registros Taxas/pagamentos governo para o

Aplicativo de pagamento em uso

ltima validao de acordo com o PABP/PA-DSS

Parte 3. Validao do PCI DSS

Outubro de 2010 Pgina 4

Parte 3a. Confirmao do status de conformidade

Parte 3b. Confirmao do prestador de servios

Assinatura do responsvel executivo pelo prestador de servios

Nome do responsvel executivo pelo prestador de servios

Representante da empresa prestadora de servios

Parte 4. Plano de ao para status de no conformidade

Outubro de 2010 Pgina 5

Data e aes de correo (se o Status de conformidade for "No")

Outubro de 2010 Pgina 6

Construir e manter uma rede segura

Outubro de 2010 Pgina 1

Pergunta do PCI DSS

1.3.4 1.3.5 1.3.6

Outubro de 2010 Pgina 2

Pergunta do PCI DSS 1.3.7

Outubro de 2010 Pgina 3

Outubro de 2010 Pgina 4

Pergunta do PCI DSS