PCI DSS v3

Indstria de cartes de pagamento (PCI)
Padro de Segurana de Dados
Requisitos e procedimentos da avaliao de segurana

Verso 3.0
Novembro de 2013
Alteraes no documento
Data Verso Descrio Introduzir PCI DSS v1.2 como Requisitos e procedimentos de avaliao da segurana do PCI DSS, eliminando a redundncia entre os documentos e fazer mudanas gerais e especficas de Procedimentos de auditoria de segurana do 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. Julho de 2009 1.2.1 Remover marca cinza nas 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 Novembro de 2013 2.0 3.0 Atualizar e implementar as alteraes da v1.2.1. Consulte Resumo de alteraes do PCI DSS a partir da verso 1.2.1 para a 2.0 do PCI-DSS. Atualizar a partir da v2.0. Consulte Resumo de alteraes do PCI DSS a partir da verso 2.0 para a 3.0 do PCI-DSS. 5 32 33 Pginas
Outubro de 2008
1.2
64
Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados.
Pgina 2 Novembro de 2013
ndice
Alteraes no documento ................................................................................................................................................................. 2 Introduo e viso geral do padro de segurana de dados do PCI.............................................................................................. 5
Recursos PCI DSS ...................................................................................................................................................................................................... 6
Informaes de aplicabilidade do PCI DSS ...................................................................................................................................... 7 Relao entre PCI DSS e PA-DSS ..................................................................................................................................................... 9
Aplicabilidade do PCI DSS para aplicativos PA-DSS ................................................................................................................................................. 9 Aplicabilidade do PCI DSS para fornecedores de aplicativos de pagamento ............................................................................................................ 9
Escopo dos requisitos do PCI DSS ................................................................................................................................................ 10

Segmentao da rede ............................................................................................................................................................................................... 11 Sem fio 11 Uso dos prestadores de servios terceirizados/terceirizao ................................................................................................................................... 12
Melhores prticas para implementar o PCI DSS nos processos de cenrios de referncia ...................................................... 13 Para os assessores: Amostragem de reas de negcios e componentes do sistema ............................................................... 15 Controles de compensao ............................................................................................................................................................ 16 Instrues e contedo para o relatrio sobre conformidade ....................................................................................................... 17 Processo de avaliao do PCI DSS ................................................................................................................................................ 17 Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana...................................................................... 18
Construir e manter a segurana de rede e sistemas ............................................................................................................................................ 19 Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do portador do carto ................................................ 19 Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana ................... 28 Proteger os dados do portador do carto ............................................................................................................................................................. 35 Requisito 3: Proteger os dados armazenados do portador do carto ............................................................................................................. 35 Requisito 4: Criptografe a transmisso dos dados do portador do carto em redes abertas e pblicas ....................................................... 47 Manter um programa de gerenciamento de vulnerabilidades ............................................................................................................................. 50 Requisito 5: Proteja todos os sistemas contra softwares prejudiciais e atualize regularmente programas ou software de antivrus ............ 50 Requisito 6: Desenvolver e manter sistemas e aplicativos seguros ............................................................................................................... 54 Implemente medidas rigorosas de controle de acesso ....................................................................................................................................... 69 Requisito 7: Restrinja o acesso aos dados do portador do carto de acordo com a necessidade de conhecimento para o negcio ........... 69 Requisito 8: Identifique e autentique o acesso aos componentes do sistema ............................................................................................... 72
Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados. Pgina 3 Novembro de 2013
Requisito 9:
Restrinja o acesso fsico aos dados do portador do carto ........................................................................................................ 82
Monitorar e testar as redes regularmente.............................................................................................................................................................. 93 Requisito 10: Acompanhe e monitore todos os acessos com relao aos recursos da rede e aos dados do portador do carto .................. 93 Requisito 11: Testar regularmente os sistemas e processos de segurana................................................................................................... 101 Manter uma poltica de segurana de informaes ............................................................................................................................................ 111 Requisito 12: Mantenha uma poltica que aborde a segurana da informao para todas as equipes. ................................................................ 111
Apndice A: Apndice B: Apndice C: Apndice D:
Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada ................................. 122 Controles de compensao.............................................................................................................................. 125 Planilha dos controles de compensao ........................................................................................................ 127 Segmentao e amostragem de reas de negcios/componentes do sistema............................................ 129
Requisito A.1: Os provedores de hospedagem compartilhada devem proteger o ambiente de dados do portador do carto .............................. 122
Introduo e viso geral do padro de segurana de dados do PCI

O Padro de Segurana de Dados da Indstria de Cartes de Pagamento (PCI DSS) foi desenvolvido para incentivar e aprimorar a segurana dos dados do portador do carto e promover a ampla adoo de medidas de segurana de dados consistentes no mundo todo. O PCI DSS oferece a base de requisitos tcnicos e operacionais elaborados para proteger os dados do portador do carto. O PCI DSS se aplica a todas as entidades envolvidas nos processos de pagamento do carto inclusive comerciantes, processadores, adquirentes, emissores e prestadores de servio, bem como todas as entidades que armazenam, processam ou transmitem os dados do portador do carto (CHD) e/ou dados de autenticao confidenciais (SAD). Abaixo, h uma viso geral de alto nvel dos 12 requisitos do PCI DSS.
Este documento, Requisitos dos Padro 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 do PCI DSS se iniciam na pgina 15. O PCI DSS compreende um conjunto mnimo de requisitos para proteger os dados do portador do carto e pode ser aperfeioado por controles e prticas adicionais para amenizar ainda mais os riscos, bem como as normas e leis 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 portador do carto). O PCI DSS no substitui as leis locais ou regionais, normas governamentais ou outros requisitos legais.
Recursos PCI DSS

O site do PCI Security Standards Council (PCI SSC) (www.pcisecuritystandards.org) contm alguns recursos adicionais para auxiliar as organizaes com suas avaliaes e validaes do PCI DSS, inclusive: Biblioteca de documentos, incluindo: o o o o o o o o PCI DSS Resumo de alteraes a partir da verso 2.0 para a 3.0 do PCIDSS. Guia de referncia rpida do PCI DSS Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS Suplementos informativos e orientaes Abordagem priorizada para o PCI DSS Relatrio de conformidade (ROC) Modelo de relatrio e Instrues de relatrio Questionrios de autoavaliao (SAQs) e diretrizes e instrues do SAQ Atestados de conformidade (AOCs) Observao: Os suplementos informativos complementam o PCI DSS e identificam consideraes adicionais e recomendaes para atender aos requisitos do PCI DSSeles no alteram, eliminam ou sobrepem o PCI DSS ou qualquer de seus requisitos.
Perguntas frequentes (FAQs) PCI para sites de pequenos comerciantes Treinamentos e seminrios online do PCI Lista de assessores de segurana qualificados (QSAs) e fornecedores de varredura aprovados (ASVs) Lista de dispositivos PTS aprovados e aplicativos PA-DSS de pagamento validados
Consulte www.pcisecuritystandards.org para obter informaes sobre estes e outros recursos.
Informaes de aplicabilidade do PCI DSS

O PCI DSS se aplica a todas as entidades envolvidas nos processos de pagamento do carto, inclusive comerciantes, processadores e prestadores de servio, bem como todas as entidades que armazenam, processam ou transmitem os dados do portador do carto e/ou dados de autenticao confidenciais. Os dados do portador do carto e os dados de autenticao confidenciais so definidos conforme segue:
Dados contbeis Os dados do portador do carto incluem: O nmero da conta principal (PAN) Nome do portador do carto Data de vencimento Cdigo de servio Os dados de autenticao confidenciais incluem: Dados de rastreamento completo (dados em tarja magntica ou equivalentes em chip) CAV2/CVC2/CVV2/CID PINs/Bloqueios de PIN
O primeiro nmero contbil o fator determinante para os dados do portador do carto. Se o nome, cdigo de servio e/ou data de validade de um portador do carto so armazenados, processados ou transmitidos com o PAN ou, de outro modo, esto presentes no ambiente de dados do portador do carto, eles devem ser protegidos de acordo com os requisitos aplicveis do PCI DSS. Os requisitos do PCI DSS se aplicam a organizaes e ambientes onde os dados contbeis (dados do portador do carto e/ou dados de autenticao confidenciais) sejam armazenados, processados ou transmitidos. Alguns requisitos do PCI DSS tambm podem ser aplicveis a 1 organizaes que tenham terceirizado suas operaes de pagamento ou o gerenciamento de seu CDE . Alm disso, as organizaes que terceirizam seu CDE ou operaes de pagamento para terceiros so responsveis por garantir que os dados contbeis sejam protegidos por este terceiro conforme os requisitos aplicveis do PCI DSS. A tabela a seguir ilustra os elementos comumente usados do portador 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.
De acordo com os programas em conformidade com a empresa de pagamento individual Pgina 7 Novembro de 2013
Elemento de dados O nmero da conta principal (PAN) Dados contbeis Dados do portador do carto Nome do portador do carto Cdigo de servio Data de vencimento Dados de autenticao 2 confidenciais Dados de rastreamento 3 completo CAV2/CVC2/CVV2/CID PIN/Bloco de PIN
5 4
Armazenamento permitido Sim Sim Sim Sim No No No
Converter dados armazenados ilegveis conforme Requisito 3.4 Sim No No No No armazenvel conforme Requisito 3.2 No armazenvel conforme Requisito 3.2 No armazenvel conforme Requisito 3.2
Os Requisitos 3.3 e 3.4 do PCI DSS aplicam-se apenas ao PAN. Se o PAN for armazenado com outros elementos dos dados do portador do carto, somente o PAN dever ser convertido como ilegvel de acordo com o Requisito 3.4 do PCI DSS. Dados de autenticao confidenciais no devem ser armazenados aps a autorizao, mesmo se forem criptografados. Isso se aplica mesmo onde no h PAN no ambiente. As organizaes devem entrar em contato diretamente com seu adquirente ou empresa de pagamento para saber se permitido armazenar o SAD antes da autorizao, por quanto tempo e quaisquer requisitos de proteo e utilizao.
2 3 4 5
Os dados de autenticao confidenciais no devem ser armazenados aps a autorizao (mesmo se forem criptografados). Dados de rastreamento completo da tarja magntica, dados equivalentes no chip, ou em outro lugar O valor de trs ou quatro dgitos impresso na frente ou atrs de um carto de pagamento Nmero de identificao pessoal inserido pelo portador do carto durante uma transao com carto e/ou bloqueio de PIN criptografado dentro da mensagem da transao Pgina 8 Novembro de 2013
Relao entre PCI DSS e PA-DSS

Aplicabilidade do PCI DSS para aplicativos PA-DSS
O uso de um aplicativo compatvel com o Padro de Segurana de Dados de Formulrio de Pagamento (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. Todos os aplicativos que armazenam, processam ou transmitem dados do portador do carto abrangem uma avaliao do PCI DSS da entidade, incluindo aplicativos que tenham sido validados para PA-DSS. A avaliao do PCI DSS deve verificar se o aplicativo de pagamento validado do PA-DSS est configurado adequadamente e implementado com segurana conforme os requisitos do PCI DSS. Se o aplicativo de pagamento tiver passado por qualquer customizao, uma reviso mais detalhada ser exigida durante a avaliao do PCI DSS, j que o aplicativo pode no ser mais caracterstico da verso que foi validada para o PA-DSS. Os requisitos do PA-DSS derivam-se dos Requisitos do PCI DSS e dos procedimentos de avaliao da segurana (definidos neste documento). O PA-DSS detalha os requisitos que um aplicativo de pagamento deve atender para facilitar a conformidade do PCI DSS de um cliente. Os aplicativos de pagamento seguro, quando implementados em um ambiente compatvel com PCI-DSS, minimizaro as possibilidades de quebras na segurana, levando ao comprometimento do PAN, dados de rastreamento completo, cdigos e valores de validao do carto (CAV2, CID, CVC2 e CVV2), PINs e bloqueios de PIN e a fraudes destruidoras resultantes dessas quebras. Para determinar se o PA-DSS se aplica a um determinado aplicativo de pagamento, consulte o Guia do programa PA-DSS que pode ser encontrado no site www.pcisecuritystandards.org.
Aplicabilidade do PCI DSS para fornecedores de aplicativos de pagamento

O PCI DSS pode se aplicar a fornecedores de aplicativos de pagamentos se estes armazenam, processam ou transmitem dados do portador do carto, ou se tiverem acesso aos dados do portador do carto de seus clientes (por exemplo, na funo de um prestador de servios).
Escopo dos requisitos do PCI DSS

Os requisitos de segurana do PCI DSS se aplicam a todos os componentes do sistema que estejam includos ou conectados no ambiente dos dados do portador do carto. O ambiente de dados do portador do carto (CDE) compreende pessoas, processos e tecnologias que armazenam, processam, ou transmitem os dados do portador do carto ou dados de autenticao confidenciais. Os "componentes do sistema" incluem dispositivos de rede, servidores, dispositivos de computao e aplicativos. Exemplos de componentes do sistema incluem, entre outros, o seguinte: Sistemas que oferecem servios de segurana (por exemplo, servidores de autenticao), facilitam a segmentao (por exemplo, firewalls internos) ou podem impactar a segurana do CDE (por exemplo, servidores de redirecionamento de rede ou resoluo de nome). Componentes de virtualizao como mquinas virtuais, switches/roteadores virtuais, mecanismos virtuais, aplicativos/desktops virtuais e hipervisores. Os componentes de rede incluem, entre outros, firewalls, switches, roteadores, pontos de acesso sem fio, dispositivos de rede e outros dispositivos de segurana. Os tipos de servidor incluem, entre outros, 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). Qualquer outro componente ou dispositivo localizado dentro ou conectado ao CDE
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 portador 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 portador do carto em seu ambiente, para verificar se nenhum dado do portador do carto existe fora do CDE definido no momento. Assim que todos os locais dos dados do portador 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 portador do carto). A entidade considera que quaisquer dados do portador do carto encontrados esto no escopo da avaliao do PCI DSS e so parte do CDE. Se a entidade identificar dados que no estejam atualmente includos no CDE, estes dados devem ser apagados com segurana, migrados para o CDE definido atualmente ou para o CDE redefinido para incluir estes dados. A entidade retm a documentao que mostra como o escopo do PCI DSS foi determinado. A documentao retida para a reviso da assessoria e/ou para referncia durante a prxima atividade anual de confirmao do escopo do PCI DSS.
Para cada avaliao do PCI DSS, necessrio que o assessor valide que o escopo da avaliao est corretamente definido e documentado.
Segmentao da rede
A segmentao da rede ou o isolamento (separao) do ambiente de dados do portador 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 portador 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. Para ser considerado fora do escopo para o PCI DSS, um componente de sistema deve estar adequadamente isolado (segmentado) do CDE, de forma que mesmo se o componente de sistema fora do escopo estivesse comprometido, ele no poderia impactar na segurana do CDE. Um pr-requisito importante para reduzir o escopo do ambiente de dados do portador do carto uma compreenso clara das necessidades do negcio e dos processos relacionados ao armazenamento, processamento ou transmisso dos dados do portador do carto. Restringir os dados do portador 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 portador do carto por meio de um diagrama de fluxo de dados ajuda a compreender totalmente todos os fluxos de dados do portador do carto e assegura que qualquer segmentao de rede seja eficiente no isolamento do ambiente de dados do portador do carto. Se a segmentao da rede tiver sido implementada e sendo usada para reduzir o escopo da avaliao do PCI DSS, o assessor 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 portador do carto dos outros sistemas. Entretanto, a adequao de uma implementao especfica da segmentao da rede varia muito e depende de 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 portador do carto (por exemplo, transaes do ponto de venda, "quebra de linha") ou se uma WLAN (Wireless Local Area Network) for parte do ou estiver conectada ao ambiente de dados do portador do carto, 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.
Uso dos prestadores de servios terceirizados/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 portador do carto. Um prestador de servios ou comerciante pode usar um provedor terceirizado para armazenar, processar ou transmitir dados do portador 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 portador do carto. As partes devem identificar claramente os servios e componentes do sistemas que so includos no escopo da avaliao do PCI DSS do prestador de servios, os requisitos especficos do PCI DSS abrangidos pelo prestador de servios e quaisquer requisitos que os clientes do prestador de servios sejam responsveis por incluir em suas prprias revises do PCI DSS. Por exemplo, um provedor de hospedagem gerenciada deve definir claramente quais de seus endereos IP so mapeados como parte de seu processo trimestral de varredura da vulnerabilidade e quais endereos IP os clientes so responsveis por incluir em suas prprias varreduras trimestrais. H duas opes para que os prestadores de servios terceirizados comprovem a conformidade: 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. Se o terceiro realizar sua prpria avaliao do PCI DSS, ele deve fornecer evidncias suficientes aos seus clientes para certificar que o escopo da avaliao do PCI DSS do prestador de servios incluiu os servios aplicveis ao cliente e que os requisitos relevantes do PCI DSS foram examinados e determinados como adequados. O tipo especfico de evidncia fornecida pelo prestador de servios aos seus clientes depender dos acordos/contratos em vigor entre as partes. Por exemplo, fornecer o AOC e/ou sees relevantes do ROC do prestador de servios (redigido para proteger qualquer informao confidencial) pode ajudar a fornecer toda ou alguma informao. 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 portador do carto. Para obter detalhes, consulte o Requisito 12.8 nesse documento.
Melhores prticas para implementar o PCI DSS nos processos de cenrios de referncia
Para assegurar que os controles de segurana continuem a ser adequadamente implementados, o PCI DSS deve ser implementado nas atividades do cenrio de referncia BAU (Business-As-Usual) como parte de uma estratgia global de segurana da entidade. Isso possibilita que uma entidade monitore a efetividade de seus controles de segurana continuamente e mantenha seu ambiente compatvel com o PCI DSS entre as avaliaes do PCI DSS. Exemplos de como o PCI DSS deve ser incorporado nas atividades BAU incluem, entre outros: 1. Monitoramento de controles de segurana (como firewalls, sistemas de deteco de invaso/sistemas de preveno contra invaso (IDS/IPS), monitoramento da integridade do arquivo (FIM), antivrus, controles de acesso, etc.) para assegurar que eles estejam funcionando de maneira efetiva e conforme o planejado. 2. Assegurar que todas as falhas nos controles de segurana sejam detectadas e resolvidas em tempo hbil. Os processos para resolver falhas no controle de segurana devem incluir: Restaurar o controle de segurana Identificar a causa da falha Identificar e encaminhar quaisquer problemas de segurana que surgirem durante a falha do controle de segurana Implementar a minimizao (como controles tcnicos ou de processo) para prevenir que a causa da falha ocorra novamente Retomar o monitoramento do controle de segurana, talvez com monitoramento aprimorado por um perodo de tempo, para confirmar que o controle esteja funcionando de maneira efetiva.
3. Revisar alteraes no ambiente (por exemplo, acrscimo de novos sistemas, mudanas nas configuraes de rede ou do sistema) antes de concluir a alterao e realizar o seguinte: Determinar o possvel impacto ao escopo do PCI DSS (por exemplo, uma nova regra do firewall que permite a conectividade entre um sistema no CDE e outro sistema pode trazer redes ou sistemas adicionais ao escopo para o PCI DSS). Identificar os requisitos do PCI DSS aplicveis aos sistemas e redes afetados pelas alteraes (por exemplo, se um novo sistema estiver no escopo para o PCI DSS, ser preciso configur-lo de acordo com os padres de configurao de sistema, incluindo FIM, AV, patches, registros de auditoria, etc. e ser preciso adicion-lo programao trimestral de varredura de vulnerabilidade). Atualizar o escopo do PCI DSS e implementar controles de segurana conforme o caso
4. Alteraes na estrutura organizacional (por exemplo, aquisio ou fuso de um empresa) devem resultar em reviso formal do impacto ao escopo e requisitos do PCI DSS. 5. Comunicaes e revises peridicas devem ser realizadas para confirmar que os requisitos do PCI DSS continuam em vigor e que os funcionrios esto seguindo os processos seguros. Estas revises peridicas devem abranger todas as instalaes e locais, incluindo pontos de venda, centros de dados, etc. e incluir a reviso dos componentes do sistema (ou amostras dos componentes do sistema), para garantir que os requisitos do PCI DSS continuem em vigor, por exemplo, os padres de configurao foram aplicados, patches e AV esto
atualizados, logs de auditoria esto sendo revisados e assim por diante. A frequncia das revises peridicas deve ser determinada pela entidade conforme o tamanho e complexidade de seu ambiente. Estas revises tambm podem ser usadas para verificar se a evidncia adequada est sendo mantida (por exemplo, logs de auditoria, relatrios de varredura de vulnerabilidade, revises do firewall, etc.) a fim de auxiliar a preparao da entidade para sua prxima avaliao de conformidade. 6. Revisar tecnologias do software e hardware pelo menos uma vez ao ano para se certificar se eles continuam com suporte do fornecedor e se podem atender aos requisitos de segurana da entidade, incluindo o PCI DSS. Se for constatado que as tecnologias no tm mais suporte do fornecedor ou no possam atender s necessidades de segurana da entidade, esta deve preparar um plano de retificao, atualizando e incluindo substituio da tecnologia, se necessrio. Alm das prticas mencionadas acima, as organizaes tambm podem querer considerar a implementao da separao de obrigaes para suas funes de segurana para que as funes de auditoria e/ou segurana sejam separadas das funes operacionais. Em ambientes em que um indivduo executa diversas funes (por exemplo, operaes de segurana e administrativas), as obrigaes podem ser atribudas de forma que nenhum indivduo possua controle total de um processo sem um ponto de verificao independentemente. Por exemplo, as responsabilidades pela configurao e responsabilidades pela aprovao de alteraes podem ser atribudas a indivduos separados.
Observao: Estas prticas de implementao do PCI DSS nos processos de cenrio de referncia so fornecidas apenas como recomendao e orientao e elas no substituem ou expandem qualquer requisito do PCI DSS.
Para os assessores: Amostragem de reas de negcios e componentes do sistema

A amostragem uma opo para que os assessores facilitem o processo de avaliao onde houver grandes nmeros de reas de negcios e/ou componentes do sistema. Enquanto aceitvel que um assessor tire amostras das instalaes do negcio/componentes do sistema como parte de sua reviso da conformidade do PCI DSS de uma entidade, no aceitvel que uma entidade aplique os requisitos do PCI DSS para apenas uma amostra de seu ambiente (por exemplo, requisitos de varredura trimestral de vulnerabilidade se aplicam a todos os componentes do sistema). Da mesma forma, no aceitvel que um assessor faa a reviso de apenas uma amostra dos requisitos do PCI DSS para analisar a conformidade. Aps considerar o escopo e a complexidade gerais do ambiente a ser avaliado, o assessor pode selecionar amostras representativas de reas de negcios/componentes de sistema independentemente para avaliar a conformidade da entidade com 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 assessor garantia de que os controles sero implementados conforme o esperado. Exemplos de reas de negcios incluem, entre outros, escritrios corporativos, lojas, locais de franquias, reas de processamento, centros de dados e outros tipos 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 assessor pode definir uma amostra em uma rea de negcios para incluir servidores Sun executando Apache, servidores Windows executando Oracle, sistemas do mainframe executando aplicativos de processamento de cartes herdados, 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 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 assessor garantia razovel de que todas as reas de negcio/componentes do sistema estejam configurados pelo processo padro. O assessor deve verificar se os controles centralizados e padronizados esto implementados e funcionando de forma efetiva. 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 do PCI DSS seja gerenciado por meio de processos no padronizados, a amostra deve ser maior para o assessor se assegurar de que cada rea de negcio/componente do sistema tenha implementado os requisitos do PCI DSS apropriadamente.
As amostras de componentes do sistema devem incluir todos os tipos e combinaes em uso. Por exemplo, quando os aplicativos servem como amostras, a amostra deve incluir todas as verses e plataformas para cada tipo de aplicativo. Consulte tambm: Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema
Para cada instncia em que a amostragem for usada, o assessor dever: Registrar o argumento atrs da tcnica de amostragem e do tamanho da amostragem, Registrar e validar 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.
Controles de compensao
Anualmente, quaisquer controles de compensao devem ser documentados, revisados e validados pelo assessor 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

As instrues e o contedo do Relatrio de conformidade (ROC) agora so informados no Modelo de relatrio do PCI DSS. O Modelo de relatrio ROC do PCI DSS deve ser usado como modelo para gerar o Relatrio de 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 ou adquirente para definir os requisitos e instrues de relatrio.
Processo de avaliao do PCI DSS

