Pci Dss v2-0

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

Requisitos e procedimentos de avaliao da segurana
Verso 2.0
Outubro de 2010
Alteraes no documento
Data
Outubro de 2008
Verso
1.2
Descrio
Introduzir PCI DSS v1.2 como Requisitos e procedimentos de avaliao da segurana PCI DSS, eliminando a redundncia entre os documentos e fazer mudanas gerais e especficas de Procedimentos de auditoria de segurana PCI DSS v1.1. Para obter informaes completas, consulte Resumo de alteraes no padro de segurana de dados do PCI do PCI DSS Verso 1.1 para 1.2. Adicionar sentena que foi excluda incorretamente entre o PCI DSS v1.1 e v1.2. Corrigir grafia nos procedimentos de teste 6.3.7.a e 6.3.7.b.
Pginas
5 32 33 64
Julho de 2009
1.2.1
Remover marca cinza para as colunas implantado e no implantado nos procedimentos de teste 6.5.b. Para a Planilha de controles de compensao exemplo completo, corrigir o texto no alto da pgina para Use esta planilha para definir os controles de compensao para qualquer requisito indicado como implantado via controles de compensao.
Outubro de 2010
2.0
Atualizar e implementar as alteraes da v1.2.1. Para obter detalhes, consulte o Resumo de alteraes PCI DSS Verso 1.2.1 para 2.0.
Requisitos do PCI DSS e Procedimentos da Avaliao da Segurana, verso 2.0 Copyright 2010 Conselho de Padres de Segurana LLC do PCI
Outubro de 2010 Pgina 2
ndice
Alteraes no documento ................................................................................................................................................................. 2 Introduo e viso geral do padro de segurana de dados do PCI.............................................................................................. 5 Informaes de aplicabilidade do PCI DSS...................................................................................................................................... 8 Relao entre PCI DSS e PA-DSS ................................................................................................................................................... 10 Escopo da avaliao quanto conformidade com os requisitos do PCI DSS ............................................................................ 11
Segmentao da rede.....................................................................................................................................................11 Sem fio............................................................................................................................................................................12 Terceiros/Terceirizao ..................................................................................................................................................12 Amostragem de reas de negcios e componentes do sistema.....................................................................................13 Controles de compensao ............................................................................................................................................14
Instrues e contedo para o relatrio sobre conformidade ....................................................................................................... 15
Contedo e formato do relatrio .....................................................................................................................................15 Revalidao dos itens em aberto....................................................................................................................................18 Conformidade do PCI DSS Etapas de concluso ........................................................................................................19
Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana...................................................................... 20 Construa e mantenha uma rede segura....................................................................................................................................... 21
Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do titular do carto....................21 Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana 26
Proteger os dados do portador do carto.................................................................................................................................... 30
Requisito 3: Proteger os dados armazenados do titular do carto ...............................................................................30 Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas .........................38
Manter um programa de gerenciamento de vulnerabilidades .................................................................................................... 40
Requisito 5: Usar e atualizar regularmente o software ou programas antivrus ...........................................................40 Requisito 6: Desenvolver e manter sistemas e aplicativos seguros .............................................................................41
Implementar medidas de controle de acesso rigorosas............................................................................................................. 47
Requisito 7: o negcio Requisito 8: Requisito 9:
Restringir o acesso aos dados do titular do carto de acordo com a necessidade de conhecimento para 47 Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador..........................49 Restringir o acesso fsico aos dados do titular do carto .........................................................................55
Monitorar e Testar as Redes Regularmente ................................................................................................................................ 60
Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do portador do carto...................... ...................................................................................................................................................60 Requisito 11: Testar regularmente os sistemas e processos de segurana. ...............................................................65
Manter uma Poltica de Segurana de Informaes.................................................................................................................... 70
Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes............................70
Anexo A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada ................................... 77 Apndice B: Controles de compensao................................................................................................................................ 80 Anexo C: Planilha dos controles de compensao .......................................................................................................... 82 Planilha dos controles de compensao Exemplo completo.................................................................................................. 83 Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema.............................................. 84
Introduo e viso geral do padro de segurana de dados do PCI

O Padro de Segurana de Dados (DSS) do Setor de Cartes de Pagamento (PCI) foi desenvolvido para incentivar e aprimorar a segurana dos dados do titular do carto e facilitar a ampla adoo de medidas de segurana de dados consistentes no mundo todo. O PCI DSS oferece a base de requisitos tcnicos e operacionais projetados para proteger os dados do titular do carto. O PCI DSS se aplica a todas as entidades envolvidas no processos de pagamento do carto - inclusive comerciantes, financeiras, adquirentes, emissores e prestadores de servio, bem como todas as entidades que armazenam, processam ou transmitem os dados do titular do carto. O PCI DSS compreende um conjunto mnimo de requisitos para proteger os dados do titular do carto e pode ser aperfeioado por controles e prticas adicionais para amenizar os riscos ainda mais. Abaixo, h uma viso geral de alto nvel dos 12 requisitos do PCI DSS.
Este documento, Requisitos dos Padres de Segurana de Dados do PCI e Procedimentos de Avaliao da Segurana, usa como base os 12 requisitos do PCI DSS e combina-os com procedimentos de testes correspondentes em uma ferramenta de avaliao de segurana. Ele foi projetado para o uso durante as avaliaes de conformidade PCI DSS como parte do processo de validao de uma entidade. As seguintes
sees oferecem orientaes e as melhores prticas para auxiliar entidades a conduzir, relatar e se preparar para os resultados de uma avaliao PCI DSS. Os Requisitos e procedimentos de teste PCI DSS se iniciam na pgina 19.
O site do PCI Security Standards Council (PCI SSC - conselho de padres de segurana PCI) (www.pcisecuritystandards.org) contm alguns recursos adicionais, inclusive: Atestado de conformidade Navegando pelo PCI DSS: Entendendo o porqu dos Requisitos Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS Perguntas frequentes (FAQs) Suplementos Informativos e Orientaes Consulte o site www.pcisecuritystandards.org para obter mais informaes. Observao: Os Suplementos Informativos complementam o PCI DSS e identificam consideraes adicionais e recomendaes para atender aos requisitos PCI DSS - eles no alteram, eliminam ou sobrepem o PCI DSS ou qualquer de seus requisitos.
Informaes de aplicabilidade do PCI DSS

O PCI DSS se aplica onde quer que os dados da conta sejam armazenados, processados ou transmitidos. Os Dados da Conta se consistem em Dados do titular do carto mais Dados de autenticao confidenciais, como se segue: Os Dados de autenticao confidenciais incluem: Dados em tarja magntica ou equivalente em chip CAV2/CVC2/CVV2/CID PINs/Bloqueios de PIN
Os Dados do titular do carto incluem: O nmero da conta principal (PAN) O nome do titular do carto Data de vencimento Cdigo de servio
O nmero da conta principal o fator decisivo na aplicabilidade dos requisitos do PCI DSS. Os requisitos do PCI DSS so aplicveis se um nmero de conta principal (PAN) for armazenado, processado ou transmitido. Se um PAN no for armazenado, processado ou transmitido, os requisitos do PCI DSS no so aplicveis. Se o nome, cdigo de servio e/ou data de validade de um titular do carto so armazenados processados ou transmitidos com o PAN ou, de outro modo, esto presentes no ambiente de dados do titular do carto, eles devem ser protegidos de acordo com os Requisitos 3.3 e 3.4 que se aplicam somente ao PAN. O PCI DSS representa um conjunto mnimo de objetivos de controle que podem ser aperfeioados por leis e normas locais, regionais e do setor. Alm disso, os requisitos legais ou regulatrios podem exigir proteo especfica de informaes pessoalmente identificveis ou outros elementos de dados (por exemplo, o nome do titular do carto) ou definir prticas de divulgao de uma entidade ligadas a informaes de clientes. Os exemplos incluem a legislao relacionada proteo de dados de clientes, privacidade, roubo de identidade ou segurana de dados. O PCI DSS no sobrepe as leis locais ou regionais, normas governamentais ou outros requisitos legais. A tabela a seguir ilustra os elementos comumente usados do titular do carto e dados de autenticao confidenciais; se o armazenamento de cada elemento de dados permitido ou proibido; e se cada elemento de dados deve ser protegido. Essa tabela no completa, mas exibida para ilustrar os diferentes tipos de requisitos que se aplicam a cada elemento de dados.
Elemento de dados O nmero da conta principal (PAN) Dados da conta Dados do titular do carto O nome do titular do carto Cdigo de servio Data de vencimento Dados completos da tarja 2 magntica CAV2/CVC2/CVV2/CID PIN/Bloqueio de PIN
Armazenamento permitido
Converte dados de conta armazenados ilegveis pelo Requisito 3.4 Sim No No No No armazenvel pelo Requisito 3.2 No armazenvel pelo Requisito 3.2 No armazenvel pelo Requisito 3.2
Sim Sim Sim Sim No No No
Dados de autenticao confidenciais

1
Os requisitos 3.3 e 3.4 do PCI DSS se aplicam somente ao PAN. Se o PAN for armazenado com outros elementos dos dados do titular do carto, somente o PAN dever ser convertido como ilegvel de acordo com o Requisito 3.4 do PCI DSS. O PCI DSS se aplica somente se os PANs so armazenados, processados e/ ou transmitidos.
1 2
Dados de autenticao confidenciais no devem ser armazenados aps a autorizao (mesmo se forem criptografados). Dados completos de rastreamento da tarja magntica, dados equivalentes no chip, ou em outro lugar.
Relao entre PCI DSS e PA-DSS

O uso de um aplicativo compatvel com o PA-DSS no torna uma entidade compatvel com o PCI DSS por si s, uma vez que o aplicativo deve ser implementado em um ambiente compatvel com o PCI DSS e de acordo com o Guia de Implementao do PA-DSS oferecido pelo fornecedor do aplicativo de pagamento (pelo Requisito 13.1 do PA-DSS). Os requisitos para o Padro de segurana de dados de aplicativos de pagamento (PA-DSS) derivam-se dos Requisitos do PCI DSS e os Procedimentos de avaliao da segurana (este documento). O PA-DSS Error! Hyperlink reference not valid.detalha qual aplicativo de pagamento deve suportar para facilitar a conformidade de um cliente. Os aplicativos de pagamento seguros, quando implementados em um ambiente compatvel com PCI-DSS, minimizaro as possibilidades de quebras na segurana, levando ao comprometimento de todos os dados da tarja magntica, cdigos e valores de validao do carto (CAV2, CID, CVC2 e CVV2), PINs e bloqueios de PIN e a fraudes destruidoras resultantes dessas quebras. Veja a seguir algumas formas nas quais os aplicativos de pagamento podem impedir a conformidade: Armazenamento de dados de tarja magntica e/ou dados equivalentes do chip na rede do cliente aps a autorizao; Aplicativos que exigem que os clientes desabilitem outros recursos necessrios pelo PCI DSS, como software antivrus ou firewalls, para que o aplicativo de pagamento funcione corretamente. Uso por parte do fornecedor de mtodos no seguros para conectar-se ao aplicativo para oferecer suporte ao cliente. O PA-DSS aplica-se a fornecedores de software e outros desenvolvedores de aplicativos de pagamento que armazenam, processam ou transmitem dados de titular de carto como parte da autorizao ou acordo, em que esses aplicativos de pagamento so vendidos, distribudos ou licenciados a terceiros. Observe o seguinte, referente aplicabilidade do PA-DSS: O PA-DSS destina-se a aplicativos de pagamento que geralmente so vendidos e instalados de forma pr-definida sem muita personalizao dos fornecedores de software. O PA-DSS no se destina a aplicativos de pagamento desenvolvidos por comerciantes e fornecedores de servio se utilizados apenas internamente (no vendido, distribudo ou licenciado a terceiros), visto que esse aplicativo de pagamento desenvolvido internamente deveria ser coberto como parte da conformidade normal do comerciante ou fornecedor de servio do PCI DSS. Para obter orientao detalhada sobre a determinao se o PA-DSS se aplica a determinado aplicativo de pagamento, consulte os Requisitos do PA-DSS e os Procedimentos de avaliao da segurana que pode ser encontrado no site www.pcisecuritystandards.org.
Escopo da avaliao quanto conformidade com os requisitos do PCI DSS

Os requisitos de segurana do PCI DSS se aplicam a todos os componentes do sistema. No contexto do PCI DSS, os "componentes do sistema" so definidos como qualquer componente de rede, servidor ou aplicativo que esteja includo ou vinculado ao ambiente de dados do titular do carto. Os "componentes do sistema" tambm incluem quaisquer componentes de virtualizao como mquinas virtuais, switches/roteadores virtuais, mecanismos virtuais, aplicativos/desktops virtuais e hipervisores. O ambiente de dados do titular do caro compreende pessoas, processos e tecnologia que armazenam, processam e transmitem os dados do titular do carto ou dados de autenticao confidenciais. Os componentes de rede incluem, mas no se limitam a, firewalls, chaves, roteadores, pontos de acesso sem fio, mecanismos de rede e outros mecanismos de segurana. Os tipos de servidor incluem, mas no se limitam a: web, aplicativo, banco de dados, autenticao, e-mail, proxy, NTP (network time protocol) e DNS (domain name server). Os aplicativos incluem todos os aplicativos adquiridos e personalizados, incluindo os aplicativos internos e externos (Internet, por exemplo). A primeira etapa de uma avaliao do PCI DSS determinar precisamente o escopo da reviso. Ao menos anualmente e antes da avaliao anual, a entidade deve confirmar a preciso de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do titular do carto e assegurar que estejam includos no escopo do PCI DSS. Para confirmar a preciso e a adequao do escopo do PCI DSS, execute o seguinte: A entidade avaliada identifica e documenta a existncia de todos os dados do titular do carto em seu ambiente, para verificar que nenhum dado de titular do carto existe fora do ambiente de dados do titular do carto definido no momento (CDE). Assim que todos os locais dos dados do titular do carto forem identificados e documentados, a entidade usa os resultados para verificar se o escopo do PCI DSS adequado (por exemplo, os resultados podem ser um diagrama ou um inventrio de locais de dados do titular de carto). A entidade considera que qualquer dado do titular do carto esteja no escopo da avaliao do PCI DSS e parte do CDE, a no ser que tal dado seja excludo ou migrado/consolidado no CDE definido atualmente. A entidade retm a documentao que mostra como o escopo do PCI DSS foi confirmado e os resultados, para a reviso da assessoria e/ou para referncia durante a prxima atividade anual de confirmao do escopo do PCI SCC.
Segmentao da rede
A segmentao da rede ou o isolamento (separao) do ambiente de dados do titular do carto do restante da rede corporativa no um requisito do PCI DSS. Entretanto, ela recomendada como um mtodo que pode reduzir: O escopo da avaliao do PCI DSS O custo da avaliao do PCI DSS O custo e a dificuldade de implementar e manter controles do PCI DSS O risco de uma empresa (reduzido pela consolidao dos dados do titular do carto em locais mais controlados e que totalizam um nmero menor)
Sem a segmentao adequada da rede (s vezes chamada de "rede plana"), toda a rede est no escopo da avaliao do PCI DSS. A segmentao da rede pode ser realizada por meio de firewalls internos da rede, roteadores com listas de controle de acesso rigorosas ou outras tecnologias que restringem o acesso a um determinado segmento de uma rede. Um pr-requisito importante para reduzir o escopo do ambiente de dados do titular do carto uma compreenso clara das necessidades do negcio e dos processos relacionados ao armazenamento, processamento ou transmisso dos dados do titular do carto. Restringir os dados do titular do carto menor quantidade de locais possvel ao eliminar dados desnecessrios e consolidar os dados necessrios talvez exija a reformulao de prticas de negcios de longa data. Documentar os fluxos dos dados do titular do carto por meio de um diagrama de fluxo de dados ajuda a compreender totalmente todos os fluxos de dados do titular do carto e assegura que qualquer segmentao de rede seja eficiente no isolamento do ambiente de dados do titular do carto. Se a segmentao da rede tiver sido implementada e sendo usada para reduzir o escopo da avaliao do PCI DSS, o avaliador dever verificar se a segmentao adequada para diminuir o escopo da avaliao. Em um nvel elevado, a segmentao adequada da rede isola os sistemas que armazenam, processam ou transmitem dados do titular do carto dos outros sistemas. Entretanto, a adequao de uma implementao especfica da segmentao da rede varia muito e depende certos fatores, como uma determinada configurao de rede, das tecnologias implementadas e de outros controles que podem ser empregados. Apndice D: A segmentao e a amostragem dos componentes de sistema/reas de negcio oferece mais informaes sobre o efeito da segmentao e da amostragem da rede no escopo das avaliaes do PCI DSS.
Sem fio
Se uma tecnologia sem fio for usada para armazenar, processar ou transmitir dados do titular do carto (por exemplo, transaes do ponto de venda, "quebra de linha") ou se uma WLAN (local area network sem fio) estiver conectada ao ambiente de dados do titular do carto ou a parte dele (por exemplo, no separado claramente por um firewall), os requisitos do PCI DSS e os procedimentos de teste para ambientes sem fio se aplicaro e devero ser realizados (por exemplo, Requisitos 1.2.3, 2.1.1 e 4.1.1). Antes da tecnologia sem fio ser implementada, uma entidade deve avaliar cuidadosamente a necessidade da tecnologia com relao ao risco. Considere a implementao da tecnologia sem fio somente para a transmisso de dados no confidenciais.
Terceiros/Terceirizao
Para prestadores de servios que devem realizar uma avaliao in loco anual, a validao da conformidade deve ser desempenhada em todos os componentes do sistema no ambiente dos dados do titular do carto. Um prestador de servios ou comerciante pode usar um provedor terceirizado para armazenar, processar ou transmitir dados do titular do carto em seu nome ou gerenciar componentes como roteadores, firewalls, bancos de dados, segurana fsica e/ou servidores. Se for o caso, talvez haja um impacto na segurana do ambiente de dados do titular do carto. Para aquelas entidades que terceirizam o armazenamento, o processamento ou a transmisso dos dados do titular do carto para prestadores de servios terceirizados, o Relatrio sobre a conformidade (ROC) deve registrar a funo de cada prestador de servios, identificando claramente quais requisitos se aplicam entidade avaliada e quais se aplicam ao prestador de servios. H duas opes para que os prestadores de servios terceirizados comprovem a conformidade: Requisitos do PCI DSS e Procedimentos da Avaliao da Segurana, verso 2.0 Copyright 2010 Conselho de Padres de Segurana LLC do PCI Outubro de 2010 Pgina 12
1) Eles podem ser submetidos a uma avaliao do PCI DSS por vontade prpria e fornecer evidncias de sua conformidade a seus clientes; ou 2) Caso no se submetam avaliao do PCI DSS, ser necessrio que tenham seus servios analisados durante o curso de cada avaliao do PCI DSS de seus clientes. Para obter mais informaes, consulte o indicador que comea com "Para anlises do prestador de servios gerenciado (MSP)" no Item 3 na seo "Instrues e contedo para o relatrio sobre conformidade" abaixo. Alm disso, os comerciantes e prestadores de servios devem gerenciar e monitorar a conformidade do PCI DSS de todos os terceiros associados quanto ao acesso aos dados do titular do carto. Para obter detalhes, consulte o Requisito 12.8 nesse documento.
Amostragem de reas de negcios e componentes do sistema