1. Verifique o escopo da avaliao do PCI DSS. 2. Realize a avaliao do PCI DSS do ambiente, seguindo os procedimentos de teste para cada requisito. 3. Se necessrio, realize retificaes para qualquer item inadequado. 4. Conclua o relatrio aplicvel para a avaliao (ou seja, Questionrio deautoavaliao (SAQ) ou Relatrio de conformidade (ROC), incluindo a documentao de todos os controles compensatrios, de acordo com as instrues e orientaes aplicveis do PCI. 5. 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. 6. Envie o SAQ ou ROC e o atestado de conformidade, junto com qualquer outra documentao solicitada, como relatrios de varredura de ASV, 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

As informaes a seguir definem os cabealhos das colunas para os requisitos do PCI DSS e procedimentos da avaliao de segurana: Requisitos do PCI DSS Esta coluna define os requisitos do padro de segurana dos dados; a conformidade do PCI DSS validada de acordo com esses requisitos. Procedimentos de teste Esta coluna exibe os processos a serem seguidos pelo assessor para validar se os requisitos do PCI DSS tm sido atendidos e se esto "vigentes" Orientao Esta coluna descreve a inteno ou o objetivo de segurana por trs de cada um dos requisitos do PCI DSS. Esta coluna contm apenas orientao e tem o objetivo de auxiliar a compreender o porqu de cada requisito. A orientao nesta coluna no substitui ou expande os Requisitos do PCI DSS e Procedimentos de teste.
Observao: Os requisitos do PCI DSS no so considerados adequados se os controles ainda no estiverem implementados ou programados para estarem concludos em uma data futura. Depois que qualquer item em aberto ou inadequado for reportado entidade, o assessor far uma reavaliao para validar se a soluo foi concluda e se todos os requisitos foram atendidos. Consulte os seguintes recursos (disponveis no site do PCI SSC) para documentar a avaliao do PCI DSS: Para obter instrues sobre a concluso de relatrios de conformidade (ROC), consulte o Modelo de relatrio ROC do PCI DSS. Para obter instrues sobre a concluso de questionrios de autoavaliao (SAQ), consulte as Instrues e orientaes SAQ do PCI DSS. Para obter instrues sobre o envio dos relatrios de validao de conformidade do PCI DSS, consulte os atestados de conformidade do PCI DSS.
Construir e manter a segurana de rede e sistemas

Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do portador 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 firewall, contanto que atendam aos requisitos mnimos para firewalls, conforme definido no Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do portador 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 Defina e implemente os padres de configurao do firewall e do roteador que incluam o seguinte:
PROCEDIMENTOS DE TESTE
1.1 Inspecione os padres de configurao do firewall e do roteador, alm de outras documentaes especificadas abaixo e verifique se os padres esto concludos e implementados conforme segue:
ORIENTAO
Firewalls e roteadores so os principais componentes da arquitetura que controlam a entrada e a sada da rede. Esses dispositivos so software ou hardware que bloqueiam acesso indesejado e gerenciam acesso autorizado de e para a rede. Os procedimentos e padres de configurao ajudaro a garantir que a primeira linha de defesa da organizao na proteo de seus dados continue forte.
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.1 Examine os procedimentos documentados para saber se h um processo formal para testar e aprovar todas as: Conexes de rede e Alteraes nas configuraes do roteador e do firewall 1.1.1.bPara obter uma amostra de conexes de rede, converse com o funcionrio responsvel e examine registros para verificar se elas foram aprovadas e testadas.
Um processo documentado e implementado para aprovar e testar todas as conexes e alteraes nos firewalls e roteadores ajudar a evitar problemas de segurana causados pela m configurao da rede, do roteador ou do firewall. Sem a aprovao formal e teste das alteraes, os registros das alteraes podem no ser atualizados, o que pode levar inconsistncia entre a documentao de rede e a configurao Pgina 19 Novembro de 2013
REQUISITOS DO PCI DSS
em si. 1.1.1.c Identifique uma amostra de alteraes reais realizadas nas configuraes do roteador e do firewall, compare com os registros da alterao e converse com o funcionrio responsvel para verificar se as alteraes foram aprovadas e testadas.
ORIENTAO
1.1.2 Diagrama atual da rede que identifica todas as conexes entre o ambiente dos dados do portador do carto e outras redes, incluindo qualquer rede sem fio
1.1.2.a Analise o(s) diagrama(s) e observe as configuraes de rede para saber se existe um diagrama de 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 Converse com o funcionrio responsvel para verificar se o diagrama mantido atualizado.
Os diagramas de rede descrevem como as redes so configuradas e identificam a localizao de todos os dispositivos de rede. Sem os diagramas da rede atual, os dispositivos podem ser ignorados e sem querer deixados de fora dos controles de segurana implementados para PCI DSS e, assim, vulnerveis ao comprometimento. Os diagramas de fluxo de dados do portador do carto identificam a localizao de todos os dados do portador do carto que so armazenados, processados ou transmitidos dentro da rede. Os diagramas de fluxo de dados do portador do carto e de rede ajudam uma organizao a compreender e acompanhar o escopo de seu ambiente, mostrando como os dados do portador do carto passam pelas redes e entre os dispositivos e sistemas individuais. Usar um firewall em todas as conexes de internet que entram e saem da rede e entre qualquer DMZ e a rede interna permite que a organizao monitore e controle o acesso e minimize as chances de um indivduo malintencionado obter acesso rede interna por meio de uma conexo no protegida.
1.1.3 Diagrama atual que mostra todos os fluxos de dados do portador do carto pelos sistemas e redes
1.1.3 Analise o diagrama do fluxo de dados e converse com o funcionrio para verificar se o diagrama: Mostra todos os fluxos de dados do portador do carto pelos sistemas e redes. mantido atualizado conforme necessrio em relao s alteraes no ambiente.
1.1.4 Requisitos para um firewall em cada conexo da internet e entre qualquer zona desmilitarizada (DMZ) e a zona de rede interna
1.1.4.a Analise os padres de configurao do firewall e verifique se eles incluem requisitos para um firewall em cada conexo da internet e entre qualquer DMZ e a zona de rede interna. 1.1.4.b Verifique se o diagrama da rede atual est de acordo com os padres de configurao do firewall. 1.1.4.c Observe as configuraes de rede para verificar se um firewall est implementado em cada conexo da internet e entre qualquer zona desmilitarizada (DMZ) e a zona de rede interna, conforme os padres de configurao registrados e

1.1.5Descrio de grupos, funes e responsabilidades quanto ao gerenciamento dos componentes da rede
os diagramas de rede. 1.1.5.aVerifique se os padres de configurao do firewall e do roteador incluem uma descrio dos grupos, funes e responsabilidades quanto ao gerenciamento dos componentes da rede. 1.1.5.bConverse com o funcionrio responsvel pelo gerenciamento dos componentes da rede para confirmar se as funes e responsabilidades esto atribudos conforme o que est registrado.
ORIENTAO
Essa descrio de funes e a atribuio das responsabilidades garante que os funcionrios estejam cientes de quem responsvel pela segurana de todos os componentes da rede e que os responsveis por gerenciar os componentes estejam cientes de suas responsabilidades. Se as funes e responsabilidades no forem atribudos formalmente, os dispositivos podem ficar sem gerenciamento. Muitas vezes ocorrem comprometimentos decorrentes de portas e servios no utilizados ou no seguros, visto que frequente eles possurem vulnerabilidades conhecidas e muitas organizaes no aplicam patches nas vulnerabilidades para servios, protocolos e portas que eles no utilizam (embora as vulnerabilidades ainda estejam presentes). Definindo e documentando claramente quais portas, servios e portas so necessrios para a empresa, as organizaes podem garantir que todos os outros servios, protocolos e portas sejam desabilitados ou removidos. Se portas, servios e protocolos no seguros forem necessrios para a empresa, o risco apresentado pelo uso desses protocolos deve ser claramente entendido e aceito pela organizao, o uso do protocolo deve ser justificado e os recursos de segurana que permitem que esses protocolos sejam usados com segurana devero ser documentados e implementados. Se esses servios, portas e protocolos no seguros no forem necessrios para a empresa, eles devero ser desativados ou removidos.
1.1.6 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 no seguros. Exemplos de servios, protocolos ou portas no seguros incluem, entre outros, FTP, Telnet, POP3, IMAP e SNMP v1 e v2.
1.1.6.a Verifique se os padres de configurao do firewall e do roteador incluem uma lista documentada dos servios, protocolos e portas, incluindo a justificativa do negcio, por exemplo, protocolos HTTP (Hypertext Transfer Protocol), SSL (Secure Sockets Layer), SSH (Secure Shell) e VPN (Virtual Private Network). 1.1.6.b Identifique portas, servios e protocolos no seguros permitidos e verifique se os recursos de segurana esto documentados para cada servio. 1.1.6.c Analise as configuraes do roteador e do firewall para verificar se os recursos de segurana documentados esto implementados para cada porta, servio e protocolo no seguros.

1.1.7 Requisito para analisar os conjuntos de regras do firewall e do roteador pelo menos a cada seis meses
1.1.7.a Verifique se os padres de configurao do firewall e do roteador exigem a anlise dos conjuntos de regras do roteador e do firewall pelo menos a cada seis meses. 1.1.7.b Analise a documentao referente s revises do conjunto de regras e converse com o funcionrios para verificar se os conjuntos de regras so revisados pelo menos a cada seis meses.
ORIENTAO
Essa anlise d organizao a oportunidade de, pelo menos a cada seis meses, limpar todas as regras desnecessrias, obsoletas ou incorretas e garantir que todos os conjuntos de regras permitam apenas servios e portas autorizados que correspondam s justificativas registradas de negcios. As organizaes que possuem alto volume de alteraes nos conjuntos de regras do roteador e do firewall podem querer realizar as revises com mais frequncia a fim de garantir que os conjuntos de regras continuem a atender as necessidades da empresa. essencial instalar proteo de rede entre a rede interna e confivel e qualquer rede no confivel que seja externa e/ou fique fora da capacidade de controle ou gerenciamento da entidade. A falha em implementar essa medida de forma correta resulta na vulnerabilidade da entidade ao acesso no autorizado de indivduos ou softwares malintencionados. Para que a funcionalidade do firewall seja eficaz, ele deve ser configurado corretamente para controlar e/ou limitar o trfego dentro e fora da rede da entidade.
1.2 Elabore configuraes de firewall e roteador que restrinjam 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 Restrinja o trfego de entrada e sada ao que necessrio ao ambiente de dados do portador do carto e rejeite especificadamente todos os outros trfegos.
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:
1.2.1.a Analise os padres de configurao do roteador e do firewall para verificar se eles identificam o trfego de entrada e sada necessrio para o ambiente de dados do portador do carto. 1.2.1.bAnalise as configuraes do roteador e do firewall para verificar se o trfego de entrada e sada est limitado ao que necessrio para o ambiente de dados do portador do carto. 1.2.1.c Analise as configuraes do roteador e do firewall para verificar 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
Esse requisito destina-se a evitar que indivduos mal-intencionados acessem a rede da entidade por meio de endereos IP no autorizados ou usem servios, protocolos ou portas de forma no autorizada (por exemplo, enviando dados obtidos dentro da sua rede para um servidor no confivel). Implementar uma regra que rejeite todos os trfegos de entrada e sada no necessrios ajuda a evitar violaes acidentais que permitam que trfego potencialmente prejudicial entre ou saia. Pgina 22 Novembro de 2013
a declarao de permisso.
ORIENTAO
1.2.2 Proteja e sincronize os arquivos de configurao do roteador.
1.2.2.a Analise os arquivos de configurao do roteador para verificar se eles esto seguros em relao ao acesso no autorizado. 1.2.2.b Analise as configuraes do roteador para verificar se eles esto sincronizados, por exemplo, a configurao executada (ou ativa) corresponde configurao de inicializao (usada quando as mquinas so ligadas).
Enquanto os arquivos de configurao do roteador executados (ou ativos) incluem as configuraes seguras e atuais, os arquivos de inicializao (que so usados quando os roteadores so reiniciados ou ligados) devem ser atualizados com as mesmas configuraes seguras para garantir que estas configuraes sejam aplicadas quando a configurao de inicializao executada. Por serem executados apenas de vez em quando, os arquivos de configurao de inicializao so frequentemente esquecidos e no so atualizados. Quando o roteador reinicializar e carregar uma configurao de inicializao que no tenha sido atualizada com as mesmas configuraes seguras que a configurao de execuo, isso pode resultar em regras mais fracas que permitam que indivduos mal-intencionados entrem na rede.
1.2.3 Instale firewalls de permetro entre todas as redes sem fio e o ambiente de dados do portador do carto e configure esses firewalls para recusar ou, se o trfego for necessrio para fins comerciais, permitir apenas trfego autorizado entre o ambiente sem fio e o ambiente de dados do portador do carto.
1.2.3.a Analise as configuraes do firewall e do roteador para verificar se h firewalls de permetro instalados entre todas as redes sem fio e o ambiente de dados do portador do carto. 1.2.3.b Verifique se os firewalls recusam ou, se o trfego for necessrio para fins comerciais, permitem apenas trfego autorizado entre o ambiente sem fio e o ambiente de dados do portador do carto.
A implementao conhecida (ou desconhecida) e a explorao da tecnologia sem fio dentro de uma rede um caminho comum para indivduos malintencionados ganharem acesso rede e aos dados do portador do carto. Se um dispositivo sem fio ou uma rede forem instalados sem o conhecimento da entidade, um indivduo malintencionado pode fcil e invisivelmente entrar na rede. Se os firewalls no restringirem o acesso das redes sem fio no CDE, indivduos malintencionados que tiverem acesso no autorizado rede sem fio podero se conectar facilmente ao CDE e comprometer as informaes da conta. Devero ser instalados firewalls entre todas as redes sem fio e o CDE, independentemente da finalidade do ambiente com o qual a rede sem fio estiver conectada. Isto pode incluir, entre outros, redes corporativas, revendedores, redes de
ORIENTAO
acesso ao visitante, ambientes de armazenamento, etc.
1.3 Proba o acesso pblico direto entre a internet e qualquer componente do sistema no ambiente de dados do portador do carto.
1.3 Analise as configuraes do firewall e do roteador (incluindo, entre outros, roteador de suspenso na internet, o roteador DMZ e o firewall, o segmento DMZ do portador do carto, o roteador de permetro e o segmento interno da rede do portador do carto) e realizar o que segue para determinar que no haja acesso direto entre a internet e os componentes do sistema no segmento interno da rede de dados do portador do carto.
O objetivo do firewall gerenciar e controlar todas as conexes entre os sistemas pblicos e internos, especialmente aqueles que armazenam, processam ou transmitem os dados do portador do carto. Se for permitido o acesso direto entre sistemas pblicos e o CDE, as protees oferecidas pelo firewall sero ignoradas e os componentes do sistema que armazenam os dados do portador do carto podero ser comprometidos. O DMZ a parte da rede responsvel pelo gerenciamento das conexes entre a internet (ou redes no confiveis) e os servios que uma empresa precisa disponibilizar para o pblico (como um servidor Web). Este recurso ser utilizado para evitar que indivduos mal-intencionados acessem a rede interna da empresa pela internet ou por meio de servios, protocolos ou portas de forma no autorizada. A anlise de todas as conexes de entrada e sada permite a inspeo e restrio de trfego com base na fonte e/ou endereo de destino, bem como inspeo e bloqueio de contedo no desejado, evitando assim o acesso no filtrado entre ambientes confiveis e no confiveis. Isto ajudar a evitar, por exemplo, que indivduos malintencionados enviem dados obtidos na rede para um servidor externo no confivel em uma rede no confivel.
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 Limite o trfego de entrada da internet a endereos IP na DMZ.
1.3.1 Analise as configuraes do firewall e do roteador para verificar se uma DMZ foi implementada para limitar o trfego somente para componentes do sistema que oferea servios, protocolos e portas acessveis publicamente. 1.3.2 Analise as configuraes do firewall e do roteador para verificar se o trfego de entrada da internet est limitado a endereos IP na DMZ.
1.3.3No permita a entrada ou sada de nenhuma rota direta com relao ao trfego entre a internet e o ambiente de dados do portador do carto.
1.3.3Analise as configuraes do firewall e do roteador para verificar se a entrada ou sada de nenhuma rota direta com relao ao trfego entre a internet e o ambiente de dados do portador do carto no esto autorizadas.

1.3.4 Implemente medidas contra falsificao para detectar e impedir que endereos IP de fonte falsificada entrem na rede. (Por exemplo, bloquear trfego originado da internet com um endereo de fonte interna).
1.3.4 Analise as configuraes do firewall e do roteador para verificar se as medidas contra falsificao esto implementadas, por exemplo, os endereos internos no conseguem passar da internet para a DMZ.
ORIENTAO
Normalmente, um pacote contm o endereo IP do computador que originalmente o enviou para que os outros computadores da rede saibam de onde vem o pacote. Indivduos mal-intencionados tentaro falsificar (ou copiar) o endereo de envio do IP para que o sistema alvo acredite que o pacote seja de uma fonte confivel. Filtrar pacotes que entram na rede ajuda, entre outras coisas, a garantir que os pacotes no sofram falsificao, parecendo que vm da prpria rede interna da organizao.
1.3.5No permita o trfego de sada no autorizado do ambiente de dados do portador do carto para a internet.
1.3.5 Analise as configuraes do firewall e do roteador para verificar se o trfego de sada do ambiente de dados do portador do carto para a internet est explicitamente autorizado.
Todo o trfego que sair do ambiente de dados do portador do carto dever ser avaliado para garantir que esteja de acordo com as regras autorizadas preestabelecidas. As conexes devero ser inspecionadas para restringir o trfego de forma a permitir apenas as comunicaes autorizadas (por exemplo restringindo portas/endereos de origem/destino ou bloqueando o contedo). Um firewall que executa inspeo de pacotes com status mantm o status (ou estado) de cada conexo atravs do firewall. Mantendo o "status", o firewall sabe se uma resposta aparente a uma conexo anterior realmente uma resposta vlida e autorizada (j que ele preserva cada status de conexo) ou se trfego mal-intencionado tentando enganar o firewall para que este permita a conexo.
1.3.6 Implemente inspeo com status, tambm conhecida como filtragem de pacote dinmico. (Ou seja, somente conexes "estabelecidas" so permitidas na rede.)
1.3.6 Analise as configuraes do firewall e do roteador para verificar se o firewall desempenha a inspeo com status (filtragem de pacote dinmica). (Somente conexes estabelecidas devem ser permitidas a entrar e somente se estiverem associadas a alguma sesso previamente estabelecida.)

1.3.7 Implemente os componentes do sistema que armazenam dados do portador do carto (como banco de dados) em uma zona de rede interna, separada da DMZ e de outras redes no confiveis.
1.3.7 Analise as configuraes do firewall e do roteador para verificar se os componentes do sistema que armazenam dados do portador do carto esto em uma zona de rede interna, separada da DMZ e de outras redes no confiveis.
ORIENTAO
Se os dados do portador do carto estiverem localizados dentro da DMZ, o acesso a essas informaes ser mais fcil para um invasor externo, pois h poucas camadas a serem penetradas. Proteger os componentes do sistema que armazenam os dados do portador do carto em uma zona de rede interna separada da DMZ e de outras redes no confiveis com um firewall pode evitar que um trfego de rede no autorizado alcance o componente do sistema. Observao: Este requisito no se aplica ao armazenamento temporrio dos dados do portador do carto em memria voltil.
1.3.8 No divulgue endereos IP privados e informaes de roteamento a partes no autorizadas. Observao: Os mtodos para ocultar o endereo IP podem incluir, entre outros: Converso de endereos de rede (NAT) Implementao dos servidores contendo dados do portador do carto atrs dos servidores de proxy/firewalls, 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.8.a Analise as configuraes do firewall e do roteador para verificar se os mtodos esto implementados para evitar a divulgao de endereos IP privados e informaes de roteamento das redes internas para a internet.
Restringir a divulgao de endereos IP internos ou privados essencial para evitar que os hackers "descubram" os endereos IP da rede interna e utilizem essas informaes para acessar a rede. Os mtodos usados para atender inteno deste requisito podem variar de acordo com a tecnologia de rede especfica utilizada. Por exemplo, os controles utilizados para atender a estes requisitos em redes IPv4 podero ser diferentes daqueles utilizados em redes IPv6.
1.3.8.b Questione os funcionrios e analise a documentao para verificar se qualquer divulgao de endereos IP privados e informaes de roteamento a entidades externas est autorizada.

1.4Instale o software de firewall pessoal em quaisquer dispositivos mveis e/ou de propriedade do funcionrio com conectividade internet quando estiverem fora da rede (por exemplo, laptops usados pelos funcionrios) e que tambm so usados para acessar a rede. As configuraes do firewall incluem: Os ajustes especficos de configurao so definidos pelo software do firewall pessoal. O software do firewall pessoal est funcionando ativamente. O software do firewall pessoal no pode ser alterado pelos usurios dos dispositivos mveis e/ou de propriedade do funcionrio.
1.4.aAnalise as polticas e padres de configurao para verificar: O software de firewall pessoal necessrio para todos os dispositivos mveis e/ou de propriedade do funcionrio com conectividade internet (por exemplo, laptops usados pelos funcionrios) quando esto fora da rede e que tambm so usados para acessar a rede. Os ajustes especficos de configurao so definidos pelo software do firewall pessoal. O software do firewall pessoal est configurado para funcionar ativamente. O software de firewall pessoal est configurado para no ser alterado pelos usurios de dispositivos mveis e/ou de propriedade do funcionrio. 1.4.b Inspecione uma amostra dos dispositivos mveis e/ou de propriedade do funcionrio para verificar se: O software de firewall pessoal instalado e configurado de acordo com os ajustes de configurao especficos da organizao. O software do firewall pessoal est funcionando ativamente. O software do firewall pessoal no pode ser alterado pelos usurios dos dispositivos mveis e/ou de propriedade do funcionrio. 1.5 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais do gerenciamento dos firewalls esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
ORIENTAO
Os dispositivos portteis de computao que tm permisso para conectar-se internet fora do firewall corporativo so mais vulnerveis s ameaas baseadas na internet. O uso de um firewall pessoal ajuda a proteger os dispositivos de invases via internet, o qual pode usar o dispositivo para obter acesso aos dados e sistemas da organizao, uma vez que o dispositivo reconectado rede. Os ajustes especficos das configuraes do firewall so determinados pela organizao. Observao: O objetivo deste requisito se aplica a computadores de propriedade do funcionrio e da empresa. Os sistemas que no podem ser gerenciados pelas polticas empresariais introduzem fraquezas ao permetro e oferecem oportunidades a pessoas mal-intencionadas. Permitir que sistemas no confiveis se conectem rede da organizao pode resultar em acesso garantido aos invasores e outros usurios malintencionados.
1.5 Certifique-se de que as polticas de segurana e procedimentos operacionais do gerenciamento dos firewalls estejam documentados, em uso e conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para garantir que os firewalls e roteadores sejam continuamente gerenciados a fim de evitar o acesso no autorizado rede.
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.

2.1 Sempre altere os padres disponibilizados pelo fornecedor e remova ou desabilite contas padro desnecessrias antes de instalar um sistema na rede. Isto se aplica a TODAS as senhas padro, incluindo, entre outros, as usadas pelos sistemas operacionais, software que oferece servios de segurana, aplicativos e contas de sistema, terminais de pontos de venda (POS), strings de comunidade SNMP (Simple Network Management Protocol), etc.).
2.1.a Escolha uma amostra dos componentes do sistema e tente acessar (com a ajuda do administrador do sistema) os dispositivos e aplicativos usando as contas e senhas padro disponibilizadas pelo fornecedor, para verificar se TODAS as senhas padro (incluindo as que esto nos sistemas operacionais, software que oferece servios de segurana, aplicativos e contas de sistema, terminais POS e strings de comunidade SNMP (Simple Network Management Protocol)) foram alteradas. (Use os manuais do fornecedor e as fontes na internet para localizar as contas/senhas disponibilizadas pelo fornecedor.) 2.1.b Para obter um exemplo dos componentes do sistema, verifique se todas as contas padro desnecessrias (incluindo contas usadas pelos sistemas operacionais, software de segurana, aplicativos, sistemas, terminais POS, SNMP, etc.) foram removidas ou desabilitadas. 2.1.c Questione os funcionrios e analise a documentao de suporte para verificar se: Todas as senhas padro (incluindo senhas padro em sistemas operacionais, software que oferece servios de segurana, aplicativos e contas do sistema, terminais POS, strings de comunidade SNMP (Simple Network Management Protocol), etc.)) so alteradas antes de um sistema ser instalado na rede. Contas padro desnecessrias (incluindo contas usadas pelos sistemas operacionais, software de segurana, aplicativos, sistemas, terminais POS, SNMP, etc.) so removidas ou desabilitadas antes de um sistema ser instalado na rede.
ORIENTAO
Indivduos mal-intencionados (dentro e fora de uma empresa) com frequncia usam as configuraes, nomes de conta e senhas padro do fornecedor para comprometer o software do sistema operacional, aplicativos e os sistemas nos quais eles esto instalados. Por estas configuraes padro serem frequentemente publicadas e bem conhecidas nas comunidades de hackers, alterar estas configuraes deixar os sistemas menos vulnerveis a invases. Mesmo se uma conta padro no tem o objetivo de ser usada, alterar a senha padro para uma senha forte e exclusiva e ento desabilitar a conta evitar que um indivduo mal-intencionado reabilite a conta e obtenha acesso com a senha padro.

2.1.1 Em ambientes sem fio conectados ao ambiente de dados do portador do carto ou que transmitam dados do portador do carto, altere TODOS os padres do fornecedor sem fio na instalao, incluindo, entre outros, chaves de criptografia sem fio padro, senhas e strings de comunidades de SNMP.
2.1.1.a Questione os funcionrios responsveis e analise a documentao de suporte para verificar se: As chaves de criptografia foram modificadas a partir do padro na instalao As chaves de criptografia padro so modificadas sempre que um funcionrio que conhece as chaves sai da empresa ou troca de cargo. 2.1.1.b Questione os funcionrios e consulte a as polticas e procedimentos para verificar se: As strings de comunidades de SNMP padro precisam ser modificadas na instalao. As senhas/frases padro nos pontos de acesso precisam ser modificadas na instalao. 2.1.1.c Consulte a documentao do fornecedor e conecte-se aos dispositivos sem fio, com a ajuda do administrador do sistema, para verificar se: As strings de comunidades de SNMP padro no so utilizadas. As senhas padro dos pontos de acesso no so utilizadas. 2.1.1.d Consulte a documentao do fornecedor e observe os ajustes da configurao sem fio para verificar se o firmware nos dispositivos sem fio foi atualizado para ser compatvel com a criptografia forte para: Autenticao em redes sem fio Transmisso em redes sem fio. 2.1.1.e Analise a documentao do fornecedor e observe os ajustes da configurao sem fio para verificar se outros padres sem fio do fornecedor ligados segurana foram alterados, se aplicvel.
ORIENTAO
Se as redes sem fio no forem implementadas com configuraes de segurana suficientes (incluindo a alterao das configuraes padro), os sniffers da rede sem fio conseguem espreitar o trfego, capturar dados e senhas e entrar e invadir a sua rede com facilidade. Alm disso, o protocolo de troca de chaves para verses mais antigas da criptografia 802.11x (Wired Equivalent Privacy ou WEP) foi quebrado e pode tornar a criptografia intil. O firmware dos dispositivos deve estar atualizado para suportar protocolos mais seguros.

2.2 Desenvolva padres de configurao para todos os componentes do sistema. Certifique-se de que esses padres abrangem todas as vulnerabilidades de segurana conhecidas e esto em conformidade com os padres de fortalecimento do sistema aceitos pelo setor. As fontes dos padres de proteo do sistema aceitos pelo setor podem incluir, entre outros: 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.a Analise 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 Analise as polticas e questione os funcionrios para verificar se os padres de configurao do sistema esto atualizados conforme novos problemas de vulnerabilidade so identificados, conforme definido no Requisito 6.1. 2.2.c Analise as polticas e questione os funcionrios para verificar se os padres de configurao do sistema so aplicados quando novos sistemas so configurados e considerados adequados antes de o sistema ser instalado na rede. 2.2.d Verifique se os padres de configurao do sistema incluem os seguintes procedimentos para todos os tipos de componentes do sistema: Alterao de todos os padres informados pelo fornecedor e eliminao de contas padro desnecessrias Implementao de apenas uma funo principal por servidor para evitar funes que exigem diferentes nveis de segurana coexistindo no mesmo servidor Habilitar apenas servios, protocolos, daemons, etc. necessrios, conforme exigido para a funo do sistema Implantar recursos de segurana adicionais para todos os servios, protocolos ou daemons exigidos que forem considerados no seguros Configurar os parmetros de segurana do sistema para impedir o uso incorreto Remover todas as funcionalidades desnecessrias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores Web desnecessrios.
ORIENTAO
Existem pontos fracos conhecidos em vrios sistemas operacionais, bancos de dados e aplicativos empresariais, alm disso existem tambm formas conhecidas de configurar esses sistemas para corrigir as vulnerabilidades de segurana. Para ajudar quem no especialista em segurana, as organizaes de segurana criaram recomendaes e orientaes para proteo do sistema que aconselham como corrigir esses pontos fracos. Exemplos de fontes para orientao sobre padres de configurao incluem, entre outros: www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org e fornecedores do produto. Os padres de configurao do sistema devero ser mantidos atualizados para garantir que as deficincias recentemente identificadas sejam corrigidas antes de o sistema ser instalado na rede.

2.2.1Implemente somente uma funo principal por servidor para evitar funes que exigem diferentes nveis de segurana coexistindo no mesmo servidor. (Por exemplo, servidores 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.
2.2.1.a Selecione uma amostra dos componentes do sistema e inspecione as configuraes do sistema para verificar se somente uma funo principal est implementada por servidor. 2.2.1.bSe forem usadas tecnologias de virtualizao, inspecione as configuraes do sistema para verificar se somente uma funo principal est implementada por componente ou dispositivo do sistema virtual.
ORIENTAO
Se funes do servidor que precisam de diferentes nveis de segurana estiverem localizadas no mesmo servidor, o nvel de segurana das funes com maior necessidade de segurana pode ser reduzido devido presena das funes de menor segurana. Alm disso, as funes do servidor com menor nvel de segurana podem apresentar falhas da segurana para outras funes no mesmo servidor. Considerando as necessidades de segurana de diferentes funes do servidor como parte dos padres de configurao do sistema e processos relacionados, as organizaes podem garantir que as funes que exigem diferentes nveis de segurana no coexistam no mesmo servidor. Conforme informado no item 1.1.6, existem muitos protocolos de que uma empresa pode precisar (ou estarem ativados por padro) que normalmente so usados por indivduos malintencionados para comprometer uma rede. Incluir este requisito como parte dos padres de configurao da empresa e dos processos relacionados garante que apenas os servios e protocolos necessrios sejam habilitados. Habilitar recursos de segurana antes que novos servidores sejam implantados evitar que os servidores sejam instalados no ambiente com configuraes no seguras. Garantir que todos os servios, protocolos e daemons no seguros estejam adequadamente protegidos com recursos de segurana apropriados dificulta que indivduos malintencionados se aproveitem dos pontos de comprometimento normalmente usados dentro de uma rede.
2.2.2 Habilite somente servios, protocolos, daemons, etc., necessrios para a funo do sistema.
2.2.2.a Selecione uma amostra dos componentes do sistema e inspecione os servios, daemons e protocolos do sistema ativado para verificar se apenas os servios ou protocolos necessrios esto habilitados. 2.2.2.b Identifique qualquer servio, daemons ou protocolos no seguros que estejam habilitados e questione os funcionrios para verificar se eles tm justificativa conforme os padres de configurao documentados.
2.2.3 Implemente recursos de segurana adicionais para quaisquer servios, protocolos ou daemons considerados no seguros, por exemplo, utilize tecnologias seguras, como SSH, S-FTP, SSL ou IPSec VPN para proteger servios no seguros como o NetBIOS, file-sharing, Telnet, FTP, etc.
2.2.3Inspecione os ajustes de configurao para verificar se os recursos de segurana esto documentados e implementados para todos os servios, daemons ou protocolos no seguros.

2.2.4 Configure os parmetros de segurana do sistema para impedir o uso incorreto.
2.2.4.a Questione 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.
ORIENTAO
Os padres de configurao do sistema de sua organizao e os processos relacionados devem abordar especificamente as configuraes e os parmetros de segurana que tenham implicaes de segurana conhecidas para cada tipo de sistema em uso. (Continua na prxima pgina)
2.2.4.b Analise os padres de configurao do sistema para verificar se as configuraes comuns dos parmetros de segurana esto includas. 2.2.4.c Selecione uma amostra dos componentes do sistema e inspecione os parmetros comuns de segurana para verificar se eles esto ajustados corretamente e de acordo com os padres de configurao.
Para que os sistemas sejam configurados corretamente, os funcionrios responsveis pela configurao e/ou administrao dos sistemas devem ter conhecimento dos parmetros especficos de segurana e ajustes que se aplicam ao sistema. Funes desnecessrias podem gerar oportunidades adicionais para indivduos malintencionados obterem acesso ao sistema. Removendo funcionalidades desnecessrias, as organizaes podem se concentrar em proteger as funes exigidas e reduzir o risco de funes desconhecidas serem aproveitadas. Incluir isto nos padres de proteo do servidor e processos resolve as implicaes de segurana especficas associadas a funes desnecessrias (por exemplo, removendo/desativando FTP ou o servidor Web, caso o servidor no execute essas funes). Se a administrao que no utiliza console (incluindo remota) no usa autenticao segura e comunicaes criptografadas, informaes confidenciais de nvel administrativo ou operacional (como as senhas e IDs do administrador) podero ser reveladas a um espio. Um indivduo mal-intencionado pode usar essas informaes para acessar a rede, tornar-se Pgina 32 Novembro de 2013
2.2.5 Remova todas as funcionalidades desnecessrias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores Web desnecessrios.
2.2.5.a Selecione uma amostra dos componentes do sistema e inspecione as configuraes para verificar se todas as funcionalidades desnecessrias (por exemplo, scripts, drivers, recursos, subsistemas, sistemas de arquivo, etc.) foram removidas. 2.2.5.b. Consulte a documentao e os parmetros de segurana para verificar se as funes ativadas esto documentadas e suportam a configurao segura. 2.2.5.c. Consulte a documentao e os parmetros de segurana para verificar se somente as funcionalidades registradas esto presentes nos componentes do sistema da amostra.
2.3 Criptografe todo o acesso administrativo que no utiliza console durante a criptografia forte. Com o uso tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento com base na Web e outros acessos administrativos que no utilizam console.
2.3Selecione uma amostra dos componentes do sistema e verifique se o acesso administrativo que no utiliza console criptografado realizando o que segue: 2.3.a Observe um administrador efetuar logon em cada sistema e analise as configuraes do sistema para verificar se o mtodo de criptografia forte invocado 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 logon remoto no seguros no esto disponveis para o acesso que no utiliza console. 2.3.c Observe um administrador efetuar logon em cada sistema para verificar se o acesso do administrador s interfaces de gerenciamento baseadas na Web criptografado com criptografia forte. 2.3.d Analise a documentao do fornecedor e questione os funcionrios para verificar se a criptografia forte para a tecnologia utilizada est implementada de acordo com as melhores prticas do setor e/ou recomendaes do fornecedor.
ORIENTAO
administrador e roubar os dados. Protocolos de texto simples (como HTTP, telnet, etc.) no criptografam detalhes de trfego ou acesso, facilitando que um espio intercepte estas informaes. Para serem considerados com "criptografia forte", os protocolos reconhecidos pelo setor com resistncias de chave adequadas e gerenciamento de chave devem estar corretos conforme aplicvel para o tipo de tecnologia utilizada. (Consulte criptografia forte no Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS .) Manter uma lista atual de todos os componentes do sistema permite que a organizao defina de forma precisa e eficaz o escopo de seu ambiente para implementar os controles do PCI DSS. Sem uma relao, alguns componentes do sistema podem ser esquecidos e excludos sem querer dos padres de configurao da organizao. Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais dirios para garantir que os padres do fornecedor e outros parmetros de segurana sejam continuamente gerenciados a fim de evitar configuraes no seguras.
2.4 Mantenha uma relao dos componentes do sistema que esto no escopo do PCI DSS.
2.4.a Analise a relao do sistema para verificar se uma lista de componentes de hardware e software mantida e se inclui uma descrio da funo/uso de cada um deles. 2.4.b Questione os funcionrios para verificar se uma relao documentada mantida no momento.
2.5 Certifique-se de que as polticas de segurana e procedimentos operacionais do gerenciamento dos padres do fornecedor e outros parmetros de segurana estejam documentados, em uso e conhecidos por todas as partes envolvidas. 2.6Os provedores de hospedagem compartilhada devem proteger cada ambiente hospedado da entidade e os dados do portador 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.5 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais do gerenciamento dos padres do fornecedor e outros parmetros de segurana esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas. 2.6 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).
Isso serve para provedores de hospedagem que oferecem ambientes de hospedagem compartilhada para vrios clientes no mesmo servidor. Quando todos os dados estiverem no mesmo servidor e sob o controle de um nico ambiente, as configuraes nestes servidores compartilhados frequentemente no so gerenciveis pelos clientes individuais. Isto permite que os clientes adicionem funes e Pgina 33 Novembro de 2013
ORIENTAO
scripts no seguros que causam impacto na segurana de todos os outros ambientes de clientes e, assim, facilitando para um indivduo mal-intencionado comprometer os dados de um cliente, obtendo acesso a todos os dados dos outros clientes. Consulte o Apndice A para saber detalhes sobre os requisitos.
Proteger os dados do portador do carto

Requisito 3: Proteger os dados armazenados do portador 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 tambm devem ser considerados como oportunidades potenciais de minimizao dos riscos. Por exemplo, os mtodos para minimizar os riscos incluem no armazenar os dados do portador 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 forte" e outros termos do PCI DSS. REQUISITOS DO PCI DSS
3.1Mantenha a armazenagem dos dados do portador do carto o mnimo possvel, implementando polticas, processos e procedimentos de reteno e descarte de dados que incluem pelo menos o que segue para todo o armazenamento dos dados do portador do carto (CHD): 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 portador do carto
3.1.aAnalise as polticas, processos e procedimentos de reteno e descarte de dados para verificar se eles incluem pelo menos o que segue: Requisitos legais, regulamentares e comerciais para reteno de dados, incluindo Requisitos especficos quanto reteno de dados do portador do carto (por exemplo, os dados do portador do carto precisam ser retidos por um perodo X por razes comerciais Y). Excluso segura dos dados do portador do carto que no so mais necessrios por motivos legais, regulamentares ou comerciais Abrangncia de todo o armazenamento dos dados do portador do carto Processos trimestrais para identificar e excluir com segurana os dados do portador do carto que excederem os requisitos de reteno definidos.
ORIENTAO
Polticas formais de reteno de dados identificam quais dados precisam ser retidos e onde ficam, de forma a serem excludos ou destrudos com segurana assim que no forem mais necessrios. Os nicos dados do portador do carto que podem ser armazenados so o nmero da conta principal ou PAN (desde que ilegvel), data de vencimento, nome do portador do carto e cdigo de servio. necessrio saber onde os dados do portador do carto esto localizados para que estes sejam retidos ou descartados corretamente quando no forem mais necessrios. Para definir os requisitos de reteno adequados, a empresa dever primeiro conhecer suas necessidades de negcios, bem como as responsabilidades legais

Processos trimestrais para identificar e excluir com segurana os dados do portador do carto que excederem a reteno definida.
3.1.b Questione os funcionrios para verificar se: Todos os locais de armazenamento dos dados do portador do carto esto includos nos processos de reteno e descarte de dados. Um processo trimestral manual ou automtico est implantado para identificar e excluir com segurana os dados do portador do carto. O processo trimestral manual ou automtico realizado para todos os locais de dados do portador do carto. 3.1.c Para obter uma amostra dos componentes do sistema que armazenam dados do portador do carto: Analise os arquivos e registros do sistema para verificar se os dados armazenados no excedem os requisitos definidos na poltica de reteno Observe o mecanismo de excluso para verificar se os dados so excludos de forma segura.
ORIENTAO
e regulamentares que se aplicam setor ou ao tipo dos dados que sero retidos. (Continua na prxima pgina)
Identificar e excluir dados armazenados que tenham excedido seu perodo de reteno especificado evita a reteno de dados que no so mais necessrios. Este processo pode ser automtico ou manual ou uma combinao dos dois. Por exemplo, um procedimento programtico (automtico ou manual) para localizar e remover dados e/ou uma reviso manual de reas de armazenamento de dados pode ser realizado. Implementar mtodos de excluso seguros garante que os dados no podero ser recuperados quando no forem mais necessrios. Lembre-se: se voc no precisar, no os armazene!
3.2 No armazenar dados de autenticao confidenciais aps a autorizao (mesmo se estiverem criptografados). Se forem recebidos dados de autenticao confidenciais, processe todos os dados irrecuperveis ao completar o processo de autorizao. O armazenamento de dados de
3.2.a Para os emissores e/ou empresas que suportam servios de emisso e armazenam dados de autenticao confidenciais, revise as polticas e questione os funcionrios para verificar se h justificativa comercial documentada para o armazenamento de dados de autenticao confidenciais.
Os dados de autenticao confidenciais so formados por dados de rastreamento completo, cdigo ou valor de validao do carto e dados do PIN. O armazenamento de dados de autenticao confidenciais aps a autorizao proibido! Esses dados so muito valiosos para indivduos mal-intencionados, pois permitem falsificar cartes de pagamento e criar transaes fraudulentas.

autenticao confidenciais permitido aos emissores e empresas que suportam servios de emisso se: Houver uma justificativa comercial e Os dados so armazenados com segurana. Os dados de autenticao confidenciais incluem os dados conforme mencionados nos seguintes Requisitos 3.2.1 at 3.2.3:
3.2.b Para os emissores e/ou empresas que suportam servios de emisso e armazenam dados de autenticao confidenciais, analise o armazenamento de dados e configuraes do sistema para verificar se os dados de autenticao confidenciais esto seguros. 3.2.c Para todas as outras entidades, se dados de autenticao confidenciais forem recebidos, revise as polticas e procedimentos e analise as configuraes do sistema para verificar se os dados no esto retidos aps a autorizao.
ORIENTAO
As entidades que emitem cartes de pagamento ou que desempenham ou suportam servios de emisso, frequentemente criaro e controlaro os dados de autenticao confidenciais como parte da funo de emisso. As empresas que executam, facilitam ou suportam servios de emisso tm permisso para armazenar dados de autenticao confidenciais SOMENTE SE apresentarem legtima necessidade de negcios para armazenar esses dados. Deve-se observar que todos os requisitos de PCI DSS se aplicam aos emissores e a nica exceo para emissores e processadores de emisses que os dados de autenticao confidenciais podero ficar retidos se houver uma razo legtima para tanto. Razo legtima aquela necessria para o desempenho da funo fornecida para o emissor e no de convenincia. Esses dados devero ser armazenados com segurana e de acordo com o PCI DSS e os requisitos especficos da empresa de pagamento.
3.2.d Para todas as outras entidades, se dados de autenticao confidenciais forem recebidos, revise os procedimentos e analise os processos de excluso dos dados para verificar se os dados so irrecuperveis.
Para entidades que no executam servios de emisso, no permitido reter os dados de autenticao confidenciais aps a autenticao.

3.2.1 No armazene o contedo completo de qualquer rastreamento (da tarja magntica localizada na parte posterior do carto, em dados equivalentes constando no chip ou outro local). Esses dados tambm so denominados como rastreamento completo, rastreamento, rastreamento 1, rastreamento 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 portador 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 armazene 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 sem o carto.
3.2.1 Para obter uma amostra dos componentes do sistema, analise as fontes de dados, inclusive, entre outros, o que segue e verifique se o contedo completo de qualquer rastreamento da tarja magntica na parte posterior do carto ou dados equivalentes em um chip no so armazenados aps a autorizao: Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastreamento Vrios esquemas do banco de dados Contedo de bancos de dados.
ORIENTAO
Se os dados de rastreamento completo forem armazenados, os indivduos mal-intencionados que obtiverem esses dados podero reproduzir os cartes de pagamento e realizar transaes fraudulentas.
3.2.2Para obter uma amostra dos componentes do sistema, analise as fontes dos dados, inclusive, entre outros, o 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 aps a autorizao: Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastreamento Vrios esquemas do banco de dados Contedo de bancos de dados.
O objetivo do cdigo de validao do carto proteger as transaes do tipo "carto no presente", aquelas feitas por internet, por correio ou telefone (MO/TO), nas quais o consumidor e o carto no esto presentes. Se esses dados forem roubados, indivduos malintencionados podem executar transaes fraudulentas pela internet e por MO/TO.

3.2.3 No armazene o PIN (Personal Identification Number) ou o bloco de PIN criptografado.
3.2.3Para obter uma amostra dos componentes do sistema, analise as informaes a seguir e verifique se os PINs e blocos de PIN criptografados no so armazenados aps a autorizao: Dados de transao de entrada Todos os registros (por exemplo, transao, histrico, depurao, erro) Arquivos do histrico Arquivos de rastreamento Vrios esquemas do banco de dados Contedo de bancos de dados.
ORIENTAO
Esses valores s devem ser conhecidos pelo proprietrio do carto ou pelo banco que emitiu o carto. Se esses dados forem roubados, indivduos mal-intencionados podem executar transaes fraudulentas de dbito protegidas por senha (por exemplo, saques em caixas eletrnicos).
3.3 Mascare o PAN quando exibido (os primeiros seis e quatro ltimos dgitos so o nmero mximo de dgitos a serem exibidos), como no caso em que apenas funcionrios com necessidade comercial legtima podem visualizar o PAN completo. Observao: Esse requisito no substitui os requisitos mais rigorosos em vigor quanto s exibies dos dados do portador do carto, por exemplo, requisitos legais ou da bandeira do carto de pagamento para recebimentos do ponto de venda (POS).
3.3.a Analise as polticas e procedimentos escritos sobre a mascaragem da exibio de PANs para verificar se: Uma lista de funes que precisam acessar as exibies do PAN completo est documentada, junto com uma necessidade comercial legtima para que cada funo tenha este acesso. O PAN deve ser mascarado quando exibido, como no caso em que apenas funcionrios com necessidade comercial legtima podem ver o PAN completo. Todas as outras funes no autorizadas especificamente para visualizar o PAN completo devem visualizar apenas os PANs mascarados. 3.3.b Analise as configuraes do sistema para verificar se o PAN completo exibido apenas para usurios/funes com uma necessidade comercial documentada e que o PAN esteja mascarado para todas as outras solicitaes. 3.3.c Analise as exibies do PAN (por exemplo, na tela, em recibos) para verificar se os PANs esto mascarados ao exibir os dados do portador do carto e que apenas as pessoas que tenham uma necessidade comercial legtima possam visualizar o PAN completo.
A exibio do PAN completo em locais como telas de computador, recibos de carto de pagamento, faxes ou extratos em papel pode fazer com que esses dados sejam obtidos por indivduos no autorizados e usados de forma fraudulenta. Garantir que o PAN completo seja exibido apenas para aqueles com necessidade comercial legtima de visualizar o PAN completo minimiza o risco de pessoas no autorizadas obterem acesso aos dados do PAN. Este requisito est relacionado proteo do PAN exibida em telas, recibos, impresses, etc. e no deve ser confundido com o Requisito 3.4 para proteo do PAN quando armazenado em arquivos, bancos de dados, etc.

3.4Torne o PAN ilegvel em qualquer local onde ele esteja armazenado (inclusive em mdia digital porttil, mdia de backup e em registros) utilizando qualquer uma das seguintes abordagens: Hash de direo nica com base na criptografia forte (o hash deve ser do PAN inteiro) Truncamento (a codificao hash no pode ser usada para substituir o segmento truncado do PAN) Tokens e blocos de ndice (os blocos devem ser armazenados de forma segura) Criptografia forte com processos e procedimentos de gerenciamentochave associados.
3.4.a 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) para verificar se o PAN apresentado ilegvel, usando qualquer um dos mtodos a seguir: Codificao hash de direo nica com base na criptografia forte, Truncamento Tokens e blocos de ndice, sendo que os blocos so armazenados de forma segura Criptografia forte 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). 3.4.cAnalise um exemplo de mdia removvel (por exemplo, fitas de backup) paa confirmar se o PAN foi tornado ilegvel.
ORIENTAO
Os PANs armazenados no armazenamento principal (bancos de dados ou arquivos simples, como arquivos de texto e planilhas), alm de armazenamento no principal (backup, logs de auditoria, logs de exceo ou de resoluo de problemas) devem todos estar protegidos. Funes de hash de direo nica baseadas em uma criptografia forte podem ser usadas para deixar os dados do portador do carto ilegveis. As funes de condificao de hash so adequadas quando no houver necessidade de recuperar o nmero original (o hash de direo nica irreversvel). Recomenda-se, mas no um requisito atual, que um valor de entrada adicional e aleatrio seja adicionado aos dados do portador do carto antes da codificao hash para reduzir a possibilidade de um invasor comparar os dados com (e produzir o PAN a partir das) tabelas de valores de hash pr-

Observao: um esforo relativamente simples para um indivduo mal-intencionado reconstituir os dados do PAN original caso ele tenha acesso s verses truncadas e hash do PAN. Quando as verses truncada e hash do mesmo PAN estiverem presentes no ambiente de uma entidade, controles adicionais devero ser implantados para assegurar que as verses truncada e hash no sejam correlacionadas para reconstituir o PAN original.
3.4.d Analise uma amostra de logs de auditoria para confirmar se o PAN tornou-se ilegvel ou foi removido dos logs. computados.
ORIENTAO
O objetivo do truncamento que somente uma parte (sem exceder os primeiro seis e os ltimos quatro dgitos) do PAN seja armazenado. Um token de ndice um token criptogrfico que substitui o PAN com base em um determinado ndice para um valor imprevisvel. Um pad de uso nico um sistema no qual uma chave privada gerada aleatoriamente usada s uma vez para criptografar uma mensagem que ento descodificada usando um pad e uma chave de uso nico correspondentes. O objetivo da criptografia forte (conforme definido noGlossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS) que a criptografia se baseie em um algoritmo testado e aceito pela empresa (no um algoritmo feito em casa) com chaves de criptografia forte. Ao correlacionar as verses de hash e truncada de um determinado PAN, um indivduo malintencionado poder facilmente derivar o valor do PAN original. Os controles que evitam a correlao desses dados ajudaro a garantir que o PAN original permanea ilegvel.
3.4.1 Se a criptografia de dados for utilizada (em vez da criptografia de bancos de dados no nvel de arquivo ou coluna), o acesso lgico deve ser gerenciado separadamente e independentemente de mecanismos de controle de acesso e autenticao do sistema operacional nativo (por exemplo, no utilizando bancos de dados de contas de usurio locais ou credenciais gerais de logon da rede). Chaves de decodificao no devem estar associadas a contas de usurios.
3.4.1.a Se a criptografia de dados for usada, inspecione a configurao e observe o processo de autenticao para verificar se o acesso lgico aos sistemas de arquivos criptografados foi implementado por meio de um mecanismo que seja separado do mecanismo de autenticao do sistema operacional nativo (por exemplo, no usando os bancos de dados das contas de usurio locais ou credenciais gerais de logon da rede). 3.4.1.bObserve os processos e questione os funcionrios para verificar se as chaves criptogrficas so armazenadas de forma segura (por exemplo, armazenadas nas mdias removveis que esto protegidas adequadamente com controles de acesso robustos).
O objetivo deste requisito abordar a aceitabilidade da criptografia no nvel de disco para deixar os dados do portador do carto ilegveis. A criptografia no nvel de disco codifica todas os discos/divises em computador e descodifica automaticamente as informaes quando um usurio autorizado as solicita. Muitas solues de criptografia de dados interceptam as operaes de leitura/gravao do sistema operacional e executam as transformaes criptogrficas adequadas sem nenhuma ao especial por parte do usurio, alm de fornecer uma senha ao ligar o sistema ou no incio de uma sesso. Com base nessas caractersticas de Pgina 41 Novembro de 2013
3.4.1.c Analise as configuraes e observe os processos para verificar se os dados do portador do carto nas mdias removveis esto criptografados onde quer que estejam armazenados. Observao: Se a criptografia de dados no for usada para criptografar a mdia removvel, os dados armazenados nessa mdia devero ser tornados ilegveis por meio de outro mtodo.
ORIENTAO
criptografia no nvel de disco, a fim de atender a esse requisito, o mtodo no pode: 1) 2) Utilizar o mesmo autenticador de conta do usurio que o sistema operacional, ou Utilizar uma chave de descodificao associada com ou derivada do banco de dados da conta do usurio local do sistema ou credenciais gerais de logon da rede.
A criptografia de dados completa ajuda a proteger os dados no caso de perda de um disco e, portanto, pode ser apropriada para dispositivos portteis que armazenam dados do portador do carto. 3.5 Registre e implemente os procedimentos para proteger as chaves utilizadas para armazenar de forma segura os dados do portador do carto em relao a divulgaes ou mau uso: Observao: Esse requisito se aplica a chaves usadas para proteger os dados armazenados do portador do carto e tambm a chaves de criptografia de dados, essas chaves de criptografia de chaves devem ser ao menos to fortes quanto as chaves de criptografia de dados. 3.5 Analise as polticas e procedimentos de gerenciamento de chave para verificar se os processos esto especificados para proteger as chaves usadas para a criptografia dos dados do portador do carto contra a divulgao e o uso incorreto e se incluem pelo menos o que segue: O acesso s chaves est restrito ao menor nmero necessrio de responsveis pela proteo. As chaves de criptografia de chaves so to fortes quanto as chaves de criptografia de dados que protegem. As chaves de criptografia de chaves so armazenadas separadamente das chaves de criptografia. As chaves so armazenadas de forma segura no menor nmero possvel de locais e formatos. As chaves criptogrficas devem ser muito bem protegidas, pois quem tiver acesso a elas conseguir decodificar os dados. As chaves de criptografia de chaves, se utilizadas, devero ser ao menos to fortes quanto as chaves de criptografia de dados para garantir a proteo adequada da chave que criptografa os dados e dos dados criptografados por essa chave. O requisito para proteger chaves da divulgao e do uso indevido se aplica tanto s chaves de criptografia de dados quanto s chaves de criptografia de chaves. Como uma chave de criptografia de chaves poder conceder direito de acesso a vrias chaves de criptografia de dados, as chaves de criptografia de chaves necessitam de medidas de proteo vigorosas. Deve haver pouqussimas pessoas com acesso s chaves criptogrficas (reduzindo o potencial de deixar os dados do portador do carto visveis para pessoas no autorizadas), normalmente s aquelas com responsabilidades de custdia de chaves.
3.5.1Restrinja o acesso s chaves criptogrficas ao menor nmero necessrio de responsveis pela proteo.
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 Armazene chaves privadas e secretas usadas para criptografar/descodificar os dados do portador do carto em uma (ou mais) das formas a seguir em todos os momentos: Criptografadas com uma chave de criptografia de chaves que seja ao menos to forte quanto a chave de criptografia de dados e que esteja armazenada separadamente da chave de criptografia de dados. Dentro de um dispositivo criptogrfico seguro (como um mdulo de segurana de hospedagem (HSM) ou dispositivo PTS de interao de ponto aprovado) Como duas partes de chave ou componentes de chave de tamanho total, de acordo com um mtodo aceito pela empresa Observao: No exigido que chaves pblicas sejam armazenadas em uma destas formas.
3.5.2.a Analise os procedimentos documentados para verificar se as chaves criptogrficas usadas para criptografar/descodificar os dados do portador do carto devem existir em apenas uma (ou mais) das formas a seguir em todos os momentos. Criptografadas com uma chave de criptografia de chaves que seja ao menos to forte quanto a chave de criptografia de dados e que esteja armazenada separadamente da chave de criptografia de dados. Dentro de um dispositivo criptogrfico seguro (como um mdulo de segurana de hospedagem (HSM) ou dispositivo PTS de interao de ponto aprovado) Como partes de chave ou componentes de chave, de acordo com um mtodo aceito pela empresa 3.5.2.b Analise as configuraes do sistema e os locais de armazanamento de chave para verificar se as chaves criptogrficas usadas para criptografar/descodificar os dados do portador do carto existem em uma (ou mais) das formas a seguir em todos os momentos. Criptografadas com uma chave de criptografia de chave Dentro de um dispositivo criptogrfico seguro (como um mdulo de segurana de hospedagem (HSM) ou dispositivo PTS de interao de ponto aprovado) Como partes de chave ou componentes de chave, de acordo com um mtodo aceito pela empresa 3.5.2.c Onde quer que as chaves de criptografia de chave sejam usadas, analise as configuraes do sistema e os locais de armazenamento de chave para verificar se: As chaves de criptografia de chaves so to fortes quanto as chaves de criptografia de dados que protegem As chaves de criptografia de chaves so armazenadas separadamente das chaves de criptografia.
ORIENTAO
Chaves criptogrficas devem ser armazenadas com segurana para evitar o acesso no autorizado e desnecessrio que pode resultar na exposio dos dados do portador do carto. As chaves de criptografia de chaves no precisam ser criptografadas, mas devem ficar protegidas contra divulgao e uso indevido conforme definido no Requisito 3.5. Se forem usadas chaves de criptografia de chave, armazen-las em locais fisicamente e/ou logicamente separados das chaves de criptografia de dados reduz os riscos de acesso no autorizado s duas chaves.

3.5.3 Armazene chaves criptogrficas no menor nmero possvel de locais.
3.5.3 Analise os locais de armazenamento de chave e observe os processos para verificar se as chaves so armazenadas no menor nmero possvel de locais.
ORIENTAO
Armazenar chaves criptogrficas no menor nmero possvel de locais ajuda a organizao a acompanhar e monitorar todos os locais de chaves e minimiza o potencial das chaves serem expostas a pessoas no autorizadas. A forma como as chaves criptogrficas so gerenciadas parte essencial da segurana continuada da soluo de criptografia. Um bom processo de gerenciamento de chaves, seja ele manual ou automatizado, como parte do produto de criptografia, baseia-se nos padres do setor e aborda todos os elementos de chave em 3.6.1 a 3.6.8. Fornecer orientao aos clientes sobre como transmitir, armazenar e atualizar as chaves criptogrficas com segurana pode ajudar a evitar que as chaves sejam mal administradas ou divulgadas a entidades no autorizadas. Este requisito se aplica s chaves utilizadas para criptografar os dados do portador do carto armazenados e a qualquer chave de criptografia de chaves respectiva.
3.6 Documente e implemente por completo todos os processos e procedimentos de gerenciamento de chave com relao s chaves criptogrficas usadas para a criptografia dos dados do portador do carto, incluindo o seguinte: Observao: Vrios padres do setor para o gerenciamento-chave esto disponveis a partir de diversos recursos, incluindo NIST, que pode ser encontrado em http://csrc.nist.gov.
3.6.a Procedimento de teste adicional para prestadores de servios: Se o prestador de servios compartilhar chaves com seus clientes para a transmisso ou armazenamento de dados do portador do carto, analise a documentao que o prestador de servios fornece aos clientes para verificar se ela inclui uma orientao sobre como transmitir, armazenar e atualizar as chaves do cliente de forma segura, de acordo com os Requisitos 3.6.1 a 3.6.8 abaixo. 3.6 Analise os processos e procedimentos de gerenciamento de chave com relao s chaves usadas para a criptografia dos dados do portador do carto e faa o seguinte:
3.6.1 Gerao de chaves criptogrficas fortes
3.6.1.a Verifique se os procedimentos de gerenciamentochave especificam como gerar chaves fortes. 3.6.1.b Observe o mtodo de gerao de chaves para verificar se chaves fortes so geradas.
A soluo de criptografia deve gerar chaves fortes, conforme definido no Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS, em "criptografia forte". O uso de chaves criptogrficas fortes aumenta significativamente o nvel de segurana dos dados criptografados do portador do carto. A soluo de criptografia deve distribuir as chaves de forma segura, o que significa que as chaves so distribudas somente para os responsveis identificados em 3.5.1 e nunca distribudas sem limitao. A soluo de criptografia deve armazenar as chaves com segurana, por exemplo, Pgina 44 Novembro de 2013
3.6.2 Distribuio segura da chave criptogrfica
3.6.2.a Verifique se os procedimentos de gerenciamentochave especificam como distribuir chaves de forma segura. 3.6.2.b Observe o mtodo de distribuio de chaves para verificar se elas so distribudas de forma segura.
3.6.3 Armazenamento seguro de chaves criptogrficas
3.6.3.a Verifique se os procedimentos de gerenciamentochave especificam como armazenar chaves de forma segura.
3.6.3.b Observe o mtodo de armazenamento das chaves para verificar se elas esto armazenadas com segurana.
ORIENTAO
criptografando-as com uma chave de criptografia. Armazenar as chaves sem proteo adequada pode dar acesso aos invasores, resultando na descodificao e exposio dos dados do portador do carto. Um criptoperodo o tempo transcorrido durante o qual uma determinada chave de criptografia poder ser utilizada para seus devidos fins. As consideraes para definir o criptoperodo incluem, entre outros, a fora do algoritmo em destaque, o tamanho ou o comprimento da chave, o risco de comprometimento da chave e a confidencialidade dos dados a serem criptografados. A troca peridica das chaves de criptografia ao atingirem o criptoperodo essencial para minimizar o risco de algum obter as chaves de criptografia e us-las para decodificar os dados.
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.4.a Verifique se os procedimentos de gerenciamentochave incluem um criptoperodo definido para cada tipo de chave em uso e se define um processo para modificaes de chave no final do criptoperodo definido. 3.6.4.b Questione os funcionrios para verificar se as chaves so modificadas no final do criptoperodo definido.
3.6.5 Inutilizao ou substituio (por exemplo, arquivamento, destruio e/ou revogao) de chaves consideradas necessrias quando a integridade da chave estiver enfraquecida (por exemplo, sada de um funcionrio com conhecimento sobre um componente de chave de texto simples) ou quando houver suspeita de que a chave esteja comprometida. Observao: Caso chaves criptogrficas inutilizadas ou recolocadas precisarem ser retidas, essas chaves
3.6.5.a Verifique se os procedimentos de gerenciamentochave especificam processos para o que segue: A inutilizao ou substituio de chaves quando sua integridade tiver sido enfraquecida A substituio de chaves que estejam sabidamente ou potencialmente comprometidas. Qualquer chave mantida aps a inutilizao ou substituio no so utilizadas para operaes de criptografia 3.6.5.b Questione os funcionrios para verificar se os seguintes processos esto implementados: As chaves so inutilizadas ou substitudas quando sua integridade tenha sido enfraquecida, incluindo quando
Chaves que no so mais usadas nem necessrias ou chaves que se sabe ou so suspeitas de estarem comprometidas devem ser inutilizadas e/ou destrudas para garantir que no possam mais ser usadas. Se for necessrio mant-las (para usar com dados arquivados e criptografados, por exemplo), elas devero ser muito bem protegidas. A soluo de criptografia deve fornecer e facilitar o processo para substituir as chaves que estejam no prazo de substituio, ou sabidamente ou potencialmente comprometidas.

devero ser arquivadas em segurana (por exemplo, usando uma chave de criptografia de chaves). Chaves criptogrficas arquivadas devem ser usadas somente para fins de decodificao/verificao.
algum com conhecimento sobre a chave sai da empresa. As chaves so substitudas se estiverem sabidamente ou potencialmente comprometidas. Qualquer chave mantida aps a inutilizao ou substituio no so utilizadas para operaes de criptografia. 3.6.6.a Verifique se os procedimentos manuais de gerenciamento-chave de texto simples especificam processos para o uso do que segue: O conhecimento separado de chaves, como os componentes de chaves que esto sob o controle de pelo menos duas pessoas que tm conhecimento apenas de seus prprios componentes de chave; E Controle duplo de chaves, que necessita de pelo menos duas pessoas para executar qualquer operao de gerenciamento-chave e que uma nica pessoa no tenha acesso aos materiais de autenticao (por exemplo, senhas ou chaves) do outro. 3.6.6 Questione os funcionrios e/ou observe os processos para verificar se as chaves manuais de texto simples so gerenciadas com: Conhecimento separado, E Controle duplo
ORIENTAO
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. Observao: Os exemplos de operaes manuais de gerenciamento de chave incluem, entre outros: gerao, transmisso, carregamento, armazenamento e destruio de chaves.
O conhecimento separado e o controle duplo das chaves so usados para eliminar a possibilidade de uma pessoa ter acesso chave inteira. Este controle aplicvel em operaes de gerenciamento de chaves manual ou onde o gerenciamento de chaves no for implementado por um produto de criptografia. O conhecimento separado um mtodo no qual duas ou mais pessoas possuem componentes de chave separadamente, onde cada pessoa conhece apenas seu prprio componente e os componentes de chave individuais no transmitem nenhum conhecimento da chave criptogrfica original). O controle duplo requer que duas ou mais pessoas realizem uma funo e uma nica pessoa no pode acessar ou usar os materiais de autenticao do outro. A soluo de criptografia no deve permitir nem aceitar a substituio de chaves vindas de fontes no autorizadas ou de processos inesperados.
3.6.7 Preveno contra a substituio no autorizada de chaves criptogrficas.
3.6.7.a Verifique se os procedimentos do gerenciamento de chaves especificam processos para evitar a substituio no autorizada das chaves. 3.6.7.b Questione os funcionrios e/ou observe os processos para verificar se a substituio no autorizada de chaves evitada.
3.6.8 Requisito para que os responsveis pela proteo das chaves criptogrficas assinem um formulrio declarando que eles compreendem e aceitam suas
3.6.8.a Verifique se os procedimentos do gerenciamento de chaves especificam processos para que os responsveis pela proteo garantam (por escrito ou eletronicamente) que compreendem e aceitam suas responsabilidades de proteo das chaves.
Este processo garantir que os indivduos que atuam como responsveis se comprometam com a funo de responsveis pela chave e conheam e aceitem as responsabilidades.

responsabilidades pela proteo das chaves.
3.6.8.b Observe a documentao ou outras evidncias que demonstrem se os responsveis pela proteo garantem (por escrito ou eletronicamente) que compreendem e aceitam suas responsabilidades de proteo das chaves. 3.7 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para proteger os dados armazenados do carto esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
ORIENTAO
3.7 Certifique-se de que as polticas de segurana e procedimentos operacionais para proteger os dados armazenados do portador do carto estejam documentados, em uso e conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais documentados para gerenciar o armazenamento seguro dos dados do portador do carto continuamente.
Requisito 4:
Criptografe a transmisso dos dados do portador 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 sem fio configuradas de forma incorreta e vulnerabilidades na criptografia herdada e protocolos de autenticao continuam a 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 criptografia forte e protocolos de segurana (por exemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger dados confidenciais do portador do carto durante a transmisso por redes pblicas e abertas, incluindo o que segue: Somente chaves e certificados confiveis so aceitos. O protocolo em uso suporta apenas verses ou configuraes seguras. A fora da criptografia adequada para a metodologia de criptografia que est sendo utilizada.
4.1.a Identifique todos os locais onde os dados do portador do carto so transmitidos ou recebidos por redes pblicas, abertas. Analise os padres documentados e compare com as configuraes do sistema para verificar o uso de protocolos de segurana e criptografia forte em todos os locais. 4.1.b Revise as polticas e procedimentos documentados para verificar se os processos so especificados para o que segue: Aceitao de apenas chaves e/ou certificados confiveis O protocolo em uso suporta apenas verses e configuraes seguras (verses e configuraes no seguras no so suportadas) Implementao de fora de criptografia adequada conforme a metodologia de criptografia que est sendo utilizada.
ORIENTAO
As informaes confidenciais devem ser criptografas durante a transmisso por redes pblicas, pois fcil e comum para um indivduo mal-intencionado interceptar e/ou desviar os dados enquanto eles estiverem em trnsito. A transmisso segura dos dados do portador do carto requer o uso de chaves/certificados confiveis, um protocolo seguro para o transporte e criptografia forte adequada para criptografar os dados do portador do carto. As solicitaes de conexo de sistemas que no suportam a criptografia forte adequada e que possam resultar em uma conexo no segura, no devem ser aceitas.

Os exemplos de redes abertas e pblicas incluem, entre outros: A internet Tecnologias sem fio, incluindo 802.11 e Bluetooth Tecnologia celular, por exemplo, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA) General Packet Radio Service (GPRS). Comunicaes por satlite.
4.1.c Selecione e observe uma amostra das transmisses de entrada e sada conforme elas ocorrem para verificar se os dados do portador do carto esto bem criptografados durante o trnsito. 4.1.dAnalise as chaves e certificados para verificar se somente chaves e/ou certificados confiveis so aceitos. 4.1.e Analise as configuraes do sistema para verificar se o protocolo foi implementado para usar apenas configuraes seguras e se no suportam verses ou configuraes no seguras. 4.1.f Analise as configuraes do sistema para verificar se a fora da criptografia adequada implementada para a metodologia de criptografia que est sendo utilizada. (Verifique as recomendaes/melhores prticas do fornecedor.)
ORIENTAO
Observe que algumas implantaes de protocolo (como SSL verso 2.0, SSH verso 1.0 e TLS 1.0) possuem vulnerabilidades conhecidas que um invasor poder utilizar para obter o controle do sistema afetado. Qualquer que seja o protocolo de segurana adotado, verifique que esteja configurado para utilizar somente configuraes e verses seguras para evitar o uso de uma conexo no segura. Por exemplo, o TLS v1.1 ou mais recente, certificados obtidos a partir de uma autoridade pblica e reconhecida e que suporte apenas critptografia forte, podem ser considerados. Verificar se os certificados so confiveis (por exemplo, que no estejam vencidos e que sejam emitidos a partir de uma fonte confivel) ajuda a garantir a integridade da conexo segura. Geralmente, o URL da pgina Web inicia com "HTTPS" e/ou o navegador da Web exibe um cone de cadeado em algum lugar na janela do navegador. Muitos fornecedores de certificados SSL tambm fornecem um selo de verificao bem visvel, s vezes chamados de "selo de segurana", "selo de local seguro" ou "selo confivel seguro"), o qual possibilita clicar no selo para revelar as informaes sobre o site.
4.1.g Para as implementaes de SSL/TLS, analise as configuraes do sistema para verificar se o SSL/TLS est habilitado onde quer que os dados do portador do carto sejam transmitidos ou recebidos. Por exemplo, para implementaes com base no navegador: O "HTTPS" aparece como parte do protocolo de Universal Record Locator (URL) do navegador, e Os dados do portador do carto so exigidos somente se o "HTTPS" aparece como parte do URL.