A amostragem no um requisito do PCI DSS. No entanto, aps considerar o escopo e a complexidade gerais do ambiente sendo avaliado, o avaliador pode selecionar amostras representativas de reas de negcios/componentes de sistema independentemente para avaliar os requisitos do PCI DSS. Essas amostras devem ser definidas primeiramente para as reas de negcios e, em seguida, para os componentes de sistema em cada rea de negcio selecionada. As amostras devem ser uma seleo representativa de todos os tipos e locais das reas de negcios, bem como tipos de componentes de sistema nas reas de negcio selecionadas. As amostras devem ser suficientemente amplas para fornecer ao avaliador garantia de que os controles sero implementados conforme o esperado. A amostragem de reas de negcios/componentes de sistema para uma avaliao no reduz o escopo do ambiente dos dados do titular do carto ou a aplicabilidade dos requisitos do PCI DSS. Utilizando ou no a amostragem, os requisitos do PCI DSS se aplicam ao ambiente inteiro dos dados do titular do carto. Caso a amostragem seja usada, cada amostra deve ser avaliada quanto a todos os requisitos do PCI DSS aplicveis. A amostragem dos prprios requisitos do PCI DSS no permitida. Exemplos de reas de negcios incluem mas no se limitam a escritrios corporativos, lojas, locais de franquias, reas de processamento, centros de dados e outros tipo de instalaes em diferentes locais. Os exemplos devem incluir componentes de sistema em cada rea de negcio. Por exemplo, para cada rea de negcio, inclua uma srie de sistemas operacionais, funes e aplicativos que so aplicveis rea sob anlise. Como exemplo, o avaliador poderia selecionar servidores Sun executando Apache WWW, servidores Windows executando Oracle, sistemas do mainframe executando aplicativos de processamento de cartes legados, servidores de transferncia de dados executando HP-UX e servidores Linux executando MYSQL. Se todos os aplicativos forem executados a partir de um nico SO (por exemplo, Windows 7 ou Solaris 10), ento o exemplo tambm dever incluir vrios aplicativos (por exemplo, servidores do banco de dados, servidores da Web, servidores de transferncia de dados). Ao selecionar exemplos de reas de negcios/componentes de sistema, os avaliadores devem considerar o seguinte: Se houver segurana, processos e controles operacionais do PCI DSS implementados de forma padro e centralizada que garanta consistncia e que cada rea de negcio/componente de sistema deva seguir, a amostra poder ser menor do que se no houver processos/controles padronizados implementados. A amostra dever ser ampla o bastante para fornecer ao avaliador garantia razovel de que todas as reas de negcio/componentes do sistema estejam configurados pelo processo padro.
Caso haja mais de um tipo de segurana e ou processo operacional padro implementados (por exemplo, para tipos diferentes de reas de negcio/componentes do sistema), a amostra deve ser ampla o bastante para incluir reas de negcios/componentes do sistema seguros com cada tipo de processo. Caso no haja processos/controles padro implementados e cada rea de negcio/componente do sistema seja gerenciado por meio de processos no padronizados, a amostra deve ser maior para o avaliador se assegurar de que cada rea de negcio/componente do sistema tenha implementado os requisitos apropriadamente. Para cada instncia em que a amostragem for usada, o avaliador dever: Registrar o argumento atrs da tcnica de amostragem e do tamanho da amostragem, Registrar e validade os processos e controles padronizados do PCI DSS usados para determinar o tamanho da amostra e Explicar como a amostra adequada e representativa da populao geral. Os avaliadores devem revalidar o argumento da amostragem para cada avaliao. Se a amostragem for utilizada, diferentes amostras de reas de negcios e componentes do sistema devem ser selecionadas para cada avaliao. Consulte tambm: Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema.
Controles de compensao
Anualmente, quaisquer controles de compensao devem ser registrados, analisados e validados pelo avaliador e includos no envio do Relatrio sobre conformidade, de acordo com o Apndice B: Controles de compensao e Apndice C: Planilha dos controles de compensao. Para cada um dos controles de compensao, a Planilha dos controles de compensao (Apndice C) deve ser preenchida. Alm disso, os resultados dos controles de compensao devem ser registrados no ROC na seo de requisitos do PCI DSS correspondente. Para obter mais detalhes sobre "controles de compensao", consulte os Apndices B e C mencionados acima.
Instrues e contedo para o relatrio sobre conformidade

Este documento deve ser usado como o modelo para a criao do Relatrio sobre conformidade. A entidade avaliada deve seguir os requisitos de informe respectivos de cada bandeira de pagamento para assegurar que cada bandeira de pagamento reconhea o status de conformidade da entidade. Entre em contato com cada bandeira de pagamento para definir os requisitos e instrues de informe.
Contedo e formato do relatrio

Siga estas instrues referentes ao contedo e ao formato do relatrio ao preencher um Relatrio sobre conformidade: 1. Resumo executivo Inclui o seguinte: Descreve o ramo do carto de pagamento da entidade, incluindo: Sua funo comercial nos cartes de pagamento, que como e por que eles armazenam, processam e/ou transmitem dados do titular do carto Observao: Esse documento no visa ser uma cpia do site da entidade, mas deve ser uma descrio personalizada que demonstra que o avaliador compreende o pagamento e a funo da entidade. Como eles processam o pagamento (diretamente, indiretamente, etc.) A quais tipos de canais de pagamento eles atendem, como carto no presente (por exemplo, pedido por e-mail-pedido por telefone (MOTO), e-commerce) ou carto presente Quaisquer entidades s quais eles estajm vinculados para a transmisso ou o processamento do pagamento, incluindo relacionamentos com o responsvel pelo processamento Conexes dentro e fora da rede Componentes crticos no ambiente de dados do titular do carto, incluindo dispositivos POS, sistemas, bancos de dados e servidores da Web, conforme aplicvel. Outros componentes de pagamento necessrios, conforme aplicvel.
Um diagrama de rede de alto nvel (obtido junto entidade ou criado pelo avaliador) da topografia da rede da entidade que inclui: -
2. Descrio do escopo de trabalho e abordagem adotada Descreva o escopo, de acordo com a seo Escopo da avaliao desse documento, incluindo o seguinte: Registre como o avaliador validou a preciso do escopo do PCI DSS para a avaliao, incluindo: Os mtodos ou processos usados para identificar e registrar todas as presenas de dados do titular do carto Como os resultados foram avaliados e registrados Como a efetividade e a preciso dos mtodos usados foram verificadas Se o avaliador valida que o escopo da avaliao esteja preciso e adequado.
Ambiente no qual a avaliao se concentrou (por exemplo, pontos de acesso de Internet do cliente, rede corporativa interna, conexes de processamento) Se houver segmentao de rede implantada e ela tiver sido usada para reduzir o escopo da anlise do PCI DSS, explique brevemente essa segmentao e como o avaliador validou sua efetividade. Se tiver sido usada amostragem durante a avaliao, para cada conjunto de amostras selecionado (de reas de negcios/componentes de sistema) registre o seguinte: Total da populao Nmero exemplificado Argumento para o exemplo selecionado Descrio da segurana, dos processos e controles operacionais padronizados do PCI DSS usados para determinar o tamanho da amostra e como os processos/controles foram validados Como a amostra adequada e representativa da populao geral Descrio de quaisquer locais ou ambientes que armazenam, processam ou transmitem dados do titular do carto que foram EXCLUDOS do escopo da anlise e por que esses locais/ambientes foram excludos
Relacione quaisquer entidades de propriedade integral que exijam a conformidade com o PCI DSS e se elas foram analisadas separadamente ou como parte dessa avaliao Relacione quaisquer entidades internacionais que exijam a conformidade com o PCI DSS e se elas foram analisadas separadamente ou como parte dessa avaliao Relacione quaisquer LANs sem fio e/ou aplicativos de pagamento sem fio (por exemplo, terminais POS) que estejam vinculados ou que poderiam causar um impacto na segurana do ambiente de dados do titular do carto e descreva a segurana implementada nesses ambientes sem fio A verso do documento Requisitos do PCI DSS e procedimentos da avaliao de segurana usada para realizar a avaliao
3. Detalhes sobre o Ambiente Analisado Inclua os detalhes a seguir nesta seo: Um diagrama de cada link de comunicao, incluindo LAN, WAN ou Internet A descrio do ambiente de dados do titular do carto, por exemplo: A transmisso e o processamento do documento dos dados do titular do carto, incluindo autorizao, captura, pagamento, cobrana retroativa e outros fluxos, conforme aplicvel A lista dos arquivos e tabelas que armazenam os dados do titular do carto, compatvel com um inventrio criado (ou obtido junto ao cliente) e mantido pelo avaliador no documento. Esse inventrio deve incluir, para cada armazenamento de dados do titular do carto (arquivo, tabela, etc.): A lista de todos os elementos dos dados de titular do carto armazenados Como o armazenamento de dados protegido Como o acesso aos armazenamentos de dados registrado
A lista de hardwares e softwares crticos utilizados no ambiente de dados do titular do carto, junto com a descrio da funo/uso de cada um deles A lista dos prestadores de servios e outras entidades com as quais a empresa compartilha os dados do titular do carto Observao: Essas entidades esto sujeitas ao Requisito 12.8 do PCI DSS) A lista dos produtos dos aplicativos de pagamento de terceiros e nmeros das verses utilizadas, incluindo se cada aplicativo de pagamento foi validado de acordo com PA-DSS. Mesmo se um aplicativo de pagamento tiver sido validado por PA-DSS, o avaliador precisar verificar se o aplicativo foi implementado em conformidade com o PCI DSS e no ambiente respectivo, e de acordo com o Guia de implementao de PA-DSS do fornecedor do aplicativo de pagamento. Observao: A utilizao de aplicativos validados por PA-DSS no um requisito do PCI DSS. Consulte cada bandeira de pagamento individualmente para compreender seus requisitos de conformidade com PA-DSS. Lista de indivduos entrevistados, suas organizaes, ttulos e tpicos tratados A lista da documentao revisada. Para anlises do prestador de servios gerenciado (MSP), o avaliador deve identificar com clareza quais requisitos nesse documento se aplicam ao MSP (e esto includos na anlise) e quais no esto includos na anlise e cuja incluso em suas anlises de responsabilidade dos clientes do MSP. Inclua informaes sobre quais endereos IP do MSP so detectados como parte integrante das varreduras de vulnerabilidades trimestrais do MSP e quais endereos IP so de responsabilidade dos clientes do MSP incluir em suas prprias varreduras trimestrais.
4. Informaes de contato e data do relatrio Inclui: As informaes de contato do comerciante ou prestador de servios e avaliador Programao de avaliaoespecifique a durao e o perodo de tempo em que a avaliao ocorreu A data do relatrio 5. Resultados das varreduras trimestrais Resuma os resultados das quatro varreduras trimestrais mais recentes da ASV no Resumo executivo, assim como nos comentrios no Requisito 11.2.2. Observao: No exigido que quatro varreduras trimestrais sejam preenchidas para conformidade com o PCI DSS caso o avaliador verifique que: 1) O resultado mais recente de varredura foi uma varredura de passagem, 2) A entidade documentou polticas e procedimentos exigindo o prosseguimento da varredura trimestral e 3) Quaisquer vulnerabilidades observadas na varredura inicial foi corrigida conforme mostrado em nova varredura. Nos anos seguintes aps a anlise inicial do PCI DSS, quatro varreduras trimestrais aprovadas devem ter ocorrido. A varredura deve abranger todos os endereos IP (na Internet) acessveis externamente existentes na entidade, de acordo com os Procedimentos de varredura de segurana do PCI. 6. Descobertas e observaes No Resumo executivo, sintetize quaisquer descobertas que talvez no se encaixem no formato do modelo do Relatrio sobre conformidade padro. Todos os avaliadores devem: Usar o modelo Requisitos detalhados do PCI DSS e procedimentos de avaliao de segurana para fornecer descries e descobertas detalhadas no relatrio sobre cada requisito, principal e secundrio. Assegurar que todas as respostas N/A sejam explicadas claramente. Analisar e registrar quaisquer controles de compensao considerados para concluir que um controle esteja implementado. Para obter mais detalhes sobre "controles de compensao", consulte a seo Controles de compensao acima e os Apndices B e C.
Revalidao dos itens em aberto

Um relatrio sobre controles implementados exigido para verificar a conformidade. O relatrio ser considerado como no conforme se contiver "itens em aberto" ou itens que sero concludos em uma data futura. O comerciante/prestador de servios deve atentar para esses itens antes de concluir a validao. Depois que os itens receberem ateno do comerciante/prestador de servios, o avaliador far uma reavaliao para validar se a soluo foi providenciada e todos os requisitos foram atendidos. Aps a revalidao, o avaliador emitir um novo Relatrio sobre conformidade, atestando que o ambiente de dados do titular do carto est em total conformidade e ir envi-lo de forma consistente de acordo com as instrues (veja abaixo). Requisitos do PCI DSS e Procedimentos da Avaliao da Segurana, verso 2.0 Copyright 2010 Conselho de Padres de Segurana LLC do PCI Outubro de 2010 Pgina 18
Conformidade do PCI DSS Etapas de concluso

1. Conclua o Relatrio de conformidade (ROC) de acordo com a seo acima intitulada "Instrues e contedo para o Relatrio sobre conformidade". 2. Certifique-se de que a(s) varredura(s) de vulnerabilidades aprovada(s) tenha(m) sido concluda(s) por um Fornecedor de varredura aprovado (ASV) do PCI SSC e obtenha uma comprovao da(s) varredura(s) aprovada(s) junto ao ASV. 3. Preencha por completo o Atestado de conformidade referente aos Prestadores de servios ou Comerciantes, conforme aplicvel. Os Atestados de conformidade esto disponveis no site do PCI SSC (www.pcisecuritystandards.org). 4. Envie o ROC, 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).
Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana

Para saber mais sobre os Requisitos do PCI DSS e procedimentos da avaliao de segurana, as informaes a seguir definem os cabealhos das colunas da tabela: Requisitos do PCI DSS Esta coluna define o Padro de Segurana dos Dados e lista os requisitos para atingir a conformidade do PCI DSS; a conformidade ser validada de acordo com esses requisitos. Procedimentos de teste Esta coluna exibe os processos a serem seguidos pelo avaliador para validar se os requisitos do PCI DSS esto "em vigor" Implementados - Esta coluna deve ser usada pelo avaliador para fornecer uma breve descrio dos controles que foram validados como "implementados" para cada requisito, incluindo descries de controles encontrados em implementao como resultado de controles compensatrios ou como resultado de um requisito sento "No aplicvel". Observao: Esta coluna no deve ser usada para itens que ainda no estejam implementados ou para itens em aberto a serem concludos em uma data futura.
No implementados Esta coluna deve ser usada pelo avaliador para fornecer uma descrio resumida dos controles que no esto implementados. Um relatrio de no conformidade no deve ser enviado a uma bandeira de pagamento ou adquirente a menos que seja solicitado de forma especfica. Para obter mais instrues sobre os relatrios de no conformidade, consulte os Atestados de conformidade, disponveis no site do PCI SSC (www.pcisecuritystandards.org). Data prevista/Comentrios Para os controles "No implementados", o avaliador pode incluir uma data prevista na qual o comerciante ou o prestador de servios espera que os controles estejam "Implementados".Quaisquer observaes ou comentrios adicionais tambm podem ser includos aqui.
Construa e mantenha uma rede segura

Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do titular do carto
Firewalls so dispositivos do computador que controlam o trfego do computador permitido entre a rede de uma empresa (interna) e redes no confiveis (externa), assim como o trfego dentro e fora de muitas reas confidenciais na rede confivel interna de uma empresa. O ambiente de dados do portador do carto um exemplo de uma rea mais sensvel dentro da rede confivel de uma empresa. Um firewall examina todo o trfego da rede e bloqueia aquelas transmisses que no atendem aos critrios de segurana especficos. Todos os sistemas devem ser protegidos do acesso no autorizado de redes no confiveis, seja acessando o sistema por meio da Internet como e-commerce, acesso Internet atravs dos navegadores na rea de trabalho por parte dos funcionrios, acesso via e-mail dos funcionrios, conexo dedicada como conexes entre negcios, por meio de redes sem fio ou de outras fontes. Com frequncia, trajetos aparentemente insignificantes que direcionam ou partem de redes no confiveis podem fornecer caminhos no protegidos aos sistemas principais. Os firewalls so um mecanismo de proteo essencial para qualquer rede de computador. Outros componentes do sistema podem oferecer a funcionalidade de filirena, contanto que atendam aos requisitos mnimos para firewalls, conforme o Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do titular do carto para oferecer a funcionalidade do firewall, esses dispositivos devero ser includos no escopo e na avaliao do Requisito 1.
Requisitos do PCI DSS