4.1.1 Certifique-se de que as redes sem fio estejam transmitindo dados do portador do carto ou estejam conectadas ao ambiente de dados do portador do carto, use as melhores prticas do setor (por exemplo, IEEE 802.11i) para implementar a criptografia forte para a autenticao e a transmisso. Observao: O uso de WEP como controle de segurana proibido. 4.2 Nunca envie PANs desprotegidos por tecnologias de envio de mensagens de usurio final (por exemplo, e-mail, sistemas de mensagens instantneas, chat, etc.).
4.1.1 Identifique todas as redes sem fio que transmitem dados do portador do carto ou conectadas ao ambiente de dados do portador do carto. Analise os padres documentados e compare com as configuraes do sistema para verificar o que segue para todas as redes sem fio identificadas: As melhores prticas do setor (por exemplo, IEEE 802.11i) so usadas para implementar a criptografia forte para autenticao e transmisso. A criptografia fraca (por exemplo, WEP, SSL verso 2.0 ou mais antiga) no utilizada como controle de segurana para a autenticao ou transmisso. 4.2.a Se forem utilizadas tecnologias de mensagem de usurio final para enviar dados do portador do carto, observe os processos de envio do PAN e analise uma amostra das transmisses de sada quando elas ocorrerem para verificar se o PAN entregue ilegvel ou protegido com criptografia forte sempre que enviado por meio de tecnologias de mensagens de usurio final. 4.2.bRevise as polticas escritas para verificar a existncia de uma poltica que afirme que os PANs desprotegidos no devem ser enviados por meio das tecnologias de envio de mensagens de usurio final.
ORIENTAO
Usurios mal-intencionados usam as vrias ferramentas que esto disponveis gratuitamente para espionar as comunicaes sem fio. O uso de criptografias fortes pode limitar a divulgao de informaes confidenciais atravs da rede sem fio. A criptografia forte para autenticao e transmisso dos dados do portador do carto necessria para evitar que usurios malintencionados obtenham acesso rede sem fio ou utilizem as redes sem fio para acessar outros dados ou redes internos. E-mail, sistemas de mensagens instantneas e chat podem ser facilmente interceptados por sniffing de pacotes durante a entrega por redes internas e pblicas. No utilize essas ferramentas de envio de mensagem para enviar o PAN se elas no estiverem configuradas para fornecer criptografia forte.
4.3 Certifique-se de que as polticas de segurana e procedimentos operacionais para criptografar as transmisses dos dados do portador do carto estejam documentados, em uso e conhecidos por todas as partes envolvidas.
4.3 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para criptografar as transmisses dos dados do portador do carto esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para gerenciar a transmisso segura dos dados do portador do carto continuamente.
Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: antivrus Proteja todos os sistemas contra softwares prejudiciais e atualize regularmente programas ou software de
Softwares mal-intencionados, normalmente chamados de "malware" (incluindo vrus, worms e cavalos de Troia) 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. O software de antivrus deve ser usado em todos os sistemas comumente afetados pelo malware para proteger os sistemas de ameaas atuais e potenciais de softwares mal-intencionados. Solues adicionais contra malware podem ser consideradas como suplemento ao software de antivrus; no entanto, estas solues adicionais no substituem a necessidade do software de antivrus estar adequado.
Requisitos do PCI DSS
5.1 Implemente softwares de antivrus em todos os sistemas normalmente afetados por softwares malintencionados (especialmente em computadores pessoais e servidores).
5.1Para obter uma amostra dos componentes do sistemas incluindo todos os tipos de sistemas operacionais normalmente afetados por softwares mal-intencionados, verifique se o software de antivrus foi implementado se houver uma tecnologia antivrus aplicvel.
ORIENTAO
Existe um fluxo constante de invases usando faanhas amplamente divulgadas, muitas vezes do tipo "zero day" (uma invaso que se aproveita de uma vulnerabilidade previamente desconhecida), contra sistemas at ento seguros. Sem uma soluo de antivrus que seja atualizada regularmente, essas novas formas de software mal-intencionado podem atacar os sistemas, desativar uma rede ou levar ao comprometimento dos dados. importante proteger contra TODOS os tipos e formas de softwares mal-intencionados.
5.1.1 Certifique-se de que os programas antivrus sejam capazes de detectar, remover e proteger contra todos os tipos conhecidos de softwares mal-intencionados.
5.1.1 Revise a documentao do fornecedor e analise as configuraes do antivrus para verificar se os programas antivrus; Detectam todos os tipos conhecidos de softwares malintencionados. Removem todos os tipos conhecidos de softwares malintencionados, e Protegem contra todos os tipos conhecidos de softwares mal-intencionados. Os exemplos de tipos de softwares mal-intencionados incluem vrus, worms, trojans, spyware, adware e rootkits.

5.1.2 Para sistemas que normalmente no so atacados por softwares malintencionados, execute avaliaes peridicas para identificar e avaliar a evoluo de ameaas de malware a fim de confirmar se tais sistemas continuam a no precisar de software de antivrus.
5.1.2Questione os funcionrios para verificar se a evoluo de ameaas de malware monitorada e avaliada para sistemas que normalmente no so atacados por softwares mal-intencionados, a fim de confirmar se tais sistemas continuam a no precisar de software de antivrus.
ORIENTAO
Tipicamente, mainframes, computadores de mdio porte (como AS/400) e sistemas similares podem no ser alvos ou afetados por malware no momento. No entanto, as tendncias do setor para softwares mal-intencionados podem mudar rapidamente, por isso importante que as organizaes estejam cientes de novos malwares que possam afetar seus sistemas, por exemplo, monitorando os avisos de segurana do fornecedor e novos grupos de antivrus para determinar se seus sistemas podem estar sob ameaa de novos malwares. As tendncias em softwares mal-intencionados devem ser includas na identificao de novas vulnerabilidades de segurana e os mtodos para resolver novas tendncias devem ser incorporados aos padres de configurao da empresa e aos mecanismos de proteo, conforme necessrio
5.2 Certifique-se de que todos os mecanismos antivrus sejam mantidos conforme segue: So mantidos atualizados, Executam varreduras peridicas Geram logs de auditoria que so mantidos conforme o Requisito 10.7 do PCI DSS.
5.2.a Analise as polticas e os procedimentos para verificar se exigido que as definies e o software de antivrus sejam mantidos atualizados. 5.2.b Analise as configuraes do antivrus, incluindo a instalao principal do software para verificar se os mecanismos antivrus esto: Configurados para executar atualizaes automticas, e Configurados para executar varreduras peridicas. 5.2.c Analise uma amostra dos componentes do sistema incluindo todos os tipos de sistemas operacionais normalmente afetados pelos softwares mal-intencionados, para verificar se: O software de antivrus e as definies so atuais. Executam varreduras peridicas. 5.2.d Analise as configuraes do antivrus, incluindo a instalao principal do software e uma amostra dos componentes do sistema para verificar se: A gerao de log do software de antivrus est habilitada, e
Mesmo as melhores solues antivrus so limitadas se no forem atualizadas com as mais recentes atualizaes de segurana, arquivos de assinatura ou protees contra malware. Os logs de auditoria oferecem a capacidade de monitorar as atividades do vrus e de malware e as reaes contra malware. Dessa forma, imprescindvel que as solues de malware sejam configuradas de forma a gerar logs de auditoria e esses logs devero ser gerenciados de acordo com o Requisito 10.
Os logs so mantidos de acordo com o Requisito 10.7 do PCI DSS.
ORIENTAO

5.3 Certifique-se de que os mecanismos antivrus estejam funcionando ativamente e no possam ser desativados ou alterados pelos usurios, a menos que seja especificamente autorizado pelo gerenciamento com base em cada caso por um perodo limitado de tempo. Observao: As solues de antivrus podem ser temporariamente desativadas apenas se houver necessidade tcnica comprovada, conforme autorizado pelo gerenciamento com base em cada caso. Se a proteo de antivrus precisar ser desativada por um motivo especfico, isso deve ser formalmente autorizado. Medidas adicionais de segurana tambm podem precisar ser implementadas pelo perodo de tempo durante o qual a proteo de antivrus no estiver ativa. 5.4 Certifique-se de que as polticas de segurana e procedimentos operacionais para proteger os sistemas contra malware estejamdocumentados, em uso e conhecidos por todas as partes envolvidas.
5.3.a Analise as configuraes do antivrus, incluindo a instalao principal do software e uma amostra dos componentes do sistema para verificar se o software de antivrus est funcionando ativamente. 5.3.b Analise as configuraes do antivrus, incluindo a instalao principal do software e uma amostra dos componentes do sistema para verificar se o software de antivrus no pode ser desativado ou modificado pelos usurios. 5.3.c Questione os funcionrios responsveis e observe os processos para verificar se o software de antivrus no pode ser desativado ou alterado pelos usurios, a menos que seja especificamente autorizado pelo gerenciamento com base em cada caso por um perodo limitado de tempo.
ORIENTAO
O antivrus executado continuamente e que desativado para ser modificado proporcionar a segurana persistente contra malware. O uso de controles baseados na poltica em todos os sistemas para garantir que as protees contra malware no possam ser modificadas ou desativadas ajudar a evitar que a fraqueza do sistema seja aproveitada por software malintencionado. Medidas adicionais de segurana tambm podem ser necessrias pelo perodo de tempo durante o qual a proteo antivrus no estiver ativada, por exemplo, desconectar o sistema desprotegido da internet enquanto a proteo antivrus estiver desativada e executar uma varredura completa depois que ela for reativada.
5.4 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para proteger os sistemas contra malware esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para garantir que os sistemas estejam continuamente protegidos contra malware.
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 devem contar com os patches de software adequados para proteger contra a explorao e o comprometimento dos dados do portador 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. REQUISITOS DO PCI DSS
6.1 Estabelea um processo para identificar as vulnerabilidades de segurana, usando fontes externas de boa reputao para informaes de vulnerabilidades da segurana e classifique uma escala de risco (por exemplo, "alto", "mdio" ou "baixo") para vulnerabilidades de segurana recentemente descobertas. Observao: As classificaes de risco devem ser baseadas nas melhores prticas do setor, bem como a considerao de impacto potencial. Por exemplo, os critrios para classificar as vulnerabilidades podem incluir a considerao da marca da base CVSS e/ou a classificao pelo fornecedor e/ou os tipos de sistemas afetados. Os mtodos para avaliar as vulnerabilidades e classificar o nvel de risco variam baseados no ambiente da organizao e na estratgia de avaliao de risco. As classificaes de risco devem, no mnimo, identificar todas as vulnerabilidades consideradas de "alto risco" ao ambiente. Alm da classificao de risco, as vulnerabilidades podem ser consideradas "crticas" se apresentarem uma ameaa iminente ao ambiente, sistemas crticos de impacto e/ou resultaria em comprometimento potencial se no resolvidas. Exemplos de sistemas crticos podem incluir sistemas de
6.1.a Analise as polticas e procedimentos para verificar se os processos esto definidos para o que segue: Para identificar novas vulnerabilidades da segurana Para classificar uma escala de risco para as vulnerabilidades que incluem identificao de todas as vulnerabilidades de "alto risco" e "crticas". Para usar fontes externas de boa reputao para obter informaes sobre vulnerabilidade da segurana. 6.1.b Questione os funcionrios responsveis e observe os processos para verificar se: Novas vulnerabilidades da segurana so identificadas. Uma escala de risco classificada para as vulnerabilidades que incluem identificao de todas as vulnerabilidades de "alto risco" e "crticas". Os processos de identificao de novas vulnerabilidades de segurana incluem o uso de fontes externas de boa reputao para obteno de informaes sobre vulnerabilidades.
ORIENTAO
O objetivo deste requisito que as organizaes se mantenham atualizadas quanto a novas vulnerabilidades que podero interferir no sistema. As fontes de informao de vulnerabilidades devem ser confiveis e frequentemente incluem sites do fornecedor, novos grupos do setor, lista de envios ou RSS feeds. Quando uma organizao identifica uma vulnerabilidade que poder afetar seu ambiente, o risco que essa vulnerabilidade representa deve ser avaliado e classificado. A organizao deve ento, ter um mtodo adequado para avaliar as vulnerabilidades continuamente e classificar as escalas de risco para estas vulnerabilidades. Isso no acontece pela varredura ASV ou varredura de vulnerabilidade interna, mas exige um processo para monitorar ativamente as fontes do setor para informaes de vulnerabilidade. Classificar os riscos (por exemplo, como "altos", "mdios" ou "baixos") permite que as organizaes identifiquem, priorizem e encaminhem itens de maior risco mais rapidamente e reduzam a probabilidade de as vulnerabilidades que representarem maior risco serem exploradas.

segurana, dispositivos voltados ao pblico e sistemas, bancos de dados e outros sistemas que armazenam, processam ou transmitem dados do portador do carto. 6.2 Certifique-se de que todos os componentes do sistema e softwares estejam protegidos de vulnerabilidades conhecidas instalando os patches de segurana aplicveis disponibilizados pelos fornecedores. Instale patches de segurana crticos em at um ms aps o lanamento. Observao: Os patches de segurana crtica devem ser identificados de acordo com o processo de classificao de risco definido no Requisito 6.1.
ORIENTAO
6.2.aAnalise as polticas e procedimentos relacionados instalao dos patches de segurana para verificar se esto definidos processos para: Instalao de patches de segurana crticos disponibilizados pelo fornecedor em at um ms aps o lanamento. Instalao de todos os patches de segurana aplicveis disponibilizados pelo fornecedor dentro de um perodo de tempo apropriado (por exemplo, dentro de trs meses). 6.2.b Para obter uma amostra 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 o seguinte: Os patches de segurana crticos disponibilizados pelo fornecedor so instalados em at um ms aps o lanamento. Todos os patches de segurana aplicveis disponibilizados pelo fornecedor so instalados em um perodo de tempo apropriado (por exemplo, dentro de trs meses).
Existe um fluxo constante de invases usando faanhas amplamente divulgadas, muitas vezes do tipo "zero day" (uma invaso que se aproveita de uma vulnerabilidade previamente desconhecida), contra sistemas at ento seguros. Se os patches mais recentes no forem implantados nos sistemas crticos assim que possvel, um indivduo malintencionado pode us-los para atacar ou desativar um sistema ou obter acesso aos dados confidenciais. Priorizar os patches para a infraestrutura crtica garante que os sistemas e dispositivos de alta prioridade sejam protegidos contra vulnerabilidades assim que o patch lanado. Considere priorizar as instalaes do patch de forma que os patches de segurana em sistemas crticos ou em risco sejam instalados em at 30 dias e outros patches de menor risco sejam instalados em 2 ou 3 meses. Este requisito se aplica aos patches aplicveis para todos os softwares instalados.
6.3 Desenvolva aplicativos de software internos e externos (incluindo acesso administrativo pela Web aos aplicativos) com segurana, conforme segue: De acordo com o PCI DSS (por exemplo, autenticao e logs seguros) Baseados nos padres e/ou melhores prticas do setor. Incorporar segurana da informao ao longo da vida til do desenvolvimento do
6.3.a 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 da 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 software foram desenvolvidos de acordo com o PCI DSS.
Sem a incluso de uma proteo durante as fases de definio de requisitos, design, anlise e teste do desenvolvimento de software, as vulnerabilidades de segurana podem ser apresentadas de forma inadvertida ou mal-intencionada no ambiente de produo. Saber como os dados confidenciais so controlados pelo aplicativo (incluindo quando so armazenados, transmitidos e quando esto na memria) pode ajudar a identificar onde os dados precisam ser

software. Observao: isso se aplica a todos os softwares desenvolvidos internamente, bem como a softwares personalizados ou sob encomenda desenvolvidos por terceiros. 6.3.1 Remova as contas de desenvolvimento, teste e/ou personalizados, IDs de usurio e senhas antes que o aplicativo se torne ativo ou seja lanado aos clientes.
6.3.d Questione os desenvolvedores do software para verificar se processos por escrito de desenvolvimento do software esto implementados. protegidos.
ORIENTAO
6.3.1 Analise os procedimentos escritos do desenvolvimento do software e questione os funcionrios responsveis para verificar se as contas de pr-produo e/ou de aplicativos personalizados, IDs de usurios e/ou senhas so removidos antes de um aplicativo ser produzido ou lanado aos clientes.
Contas de desenvolvimento, teste e/ou aplicativos personalizados, IDs de usurios e senhas devem ser removidos do cdigo de produo antes de o aplicativo ser ativado ou liberado para os clientes, pois esses itens podem fornecer informaes sobre o funcionamento do aplicativo. A posse dessas informaes pode facilitar o comprometimento do aplicativo e dos dados relacionados do portador do carto.

6.3.2 Revise o cdigo personalizado antes da liberao para produo ou clientes a fim de identificar qualquer possvel vulnerabilidade no cdigo (usando processos manuais ou automatizados) para incluir ao menos o seguinte: As alteraes dos cdigos so analisadas por outras pessoas alm do autor do cdigo e por pessoas que esto cientes das tcnicas de anlise dos cdigos e das prticas de codificao seguras. As revises de cdigo garantem que o cdigo seja desenvolvido de acordo com as diretrizes de codificao seguras. As correes adequadas so implementadas antes da liberao. Os resultados das anlises dos cdigos so revisados e aprovados pelo gerenciamento antes da liberao. (Continua na prxima pgina)
6.3.2.a Analise os procedimentos escritos do desenvolvimento do software e questione os funcionrios responsveis para confirmar se todas as alteraes nos cdigos dos aplicativos personalizados devem ser revisadas (usando processos manuais ou automatizados), conforme 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 pelo gerenciamento antes da liberao.
ORIENTAO
As vulnerabilidades de segurana no cdigo personalizado so comumente exploradas por indivduos mal-intencionados para obter acesso a uma rede e comprometer os dados do portador do carto. Um indivduo com conhecimento e experincia nas tcnicas de anlise do cdigo deve estar envolvido no processo de anlise. As anlises do cdigo devem ser realizadas por algum que no seja o desenvolvedor do cdigo a fim de permitir uma reviso independente e objetiva. Processos ou ferramentas automatizados tambm podem ser usados ao invs de anlises manuais, mas pode ser difcil ou at mesmo impossvel para uma ferramenta automatizada identificar alguns problemas do cdigo. Corrigir os erros de codificao antes que o cdigo seja enviado para produo ou distribudo para os clientes evita que o mesmo exponha os ambientes a possveis aproveitadores. Tambm muito mais difcil de resolver um cdigo com defeito depois de ele ser distribudo ou liberado para ambientes de produo. Incluir uma reviso formal e aprovao do gerenciamento antes da liberao ajuda a garantir que o cdigo seja aprovado e tenha sido desenvolvido de acordo com as polticas e procedimentos.

Observao: Este requisito referente s anlises dos cdigos se aplica a todos os cdigos personalizados (internos e voltados ao 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 voltados ao pblico tambm esto sujeitos a controles extras para abranger ameaas e vulnerabilidades contnuas aps a implementao, conforme definido no Requisito 6.6 do PCI DSS. 6.4 Siga os procedimentos de controle de alteraes para todas as alteraes nos componentes do sistema. Esses processos devem incluir o seguinte:
6.3.2.b Selecione uma amostra de alteraes recentes dos aplicativos personalizados e verifique se o cdigo do aplicativo personalizado analisado de acordo com o item 6.3.2 acima.
ORIENTAO
6.4 Analise as polticas e os procedimentos para verificar se o seguinte est definido: Os ambientes de desenvolvimento/teste so separados do ambiente de produo, com controle de acesso implementado para executar a separao. Uma separao das tarefas entre a equipe atribuda aos ambientes de desenvolvimento/teste e a atribuda ao ambiente de produo. Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento. Os dados e as contas de teste so removidos antes que o sistema de produo se torne ativo. Os procedimentos de controle de alteraes ligados implementao de patches de segurana e s modificaes esto documentados. 6.4.1.a Analise a documentao de rede e as configuraes do dispositivo de rede para verificar se os ambientes de desenvolvimento/teste so separados do ambiente de produo. 6.4.1.b Analise os ajustes dos controles de acesso para verificar se estes esto implementados para forar a separao entre os ambientes de teste/desenvolvimento e os ambientes de produo.
Sem controles de alterao adequadamente documentados e implementados, os recursos de segurana podem ser omitidos sem ou com inteno ou ainda tornados inoperveis e podem ocorrer irregularidades no processamento ou pode ser introduzido um cdigo mal-intencionado.
6.4.1 Separe os ambientes de teste/desenvolvimento do ambiente de produo e reforce a separao com controle de acesso.
Devido mutao constante dos ambientes de desenvolvimento e teste, estes tendem a ser menos seguros do que o ambiente de produo. Sem a separao adequada entre os ambientes, possvel que o ambiente de produo e os dados do portador do carto sejam comprometidos devido s configuraes de segurana menos rigorosas e possveis vulnerabilidades em um ambiente de teste ou desenvolvimento. Pgina 58 Novembro de 2013

6.4.2 Separao dos deveres entre os ambientes de desenvolvimento/teste e de produo
6.4.2 Observe os processos e questione os funcionrios designados para os ambientes de teste/desenvolvimento e os designados para os ambientes de produo para verificar se a separao dos deveres foi implementada entre eles.
ORIENTAO
Reduzir o nmero de pessoas com acesso ao ambiente de produo e aos dados do portador do carto reduz os riscos e ajuda a garantir que o acesso seja limitado aos indivduos com necessidade comercial de saber. O objetivo deste requisito separar as funes de desenvolvimento e teste das funes de produo. Por exemplo, um desenvolvedor poder utilizar uma conta com nvel de administrador com privilgios elevados no ambiente de desenvolvimento e possuir uma conta separada com acesso de nvel de usurio ao ambiente de produo.
6.4.3 Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento
6.4.3.a Observe os processos de teste e questione os funcionrios para verificar se os procedimentos esto implementados para garantir que os dados de produo (PANs ativos) no sejam usados para testes ou desenvolvimento. 6.4.3.b Analise uma amostra dos dados de teste para verificar se os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento.
Os controles de segurana normalmente no so to rgidos no ambiente de desenvolvimento ou de teste. O uso de dados de produo d aos indivduos mal-intencionados a oportunidade de ganhar acesso no autorizado aos dados de produo (dados do portador do carto).
6.4.4 Remoo dos dados de teste e contas antes que os sistemas de produo se tornem ativos
6.4.4.a Observe os processos de teste e questione os funcionrios para verificar se os dados e as contas de teste so removidos antes que o sistema de produo se torne ativo. 6.4.4.b Analise uma amostra de dados e contas dos sistemas de produo recentemente instalados ou atualizados para verificar se estes so removidos antes que o sistema se torne ativo.
Dados e contas de teste devem ser removidos do cdigo da produo antes de o aplicativo ser ativado, pois esses itens podem fornecer informaes sobre o funcionamento do aplicativo ou do sistema. A posse dessas informaes pode facilitar o comprometimento do sistema e dos dados relacionados do portador do carto.

6.4.5 Os procedimentos de controle de alteraes para a implementao de patches de segurana e modificaes de software devem incluir o seguinte:
6.4.5.a Analise os procedimentos de controle de alteraes ligados implementao de patches de segurana e s modificaes do software e verifique se os procedimentos esto definidos para: Documentao de impacto Aprovao documentada de alterao pelas partes autorizadas Teste de funcionalidade para verificar se a alterao no tem impacto adverso sobre a segurana do sistema Procedimentos de reverso 6.4.5.b Para obter uma amostra dos componentes do sistema, questione os funcionrios responsveis para determinar os patches de segurana/alteraes recentes. Rastreie essas alteraes com a documentao de controle de alterao relacionada. Para cada alterao analisada, desempenhe o seguinte:
ORIENTAO
Se no for adequadamente controlado, o impacto das atualizaes do software e patches de segurana pode no ser realizado por completo e pode ter consequncias inesperadas.
6.4.5.1 Documentao de impacto.
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 autorizadas 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 todas as atualizaes foram testadas para estarem de acordo com o Requisito 6.5 do PCI DSS antes de serem implementadas na produo.
O impacto da alterao deve ser documentado de forma que todas as partes afetadas possam planejar adequadamente quaisquer alteraes de processamento. A aprovao por partes autorizadas indica que a alterao legtima e que a alterao aprovada foi sancionada pela organizao. Devero ser realizados testes rigorosos para verificar se a segurana do ambiente no se reduz ao ser implantada uma alterao. O teste dever validar se todos os controles de segurana existentes permaneam no lugar, sejam substitudos por controles igualmente rigorosos ou sejam reforados aps alguma alterao no ambiente.
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.4.5.4 Verifique se os procedimentos de reverso foram preparados para cada alterao exemplificada.
ORIENTAO
Para cada alterao, deve haver procedimentos de reverso documentados para o caso de falhas na alterao ou efeitos adversos na segurana de um aplicativo ou sistema, a fim de permitir que o sistema seja restaurado ao seu estado anterior. A camada do aplicativo de alto risco e pode ser tida como alvo por ameaas internas e externas. Os requisitos 6.5.1 a 6.5.10 so os controles mnimos que devem ser implementados e as organizaes devem incorporar as prticas seguras de codificao relevantes conforme aplicvel tecnologia especfica em seu ambiente. Os desenvolvedores de aplicativos devem ser treinados adequadamente para identificar e resolver problemas relacionados a estas (e outras) vulnerabilidades de codificao comuns. Uma equipe com conhecimento sobre as orientaes seguras de codificao deve minimizar o nmero de vulnerabilidades de segurana introduzidas por meio de ms prticas de codificao. O treinamento para os desenvolvedores pode ser ministrado no local ou por terceiros e deve ser aplicvel tecnologia utilizada. Todas as alteraes de prticas de decodificao aceitas pelo setor, as prticas de decodificao organizacionais e o treinamento de desenvolvedores devem ser atualizados igualmente para lidar com novas ameaas, por exemplo, invases relacionadas limpeza de memria. As vulnerabilidades identificadas no 6.5.1 at o 6.5.10 oferecem uma linha de base mnima. de escolha da organizao permanecer atualizada com as tendncias de vulnerabilidades e incorporar as medidas apropriadas em suas prticas seguras de codificao.
6.5 Trate as vulnerabilidades de codificao comuns nos processos de desenvolvimento do software conforme segue: Treine os desenvolvedores sobre tcnicas seguras de codificao, incluindo como evitar vulnerabilidades comuns de codificao e compreendendo como os dados confidenciais so controlados na memria. Desenvolva aplicativos baseados nas diretrizes de cdigo seguro. Observao: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.10 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.a Analise as polticas e procedimentos de desenvolvimento de software para verificar se exigido treinamento em tcnicas de codificao seguras para desenvolvedores, com base nas melhores prticas e diretrizes do setor. 6.5.b Questione alguns desenvolvedores para verificar se eles esto instrudos sobre as tcnicas de codificao seguras. 6.5.c Consulte os registros de treinamento para verificar se os desenvolvedores de software receberam treinamento sobre tcnicas seguras de codificao, incluindo como evitar vulnerabilidades comuns de codificao e compreendendo como os dados confidenciais so controlados na memria. 6.5.d. Verifique se esto implementados processos para proteger os aplicativos contra, pelo menos, as seguintes vulnerabilidades:
ORIENTAO
Observao: Os requisitos 6.5.1 a 6.5.6 abaixo se aplicam a todos os aplicativos (internos ou externos). 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.1 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se as falhas de injeo so resolvidas pelas tcnicas de codificao que incluem: Validar a entrada para verificar se os dados do usurio no podem modificar o significado dos comandos e das consultas. Utilizar consultas parametrizadas. As falhas de injeo, principalmente de injeo de SQL, so um mtodo comumente utilizado em aplicativos comprometidos. A injeo ocorre quando dados fornecidos pelo usurio so enviados para um intrprete como parte de um comando ou consulta. Os dados hostis do invasor enganam o intrprete para executar comandos no planejados ou para alterar os dados e permitem que o invasor invada os componentes dentro da rede por meio do aplicativo, a fim de iniciar invases como sobrecargas do buffer, ou para revelar tanto informaes confidenciais quando funcionalidades no aplicativo do servidor. As informaes devem ser validadas antes de serem enviadas para o aplicativo, por exemplo, ao verificar todos os caracteres alfabticos, mistura de caracteres alfabticos e numricos, etc. 6.5.2 Sobrecargas do buffer 6.5.2 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se as sobrecargas de buffer so resolvidas pelas tcnicas de codificao que incluem: Validar os limites do buffer. Truncar as strings de entrada. As sobrecargas de buffer ocorrem quando um aplicativo no possui uma verificao de limites adequada em seu espao de buffer. Isto pode fazer com que as informaes no buffer sejam empurradas para o espao da memria do buffer e o espao da memria executvel. Quando isso ocorre, o invasor consegue inserir um cdigo malintencionado no final do buffer e envie por push este cdigo para o espao de memria executvel ao provocar sobrecarga de buffer. O cdigo malintencionado ento executado e com frequncia permite que o invasor acesse remotamente o aplicativo e/ou o sistema infectado.

6.5.3 Armazenamento criptogrfico no seguro
6.5.3 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se o armazenamento criptogrfico no seguro direcionado pelas tcnicas de codificao que: Evita falhas criptogrficas. Utiliza chaves e algoritmos de criptografia forte.
ORIENTAO
Os aplicativos que no utilizam recursos de criptografia forte de maneira adequada para armazenar dados correm um risco maior de ficarem comprometidos e de expor as credenciais de autenticao e/ou os dados do portador do carto. Caso um invasor consiga explorar os processos criptogrficos, ele poder obter acesso de texto simples aos dados criptografados. Os aplicativos que no criptografarem adequadamente o trfego de rede utilizando criptografia forte correm um risco maior de ficarem comprometidos e de expor os dados do portador do carto. Se o invasor conseguir explorar os processos criptografados, poder obter controle de um aplicativo ou at mesmo obter acesso de texto no criptografado a dados criptografados. Os aplicativos podem, de forma no intencional, vazar informaes sobre sua configurao, trabalhos internos ou expor informaes privilegiadas por meio de mtodos de tratamento de erros. Os invasores usam esse ponto fraco para roubar dados confidenciais ou para comprometer o sistema como um todo. Se um indivduo malintencionado puder criar erros que o aplicativo no consegue manusear corretamente, eles podem obter informaes detalhadas do sistema, criar interrupes de negao de servio, causar falhas de segurana ou criar problemas no servidor. Por exemplo, a mensagem senha incorreta informa ao invasor que o ID de usurio fornecido est correto e que ele deve concentrar os esforos somente na senha. Use mensagens de erro mais genricas, como os dados no puderam ser verificados".
6.5.4 Comunicaes no seguras
6.5.4 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se as comunicaes no seguras so direcionadas pelas tcnicas de codificao que autenticam e criptografam corretamente todas as comunicaes confidenciais.
6.5.5 Tratamento incorreto de erros
6.5.5 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se o tratamento incorreto de erros direcionado pelas tcnicas de codificao que no vazam informaes por meio de mensagens de erro (por exemplo, retornando detalhes de erros genricos ao invs de erros especficos).

6.5.6 Todas as vulnerabilidades de "alto risco" identificadas no processo de identificao de vulnerabilidade (conforme definido no Requisito 6.1 do PCI DSS).
6.5.6Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se as tcnicas de codificao resolvem qualquer vulnerabilidade de "alto risco" que possa afetar o aplicativo, conforme identificado no Requisito 6.1 do PCI DSS.
ORIENTAO
Todas as vulnerabilidades identificadas pelo processo de classificao de risco de vulnerabilidade de uma organizao (definido no Requisito 6.1) como sendo de "alto risco" e que possam afetar o aplicativo devem ser identificadas e resolvidas durante o desenvolvimento do aplicativo. Os aplicativos da Web, tanto internos quanto externos (pblicos), possuem riscos de segurana exclusivos com base em sua arquitetura e sua relativa facilidade em apresentar comprometimento. Ocorrem falhas no XSS sempre que o aplicativo coletar os dados fornecidos pelo usurio e envi-los para um navegador sem primeiro validar ou codificar esse contedo. O XSS permite que os invasores executem o script no navegador da vtima, que pode se apoderar de sesses de usurios, desfigurar sites, possivelmente introduzir worms, etc.
Observao: Os Requisitos 6.5.7 a 6.5.10 abaixo se aplicam a aplicativos da Web e em interfaces de aplicativos (internos ou externos): 6.5.7 Script intersite (XSS) 6.5.7Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se o script intersite (XSS) direcionado pelas tcnicas de codificao que incluem Validar todos os parmetros antes da incluso Utilizar sada de contexto confidencial.

6.5.8 Controle de acesso inadequado (como referncias diretas no seguras a objetos, falhas em restringir o acesso a URLs, diretrios transversais e falhas em restringir o acesso do usurio s funes).
6.5.8 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se o controle de acesso incorreto (como referncias diretas no seguras a objetos, falha em restringir o acesso a URLs e diretrios transversais) direcionado pelas tcnicas de codificao que incluem: Autenticao adequada dos usurios Limpar a entrada No expor referncias de objetos internos aos usurios As interfaces do usurio no permitem o acesso a funes no autorizadas.
ORIENTAO
Uma referncia de objeto direto ocorre quando o desenvolvedor expe uma referncia a um objeto de implementao interna, como arquivo, diretrio, registro de banco de dados ou chave, como um URL ou forma de parmetro. Os invasores podem manipular essas referncias para acessar outros objetos sem autorizao. Force constantemente o controle de acesso na camada de apresentao e na lgica de negcios para todos os URLs. Muitas vezes um aplicativo s protege os recursos confidenciais ao evitar a exibio de links ou URLs para usurios no autorizados. Os invasores podem usar esse ponto fraco para acessar e executar operaes no autorizadas, acessando diretamente esses URLs. Um invasor poder ser capaz de enumerar e navegar pela estrutura do diretrio de um site (diretrio transversal), obtendo acesso a informaes no autorizadas e descobrindo o funcionamento do site para explorao futura. Se as interfaces do usurio permitirem o acesso a funes no autorizadas, este acesso pode fazer com que indivduos no autorizados obtenham acesso a credenciais privilegiadas ou aos dados do portador do carto. Apenas usurios autorizados devem ter permisso para acessar as referncias diretas de objetos a recursos confidenciais. Limitar o acesso aos recursos de dados ajudar a evitar que os dados do portador do carto sejam apresentados a recursos no autorizados.
6.5.9 Solicitao intersite forjada (CSRF).
6.5.9Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se a solicitao intersite forjada (CSRF) direcionada pelas tcnicas de codificao que garantem que os aplicativos no contem com tokens e credenciais de autorizao automaticamente enviados pelos navegadores.
Um invaso de CSRF fora o navegador da vtima logada a enviar uma solicitao pr-autenticada a um aplicativo da Web vulnervel, que ento possibilita ao invasor realizar qualquer operao de modificao do status que a vtima tenha autorizao para realizar (como atualizar detalhes da conta, fazer aquisies ou at mesmo autenticar ao aplicativo). Pgina 65 Novembro de 2013

6.5.10 Autenticao quebrada e gerenciamento de sesso Observao: O requisito 6.5.10 ser considerado uma das melhores prticas at 30 de junho de 2015 quando passar a ser um requisito.
6.5.10 Analise as polticas e procedimentos de desenvolvimento de software e questione os funcionrios responsveis para verificar se a autenticao quebrada e o gerenciamento de sesso so resolvidos pelas tcnicas de codificao que comumente incluem: Marcar os tokens de sesso (por exemplo, cookies) como "seguro" No expor os IDs de sesso no URL Incorporar perodos de tempo apropriados e rotao de IDs de sesso depois de efetuar logon com sucesso.
ORIENTAO
A autenticao segura e gerenciamento de sesso evita que indivduos no autorizados comprometam as credenciais, chaves ou tokens de sesso legtimos da conta, o que pode permitir que o invasor assuma a identidade de um usurio autorizado.

6.6 Para aplicativos da Web voltados ao pblico, trate novas ameaas e vulnerabilidades continuamente e assegure que esses aplicativos estejam protegidos contra invases conhecidos por meio de 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 Observao: Esta avaliao no igual s varreduras de vulnerabilidades realizadas para o Requisito 11.2. Instalar uma soluo tcnica automatizada que detecte e previna invases baseadas na Web (por exemplo, um firewall de aplicativo na Web) na frente de aplicativos da Web voltados para o pblico, para verificar continuamente todo o trfego.
6.6Para aplicativos da Web voltados ao pblico, certifiquese de que qualquer um dos mtodos a seguir esteja implementado conforme se segue: Analise os processos documentados, questione os funcionrios e analise os registros de avaliao de segurana do aplicativo para verificar se os aplicativos da Web voltados ao pblico so analisados (usando ferramentas ou mtodos manuais ou automatizados de avaliao de segurana das vulnerabilidades) conforme segue: - Pelo menos uma vez ao ano - Aps quaisquer alteraes - Por meio de uma empresa especializada na segurana de aplicativos - Se, pelo menos, todas as vulnerabilidades no Requisito 6.5 esto includas na avaliao - Se todas as vulnerabilidades so corrigidas - Se o aplicativo reavaliado aps as correes. Analise os ajustes da configurao do sistema e questione os funcionrios para verificar se uma soluo tcnica automatizada que detecte e previna invases baseadas na Web (por exemplo, um firewall de aplicativo na Web) seja implementada conforme segue: - Est situada diante de aplicativos da Web voltados ao pblico para detectar e prevenir invases baseadas na Web. - Est funcionando ativamente e atualizada conforme aplicvel. - Est gerando logs de auditoria. - Est configurada para bloquear invases baseadas na Web ou gerar um alerta.
ORIENTAO
Os aplicativos da Web voltados ao pblico so alvos principais de invasores e se no estiverem bem codificados, proporcionam caminho fcil para que os invasores obtenham acesso aos dados e sistemas confidenciais. O requisito para analisar aplicativos ou instalar firewalls de aplicativos da Web destina-se a reduzir o nmero de comprometimentos em aplicativos da Web devido m codificao ou ms prticas de gerenciamento do aplicativo. Ferramentas ou mtodos de avaliao da segurana de vulnerabilidade manual ou automatizada analisam e/ou testam o aplicativo para identificar vulnerabilidades Firewalls de aplicativo da Web filtram e bloqueiam trfego no essencial na camada do aplicativo. Utilizado em conjunto com um firewall com base em rede, um firewall de aplicativo da Web configurado corretamente evita invases na camada de aplicativos caso estes estejam codificados ou configurados incorretamente. Observao: Uma empresa especializada na segurana de aplicativos pode ser uma empresa terceirizada ou uma empresa interna, desde que os analisadores sejam especializados na segurana de aplicativos e possam demonstrar que no dependem da equipe de desenvolvimento.

6.7 Certifique-se de que as polticas de segurana e procedimentos operacionais para desenvolver e manter os sistemas e aplicativos estejamdocumentados, em uso e conhecidos por todas as partes envolvidas.
6.7 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para desenvolver e manter os sistemas e aplicativos esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
ORIENTAO
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para garantir que os sistemas e aplicativos sejam desenvolvidos com segurana e continuamente protegidos contra vulnerabilidades.
Implemente medidas rigorosas de controle de acesso

Requisito 7: o negcio Restrinja o acesso aos dados do portador do carto de acordo com a necessidade de conhecimento para
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 Limite o acesso aos componentes do sistema e aos dados do portador do carto somente quelas pessoas cuja funo requer tal acesso.
7.1 Analise a poltica por escrito para o controle de acesso e verifique se a poltica incorpora os requisitos 7.1.1 a 7.1.4 conforme segue: Definir necessidades de acesso e atribuies especiais para cada funo Restrio de acesso a IDs de usurios privilegiados ao menor nmero de privilgios necessrios para desempenhar as responsabilidades da funo A concesso do acesso se baseia na classificao e na atribuio da funo da equipe individual Aprovao documentada (eletronicamente ou por escrito) pelas partes autorizadas a todo o acesso, incluindo lista de privilgios especficos aprovados. 7.1.1 Selecione uma amostra de funes e verifique se as necessidades de acesso para cada funo esto definidas e se incluem: Componentes do sistema e recursos de dados que cada funo precisa acessar para realizar seu trabalho Identificao do privilgio necessrio para cada funo realizar seu trabalho.
ORIENTAO
Quanto mais pessoas tiverem acesso aos dados do portador do carto, mais risco haver de que a conta do usurio seja utilizada indevidamente. Limitar o acesso s pessoas com motivo corporativo legtimo para ter esse acesso ajuda a organizao a evitar o mau uso dos dados do portador do carto devido inexperincia ou ms intenes.
7.1.1 Defina as necessidades de acesso para cada funo, incluindo: Componentes do sistema e recursos de dados que cada funo precisa acessar para realizar seu trabalho O nvel de privilgio necessrio (por exemplo, usurio, administrador, etc.) para acessar os recursos.
Para limitar o acesso aos dados do portador do carto para apenas os indivduos que precisam deste acesso, primeiro necessrio definir as necessidades de acesso para cada funo (por exemplo, administrador do sistema, equipe da central de atendimento, balconista), os sistemas/dispositivos/dados que cada funo precisa acessar e o nvel de privilgio que cada funo precisa para desempenhar efetivamente as tarefas atribudas. Uma vez que as funes e necessidades de acesso correspondentes estiverem definidas, os indivduos tero o direito de acesso.

7.1.2 Restrinja o acesso a IDs de usurios privilegiados ao menor nmero de privilgios necessrios para desempenhar as responsabilidades da funo.
7.1.2.a Questione os funcionrios responsveis por permitir o acesso para verificar se o acesso a IDs de usurios privilegiados : Permitido apenas s funes que requerem especificamente tal acesso privilegiado Restritos ao menor nmero de privilgios necessrios para o desempenho das responsabilidades da funo. 7.1.2.b Selecione uma amostra de IDs de usurio com acesso privilegiado e questione a equipe de gerenciamento responsvel para verificar se os privilgios concedidos so: Necessrios para a funo daquela pessoa Restritos ao menor nmero de privilgios necessrios para o desempenho das responsabilidades da funo.
ORIENTAO
Ao atribuir IDs privilegiados, importante atribuir aos indivduos apenas os privilgios que eles precisam para desempenhar seu trabalho (o "mnimo de privilgios"). Por exemplo, o administrador do bando de dados ou do backup no deve ter os mesmos privilgios que o administrador dos sistemas como um todo. (Continua na prxima pgina) Conceder o mnimo de privilgios ajuda a evitar que usurios sem conhecimento suficiente sobre o aplicativo alterem incorretamente ou acidentalmente a configurao do aplicativo ou alterem seus ajustes de segurana. Executar o mnimo de privilgios tambm ajuda a minimizar os danos de uma pessoa no autorizada obter acesso ao ID do usurio. Quando as necessidades estiverem definidas para as funes do usurio (conforme o requisito 7.1.1 do PCI DSS), fcil conceder o acesso aos indivduos de acordo com sua funo e classificao de seu trabalho utilizando as funes j criadas. A aprovao documentada (por exemplo, por escrito ou eletronicamente) garante que as pessoas com acesso e privilgios estejam cientes e autorizadas pelo gerenciamento e que seu acesso seja necessrio para suas funes.
7.1.3 Conceda acesso com base na classificao e na atribuio da funo de cada indivduo da equipe.
7.1.3 Selecione uma amostra de IDs de usurio e questione a equipe de gerenciamento responsvel para verificar se os privilgios concedidos baseiam-se na classificao e atribuio da funo do indivduo.
7.1.4 Solicite aprovao documentada por partes autorizadas especificando os privilgios exigidos.
7.1.4 Selecione uma amostra dos IDs de usurio e compare com as aprovaes documentadas para verificar se: Existe aprovao documentada para os privilgios atribudos A aprovao foi realizada pelas partes autorizadas Os privilgios especificados correspondem com as funes atribudas ao indivduo.

7.2 Estabelea um sistema de controle de acesso para os componentes do sistema que restrinja o acesso com base na necessidade de conhecimento do usurio e que esteja 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 aos indivduos est baseada na classificao e na atribuio da funo. 7.2.3 Configurao padro recusar todos. 7.3 Certifique-se de que as polticas de segurana e procedimentos operacionais para restringir o acesso aos dados do portador do carto estejam documentados, em uso e conhecidos por todas as partes envolvidas.
7.2Analise as configuraes do sistema e a documentao do fornecedor para verificar se um sistema de controle de acesso foi implementado, conforme segue:
ORIENTAO
Sem um mecanismo para restringir o acesso com base na necessidade de conhecimento do usurio, este pode sem querer receber acesso aos dados do portador do carto. Um sistema de controle de acesso automatiza o processo de restringir o acesso e atribuir privilgios. Alm disso, uma configurao padro "recusar todos" garante que ningum tenha acesso at ou a menos que uma regra seja estabelecida especificamente concedendo este acesso. 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.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.3 Confirme se os sistemas de controle de acesso tm uma configurao padro recusar todos. 7.3 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para restringir o acesso aos dados do portador do carto esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para garantir que o acesso seja continuamente controlado e com base na necessidade de conhecimento e no mnimo de privilgios.
Requisito 8:
Identifique e autentique o acesso aos componentes do sistema
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 e podem ser rastreadas, por usurios e processos conhecidos e autorizados. A efetividade de uma senha largamente determinada pelo projeto e implementao do sistema de autenticao, particularmente, com que frequncia um invasor pode fazer tentativas de senha e os mtodos de segurana para proteger as senhas do usurio no ponto de entrada, durante a transmisso e enquanto estiver armazenada. 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 portador do carto ou acessar sistemas com dados do portador do carto. Isso inclui as contas usadas por fornecedores e outros terceiros (por exemplo, para suporte e manuteno). No entanto, os requisitos 8.1.1, 8.2, 8.5, 8.2.3 at o 8.2.5 e o 8.1.6 at o 8.1.8 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). REQUISITOS DO PCI DSS
8.1 Defina e implemente polticas e procedimentos para garantir o gerenciamento adequado da identificao do usurio para usurios que no sejam clientes e administradores em todos os componentes do sistema, conforme segue: 8.1.1Atribua a todos os usurios um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do portador do carto. 8.1.2Controle o acrscimo, a excluso e a modificao dos IDs do usurio, credenciais e outros objetos do responsvel pela identificao.
8.1.a Revise os procedimentos e confirme se eles definem processos para cada um dos itens abaixo em 8.1.1 at 8.1.8 8.1.b Verifique se os processos foram implementados para o gerenciamento de identificao do usurio, realizando o seguinte:
ORIENTAO
Ao garantir que todos os usurios sejam individualmente identificados, em vez de usar um ID para vrios funcionrios, uma organizao consegue manter a responsabilidade individual pelas aes e uma trilha de auditoria eficaz por funcionrio. Isso ajudar a apressar a resoluo e a conteno de problemas quando ocorrer mau uso ou tentativa mal-intencionada.
8.1.1Questione a equipe administrativa para confirmar se todos os usurios recebem um ID exclusivo para acessar os componentes do sistema ou os dados do portador do carto. 8.1.2 Para obter uma amostra dos IDs de usurios privilegiados e IDs de usurios gerais, analise as autorizaes associadas e observe os ajustes do sistema para verificar se cada ID do usurio e ID do usurio privilegiado foi implementado apenas com os privilgios especificados na aprovao documentada. Para garantir que as contas de usurio com acesso aos sistemas so todas usurios vlidos e reconhecidos, processos rigorosos devem controlar todas as modificaes nos IDs de usurio e outras credenciais de autenticao, incluindo adicionar novos e modificar ou excluir os existentes.

8.1.3 Revogue imediatamente o acesso de quaisquer usurios desligados da empresa.
8.1.3.a Selecione uma amostra de funcionrios desligados da empresa nos ltimos seis meses e analise as listas de acesso dos usurios atuais,tanto para o acesso remoto quanto o local, a fim de verificar se seus IDs foram desativados ou removidos das listas de acesso. 8.1.3.b Verifique se todos os mtodos fsicos de autenticao (como smart cards, tokens, etc.) tenham sido devolvidos ou desativados.
ORIENTAO
Se um funcionrio sair da empresa e ainda tiver acesso rede por meio de sua conta de usurio, pode ocorrer um acesso desnecessrio ou malintencionado aos dados do portador do carto, pelo antigo funcionrio ou por um usurio malintencionado que se aproveite da conta antiga e no utilizada. Para prevenir o acesso no autorizado, as credenciais do usurio e outros mtodos de autenticao precisam ser revogados imediatamente (assim que possvel) sada do funcionrio. As contas no usadas regularmente so alvos frequentes de invases, pois menos provvel que qualquer alterao (como uma senha alterada) seja notada. Desse modo, estas contas podem ser aproveitadas mais facilmente e usadas para acessar os dados do portador do carto. Permitir que fornecedores tenham acesso integral sua rede caso eles precisem dar suporte ao seu sistema aumenta as chances de acesso no autorizado, seja de um usurio no ambiente do fornecedor ou de um indivduo mal-intencionado que descubra e use esse ponto de entrada externo sempre pronto para sua rede. Ativar o acesso apenas pelos perodos de tempo necessrios e desativar assim que no for mais necessrio, ajuda a prevenir o mau uso destas conexes. O monitoramento do acesso do fornecedor proporciona a garantia de que os fornecedores estejam acessando apenas os sistemas necessrios e somente durante os perodos de tempo aprovados. Sem a implementao de mecanismos de bloqueio de conta, um invasor pode tentar continuamente adivinhar uma senha por meio de ferramentas manuais ou automatizadas (por exemplo, cracking de senha) at ter sucesso e ganhar acesso conta Pgina 73 Novembro de 2013
8.1.4 Remover/desativar as contas inativas dos usurios pelo menos a cada 90 dias.
8.1.4Observe as contas do usurio para verificar se as contas inativas por mais de 90 dias so removidas ou desativadas.
8.1.5 Controle as IDs usadas pelos fornecedores para acessar, suportar ou manter os componentes do sistema por meio de acesso remoto, conforme segue: Ativar apenas durante o perodo necessrio e desativar quando no estiverem em uso. Monitorar quando estiverem em uso.
8.1.5.a Questione os funcionrios e observe os processos para controlar as contas usadas pelos fornecedores para acessar, suportar ou manter os componentes do sistema para verificar se as contas usadas por fornecedores por meio de acesso remoto so: Desativadas quando no estiverem em uso Ativadas apenas quando necessrio para o fornecedor e desativadas quando no estiverem em uso. 8.1.5.b Questione os funcionrios e observe os processos para verificar se as contas de acesso remoto do fornecedor so monitoradas quando esto em uso.
8.1.6 Limite tentativas de acesso repetidas bloqueando o ID do usurio aps seis tentativas, no mximo.
8.1.6.a Para obter uma amostra dos componentes do sistema, inspecione as configuraes do sistema para verificar se os parmetros de autenticao esto definidos para exigir que as contas de usurios sejam bloqueadas aps seis tentativas invlidas de efetuar logon.
8.1.6.b Procedimento de teste adicional para prestadores de servios: Analise os processos internos e a documentao do cliente/usurio e observe os processos implementados para verificar se as contas do usurio que no cliente so bloqueadas temporariamente aps seis tentativas invlidas de acesso. do usurio.
ORIENTAO
8.1.7Defina a durao do bloqueio para um mnimo de 30 minutos ou at que o administrador ative o ID do usurio.
8.1.7 Para obter uma amostra dos componentes do sistema, analise as configuraes do sistema para verificar se os parmetros de senha esto 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.
Se uma conta estiver bloqueada em funo de uma pessoa tentar continuamente adivinhar a senha, os controles para atrasar a reativao dessas contas bloqueadas evitaro que o indivduo malintencionado continue a tentar adivinhar a senha (ele ter de parar por pelo menos 30 minutos at a conta ser reativada). Alm disso, se a reativao precisar ser solicitada, a administrao ou o servio de suporte pode validar se o real proprietrio da conta que est solicitando a reativao. Quando os usurios se distanciam de uma mquina aberta com acesso a componentes crticos do sistema e dados do portador do carto, essa mquina poder ser usada por outras pessoas na ausncia do usurio, resultando em acesso no autorizado conta e/ou mau uso dela. A reautenticao pode ser aplicada no nvel de sistema para proteger todas as sesses em funcionamento naquela mquina, ou no nvel de aplicativo.
8.1.8 Se uma sesso estiver ociosa por mais de 15 minutos, solicite que o usurio redigite a senha para reativar o terminal.
8.1.8 Para obter uma amostra dos componentes do sistema, 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.2Alm de atribuir uma ID exclusiva, garanta que um controle adequado da autenticao do usurio para usurios que no sejam clientes e administradores em todos os componentes do sistema, empregando pelo menos um dos mtodos a seguir para autenticar todos os usurios: Algo que voc sabe, como uma senha ou frase de senha Algo que voc tem, como um dispositivo de token ou um smart card Algo que voc , como a biomtrica.
8.2Para verificar se os usurios so autenticados usando o ID exclusivo e a autenticao adicional (por exemplo, uma senha/frase) para acessar o ambiente de dados do portador do carto, desempenhe o seguinte: 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 a autenticao est sendo executada de acordo com o(s) mtodo(s) de autenticao documentado(s).
ORIENTAO
Esses mtodos de autenticao, quando usados alm dos IDs exclusivos, ajudam a proteger os IDs dos usurios contra o comprometimento, visto que quem estiver tentando as necessidades de comprometimento precisa conhecer tanto o ID exclusivo quanto a senha (ou outro item de autenticao). Observe que um certificado digital uma opo vlida para "algo que voc tem" desde que seja exclusivo. Como uma das primeiras etapas tomadas por um indivduo mal-intencionado para comprometer um sistema explorar senhas fracas ou inexistentes, importante implementar bons processos para controle de autenticao.

8.2.1 Use criptografia forte, converta todas as credenciais de autenticao (como senhas/frases) ilegveis durante a transmisso e armazenamento em todos os componentes do sistema.
8.2.1.a Analise a documentao do fornecedor e os ajustes da configurao do sistema para verificar se as senhas esto protegidas com criptografia forte durante a transmisso e o armazenamento. 8.2.1.bPara obter uma amostra dos componentes do sistema, analise os arquivos de senha para verificar se as senhas esto ilegveis durante o armazenamento. 8.2.1.cPara obter uma amostra dos componentes do sistema, analise as transmisses de dados para verificar se as senhas esto ilegveis durante a transmisso. 8.2.1.d Procedimento de teste adicional para prestadores de servios: Observe os arquivos de senha para verificar se as senhas do cliente esto ilegveis durante o armazenamento. 8.2.1.e Procedimento de teste adicional para prestadores de servios: Observe as transmisses de dados para verificar se as senhas do cliente esto ilegveis durante a transmisso.
ORIENTAO
Muitos dispositivos de rede e aplicativos transmitem senhas sem criptografia e legveis por uma rede e/ou armazenam as senhas sem criptografia. Um indivduo mal-intencionado pode facilmente interceptar as senhas sem criptografia durante a transmisso usando um sniffer, ou ento acessar diretamente as senhas no criptografas em arquivos onde eles so armazenados e usar esses dados para obter acesso no autorizado.
8.2.2 Verifique a identidade do usurio antes de modificar qualquer credencial de autenticao, por exemplo, executar restaurao da senha, provisionar novos tokens ou gerar novas chaves.
8.2.2Analise os procedimentos de autenticao para modificar as credenciais de autenticao e observe a equipe de segurana para verificar se, caso um usurio solicite uma redefinio credencial de autenticao por telefone, e-mail, Web ou outro mtodo remoto, a identidade do usurio comprovada antes que a credencial de autenticao seja modificada.
Muitos indivduos mal-intencionados usam a engenharia social (por exemplo, ligam para o servio de suporte e agem como um usurio legtimo) para trocar a senha, de forma que possam utilizar um ID de usurio. Considere usar uma pergunta secreta que s o prprio usurio possa responder para ajudar os administradores a identificar o usurio antes de redefinir ou modificar as credencias de autenticao.

8.2.3 As senhas/frases devem atender ao seguinte: Exigir uma extenso mnima de pelo menos sete caracteres. Conter caracteres numricos e alfabticos. Alternativamente, as senhas/frases devem ter complexidade e fora pelo menos equivalentes aos parmetros especificados acima.
8.2.3a Para obter uma amostra dos componentes do sistema, analise as definies de configurao do sistema para verificar se os parmetros de senha do usurio esto definidos para solicitar pelo menos a seguinte complexidade/fora: Exigir uma extenso mnima de pelo menos sete caracteres. Conter caracteres numricos e alfabticos. 8.2.3.b Procedimento de teste adicional para prestadores de servios: Analise os processos internos e a documentao do cliente/usurio para verificar se as senhas do usurio que no cliente so exigidas para atender pelo menos a seguinte complexidade/fora: Exigir uma extenso mnima de pelo menos sete caracteres. Conter caracteres numricos e alfabticos.
ORIENTAO
Senhas/frases fortes so a primeira linha de defesa para uma rede, pois um indivduo mal-intencionado muitas vezes tentar primeiro encontrar contas com senhas fracas ou inexistentes. Se as senhas forem curtas ou fceis de adivinhar, relativamente fcil para um indivduo mal-intencionado localizar essas contas fracas e comprometer uma rede parecendo um ID de usurio vlido. Este requisito especifica se os sete caracteres numricos e alfabticos devem ser usados para senhas/frases. Para os casos em que este mnimo no possvel devido a limitaes tcnicas, as entidades podem usar "fora equivalente" para avaliar sua alternativa. O NIST SP 800-63-1 define "entropia" como "uma medida de dificuldade de adivinhar ou determinar uma senha ou chave". Este documento e outros que abordam a "entropia de senha" podem ser consultados para obter mais informaes em valor de entropia aplicvel e para o entendimento da variao da fora equivalente da senha para senhas/frases de diferentes formatos. As senhas que esto vlidas por muito tempo sem modificao proporcionam mais tempo a indivduos mal-intencionados para tentar burlar a senha/frase.
8.2.4 Altere as senhas/frases do usurio pelo menos a cada 90 dias.
8.2.4.a Para obter uma amostra dos componentes do sistema, analise as definies de configurao do sistema para verificar se os parmetros de senha do usurio esto definidos para solicitar que os usurios alterem as senhas pelo menos a cada 90 dias. 8.2.4.b Procedimento de teste adicional para prestadores de servios: Revise os processos internos e a documentao do cliente/usurio para verificar se: As senhas dos usurios que no so clientes devem ser alteradas periodicamente; e Usurios que no so clientes recebem instrues sobre quando e sob quais circunstncias as senhas devem ser alteradas.

8.2.5 No permita que ningum envie uma nova senha que seja a mesma de uma das quatro ltimas senhas que tenha sido usada.
8.2.5.a Para obter uma amostra dos componentes do sistema, obtenha e analise as definies da configurao do sistema para verificar se os parmetros de senha esto definidos para solicitar que as novas senhas no possam ser iguais s quatro senhas usadas anteriormente. 8.2.5.b Procedimento de teste adicional para prestadores de servios: Analise os processos internos e a documentao do cliente/usurio para verificar se as novas senhas do usurio que no cliente no podero ser iguais s quatro senhas anteriores.
ORIENTAO
Se o histrico da senha no for mantido, a efetividade da alterao da senha reduzida, j que as senhas anteriores podem ser reutilizadas vrias vezes. Determinar que as senhas no sejam reutilizadas por um perodo de tempo reduz a probabilidade de que senhas que foram adivinhadas ou violadas sejam usadas futuramente.
8.2.6 Defina as senhas/frases para o primeiro uso e ao reiniciar com um valor exclusivo para cada usurio e altere imediatamente aps a primeira utilizao. 8.3 Incorpore autenticao de dois fatores para o acesso de rede remota originado fora da rede por funcionrios (incluindo usurios e administradores) e todos os terceiros (incluindo acesso do fornecedor para suporte ou manuteno). 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, usar duas senhas separadas) no caracteriza autenticao de dois fatores. Exemplos de tecnologias de dois fatores incluem autenticao remota e servio de dial-in (RADIUS) com tokens; sistema de controle de acesso ao controlador de acesso ao terminal (TACACS) com tokens; e outras tecnologias que
8.2.6 Analise os procedimentos de senha e observe a equipe de segurana para verificar se as senhas iniciais para usurios novos e senhas de reinicializao para usurios existentes so definidas com um valor exclusivo para cada usurio e alteradas aps a primeira utilizao. 8.3.a Analise as configuraes do sistema para os sistemas e servidores de acesso remoto para verificar se a autenticao de dois fatores exigida para: Todos os acessos remotos dos funcionrios Todos os acessos remotos de fornecedores/terceiros (incluindo acesso aos componentes do sistema e aplicativos para suporte ou manuteno). 8.3 Observe um exemplo da equipe (por exemplo, usurios e administradores) conectando-se remotamente rede e verifique se pelo menos dois dos trs mtodos de autenticao so usados.
Se a mesma senha for usada para cada novo usurio, um usurio interno, ex-funcionrio ou indivduo mal-intencionado poder conhecer ou descobrir facilmente essa senha e us-la para obter acesso s contas. A autenticao de dois fatores exige duas formas de autenticao para acessos com maior risco, como aqueles originados de fora de rede Esse requisito se aplica a toda a equipe, incluindo usurios gerais, administradores e fornecedores (para suporte ou manuteno), com acesso remoto rede, onde esse acesso remoto possa levar ao acesso do ambiente de dados do portador do carto. Se o acesso remoto for para a rede de uma entidade que possui segmentao adequada, como a impossibilidade de acesso por parte dos usurios remotos ou de impacto ao ambiente de dados do portador do carto, a autenticao de dois fatores para o acesso remoto quela rede no ser exigida. No entanto, a autenticao de dois fatores exigida para qualquer acesso remoto a redes com acesso ao ambiente de dados do portador do carto e recomendvel para todo o acesso remoto a redes de entidades.

facilitam a autenticao de dois fatores. 8.4 Registre e comunique os procedimentos e polticas de autenticao a todos os usurios, incluindo: Orientao sobre selecionar credenciais fortes de autenticao Orientao sobre como os usurios devem proteger suas credenciais de autenticao Instrues para no reutilizar senhas anteriormente usadas Instrues para alterar a senha se houver suspeita de que ela possa estar comprometida.
8.4.a Analise os procedimentos e questione os funcionrios para verificar se os procedimentos e polticas de autenticao so distribudos para todos os usurios. 8.4.b Analise os procedimentos e polticas de autenticao que so distribudos aos usurios e verifique se eles incluem: Orientao sobre selecionar credenciais fortes de autenticao Orientao sobre como os usurios devem proteger suas credenciais de autenticao. Instrues para os usurios no reutilizarem senhas anteriormente usadas Instrues para alterar a senha se houver suspeita de que ela possa estar comprometida. 8.4.c Questione alguns usurios para verificar se eles esto familiarizados com os procedimentos e polticas de autenticao.
ORIENTAO
Comunicar os procedimentos de autenticao/senha para todos os usurios ajuda-os a compreender e cumprir com as polticas. Por exemplo, a orientao sobre selecionar senhas fortes pode incluir sugestes para ajudar a equipe a selecionar senhas difceis de adivinhar que no contenham palavras do dicionrio e informaes sobre o usurio (como ID do usurio, nomes de familiares, data de aniversrio, etc.). A orientao para proteger as credenciais de autenticao pode incluir no anotar senhas ou salv-las em arquivos no seguros e estar alerta a indivduos malintencionados que possam tentar explorar suas senhas (por exemplo, ligando para um funcionrio e perguntando sua senha para que ele possa resolver um problema). Instruir os usurios a alterar suas senhas se houver a possibilidade de ela no ser mais segura pode evitar que usurios mal-intencionados usem uma senha legtima para obter acesso no autorizado. Se vrios usurios compartilharem as mesmas credenciais de autenticao (conta e senha, por exemplo), torna-se impossvel controlar o acesso ao sistema e atividades de um indivduo. Isso evita que uma entidade assuma a responsabilidade de, ou faa um registro eficaz das aes de um indivduo, pois uma determinada ao pode ter sido executada por qualquer pessoa no grupo que saiba as credencias de autenticao.
8.5 No use IDs de grupos, compartilhados ou genricos, senhas ou outros mtodos de autenticao conforme segue: IDs genricos de usurios so desativados ou removidos. IDs de usurios compartilhados no existem para a administrao do sistema e outras funes crticas. IDs de usurios compartilhados e genricos no so usados para administrar quaisquer componentes do sistema.
8.5.aPara obter uma amostra dos componentes do sistema, analise as listas de ID do usurio para verificar o seguinte: IDs genricos de usurios so desativados ou removidos. IDs de usurios compartilhados para atividades de administrao do sistema e outras funes crticas no existem. IDs de usurios compartilhados e genricos no so usados para administrar quaisquer componentes do sistema. 8.5.b Analise as polticas/procedimentos de autenticao para verificar se o uso de senhas e/ou IDs compartilhados e de grupo ou outros mtodos de autenticao so explicitamente proibidos. 8.5.c Questione os administradores do sistema para verificar se as senhas e/ou IDs de grupo ou compartilhados ou outros mtodos de autenticao no so distribudos, mesmo se forem solicitados.