1.1 Definir os padres de configurao do firewall e do roteador que incluam o seguinte: 1.1.1 Um processo formal para aprovar e testar todas as conexes de rede e alteraes s configuraes do firewall e do roteador 1.1.2 Diagrama da rede atual com todas as conexes com relao aos dados do portador do carto, incluindo quaisquer redes sem fio
Procedimentos de teste
1.1 Obtenha e inspecione os padres de configurao do firewall e do roteador, alm de outras documentaes especificadas abaixo para verificar se os padres esto concludos. Conclua o seguinte: 1.1.1 Verifique se h um processo formal para testar e aprovar todas as conexes de rede e as alteraes s configuraes do firewall e do roteador. 1.1.2.a Verifique h um diagrama da rede atual (por exemplo, um que mostre os fluxos de dados do portador do carto na rede) e se ele registra todas as conexes com relao aos dados do portador do carto, incluindo quaisquer redes sem fio. 1.1.2.b Verifique se o diagrama mantido atualizado.
Implement ado
No implement ado
Data prevista/ Comentrios
1.1.3 Requisitos para um firewall em cada conexo da Internet e entre qualquer zona desmilitarizada (DMZ) e a zona da rede interna
1.1.3.a Verifique se os padres de configurao do firewall incluem requisitos para um firewall em cada conexo da Internet entre qualquer DMZ e a zona da rede interna. 1.1.3.b Verifique se o diagrama da rede atual est de acordo com os padres de configurao do firewall.

1.1.4Descrio de grupos, funes e responsabilidades quanto ao gerenciamento lgico dos componentes da rede 1.1.5 Documentao e justificativa comercial para o uso de todos os servios, protocolos e portas permitidas, incluindo a documentao dos recursos de segurana implementados para os protocolos considerados inseguros. Exemplos de servios, protocolos ou portas inseguros incluem mas no so limitados a FTP, Telnet, POP3, IMAP e SNMP. 1.1.6 Requisito para analisar os conjuntos de regras do firewall e do roteador pelo menos a cada seis meses
1.1.4Verifique se os padres de configurao do firewall e do roteador incluem uma descrio dos grupos, funes e responsabilidades quanto ao gerenciamento lgico dos componentes da rede. 1.1.5.a Verifique se 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). 1.1.5.b Identifique servios, protocolos e portas permitidas inseguras; e comprove se so necessrios e se os recursos de segurana esto documentados e implementados examinando os padres de configurao do firewall e do roteador, alm das configuraes para cada servio. 1.1.6.a Verifique se os padres de configurao do firewall e do roteador exigem a anlise dos conjuntos de regras pelo menos a cada seis meses. 1.1.6.b Obtenha e examine a documentao para verificar se os conjuntos de regras so analisados pelo menos a cada seis meses. 1.2 Examine as configuraes do firewall e do roteador para verificar se as conexes esto restritas entre as redes no confiveis e os componentes de sistema no ambiente de dados do portador do carto, conforme se segue:
Implement ado
No implement ado
1.2 Elaborar uma configurao de firewall e do roteador que restrinja as conexes entre redes no confiveis e quaisquer componentes do sistema no ambiente de dados do portador do carto. Observao: Uma rede no confivel qualquer rede que seja externa s redes que pertencem entidade em anlise e/ou que esteja alm da capacidade da entidade de controlar ou gerenciar. 1.2.1 Restringir o trfego de entrada e sada para aquele que necessrio para o ambiente de dados do portador do carto.
1.2.1.a Verifique se o trfego de entrada e sada est limitado para aquele que necessrio para o ambiente de dados do portador do carto e se as restries esto documentadas. 1.2.1.b Verifique se todos os outros trfegos de entrada e sada so recusados de forma especfica, por exemplo ao usar a opo explcita "recusar todos" ou uma recusa implcita aps a
declarao de permisso.
Implement ado
No implement ado
1.2.2 Proteger e sincronizar os arquivos de configurao do roteador.
1.2.2 Verifique se os arquivos de configurao do roteador esto protegidos e sincronizadospor exemplo, arquivos de configurao de execuo (usados para a execuo normal dos roteadores) e arquivos de configurao de inicializao (usados quando as mquinas so reiniciadas), e se tm as mesmas configuraes seguras. 1.2.3 Verifique se h firewalls de permetro instalados entre quaisquer redes sem fio e sistemas que armazenam dados do portador do carto e se esses firewalls recusam ou controlam (se esse trfego for necessrio para fins comerciais) qualquer trfego a partir do ambiente sem fio no ambiente de dados do portador do carto.
1.2.3 Instalar firewalls de permetro entre quaisquer redes sem fio e o ambiente de dados do portador do carto, e configurar esses firewalls 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 portador do carto. 1.3 Proibir o acesso pblico direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do carto.
1.3 Examine as configuraes do firewall e do roteador - inclusive mas no limitado ao roteador de suspenso na internet, o roteador DMZ e o firewall, o segmento DMZ do titular do carto, o roteador de permetro e o segmento interno da rede do titular do carto para determinar que no haja acesso direto entre a internet e os componentes do sistema, conforme detalhado abaixo. 1.3.1 Verifique se uma DMZ foi implementada para limitar o trfego somente para componentes do sistema que oferece servios, protocolos e portas acessveis publicamente.
1.3.1 Implemente uma DMZ para limitar o trfego somente para componentes do sistema que oferece servios, protocolos e portas acessveis publicamente. 1.3.2 Limitar o trfego de entrada da Internet a endereos IP na DMZ. 1.3.3No permitir a entrada ou sada de nenhuma rota direta com relao ao trfego entre a Internet e o ambiente de dados do titular do carto. 1.3.4 No permitir que endereos internos sejam transmitidos via Internet na DMZ.
1.3.2 Verifique se o trfego de entrada da Internet est limitado a endereos IP na DMZ. 1.3.3Verifique se a entrada ou sada de nenhuma rota direta com relao ao trfego entre a Internet e o ambiente de dados do titular do carto no esto autorizadas. 1.3.4 Verifique se os endereos internos no podem ser transmitidos via Internet na DMZ.

1.3.5No permitir o trfego de sada no autorizado do ambiente de dados do titular do carto para a Internet. 1.3.6 Implementar inspeo com status, tambm conhecida como filtragem de pacote dinmico. (Ou seja, somente conexes "estabelecidas" so permitidas na rede.) 1.3.7 Implementar os componentes do sistema que armazenam dados do titular do carto (como banco de dados) em uma zona da rede interna, separada da DMZ e de outras redes no confiveis. 1.3.8 No divulgar endereos de IP privados e informaes de roteamento a partes no autorizadas. Observao: Mtodos para camuflar o endereo de IP podem incluir, mas no se limitam a: Network Address Translation (NAT) Implementao de 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.
1.3.5 Verifique se o trfego de sada do ambiente de dados do titular do carto para a Internet est explicitamente autorizada 1.3.6 Verifique se o firewall desempenha a inspeo com status (filtragem de pacote dinmico). (Somente conexes estabelecidas devem ser permitidas a entrar e somente se estiverem associadas a alguma sesso previamente estabelecida.) 1.3.7 Verifique se os componentes do sistema que armazenam dados do titular do carto esto em uma zona da rede interna, separada da DMZ e de outras redes no confiveis.
Implement ado
No implement ado
1.3.8.a Verifique se os mtodos esto implementados para evitar a divulgao de endereos de IP privados e informaes de roteamento das redes internas para a Internet.
1.3.8.b Verifique se qualquer divulgao de endereos de IP privados e informaes de roteamento a entidades externas esto autorizadas

1.4Instalar o software de firewall pessoal em quaisquer computadores mveis e/ou de propriedade do funcionrio com conectividade direta Internet (por exemplo, laptops usados pelos funcionrios), que so usados para acessar a rede da empresa.
1.4.aVerifique se os computadores mveis e/ou de propriedade do funcionrio com conectividade direta Internet (por exemplo, laptops usados pelos funcionrios), e que so usados para acessar a rede da empresa tm um software de firewall pessoal instalado e em funcionamento. 1.4.b Verifique se o software do firewall pessoal foi configurado pela empresa de acordo com padres especficos e no pode ser alterado pelos usurios de computadores mveis e/ou de propriedade do funcionrio.
Implement ado
No implement ado
Requisito 2: segurana
No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de
Indivduos mal-intencionados (dentro e fora de uma empresa) com frequncia usam senhas padro do fornecedor e outras configuraes padro do fornecedor para comprometer os sistemas. Essas senhas e configuraes so bastante conhecidas pelas comunidades de hackers e facilmente determinadas por meio de informaes pblicas.
No implement ado Data prevista/ Comentrios

2.1 Sempre alterar os padres disponibilizados pelo fornecedor antes de instalar um sistema na redepor exemplo, incluir senhas, strings de comunidade de SNMP (simple network management protocol) e a eliminao de contas desnecessrias. 2.1.1 Em ambientes sem fio conectados ao ambiente de dados do portador do carto ou que transmitam dados do portador do carto, alterar os padres do fornecedor sem fio, incluindo, mas no se limitando a, chaves de criptografia sem fio padro, senhas e strings de comunidades de SNMP.
2.1 Selecione um exemplo de componentes do sistema e tente efetuar login (com ajuda do administrador do sistema) nos dispositivos que usam contas e senhas padro disponibilizadas pelo fornecedor para verificar se essas contas e senhas padro foram alteradas. (Use os manuais do fornecedor e as fontes na Internet para localizar as contas/senhas disponibilizadas pelo fornecedor.) 2.1.1 Verifique as seguintes definies padro acerca do fornecedor para ambientes sem fio: 2.1.1a Verifique se as chaves de criptografia foram alteradas do padro na instalao e so modificadas a qualquer momento que um funcionrio que conhea as chaves sai da empresa ou troca de cargo 2.1.1.b Verifique se as strings de comunidades de SNMP padro nos dispositivos sem fio foram alteradas. 2.1.1c Verifique se as senhas/passphrases padro nos pontos de acesso foram alteradas. 2.1.1.d Verifique se o firmware nos dispositivos sem fio foi atualizado para ser compatvel com a criptografia robusta para a autenticao e a transmisso em redes sem fio. 2.1.1.e Verifique se outros padres sem fio do fornecedor ligados segurana foram alterados, se aplicvel.
Implement ado
Requisitos do PCI DSS 2.2 Desenvolver padres de configurao para todos os componentes do sistema. Certificar-se de que esses padres abrangem todas as vulnerabilidades de segurana conhecidas e esto em conformidade com os padres de endurecimento do sistema aceitos pelo setor. As fontes dos padres de proteo do sistema aceitos pelo setor podem incluir, mas no se limitam a: Center for Internet Security (CIS) International Organization for Standardization (ISO) Instituto SysAdmin Audit Network Security (SANS) National Institute of Standards and Technology (NIST) 2.2.1Implementar somente uma funo principal por servidor para evitar funes que exigem diferentes nveis de segurana coexistindo no mesmo servidor. (Por exemplo, servidores da Web, servidores do banco de dados e DNS devem ser implementados em servidores separados.) Observao: Onde tecnologias de virtualizao estiverem em uso, implemente somente uma funo principal por componente do sistema virtual.
Procedimentos de teste 2.2.a Examine os padres de configurao do sistema da organizao para todos os tipos de componentes do sistema e verifique se os padres de configurao do sistema so consistentes com os padres de proteo aceitos pelo setor. 2.2.b Verifique se os padres de configurao do sistema esto atualizados conforme novos problemas de vulnerabilidade so identificados, conforme definido no Requisito 6.2. 2.2.c Verifique se os padres de configurao do sistema sero aplicados quando novos sistemas forem configurados. 2.2.d Verifique se os padres de configurao do sistema incluem cada um dos itens abaixo (2.2.1 a 2.2.4).
Implement ado
No implement ado
2.2.1.a Para obter um exemplo dos componentes do sistema, verifique se somente uma funo principal implementada por servidor. 2.2.1.bSe forem usadas tecnologias de virtualizao, verifique se somente uma funo principal est implementada por componente ou dispositivo do sistema virtual.
Requisitos do PCI DSS 2.2.2 Ativar somente servios, protocolos, daemons, etc. necessrios e seguros, conforme exigido para a funo do sistema. Implementar recursos de segurana para quaisquer servios, protocolos ou daemons considerados inseguros - por exemplo, use tecnologias seguras, como SSG, S-FTP, ou IPSec VPN para proteger servios inseguros como o NetBIOS, file-sharing, Telnet, FTP, etc. 2.2.3 Configurar os parmetros de segurana do sistema para impedir o uso incorreto.
Procedimentos de teste 2.2.2.a Para obter uma amostra dos componentes do sistema, inspecione os servios do sistema ativado, daemons e protocolos. Verifique se somente servios e protocolos necessrios esto ativados. 2.2.2.b Identifique qualquer servio, dispositivo, daemon ou protocolo inseguros ativados. Verifique se so justificados e quais recursos de segurana esto registrados e implementados.
Implement ado
No implement ado
2.2.3.a Entreviste os administradores do sistema e/ou os gerentes de segurana para verificar se eles conhecem as configuraes comuns dos parmetros de segurana referentes aos componentes do sistema. 2.2.3.bVerifique se as configuraes comuns dos parmetros de segurana esto includas nos padres de configurao do sistema. 2.2.3.c Para obter um exemplo dos componentes do sistema, verifique se os parmetros comuns de segurana esto definidos de forma adequada.
2.2.4 Remover todas as funcionalidades desnecessrias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores da Web desnecessrios.
2.2.4.a Para obter um exemplo dos componentes do sistema, verifique se todas as funcionalidades desnecessrias (por exemplo, scripts, drivers, recursos, subsistemas, sistemas de arquivo, etc.) foram removidas. 2.2.4.b. Verifique se as funes ativadas esto documentadas e suporte a configurao segura. 2.2.4.c. Verifique se somente as funcionalidades registradas esto presentes nos componentes do sistema da amostra.
Requisitos do PCI DSS 2.3 Criptografar todo o acesso administrativo no console durante a criptografia robusta. Usar tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento baseado na Web e outros acessos administrativos noconsole.
Procedimentos de teste 2.3Para obter um exemplo dos componentes do sistema, verifique se o acesso administrativo no-console criptografado ao: 2.3.a Observe um administrador efetuar login em cada sistema para verificar se o mtodo de criptografia robusto chamado antes da senha do administrador ser solicitada. 2.3.bAnalise os servios e os arquivos de parmetro nos sistemas para determinar se o Telnet e outros comandos de login remoto no esto disponveis para uso interno. 2.3.c Verifique se o acesso do administrador s interfaces de gerenciamento baseadas na Web criptografado com uma criptografia robusta.
Implement ado
No implement ado
2..4Os provedores de hospedagem compartilhada devem proteger cada ambiente hospedado da entidade e os dados do titular do carto. Esses provedores devem atender a requisitos especficos, conforme detalhado no Apndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada.
2.4 Realize os procedimentos de teste de A.1.1 a A.1.4 detalhados no Apndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada para avaliaes do PCI DSS dos provedores de hospedagem compartilhada para verificar se os provedores de hospedagem compartilhada protegem o ambiente hospedado e os dados das suas entidades (comerciantes e prestadores de servios).
Proteger os dados do portador do carto

Requisito 3: Proteger os dados armazenados do titular do carto
Mtodos de proteo como criptografia, truncamento, mascaramento e referenciamento so componentes essenciais da proteo de dados do portador do carto. Se um invasor burlar outros controles de segurana e obtiver acesso aos dados criptografados, sem as chaves criptogrficas adequadas, os dados estaro ilegveis e inutilizveis para aquele indivduo. Outros mtodos eficientes de proteo dos dados armazenados devem ser considerados como oportunidades potenciais de minimizao dos riscos. Por exemplo, os mtodos para minimizar os riscos incluem no armazenar os dados do titular do carto a menos que seja absolutamente necessrio, truncar os dados do portador do carto se um PAN completo no for necessrio e no enviar o PAN em e-mails no criptografados. Consulte a seo Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS para obter definies de "criptografia robusta" e outros termos do PCI DSS.
Implement ado No implement ado Data prevista/ Comentrios

3.1Manter a armazenagem dos dados do titular do carto o mnimo possvel, implementar polticas, processos e procedimentos de reteno e descarte de dados. 3.1.1 Implementar uma poltica de reteno e descarte de dados que inclua: Limite da quantia de dados armazenados e do tempo de reteno ao que exigido pelos requisitos legais, regulatrios e comerciais Processos para excluso segura de dados quando no mais necessrios Requisitos de reteno especficos para dados de titular do carto
3.1 Obtenha e analise as polticas e procedimentos da empresa quanto reteno e ao descarte de dados, e desempenhe o seguinte:
3.1.1.a Verifique se as polticas e os procedimentos incluem requisitos legais, regulatrios e comerciais referentes reteno de dados, incluindo requisitos especficos quanto reteno de dados do portador do carto (por exemplo, os dados do titular do carto precisam ser mantidos por um perodo X por razes comerciais Y). 3.1.1.b Verifique se as polticas e os procedimentos incluem itens referentes ao descarte dos dados quando no forem mais necessrios por razes legais, regulatrias ou comerciais, incluindo o descarte dos dados do titular do carto. 3.1.1.c Verifique se as polticas e procedimentos incluem cobertura para todo o armazenamento de dados do titular do carto.

Processos trimestrais manuais ou automticos para identificar e excluir com segurana os dados do titular do carto que excederem os requisitos de reteno definidos
3.1.1.d Verifique se as polticas 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. 3.1.1.e Verifique se os dados armazenados no excedem os requisitos definidos na poltica de reteno de dados para obter uma amostra dos componentes do sistema que armazenam dados do titular do carto.
Implement ado
No implement ado
3.2 No armazenar dados de autenticao confidenciais aps a autorizao (mesmo se estiverem criptografados). Os dados de autenticao confidenciais incluem os dados conforme mencionados nos seguintes Requisitos 3.2.1 at 3.2.3: Observao: O armazenamento de dados de autenticao confidenciais permitido aos emissores e empresas que suportam servios de emisso se houver justificativa comercial e os dados forem armazenados com segurana.
3.2.a Para os emissores e/ou empresas que suportam servios de emisso e armazenam dados de autenticao confidenciais, verifique se h justificativa comercial para o armazenamento de dados de autenticao confidenciais e se os dados esto seguros. 3.2.b Para todas as outras entidades, se dados de autenticao confidenciais forem recebidos e excludos, obtenha e analise os processos de excluso dos dados para verificar se os dados no podem ser recuperados. 3.2.c Para cada item dos dados de autenticao confidenciais abaixo, desempenhe as seguintes etapas:

3.2.1 No armazenar o contedo completo de qualquer rastro da tarja magntica (localizada na parte posterior do carto, em um chio ou outro local). 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 mantidos: O nome do titular do carto O nmero da conta principal (PAN) Data de vencimento O cdigo de servio Para minimizar o risco, armazene somente os elementos de dados conforme necessrio para os negcios. 3.2.2 No armazenar o cdigo ou valor de verificao do carto (o nmero de trs ou quatro dgitos impresso na frente ou atrs do carto de pagamento) usado para verificar as transaes com carto no presente.
3.2.1 Para obter um exemplo dos componentes do sistema, analise as informaes a seguir e verifique se o contedo completo de qualquer rastro da tarja magntica na parte posterior do carto no armazenado em nenhuma circunstncia: Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastros Vrios esquemas do banco de dados Contedo de bancos de dados
Implement ado
No implement ado
3.2.2Para obter um exemplo dos componentes do sistema, analise as fontes dos dados, inclusive mas no limitado ao que segue e verifique se o cdigo ou o valor de verificao do carto de trs ou quatro dgitos impresso na frente do carto ou no painel de assinatura (dados CVV2, CVC2, CID, CAV2) no armazenado sob nenhuma circunstncia: Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastros Vrios esquemas do banco de dados Contedo de bancos de dados 3.2.3Para obter um exemplo dos componentes do sistema, analise as informaes a seguir e verifique se os PINs e blocos de PIN criptografados no so armazenados sob nenhuma circunstncia:
3.2.3 No armazenar o PIN (personal identification number) ou o bloco de PIN criptografado.
Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastros Vrios esquemas do banco de dados Contedo de banco de dados
Implement ado
No implement ado
3.3 Mascarar o PAN quando exibido (os primeiros seis e quatro ltimos dgitos so o nmero mximo de dgitos a serem exibidos). Observaes: Esse requisito no se aplica aos funcionrios e outras partes interessadas em um negcio legtimo que precisam visualizar o PAN completo. Este 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. 3.4Tornar o PAN ilegvel em qualquer local onde ele esteja armazenado (inclusive em mdia digital porttil, mdia de back-up, em registros) utilizando qualquer uma das seguintes abordagens: Referncias nicas com base na criptografia robusta (o hash deve ser do PAN inteiro) Truncamento (o hashing no pode ser usado para substituir o segmento truncado do PAN) Tokens e blocos de ndice (os blocos devem ser armazenados de forma segura)
3.3 Obtenha e analise as polticas por escrito e examine as exibies do PAN (por exemplo, na tela, em recebimentos no formato de papel) para verificar se os PANs (primary account numbers) esto mascarados ao exibir os dados do titular do carto, exceto para aquelas pessoas que tenham uma necessidade de negcios legtima de visualizar o PAN completo.
3.4.a Obtenha e analise a documentao sobre o sistema usado para proteger o PAN, incluindo o fornecedor, o tipo de sistema/processo e os algoritmos de criptografia (se aplicvel). Verifique se o PAN for tornado ilegvel usando um dos seguintes mtodos: Referncias nicas com base na criptografia robusta Truncamento Tokens e blocos de ndice, sendo que os blocos so armazenados de forma segura Criptografia robusta, com processos e procedimentos de gerenciamento-chave associados 3.4.bAnalise as diversas tabelas ou arquivos de um exemplo de repositrios de dados para verificar se o PAN foi tornado ilegvel (ou seja, no foi armazenado em texto simples).

Criptografia robusta com processos e procedimentos de gerenciamentochave associados Observao: um esforo relativamente simples para um indivduo mal-intencionado reconstituir os dados do PAN original caso 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, os controles adicionais devero estar 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 for utilizada (em vez da criptografia de bancos de dados no nvel de arquivo ou coluna), o acesso lgico deve ser gerenciado independentemente de mecanismos de controle de acesso a sistemas operacionais nativos (por exemplo, no utilizando bancos de dados de contas de usurio locais). As chaves da descrio no devem estar ligadas s contas de usurio.
3.4.cAnalise um exemplo de mdia removvel (por exemplo, fitas de back-up) paa confirmar se o PAN foi tornado ilegvel. 3.4.d Analise um exemplo de registros de auditoria para confirmar se o PAN tornou-se ilegvel ou foi removido dos registros.
Implement ado
No implement ado
3.4.1.a Se a criptografia de disco for usada, verifique se o acesso lgico aos sistemas de arquivos criptografados foi implementado por meio de um mecanismo que seja separado do mecanismo de sistemas operacionais nativos (por exemplo, no usando os bancos de dados das contas de usurio locais). 3.4.1.bVerifique se as chaves criptogrficas so armazenadas de forma segura (por exemplo, armazenadas nas mdias removveis que esto protegidas adequadamente com controles de acesso robustos). 3.4.1.c Verifique se os dados do titular do carto nas mdias removveis esto criptografados onde quer que estejam armazenados. Observao: Se a criptografia no for usada para criptografar a mdia removvel, os dados armazenados nessa mdia devero ser convertidos em legveis por meio de outro mtodo.

3.5 Proteja qualquer chave usada para tornar os dados do titular do carto seguros contra divulgao e mal uso: Observao: Esse requisito tambm se aplica a chaves de criptografia de chaves usadas para proteger as chaves de criptografia de dados - tais chaves de criptografia de chaves devem ser ao menos to robustas quanto as chaves de criptografia de dados. 3.5.1Restringir o acesso s chaves criptogrficas ao menor nmero necessrio de responsveis pela proteo. 3.5.2 Armazenar chaves criptogrficas de forma segura no menor nmero possvel de locais e formatos.
3.5 Verifique os processos para proteger as chaves usadas para a criptografia dos dados do portador do carto contra a divulgao e o uso incorreto ao desempenhar o seguinte:
Implement ado
No implement ado
3.5.1 Analise as listas de acesso dos usurios para verificar se o acesso s chaves est restrito a poucos responsveis pela proteo. 3.5.2.aAnalise os arquivos de configurao do sistema para verificar se as chaves esto armazenadas no formato criptografado e se as chaves de criptografia de chaves esto armazenadas separadamente das chaves de criptografia de dados. 3.5.2.b Identifique os locais de armazenamento para verificar se as chves so armazenadas no menor nmero posvel de locais e formatos.
3.6 Documentar e implementar por completo todos os processos e procedimentos de gerenciamento de chave com relao s chaves criptogrficas usadas para a criptografia dos dados do titular do carto, incluindo o seguinte: Observao: Vrios padres do setor para o gerenciamento de chave esto disponveis a partir de diversos recursos, incluindo NIST, que pode ser encontrado em http://csrc.nist.gov. 3.6.1 Gerao de chaves criptogrficas robustas
3.6.a Verifique a existncia de procedimentos de gerenciamento de chave para as chaves usadas para a criptografia de dados do titular do carto. 3.6.b Somente para os prestadores de servios: Se o prestador de servios compartilhar chaves com seus clientes para a transmisso de dados do titular do carto, verifique se o prestador de servios fornece uma documentao para os clientes que inclua uma orientao sobre como transmitir, armazenar e alterar as chaves do cliente de forma segura, de acordo com os Requisitos 3.6.1 a 3.6.8 abaixo. 3.6.c Analise os procedimentos de gerenciamento de chave e desempenhe o seguinte: 3.6.1 Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir a gerao de chaves robustas.

3.6.2 Distribuio segura da chave criptogrfica 3.6.3 Armazenamento seguro de chaves criptogrficas 3.6.4 Troca de chave criptogrfica para as chaves que chegaram ao final de seu criptoperodo (por exemplo, aps ter passado determinado perodo de tempo e/ ou aps certa quantidade de texto cifrado ter sido produzido por dada chave), conforme definido pelo fornecedor associado do aplicativo ou o dono da chave e com base nas melhores prticas e orientaes do setor (por exemplo, a Publicao Especial NIST 800-57). 3.6.5 Inutilizao ou substituio (por exemplo, arquivamento, destruio e/ ou revogao) de chaves considerada necessria quando a integridade da chave estiver enfraquecida (por exemplo, sada de um funcionrio de uma chave de texto simples) ou houver suspeita de que a chave esteja comprometida. Observao: Se as chaves criptogrficas inutilizadas ou substitudas precisarem ser mantidas, essas chaves devero ser arquivadas com segurana (por exemplo, usando uma chave de criptografia de chaves). Chaves criptogrficas arquivadas devem ser usadas somente para fins de decodificao/verificao.
3.6.2 Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir a distribuio segura de chaves. 3.6.3Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir o armazenamento seguro das chaves. 3.6.4 Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir trocas peridicas de chave ao final do criptoperodo definido.
Implement ado
No implement ado
3.6.5.a Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir a inutilizao de chaves quando a integridade da chave estiver enfraquecida.
3.6.5.b Verifique se os procedimentos do gerenciamento de chaves foram implementados para exigir a substituio de chaves comprometidas conhecidas ou suspeitas.
3.6.5.c Se as chaves inutilizadas ou substitudas forem mantidas, verifique se essas chaves no foram usadas para operaes de criptografia.

3.6.6 Se forem usadas operaes manuais de gerenciamento de chave criptogrfica de texto simples, essas operaes devem ser gerenciadas com o uso de conhecimento separado e de controle duplo (por exemplo, exigindo duas ou trs pessoas, cada uma conhecendo somente o seu componente da chave, para reconstituir a chave completa). Observao: Exemplos de operaes manuais de gerenciamento de chave incluem, mas no so limitados a: gerao de chave, transmisso, carregamento, armazenamento e destruio. 3.6.7 Preveno contra a substituio no autorizada de chaves criptogrficas. 3.6.8 Requisito para que os responsveis pela proteo das chaves criptogrficas assinem um formulrio declarando que eles compreendem e aceitam suas responsabilidades pela proteo das chaves.
3.6.6 Verifique se os procedimentos de gerenciamento de chave de texto simples exigem conhecimento dividido e controle duplo das chaves.
Implement ado
No implement ado
3.6.7Verifique se os procedimentos de gerenciamento de chave foram implementados para exigir a preveno contra a substituio no autorizada das chaves. 3.6.8 Verifique se os procedimentos do gerenciamento de chaves foram implementados para exigir que os responsveis pela proteo garantem (por escrito ou eletronicamente) compreendem e aceitam suas responsabilidades de proteo das chaves.
Requisito 4:
Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas
As informaes confidenciais devem ser criptografadas durante a transmisso nas redes que so facilmente acessadas por indivduos malintencionados. Redes wireless configuradas de forma incorreta e vulnerabilidades na criptografia legada e protocolos de autenticao podem ser alvos contnuos de indivduos mal-intencionados que exploram essas vulnerabilidades para obter acesso privilegiado aos ambientes de dados do portador do carto.