8.5.1 Requisito adicional para prestadores de servios: Os prestadores de servio com acesso remoto ao local do cliente (por exemplo, para suporte de servidores ou sistemas POS) devem usar uma credencial de autenticao exclusiva (como uma senha/frase) para cada cliente. Observao: Este requisito no tem o objetivo de se aplicar a provedores de hospedagem compartilhada que acessam seu prprio ambiente de hospedagem, onde vrios ambientes do cliente so hospedados. Observao: O requisito 8.5.1 considerado uma das melhores prticas at 30 de junho de 2015 quando passar a ser um requisito. 8.6 Onde forem usados outros mecanismos de autenticao (por exemplo, tokens de segurana fsicos ou virtuais, smart cards, certificados, etc.), o uso destes mecanismos deve ser atribudo conforme segue: Os mecanismos de autenticao devem ser atribudos a uma conta individual e no compartilhados entre vrias contas. Controles fsicos e/ou virtuais devem ser implementados para garantir que apenas a conta pretendida possa usar o mecanismo para obter acesso.
8.5.1 Procedimento de teste adicional para prestadores de servios: Analise as polticas e procedimentos de autenticao e questione os funcionrios para verificar se so usadas autenticaes diferentes para acesso a cada cliente.
ORIENTAO
Para prevenir o comprometimento de vrios clientes devido ao uso de um conjunto nico de credenciais, os fornecedores com contas de acesso remoto aos ambientes do cliente devem usar uma credencial de autenticao diferente para cada cliente. Tecnologias, como mecanismos de dois fatores, que oferecem uma credencial nica para cada conexo (por exemplo, por meio de uma senha de uso comum) tambm podem atender ao objetivo deste requisito.
8.6.a Analise as polticas e procedimentos de autenticao para verificar se os procedimentos para usar os mecanismos de autenticao, como tokens de segurana fsicos, smart cards e certificados esto definidos e incluem: Os mecanismos de autenticao so atribudos a uma conta individual e no compartilhados entre vrias contas. Controles fsicos e/ou virtuais esto definidos para garantir que apenas a conta pretendida possa usar o mecanismo para obter acesso.
Se os mecanismos de autenticao do usurio, como tokens, smart cards e certificados puderem ser usados por vrias contas, pode ser impossvel identificar o indivduo que utiliza o mecanismo de autenticao. Ter controles fsicos e/ou virtuais (por exemplo, um PIN, dados biomtricos ou uma senha) para identificar exclusivamente o usurio da conta evitar que usurios no autorizados obtenham acesso atravs do uso de um mecanismo de autenticao compartilhado.
8.6.b Questione a equipe de segurana para verificar se os mecanismos de autenticao so atribudos a uma conta e no compartilhados entre vrias contas. 8.6.c Analise os ajustes da cofigurao do sistema e/ou os controles fsicos, conforme aplicvel, para verificar se os controles esto implementados para garantir que apenas a conta pretendida possa usar o mecanismo para obter acesso.
ORIENTAO
8.7 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) so restritos conforme segue: Todos os acessos, consultas e aes do usurio no banco de dados ocorrem atravs de mtodos programticos. Apenas os administradores do banco de dados podem acessar diretamente ou consultar o banco de dados. Os IDs dos aplicativos para os aplicativos do banco de dados s podem ser usados pelos aplicativos (e no por usurios individuais ou outros processos sem aplicativo).
8.7.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.7.b Analise as definies de configurao do aplicativo e do banco de dados para verificar se todos os acessos, consultas 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.7.c Analise as configuraes do controle de acesso do banco de dados e as definies de configurao do aplicativo e do banco de dados para verificar se o acesso direto ou consultas ao banco de dados so restritos aos administradores. 8.7.d Analise as configuraes do controle de acesso do banco de dados, as definies de configurao do aplicativo 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). 8.8 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para identificao e autenticao esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
Sem autenticao do usurio para acesso a bancos de dados e aplicativos, o potencial para acesso no autorizado ou mal-intencionado aumenta e esse acesso no pode ser registrado, pois o usurio no foi autenticado e, assim, no conhecido pelo sistema. Alm disso, o acesso ao banco de dados s deve ser concedido por meio de mtodos programticos (por exemplo, por meio de procedimentos armazenados) e no por acesso direto ao banco de dados por usurios finais (exceto para DBAs, que podem precisar de acesso direto ao banco de dados para as tarefas administrativas).
8.8 Certifique-se de que as polticas de segurana e procedimentos operacionais para identificao e autenticao estejam documentados, em uso e conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para controlar continuamente as identificaes e autorizaes.
Requisito 9:
Restrinja o acesso fsico aos dados do portador 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 portador do carto.
9.1Use controles de entrada facilitados e adequados para limitar e monitorar o acesso fsico aos sistemas no ambiente de dados do portador 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 portador 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 logon 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.
ORIENTAO
Sem controles fsicos de acesso, como sistemas de crachs e controles de porta, usurios no autorizados podem facilmente obter acesso s instalaes para roubar, desativar, interromper ou destruir sistemas crticos e dados do portador do carto. Bloquear telas de logon em consoles evita que pessoas no autorizadas obtenham acesso a informaes confidenciais, alterando as configuraes do sistema, introduzindo vulnerabilidades na rede ou destruindo registros. Ao investigar violaes fsicas, esses controles podem ajudar a identificar indivduos que acessaram fisicamente as reas confidenciais,
9.1.1 Use cmeras de vdeo ou outros mecanismos de controle de acesso para monitorar o acesso fsico
9.1.1.a Verifique se cmeras de vdeo e/ou outros mecanismos de controle de acesso foram implantados para monitorar os pontos de entrada/sada das reas confidenciais.

individual a reas confidenciais. Analise os dados coletados e relacione com outras entradas. Armazene, 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 portador do carto. Isso exclui reas voltadas ao pblico nas quais h somente terminais do ponto de venda presentes, como as reas dos caixas em uma loja de varejo.
9.1.1.b Verifique se cmeras de vdeo ou outros mecanismos de controle de acesso esto protegidos contra adulterao ou desativao.
ORIENTAO
bem como quando eles entraram e saram. Criminosos que tentam obter acesso fsico s reas confidenciais muitas vezes tentaro desativar ou desviar os controles de monitoramento. Para proteger estes controles contra adulteraes, cmeras de vdeo podem ser posicionadas de forma que fiquem fora de alcance e/ou sejam monitoradas para detectar falsificaes. Da mesma forma, os mecanismos de controle de acesso podem ser monitorados ou ter protees fsicas instaladas para evitar que sejam danificados ou desativados por indivduos malintencionados. (Continua na prxima pgina)
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.
Exemplos de reas confidenciais incluem salas de servidor do banco de dados corporativo, salas de escritrios administrativos em um local de revenda que armazene dados do portador do carto e reas de armazenamento de grandes quantidades de dados do portador do carto. As reas confidenciais devem ser identificadas por cada organizao para garantir que os controles de monitoramento fsicos adequados sejam implementados.

9.1.2 Implemente controles fsicos e/ou virtuais para restringir o acesso a pontos de rede acessveis publicamente. Por exemplo, pontos de rede localizados em reas pblicas e reas acessveis a visitantes podem ser desativados e somente ativados quando o acesso rede explicitamente autorizado. Alternativamente, processos podem ser implementados para garantir que os visitantes sempre sejam acompanhados nas reas com pontos de rede ativos. 9.1.3 Restrinja o acesso fsico a pontos sem fio de acesso, gateways, dispositivos portteis, hardwares de comunicao/rede e linhas de telecomunicao.
9.1.2 Questione os funcionrios responsveis e observe os locais de pontos de rede publicamente acessveis para verificar se controles fsicos e/ou virtuais esto implementados para restringir o acesso a estes pontos de rede.
ORIENTAO
Restringir o acesso aos pontos de rede (ou portas de rede) evita que indivduos mal-intencionados se conectem em pontos de rede prontamente disponveis e obtenham acesso aos recursos de rede internos. Se forem usados controles fsicos ou virtuais, ou os dois, eles devem ser suficientes para evitar que um indivduo ou dispositivo no autorizado consiga se conectar rede.
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.
Sem segurana no acesso a componentes e dispositivos sem fio, indivduos mal-intencionados podem usar os dispositivos sem fio da sua empresa que no estejam sendo utilizados para acessar os recursos de rede ou at para conectar seus prprios dispositivos rede sem fio para obter acesso no autorizado. Alm disso, fazer a segurana dos materiais de comunicao e rede evita que usurios mal-intencionados interceptem o trfego da rede ou conectem fisicamente seus prprios dispositivos aos recursos de rede com fio. Identificar visitantes autorizados para que sejam facilmente distinguidos dos funcionrios do local evita que os visitantes no autorizados acessem reas contendo dados do portador do carto.
9.2 Desenvolva procedimentos para diferenciar facilmente a equipe interna dos visitantes e inclua: Identificar novos funcionrios ou visitantes (por exemplo, conceder crachs) Modificaes nos requisitos de acesso Anular ou excluir identificaes de funcionrios que se desligaram da
9.2 Analise os processos documentados para verificar se esto definidos procedimentos para identificar e diferenciar os funcionrios dos visitantes. Verifique se os processos incluem o seguinte: Identificar novos funcionrios ou visitantes (por exemplo, conceder crachs), Modificar os requisitos de acesso e Anular identificaes de funcionrios que se desligaram da empresa e de visitantes que encerraram sua atividade (como crachs de identificao)

empresa e de visitantes que encerraram sua atividade (como crachs de identificao).
9.2.b Observe os processos para identificar e diferenciar os funcionrios dos visitantes para verificar se: Os visitantes so claramente identificados, e fcil diferenciar os visitantes dos membros da equipe interna. 9.2.c Verifique se o acesso ao processo de identificao (como um sistema de crachs) limitado a funcionrios autorizados. 9.2.d Analise os mtodos de identificao (como crachs de identificao) em uso para verificar se identificam claramente os visitantes e se fcil distinguir funcionrios de visitantes.
ORIENTAO
9.3 Controle o acesso fsico dos funcionrios s reas confidenciais conforme segue: O acesso deve ser autorizado e com base na funo do indivduo. O acesso anulado imediatamente ao trmino da atividade e todos os mecanismos de acesso fsico, como chaves, cartes de acesso, etc., so devolvidos e desativados.
9.3.a Para obter uma amostra de funcionrios com acesso fsico ao CDE, questione o funcionrio responsvel e observe as listas de controle de acesso para verificar se: O acesso ao CDE est autorizado. O acesso necessrio para a funo da pessoa. 9.3.b Observe o acesso dos funcionrios ao CDE para verificar se todos so autorizados antes de receberem o acesso. 9.3.c Selecione exemplos de funcionrios desligados e revise as listas de controle de acesso para verificar se os mesmos no tm acesso fsico ao CDE.
Controlar o acesso fsico ao CDE ajuda a garantir que apenas funcionrios autorizados com necessidade comercial legtima tero acesso. Quando um funcionrio deixa a empresa, todos os mecanismos de acesso fsico devem ser devolvidos e desativados imediatamente (assim que possvel) aps a sua sada, para garantir que ele no tenha acesso fsico ao CDE quando no for mais funcionrio da empresa.

9.4 Implemente procedimentos para identificar e autorizar visitantes. Os procedimentos devem incluir o seguinte: 9.4.1 Os visitantes devem obter autorizao antes de entrar e serem sempre acompanhados em reas nas quais os dados do portador do carto so processados ou mantidos.
9.4 Verifique se os controles de acesso e autorizao dos visitantes esto implementados da seguinte forma:
ORIENTAO
O controle de visitantes importante para reduzir a possibilidade de pessoas no autorizadas e malintencionadas obterem acesso s instalaes (e possivelmente aos dados do portador do carto). Os controles de visitantes garantem que eles sejam identificados como visitantes, de forma que os funcionrios possam monitorar suas atividades e que o acesso esteja restrito somente durao de sua visita. Garantir que os crachs de visitantes sejam devolvidos ao final de sua visita evita que pessoas mal-intencionadas utilizem uma passagem anteriormente autorizada para obter acesso fsico ao prdio aps o trmino de sua visita. Um log de visitantes documentando as informaes mnimas sobre eles de manuteno fcil e barata e ajuda a identificar o acesso fsico a um edifcio ou a uma sala e um possvel acesso aos dados do portador do carto.
9.4.1.a Observe os procedimentos e questione os funcionrios para verificar se os visitantes devem obter autorizao antes de entrar e serem sempre acompanhados em reas nas quais os dados do portador do carto so processados ou mantidos. 9.4.1.b Observe o uso dos crachs de visitante ou outra identificao para verificar se um crach de token fsico no permite acesso desacompanhado a reas fsicas onde os dados do portador do carto so processados ou mantidos. 9.4.2.a Observe as pessoas na instalao para verificar o uso dos crachs de visitante ou outra identificao e se fcil distinguir os visitantes dos funcionrios. 9.4.2.b Verifique se os crachs de visitante ou outra identificao tm validade. 9.4.3 Observe os visitantes que saem das dependncias para verificar se solicitado que eles apresentem seu crach ou outra identificao na sada ou ao vencimento. 9.4.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. 9.4.4.b Verifique se o registro contm: O nome do visitante, A empresa representada, e O funcionrio que autoriza o acesso fsico.
9.4.2 Os visitantes so identificados e recebem um crach ou outra identificao que expira e que distingue visivelmente os visitantes dos funcionrios internos. 9.4.3 solicitado que os visitantes apresentem o crach ou identificao antes de sair das dependncias ou na data do vencimento. 9.4.4 Um registro de visitantes usado para manter uma trilha de auditoria da atividade do visitante nas dependncias, assim como aos ambientes com computador e centrais de dados onde os dados do portador do carto so armazenados ou transmitidos. 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 Proteja toda a mdia fisicamente.
9.4.4.c Verifique se o registro mantido por pelo menos trs meses.
ORIENTAO
9.5 Verifique se os procedimentos para proteger os dados do portador do carto incluem controles para proteger fisicamente todas as mdias (incluindo, entre outros, a computadores, mdias eletrnicas removveis, recebimentos de documentos impressos, relatrios impressos e faxes).
Os controles para proteger fisicamente as mdias tm o objetivo de evitar que pessoas no autorizadas obtenham acesso aos dados do portador do carto em qualquer tipo de mdia. Os dados do portador do carto estaro suscetveis a visualizao, cpia ou digitalizao no autorizada caso estejam desprotegidos enquanto estiverem em mdia porttil, forem impressos ou deixados na mesa de algum. Se armazenados em um local no protegido, os backups que contm dados do portador do carto podem ser facilmente perdidos, roubados ou copiados com ms intenes. Revisar periodicamente o local de armazenamento permite que a organizao resolva problemas de segurana em tempo hbil, minimizando o potencial de risco. Procedimentos e processos ajudam a proteger os dados do portador do carto em mdias distribudas a usurios internos e/ou externos. Sem tais procedimentos, os dados podero ser perdidos ou roubados e usados para fins fraudulentos.
9.5.1 Armazene backups de mdia em um local seguro, preferencialmente em outras instalaes, como um lugar alternativo de backup ou uma instalao comercial de armazenamento. Analise a segurana do local pelo menos uma vez por ano.
9.5.1.a Observe a segurana fsica do local de armazenamento para confirmar que o armazenamento da mdia de backup est seguro. 9.5.1.b Verifique se a segurana do local de armazenamento revisada ao menos anualmente.
9.6 Mantenha controle rigoroso quanto distribuio interna ou externa de qualquer tipo de mdia, incluindo o seguinte:
9.6 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.6.1 Classifique a mdia para que a confidencialidade dos dados possa ser determinada.
9.6.1 Verifique se toda a mdia foi classificada para que a confidencialidade dos dados possa ser determinada.
ORIENTAO
importante que a mdia seja identificada para que seu status de classificao possa ser facilmente discernvel. A mdia no identificada como confidencial pode no ser protegida adequadamente ou ser roubada. Observao: Isto no significa que as mdias precisam ter anexado um rtulo "Confidencial"; o objetivo que a organizao tenha identificado a mdia que contm dados confidenciais para que possa proteg-los.
9.6.2 Envie a mdia via mensageiro seguro ou outro mtodo de entrega que possa ser monitorado com preciso.
9.6.2.a Questione os funcionrios e analise os registros para verificar se toda a mdia enviada para fora das dependncias registrada e encaminhada via mensageiro seguro ou outro mtodo de entrega que possa ser monitorado. 9.6.2.b Selecione um exemplo recente de vrios dias de registros de monitoramento externo para todas as mdias e verifique se os detalhes de rastreamento esto documentados.
A mdia pode ser perdida ou roubada se for enviada por um mtodo no rastrevel, como remessa postal. O uso de mensageiros seguros para entregar mdias que contenham dados do portador do carto permite que as organizaes usem seus sistemas de rastreamento para manter inventrio e localizao dos envios. Sem um processo rigoroso para garantir que todos os movimentos de mdia sejam aprovados antes que ela seja removida das reas seguras, a mdia no seria rastreada ou adequadamente protegida e sua localizao seria desconhecida, levando a mdias perdidas ou roubadas. Sem mtodos cuidadosos de inventrio e controles de armazenamento, mdias roubadas ou ausentes podem passar despercebidas por tempo indefinido. Se a mdia no passar por inventrio, mdias roubadas ou perdidas podem passar despercebidas por bastante tempo.
9.6.3 Certifique-se de que o gerenciamento aprova quaisquer e todas as mdias que so movidas de uma rea segura (incluindo quando as mdias forem distribudas s pessoas).
9.6.3 Selecione um exemplo recente de vrios dias de logs de monitoramento externo para todas as mdias. A partir da anlise dos registros e questionamentos com os funcionrios responsveis, verifique se obtida a autorizao adequada do gerenciamento sempre que as mdias forem movidas de uma rea segura (incluindo quando as mdias forem distribudas s pessoas). 9.7 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.7.1 Revise o registro do inventrio das mdias para verificar se os registros so mantidos e se os inventrios de mdia so realizados pelo menos uma vez por ano.
9.7 Mantenha um controle rigoroso sobre o armazenamento e a acessibilidade das mdias. 9.7.1 Mantenha adequadamente os registros do inventrio de todas as mdias e realize inventrios das mdias pelo menos uma vez por ano.

9.8 Destrua as mdias quando no forem mais necessrias por motivos legais ou de negcios, conforme segue:
9.8 Analise a poltica de destruio peridica das mdias e verifique se ela abrange todas as mdias e se define requisitos para o seguinte: Materiais impressos devem ser triturados, incinerados ou amassados de forma que haja uma garantia razovel de que esses materiais no possam ser recuperados. Os containers de armazenamento usados para os materiais a serem destrudos devem estar seguros. Os dados do portador do carto nas mdias eletrnicas devem ser indisponibilizados por meio de um programa de limpeza segura (de acordo com os padres aceitos pelo setor quanto excluso segura) ou destruindo fisicamente as mdias.
ORIENTAO
Se as etapas no forem seguidas par destruir as informaes contidas em discos rgidos, drives portteis, CD/DVDs ou papis antes do descarte, indivduos mal-intencionados poder estar aptos a recuperar as informaes da mdia descartada, levando ao comprometimento dos dados. Por exemplo, indivduos mal-intencionados podem usar uma tcnica conhecida como dumpster diving, na qual eles pesquisam em lixeiras e usam as informaes encontradas para iniciar um invaso. Proteger os containers de armazenamento usados para os materiais que sero destrudos evita que informaes confidenciais sejam capturadas enquanto os materiais esto sendo coletados. Por exemplo, containers "a serem triturados" podem ter um bloqueio que evita o acesso a seu contedo ou que previna fisicamente o acesso para dentro do continer. Exemplos de mtodos para destruir mdias eletrnicas incluem limpeza segura, desmagnetizao ou destruio fsica (como esmagar ou triturar os discos rgidos).
9.8.1 Triture, incinere ou amasse materiais impressos para que os dados do portador do carto no possam ser recuperados. Containers de armazenamento usados para os materiais a serem destrudos.
9.8.1.a Questione os funcionrios e analise os procedimentos para verificar se os materiais impressos so picotados, triturados, incinerados ou amassados para que haja garantia razovel de que no possam ser reconstitudos. 9.8.1.b Analise os contineres de armazenamento usados para os materiais que contm informaes a serem destrudas para verificar se so seguros. 9.8.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).
9.8.2 Torne os dados do portador do carto nas mdias eletrnicas irrecuperveis para que esses dados no possam ser reconstitudos.

9.9Proteja contra falsificao e substituio os dispositivos que capturam os dados do carto de pagamento por meio de interao fsica direta com o carto. Observao: Estes requisitos se aplicam aos dispositivos de leitura do carto usados em transaes com a presena do carto (ou seja, de passar ou inserir) no ponto de venda. Este requisito no tem o objetivo de se aplicar aos componentes de entrada de chave manual, como teclados de computador e teclados POS. Observao: O requisito 9.9 considerado uma das melhores prticas at 30 de junho de 2015 quando passar a ser um requisito.
9.9 Analise as polticas e procedimentos para verificar se eles incluem: Manter uma lista de dispositivos Inspecionar periodicamente os dispositivos para identificar falsificaes ou substituies Treinar os funcionrios para que reconheam comportamentos suspeitos e para reportar a falsificao ou substituio de dispositivos.
ORIENTAO
Criminosos tentam roubar os dados do portador do carto roubando e/ou manipulando os terminais e dispositivos de leitura do carto. Por exemplo, eles tentaro roubar os dispositivos para que eles possam saber como arromb-los e eles geralmente tentam validar os dispositivos com dispositivos fraudulentos que enviam a eles as informaes do carto de pagamento sempre que o carto inserido. Os criminosos tambm tentaro adicionar componentes de "espionagem" na parte externa dos dispositivos, que so designados para capturar os detalhes do carto antes mesmo de ser inserido, por exemplo, anexando um leitor de carto adicional em cima do leitor do carto original para que os detalhes do carto sejam capturados duas vezes: uma vez pelo componente do criminoso e depois pelo componente legtimo do dispositivo. Dessa forma, as transaes ainda podem ser concludas sem interrupo enquanto o criminoso est "espiando" as informaes do carto durante o processo. Este requisito recomendado, mas no exigido, para componentes de entrada de chave manual, como teclados de computador e teclados POS. Melhores prticas adicionais sobre a preveno de espionagem esto disponveis no site do PCI SSC.
9.9.1 Mantenha uma lista atualizada de dispositivos. A lista deve incluir o seguinte: Marca, modelo do dispositivo Localizao do dispositivo (por exemplo, o endereo do local ou instalao onde o dispositivo est localizado) Nmero de srie do dispositivo ou
9.9.1.a Analise a lista de dispositivos para verificar se ela inclui: Marca, modelo do dispositivo Localizao do dispositivo (por exemplo, o endereo do local ou instalao onde o dispositivo est localizado) Nmero de srie do dispositivo ou outro mtodo de identificao exclusivo. 9.9.1.b Selecione uma amostra de dispositivos a partir da lista e observe as localizaes do dispositivo para verificar se a lista est exata e atualizada.
Manter uma lista atualizada de dispositivos ajuda uma organizao a controlar onde os dispositivos devem estar e rapidamente identificar se um deles est faltando ou perdido. O mtodo para manter uma lista de dispositivos pode ser automatizado (por exemplo, um sistema de gerenciamento de dispositivos) ou manual (por exemplo, documentado em registros de papel ou eletrnicos). Para os dispositivos em trnsito, a localizao pode incluir o nome do funcionrio para

outro mtodo de identificao exclusivo.
9.9.1.c Questione os funcionrios para verificar se a lista de dispositivos atualizada quando dispositivos so adicionados, realocados, retirados, etc. 9.9.2.a Analise os procedimentos documentados para verificar se os processos esto definidos para incluir o que segue: Procedimentos para inspecionar os dispositivos Frequncia de inspees. 9.9.2.b Questione os funcionrios responsveis e observe os processos de inspeo para verificar se: Os funcionrios conhecem os procedimentos de inspeo dos dispositivos. Todos os dispositivos so inspecionados periodicamente para evidncia de adulterao e substituio.
ORIENTAO
quem o dispositivo concedido.
9.9.2Inspecione periodicamente as superfcies dos dispositivos para detectar adulterao (por exemplo, adio de espies aos dispositivos), ou substituio (por exemplo, verificando o nmero de srie ou outras caractersticas do dispositivo para verificar se ele no foi trocado por um dispositivo fraudulento). Observao: Exemplos de sinais de que um dispositivo possa ter sido adulterado ou substitudo incluem anexos inesperados ou cabos conectados ao dispositivo, rtulos de segurana alterados ou ausentes, revestimento quebrado ou de cor diferente, ou alteraes no nmero de srie ou outras marcas externas.
As inspees regulares dos dispositivos ajudaro as organizaes a detectar mais rapidamente adulteraes ou substituies de um dispositivo e, ento, minimizar o possvel impacto de usar dispositivos fraudulentos. O tipo de inspeo depender do dispositivo, por exemplo, fotografias de dispositivos que so conhecidos por serem seguros podem ser usadas para comparar a aparncia atual de um dispositivo com sua aparncia original para ver se ela mudou. Outra opo pode ser usar uma caneta marcadora segura, como um marcador de luz UV, para marcar as superfcies e aberturas do dispositivo para que qualquer adulterao ou substituio seja aparente. Os criminosos frequentemente substituiro a estrutura externa de um dispositivo para ocultar sua adulterao e estes mtodos podem ajudar a detectar tais atividades. Os fornecedores dos dispositivos tambm podem fornecer orientaes de segurana e guias "como fazer" para ajudar a determinar se o dispositivo foi adulterado. A frequncia de inspees depender de fatores como o local do dispositivo e se este frequentado ou no. Por exemplo, dispositivos deixados em reas pblicas sem superviso pelo funcionrio pode ter inspees mais frequentes do que dispositivos mantidos em reas seguras ou que sejam supervisionados quando eles esto acessveis ao pblico. O tipo e frequncia de inspees so determinados pelo comerciante, conforme definido pelo seu processo anual de avaliao de riscos.

9.9.3 Treine os funcionrios para que estejam cientes das tentativas de adulterao ou substituio de dispositivos. O treinamento deve incluir o seguinte: Verifique a identidade de qualquer terceiro que alegue ser da equipe de manuteno ou reparo, antes de conceder acesso para modificar ou resolver problemas nos dispositivos. No instale, substitua ou devolva dispositivos sem verificao. Esteja atento a comportamentos suspeitos ao redor dos dispositivos (por exemplo, tentativas de desconectar ou abrir os dispositivos por pessoas desconhecidas). Reporte comportamentos suspeitos e indicaes de adulterao ou substituio para a equipe apropriada (por exemplo, para um gerente ou funcionrio da segurana).
9.9.3.a Analise os materiais de treinamento para os funcionrios dos locais de ponto de venda para verificar se eles incluem o treinamento do seguinte: Verificar a identidade de qualquer terceiro que alegue ser da equipe de manuteno ou reparo, antes de conceder acesso para modificar ou resolver problemas nos dispositivos No instalar, substituir ou devolver dispositivos sem verificao Estar atento a comportamentos suspeitos ao redor dos dispositivos (por exemplo, tentativas de desconectar ou abrir os dispositivos por pessoas desconhecidas) Reportar comportamentos suspeitos e indicaes de adulterao ou substituio para a equipe apropriada (por exemplo, para um gerente ou funcionrio da segurana). 9.9.3.b Questione alguns funcionrios nos locais de ponto de venda para verificar se ele receberam treinamento e se esto cientes dos procedimentos para o seguinte: Verificar a identidade de qualquer terceiro que alegue ser da equipe de manuteno ou reparo, antes de conceder acesso para modificar ou resolver problemas nos dispositivos No instalar, substituir ou devolver dispositivos sem verificao Estar atento a comportamentos suspeitos ao redor dos dispositivos (por exemplo, tentativas de desconectar ou abrir os dispositivos por pessoas desconhecidas) Reportar comportamentos suspeitos e indicaes de adulterao ou substituio para a equipe apropriada (por exemplo, para um gerente ou funcionrio da segurana).
ORIENTAO
Os criminosos frequentemente afirmam ser da equipe de manuteno autorizada para obter acesso aos dispositivos POS. Todos os terceiros que solicitarem acesso aos dispositivos devem ser sempre verificados antes de terem o acesso concedido, por exemplo, verificando com o gerenciamento ou telefonando para a empresa de manuteno do POS (como o fornecedor ou adquirente) para verificao. Muitos criminosos tentaro enganar os funcionrios se vestindo para a funo (por exemplo, carregando caixas de ferramentas e vestidos com uniformes de trabalho) e tambm podem saber sobre os locais dos dispositivos, por isso importante que os funcionrios sejam treinados para seguir sempre os procedimentos. Outro truque que os criminosos gostam de usar enviar um "novo" sistema de POS com instrues para troc-lo com o sistema legtimo e "devolver" o sistema legtimo para um endereo especfico. Os criminosos podem ainda oferecer a postagem de retorno j que querem muito colocar suas mos nestes dispositivos. Os funcionrios sempre verificam com o gerente ou fornecedor se o dispositivo legtimo e se veio de uma fonte confivel antes de instal-lo ou us-lo para negcios.
9.10 Certifique-se de que as polticas de segurana e procedimentos operacionais para restringir o acesso fsico aos dados do portador do carto estejam documentados, em uso e conhecidos por todas as partes envolvidas.
9.10 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para restringir o acesso fsico aos dados do portador do carto esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para restringir o acesso fsico dos dados do portador do carto e sistemas CDE continuamente.
Monitorar e testar as redes regularmente

Requisito 10: carto Acompanhe e monitore 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. REQUISITOS DO PCI DSS
10.1 Implemente trilhas de auditoria para ligar todos os acessos aos componentes do sistema para cada usurio individual.
10.1 Verifique, atravs da observao e questionando o administrador do sistema, se: Trilhas de auditoria esto habilitadas e ativas para os componentes do sistema. O acesso aos componentes do sistema est ligado aos usurios individuais. 10.2 Por meio de entrevistas do funcionrio responsvel, observao de registros de auditoria e anlise de suas configuraes, desempenhe o seguinte:
ORIENTAO
essencial ter um processo ou sistema que vincule o acesso do usurio aos componentes do sistema acessados. Esse sistema gera logs de auditoria e oferece a capacidade de rastrear as atividades suspeitas de um usurio especfico.
10.2 Implemente trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos:
Gerar trilhas de auditoria de atividades suspeitas alerta o administrador do sistema, envia dados a outros mecanismos de monitoramento (como sistemas de deteco de intruso) e fornece uma trilha do histrico para acompanhamento psacidente. Registrar os seguintes eventos permite que uma empresa identifique e rastreie atividades potencialmente mal-intencionadas Indivduos mal-intencionados poderiam tomar conhecimento de uma conta de usurio com acesso aos sistemas no CDE ou poderiam criar uma conta nova, no autorizada, para acessar os dados do portador do carto. Um registro de todos os acessos individuais para os dados do portador do carto pode identificar quais contas podem ter sido comprometidas ou usadas inadequadamente.
10.2.1 Todos os acessos de usurios individuais aos dados do portador do carto
10.2.1 Verifique se todos os acessos individuais aos dados do portador do carto esto registrados.

10.2.2 Todas as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos
10.2.2 Verifique se todas as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos so registradas.
ORIENTAO
Contas com privilgios maiores, como "administrador" ou "raiz", tm o potencial para impactar fortemente a segurana ou a funcionalidade operacional de um sistema. Sem o registro das atividades executadas, uma empresa no capaz de rastrear qualquer problema resultante de algum erro administrativo ou uso inadequado de privilgios em uma ao ou indivduo especfico. Usurios mal-intencionados tentam frequentemente alterar os registros de auditoria para ocultar suas aes e um registro de acesso permite que uma empresa rastreie quaisquer inconsistncias ou potenciais adulteraes dos registros para uma conta individual. Ter acesso aos registros que identificam alteraes, adies e excluses pode ajudar a reconstituir os passos feitos pelo pessoal no autorizado. Indivduos mal-intencionados na rede muitas vezes executam vrias tentativas de acesso nos sistemas alvejados. Vrias tentativas invlidas de logon podem ser um indicador de tentativas de um usurio no autorizado "forar" ou adivinhar uma senha. Sem saber quem estava registrado no momento de um incidente, impossvel identificar as contas que possam ter sido usadas. Alm disso, usurios mal-intencionados tentam manipular os controles de autenticao com o objetivo de contorn-los ou imitar uma conta vlida.
10.2.3 Acesso a todas as trilhas de auditoria
10.2.3 Verifique se o acesso a todas as trilhas de auditoria registrado.
10.2.4 Tentativas invlidas de acesso lgico
10.2.4 Verifique se as tentativas invlidas de acesso lgico esto registradas.
10.2 5 O uso e alteraes dos mecanismos de identificao e autenticao, incluindo, entre outros, a criao de novas contas e aumento de privilgios e todas as alteraes, adies ou excluses de contas com privilgios raiz ou administrativos
10.2.5.a Verifique se o uso dos mecanismos de identificao e autenticao registrado. 10.2.5.b Verifique se todos os aumentos de privilgios so registrados. 10.2.5.c Verifique se todas as alteraes, adies ou excluses em qualquer conta com privilgios raiz ou administrativos so registradas.