4.1 Uso de protocolos robustos de criptografia e de segurana (por exemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger dados confidenciais do titular do carto durante a transmisso por redes pblicas, abertas. Os exemplos de redes abertas e pblicas que esto no escopo do PCI DSS incluem mas no se limitam a: A Internet Tecnologias sem fio, Global System for Mobile communications (GSM) General Packet Radio Service (GPRS).
4.1 Verifique o uso de protocolos de segurana sempre que dados do titular do carto forem transmitido ou recebido por redes pblicas, abertas. Verifique se a criptografia robusta usada durante a transmisso dos dados, conforme segue: 4.1.a Selecione um exemplo de transaes medida que recebem e observam as transaes conforme elas ocorrem para verificar se os dados do portador do carto esto criptografados durante o trnsito. 4.1.bVerifique se somente chaves e/ ou certificados confiveis so aceitos. 4.1.c Verifique se o protocolo foi implementado para usar configuraes seguras e no suportam verses ou configuraes inseguras. 4.1.d Verifique se a fora da criptografia adequada implementada para a metodologia de criptografia sendo utilizada. (Verifique as recomendaes/melhores prticas do fornecedor.) 4.1.e Para implementaes de SSL/TLS: Verifique se HTTPS exibido como parte do Universal Record Locator (URL) do navegador. Verifique se nenhum dado do portador do carto exigido quando HTTPS no for exibido no URL.
Implement ado

4.1.1 Certificar-se de que as redes wireless estejam transmitindo dados do titular do carto ou estejam conectadas ao ambiente de dados do titular do carto, usar as melhores prticas do setor (por exemplo, IEEE 802.11i) para implementar a criptografia robusta para a autenticao e a transmisso. Observao: O uso de WEP como controle de segurana foi proibido em 30 de junho de 2010. 4.2Nunca enviar PANs no criptografados por tecnologias de envio de mensagens de usurio final (por exemplo, e-mail, sistemas de mensagens instantneas, bate-papo).
4.1.1Para redes sem fio que transmitem dados do titular do carto ou que estejam conectadas ao ambiente de dados do titular do carto, verifique se as melhores prticas (por exemplo, IEEE 802.11i) so usadas para implementar uma criptorafia robusta para a autenticao e a transmisso.
Implement ado
No implement ado
4.2.a Verifique se o PAN foi convertido em ilegvel ou protegido com uma criptografia robusta sempre que for enviado por meio de tecnologias de envio de mensagens de usurio final. 4.2.bVerifique a existncia de uma poltica que afirme 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
Softwares mal-intencionados, normalmente chamados de "malware" incluindo vrus, worms e cavalos de Tria adentram a rede durante muitas atividades de negcios aprovadas, incluindo e-mail dos funcionrios e uso da Internet, computadores mveis e dispositivos de armazenamento, resultando na explorao das vulnerabilidades do sistema. Softwares anti-vrus devem ser usados em todos os sistemas comumente afetados por malwares para proteg-los das ameaas de softwares atuais e em evoluo.
5.1Implementar softwares antivrus em todos os sistemas normalmente afetados por softwares mal-intencionados (especialmente em computadores pessoais e servidores). 5.1.1 Certificar-se de que todos os programas antivrus podem detectar, remover e proteger contra todos os tipos conhecidos de softwares malintencionados. 5.2 Certificar-se de que todos os mecanismos antivrus estejam atualizados, funcionem ativamente e possam gerar registros de auditoria.
5.1Para obter um exemplo dos componentes do sistemas incluindo todos os tipos de sistemas operacionais normalmente afetados por softwares mal-intencionados, verifique se o software antivrus foi implementado se houver uma tecnologia antivrus aplicvel. 5.1.1 Para obter um exemplo dos componentes do sistema, verifique se todos os programas antivrus detectam, removem e protegem contra todos os tipos conhecidos de softwares malintencionados (por exemplo, vrus, cavalos de Troia, worms, spyware, adware e rootkits). 5.2Verifique se todos os softwares antivrus esto atualizados, funcionando ativamente e podem gerar registros ao desempenhar o seguinte: 5.2.a Obtenha e analise a poltica e verifique se ela exige a atualizao dos softwares antivrus e definies. 5.2.b Verifique se a instalao principal do software est ativada para atualizaes automticas e varreduras peridicas. 5.2.c Para obter um exemplo dos componentes do sistema incluindo todos os tipos de sistemas operacionais normalmente afetados pelos softwares mal-intencionados, verifique se as atualizaes automticas e as varreduras peridicas esto ativadas. 5.2.d Para obter um exemplo dos componentes do sistema, verifique se a gerao de registros dos softwares antivrus est ativada e se tais registros so mantidos de acordo com o Requisito 10.7 do PCI DSS
Implement ado
No implement ado
Requisito 6:
Desenvolver e manter sistemas e aplicativos seguros
Indivduos inescrupulosos usam as vulnerabilidades da segurana para obter acesso privilegiado aos sistemas. Muitas dessas vulnerabilidades so solucionadas pelos patches de segurana disponibilizados pelos fornecedores, que devem ser instalados pelas entidades que gerenciam os sistemas. Todos os sistemas crticos devem contar com os patches de software adequados lanados mais recentes para proteger contra a explorao e o comprometimento dos dados do titular do carto por indivduos e softwares mal-intencionados. Observao: Patches de software adequados so aqueles patches que foram avaliados e testados de forma suficiente para determinar se os patches no entram em conflito com as configuraes de segurana existentes. Para aplicativos desenvolvidos internamente, diversas vulnerabilidades podem ser evitadas ao utilizar processos de desenvolvimento do sistema padro e tcnicas de codificao seguras.
6.1 Certificar-se de que todos os componentes do sistema e softwares esto protegidos de vulnerabilidades conhecidas pois tm os patches de segurana mais recentes disponibilizados pelos fornecedores instalados. Instalar patches de segurana crticos em at 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 (por exemplo, dispositivos e sistemas disponibilizados ao pblico, 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.
6.1.a Para obter um exemplo dos componentes do sistema e dos softwares relacionados, compare a lista de patches de segurana instalados em cada sistema com a lista de patches de segurana mais recentes do fornecedor para verificar se os patches atuais do fornecedor foram instalados. 6.1.bAnalise as polticas relacionadas instalao dos patches de segurana para verificar se elas exigem a instalao de todos os patches de segurana crticos novos em um ms.
Implement ado
No implement ado

6.2 Estabelecer um processo para identificar e designar um ranking de risco para as vulnerabilidades de segurana recm-descobertas. Observaes: Os rankings de risco devem ser baseados nas melhores prticas do setor. Por exemplo, os critrios para o ranking de "Alto" risco as vulnerabilidades devem incluir uma pontuao de base CVSS de 4,0 ou mais e/ou um patch oferecido pelo fornecedor classificado por ele como "crtico" e/ou uma vulnerabilidade que afere um componente crtico do sistema. O ranking de vulnerabilidades conforme definido em 6.2.a considerado uma das melhores prticas at 30 de junho de 2012 quando passar a ser um requisito. 6.3 Desenvolver aplicativos de software (internos e externos, incluindo acesso administrativo pela web nos aplicativos) de acordo com o PCI DSS (por exemplo, autenticao e registro seguros) e com base nas melhores prticas do setor. Incorporar segurana de informao ao longo do ciclo de vida do desenvolvimento do software. Esses processos devem incluir o seguinte:
6.2.a Entreviste a equipe responsvel para verificar se os processos foram implementados para identificar novas vulnerabilidades de segurana e se um ranking de riscos foi designado para tais vulnerabilidades. (No mnimo, as vulnerabilidades mais crticas, de maior risco devem ser ranqueadas como "Alto". 6.2.b Verifique se os processos para identificar novas vulnerabilidades de segurana incluem o uso de fontes externas para informaes sobre vulnerabilidade de segurana.
Implement ado
No implement ado
6.3.a Obtena e analise os processos de desenvolvimento do software por escrito para verificar se os processos foram baseados nos padres e/ou nas melhores prticas do setor. 6.3.b Analise os processos de desenvolvimento do software por escrito para verificar se a segurana de informao foi includa durante o ciclo de vida. 6.3.c Analise os processos de desenvolvimento do software por escrito para verificar se os aplicativos de softwareforam desenvolvidos de acordo com o PCI DSS. 6.3.d A partir da anlise de processos de desenvolvimento do software por escrito e de entrevistas com desenvolvedores do software, verifique se:
6.3.1 Remoo de contas, IDs de usurio e senhas do aplicativo antes que ele se torne ativo ou seja lanado aos clientes
6.3.1 As contas dos aplicativos personalizados, IDs e/ou senhas de usurios so removidos antes que o sistema entre em produo ou seja liberado para os clientes.

6.3.2 Analisar o cdigo personalizado antes de liberar para produo ou para os clientes com o objetivo de identificar qualquer vulnerabilidade potencial de codificao. Observao: Esse 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 extras, caso sejam voltados ao pblico, para abranger ameaas e vulnerabilidades contnuas aps a implementao, conforme definido no Requisito 6.6 do PCI DSS. 6.4 Seguir os procedimentos de controle de alteraes para todas as alteraes nos componentes do sistema. Esses processos devem incluir o seguinte: 6.4.1 Ambientes de desenvolvimento/testes e de produo separados. 6.4.2 Separao dos deveres entre os ambientes de desenvolvimento/teste e de produo 6.4.3 Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento 6.4.4 Remoo dos dados de teste e contas antes que os sistemas de produo tornem-se ativos
6.3.2.a Obtenha e analise as polticas para confirmar que todas as alteraes nos cdigos dos aplicativos personalizados referentes aos aplicativos da Web devem ser revisados usando processos manuais ou automatizados), conforme se segue: As alteraes dos cdigos so analisadas por outras pessoas alm do autor que originou o 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 (consulte o Requisito 6.5 do PCI DSS). As correes adequadas so implementadas antes da liberao. Os resultados das anlises dos cdigos so revisados e aprovados pela gerncia antes da liberao. 6.3.2.b Selecione um exemplo de alteraes recentes dos aplicativos personalizados e verifique se o cdigo do aplicativo personalizado analisado de acordo com o item 6.3.2 acima.
Implement ado
No implement ado
6.4 A partir da anlise de processos de controle de alteraes, de entrevistas com administradores da rede e do sistema e da anlise de dados relevantes (documentao da configurao de rede, dados de produo e teste, etc.), verifique o seguinte: 6.4.1 Os ambientes de teste/desenvolvimento so separados do ambiente de produo, com controle de acesso no local para obrigar a separao. 6.4.2 Existe uma separao das tarefas entre a equipe atribuda aos ambientes de desenvolvimento/teste e a atribuda ao ambiente de produo. 6.4.3 Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento. 6.4.4 Os dados e as contas de teste so removidos antes que o sistema de produo torne-se ativo.

6.4.5 Alterar os procedimentos de controle para implementao de patches de segurana e modificaes de software. Os procedimentos devem incluir o seguinte:
6.4.5.a Verifique se os procedimentos de controle de alteraes ligados implementao de patches de segurana e s modificaes foram documentados e os itens 6.4.5.1 a 6.4.5.4 abaixo. 6.4.5.b Para obter um exemplo dos componentes do sistema e dos patches de segurana/alteraes recentes, monitore essas alteraes com relao documentao de controle de alteraes respectiva. Para cada alterao analisada, desempenhe o seguinte: 6.4.5.1 Verifique se a documentao de impacto est includa na documentao de controle de alteraes para cada alterao exemplificada. 6.4.5.2 Verifique se a aprovao documentada por partes autorizada est presente para cada alterao exemplificada. 6.4.5.3.a Para cada alterao exemplificada, verifique se o teste de funcionalidade foi realizado para verificar se a alterao no tem impacto adverso sobre a segurana do sistema. 6.4.5.3.b Para alteraes de cdigo personalizado, verifique se toras as atualizaes foram testadas para estarem de acordo com o Requisito 6.5 do PCI DSS antes de serem implantadas na produo. 6.4.5.4 Verifique se os procedimentos de reverso foram preparados para cada alterao exemplificada. 6.5.a Obtenha e analise os processos de desenvolvimento do software. Verifique se os processos requerem treinamento em tcnicas de codificao seguras para desenvolvedores baseados nas melhores prticas e nas diretrizes. 6.5.b Entreviste alguns desenvolvedores e obtenha uma comprovao de que eles esto instrudos sobre as tcnicas de codificao seguras.
Implement ado
No implement ado
6.4.5.1 Documentao de impacto.
6.4.5.2 Aprovao documentada de alterao pelas partes autorizadas. 6.4.5.3 Teste de funcionalidade para verificar se a alterao no tem impacto adverso sobre a segurana do sistema.
6.4.5.4 Procedimentos de reverso. 6.5 Desenvolver aplicativos baseados nas diretrizes de cdigo seguro. Prevenir vulnerabilidades de codificao comuns nos processos de desenvolvimento do software, para incluir o seguinte: 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 (por exemplo o Guia OWASP, SANS CWE Top 25, CERT Secure Coding, etc.), as melhores prticas atuais precisam ser usadas para estes requisitos. 6.5.1 Falhas na injeo, particularmente na injeo SQL. Tambm considere as falhas de injeo OS Command Injection, LDAP e Xpath, assim como outras falhas. 6.5.2 Buffer overflow 6.5.3 Armazenamento criptogrfico seguro 6.5.4 Comunicaes inseguras 6.5.5 Manuseio incorreto de erros 6.5.6 Todas as vulnerabilidades "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. Observao: Os Requisitos 6.5.7 a 6.5.9 abaixo se plicam em aplicativos web e em interfaces de aplicativos (internos ou externos):
6.5.c Verifique se os processos foram implementados para assegurar que os aplicativos da Web no so vulnerveis ao seguinte:
Implement ado
No implement ado
6.5.1 Falhas na injeo, particularmente na injeo SQL. (Valide a entrada para verificar se os dados do usurio no podem modificar o significado dos comandos e das queries, utilizar queries sob parmetros, etc.) 6.5.2 Buffer overflow (Valide os limites do buffer e trunque as strings truncadas.) 6.5.3Armazenamento criptogrfico inseguro (Impea a ocorrncia de falhas criptogrficas.) 6.5.4 Comunicaes inseguras (Criptografe de forma adequada todas as comunicaes autenticadas e confidenciais) 6.5.5 Manuseio incorreto de erros (no passe informaes por meio de mensagens de erro) 6.5.6 Todas as vulnerabilidades "Alto" conforme identificadas pelo Requisito 6.2.

6.5.7 Scripting de site cruzado (XSS) 6.5.8 Controle de acesso inapropriado (como referncias diretas inseguras a objetos, falhas em restringir o acesso a URLs e diretrios transversais) 6.5.9 Falsificao de solicitaes de site cruzado (CSRF). 6.6 Para aplicativos da Web voltados ao pblico, abordar novas ameaas e vulnerabilidades continuamente e assegurar que esses aplicativos estejam protegidos contra ataques conhecidos por qualquer um dos mtodos a seguir: Analisar os aplicativos da Web voltados ao pblico por meio de ferramentas ou mtodos manuais ou automticos de avaliao de segurana das vulnerabilidades dos aplicativos, pelo menos anualmente e aps quaisquer alteraes Instalar um firewall para aplicativos da Web diante de aplicativos da Web voltados ao pblico
6.5.7Scripting de site cruzado (XSS) (valide todos os parmetros antes da incluso, utilize a sada de contexto confidencial, etc.) 6.5.8 Controle de acesso inapropriado, como referncias diretas inseguras a objetos, falhas em restringir o acesso a URLs e diretrios transversais No exponha referncias de objetos internos aos usurios. 6.5.9 Falsificao de solicitaes de site cruzado (CSRF). (No responda a credenciais de autorizao e tokens enviados automaticamente pelos navegadores.) 6.6Para aplicativos da Web voltados ao pblico, certifique-se de que qualquer um dos mtodos a seguir esteja implementado conforme se segue: Verifique se os aplicativos da Web voltados ao pblico foram analisados (usando ferramentas ou mtodos manuais ou automatizados de avaliao de segurana das vulnerabilidades), conforme se segue: - Pelo menos anualmente - Aps quaisquer alteraes - Por meio de uma empresa especializada na segurana de aplicativos - Se todas as vulnerabilidades forem corrigidas - Se o aplicativo for reavaliado aps as correes Verifique se um firewall de aplicativos da Web est implementado diante dos aplicativos da Web voltados ao pblico para detectar e impedir ataques baseados na Web. Observao: "Uma empresa especializada na segurana de aplicativos" pode ser tanto uma empresa terceirizada quanto uma organizao interna, desde que os analistas se especializem em segurana de aplicativo e possam demonstrar independncia de uma equipe de desenvolvimento.
Implement ado
No implement ado
Implementar medidas de controle de acesso rigorosas

Requisito 7: negcio Restringir o acesso aos dados do titular do carto de acordo com a necessidade de conhecimento para o
Para assegurar que os dados crticos possam ser acessados somente por uma equipe autorizada, os sistemas e processos devem estar implementados para limitar o acesso com base na necessidade de divulgao e de acordo com as responsabilidades da funo. A necessidade de divulgao quando os direitos de acesso so concedidos somente ao menor nmero possvel de dados e privilgios necessrios para realizar um trabalho.

7.1 Limitar o acesso aos componentes do sistema e aos dados do portador do carto somente quelas pessoas cuja funo requer tal acesso. As limitaes de acesso devem incluir o seguinte: 7.1.1 Restrio dos direitos de acesso a IDs de usurios privilegiados ao menor nmero de privilgios necessrios para desempenhar as responsabilidades da funo 7.1.2 A concesso dos privilgios est baseada na classificao e na atribuio da funo da equipe individual 7.1.3 Requisito para aprovao por partes autorizadas documentada especificando os privilgios exigidos. 7.1.4 Implementao de um sistema de controle de acesso automtico
7.1 Obtenha e analise a poltica escrita para o controle de dados e verifique se a poltica incorpora o seguinte:
7.1.1 Confirme se os direitos de acesso a IDs de usurios privilegiados esto restritos ao menor nmero de privilgios necessrios para desempenhar as responsabilidades da funo.
7.1.2 Confirme se os privilgios so concedidos s pessoas com base na classificao e na atribuio da funo (tambm chamada de "controle de acesso baseado na funo" ou RBAC). 7.1.3 Confirme se a aprovao por partes autorizadas documentada necessria (por escrito ou eletronicamente) para todos os acessos e se ela deve especificar os privilgios necessrios. 7.1.4 Confirme se os controles de acesso foram implementados por meio de um sistema de controle de acesso automtico.

7.2 Estabelea um sistema de controle de acesso para os componentes do sistema com mltiplos usurios que restringe o acesso com base na necessidade de conhecimento do usurio e est configurado para "recusar todos", a menos que seja permitido de forma especfica. Esse sistema de controle de acesso deve incluir o seguinte: 7.2.1 Abrangncia de todos os componentes do sistema 7.2.2 A concesso dos privilgios s pessoas est baseada na classificao e na atribuio da funo 7.2.3 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.2Analise as configuraes do sistema e a documentao do fornecedor para verificar se um sistema de controle de acesso foi implementado, conforme se segue:
Implement ado
No implement ado
7.2.1 Confirme se os sistemas de controle de acesso foram implementados em todos os componentes do sistema. 7.2.2 Confirme se os sistemas de controle de acesso esto configurados para impor os privilgios concedidos s pessoas com base na classificao e na atribuio da funo. 7.2.3Confirme se os sistemas de controle de acesso tm uma configurao padro recusar todos.
Requisito 8:
Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador
Atribuir uma identificao exclusiva (ID) a cada pessoa com acesso assegura que cada indivduo seja exclusivamente responsvel pelas suas aes. Quando tal responsabilidade estiver em vigor, as aes desempenhadas nos dados e sistemas crticos sero realizadas por usurios conhecidos e autorizados, e podero levar a eles. Observao: Esses requisitos so aplicveis a todas as contas, inclusive contas de pontos de venda com capacidades administrativas e todas as contas usadas para visualizar ou acessar os dados do titular do carto ou acessar sistemas com dados do titular do carto. No entanto, os Requisitos 8.1, 8.2 e 8.5.8 a 8.5.15 no tm por objetivo serem aplicados a contas de usurio em um aplicativo de pagamento de um ponto de venda que possua acesso somente a um nmero de carto por vez para facilitar a transao nica (como contas de caixa).

8.1Atribuir a todos os usurios um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do carto. 8.2Alm 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 uma passphrase Algo que voc tem, como um dispositivo de token ou um smart card Algo que voc , como a biomtrica
8.1Verifique se todos os usurios receberam um ID exclusivo para acessar os componentes do sistema ou os dados do titular do carto. 8.2Para verificar se os usurios so autenticados usando o ID exclusivo e a autenticao adicional (por exemplo, uma senha) para acessar o ambiente de dados do portador do carto, desempenhe o seguinte: Obtenha e analise a documentao que descreve o(s) mtodo(s) de autenticao usado(s). Para cada tipo do mtodo de autenticao usado e para cada tipo do componente de sistema, observe uma autenticao para verificar se autenticao est sendo executada de acordo com o(s) mtodo(s) de autenticao documentado(s).
Implement ado

8.3Incorporar a autenticao por dois fatores para o 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 por dois fatores.) Observao: A autenticao de dois fatores exige que dois dos trs mtodos de autenticao (consulte o Requisito 8.2 para obter descries dos mtodos de autenticao) sejam usados para autenticao. Usar um fator duas vezes (por exemplo, duas senhas separadas) no considerado uma autenticao por dois fatores. 8.4 Converta todas as senhas em ilegveis durante a transmisso e armazenamento em todos os componentes do sistema usando criptografia robusta. 8.5Garantir um controle adequado da autenticao e da senha do usurio para usurios que no sejam clientes e administradores em todos os componentes do sistema, da forma a seguir: 8.5.1Controle o acrscimo, a excluso e a modificao dos IDs do usurio, credenciais e outros objetos do responsvel pela identificao.
8.3 Para verificar se a autenticao por dois fatores foi implementada para todo o acesso rede remota, observe um funcionrio (por exemplo, um administrador) conectar-se remotamente rede e verifique se dois dos trs mtodos de autenticao so usados.
Implement ado
No implement ado
8.4.aPara obter um exemplo dos componentes do sistema, analise os arquivos de senha para verificar se as senhas esto ilegveis durante a transmisso e o armazenamento. 8.4.bSomente para prestadores de servios, observe os arquivos de senha para verificar se as senhas do cliente esto criptografadas. 8.5Analise os procedimentos e entreviste as equipes para verificar se os procedimentos foram implementados visando ao gerenciamento da autenticao e da senha, desempenhando o seguinte:
8.5.1 Selecione um exemplo de IDs do usurio, incluindo administradores e usurios gerais. Verifique se cada usurio tem autorizao para usar o sistema de acordo com a poltica da empresa ao desempenhar o seguinte: Obtenha e analise um formulrio de autorizao para cada
ID. Verifique se os IDs do usurio exemplificados foram implementados de acordo com o formulrio de autorizao (incluindo os privilgios conforme especificado e todas as assinaturas obtidas) ao rastrear as informaes do formulrio de autorizao ao sistema.
Implement ado
No implement ado
8.5.2Verificar a identidade do usurio antes de realizar as redefinies de senha.
8.5.2Analise os procedimentos de senha e observe a equipe de segurana para verificar se, caso um usurio solicite uma redefinio de senha por telefone, e-mail, Web ou outro mtodo remoto, a identidade do usurio ser comprovada antes da redefinio da senha. 8.5.3 Analise os procedimentos de senha e observe a equipe de segurana para verificar se as senhas iniciais para usurios novos so definidas para um valor exclusivo para cada usurio e alteradas aps a primeira utilizao. 8.5.4 Selecione uma amostra de funcionrios desligados da empresa nos ltimos seis meses e analise as listas de acesso dos usurios atuais para verificar se seus IDs foram desativados ou removidos. 8.5.5 Verifique se as contas inativas nos ltimos 90 dias foram removidas ou desativadas. 8.5.6.a Verifique se quaisquer contas usadas pelos fornecedores para suportar e manter os componentes do sistema foram desativadas e ativadas pelo fornecedor somente quando necessrio. 8.5.6.b Verifique se as contas de acesso remoto do fornecedor so monitoradas quando esto em uso. 8.5.7 Entreviste os usurios de um exemplo de IDs do usurio para verificar se eles esto familiarizados com os procedimentos e polticas de senha. 8.5.8.aPara obter um exemplo dos componentes do sistema, analise as listas de ID do usurio para verificar o seguinte: IDs e contas genricas de usurios foram desativadas ou removidas
8.5.3 Definir as senhas iniciais para um valor exclusivo para cada usurio e alterar imediatamente aps a primeira utilizao. 8.5.4 Revogar imediatamente o acesso de quaisquer usurios desligados da empresa. 8.5.5 Remover/desativar as contas dos usurios inativos pelo menos a cada 90 dias. 8.5.6 Ativar as contas usadas pelos fornecedores somente para a manuteno remota durante o perodo necessrio. Monitorar as contas de acesso remoto do fornecedor quando estiver em uso. 8.5.7 Comunicar os processos e polticas de autenticao a todos os usurios que possuem acesso aos dados do titular do carto. 8.5.8 No use contas, senhas ou outros mtodos de autenticao de grupo, compartilhados ou genricos .
IDs de usurios compartilhados para atividades de administrao do sistema e outras funes crticas ausentes IDs de usurios compartilhados e genricos no so usados para administrar quaisquer componentes do sistema 8.5.8.b Analise as polticas/procedimentos de autenticao para verificar se senhas ou outros mtodos de autenticao de grupo e compartilhados so explicitamente proibidos. 8.5.8.cEntreviste os administradores do sistema para verificar se senhas em grupo ou compartilhadas no so distribudas, mesmo se forem solicitadas.
Implement ado
No implement ado
8.5.9 Alterar as senhas do usurio pelo menos a cada 90 dias.
8.5.9.a Para obter uma amostra dos componentes do sistema, obtenha e analise as definies de configurao do sistema para verificar se os parmetros de senha do usurio esto definidos para exigir que os usurios alterem as senhas pelo menos a cada 90 dias. 8.5.9.bSomente para os prestadores de servios, analise os processos internos e a documentao do cliente/usurio para verificar se as senhas do cliente devem ser alteradas periodicamente e se os clientes recebem instrues sobre quando e sob quais circunstncias as senhas devem ser alteradas.
8.5.10Exigir um comprimento mnimo de senha de pelo menos sete caracteres.
8.5.10.a Para obter um exemplo dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha foram definidos para exigir que as senhas tenham pelo menos sete caracteres de comprimento. 8.5.10.b Somente para prestadores de servios, analise os processos internos e a documentao do cliente/usurio para verificar se as senhas do cliente devem atender aos requisitos de comprimento mnimo.
8.5.11 Usar senhas que contenham caracteres alfanumricos.
8.5.11.a Para obter um exemplo dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha foram definidos para exigir que as senhas contenham caracteres alfanumricos.
8.5.11.b Somente para prestadores de servios, analise os processos internos e a documentao do cliente/usurio para verificar se as senhas do cliente devem conter caracteres alfanumricos.
Implement ado
No implement ado
8.5.12 No permitir que ningum envie uma nova senha que seja a mesma de uma das quatro ltimas senhas que tenha sido usada.
8.5.12.a Para obter um exemplo dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha foram definidos para exigir que as novas senhas no possam ser as mesas das quatro senhas usadas anteriormente. 8.5.12.bSomente para prestadores de servios, analise os processos internos e a documentao do cliente/usurio para verificar se as novas senhas do cliente no podero ser iguais s quatro senhas anteriores.
8.5.13 Limitar tentativas de acesso repetidas ao bloquear o ID do usurio aps seis tentativas, no mximo.
8.5.13.a Para obter um exemplo dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha foram definidos para exigir que a conta de um usurio seja bloqueada aps, seis tentativas invlidas de efetuar login, no mximo. 8.5.13.b Somente para prestadores de servios, analise os processos internos e a documentao do cliente/usurio para verificar se as contas do cliente so bloqueadas temporariamente aps seis tentativas invlidas de acesso, no mximo.
8.5.14Definir a durao do bloqueio para um mnimo de 30 minutos ou at o administrador ativar o ID do usurio.
8.5.14 Para obter um exemplo dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha so definidos para exigir que assim que a conta de um usurio for bloqueada, ela permanecer dessa forma por pelo menos 30 minutos ou at que um administrador do sistema reconfigure a conta. 8.5.15 Para obter um exemplo dos componentes do sistema, obtenha e analise as definies de configurao do sistema para verificar se os recursos de tempo esgotado de ociosidade do sistema/sesso foram definidos para 15 minutos ou menos. 8.5.16.a Analise as definies de configurao do aplicativo e do banco de dados para verificar se todos os usurios so autenticados antes do acesso.
8.5.15 Se uma sesso estiver ociosa por mais de 15 minutos, exigir que o usurio redigite a senha para reativar o terminal. 8.5.16 Autenticar todos os acessos para qualquer banco de dados que contenha dados do portador do carto,

incluindo acesso por meio de aplicativos, administradores e todos os outros usurios. Restringir acesso direto ou as consultas aos bancos de dados aos administradores do banco de dados.
8.5.16.b Verifique se as definies de configurao do aplicativo e do banco de dados asseguram que todos os acessos dos usurios, consultas dos usurios e aes dos usurios (por exemplo, mover, copiar, excluir) nos bancos de dados so por meio apenas de mtodos programticos (por exemplo, atravs dos procedimentos armazenados). 8.5.16.c Verifique se as definies de configurao do aplicativo e do banco de dados restringem aos administradores do banco de dados o acesso direto ou as consultas ao banco de dados. 8.5.16.d Analise os aplicativos do banco de dados e os IDs dos aplicativos relacionados para verificar se os IDs dos aplicativos podem ser usados somente pelos aplicativos (e no apenas por usurios individuais ou outros processos).
Implement ado
No implement ado
Requisito 9:
Restringir o acesso fsico aos dados do titular do carto
Qualquer acesso fsico aos dados ou sistemas que armazenam dados do portador do carto fornecem a oportunidade para as pessoas acessarem dispositivos ou dados e removerem sistemas ou cpias impressas, e deve ser restrito de forma adequada. Para as finalidades do Requisito 9, "funcionrio" refere-se a funcionrios que trabalham em perodo integral e meio-perodo, funcionrios e equipes temporrias, e prestadores de servios e consultores que atuem com presena fsica no endereo da entidade. Um 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. "Mdia" refere-se a todas as mdias em papel ou eletrnicas que contm dados do titular do carto.
9.1Usar controles de entrada facilitados e adequados para limitar e monitorar o acesso fsico aos sistemas no ambiente de dados do titular do carto.
9.1Verifique a existncia dos controles de segurana fsica em cada ambiente com computador, central de dados e outras reas fsicas com sistemas no ambiente de dados do titular do carto. Verifique se o acesso controlado com leitores de credenciais ou outros dispositivos, incluindo credenciais autorizadas e bloqueio e chave. Observe a tentativa de um administrador do sistema de efetuar login em consoles visando aos sistemas selecionados aleatoriamente no ambiente do portador do carto e verifique se eles esto "bloqueados" para impedir o uso no autorizado.
Implement ado
No implement ado
9.1.1 Usar cmeras de vdeo ou outros mecanismos de controle de acesso para monitorar o acesso fsico individual a reas confidenciais. Analisar os dados coletados e relacionar com outras entradas. Armazenar, por pelo menos trs meses, a menos que seja restringido de outra forma pela lei. Observao: 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 nas quais h somente terminais do ponto de venda presentes, como as reas dos caixas em uma loja de varejo.
9.1.1.a Verifique se cmeras de vdeo ou outros mecanismos de controle de acesso foram implantados para monitorar os pontos de entrada/sada das reas confidenciais. 9.1.1.b Verifique se cmeras de vdeo ou outros mecanismos de controle de acesso esto protegidos contra adulterao ou desativao. 9.1.1.c Verifique se cmeras de vdeo ou outros mecanismos de controle de acesso so monitorados e se os dados das cmeras ou outros mecanismos so armazenados por pelo menos trs meses.

9.1.2 Restringir o acesso fsico a pontos de rede acessveis publicamente. Por exemplo, reas acessveis a visitantes no devem ter portas de rede ativadas a no ser que o acesso rede seja autorizado explicitamente. 9.1.3 Restringir o acesso fsico a pontos sem fio de acesso, gateways, dispositivos portteis, hardwares de comunicao/rede e linhas de telecomunicao. 9.2 Desenvolver procedimentos para diferenciar facilmente os funcionrios dos visitantes, principalmente nas reas onde os dados do titular do carto podem ser acessados.
9.1.2 Verifique ao entrevistar os administradores da rede e observar se os pontos de rede so ativados somente quando necessrio pelos funcionrios autorizados. Verifique tambm se os visitantes sempre so acompanhados nas reas com pontos de rede ativos.
Implement ado
No implement ado
9.1.3 Verifique se o acesso fsico a pontos sem fio de acesso, gateways, dispositivos portteis, hardwares de comunicao/rede e linhas de telecomunicao restrito adequadamente.
9.2.a Analise os processos e procedimentos para atribuir crachs aos funcionrios e visitantes, e verifique se esses processos incluem o seguinte: Conceder novos crachs, Modificar os requisitos de acesso e Anular crachs de funcionrios que se desligaram da empresa e de visitantes que encerraram sua atividade. 9.2.b Verifique se o acesso ao sistema de crachs limitado a funcionrios autorizados. 9.2.c Analise os crachs em uso para verificar se identificam claramente os visitantes e se fcil distinguir funcionrios de visitantes.
9.3 Certificar-se de que todos os visitantes so identificados da seguinte forma: 9.3.1 Autorizados antes de adentrar as reas onde os dados do portador do carto so processados ou mantidos. 9.3.2 Recebem um token fsico (por exemplo, um crach ou dispositivo de acesso) que expira e que identifica os visitantes como no sendo funcionrios.
9.3 Verifique se os controles dos funcionrios/visitantes foram implementados da seguinte forma: 9.3.1 Observe o uso dos crachs de ID de visitante para verificar se um crach de ID de visitante no permite acesso desacompanhado a reas fsicas que armazenam dados do titular do carto. 9.3.2.a Observe as pessoas na instalao para verifcar o uso dos crachs de ID de visitante e se os visitantes esto facilmente disntinguveis dos funcinorios. 9.3.2.b Verifique se os crachs de visitante tm validade.

9.3.3 solicitado que os visitantes apresentem o token fsico antes de sair das dependncias ou na data do vencimento.
9.3.3 Observe os visitantes que saem das dependncias para verificar se solicitado que os visitantes apresentem seu crach de identificao na sada ou quando do vencimento.
Implement ado
No implement ado

9.4 Usar um registro de visitantes para manter um monitoramento fsico da auditoria da atividade do visitante. Documente no registro o nome do visitante, a empresa representada e o funcionrio que autoriza o acesso fsico. Armazene esse registro por pelo menos trs meses, a menos que seja restringido de outra forma pela lei. 9.5 Armazene back-ups de mdia em um local seguro, preferencialmente em outras instalaes, como um lugar alternativo de back-up ou uma instalao comercial de armazenamento. Analisar a segurana do local pelo menos uma vez por ano. 9.6 Proteja toda a mdia fisicamente.
9.4.a Verifique se um registro de visitantes est sendo usado para registrar o acesso fsico s dependncias, assim como aos ambientes com computador e centrais de dados onde os dados do portador do carto so armazenados ou transmitidos. Verifique se o registro contm o nome do visitante, a empresa representada e o funcionrio que est autorizando o acesso fsico, e se mantido por pelo menos trs meses.
Implement ado
No implement ado
9.5.a Observe a seguran fsica do local de armazenamento para confirmar que o armazenamento da mdia de back-up est seguro. 9.5.b Verifique se a segurana do local de armazenamento analisada ao menos anualmente.
9.6 Verifique se os procedimentos para proteger os dados do titular do carto incluem controles para proteger fisicamente os todas as mdias (incluindo mas no se limitando a computadores, mdias eletrnicas removveis, recebimentos de documentos impressos, relatrios impressos e faxes). 9.7 Verifique se h uma poltica para controlar a distribuio de mdias que contm dados do portador do carto e se a poltica abrange todas as mdias distribudas, incluindo as distribudas s pessoas. 9.7.1 Verifique se toda mdia foi classificada para que a confidencialidade dos dados possa ser determinada. 9.7.2 Verifique se toda mdia enviada externamente registrada e autorizada pela gerncia e encaminhada via mensageiro seguro ou outro mtodo de entrega que possa ser monitorado. 9.8 Selecione um exemplo recente de vrios dias de registros de monitoramento externo para todas as mdias que contm dados do titular do carto e verifique a presena dos detalhes de monitoramento e da autorizao apropriada da gerncia nos registros.
9.7 Manter o controle rigoroso quanto distribuio interna ou externa de qualquer tipo de mdia, incluindo o seguinte: 9.7.1 Classificar a mdia para que a confidencialidade dos dados possa ser determinada. 9.7.2 Enviar a mdia via mensageiro seguro ou outro mtodo de entrega que pode ser monitorado com preciso. 9.8 Certificar-se de que a gerncia aprova quaisquer e todas as mdias contendo dados do portador do carto que so movidas de uma rea segura (principalmente quando as mdias forem distribudas s pessoas).

9.9 Manter um controle rigoroso sobre o armazenamento e a acessibilidade das mdias que contm dados do titular do carto. 9.9.1 Manter adequadamente os registros do inventrio de todas as mdias e realizar inventrios das mdias pelo menos uma vez por ano. 9.10 Destruir as mdias que contm dados do titular do carto quando eles no forem mais necessrios por motivos de negcios ou legais, conforme se segue: 9.10.1 Triturar, incinerar ou amassar materiais impressos para que os dados do titular do carto no possam ser recuperados.
9.9 Obtenha e analise a poltica para controlar o armazenamento e a manuteno dos documentos impressos e mdias eletrnicas, e verifique se a poltica requer inventrios de mdia peridicos. 9.9.1 Obter e analisar o registro do inventrio das mdias para verificar se inventrios peridicos das mdias so realizados pelo menos uma vez por ano. 9.10 Obtenha e analise a poltica de destruio peridica das mdias e verificar se ela abrange todas as mdias que contm dados do titular do carto e confirme o seguinte:
Implement ado
No implement ado
9.10.1.a Verifique se os materiais impressos so picotados, triturados, incinerados ou amassados para que haja garantia razovel de que no possam ser reconstitudos. 9.10.1.b Analise os contineres de armazenamento usados para as informaes a serem destrudas para verificar se so seguros. Por exemplo, verifique se um continer "a ser triturado" tem uma trava que impede o acesso ao seu contedo. 9.10.2 Verifique se os dados do portador do carto nas mdias eletrnicas so tornados irrecuperveis por meio de um programa de limpeza segura, de acordo com os padres aceitos pelo setor quanto excluso segura, ou de outra forma, destruindo fisicamente as mdias (por exemplo, desmagnetizando).
9.10.2Tornar os dados do titular do carto nas mdias eletrnicas irrecuperveis para que esses dados no possam ser reconstitudos.
Monitorar e Testar as Redes Regularmente

Requisito 10: carto Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do portador do
Mecanismos de registro e a capacidade de monitorar as atividades dos usurios so fundamentais na preveno, deteco ou minimizao do impacto do comprometimento dos dados. A presena de registros em todos os ambientes permite o monitoramento, o alerta e a anlise completa quando algo d errado. Determinar a causa de um comprometimento muito difcil, se no impossvel, sem registros das atividades do sistema.
Implement ado No implementad o Data prevista/ Comentrios

10.1 Definir um processo para vincular todos os acessos aos componentes do sistema (principalmente o acesso realizado com privilgios administrativos como raiz) para cada usurio individual. Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos: 10.2.1 Todos os acessos individuais aos dados do titular do carto 10.2.2 Todas as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos 10.2.3 Acesso a todas as trilhas de auditoria 10.2.4 Tentativas invlidas de acesso lgico 10.2.5 Uso de mecanismos de identificao e autenticao 10.2.6 Inicializao dos registros de auditoria
10.1 Verifique por meio da observao e entreviste o administrador do sistema perguntando se as trilhas de auditoria esto habilitadas e ativadas para os componentes do sistema.
10.2 Por meio de entrevistas, anlise de registros de auditoria e de suas configuraes, desempenhe o seguinte:
10.2.1 Verifique se todos os acessos individuais aos dados do portador do carto esto registrados. 10.2.2 Verifique as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos so registradas. 10.2.3 Verificar se o acesso a todas as trilhas de auditoria registrado. 10.2.4 Verifique se as tentativas invlidas de acesso lgico so registradas. 10.2.5 Verifique se o uso dos mecanismos de identificao e autenticao registrado. 10.2.6 Verificar se a inicializao dos registros de auditoria registrada.

10.2.7 Criao e excluso de objetos do nvel do sistema 10.3 Registrar pelo menos as seguintes entradas das trilhas de auditoria para todos os componentes do sistema para cada evento: 10.3.1 Identificao do usurio
10.2.7 Verificar se a criao e a excluso de objetos do nvel do sistema so registrados. 10.3 Por meio de entrevistas e da observao, para cada evento auditvel (no item 10.2), realize o seguinte:
Implement ado
No implementad o
10.3.1 Verifique se a identificao do usurio est includa nas entradas do registro. 10.3.2Verifique se o tipo do evento est includo nas entradas do registro. 10.3.3Verifique se a data e o horrio esto includos nas entradas do registro. 10.3.4Verifique se a indicao de xito ou falha est includa nas entradas do registro. 10.3.5 Verifique se a origem do evento est includa nas entradas do registro. 10.3.6Verifique se a identidade ou o nome dos dados afetados, os componentes do sistema ou recursos est includo nas entradas do registro. 10.4.a Verifique se a tecnologia de sincronizao de tempo foi implementada e mantida atualizada pelos Requisitos 6.1 e 6.2 do PCI DSS. 10.4.b Obtenha e analise o processo para a aquisio e a distribuio do horrio correto na empresa, assim como as configuraes dos parmetros do sistema relacionadas ao horrio com relao a alguns exemplos dos componentes do sistema. Verifique se as informaes a seguir esto includas no processo e foram implementadas:
10.3.2 Tipo de evento
10.3.3 Data e horrio
10.3.4 Indicao de sucesso ou falha 10.3.5 Origem do evento
10.3.6 A identidade ou o nome dos dados afetados, componentes do sistema ou recurso. 10.4 Usando tecnologia de sincronizao de tempo, sincronize todos os relgios e horrios crticos do sistema e assegure-se de que os seguintes itens sejam implementados para adquirir, distribuir e armazenar horrios. Observao: Um exemplo de tecnologia de sincronizao de tempo o Network Time Protocol (NTP).

10.4.1 Sistemas crticos tm o horrio correto e consistente.
10.4.1.a Verifique se smente os servidores centraris de horrio designados recebem sinais de horrio de fontes externas e se os sinais de horrio de fontes externas so baseadas no Tempo Atmico Internacional ou no UTC. 10.4.1.b Verifique se os servidores centrais de horrio designados esto emparelhados para manter o horrio preciso e se os outros servidores internos recebem o horrio somente dos servidores centrais de horrio.
Implement ado
No implementad o
10.4.2 Os dados de horrio so protegidos.
10.4.2.a Analise as definies de configurao e de sincronizao de horrio para verificar se o acesso aos dados de horrio so restritos a somente os funcionrios com necessidades comerciais de acesso aos dados de horrio. 10.4.2.b Analise as definies e os processos de configurao e de sincronizao de horrio para verificar se qualquer alterao s definies de horrio em sistemas crticos registrada, monitorada e analisada.
10.4.3 As definies de horrio so recebidas de fontes de horrio aceitas pelo setor.
10.4.3 Verifique se os servidores de horrio aceitam atualizaes de fontes externas especficas, aceitas pelo setor (para evitar que um indivduo mal-intencionado altere o relgio). Alm disso, essas atualizaes podem ser criptografas com uma chave simtrica e as listas de controle de acesso podem ser criadas para especificar os endereos IP das mquinas clientes que sero fornecidas com as atualizaes de horrio (para evitar o uso no autorizado de servidores de horrio internos). 10.5 Entreviste o administrador do sistema e analise as permisses para verificar se as trilhas de auditoria esto protegidas de uma forma que no possam ser alteradas da seguinte forma: 10.5.1Verifique se apenas os indivduos que tm uma necessidade relacionada funo podem visualizar arquivos de trilha de auditoria. 10.5.2Verifique se os arquivos de trilha de auditoria atuais esto protegidos de modificaes no autorizadas por meio de mecanismos de controle de acesso, separao fsica e/ou separao da rede.
10.5 Proteger as trilhas de auditoria para que no possam ser alteradas.
10.5.1 Limitar a exibio de trilhas de auditoria s pessoas que tm uma necessidade relacionada funo. 10.5.2 Proteger os arquivos de trilha de auditoria de modificaes no autorizadas.

10.5.3 Fazer imediatamente o back-up dos arquivos de trilha de auditoria em um servidor de registros centralizado ou mdias que sejam difceis de alterar. 10.5.4 Documentar registros quanto s tecnologias externas em um servidor de registros na LAN interna. 10.5.5 Usar softwares de monitoramento da integridade dos arquivos ou de deteco de alteraes nos registros para assegurar que os dados de registro existentes no possam ser alterados sem gerar alertas (embora os novos dados que estejam sendo adicionados no gerem um alerta). 10.6 Analisar os registros de todos os componentes do sistema pelo menos diariamente. As anlises dos registros 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) (por exemplo, RADIUS). Observao: As ferramentas de coleta, anlise e alerta dos registros podem ser usadas para estar em conformidade com o Requisito 10.6. 10.7 Manter um histrico da trilha de auditoria por pelo menos um ano, com um mnimo de trs meses imediatamente disponvel para anlise
10.5.3Verifique se realizado imediatamente o back-up dos arquivos de trilha de auditoria atuais em um servidor de registros centralizado ou mdias que sejam difceis de alterar.
Implement ado
No implementad o
10.5.4Verifique se os registros quanto s tecnologias externas (por exemplo, sem fio, firewalls, DNS, e-mail) so transferidos ou copiados em um servidor de registro interno centralizado ou mdia seguros. 10.5.5 Verifique o uso de softwares de monitoramento da integridade dos arquivos ou de deteco de alteraes nos registros ao analisar as configuraes do sistema e os arquivos e resultados monitorados das atividades de monitoramento.
10.6.a Obtenha e analise as polticas e os procedimentos de segurana para verificar se eles incluem procedimentos para analisar os registros de segurana pelo menos diariamente e se o acompanhamento das excees exigido. 10.6.b Por meio da observao e de entrevistas, verifique se as anlises de registros regulares so realizadas em todos os componentes do sistema.
10.7.aObtenha e analise as polticas e procedimentos de segurana, e verifique se eles incluem polticas de reteno de registros de auditoria e requerem a reteno dos registros de auditoria por pelo menos um ano.