10.2.6 Inicializao, interrupo ou pausa dos registros de auditoria
10.2.6 Verifique se o que segue registrado: Inicializao dos logs de auditoria Interrupo ou pausa dos registros de auditoria.
ORIENTAO
Desativar os logs de auditoria (ou paus-los) antes de realizar atividades ilcitas uma prtica comum a usurios mal-intencionados que desejam evitar ser detectados. A inicializao dos logs de auditoria podem indicar que a funo de registro foi desativada por um usurio para ocultar suas aes. Softwares mal-intencionados, como malwares, frequentemente criam ou substituem objetos no nvel do sistema no sistema de destino para controlar uma funo ou operao nesse sistema. Registrando quando os objetos do nvel do sistema, como tabelas do banco de dados ou procedimentos armazenados, so criados ou excludos, ser mais fcil determinar se estas modificaes foram autorizadas. Ao registrar esses detalhes para os eventos auditveis em 10.2, um possvel comprometimento poder ser rapidamente identificado e com detalhes suficientes para saber quem, o que, onde, quando e como.
10.2.7 Criao e excluso de objetos do nvel do sistema
10.2.7 Verifique se a criao e a excluso de objetos do nvel do sistema so registrados.
10.3 Registre pelo menos as seguintes entradas de trilhas de auditoria para todos os componentes do sistema para cada evento: 10.3.1 Identificao do usurio 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.3 Por meio de entrevistas e da observao dos logs de auditoria, para cada evento auditvel (no item 10.2), realize o seguinte: 10.3.1 Verifique se a identificao do usurio est includa nas entradas do registro. 10.3.2Verifique se o tipo de 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.5Verifique 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 esto includos nas entradas do registro.

10.4 Usando tecnologia de sincronizao de tempo, sincronize todos os relgios e horrios crticos do sistema e assegurese de que os seguintes itens sejam implementados para adquirir, distribuir e armazenar horrios. Observao: Um exemplo de tecnologia de sincronizao de horrios o Network Time Protocol (NTP). 10.4.1 Sistemas crticos tm o horrio correto e consistente.
10.4 Analise os processos e padres de configurao para verificar se a tecnologia de sincronizao de tempo est implementada e mantida atualizada pelos Requisitos 6.1 e 6.2 do PCI DSS.
ORIENTAO
A tecnologia para sincronizao do horrio usada para sincronizar os relgios. Quando os relgios no so sincronizados adequadamente pode ser difcil, se no impossvel, comparar arquivos de registro de diferentes sistemas e estabelecer uma sequncia exata de eventos (cruciais para anlise forense no caso de uma violao). Para equipes de forenses psincidente, a preciso e a consistncia do horrio ao longo de todos os sistemas e a hora de cada atividade so essenciais para determinar a forma como os sistemas foram comprometidos.
10.4.1.a Analise o processo para a aquisio, distribuio e armazenamento do horrio correto na empresa para verificar se: Apenas os servidores centrais 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. Onde houver mais de um servidor de horrio designado, os servidores de horrios se igualam um com o outro para manter a hora exata. Os sistemas recebem informaes de horrio somente dos servidores centrais de horrio designados.
10.4.1.b Observe as configuraes dos parmetros do sistema relacionadas ao horrio para obter uma amostra dos componentes do sistema e verificar se: Apenas os servidores centrais 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. Onde houver mais de um servidor de horrio designado, os servidores centrais de horrios designados se igualam um com o outro para manter a hora exata. Os sistemas recebem o horrio somente dos servidores centrais de horrio designados.

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 somente aos funcionrios com necessidades comerciais de acesso aos dados de horrio. 10.4.2.b Analise as definies, registros e processos de configurao e de sincronizao de horrio para verificar se qualquer alterao s definies de horrio em sistemas crticos registrada, monitorada e revisada.
ORIENTAO
10.4.3 As definies de horrio so recebidas de fontes de horrio aceitas pelo setor.
10.4.3 Analise as configuraes dos sistemas para verificar se os servidores de horrio aceitam atualizaes de fontes externas especficas, aceitas pelo setor (para evitar que um indivduo malintencionado 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 Questione os administradores do sistema e analise as configuraes do sistema e permisses para verificar se as trilhas de auditoria esto protegidas de forma que no possam ser alteradas conforme segue: Muitas vezes um indivduo mal-intencionado que entra em uma rede tenta editar os logs de auditoria para ocultar suas atividades. Sem proteo adequada dos logs de auditoria, sua concluso, preciso e integridade no podero ser garantidas e os logs de auditoria podero ser inutilizados como ferramenta de investigao aps um comprometimento. Uma proteo adequada dos logs de auditoria inclui forte controle de acesso (limitar o acesso aos logs com base somente na necessidade de divulgao) e uso da separao fsica e da rede para deixar os logs mais difceis de serem encontrados e modificados. Fazer imediatamente o backup dos logs para um servidor centralizado de log ou mdias que sejam difceis de alterar mantm os registros protegidos mesmo se o sistema que gera os registros for comprometido.
10.5 Proteja as trilhas de auditoria para que no possam ser alteradas.
10.5.1 Limite a exibio de trilhas de auditoria s pessoas que tm uma necessidade relacionada funo. 10.5.2 Proteja os arquivos de trilha de auditoria de modificaes no autorizadas. 10.5.3 Faa imediatamente o backup dos arquivos de trilha de auditoria em um servidor de registros centralizado ou mdias que sejam difceis de alterar.
10.5.1Apenas os indivduos que tm uma necessidade relacionada funo podem visualizar arquivos de trilha de auditoria. 10.5.2 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.3Os arquivos de trilha de auditoria atuais tm o backup feito imediatamente em um servidor de registros centralizado ou mdias que sejam difceis de alterar.

10.5.4 Documente registros quanto s tecnologias externas em um servidor de registros centralizado, seguro ou dispositivo de mdia.
10.5.4Os registros quanto s tecnologias externas (por exemplo, sem fio, firewalls, DNS, e-mail) so escritos em um servidor de registro interno centralizado ou mdia seguros.
ORIENTAO
Ao gravar os logs de tecnologias que usam recursos externos, como sem fio, firewalls, DNS e servidores de e-mail, o risco de esses logs serem perdidos ou alterados diminudo, pois eles esto mais seguros dentro da rede interna. Os logs podem ser escritos diretamente, ou transferidos ou copiados de sistemas externos para a mdia ou sistema interno seguros.
10.5.5 Use softwares de monitoramento da integridade dos arquivos ou de deteco de alteraes nos logs 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 Revise os registros e ocorrncias de segurana para todos os componentes do sistema para identificar irregularidades ou atividades suspeitas. Observao: Ferramentas de coleta, anlise e alerta dos logs podem ser usadas para atender a este requisito.
10.5.5 Analise as configuraes do sistema, os arquivos e resultados monitorados das atividades de monitoramento para verificar o uso de software para monitoramento da integridade do arquivo ou deteco de alteraes nos registros.
Os sistemas de monitoramento da integridade do arquivo ou de deteco de alteraes verificam as alteraes nos arquivos crticos e notificam quando essas alteraes so observadas. Para fins de monitoramento da integridade do arquivo, uma entidade normalmente monitora os arquivos que no mudam regularmente, mas que, quando alterados, indicam um possvel comprometimento. Vrias violaes ocorrem durante dias ou meses antes de serem detectadas. A verificao diria dos logs minimiza a quantidade de tempo e exposio de uma violao em potencial. Revises regulares dos logs pelos funcionrios ou meios automatizados podem identificar e resolver proativamente o acesso no autorizado ao ambiente de dados do portador do carto. O processo de reviso do log no precisa ser manual. O uso de ferramentas de coleta, anlise e alertas pode facilitar o processo identificando as ocorrncias de logs que precisam ser revisados.
10.6 Realize as seguintes etapas:

10.6.1 Revise o que segue ao menos diariamente: Todas as ocorrncias de segurana Logs de todos os componentes do sistema que armazenam, processam ou transmitem CHD e/ou SAD, ou que possam impactar na segurana do CHD e/ou SAD Logs de todos os componentes crticos do sistema Registros de todos os servidores e componentes do sistema que desempenham funes de segurana (por exemplo, firewalls, sistemas de deteco de invaso/sistemas de preveno contra invaso (IDS/IPS), servidores de autenticao, servidores de redirecionamento do e-commerce, etc.).
10.6.1.a Analise as polticas e os procedimentos de segurana para verificar se esto definidos para revisar o que segue, pelo menos diariamente, seja de forma manual ou por meio de ferramentas de logs: Todas as ocorrncias de segurana Logs de todos os componentes do sistema que armazenam, processam ou transmitem CHD e/ou SAD, ou que possam impactar na segurana do CHD e/ou SAD Logs de todos os componentes crticos do sistema Logs de todos os servidores e componentes do sistema que desempenham funes de segurana (por exemplo, firewalls, sistemas de deteco de invaso/sistemas de preveno contra invaso (IDS/IPS), servidores de autenticao, servidores de redirecionamento do ecommerce, etc.) 10.6.1.b Observe os processos e questione os funcionrios para verificar se o que segue revisado, ao menos diariamente: Todas as ocorrncias de segurana Logs de todos os componentes do sistema que armazenam, processam ou transmitem CHD e/ou SAD, ou que possam impactar na segurana do CHD e/ou SAD Logs de todos os componentes crticos do sistema Registros de todos os servidores e componentes do sistema que desempenham funes de segurana (por exemplo, firewalls, sistemas de deteco de invaso/sistemas de preveno contra invaso (IDS/IPS), servidores de autenticao, servidores de redirecionamento do ecommerce, etc.).
ORIENTAO
Vrias violaes ocorrem durante dias ou meses antes de serem detectadas. A verificao diria dos logs minimiza a quantidade de tempo e exposio de uma violao em potencial. A reviso diria de ocorrncias de segurana, por exemplo, avisos ou alertas que identificam atividades irregulares ou suspeitas, bem como registros dos componentes crticos do sistema e registros dos sistemas que desempenham funes de segurana, como firewalls, IDS/IPS, sistemas de monitoramento da integridade do arquivo (FIM), etc., necessria para identificar possveis problemas. Observe que a determinao de "ocorrncia de segurana" varia para cada organizao e pode considerar o tipo de tecnologia, local e funo do dispositivo. As organizaes tambm podem manter um parmetro do trfego "normal" para ajudar a identificar comportamentos irregulares.
10.6.2 Revise os logs de todos os outros componentes do sistema periodicamente com base nas polticas e estratgia de gerenciamento de risco da organizao, conforme determinado pela avaliao de risco anual da
10.6.2.a Analise as polticas e os procedimentos de segurana para verificar se esto definidos procedimentos para revisar os logs de todos os outros componentes do sistema periodicamente, seja de forma manual ou por meio de ferramentas de logs, com base nas polticas e estratgia de gerenciamento de risco da organizao.
Os logs para todos os outros componentes do sistema tambm devem ser revisados periodicamente para identificar indicaes de possveis problemas ou tentativas de obter acesso aos sistemas confidenciais por meio de sistemas menos confidenciais. A frequncia de

organizao.
10.6.2.b Analise a documentao da avaliao de risco da organizao e questione os funcionrios para verificar se as revises so realizadas de acordo com as polticas e estratgia de gerenciamento de risco da organizao. 10.6.3.a Analise as polticas e os procedimentos de segurana para verificar se esto definidos procedimentos para acompanhar as excees e irregularidades identificadas durante o processo de reviso. 10.6.3.b Observe os processos e questione os funcionrios para verificar se so realizados acompanhamentos das excees e irregularidades.
ORIENTAO
revises deve ser determinada por uma avaliao de risco anual da entidade.
10.6.3 Acompanhe as excees e irregularidades identificadas durante o processo de reviso.
Se as excees e irregularidades identificadas durante o processo de reviso do registro no forem investigadas, a entidade pode no tomar conhecimento de atividades no autorizadas e potencialmente mal-intencionadas que estejam ocorrendo dentro de sua prpria rede.
10.7 Mantenha um histrico da trilha de auditoria por pelo menos um ano, com um mnimo de trs meses imediatamente disponvel para anlise (por exemplo, online, arquivado ou recupervel a partir do backup).
10.7.a Analise as polticas e procedimentos de segurana para verificar se eles definem o que segue: Polticas de manuteno de log de auditoria Procedimentos para manter logs de auditoria por pelo menos um ano, com um mnimo de trs meses imediatamente disponvel online. 10.7.b Questione os funcionrios e analise os logs de auditoria para verificar se eles esto disponveis por pelo menos um ano. 10.7.c Questione os funcionrios e observe os processos para verificar se os registros dos ltimos trs meses podem ser armazenados imediatamente para anlise.
Guardar os logs por pelo menos um ano leva em conta o fato de muitas vezes se levar um tempo at notar que ocorreu ou est ocorrendo um comprometimento e permite que os investigadores tenham um histrico de log suficiente para determinar melhor a quantidade de tempo de uma potencial violao e os possveis sistemas afetados. Ao ter trs meses de logs imediatamente disponveis, uma entidade pode rapidamente identificar e minimizar o impacto da violao de dados. O armazenamento de logs em locais offline pode evitar que eles fiquem prontamente disponveis, resultando em cronogramas mais longos para restaurar dados de log, executar anlises e identificar sistemas ou dados afetados. Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais dirios para monitorar todos os acessos aos recursos de rede e dados do portador do carto continuamente.
10.8 Certifique-se de que as polticas de segurana e procedimentos operacionais para monitoramento de todos os acessos aos recursos e dados do portador do carto estejam documentados, em uso e conhecidos por todas as partes envolvidas.
10.8 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para monitorar todos os acessos aos recursos de rede e dados do portador do carto esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
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. REQUISITOS DO PCI DSS
11.1 Implemente processos para testar a presena de pontos de acesso sem fio (802.11) e detectar e identificar todos os pontos de acesso sem fio autorizados e no autorizados trimestralmente. Observao: Mtodos que podem ser usados no processo incluem, entre outros, varreduras de rede sem fio, inspees fsicas/virtuais 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 dispositivos autorizados e no autorizados.
11.1.a Analise as polticas e procedimentos para verificar se esto definidos processos para detectar e identificar pontos de acesso sem fio autorizados e no autorizados trimestralmente. 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 mveis ou portteis fixados a componentes do sistema para criar um ponto de acesso sem fio (por exemplo, por USB, etc.) Dispositivos sem fio conectados a uma porta de rede ou a um dispositivo de rede. 11.1.c Analise os resultados de varreduras sem fio recentes para verificar se: Os pontos de acesso sem fio autorizados e no autorizados esto identificados, e A varredura realizada ao menos trimestralmente para todas as instalaes e componentes do sistema. 11.1.d Se o monitoramento automatizado for utilizado (por exemplo, IDS/IPS sem fio, NAC, etc.), verifique que a configurao gerar alertas para avisar os funcionrios.
ORIENTAO
A implementao e/ou explorao da tecnologia sem fio dentro de uma rede um dos caminhos mais comuns para usurios mal-intencionados obterem acesso rede e aos dados do portador do carto. Se um dispositivo sem fio ou uma rede forem instalados sem o conhecimento da empresa, ele pode permitir que um invasor entre na rede de forma fcil e invisvel. Dispositivos sem fio no autorizados devem ser ocultados ou anexados a um computador ou outro componente do sistema, ou ser anexados diretamente a uma porta ou dispositivo da rede, como um switch ou roteador. Qualquer desses dispositivos no autorizados podem resultar em um ponto no autorizado de acesso ao ambiente. Saber quais dispositivos sem fio so autorizados pode ajudar os administradores a identificar mais rapidamente os dispositivos sem fio no autorizados e reagir identificao de pontos de acesso sem fio no autorizados ajuda a minimizar proativamente a exposio do CDE a indivduos mal-intencionados. Em funo da facilidade com que o ponto de acesso sem fio pode ser conectado a uma rede, da dificuldade em detectar sua presena e do risco cada vez maior apresentado por dispositivos sem fio no autorizados, esses processos devem ser executados at quando existir uma poltica proibindo o uso da tecnologia sem fio. O tamanho e a complexidade de um ambiente privado determinaro as ferramentas e os processos adequados a serem usados para
ORIENTAO
fornecer garantia suficiente de que um ponto de acesso sem fio intruso no tenha sido instalado no ambiente. (Continua na prxima pgina)
11.1.1 Mantenha um inventrio de pontos de acesso sem fio autorizados incluindo uma justificativa comercial documentada.
11.1.1 Analise os registros documentados para verificar se mantido um inventrio de pontos de acesso sem fio autorizados e se uma justificativa comercial est documentada para todos os pontos de acesso sem fio autorizados. 11.1.2.a Analise o plano de resposta a incidentes da organizao (Requisito 12.10) para verificar se ele define e exige uma reao no caso de ser detectado um ponto de acesso sem fio no autorizado. 11.1.2.b Questione os funcionrios responsveis e/ou inspecione as varreduras sem fio recentes e as respostas relacionadas para verificar se a ao realizada quando pontos de acesso sem fio no autorizados so encontrados.
11.1.2 Implemente procedimentos de resposta a incidentes para o caso de serem detectados pontos de acesso sem fio no autorizados.
Por exemplo: No caso de um nico quiosque de revenda autnomo em um shopping, onde todos os componentes de comunicao esto contidos em estojos antiadulterao e indicadores de adulterao, executando inspees fsicas detalhadas no prprio quiosque pode ser suficiente para fornecer garantias de que nenhum ponto de acesso sem fio intruso foi anexado ou instalado. No entanto, em um ambiente com vrios ns (como em uma grande loja de revenda, uma central de atendimento, sala de servidor ou centro de dados), a inspeo fsica detalhada difcil. Nesse caso, vrios mtodos podem ser combinados para atender ao requisito, como executar inspees fsicas no sistema em conjunto com os resultados de um analisador sem fio.

11.2 Execute 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, aprimoramentos de produtos). Observao: Vrios relatrios de varredura podem ser combinados no processo de varredura trimestral para mostrar que todos os sistemas foram mapeados e que todas as vulnerabilidades aplicveis foram resolvidas. Pode ser exigida uma documentao adicional para verificar se as vulnerabilidades no resolvidas esto em processo de serem solucionadas. Para a conformidade inicial com o PCI DSS, no necessrio que as quatro varreduras trimestrais aprovadas sejam concludas se o assessor verificar que 1) o resultado da varredura mais recente foi uma varredura aprovada, 2) a entidade possui 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 Analise os relatrios de varredura e documentao de suporte para verificar se as varreduras de vulnerabilidades internas e externas so realizadas conforme segue:
ORIENTAO
Uma varredura de vulnerabilidade uma ferramenta automatizada executada em dispositivos de rede interna e externa e servidores, feita para expor possveis vulnerabilidades que possam ser encontradas e exploradas por indivduos mal-intencionados. H trs tipos de varredura de vulnerabilidades exigidas para o PCI DSS: Varredura interna de vulnerabilidades trimestral feita por funcionrios qualificados (o uso de um Fornecedor de Varredura Aprovado (ASV) para o PCI SSC no necessrio) Varredura externa de vulnerabilidades trimestral, a qual deve ser realizada por um ASV Varredura interna e externa conforme necessrio aps mudanas significativas Quando esses pontos fracos so identificados, a entidade os corrige e repete a varredura at que todas as vulnerabilidades tenham sido corrigidas. Identificar e resolver as vulnerabilidades em tempo hbil reduz as chances de explorao de uma vulnerabilidade e o comprometimento potencial de um componente do sistema ou de dados do portador do carto.

11.2.1 Realize varreduras internas de vulnerabilidades trimestralmente e novas varreduras conforme necessrio, at que todas as vulnerabilidades de "alto-risco" (identificadas no requisito 6.1) sejam resolvidas. As varreduras devem ser realizadas por uma equipe qualificada.
11.2.1.a Analise os relatrios de varredura 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 inclui novas varreduras at que todas as vulnerabilidades de "alto risco", conforme definidas no requisito 6.1 do PCI DSS, estejam solucionadas. 11.2.1.c Questione os funcionrios para verificar se a varredura foi realizada 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).
ORIENTAO
Um processo estabelecido para identificar vulnerabilidades em sistemas internos exige que as varreduras de vulnerabilidade sejam conduzidas trimestralmente. As vulnerabilidades que representam o maior risco ao ambiente (por exemplo, classificadas como "Alto" pelo requisito 6.1) deve ser resolvida com a maior prioridade. Varreduras de vulnerabilidade internas podem ser realizadas por profissionais internos e qualificados que sejam razoavelmente independentes dos componentes do sistema que esto sendo mapeados (por exemplo, um administrador de firewall no deve ser responsvel pela varredura do firewall), ou a entidade pode optar por fazer as varreduras de vulnerabilidade internas por uma empresa especializada em varreduras de vulnerabilidade. Como redes externas tm um risco maior de comprometimento, a varredura de vulnerabilidade externa trimestral deve ser realizada por um Fornecedor de Varreduras Aprovado (ASV) do PCI SSC.
11.2.2 Realize varreduras externas trimestrais de vulnerabilidades por meio de um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de padres de segurana da Indstria de cartes de pagamento (PCI SSC). Realiza novas varreduras conforme necessrio, at que se chegue a varreduras aprovadas. Observao: As varreduras externas trimestrais de vulnerabilidades devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de padres de segurana da Indstria de cartes de pagamento (PCI SSC). Consulte o Guia do programa ASV publicado no site do PCI SSC para saber sobre responsabilidades de varredura do cliente, preparao de varredura, etc.
11.2.2.a Revise o resultado das varreduras externas de vulnerabilidades dos quatro ltimos trimestres e verifique se ocorreram quatro varreduras nos ltimos 12 meses.
11.2.2.b Analise os resultados de cada varredura trimestral e de novas varreduras para verificar se 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 Revise os relatrios de varredura para verificar se as varreduras foram concludas por um Fornecedor de Varredura Aprovado (ASV) pelo PCI SSC.

11.2.3 Realize varreduras internas e externas e novas varreduras se necessrio, aps qualquer mudana significativa. As varreduras devem ser realizadas por uma equipe qualificada.
11.2.3.a Inspecione correlacione 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: No existam varreduras com pontuao maior do que 4.0 pelo CVSS para varreduras externas. Todas as vulnerabilidades de "alto risco", conforme definidas no requisito 6.1 do PCI DSS, estejam solucionadas para varreduras internas.
ORIENTAO
A determinao do que constitui uma alterao significativa depende muito da configurao de um determinado ambiente. Se uma melhoria ou modificao puder permitir o acesso aos dados do portador do carto ou afetar a segurana do ambiente de dados do portador do carto, ela pode ser considerada significativa. Mapear um ambiente depois de qualquer alterao significativa ter sido feita garante que todas as alteraes foram concludas adequadamente para que a segurana do ambiente no tenha sido comprometida como resultado da alterao. Todos os componentes do sistema afetados pela alterao precisam passar por varredura.
11.2.3.c Verifique se a varredura foi realizada 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.3Implemente uma metodologia para testes de penetrao que inclua o seguinte: baseada nas abordagens de testes de penetrao aceitas pelo setor (por exemplo, NIST SP800-115) Abrange todo o permetro do CDE e sistemas crticos Inclui testes de dentro e fora da rede Inclui testes para validar qualquer controle de reduo no escopo e segmentao Define testes de penetrao da camada do aplicativo para incluir, pelo menos, as vulnerabilidades listadas no requisito 6.5. Define testes de penetrao da camada da rede que incluam componentes 11.3 Analise a metodologia de testes de penetrao e questione o funcionrio responsvel para verificar se est implementada uma metodologia que inclua o seguinte: baseada nas abordagens de testes de penetrao aceitas pelo setor (por exemplo, NIST SP800-115) Abrange todo o permetro do CDE e sistemas crticos Testes de dentro e fora da rede Inclui testes para validar qualquer controle de reduo no escopo e segmentao Define testes de penetrao da camada do aplicativo para incluir, pelo menos, as vulnerabilidades listadas no requisito 6.5. Define testes de penetrao da camada da rede que incluam componentes compatveis com as funes da rede e com os sistemas operacionais. Inclui reviso e considerao de ameaas e vulnerabilidades ocorridas nos ltimos 12 meses O objetivo de um teste de penetrao estimular uma situao de invaso real com o objetivo de identificar at onde um invasor conseguiria penetrar em um ambiente. Isso permite que a entidade tenha mais compreenso sobre sua potencial exposio e desenvolva uma estratgia para se defender de invases. Um teste de penetrao difere de uma varredura de vulnerabilidade, uma vez que o teste de penetrao um processo ativo que pode incluir a explorao de vulnerabilidades identificadas. Conduzir uma varredura de vulnerabilidade pode ser um dos primeiros passos que um testador de penetrao realizar para planejar uma estratgia de teste, mesmo que no seja o nico passo. Mesmo que uma varredura de vulnerabilidade no detecte nenhuma vulnerabilidade conhecida, o testador de penetrao ir normalmente tomar Pgina 105 Novembro de 2013

compatveis com as funes da rede e com os sistemas operacionais. Inclui reviso e considerao de ameaas e vulnerabilidades ocorridas nos ltimos 12 meses Especifica a conservao dos resultados de testes de penetrao e resultados de atividades de reparo. Observao: Esta atualizao do requisito 11.3 considerada uma das melhores prticas at 30 de junho de 2015 quando passar a ser um requisito. Os requisitos do PCI DSS v2.0 para testes de penetrao devem ser seguidos at que a v3.0 esteja vigente.
Especifica a conservao dos resultados de testes de penetrao e resultados de atividades de reparo.
ORIENTAO
conhecimento suficiente sobre o sistema para identificar possveis lacunas de segurana. O teste de penetrao geralmente um processo altamente manual. Enquanto algumas ferramentas automatizadas podem ser usadas, o testador utiliza seu conhecimento de sistemas para penetrar em um ambiente. Normalmente o testador ir conectar diversos tipos de exploraes com o objetivo de ultrapassar camadas de defesas. Por exemplo, se o testador encontrar meios de obter acesso a um servidor de aplicativo, em seguida ele usar o servidor comprometido como um ponto de preparao para uma nova invaso com base nos recursos a que o servidor tem acesso. Dessa forma, o testador capaz de simular os mtodos utilizados por um invasor para identificar reas de fraquezas potenciais no ambiente. As tcnicas de teste de penetrao sero diferentes para diferentes organizaes e o tipo, profundidade e complexidade do teste depender do ambiente especfico e da avaliao de risco da organizao.
11.3.1 Realize testes de penetrao externos pelo menos uma vez ao ano e aps qualquer melhoria ou modificao significativa na infraestrutura ou nos aplicativos (como uma melhoria no sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor Web adicionado ao ambiente).
11.3.1.a Analise o escopo do trabalho e os resultados do teste de penetrao mais recente para verificar se os testes de penetrao so realizados conforme segue: De acordo com a metodologia definida Pelo menos uma vez ao ano Aps quaisquer alteraes significativas no ambiente. 11.3.1.b 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.2.a Analise o escopo do trabalho e os resultados do teste de penetrao mais recente para verificar se os testes
O teste de penetrao conduzido regularmente e aps mudanas significativas no ambiente uma medida de segurana proativa que ajuda a minimizar o possvel acesso ao CDE por indivduos mal-intencionados. A determinao do que constitui uma melhoria ou modificao significativa depende muito da configurao de um determinado ambiente. Se uma melhoria ou modificao puder permitir o acesso aos dados do portador do carto ou afetar a segurana do ambiente de dados do portador do carto, ela pode ser considerada significativa. Realizar testes de penetrao aps melhorias e modificaes da rede garante que os controles supostamente implementados ainda estejam Pgina 106 Novembro de 2013
11.3.2 Realize testes de penetrao internos pelo menos uma vez ao ano e

aps qualquer melhoria ou modificao significativa na infraestrutura ou nos aplicativos (como uma melhoria no sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor Web adicionado ao ambiente).
de penetrao so realizados pelo menos uma vez ao ano e aps quaisquer mudanas significativas no ambiente. De acordo com a metodologia definida Pelo menos uma vez ao ano Aps quaisquer alteraes significativas no ambiente. 11.3.2.b 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).
ORIENTAO
funcionando efetivamente aps a melhoria ou modificao.
11.3.3 As vulnerabilidades explorveis encontradas durante o teste de penetrao so corrigidas e o teste repetido para verificar as correes.
11.3.3 Analise os resultados do teste de penetrao para verificar se as vulnerabilidades explorveis observadas foram corrigidas e se o teste repetido confirmou que ela foi corrigida.

11.3.4 Se for utilizada a segmentao para isolar o CDE de outras redes, realize testes de penetrao ao menos uma vez por ano e aps qualquer alterao nos mtodos/controles de segmentao para verificar se os mtodos so operacionais e efetivos e se isolam todos os sistemas fora do escopo dos sistemas dentro do escopo.
11.3.4.a Analise os controles de segmentao e revise a metodologia de teste de penetrao para verificar se os procedimentos do teste so definidos para testar todos os mtodos de segmentao para confirmar que eles so operacionais e efetivos e isolar todos os sistemas fora do escopo dos sistemas dentro do escopo. 11.3.4.b Analise os resultados do teste de penetrao mais recente para verificar se este teste dos controles de segmentao: executado pelo menos uma vez ao ano e aps qualquer mudana nos mtodos/controles da segmentao. Abrange todos os mtodos/controles da segmentao em uso. Verifica se os mtodos de segmentao so operacionais e efetivos e se isolam todos os sistemas de fora do escopo dos sistemas de dentro do escopo.
ORIENTAO
O teste de penetrao uma ferramenta importante para confirmar se qualquer segmentao implantada para isolar o CDE de outras redes efetiva. O teste de penetrao deve focar nos controles da segmentao, tanto de dentro quanto de fora da rede da entidade, mas fora do CDE, para confirmar que eles no podem passar pelos controles da segmentao para acessar o CDE. Por exemplo, teste de rede e/ou varredura para portas abertas, para verificar se no h nenhuma conectividade entre as redes de fora e dentro do escopo.
11.4 Use tcnicas de deteco de invaso e/ou preveno contra invases para detectar e/ou evitar invases na rede. Monitore todo o trfego no permetro do ambiente de dados do portador do carto, bem como nos pontos crticos do ambiente e alerte as equipes sobre comprometimentos suspeitos. Mantenha todos os mecanismos de deteco e preveno contra invases, diretrizes e assinaturas atualizados.
11.4.a Analise as configuraes do sistema e diagramas da rede para verificar se as tcnicas (como sistemas de deteco e/ou preveno contra invases) esto implementadas para monitorar todo o trfego: No permetro do ambiente dos dados do portador do carto Nos pontos crticos do ambiente dos dados do portador do carto. 11.4.b Analise as configuraes do sistema e questione os funcionrios responsveis para confirmar se as tcnicas de deteco e/ou preveno contra invaso alertam os funcionrios de comprometimentos suspeitos. 11.4.c Analise as configuraes de IDS/IPS e a documentao do fornecedor para verificar se as tcnicas de deteco e/ou preveno contra invaso esto configuradas, mantidas e atualizadas de acordo com as instrues do fornecedor para assegurar uma proteo ideal.
As tcnicas de deteco e/ou preveno contra invases (como IDS/IPS) comparam o trfego que entra na rede com assinaturas conhecidas e/ou comportamentos de milhares de tipos de comprometimento (ferramentas de hacker, trojans e outros tipos de malware) e envia alertas e/ou interrompe a tentativa enquanto ela est acontecendo. Sem uma abordagem proativa a uma deteco de atividade no autorizada, invases (ou mau uso) de recursos de computador podem passar despercebidas em tempo real. Os alertas de segurana gerados por essas tcnicas devem ser monitorados, de forma que as tentativas de invaso possam ser interrompidas.