(por exemplo, on-line, arquivado ou recupervel a partir do back-up).
10.7.b Verifique se os registros de auditoria esto disponveis pelo menos referente ao perodo de um ano e se h processos implementados para recuperar pelo menos os registros dos ltimos trs meses para a anlise imediata.
Implement ado
No implementad o
Requisito 11:
Testar regularmente os sistemas e processos de segurana.
As vulnerabilidades esto sendo continuamente descobertas por indivduos mal-intencionados e pesquisadores, e so apresentadas por novos softwares. Os componentes do sistema, processos e softwares personalizados devem ser testados com frequncia para assegurar que os controles de segurana continuem refletindo um ambiente em transformao.

11.1 Teste para a presena de pontos de acesso sem fio e detectar pontos de acesso sem fio no autorizados trimestralmente. Observao: Mtodos que podem ser usados no processo incluem mas no se limitam a varreduras de rede sem fio, inspees de componentes e 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.
11.1.a Verifique trimestralmente se a entidade possui um processo registrado para detectar e identificar pontos de acesso sem fio. 11.1.b Verifique se a metodologia adequada para detectar e identificar qualquer ponto de acesso sem fio no autorizado, incluindo ao menos o seguinte: Cartes WLAN inseridos nos componentes do sistema Dispositivos portteis sem fio conectados aos componentes do sistema (por exemplo por USB, etc.) Dispositivos sem fio anexados a uma porta de rede ou a um dispositivo de rede 11.1.c Verifique se o processo registrado para identificar pontos de acesso sem fio no autorizados realizado ao menos trimestralmente para todos componentes e instalaes do sistema. 11.1.d Se o monitoramento automatizado for utilizado (por exemplo, IDS/IPS sem fio, NAC, etc.), verificar a configurao gerar alertas aos funcionrios. 11.1.e Verifique se o plano de resposta a incidentes da empresa (Requisito 12.9) inclui uma resposta no caso de dispositivos sem fio no autorizados serem detectados.

11.2 Executar varreduras quanto s vulnerabilidades das redes internas e externas pelo menos trimestralmente e aps qualquer mudana significativa na rede (como instalaes de novos componentes do sistema, mudanas na topologia da rede, modificaes das normas do firewall, upgrades de produtos). Observao: No ser necessrio que quatro varreduras trimestrais aprovadas sejam concludas quanto conformidade inicial do PCI DSS se o avaliador verificar que 1) o resultado da varredura mais recente foi uma varredura aprovada, 2) a entidade contar com polticas e procedimentos documentados que requerem a sequncia de 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 Realizar varreduras por vulnerabilidade interna trimestralmente.
11.2 Verifique se as varreduras por vulnerabilidade internas e externas so realizadas como se segue:
Implement ado
No implement ado
11.2.1.a Analise os relatrios de varrefura e verifique se ocorreram quatro varreduras internas trimestrais nos ltimos 12 meses. 11.2.1.b Analise os relatrios de varredura e verifique se o processo de varredura 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.
11.2.1.c Verifique se o teste foi realizado por um recurso interno qualificado ou um terceiro externo qualificado e, caso seja aplicvel, se h uma independncia organizacional do responsvel pelo teste (no necessrio que seja um QSA ou ASV).
Implement ado
No implement ado
11.2.2 As varreduras trimestrais quanto s vulnerabilidades externas devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de Segurana de Dados do Setor de Cartes de Pagamento (PCI SSC). Observao: As varreduras trimestrais quanto s vulnerabilidades externas devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de Segurana de Dados do Setor de Cartes de Pagamento (PCI SSC). As varreduras realizadas aps as alteraes na rede devem ser desempenhadas pela equipe interna da empresa. 11.2.3 Realize varreduras internas e externas aps qualquer mudana significativa. Observao: As varreduras realizadas aps as alteraes devem ser desempenhadas pela equipe interna da empresa.
11.2.2.a Analise o resultado das varreduras quanto s vulnerabilidades externas dos quatro ltimos trimestres e verifique se ocorreram quatro varreduras nos ltimos 12 meses.
11.2.2.b Analise os resultados de cada varretura trimestral para se assegurar de que elas atendem aos requisitos do Guia do Programa ASV (por exemplo, nenhuma vulnerabilidade classificada com mais de 4.0 pelo CVSS e sem falhas automticas). 11.2.2.c Analise os relatrios de varredura para verificar se as varreduras foram concludas por um Fornecedor de vsrredura aprovado (ASV), aprovado pelo PCI SSC.
11.2.3.a Inspecione a documentao do controle de alteraes e realize uma varredura nos relatrios para verificar se os componentes do sistema sujeitos a qualquer alterao significativa passaram por varredura. 11.2.3.b Analise os relatrios de varredura e verifique se o processo inclui novas varreduras at que: Para varreduras externas, no existam varreduras com pontuao maior do que 4,0 pelo CVSS, Para varreduras internas, um resultado aprovado seja obtido ou todas as vulnerabilidades em "Alto" conforme o Requisito 6.2 do PCI DSS sejam solucionadas.
11.2.3.c Verifique se o teste foi realizado por um recurso interno qualificado ou um terceiro externo qualificado e, caso seja aplicvel, se h uma independncia organizacional do responsvel pelo teste (no necessrio que seja um QSA ou ASV).
Implement ado
No implement ado
11.3 Realizar testes de penetrao externos e internos pelo menos uma vez por ano e aps qualquer upgrade ou modificao significativa na infraestrutura ou nos aplicativos (como um upgrade no sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor da Web adicionado ao ambiente). Esses testes de penetrao devem incluir o seguinte:
11.3.a Obtenha e analise os resultados do teste de penetrao mais recente para verificar se os testes de penetrao so realizados pelo menos uma vez por ano e aps quaisquer mudanas significativas no ambiente. 11.3.b Verifique se as vulnerabilidades observadas foram corrigidas e os testes repetidos. 11.3.c Verifique se o teste foi realizado por um recurso interno qualificado ou um terceiro externo qualificado e, caso seja aplicvel, se h uma independncia organizacional do responsvel pelo teste (no necessrio que seja um QSA ou ASV). 11.3.1 Verifique se o teste de penetrao inclui testes de penetrao na camada da rede. Esses testes devem incluir componentes que so compatveis com as funes da rede, assim como com os sistemas operacionais. 11.3.2 Verifique se o teste de invaso inclui testes de invaso na camada de aplicao. Os testes devem incluir, no mnimo, as vulnerabilidades listadas no Requisito 6.5. 11.4.a Verifique o uso de sistemas de deteco de invaso e/ou sistemas de preveno contra invaso e se todo o trfego no ambiente de dados do titular do carto e alertar as equipes sobre comprometimentos suspeitos monitorado. 11.4.b Confirme se o IDS e/ou IPS esto configurados para alertar as equipes sobre comprometimentos suspeitos. 11.4.c Analise as configuraes de IDS/IPS e confirme se os dispositivos de IDS/IPS esto configurados, mantidos e atualizados de acordo com as instrues dos fornecedores para assegurar uma proteo ideal.
11.3.1 Testes de penetrao na camada da rede
11.3.2 Testes de penetrao na camada do aplicativo.
11.4 Usar sistemas de deteco de invaso e/ou sistemas de preveno contra invaso para monitorar todo o trfego no ambiente de dados do titular do carto e alertar as equipes sobre comprometimentos suspeitos. Manter todos os mecanismos de deteco e preveno contra invases, diretrizes e assinaturas atualizados.

11.5 Implementar softwares de monitoramento da integridade dos arquivos para alertar as equipes quanto modificao no autorizada de arquivos crticos do sistema, arquivos de configurao ou arquivos de contedo; e configurar o software para realizar comparaes de arquivos crticos pelo menos semanalmente. 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 para os aplicativos personalizados, devem ser avaliados e definidos pela entidade (ou seja, o comerciante ou prestador de servios).
11.5.a Verifique o uso de produtos de monitoramento de integridade de arquivos no ambiente de dados do portador do carto ao observar as configuraes do sistema e os arquivos monitorados, assim como ao analisar os resultados das atividades de monitoramento. Exemplos de arquivos que devem ser monitorados: Executveis do sistema Executveis dos aplicativos Arquivos de configurao e parmetro Arquivos de registro e auditoria centralmente armazenados, histricos ou arquivados 11.5.bVerifique se as ferramentas esto configuradas para alertar os funcionrios sobre modificaes no autorizadas de arquivos crticos e para realizar comparaes de arquivos crticos ao menos semanalmente.
Implement ado
No implement ado
Manter uma Poltica de Segurana de Informaes

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes.
Uma poltica de segurana slida determina o tom da segurana para toda a empresa e informa aos funcionrios o que esperado deles. Todos os funcionrios devem estar cientes da confidencialidade dos dados e de suas responsabilidades para proteg-los. Para as finalidades do Requisito 12, "funcionrio" 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.
No implement ado

12.1 Definir, publicar, manter e disseminar uma poltica de segurana que realize o seguinte: 12.1.1 Atende a todos os requisitos do PCI DSS. 12.1.2 Inclui um processo anual que identifica ameaas e vulnerabilidades, e resulta em uma avaliao de risco formal. (Exemplos de metodologias de avaliao de risco incluem mas no so limitados a OCTAVE, ISO 27005 e NIST SP 800-30.) 12.1.3 Inclui uma anlise pelo menos uma vez por ano e atualizaes quando o ambiente modificado. 12.2 Desenvolver procedimentos de segurana operacional diariamente que estejam em conformidade com os requisitos nessa especificao (por exemplo, procedimentos de manuteno da conta do usurio e procedimentos de anlise de registros).
12.1Analise a poltica de segurana das informaes e verifique se a poltica foi publicada e disseminada a todos os funcionrios relevantes (incluindo fornecedores e parceiros comerciais). 12.1.1 Verifique se a poltica atende a todos os requisitos do PCI DSS. 12.1.2.a Verifique se um processo anual que identifica e ameaas e vulnerabilidades documentado e resulta em uma avaliao de risco formal. 12.1.2.b Analise a documentao da avaliao de risco para verificar se o processo de avaliao de risco realizada ao menos anualmente.
Implement ado
12.1.3 Verifique se 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 Analise os procedimentos de segurana operacional diariamente. Verifique se eles esto em conformidade com essa especificao e incluem procedimentos administrativos e tcnicos para cada um dos requisitos.

12.3 Desenvolver polticas de utilizao para tecnologias crticas voltadas aos funcionrios (por exemplo, tecnologias de acesso remoto, tecnologias sem fio, mdia eletrnica removvel, laptops, dados pessoais/assistentes digitais (PDAs), uso de e-mail e uso da Internet) para definir o uso adequado dessas tecnologias para todos os funcionrios e prestadores de servios. Assegurar que essas polticas de utilizao exijam o seguinte: 12.3.1 Explicitar a aprovao por partes autorizadas 12.3.2 Autenticao para o uso da tecnologia 12.3.3 Uma lista de todos esses dispositivos e equipes com acesso 12.3.4 Identificao dos dispositivos com proprietrio, informaes de contato e finalidade 12.3.5 Usos aceitveis da tecnologia 12.3.6 Locais de rede aceitveis quanto s tecnologias 12.3.7Lista dos produtos aprovados pela empresa 12.3.8 Desconexo automtica das sesses quanto s tecnologias de acesso remoto aps um perodo especfico de inatividade
12.3 Obtenha e analise a poltica de tecnologias crticas voltadas aos funcionrios e desempenhe o seguinte:
Implement ado
No implement ado
12.3.1 Verifique se as polticas de utilizao exigem a aprovao da gerncia para usar as tecnologias. 12.3.2 Verifique se as polticas de utilizao exigem que todo o uso da tecnologia seja autenticado com ID de usurio e senha ou outro item de autenticao (por exemplo, token). 12.3.3 Verifique se as polticas de utilizao exigem uma lista de todos os dispositivos e equipes autorizadas a usar os dispositivos. 12.3.4 Verifique se as polticas de utilizao exigem a identificao dos dispositivos com proprietrio, informaes de contato e finalidade. 12.3.5 Verifique se as polticas de utilizao exigem usos aceitveis quanto tecnologia. 12.3.6 Verifique se as polticas de utilizao exigem locais de rede aceitveis quanto tecnologia. 12.3.7 Verifique se as polticas de utilizao exigem uma lista de produtos aprovados pela empresa. 12.3.8 Verifique se as polticas de utilizao exigem a desconexo automtica das sesses quanto s tecnologias de acesso remoto aps um perodo especfico de inatividade.