11.5 Implemente um mecanismo de deteco de alteraes (por exemplo, ferramentas de monitoramento da integridade do arquivo) para alertar a equipe sobre modificaes no autorizadas de arquivos crticos do sistema, arquivos de configurao ou arquivos de contedo; e configure o software para realizar comparaes de arquivos crticos pelo menos uma vez por semana. Observao: Para fins de deteco de alteraes, 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. Os mecanismos de deteco de alteraes, como produtos de monitoramento da integridade dos arquivos, normalmente vm prconfigurados 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.1 Implemente um processo para responder a qualquer alerta gerado pela soluo de deteco de alteraes.
11.5.a Verifique o uso de um mecanismo de deteco de alteraes no ambiente de dados do portador do carto observando as configuraes do sistema e os arquivos monitorados, bem como analisando os resultados das atividades de monitoramento.
ORIENTAO
As solues de deteco de alteraes, como ferramentas de monitoramento da integridade do arquivo (FIM), verificam as alteraes nos arquivos crticos e notificam quando essas alteraes so detectadas. Se no implementadas corretamente e se o resultado da soluo de deteco de alteraes no for monitorado, um indivduo malintencionado pode alterar o contedo do arquivo de configurao, os programas do sistema operacional ou os executveis do aplicativo. Alteraes no autorizadas, se no detectadas, podem tornar os controles de segurana ineficazes e/ou resultar no roubo dos dados do portador do carto sem impacto perceptvel no processamento normal.
Exemplos de arquivos que devem ser monitorados:

Executveis do sistema Executveis dos aplicativos Arquivos de configurao e parmetro Arquivos de log e auditoria, histricos ou arquivados, armazenados centralmente Arquivos crticos adicionais determinados pela entidade (por exemplo, por meio de avaliao de risco ou outros meios). 11.5.bVerifique se o mecanismo est configurado para alertar os funcionrios sobre modificaes no autorizadas de arquivos crticos e para realizar comparaes de arquivos crticos ao menos uma vez por semana.
11.5.1 Questione os funcionrios para verificar se todos os alertas so investigados e resolvidos.

11.6 Certifique-se de que as polticas de segurana e procedimentos operacionais para o teste e monitoramento da segurana estejam documentados, em uso e conhecidos por todas as partes envolvidas.
11.6 Analise a documentao e questione os funcionrios para verificar se as polticas de segurana e procedimentos operacionais para o teste e monitoramento da segurana esto: Documentados, Em uso, e Conhecidos por todas as partes envolvidas.
ORIENTAO
Os funcionrios precisam estar cientes e seguir as polticas de segurana e os procedimentos operacionais para monitorar e testar a segurana continuamente.
Manter uma poltica de segurana de informaes

Requisito 12: Mantenha uma poltica que aborde a segurana da informao 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 portador do carto. Requisitos do PCI DSS
12.1 Defina, publique, mantenha e dissemine uma poltica de segurana.
Procedimentos de teste
12.1Analise a poltica de segurana da informao e verifique se a poltica foi publicada e disseminada a todos os funcionrios relevantes (incluindo fornecedores e parceiros comerciais).
Orientao
A poltica de segurana de informaes de uma empresa cria um guia para implementar as medidas de segurana para proteger seus ativos mais valiosos. Todos os funcionrios devem estar cientes da confidencialidade dos dados e de suas responsabilidades para proteg-los. As ameaas de segurana e os mtodos de proteo evoluem rapidamente. Sem atualizar a poltica de segurana para refletir essas alteraes, agora so abordadas novas medidas de proteo para lutar contra essas ameaas. Uma avaliao de riscos permite a uma organizao identificar ameaas e vulnerabilidades relacionadas que tm o potencial de causar um impacto negativo em seus negcios. Os recursos podem ento ser alocados com eficcia para implementar controles que reduzem a probabilidade e/ou o impacto potencial da ameaa em questo. Realizar avaliaes de riscos anuais e quando houver alteraes significativas permite organizao manter-se atualizada com as mudanas organizacionais e ameaas, tendncias e tecnologias em evoluo.
12.1.1 Revise a poltica de segurana ao menos uma vez por ano e atualize a poltica quando o ambiente for alterado.
12.1.1 Verifique se a poltica de segurana da informao 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.a Verifique se um processo anual de avaliao de risco est documentado e se identifica ativos, ameaas e vulnerabilidades e resulta em uma avaliao de risco formal. 12.2.b Analise a documentao da avaliao de risco para verificar se o processo de avaliao de risco realizada ao menos uma vez por ano e quando houver alteraes significativas no ambiente.
12.2 Implemente um processo de avaliao de risco que: Seja realizado ao menos uma vez por ano e quando houver modificaes significativas no ambiente (por exemplo, aquisio, fuso, transferncia, etc.), Identifique os recursos, ameaas e vulnerabilidades crticos, e Resulte em uma avaliao formal de risco. Os exemplos de metodologias de avaliao de risco incluem, entre outros, OCTAVE, ISO 27005 e NIST SP 800-30.

12.3 Desenvolva o uso de polticas de tecnologias crticas e defina o uso apropriado destas tecnologias. Observao: Exemplos de tecnologias crticas incluem, entre outros, tecnologias de acesso remoto e sem fio, laptops, tablets, mdia eletrnica removvel, uso de e-mails e da internet. Garanta que essas polticas de utilizao exijam o seguinte: 12.3.1 Aprovao explcita por partes autorizadas
12.3 Analise as polticas de uso das tecnologias crticas e questione os funcionrios responsveis para verificar se as seguintes polticas esto implementadas e so seguidas:
Orientao
As polticas de uso por funcionrios podem proibir o uso de determinados dispositivos e outras tecnologias, se for essa a poltica da empresa, ou fornecer orientao para os funcionrios quanto ao uso e implementao corretos. Se polticas de uso no estiverem vigentes, os funcionrios podem usar as tecnologias na violao da poltica da empresa, permitindo que indivduos malintencionados consigam acesso a sistemas crticos e dados do portador do carto. Sem exigir aprovao adequada do gerenciamento para implementao dessas tecnologias, um funcionrio pode implementar inocentemente uma soluo para uma necessidade de negcios percebida, mas tambm abrir um grande buraco que deixe os sistemas e dados crticos vulnerveis a indivduos malintencionados. Se a tecnologia for implementada sem autenticao adequada (IDs de usurio e senhas, tokens, VPNs, etc.), indivduos mal-intencionados podem facilmente usar essa tecnologia desprotegida para acessar sistemas crticos e dados do portador do carto. Os indivduos mal-intencionados podem violar a segurana fsica e colocar seus prprios dispositivos na rede como uma backdoor. Os funcionrios tambm podem se desviar dos procedimentos e instalar dispositivos. Um inventrio preciso, com rtulos adequados nos dispositivos, permite uma rpida identificao das instalaes no aprovadas.
12.3.1 Verifique se as polticas de utilizao incluem processos para aprovao explcita das partes autorizadas para usar as tecnologias.
12.3.2 Autenticao para o uso da tecnologia
12.3.2 Verifique se as polticas de utilizao incluem processos para 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 Uma lista de todos esses dispositivos e equipes com acesso
12.3.3 Verifique se as polticas de utilizao definem uma lista de todos os dispositivos e equipes autorizadas a usar os dispositivos.

12.3.4 Um mtodo para determinar prontamente e precisamente o proprietrio, informaes de contato e propsito (por exemplo, etiqueta, codificao, e/ou inventrio de dispositivos)
12.3.4 Verifique se as polticas de utilizao definem um mtodo para determinar prontamente e precisamente o proprietrio, informaes de contato e propsito (por exemplo, etiqueta, codificao, e/ou inventrio de dispositivos).
Orientao
Os indivduos mal-intencionados podem violar a segurana fsica e colocar seus prprios dispositivos na rede como uma backdoor. Os funcionrios tambm podem se desviar dos procedimentos e instalar dispositivos. Um inventrio preciso, com rtulos adequados nos dispositivos, permite uma rpida identificao das instalaes no aprovadas. Pense em criar uma conveno de nomes oficiais para dispositivos e registre todos os dispositivos com os controles de inventrio criados. Rtulos lgicos podem ser empregados com informaes, como cdigos que podem ser associados ao proprietrio, a informaes de contato e sua finalidade. Ao definir o uso corporativo aceitvel e a localizao dos dispositivos e da tecnologia aprovados pela empresa, a empresa fica mais capaz de gerenciar e controlar falhas nas configuraes e nos controles operacionais, a fim de garantir que no tenha sido aberta uma backdoor para um indivduo mal-intencionado obter acesso a sistemas crticos e a dados do portador do carto. As tecnologias de acesso remoto so frequentes "backdoors" a recursos crticos e a dados do portador do carto. Ao desconectar as tecnologias de acesso remoto quando no estiverem em uso (por exemplo, aquelas usadas para dar suporte aos sistemas pelo fornecedor de POS ou por outros fornecedores), o acesso e os riscos rede so minimizados.
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.5 Verifique se as polticas de utilizao definem usos aceitveis quanto tecnologia. 12.3.6 Verifique se as polticas de utilizao definem locais de rede aceitveis quanto tecnologia. 12.3.7 Verifique se as polticas de utilizao incluem uma lista de 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.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.8.b Analise as configuraes para as tecnologias de acesso remoto para verificar se as sesses de acesso remoto sero desconectadas automaticamente aps um perodo determinado 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.9 Verifique se as polticas de utilizao exigem a ativao de tecnologias de acesso remoto usadas pelos fornecedores somente quando lhes for necessrio, com desativao imediata aps o uso.

12.3.10 Para funcionrios que acessam os dados do portador do carto por meio de tecnologias de acesso remoto, proba a cpia, a transferncia e o armazenamento dos dados do portador do carto em discos rgidos locais e mdias eletrnicas removveis, exceto se explicitamente autorizado para uma necessidade comercial definida. Onde houver uma necessidade comercial autorizada, as polticas de utilizao devem exigir que os dados sejam protegidos de acordo com todos os requisitos aplicveis do PCI DSS. 12.4 Certifique-se de que a poltica e os procedimentos de segurana definem claramente as responsabilidades quanto segurana da informao para todos os funcionrios.
12.3.10.a Verifique se as polticas de utilizao probem a cpia, a transferncia ou o armazenamento dos dados do portador 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 portador do carto de acordo com os requisitos do PCI DSS.
Orientao
Para garantir que os funcionrios estejam cientes de suas responsabilidades de no armazenar nem copiar dados do portador do carto para o computador pessoal local ou outras mdias, sua empresa deve contar com uma poltica que proba claramente essas atividades, exceto para os funcionrios que foram expressamente autorizados para isso. Armazenar ou copiar dados do portador do carto em discos rgidos locais ou outras mdias deve estar de acordo com todos os requisitos aplicveis do PCI DSS.
12.4.a Verifique se as polticas de segurana da informao definem claramente as responsabilidades quanto segurana da informao para todos os funcionrios. 12.4.b Converse com alguns funcionrios responsveis para verificar se eles compreendem as polticas de segurana. 12.5 Analise as polticas e procedimentos de segurana da informao para verificar: A atribuio formal da segurana da informao com relao a um Diretor de segurana ou outro membro do gerenciamento que tenha conhecimento sobre segurana. As seguintes responsabilidades da segurana da informao so atribudas modo formal e especfico:
Sem funes e responsabilidades claramente definidas e atribudas, pode haver uma interao inconsistente com o grupo de segurana, levando a uma implementao no protegida de tecnologias ou ao uso de tecnologias no protegidas ou desatualizadas. Cada pessoa ou equipe com responsabilidades pela gesto da segurana da informao deve estar claramente ciente das responsabilidades e das tarefas relacionadas por meio da poltica especfica. Sem essa responsabilidade, falhas nos processos podem dar acesso a recursos crticos ou dados do portador do carto.
12.5 Atribua a um indivduo ou a uma equipe as seguintes responsabilidades de gerenciamento da segurana da informao:
12.5.1 Defina, documente e distribua polticas e procedimentos de segurana.
12.5.1 Verifique se a responsabilidade de definir, documentar e distribuir polticas e procedimentos de segurana est formalmente atribuda.

12.5.2 Monitore e analise os alertas e as informaes de segurana e distribua para as equipes apropriadas.
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 da informao e das unidades de negcios foi formalmente atribuda. 12.5.3 Verifique se a responsabilidade de definir, documentar e distribuir procedimentos de resposta e escalao de incidentes de segurana formalmente atribuda.
Orientao
12.5.3 Defina, documente e distribua 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 Administre as contas dos usurios, incluindo adies, excluses e modificaes. 12.5.5 Monitore e controle todos os acessos aos dados. 12.6Implemente um programa formal de conscientizao da segurana para conscientizar todos os funcionrios sobre a importncia da segurana dos dados do portador do carto.
12.5.4 Verifique se a responsabilidade pela administrao (adio, excluso e modificao) das contas dos usurios e do gerenciamento da autenticao formalmente atribuda. 12.5.5 Verifique se a responsabilidade por monitorar e controlar todo o acesso aos dados formalmente atribuda. 12.6.a Revise o programa de conscientizao da segurana para verificar se ele conscientiza os funcionrios sobre a importncia da segurana dos dados do portador do carto. 12.6.b Analise os procedimentos e a documentao do programa de conscientizao de segurana e realize o seguinte: 12.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 com base na Web, reunies e promoes). 12.6.1.b Verifique se os funcionrios participam do treinamento de conscientizao relacionados contratao pelo menos uma vez por ano. 12.6.1.c Questione alguns funcionrios para verificar se eles concluram o treinamento para se conscientizar da importncia da segurana dos dados do portador do carto. Se os usurios no forem treinados sobre as responsabilidades de segurana, as protees e os processos que forem implementados podero se tornar ineficazes por causa de erros do funcionrio ou aes no intencionais.
12.6.1 Instrua 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 portador do carto.
Se o programa de conscientizao de segurana no incluir sesses de atualizao anuais, os principais processos e procedimentos de segurana podero ser esquecidos ou ignorados, resultando em exposio dos recursos crticos e dos dados do portador do carto.

12.6.2 Solicite que os funcionrios reconheam, pelo menos uma vez ao ano, que leram e compreenderam a poltica e os procedimentos de segurana da empresa. 12.7 Analise bem os potenciais funcionrios antes de contratar a fim de minimizar o risco de invases 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 Mantenha e implemente polticas e procedimentos para controlar os prestadores de servios com quem os dados do portador so compartilhados, ou que possam afetar a segurana dos dados, conforme segue:
12.6.2 Verifique se o programa de conscientizao da segurana requer que os funcionrios reconheam, por escrito ou eletronicamente, pelo menos uma vez ao ano, que leram e compreenderam a poltica de segurana da informao da empresa. 12.7 Questione o gerenciamento do departamento de Recursos Humanos e verifique se as verificaes da formao so realizadas (dentro das restries das leis locais) antes de contratar funcionrios que tero acesso aos dados do portador do carto ou ao ambiente desses dados.
Orientao
Requerer um reconhecimento dos funcionrios, por escrito ou eletronicamente, ajuda a garantir que eles tenham lido e entendido as polticas e os procedimentos de segurana e que eles tenham se comprometido a obedecer a essas polticas. Executar investigaes de histrico completas antes de contratar funcionrios que se espera que tenham acesso aos dados do portador do carto reduz o risco do uso no autorizado de PANs e outros dados do portador do carto por pessoas com histricos questionveis ou criminais.
12.8 Por meio de observao, revise as polticas e procedimentos e a documentao de suporte, verifique se esto implementados processos para controlar prestadores de servios com quem os dados do portador do carto so compartilhados, ou que podem afetar sua segurana (por exemplo, reas de armazenamento de fitas de backup, prestadores de servios gerenciados, como empresas de hospedagem na Web ou prestadores de servios de segurana, aqueles que recebem dados para fins de determinao de fraude, etc.), conforme segue: 12.8.1 Verifique se uma lista dos prestadores de servios mantida.
Se o comerciante ou o prestador de servio compartilhar os dados do portador do carto com um prestador de servio, devem ser aplicados certos requisitos para garantir a proteo contnua desses dados por tais prestadores de servio.
12.8.1 Mantenha uma lista dos prestadores de servios.
Rastrear todos os provedores de servio identifica quando possveis riscos se estenderem para fora da organizao.

12.8.2 Mantenha 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, ou que os armazenam, processam ou transmitem em nome do cliente, ou ao ponto de que eles possam impactar a segurana do ambiente dos dados do portador do carto do cliente. Observao: As informaes exatas contidas no reconhecimento dependero do acordo entre as duas partes, dos detalhes do servio a ser prestado e das responsabilidades atribudas a cada parte. O reconhecimento no precisa ser exatamente igual ao fornecido neste requisito. 12.8.3 Certifique-se de que haja um processo definido para a contratao dos prestadores de servios, incluindo uma diligncia devida adequada antes da contratao.
12.8.2 Observe os acordos por escrito e confirme se eles incluem um reconhecimento de que os prestadores de servios so responsveis pela segurana dos dados do portador do carto que eles possurem, ou que os armazenam, processam ou transmitem em nome do cliente, ou ao ponto de que eles possam impactar a segurana do ambiente dos dados do portador do carto do cliente.
Orientao
O reconhecimento dos prestadores de servio evidencia o seu compromisso em manter a segurana adequada dos dados do portador do carto que so obtidos dos clientes. Juntamente com o Requisito 12.9, este requisito para acordos escritos entre as organizaes e prestadores de servios tem o objetivo de promover um nvel consistente de entendimento entre as partes sobre suas responsabilidades aplicveis do PCI DSS. Por exemplo, o acordo pode incluir que os requisitos aplicveis do PCI DSS sejam mantidos como parte do servio prestado.
12.8.3 Verifique se as polticas e procedimentos esto documentados e implementados, incluindo a diligncia devida adequada antes da contratao de qualquer prestador de servios.
O processo garante que qualquer envolvimento de um prestador de servio seja totalmente vetado internamente pela organizao, que deve incluir uma anlise de risco antes de estabelecer um relacionamento formal com o prestador de servios. Os processos de diligncia devida e metas especficos variam para cada organizao. Exemplos de consideraes podem incluir as prticas de relatrios do fornecedor, procedimentos de aviso de violao e resposta a incidentes, detalhes de como as responsabilidades do PCI DSS so atribudas entre cada parte, como o fornecedor valida sua conformidade com o PCI DSS e qual evidncia eles iro fornecer, etc.

12.8.4 Mantenha um programa para monitorar anualmente o status de conformidade com o PCI DSS dos prestadores de servios. 12.8.5 Mantenha informaes sobre quais requisitos do PCI DSS so administrados por cada prestador de servios e quais so administrados pela entidade.
12.8.4 Verifique se a entidade mantm um programa para monitorar o status de conformidade com o PCI DSS dos prestadores de servios pelo menos uma vez ao ano. 12.8.5 Verifique se a entidade mantm informaes sobre quais requisitos do PCI DSS so administrados por cada prestador de servios e quais so administrados pela entidade.
Orientao
Conhecer o status de conformidade do prestador de servio com o PCI DSS fornece uma garantia a mais de que eles esto de acordo com os mesmos requisitos aos quais a organizao est sujeita. Se o provedor oferecer diversos servios, este requisito se aplicar apenas aos servios realmente prestados ao cliente e os servios que estiverem dentro do escopo da avaliao de PCI DSS do cliente. A informao especfica que uma entidade mantm depender do acordo particular com seus fornecedores, o tipo de servio, etc. O objetivo que a entidade avaliada entenda quais requisitos do PCI DSS seus fornecedores concordaram em atender.

12.9 Requisito adicional para prestadores de servios: Os prestadores de servios reconhecem por escrito aos clientes que eles so responsveis pela segurana dos dados do portador do carto que eles possurem, ou que os armazenam, processam ou transmitem em nome do cliente, ou ao ponto de que eles possam impactar a segurana do ambiente dos dados do portador do carto do cliente. Observao: O requisito considerado uma das melhores prticas at 30 de junho de 2015 quando passar a ser um requisito. Observao: As informaes exatas contidas no reconhecimento dependero do acordo entre as duas partes, dos detalhes do servio a ser prestado e das responsabilidades atribudas a cada parte. O reconhecimento no precisa ser exatamente igual ao fornecido neste requisito. 12.10 Implemente um plano de resposta a incidentes. Prepare-se para reagir imediatamente a uma falha no sistema.
12.9 Procedimento de teste adicional para prestadores de servios: Revise as polticas e procedimentos do prestador de servios e observe os modelos de acordos escritos para confirmar se ele reconhece por escrito aos clientes que manter todos os requisitos aplicveis do PCI DSS ao limite em que ele procede, tem acesso ou armazena, processa ou transmite os dados do portador do carto do cliente ou dados de autenticao confidenciais, ou que administra o ambiente de dados do portador do carto em nome de um cliente.
Orientao
Este requisito se aplica quando a entidade que est sendo avaliada um prestador de servios. Juntamente com o Requisito 12.8.2, este requisito tem o objetivo de promover um nvel consistente de entendimento entre os prestadores de servios e seus clientes sobre suas responsabilidades aplicveis do PCI DSS. O reconhecimento dos prestadores de servio evidencia o seu compromisso em manter a segurana adequada dos dados do portador do carto que so obtidos dos clientes. O mtodo pelo qual o prestador de servios fornece o reconhecimento por escrito deve ser acordado entre o fornecedor e seus clientes.
12.10 Analise o plano de resposta a incidentes e os procedimentos relatados para verificar se a entidade est preparada para reagir imediatamente a uma violao no sistema realizando o que segue:
Sem um plano de resposta a incidentes de segurana completo que seja adequadamente disseminado, lido e entendido pelas partes responsveis, a confuso e a falta de uma resposta unificada podem criar mais tempo ocioso para a empresa, exposio pblica desnecessria e novas responsabilidades legais.

12.10.1 Crie o plano de resposta a incidentes para ser implementado no caso de violaes do sistema. Certifique-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 backup 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. 12.10.2 Teste o plano pelo menos uma vez ao ano. 12.10.3 Designe equipes especficas para estarem disponveis em tempo integral para responder aos alertas.
12.10.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 backup 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. 12.10.1.b Questione os funcionrios e revise a documentao a partir de incidentes ou alertas relatados previamente para verificar se o plano e os procedimentos de resposta ao incidente documentado foram seguidos. 12.10.2 Verifique se o plano testado pelo menos uma vez ao ano. 12.10.3 Verifique, por meio da observao, anlise das polticas e entrevistas com funcionrios responsveis se a equipe designada est disponvel para cobertura de monitoramento e resposta a incidentes em tempo integral 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.
Orientao
O plano de resposta a incidentes deve ser completo e conter todos os elementos-chave para permitir que sua empresa reaja com eficincia no caso de uma violao que possa causar impacto nos dados do portador do carto.
Sem testes adequados, etapas essenciais podem ser perdidas, o que poderia aumentar a exposio durante um incidente. Sem uma equipe de reao a incidentes treinada e prontamente disponvel, podem ocorrer danos extensos rede e dados e sistemas crticos podem ficar poludos pelo manuseio inadequado dos sistemas almejados. Isso pode evitar o sucesso de uma investigao ps-incidente.

12.10.4 Fornea treinamento adequado equipe que responsvel pela resposta s falhas do sistema. 12.10.5 Inclua alertas a partir dos sistemas de monitoramento de segurana, incluindo, entre outros, deteco e preveno contra invases, firewalls e sistemas de monitoramento da integridade dos arquivos. 12.10.6 Desenvolva 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.
12.10.4 Verifique, por meio de observao, anlises das polticas e entrevistas com os funcionrios responsveis se a equipe com responsabilidades de resposta a violaes de segurana so treinadas periodicamente. 12.10.5 Verifique, por meio da observao e da anlise dos processos, se o monitoramento e a resposta aos alertas a partir dos sistemas de monitoramento de segurana, incluindo deteco dos pontos de acesso sem fio no autorizados, so abordados no plano de resposta a incidentes. 12.10.6 Verifique, por meio da observao, da anlise das polticas e entrevistas com os funcionrios responsveis 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.
Orientao
Esses sistemas de monitoramento so feitos para se concentrar em possveis riscos aos dados, so essenciais para se tomar uma ao rpida para evitar uma violao e devem estar includos nos processos de resposta a incidentes. Incorporar as lies aprendidas no plano de reao a incidentes depois de um incidente ajuda a manter o plano atualizado e capaz de reagir s ameaas que surgirem e s tendncias de segurana.
Apndice 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 e 12.9, 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.6 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.
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: O provedor de hospedagem deve cumprir esses requisitos e todas as outras sees relevantes do PCI DSS. Observao: Mesmo que o provedor de hospedagem cumpra esses requisitos, a conformidade da entidade que usa o provedor de hospedagem no est assegurada. Cada entidade deve estar em conformidade com o PCI DSS e validar a conformidade, conforme aplicvel.
A.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:
Orientao
O Apndice A do PCI DSS destinado a provedores de hospedagem compartilhada que desejam fornecer aos clientes do comerciante e/ou prestador de servio um ambiente de hospedagem em conformidade com o PCI DSS.
Requisitos
A.1.1 Certifique-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 Web compartilhado. Todos os scripts CGI usados por uma entidade devem ser criados e executados como o ID do usurio exclusivo da entidade.
Orientao
Se um comerciante ou prestador de servio puder executar seus prprios aplicativos no servidor compartilhado, eles devem ser executados com o ID de usurio do comerciante ou prestador de servio e no como um usurio privilegiado.
A.1.2 Restrinja o acesso e os privilgios de cada entidade somente ao prprio ambiente de dados do portador do carto.
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) leu, 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 log 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 sobrecargas de buffer), verifique se as restries foram implementadas para a utilizao destes recursos do sistema: Espao em disco Largura de banda Memria CPU
Para garantir que os acessos e os privilgios estejam restritos, de forma que cada comerciante ou prestador de servio s tenha acesso ao prprio ambiente dos dados, considere o seguinte: 1. Privilgios do ID do usurio do servidor Web do prestador de servios ou do comerciante; Permisses concedidas para ler, escrever e executar arquivos; Permisses concedidas para escrever em binrios do sistema; Permisses concedidas para arquivos de log dos comerciantes e prestadores de servios; e Controles para garantir que um comerciante ou prestador de servios no possa monopolizar recursos do sistema.
2. 3. 4.
5.
Requisitos
A.1.3 Certifique-se de que os registros e as trilhas de auditoria esto ativados e so exclusivos 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.3 Verifique se o provedor de hospedagem compartilhada ativou os registros conforme 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.
Orientao
Os logs devem estar disponveis em um ambiente de hospedagem compartilhado, de forma que os comerciantes e prestadores de servio tenham acesso e consigam analisar os logs especficos ao ambiente dos dados do portador do carto.
A.1.4 Permita que os processos providenciem uma investigao forense oportuna no caso de um comprometimento em qualquer comerciante ou prestador de servios hospedado.
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.
Os provedores de hospedagem compartilhada devem ter processos para fornecer uma resposta rpida e fcil no caso de uma investigao forense ser necessria para um comprometimento, at o nvel adequado de detalhes, de forma que os detalhes individuais do comerciante ou do prestador de servio estejam disponveis.
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. Fornea 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. Esteja "acima e alm" dos outros requisitos do PCI DSS. (Simplesmente estar em conformidade com outros requisitos do PCI DSS no um controle de compensao.) Ao utilizar o critrio de avaliao "acima e alm" para controles de compensao, considere o seguinte: Observao: Os itens nas alternativas a) a c) abaixo so apenas exemplos. Todos os controles de compensao devem ser analisados e validados quanto suficincia pelo responsvel pela avaliao que realiza a anlise do PCI DSS. A efetividade de um controle de compensao depende das especificidades do ambiente no qual o controle est implementado, dos controles de segurana ao redor e da configurao do controle. As empresas devem estar cientes de que um determinado controle de compensao no ser efetivo em todos os ambientes. a) Os requisitos existentes do PCI DSS NO PODERO ser considerados como controles de compensao se j tiverem sido exigidos para o item sob anlise. Por exemplo, as senhas para o acesso administrativo realizado que no utiliza 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 invaso, 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 PODEM 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 que no utiliza console quando no houver suporte para a transmisso de senhas criptografadas. A autenticao com dois fatores pode ser um controle de compensao aceitvel se: (1) atender ao objetivo 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 do endereos IP ou endereo MAC; e (3) autenticao com dois fatores dentro da rede interna.
Padro de segurana de dados da Indstria de cartes de pagamento (PCI), v3.0 2006-2013 PCI Security Standards Council, LLC. Todos os direitos reservados. Novembro de 2013 Pgina 125
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.
Novembro de 2013 Pgina 126
Apndice 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 Liste as restries que impossibilitam a conformidade com o requisito original. Defina o objetivo do controle original; identifique o objetivo atendido pelo controle de compensao. Identifique qualquer risco adicional imposto pela ausncia do controle original. Defina os controles de compensao e explique como eles abordam os objetivos do controle original e o aumento dos riscos, caso haja algum. Defina como os controles de compensao foram validados e testados. Defina 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.1 Todos os usurios so identificados com um ID de usurio exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do portador do carto? Informaes necessrias 1. Restries Liste 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 logon "raiz". A empresa XYZ no pode gerenciar o logon "raiz" nem possvel registrar todas as atividades "raiz" por usurio. O objetivo de exigir logons exclusivos duplo. Primeiro, no considerado aceitvel, da perspectiva de segurana, compartilhar credenciais de logon. Segundo, ter logons 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 logon nos servidores a partir dos seus desktops usando o comando SU (usurio substituto). Isso permite que um usurio acesse a conta "raiz" e desempenhe aes na conta "raiz", mas possa efetuar logon no diretrio de log do SU. Dessa forma, cada ao do usurio pode ser rastreada pela conta SU e a senha "raiz" no compartilhada com os usurios. A empresa XYZ demonstra ao responsvel pela avaliao que o comando SU est sendo executado em todas as atividades e que as pessoas usando o comando efetuaram logon 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, identificados e registrados individualmente.
2. Objetivo
Defina o objetivo do controle original; identifique o objetivo atendido pelo controle de compensao.
3. Risco identificado
Identifique qualquer risco adicional imposto pela ausncia do controle original. Defina 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
Defina como os controles de compensao foram validados e testados.
6. Manuteno
Defina o processo e os controles implementados para manter os controles de compensao.
Apndice D: Segmentao e amostragem de reas de negcios/componentes do sistema

PCI DSS v3

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PCI DSS v3

Transféré par

Droits d'auteur :

Formats disponibles

Indstria de cartes de pagamento (PCI)

Padro de Segurana de Dados

Requisitos e procedimentos da avaliao de segurana

Pgina 2 Novembro de 2013

Escopo dos requisitos do PCI DSS ................................................................................................................................................ 10

Restrinja o acesso fsico aos dados do portador do carto ........................................................................................................ 82

Apndice A: Apndice B: Apndice C: Apndice D:

Pgina 4 Novembro de 2013

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

Pgina 5 Novembro de 2013

Recursos PCI DSS

Consulte www.pcisecuritystandards.org para obter informaes sobre estes e outros recursos.

Pgina 6 Novembro de 2013

Informaes de aplicabilidade do PCI DSS

Armazenamento permitido Sim Sim Sim Sim No No No

Relao entre PCI DSS e PA-DSS

Aplicabilidade do PCI DSS para fornecedores de aplicativos de pagamento

Pgina 9 Novembro de 2013

Escopo dos requisitos do PCI DSS

Uso dos prestadores de servios terceirizados/terceirizao

Pgina 12 Novembro de 2013

Pgina 13 Novembro de 2013

Pgina 14 Novembro de 2013

Para os assessores: Amostragem de reas de negcios e componentes do sistema

Pgina 16 Novembro de 2013

Instrues e contedo para o relatrio sobre conformidade

Processo de avaliao do PCI DSS

Pgina 17 Novembro de 2013

Requisitos detalhados do PCI DSS e procedimentos da avaliao de segurana

Pgina 18 Novembro de 2013

Construir e manter a segurana de rede e sistemas

REQUISITOS DO PCI DSS

Pgina 20 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 21 Novembro de 2013

REQUISITOS DO PCI DSS

REQUISITOS DO PCI DSS

1.2.2 Proteja e sincronize os arquivos de configurao do roteador.

Pgina 23 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 24 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 25 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 26 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 27 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 28 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 29 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 30 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 31 Novembro de 2013

REQUISITOS DO PCI DSS

REQUISITOS DO PCI DSS

REQUISITOS DO PCI DSS

Pgina 34 Novembro de 2013

Proteger os dados do portador do carto

Pgina 35 Novembro de 2013

REQUISITOS DO PCI DSS

Pgina 36 Novembro de 2013