12.3.9 Ativao de tecnologias de acesso remoto para fornecedores e parceiros de negcio somente quando lhes for necessrio, com desativao imediata aps o uso 12.3.10 Para funcionrios que acessam os dados do titular do carto por meio de tecnologias de acesso remoto, proibir a cpia, a transferncia e o armazenamento dos dados do titular do carto em discos rgidos locais e mdias eletrnicas removveis, exceto se explicitamente autorizado para uma necessidade comercial definida. 12.4 Certificar-se de que a poltica e os procedimentos de segurana definem claramente as responsabilidades quanto segurana das informaes para todos os funcionrios. 12.5 Atribuir a um indivduo ou a uma equipe as seguintes responsabilidades de gerenciamento da segurana das informaes:
12.3.9 Verifique se as polticas de utilizao exigem a ativao de tecnologias de acesso remoto usadas pelos fornecedores somente quando for necessrio por parte dos fornecedores, com uma desativao imediata aps o uso. 12.3.10.a Verifique se as polticas de utilizao probem a cpia, a transferncia ou o armazenamento dos dados do titular do carto em discos rgidos locais e mdias eletrnicas removveis ao acessar esses dados por meio de tecnologias de acesso remotas. 12.3.10.b Para funcionrios com autorizao adequada, verifique se o uso de polticas exige a proteo dos dados do titular do carto de acordo com os Requisitos do PCI DSS.
Implement ado
No implement ado
12.4 Verifique se as polticas de segurana das informaes definem claramente as responsabilidades quanto segurana das informaes para todos os funcionrios.
12.5Verifique a atribuio formal da segurana das informaes com relao a um Responsvel pela Segurana ou outro membro do gerenciamento que tenha conhecimento sobre segurana. Obtenha e analise as polticas e procedimentos de segurana das informaes para verificar se as seguintes responsabilidades da segurana das informaes foram atribudas de modo especfico e formal: 12.5.1 Verifique se a responsabilidade de criar e distribuir polticas e procedimentos de segurana est formalmente atribuda. 12.5.2 Verifique se a responsabilidade pelo monitoramento e anlise dos alertas de segurana, e pela distribuio de informaes s equipes de gerenciamento adequadas da segurana das informaes e das unidades de negcios foi formalmente atribuda.
12.5.1 Definir, documentar e distribuir polticas e procedimentos de segurana. 12.5.2 Monitorar e analisar os alertas e as informaes de segurana, e distribuir para as equipes apropriadas.

12.5.3 Definir, documentar e distribuir procedimentos de resposta e escalao de incidentes de segurana para assegurar que todas as situaes sejam abordadas de modo oportuno e eficiente. 12.5.4 Administrar as contas dos usurios, incluindo adies, excluses e modificaes 12.5.5 Monitorar e controlar todos os acessos aos dados. 12.6Implementar um programa formal de conscientizao da segurana para conscientizar todos os funcionrios sobre a importncia da segurana dos dados do portador do carto. 12.6.1 Instruir os funcionrios quando da contratao e pelo menos uma vez por ano. Observao: Os mtodos podem variar dependendo da funo de cada funcionrio e do nvel de acesso aos dados do titular do carto. 12.6.2 Exigir que os funcionrios reconheam, pelo menos uma vez por ano, que leram e compreenderam a poltica e os procedimentos de segurana da empresa.
12.5.3 Verifique se a responsabilidade pela criao e distribuio de procedimentos de resposta e escalao de incidentes segurana foi formalmente atribuda.
Implement ado
No implement ado
12.5.4 Verifique se a responsabilidade pela administrao das contas dos usurios e do gerenciamento da autenticao foi formalmente atribuda. 12.5.5 Verifique se a responsabilidade por monitorar e controlar todo o acesso aos dados est formalmente atribuda. 12.6.a Verifique a existncia de um programa formal de conscientizao da segurana para todos os funcionrios. 12.6.b Obtenha e analise os procedimentos e a documentao do programa de conscientizao de segurana, e desempenhe o seguinte: 21.6.1.a Verifique se o programa de conscientizao da segurana fornece vrios mtodos para transmitir a conscientizao e instruir os funcionrios (por exemplo, cartazes, cartas, memorandos, treinamento baseado na Web, reunies e promoes). 12.6.1.b Verifique se os funcionrios participam do treinamento de conscientizao quando da contratao e pelo menos uma vez por ano. 12.6.2 Verifique se o programa de conscientizao da segurana exige que os funcionrios reconheam (por exemplo, por escrito ou eletronicamente), pelo menos uma vez por ano, que leram e compreenderam a poltica de segurana das informaes da empresa.

12.7 Analise bem os potenciais funcionrios antes de contratar para minimizar o risco de ataques a partir 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 os funcionrios como caixas de loja que tm acesso somente a um nmero do carto por vez ao viabilizar uma transao, esse requisito apenas uma recomendao. 12.8 Se os dados do titular do carto forem compartilhados com prestadores de servios, manter e implementar polticas e procedimentos para gerenciar os prestadores de servios, incluindo o seguinte:
12.7 Indagar a gerncia do departamento dos Recursos Humanos e conferir se as verificaes da formao so realizadas (dentro das restries das leis locais) junto aos funcionrios antes de contratar quem ter acesso aos dados do titular do carto ou ao ambiente desses dados.
Implement ado
No implement ado
12.8 Se a entidade compartilha dados do portador do carto com prestadores de servios (por exemplo, reas de armazenamento de fitas de back-up, prestadores de servios gerenciados, como empresas de hospedagem na Web ou prestadores de servios de segurana, ou aqueles que recebem dados para fins de determinao de fraude), analise, por meio da observao, as polticas e procedimentos, alm da documentao de suporte, e desempenhe o seguinte: 12.8.1 Verificar se uma lista dos prestadores de servios mantida. 12.8.2 Verifique se o acordo por escrito inclui um reconhecimento dos prestadores de servios quanto sua responsabilidade pela proteo dos dados do portador do carto.
12.8.1 Manter uma lista dos prestadores de servios. 12.8.2 Manter um acordo por escrito que inclua um reconhecimento de que os prestadores de servios so responsveis pela segurana dos dados do portador do carto que eles possurem. 12.8.3 Certificar-se de que haja um processo definido para a contratao dos prestadores de servios, incluindo uma diligncia devida adequada antes da contratao.
12.8.3 Verifique se as polticas e procedimentos esto documentados e foram seguidos, incluindo a diligncia devida adequada antes da contratao de qualquer prestador de servios.

12.8.4 Manter um programa para monitorar o status de conformidade quanto ao PCI DSS dos prestadores de servios. 12.9 Implementar um plano de resposta a incidentes. Preparar-se para responder imediatamente a uma falha no sistema. 12.9.1 Criar o plano de resposta a incidentes para ser implementado no caso de violaes do sistema. Certificar-se de que o plano aborda o seguinte, pelo menos: Funes, responsabilidades e estratgias de comunicao e contato no caso de um comprometimento, incluindo a notificao s bandeiras de pagamento, pelo menos Procedimentos de resposta especficos a incidentes Procedimentos de recuperao e continuidade dos negcios Processos de back-up dos dados Anlise dos requisitos legais visando ao relato dos comprometimentos Abrangncia e resposta de todos os componentes crticos do sistema Referncia ou incluso de procedimentos de resposta a incidentes por parte das bandeiras de pagamento 12.9.2 Testar o plano pelo menos uma vez por ano.
12.8.4 Verifique se a entidade mantm um programa para monitorar o status de conformidade quanto ao PCI DSS dos prestadores de servios pelo menos uma vez por ano. 12.9 Obtenha e analise o Plano de Resposta a Incidentes e os procedimentos relacionados, e desempenhe o seguinte: 12.9.1.a Verifique se o plano de resposta a incidentes inclui: Funes, responsabilidades e estratgias de comunicao no caso de um comprometimento, incluindo a notificao s bandeiras de pagamento, pelo menos: Procedimentos de resposta especficos a incidentes Procedimentos de recuperao e continuidade dos negcios Processos de back-up dos dados Anlise dos requisitos legais referentes ao relato dos comprometimentos (por exemplo, Lei 1386 da Califrnia, que exige a notificao dos clientes afetados no caso de um comprometimento real ou suspeito para qualquer negcio que seja realizado com moradores da Califrnia em seu banco de dados) Abrangncia e resposta de todos os componentes crticos do sistema Referncia ou incluso de procedimentos de resposta a incidentes por parte das bandeiras de pagamento 12.9.1.b Analise a documentao a partir de um incidente ou alerta relatado previamente para verificar se o plano e os procedimentos de resposta ao incidente documentado foram seguidos.
Implement ado
No implement ado
12.9 Verificar se o plano testado pelo menos uma vez por ano.

12.9.3 Designar equipes especficas para estarem disponveis em tempo integral para responder aos alertas.
12.9.3 Verifique, por meio da observao e da analise das polticas se h uma resposta a incidentes em tempo integral e uma cobertura de monitoramento para qualquer evidncia de atividade no autorizada, deteco de pontos de acesso sem fio no autorizados, alertas de IDS crticos e/ou relatrios de sistemas crticos no autorizados ou alteraes nos arquivos de contedo. 12.9.4 Verifique, por meio de polticas e de anlise, se a equipe com responsabilidades por violaes de segurana so treinadas periodicamente. 12.9.5 Verifique, por meio da observao e da anlise dos processos, se o monitoramento e a resposta aos alertas dos sistemas de segurana, incluindo os pontos de acesso sem fio no autorizados so abordados no Plano de Resposta a Incidentes. 12.9.6 Verifique, por meio da observao e da anlise das polticas, se h um processo para modificar e aprimorar o plano de resposta a incidentes, de acordo com as lies aprendidas e para incorporar os desenvolvimentos do setor.
Implement ado
No implement ado
12.9.4Fornecer o treinamento adequado equipe que responsvel pela resposta s falhas do sistema. 12.9.5 Incluir alertas de sistemas de deteco de invaso, preveno contra invases e monitoramento da integridade dos arquivos. Desenvolver um processo para modificar e aprimorar o plano de resposta a incidentes, de acordo com as lies aprendidas e para incorporar os desenvolvimentos do setor.
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 portador do carto
Conforme mencionado no Requisito 12.8, todos os prestadores de servios com acesso aos dados do portador do carto (incluindo os provedores de hospedagem compartilhada) devem seguir o PCI DSS. Alm disso, o Requisito 2,4 afirma que os provedores de hospedagem compartilhada devem proteger o ambiente hospedado e os dados de cada entidade. Portanto, os provedores de hospedagem compartilhada tambm devem estar em conformidade com os requisitos nesse Apndice.
Impleme ntado No impleme ntado Data prevista/ Comentrios
Requisitos
A.1 Proteja o ambiente hospedado e os dados de cada entidade (seja comerciante, prestador de servios ou outra entidade), de acordo com os itens A.1.1 a A.1.4: Um provedor de hospedagem deve atender a esses requisitos, assim como a todas as outras sees relevantes do PCI DSS. Observao: Embora um provedor de hospedagem possa atender a esses requisitos, a conformidade da entidade de que utiliza o provedor de hospedagem no assegurada. Cada entidade deve estar em conformidade com o PCI DSS e validar a conformidade, conforme aplicvel.
A.1Especificamente para uma avaliao do PCI DSS de um provedor de hospedagem compartilhada, para verificar se os provedores de hospedagem compartilhada protegem o ambiente hospedado e os dados das entidades (comerciantes e prestadores de servios), selecione um exemplo de servidores (Microsoft Windows e Unix/Linux) dentre vrios exemplos representativos de comerciantes e prestadores de servios e desempenhe o que est descrito nos itens A.1.1 a A.1.4 abaixo
Requisitos
A.1.1 Certificar-se de que cada entidade executa somente os processos que tm acesso aos dados do portador do carto daquela entidade.
A.1.1 Se um provedor de hospedagem compartilhada permitir que as entidades (por exemplo, comerciantes ou prestadores de servios) executem seus prprios aplicativos, verifique se os processos desses aplicativos so executados usando o 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.a Verifique se o ID do usurio de qualquer processo de aplicativos no um usurio privilegiado (raiz/admin). A.1.2.b Verifique se cada entidade (comerciante, prestador de servios) lei, gravou ou executou as permisses somente 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. A.1.2.c Verifique se os usurios da entidade no tm acesso de gravao aos binrios compartilhados do sistema. A.1.2.d Verifique se a visualizao das entradas de registro restrita entidade detentora. A.1.2.e Para assegurar que cada entidade no possa monopolizar os recursos do servidor para explorar as vulnerabilidades (por exemplo, condies de erro, acelerao e reinicializao, resultando, por exemplo, em excessos de buffer), verifique se as restries foram implementadas para a utilizao destes recursos do sistema: Espao em disco Largura de banda Memria CPU
Impleme ntado
No impleme ntado
A.1.2 Restringir o acesso e os privilgios de cada entidade somente ao prprio ambiente de dados do portador do carto.
Requisitos
A.1.3 Certificar-se de que os registros e as trilhas de auditoria esto ativadas e so exclusivas para o ambiente de dados do portador do carto de cada entidade, alm de estarem em conformidade com o Requisito 10 do PCI DSS. A.1.4 Permitir que os processos providenciem uma investigao forense oportuna no caso de um comprometimento em qualquer comerciante ou prestador de servios hospedado.
A.1.3 Verifique se o provedor de hospedagem compartilhada ativou os registros conforme se segue, para o ambiente de cada comerciante e prestador de servios: Os registros so ativados para os aplicativos de terceiros comuns. Como padro, os registros esto ativados. Os registros esto disponveis para anlise pela entidade detentora. As localizaes dos registros so informadas com clareza entidade detentora. A.1.4 Verifique se o provedor de hospedagem compartilhada definiu polticas que fornecem uma investigao forense oportuna dos servidores relacionados no caso de um comprometimento.
Impleme ntado
No impleme ntado
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 no 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 referente ao item sob anlise (contas). 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 no console quando a transmisso de senhas criptografadas no for compatvel. A autenticao com dois fatores pode 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 portador 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
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.
Anexo C: Planilha dos controles de compensao

Use esta planilha para definir os controles de compensao para qualquer requisito no qual os controles de compensao so usados para atender a um requisito do PCI DSS. Os controles de compensao tambm devem ser documentados no Relatrio sobre Conformidade na seo do requisito do PCI DSS correspondente. 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 explique 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
Planilha dos controles de compensao Exemplo completo

Use esta planilha para definir os controles de compensao para qualquer requisito indicado como implantado via controles de compensao. 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 portador 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 registro 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 que o comando SU est sendo executado e que as pessoas usando o comando efetuaram login para identificar que se 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 explique 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.
Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema
Requisitos do PCI DSS e Procedimentos da Avaliao da Segurana, Verso 2.0 Copyright 2010 Conselho de Padres de Segurana LLC do PCI

Pci Dss v2-0

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

Pci Dss v2-0

Caricato da

Copyright:

Formati disponibili

Setor de cartes de pagamento (PCI)

Padro de segurana de dados

Outubro de 2010 Pgina 2

Requisito 7: o negcio Requisito 8: Requisito 9:

Monitorar e Testar as Redes Regularmente ................................................................................................................................ 60

Outubro de 2010 Pgina 4

Introduo e viso geral do padro de segurana de dados do PCI

Outubro de 2010 Pgina 5

Outubro de 2010 Pgina 6

Outubro de 2010 Pgina 7

Informaes de aplicabilidade do PCI DSS

Outubro de 2010 Pgina 8

Sim Sim Sim Sim No No No

Dados de autenticao confidenciais

Outubro de 2010 Pgina 9

Relao entre PCI DSS e PA-DSS

Outubro de 2010 Pgina 10

Escopo da avaliao quanto conformidade com os requisitos do PCI DSS

Outubro de 2010 Pgina 11

Amostragem de reas de negcios e componentes do sistema

Outubro de 2010 Pgina 13

Outubro de 2010 Pgina 14

Instrues e contedo para o relatrio sobre conformidade

Contedo e formato do relatrio

Outubro de 2010 Pgina 15

Outubro de 2010 Pgina 16

Outubro de 2010 Pgina 17

Revalidao dos itens em aberto

Conformidade do PCI DSS Etapas de concluso

Outubro de 2010 Pgina 19

Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana

Outubro de 2010 Pgina 20

Construa e mantenha uma rede segura

Requisitos do PCI DSS

Data prevista/ Comentrios

Outubro de 2010 Pgina 21

Requisitos do PCI DSS

Data prevista/ Comentrios

Outubro de 2010 Pgina 22

Requisitos do PCI DSS

Data prevista/ Comentrios

1.2.2 Proteger e sincronizar os arquivos de configurao do roteador.

Outubro de 2010 Pgina 23

Requisitos do PCI DSS

Data prevista/ Comentrios

Outubro de 2010 Pgina 24

Requisitos do PCI DSS

Data prevista/ Comentrios

Outubro de 2010 Pgina 25

Requisitos do PCI DSS

Outubro de 2010 Pgina 26

Data prevista/ Comentrios

Outubro de 2010 Pgina 27

Data prevista/ Comentrios

Outubro de 2010 Pgina 28

Data prevista/ Comentrios

Outubro de 2010 Pgina 29

Proteger os dados do portador do carto

Requisitos do PCI DSS

Outubro de 2010 Pgina 30

Requisitos do PCI DSS

Data prevista/ Comentrios

Outubro de 2010 Pgina 31