Navigating DSS v2 PDF

Indstria de cartes de dbito (PCI - Payment Card Industry) Padro de segurana dos dados
Navegando pelo PCI DSS
Conhecer a inteno dos requisitos

Verso 2.0
Outubro de 2010
Alteraes no documento
Data 1 de outubro de 2008 28 de outubro de 2010 Version 1.2 2.0 Description Alinhar o contedo com o novo PCI DSS v1.2 e implementar pequenas alteraes observadas desde o original v1.1. Alinhar o contedo com o novo PCI DSS v2.0.
Navegando pelo PCI DSS: Conhecer a inteo dos requisitos, v2.0 Copyright 2010 Conselho de Padres de Segurana LLC do PCI
Outubro de 2010 Pgina 2
ndice
Alteraes no documento ..................................................................................................................................................2 Prefcio ................................................................................................................................................................................4
Virtualizao ............................................................................................................................................................................................................ 5
Elementos dos dados do titular do carto e de autenticao confidenciais .................................................................6

Localizao dos dados do titular do carto e dos dados de autenticao confidenciais........................................................................................ 8 Dados do rastro 1 vs. rastro 2 ................................................................................................................................................................................. 9
Orientao relacionada para o Padro de segurana de dados do PCI.......................................................................10 Orientao para os Requisitos 1 e 2: Construa e mantenha uma rede segura ...........................................................11
Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do titular do carto ........................................................... 11 Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana ......................... 17
Orientao para os Requisitos 3 e 4: Proteger os dados do titular do carto.............................................................20

Requisito 3: Proteger os dados armazenados do titular do carto ....................................................................................................................... 20 Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas................................................................. 28
Orientao para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades ........................30

Requisito 5: Usar e atualizar regularmente o software ou programas antivrus ................................................................................................... 30 Requisito 6: Desenvolver e manter sistemas e aplicativos seguros ..................................................................................................................... 32
Orientao para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas .............................40

Requisito 7: Restringir o acesso aos dados do titular do carto de acordo com a necessidade de conhecimento para o negcio .................... 40 Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador ................................................................. 42 Requisito 9: Restringir o acesso fsico aos dados do titular do carto.................................................................................................................. 47
Orientao para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente.................................................51

Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto ........................ 51 Requisito 11: Testar regularmente os sistemas e processos de segurana ........................................................................................................ 55
Orientao para o Requisito 12: Manter uma Poltica de Segurana de Informaes................................................61

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes. ............................................................... 61
Orientao para o Requisito A.1: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada................................................... .................................................................................................................67 Anexo A: Padro de segurana de dados do PCI: documentos relacionados........................................................69
Prefcio
Este documento descreve os 12 requisitos do Padro de segurana de dados do Setor de cartes de pagamento (PCI DSS), junto com uma orientao para explicar o propsito de cada um deles. A finalidade deste documento auxiliar comerciantes, prestadores de servio e instituies financeiras que desejem conhecer mais a respeito do padro de segurana de dados do setor de cartes de dbito, bem como o significado especfico e as intenes por trs dos requisitos detalhados para proteger os componentes do sistema (servidores, rede, aplicativos, etc). compatveis com os ambientes de dados do titular do carto. OBSERVAO: Navegando pelo PCI DSS: Conhecer a inteno dos requerimentos servir apenas como orientao. Ao preencher uma avaliao on-site do PCI DSS ou um questionrio de auto-avaliao (SAQ - Self Assessment Questionnaire), os Requisitos do PCI DSS dos Padres de Segurana de Dados e os Questionrios de auto-avaliao do PCI DSS 2.0 sero os documentos de registro. Os requisitos de segurana do PCI DSS se aplicam a todos os componentes do sistema. No contexto do PCI DSS, os "componentes do sistema" so definidos como qualquer componente de rede, servidor ou aplicativo que esteja includo ou vinculado ao ambiente de dados do titular do carto. Os componentes do sistema incluem tambm qualquer componente de virtualizao, como mquinas virtuais, roteadores e comutadores virtuais, ferramentas virtuais, aplicativos e desktops virtuais e hipervisores. O ambiente de dados do titular do carto compreende pessoas, processos e tecnologia que lidam com os dados do titular do carto ou dados de autenticao confidenciais. Os componentes de rede podem incluir, mas no de forma exclusiva, firewalls, chaves, roteadores, pontos de acesso wireless, mecanismos de rede e outros mecanismos de segurana. Os tipos de servidor incluem, mas no se limitam a: web, aplicativo, banco de dados, autenticao, e-mail, proxy, NTP (network time protocol) e DNS (domain name server). Os aplicativos incluem todos os aplicativos adquiridos e personalizados, incluindo os aplicativos internos e externos (Internet, por exemplo). A primeira etapa de uma avaliao do PCI DSS determinar precisamente o escopo da reviso. Ao menos anualmente e antes da avaliao anual, a entidade deve confirmar a preciso de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do titular do carto e assegurar que estejam includos no escopo do PCI DSS. Para confirmar a preciso e a adequao do escopo do PCI DSS, execute o seguinte: A entidade avaliada identifica e documenta a existncia de todos os dados do titular do carto em seu ambiente, para verificar que nenhum dado de titular do carto existe fora do ambiente de dados do titular do carto definido no momento (CDE). Assim que todos os locais dos dados do titular do carto forem identificados e documentados, a entidade usa os resultados para verificar se o escopo do PCI DSS adequado (por exemplo, os resultados podem ser um diagrama ou um inventrio de locais de dados do titular de carto). A entidade considera que qualquer dado do titular do carto esteja no escopo da avaliao do PCI DSS e parte do CDE, a no ser que tal dado seja excludo ou migrado/consolidado no CDE definido atualmente. A entidade retm a documentao que mostra como o escopo do PCI DSS foi confirmado e os resultados, para a reviso da assessoria e/ou para referncia durante a prxima atividade anual de confirmao do escopo do PCI SCC.
A segmentao da rede ou o isolamento (separao) do ambiente de dados do titular do carto do restante da rede corporativa no um requisito do PCI DSS. Entretanto, altamente recomendvel como um mtodo que reduzir o escopo do ambiente de dados do titular do carto. Um Assessor de Segurana Qualificado (QSA) pode auxiliar na determinao do escopo dentro do ambiente dos dados do titular do carto, junto com orientao sobre como estreitar o escopo de uma avaliao do PCI DSS ao implementar uma segmentao de rede adequada. Se houver dvidas quanto consonncia de uma determinada implantao em relao ao padro ou a um requerimento especfico, o PCI SSC recomenda s empresas que consultem o QSA para validar a implantao da tecnologia e dos processos e atender ao padro de segurana de dados do PCI. A experincia dos QSAs em trabalhar com ambientes de rede complexos boa para proporcionar melhores prticas e orientao ao comerciante ou prestador de servios na tentativa de conquistar conformidade. A lista dos assessores de segurana qualificados do PCI SSC poder ser encontrada em: https://www.pcisecuritystandards.org.
Virtualizao
Se uma virtualizao for implantada, todos os componentes que estiverem no ambiente virtual devero ser identificados e considerados dentro do escopo para a reviso, incluindo os hosts individuais virtuais ou dispositivos, mquinas visitantes, aplicativos, interfaces de gerenciamento, consoles de gerenciamento centrais, hipervisores, etc. Todas as comunicaes e fluxos de dados trocados entre os hosts devero ser identificados e documentados, bem como aqueles trocados entre o componente virtual e os componentes do sistema. A implantao de um ambiente virtualizado dever atender s intees de todos os requerimentos de forma que os sistemas virtualizados possam de fato ser considerados hardwares separados. Por exemplo: dever haver uma segmentao clara das funes e segregao de redes com nveis de segurana diferentes. A segmentao dever evitar o compartilhamento dos ambientes de produo e de teste e desenvolvimento. A configurao virtual dever ser protegida de forma que as vulnerabilidades em uma funo no interfiram na segurana de outras. E dispositivos como USB ou em srie no possam ser acessados por todas as instncias virtuais. Alm disso, todos os protocolos de interface de gerenciamento virtuais devero ser includos na documentao do sistema, e devero ser definidas funes e permisses para gerenciamento das redes virtuais e dos componentes virtuais do sistema. As plataformas de virtualizao devero ter a capacidade de aplicar a separao de tarefas e de privilgios menores, de forma a separar o gerenciamento de rede virtual do gerenciamento de servidor virtual. Deve-se ter ateno especial ao implantar os controles de autenticao, de forma a garantir que a autenticao dos usurios seja realizada nos componentes de sistema virtual adequados e que haja distino entre as mquinas virtuais (VMs - virtual machines) do visitante e o hipervisor.
Elementos dos dados do titular do carto e de autenticao confidenciais

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

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

Os dados confidenciais de autenticao consistem em dados de tarja magntica (ou trilha) , cdigo de validao do carto ou valor , e dados de 5 PIN . O armazenamento de dados de autenticao confidenciais proibido! Esses dados so muito valiosos para indivduos malintencionados, pois permitem gerar cartes de pagamento falsos e criar transaes fraudulentas. Consulte o Glossrio de termos, abreviaes e acrnimos utilizados no PCI DSS e no PA-DSS para obter a definio completa dos "dados confidenciais de autenticao". As imagens da frente e do verso do carto exibidas a seguir mostram o local dos dados do titular do carto e dos dados confidenciais de autenticao.
3 4
Observao: O chip contm dados de trilha equivalentes, bem como outros dados confidenciais, incluindo o valor de verificao de chip de circuito integrado (IC - integrated circuit), tambm chamado de CVC, iCVV, CAV3 ou iCSC do chip.
Dados codificados na tarja magntica utilizados para autorizao durante a transao com o carto. Estes dados tambm podero ser encontrados em um chip ou em outra parte do carto. As entidades no podem reter esses dados aps a autorizao da transao. Os nicos elementos dos dados da tarja que podem ser retidos so o nmero da conta principal, o nome do titular do carto, a data de vencimento e o cdigo de servio. O valor de trs ou quatro dgitos impresso direita do painel de assinatura ou na frente do carto de pagamento usado para verificar transaes com carto no presente. Nmero de Identificao Pessoal inserido pelo titular do carto durante uma transao com o carto e/ou bloqueio de PIN criptografado dentro da mensagem da transao.
4 5
Dados do rastro 1 vs. rastro 2

Se os dados completos de uma tarja (seja Rastro 1 ou Rastro 2, da tarja magntica, imagem da tarja magntica no chip ou outro local) forem armazenados, indivduos mal-intencionados que obterem esses dados podero reproduzir e vender cartes de pagamento no mundo inteiro. O armazenamento de dados completos da tarja tambm viola as regras operacionais das bandeiras, podendo ocasionar multas e penalidades. A ilustrao abaixo fornece informaes sobre os dados das Tarjas 1 e 2, descrevendo as diferenas e mostrando o layout dos dados conforme eles so armazenados na tarja magntica. Rastro 1 Contm todos os campos do rastro 1 e do rastro 2 Comprimento de at 79 caracteres Rastro 2 Tempo de processamento menor para transmisses discadas mais antigas Comprimento de at 40 caracteres
Observao: Os campos de dados opcionais so definidos pelo emissor do carto pela marca do carto de dbito. Os campos definidos pelo emissor que contm dados que o emissor ou a bandeira do carto de dbito no consideram como dados confidenciais de autenticao podero ser includos na poro de dados opcionais da tarja, e tero permisso para armazenar estes dados especficos em situaes e condies especficas da forma definida pelo emissor ou pela bandeira do carto de dbito. Entretanto, todos os dados considerados confidenciais de autenticao, contidos ou no em um campo de dados opcionais, no devero ser armazenados aps a autorizao.
Orientao relacionada para o Padro de segurana de dados do PCI

Construa e mantenha uma rede segura
Requisito 1: Requisito 2: Instalar e manter uma configurao de firewall para proteger os dados do titular do carto No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana
Proteger os dados do titular do carto

Requisito 3: Requisito 4: Proteger os dados armazenados do titular do carto Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas
Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: Requisito 6: Usar e atualizar regularmente o software ou programas antivrus Desenvolver e manter sistemas e aplicativos seguros
Implementar medidas de controle de acesso rigorosas

Requisito 7: Requisito 8: Requisito 9: Restringir o acesso aos dados do titular do carto de acordo com a necessidade de divulgao dos negcios Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador Restringir o acesso fsico aos dados do titular do carto
Monitorar e Testar as Redes Regularmente

Requisito 10: Requisito 11: Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto Testar regularmente os sistemas e processos de segurana
Manter uma Poltica de Segurana de Informaes

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes.
Orientao para os Requisitos 1 e 2: Construa e mantenha uma rede segura

Requisito 1: Instalar e manter uma configurao de firewall para proteger os dados do titular do carto
Firewalls so dispositivos do computador que controlam o trfego do computador permitido entre a rede de uma empresa (interna) e redes no confiveis (externa), assim como o trfego dentro e fora de muitas reas confidenciais na rede confivel interna de uma empresa. O ambiente de dados do titular 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 freqncia, trajetos aparentemente insignificantes que direcionam ou partem de redes no confiveis podem fornecer caminhos no protegidos aos sistemas principais. Os firewalls so um mecanismo de proteo essencial para qualquer rede de computador. Outros componentes do sistema podem oferecer a funcionalidade de filirena, contanto que atendam aos requisitos mnimos para firewalls, conforme o Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do titular do carto para oferecer a funcionalidade do firewall, esses dispositivos devero ser includos no escopo e na avaliao do Requisito 1. Requisito
1.1 Definir os padres de configurao do firewall e do roteador que incluam o seguinte:
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. Sem polticas e procedimentos para documentar como a equipe deve configurar firewalls e roteadores, fica fcil uma empresa perder sua primeira linha de defesa na proteo de dados. As polticas e os procedimentos ajudaro a garantir que a primeira linha de defesa da organizao na proteo de seus dados continue forte. Os ambientes virtuais onde os fluxos de dados no transitarem por uma rede fsica devero ser avaliados de forma a garantir que se obtenha a segmentao da rede.
1.1.1 Um processo formal para aprovar e testar todas as conexes de rede e alteraes s configuraes do firewall e do roteador
Uma poltica e um processo 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. Os fluxos de dados entre mquinas virtuais devero ser includos nas polticas e processos.
Requisito
1.1.2 Diagrama da rede atual com todas as conexes com relao aos dados do titular do carto, incluindo quaisquer redes sem fio
Orientao
Os diagramas de rede permitem que a organizao identifique o local de todos os dispositivos de rede. Alm disso, o diagrama de rede pode ser usado para mapear o fluxo de dados dos dados do titular do carto por toda a rede e entre cada dispositivo, a fim de entender totalmente o escopo do ambiente dos dados do titular do carto. Sem os diagramas da rede atual e do fluxo de dados, os dispositivos com dados do titular do carto podem ser ignorados e sem querer deixados de fora dos controles de segurana em camadas implementados para PCI DSS e, assim, vulnerveis ao comprometimento. Os diagramas de rede e fluxo de dados devero incluir componentes do sistema virtual e fluxos de dados trocados entre os hosts.
1.1.3 Requisitos para um firewall em cada conexo da Internet e entre qualquer zona desmilitarizada (DMZ) e a zona da rede interna 1.1.4Descrio de grupos, funes e responsabilidades quanto ao gerenciamento lgico dos componentes da rede
Usar um firewall e todas as conexes que entram e saem da rede permite que a organizao monitore e controle a entrada e sada de acesso, e minimize as chances de um indivduo mal-intencionado de obter acesso rede interna. Essa descrio de funes e a atribuio da responsabilidade garante que algum seja claramente responsvel pela segurana de todos os componentes e esteja ciente da responsabilidade, e tambm que nenhum dispositivo fique sem gerenciamento. Muitas vezes ocorrem comprometimentos decorrentes de servios e portas no utilizados ou inseguros, visto que freqente eles possurem vulnerabilidades conhecidas e muitas organizaes esto vulnerveis a esses tipos de comprometimentos, pois no aplicam patches nas vulnerabilidades de segurana para servios, protocolos e portas que no utilizam (ainda que as vulnerabilidades ainda estejam presentes). Cada organizao deve decidir claramente quais servios, protocolos e portas so necessrios para seus negcios, document-los nos registros e garantir que todos os outros servios, protocolos e portas sejam desabilitados ou removidos. Alm disso, as organizaes devem pensar em bloquear todo o trfego e somente reabrir essas portas depois de ser determinada e documentada uma necessidade. Alm disso, existem muitos servios, protocolos ou portas de que uma empresa pode precisar (ou estarem ativados por padro) que normalmente sejam usados por indivduos mal-intencionados para comprometer uma rede. Se esses servios, protocolos e portas inseguros 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, protocolos ou portas inseguros no forem necessrios para a empresa, eles devero ser desativados ou removidos.
1.1.5 Documentao e justificativa comercial para o uso de todos os servios, protocolos e portas permitidas, incluindo a documentao dos recursos de segurana implementados para os protocolos considerados inseguros. Exemplos de servios, protocolos ou portas inseguros incluem mas no so limitados a FTP, Telnet, POP3, IMAP e SNMP.
Requisito
1.1.6 Requisito para analisar os conjuntos de regras do firewall e do roteador 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 s permitam que servios e portas no autorizados correspondam s justificativas de negcios. aconselhvel fazer essas anlises com mais freqncia, como mensalmente, para garantir que os conjuntos de regras estejam atualizados e correspondam s necessidades da empresa, sem abrir furos na segurana e correr riscos desnecessrios.
1.2 Elaborar uma configurao de firewall e do roteador que restrinja as conexes entre redes no confiveis e quaisquer componentes do sistema no ambiente de dados do titular do carto. Observao: Uma rede no confivel qualquer rede que seja externa s redes que pertencem entidade em anlise e/ou que esteja alm da capacidade da entidade de controlar ou gerenciar. 1.2.1 Restringir o trfego de entrada e sada para aquele que necessrio para o ambiente de dados do titular do carto.
essencial instalar a proteo de rede, principalmente um componente do sistema com (pelo menos) a funo de firewall de inspeo com status, entre a rede interna confivel e outra rede no confivel externa ou que esteja fora do poder de controle e administrao da empresa. A no-implementao dessa medida corretamente significa que a entidade estar vulnervel ao acesso no autorizado de indivduos ou softwares mal-intencionados. Se o firewall estiver instalado, mas no tiver regras que controlam ou limitam determinado trfego, indivduos mal-intencionados ainda podero explorar os protocolos e portas vulnerveis para atacar sua rede. Esse requisito destina-se a evitar que indivduos mal-intencionados acessem a rede da empresa 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). Todos os firewalls devem incluir uma regra que negue todo trfego de entrada e sada no especificamente necessrio. Isso evita o surgimento de buracos inadvertidos que permitam a entrada ou sada de outros trfegos indesejados e potencialmente prejudiciais.
1.2.2 Proteger e sincronizar os arquivos de configurao do roteador.
Apesar de os arquivos de configurao de execuo normalmente serem implementados com configuraes seguras, os arquivos de inicializao (os roteadores s executam esses arquivos na reinicializao) podem no ser implementados com as mesmas configuraes seguras, pois eles s so executados ocasionalmente. Quando o roteador for reinicializado sem as mesmas configuraes seguras que as dos arquivos de configurao de execuo, o resultado pode ser regras mais fracas que permitam que indivduos malintencionados entrem na rede, pois os arquivos de inicializao podem no ter sido implementados com as mesmas configuraes de segurana que os arquivos de configurao de execuo.
Requisito
1.2.3 Instalar firewalls de permetro entre quaisquer redes sem fio e o ambiente de dados do titular do carto, e configurar esses firewalls para recusar ou controlar (se esse trfego for necessrio para fins comerciais) qualquer trfego a partir do ambiente sem fio no ambiente de dados do titular do carto.
Orientao
A implementao conhecida (ou desconhecida) e a explorao da tecnologia wireless dentro de uma rede um caminho comum para indivduos malintencionados ganharem acesso rede e aos dados do titular do carto. Se um dispositivo wireless ou uma rede forem instalados sem o conhecimento da empresa, um indivduo mal-intencionado pode fcil e invisivelmente entrar na rede. Se os firewalls no restringirem o acesso das redes wireless no ambiente do carto de pagamento, indivduos mal-intencionados que tiverem acesso no autorizado rede wireless podero se conectar facilmente ao ambiente do carto de pagamento e comprometer as informaes da conta. Devero ser instalados firewalls entre as redes sem fio e o CDE, independente da finalidade do ambiente a que a rede sem fio estiver conectada. Isto dever incluir, ao menos, redes corporativas, revendedores, ambientes de armazenamento, etc.
1.3 Proibir o acesso pblico direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do carto.
O objetivo do firewall gerenciar e controlar todas as conexes entre os sistemas pblicos e os internos (especialmente aqueles que armazenam os dados do titular do carto). Se for permitido o acesso direto entre sistemas pblicos e aqueles que armazenam os dados do titular do carto, as protees oferecidas pelo firewall sero ignoradas e os componentes do sistema que armazenam os dados do titular 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 internos de que a empresa precisa disponibilizar para o pblico (como servidor web). Essa a primeira linha de defesa ao isolar e separar o trfego que precisa se comunicar com a rede interna daquele que no precisa. Este recurso ser utilizado para evitar que indivduos mal-intencionados acessem a rede da empresa atravs de endereos de IP no autorizados ou por meio de servios, protocolos ou portas de forma no autorizada.
1.3.1 Implemente uma DMZ para limitar o trfego somente para componentes do sistema que oferece servios, protocolos e portas acessveis publicamente.
1.3.2 Limitar o trfego de entrada da Internet a endereos IP na DMZ. 1.3.3No permitir a entrada ou sada de nenhuma rota direta com relao ao trfego entre a Internet e o ambiente de dados do titular do carto.
A interrupo das conexes de IP oferecem uma oportunidade para inspeo e restrio de fontes/destinos, ou inspeo/bloqueio do contdo, evitando assim o acesso no filtrado entre pessoas no confiveis e ambientes confiveis. A interrupo das conexes de IP oferecem uma oportunidade para inspeo e restrio de fontes/destinos, ou inspeo/bloqueio do contdo, evitando assim o acesso no filtrado entre pessoas no confiveis e ambientes confiveis. Isto ajudar a evitar, por exemplo, que indivdos mal-intencionados enviem dados obtidos na rede para um servidor externo no confivel em uma rede no confivel
Requisito
1.3.4 No permitir que endereos internos sejam transmitidos via Internet na DMZ.
Orientao
Normalmente um pacote contm os endereos de IP do computador que originalmente o enviou, permitindo que os outros computadores da rede saibam de onde ele vem. Em certos casos, esse endereo de IP de envio sofrer spoofing por indivduos mal-intencionados. Por exemplo: indivduos mal-intencionados enviam um pacote com um endereo spoof, para que (a menos que seu firewall proba) o pacote consiga entrar na sua rede pela Internet, parecendo que se trata de um trfego interno e, portanto, legtimo. Quando o indivduo mal-intencionado estiver dentro da sua rede, ele poder comear a comprometer seus sistemas. A filtragem ingressa uma tcnica que voc pode usar no seu firewall para filtrar pacotes que entram na sua rede, como, entre outras coisas, garantindo que os pacotes no sofram spoofing, parecendo que vm de sua prpria rede interna. Para obter mais informaes sobre a filtragem de pacotes, pense em obter informaes sobre uma tcnica complementar chamada filtragem egressa.
1.3.5No permitir o trfego de sada no autorizado do ambiente de dados do titular do carto para a Internet.
Todo trfego que sair do ambiente de dados do titular do carto dever ser avaliado para garantir que o trfego de sada esteja de acordo com as regras autorizadas preestabelecidas. As conexes devero ser inspecionadas para retringir o trfego de forma a permitir apenas as comunicaes autorizadas (por exemplo restringindo portas/endereos de origem/destino ou bloqueando o contedo). Onde no forem permitidas conexes de entrada, as conexes de sada podero ser alcanadas atravs de arquiteturas ou componentes de sistema que interrompam e inspecionem a conexo de IP.
1.3.6 Implementar inspeo com status, tambm conhecida como filtragem de pacote dinmico. (Ou seja, somente conexes "estabelecidas" so permitidas na rede.)
Um firewall que executa inspeo de pacotes com status mantm o status (ou estado) de cada conexo para o firewall. Ao manter o "status, o firewall sabe se o que parece ser uma resposta a uma conexo anterior de fato uma resposta (visto que isso lembra a conexo anterior) ou se trata-se de um indivduo ou software mal-intencionado tentando fazer spoofing ou enganar o firewall para permitir a conexo. Os dados do titular do carto exigem o mais alto nvel de proteo de informaes. Se os dados do titular do carto estiverem localizados dentro da DMZ, o acesso a essas informaes ser mais fcil para um atacante externo, pois h poucas camadas a serem penetradas. Observao: a inteno deste requisito no inclui armazenamento em memria voltil.
1.3.7 Implementar os componentes do sistema que armazenam dados do titular do carto (como banco de dados) em uma zona da rede interna, separada da DMZ e de outras redes no confiveis.
Requisito
1.3.8 No divulgar endereos de IP privados e informaes de roteamento a partes no autorizadas. Observao: Mtodos para camuflar o endereo de IP podem incluir, mas no se limitam a: Network Address Translation (NAT) Implementao de servidores contendo dados do titular do carto atrs dos servidores de proxy/firewalls ou caches de contedo, Remoo ou filtragem das propagandas de rota para redes privadas que empregam endereamento registrado. Uso interno do espao de endereo RFC1918 em vez de endereo registrado.
Orientao
importante restringir a transmisso de endereos IP de forma a evitar que os hackers "descubram" os endereos IP da rede interna e utilizem essas informaes para acessar a rede. Os meios eficazes de atender inteo deste requisito podem variar de acordo com a tecnologia de rede especfica utilizada em seu ambiente. Por exemplo: os controles utilizados para atender a estes requisitos em redes IPv4 podero ser diferentes daqueles utilizados em redes IPv6. Uma tcnica para evitar que as informaes de endereo IP sejam descobertas em uma rede IPv4 implantar a traduo do endereo de rede (NAT - Network Address Translation). A NAT, que normalmente gerada firewall, permite que a organizao tenha endereos internos que s sejam visveis dentro da rede, e um endereo externo que seja visvel externamente. Se o firewall no ocultar (ou mascarar) os endereos de IP da rede interna, um indivduo mal-intencionado pode descobrir os endereos de IP internos e tentar acessar a rede com um endereo de IP obtido por spoofing. Em redes IPv4 o espao de endereos RFC1918 reservado para endereamentos internos e no poder ser roteado pela Internet. Dessa forma, o preferido para endereamento de IP de redes internas. Entretanto, as empresas podero ter suas razes para utilizar em suas redes internas outros espaos de endereos que no sejam o RFC1918. Neste caso, dever ser utilizada uma forma de preveno de propagandas de rota para evitar que o espao de endereos interno seja transmitido pela Internet ou divulgado a pessoas no autorizadas.
1.4Instalar o software de firewall pessoal em quaisquer computadores mveis e/ou de propriedade do funcionrio com conectividade direta Internet (por exemplo, laptops usados pelos funcionrios), que so usados para acessar a rede da empresa.
Se o computador no tiver instalado em si um firewall ou programa antivrus, spyware, Trojans, vrus, worms e rootkits (malware) podero ser baixados e/ou instalados sem conhecimento. O computador fica ainda mais vulnervel quando estiver diretamente conectado Internet, e no estiver por trs do firewall corporativo, caso em que o malware carregado em um computador poder buscar com ms intenes nas informaes dentro da rede quando o computador for reconectado rede corporativa. Observao: A inteno deste requisito se aplica a computadores de acesso remoto, sejam eles de propriedade do funcionrio ou da empresa. Os sistemas que no podem ser gerenciados pelas polticas empresariais introduzem fraquezas ao permetro e oferecem oportunidades a pessoas mal-intencionadas.
Requisito 2: No usar padres disponibilizados pelo fornecedor para senhas do sistema e outros parmetros de segurana
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. Requisito
2.1 Sempre alterar os padres disponibilizados pelo fornecedor antes de instalar um sistema na redepor exemplo, incluir senhas, strings de comunidade de SNMP (simple network management protocol) e a eliminao de contas desnecessrias. 2.1.1Em ambientes sem fio conectados ao ambiente de dados do titular do carto ou que transmitam dados do titular do carto, alterar os padres do fornecedor sem fio, incluindo, mas no se limitando a, chaves de criptografia sem fio padro, senhas e strings de comunidades de SNMP.
Orientao
Indivduos mal-intencionados (dentro e fora de uma empresa) com freqncia usam senhas padro do fornecedor e outras configuraes padro do fornecedor para comprometer os sistemas. Essas configuraes so conhecidas nas comunidades de hackers e deixam seu sistema altamente vulnervel a ataques. Muitos usurios instalam esses dispositivos sem aprovao da gerncia e no alteram as configuraes-padro nem fazem as configuraes de segurana. Se as redes wireless no forem implementadas com configuraes de segurana suficientes (incluindo a alterao das configuraes-padro), os sniffers da rede wireless conseguem espreitar o trfego, capturar dados e senhas e entrar e atacar sua rede com facilidade. Alm disso, o protocolo de troca de chaves para a verso antiga da criptografia o 802.11x (WEP) foi quebrado e pode tornar a criptografia intil. Verifique se o firmware dos dispositivos est atualizado para suportar protocolos mais seguros (por exemplo, WPA2). Existem pontos fracos conhecidos em vrios sistemas operacionais, bancos de dados e aplicativos empresariais, e existem tambm formas conhecidas de configurar esses sistemas para corrigir as vulnerabilidades de segurana. Para ajudar quem no especialista nisso, as organizaes de segurana criaram recomendaes para proteo do sistema que aconselham como corrigir esses pontos fracos. Se os sistemas forem deixados com esses pontos fracos, como por exemplo configuraes de arquivo fracas ou servios e protocolos com falhas (para aqueles servios e protocolos que no so necessrios com freqncia), um transgressor poder usar vrias e conhecidas exploraes para atacar servios e protocolos vulnerveis e, assim, ganhar acesso rede da organizao. Websites de origem onde voc poder aprender sobre as melhores prticas da indstria que podero ajud-lo a implantar padres de configurao incluindo, mas no apenas: www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org. Os padres de configurao do sistema tambm devero ser mantidos atualizados para garantir que as deficincias recentemente identificadas sejam corrigidas antes de o sistema ser instalado na rede.
2.2 Desenvolver padres de configurao para todos os componentes do sistema. Certificar-se de que esses padres abrangem todas as vulnerabilidades de segurana conhecidas e esto em conformidade com os padres de fortalecimento do sistema aceitos pelo setor. As fontes dos padres de proteo do sistema aceitos pelo setor podem incluir, mas no se limitam a: Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) National Institute of Standards and Technology (NIST)
Requisito
2.2.1Implementar somente uma funo principal por servidor para evitar funes que exigem diferentes nveis de segurana coexistindo no mesmo servidor. (Por exemplo, servidores da Web, servidores do banco de dados e DNS devem ser implementados em servidores separados.) Observao: Onde tecnologias de virtualizao estiverem em uso, implemente somente uma funo principal por componente do sistema virtual.
Orientao
Isso serve para garantir que os padres de configurao do sistema da sua organizao e os processos relacionados abordem funes do servidor que precisem ter nveis de segurana diferentes ou que possam introduzir pontos fracos de segurana em outras funes do mesmo servidor. Por exemplo: 1. Um banco de dados que precise ter medidas de segurana robustas estaria arriscado a compartilhar um servidor com um aplicativo da Web, que precisa ser aberto e interagir diretamente com a Internet. 2. A no-aplicao de um patch em uma funo aparentemente pequena pode resultar em comprometimento que cause impacto em outras funes mais importantes (como um banco de dados) no mesmo servidor. Este requisito poder ser utilizado em todos os servidores do ambiente de dados do titular do carto (geralmente com base em Unix, Linux ou Windows). Este requisito no dever ser aplicado em sistemas que originalmente implantem nveis de segurana em um nico servidor (ex.: mainframe). Onde forem utilizadas tecnologias de virtualizao, cada componente virtual (ex.: mquina virtual, comutador virtual, aplicativo de segurana virtual, etc) dever ser considerado delimitador "de sistema". Os hipervisores individuais podero ser compatveis com diversas funes, mas uma nica mquina virtual deveria aderir regra "uma funo primria". Nestas circunstncias, o comprometimento do hipervisor poder levar ao comprometimento de todas as funes do sistema. Consequentemente, o nvel de risco tambm dever ser considerado ao localizar diversas funes ou componentes em um nico sistema fsico.
2.2.2 Ativar somente servios, protocolos, daemons, etc. necessrios e seguros, conforme exigido para a funo do sistema. Implantar recursos de segurana para todos os servios, protocolos ou daemons exigidos que forem considerados no seguros. Por exemplo: utilizar tecnologias como SSH, S-FTP, SSL ou IPSec VPN para proteger sistemas como NetBIOS, compartilhamento de arquivos, Telnet, FTP, etc. 2.2.3 Configurar os parmetros de segurana do sistema para impedir o uso incorreto.
Conforme informado no item 1.1.5, existem muitos protocolos de que uma empresa pode precisar (ou estarem ativados por padro) que normalmente sejam usados por indivduos mal-intencionados para comprometer uma rede. Para garantir que apenas os servios e protocolos necessrios sejam ativados e que todos os servios e protocolos no seguros sejam protegidos adequadamente antes da implantao de novos servidores, este requisito dever fazer parte dos padres de configurao da empresa e dos processos relacionados.
Isso serve para garantir que os padres de configurao do sistema de sua organizao e os processos relacionados abordem especificamente as configuraes e os parmetros de segurana que tenham implicaes de segurana conhecidas.
Requisito
2.2.4 Remover todas as funcionalidades desnecessrias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores da Web desnecessrios. 2.3 Criptografar todo o acesso administrativo no console durante a criptografia robusta. Usar tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento baseado na Web e outros acessos administrativos no-console. 2..4Os provedores de hospedagem compartilhada devem proteger cada ambiente hospedado da entidade e os dados do titular do carto. Esses provedores devem atender a requisitos especficos, conforme detalhado no Apndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada.
Orientao
Os padres de proteo do servidor devem incluir processos para resolver funcionalidades desnecessrias com implicaes de segurana especficas (como remover/desativar FTP ou o servidor da Web, caso o servidor no execute essas funes). Se a administrao remota no for feita com autenticao segura e comunicaes criptografadas, informaes confidenciais de nvel administrativo ou operacional (como as senhas do administrador) podero ser reveladas a um espio. Um indivduo mal-intencionado pode usar essas informaes para acessar a rede, tornar-se administrador e roubar os dados. 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 controle de um nico ambiente, muitas vezes essas configuraes nesses servidores compartilhados no sero gerenciveis por clientes individuais, permitindo que os clientes adicionem funes e scripts inseguros que causam impacto na segurana de todos os outros ambientes de clientes e, assim, facilitando para um indivduo malintencionado comprometer os dados de um cliente, obtendo acesso a todos os dados dos outros clientes. Veja o Anexo A.
Orientao para os Requisitos 3 e 4: Proteger os dados do titular do carto

Requisito 3: Proteger os dados armazenados do titular do carto
Mtodos de proteo como criptografia, truncamento, mascaramento e referenciamento so componentes essenciais da proteo de dados do titular do carto. Se um invasor burlar outros controles de segurana e obtiver acesso aos dados criptografados, sem as chaves criptogrficas adequadas, os dados estaro ilegveis e inutilizveis para aquele indivduo. Outros mtodos eficientes de proteo dos dados armazenados devem ser considerados como oportunidades potenciais de minimizao dos riscos. Por exemplo, os mtodos para minimizar os riscos incluem no armazenar os dados do titular do carto a menos que seja absolutamente necessrio, truncar os dados do titular 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 para obter definies de "criptografia robusta" e outros termos do PCI DSS. Requisito
3.1Manter a armazenagem dos dados do titular do carto o mnimo possvel, implementar polticas, processos e procedimentos de reteno e descarte de dados. 3.1.1 Implementar uma poltica de reteno e descarte de dados que inclua: Limite da quantia de dados armazenados e do tempo de reteno ao que exigido pelos requisitos legais, regulatrios e comerciais Processos para excluso segura de dados quando no mais necessrios Requisitos de reteno especficos para dados de titular do carto Processos trimestrais manuais ou automticos para identificar e excluir com segurana os dados do titular 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. Para definir os requisitos de reteno adequados, a empresa dever primeiro conhecer suas necessidades de negcios, bem como as responsabilidades legais e regulamentares que se aplicam indstria ou ao tipo dos dados que sero retidos. O armazenamento prolongado dos dados do titular do carto alm das necessidades da empresa cria um risco desnecessrio. Os nicos dados do titular do carto que podem ser armazenados so o nmero da conta principal, ou PAN (desde que ilegvel), data de vencimento, nome e cdigo de servio. 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!
Requisito
3.2 No armazenar dados de autenticao confidenciais aps a autorizao (mesmo se estiverem criptografados). Os dados de autenticao confidenciais incluem os dados conforme mencionados nos seguintes Requisitos 3.2.1 at 3.2.3: Observao: permissvel para os emissores e empresas que suportam os servios de emisso para armazenar dados de autenticao sensvel se houver justificao de negcios e se os dados forem armazenados com segurana.
Orientao
Os dados confidenciais de autenticao consistem em dados de tarja magntica (ou trilha)6, cdigo de validao do carto ou valor7, e dados de PIN8. 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 falsos e criar transaes fraudulentas. Veja Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS para obter a definio completa de dados de autenticao confidenciais. Observao: 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 bandeira de dbito. Se for armazenado o rastro inteiro, indivduos mal-intencionados que obtiverem esses dados podero reproduzir e vender cartes de pagamento.
3.2.1 No armazenar o contedo completo de qualquer rastro da tarja magntica (localizada na parte posterior do carto, em um chio ou outro local). Esses dados so denominados alternativamente como rastro completo, rastro, rastro 1, rastro 2 e dados da tarja magntica. Observao: No curso normal dos negcios, os seguintes elementos de dados da tarja magntica talvez precisem ser retidos: O nome do titular do carto O nmero da conta principal (PAN) Data de vencimento O cdigo de servio Para minimizar o risco, armazene somente os elementos de dados conforme necessrio para os negcios.
Dados codificados na tarja magntica utilizados para autorizao durante a transao com o carto. Estes dados tambm podero ser encontrados em um chip ou em outra parte do carto. As entidades no podem manter todos os dados da tarja magntica aps a autorizao da transao. Os nicos elementos dos dados da tarja que podem ser retidos so o nmero da conta principal, o nome do titular do carto, a data de vencimento e o cdigo de servio. O valor de trs ou quatro dgitos impresso direita do painel de assinatura ou na frente do carto de pagamento usado para verificar transaes com carto no presente. Nmero de Identificao Pessoal inserido pelo titular do carto durante uma transao com o carto e/ou bloqueio de PIN criptografado dentro da mensagem da transao.
7 8
Requisito
3.2.2 No armazenar o cdigo ou valor de verificao do carto (o nmero de trs ou quatro dgitos impresso na frente ou atrs do carto de pagamento) usado para verificar as transaes com carto no presente.
Orientao
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. Esses tipos de transao podem ser autenticadas como originadas do proprietrio do carto somente ao solicitar esse cdigo de validao do carto, pois o proprietrio do carto o tem em mos e pode ler o valor. Se esses dados proibidos forem armazenados e depois roubados, indivduos mal-intencionados podem executar transaes fraudulentas pela Internet e por MO/TO. Esses valores s devem ser conhecidos pelo proprietrio do carto ou pelo banco que emitiu o carto. Se esses dados proibidos forem armazenados e depois roubados, indivduos mal-intencionados podem executar transaes de dbito protegidas por senha (por exemplo, saques em caixas eletrnicos). 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. O PAN pode ser exibido em sua integridade nos recibos do tipo cpia do comerciante; no entanto, os recibos em papel devem obedecer aos mesmos requisitos de segurana que as cpias eletrnicas e seguir as diretrizes do Padro de segurana de dados do PCI, especialmente o Requisito 9, sobre segurana fsica. O PAN completo tambm pode ser exibido para as pessoas com necessidade de negcios legtima de ver o PAN completo. Este requisito est relacionado proteo do PAN exibida em telas, recibos, etc, e no dever ser confundido com o Requisito 3.4 para proteo do PAN quando armazenado em arquivos, bancos de dados, etc.
3.2.3 No armazenar o PIN (personal identification number) ou o bloco de PIN criptografado.
3.3 Mascarar o PAN quando exibido (os primeiros seis e quatro ltimos dgitos so o nmero mximo de dgitos a serem exibidos). Observaes: Esse requisito no se aplica aos funcionrios e outras partes interessadas em um negcio legtimo que precisam visualizar o PAN completo. Este requisito no substitui os requisitos mais rigorosos em vigor quanto s exibies dos dados do titular do carto por exemplo, para recebimentos do ponto de venda.
Requisito
3.4Tornar o PAN ilegvel em qualquer local onde ele esteja armazenado (inclusive em mdia digital porttil, mdia de back-up, em registros) utilizando qualquer uma das seguintes abordagens: Referncias nicas com base na criptografia robusta (o hash deve ser do PAN inteiro) Truncamento (o hashing no pode ser usado para substituir o segmento truncado do PAN) Tokens de ndice e pads (os pads devem ser armazenados de forma segura) Criptografia robusta com processos e procedimentos de gerenciamento de chaves associados Observao: um esforo relativamente simples para um indivduo mal-intencionado reconstituir os dados do PAN original caso tenha acesso s verses truncadas e hash do PAN. Quando as verses truncada e hash do mesmo PAN estiverem presentes no ambiente de uma entidade, os controles adicionais devero estar implantados para assegurar que as verses truncada e hash no sejam correlacionadas para reconstituir o PAN original. Referncias nicas com base na criptografia robusta (o hash deve ser do PAN inteiro)
Orientao
A falta de proteo dos PANs pode permitir que indivduos mal-intencionados visualizem ou faam download desses dados. 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. Danos decorrentes de roubou ou perda de tarjas de backup durante o transporte podero ser reduzidos ao garantir que os PANs sejam deixados ilegveis por meio de criptografia, truncamento ou codificao hash. Como os logs de auditoria, resoluo de problemas e de exceo precisam ser retidos, voc pode evitar a divulgao dos dados nos logs ao deixar os PANs ilegveis (ou removendo-os) em logs. Ao correlacionar as verses de hash e truncada de um determinado PAN, um indivduo mal-intencionado 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. Consulte a seo Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS para obter definies de "criptografia robusta" e outros termos do PCI DSS.
As funes de sentido nico, como o Algoritmo de has protegido (SHA - Secure Hash Algorithm) com base em criptografia robusta podero ser utilizadas para tornar ilegveis os dados do titular do carto. As funes de hashing so adequadas quando no houver necessidade de recuperar o nmero original (o hashing de direo nica irreversvel). Para complicar a criao de tabelas de arco ris recomendvel, mas no necessrio, que seja inserido um valor de sal funo de hash alm do PAN.
Truncamento (o hashing no pode ser usado para substituir o segmento truncado do PAN)
A inteno do truncamento que somente uma parte (sem exceder os primeiro seis e os ltimos quatro dgitos) do PAN seja armazenado. Isso diferente do mascaramento, no qual o PAN inteiro armazenado, mas isso ocorre quando ele exibido (ou seja, somente parte do PAN exibido em telas, relatrios, recibos, etc.). Este requisito est relacionado proteo do PAN quando armazenado em arquivos, bancos de dados, etc, e no dever ser confundido com o Requisito 3.3 para proteo do PAN exibido em telas, recibos, etc.
Requisito
Tokens de ndice e pads (os pads devem ser armazenados de forma segura)
Orientao
Os tokens de ndice e pads tambm podem ser usados para tornar os dados do titular do carto ilegveis. Um token de ndice um token criptogrfico que substitui o PAN, com base em 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 robusta (veja a definio e os comprimentos da chave no documento Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS) que a criptografia se baseie em um algoritmo testado e aceito pela empresa (e no um algoritmo feito em casa). O objetivo deste requisito abordar a aceitabilidade da criptografia de disco para deixar os dados do titular do carto ilegveis. A criptografia de disco codifica os dados armazenados no armazenamento em massa do computador e descodifica automaticamente as informaes quando um usurio autorizado as solicita. Os sistemas de criptografia de disco interceptam as operaes de leitura e gravao do sistema operacional e executam as transformaes criptogrficas adequadas sem nenhuma ao especial por parte do usurio, alm de fornecer uma senha ou passphrase no incio de uma sesso. Com base nessas caractersticas de criptografia de disco, para obedecer a esse requisito, o mtodo de criptografia de disco no pode ter: 1) Associao direta com o sistema operacional, ou 2) Chaves de decodificao que estejam associadas a contas de usurios.
Criptografia robusta com processos e procedimentos de gerenciamento de chaves associados
3.4.1 Se a criptografia de disco for utilizada (em vez da criptografia de bancos de dados no nvel de arquivo ou coluna), o acesso lgico deve ser gerenciado independentemente de mecanismos de controle de acesso a sistemas operacionais nativos (por exemplo, no utilizando bancos de dados de contas de usurio locais). As chaves da descrio no devem estar ligadas s contas de usurio.
3.5 Proteja qualquer chave usada para tornar os dados do titular do carto seguros contra divulgao e mal uso: Observao: Esse requisito tambm se aplica a chaves de criptografia de chaves usadas para proteger as chaves de criptografia de dados - tais chaves de criptografia de chaves devem ser ao menos to robustas quanto as chaves de criptografia de dados.
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 robustas 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. Os mtodos de armazenamento seguro das chaves de criptografia de chaves incluem, mas no limitam-se a, mdulos de segurana de hardware (HSMs) e adulteram o armazenamento evidente com controle e diviso de conhecimento. Deve haver muito poucas pessoas com acesso s chaves criptogrficas, normalmente s aquelas com responsabilidades de custdia de chaves.
3.5.1Restringir o acesso s chaves criptogrficas ao menor nmero necessrio de responsveis pela proteo.
Requisito
3.5.2 Armazenar chaves criptogrficas de forma segura no menor nmero possvel de locais e formatos.
Orientao
As chaves criptogrficas devem ser armazenadas em segurana, normalmente criptografas com chaves de criptografia e armazenadas em muito poucos locais. As chaves de criptografia de chaves no precisaro ser criptografadas, mas devero ficar protegidas contra divulgao e uso indevido da forma definida no Requisito 3.5. Armazenar as chaves de criptografia de chaves em locais fsicos ou logicamente separados das chaves de criptografia de dados reduz os riscos de acesso no autorizado s duas chaves. 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, aborda todos os elementos de chave, de 3.6.1 a 3.6.8.
3.6 Documentar e implementar por completo todos os processos e procedimentos de gerenciamento de chave com relao s chaves criptogrficas usadas para a criptografia dos dados do titular do carto, incluindo o seguinte: Observao: Vrios padres do setor para o gerenciamento de chave esto disponveis a partir de diversos recursos, incluindo NIST, que pode ser encontrado em http://csrc.nist.gov. 3.6.1 Gerao de chaves criptogrficas robustas
A soluo de criptografia deve gerar chaves robustas, conforme definido em Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS, em "Criptografia robusta". A soluo de criptografia deve distribuir as chaves de forma segura, o que significa que as chaves no deve ser distribudas sem limitao, e sim somente para os responsveis identificados em 3.5.1. A soluo de criptografia deve armazenar as chaves com segurana, o que significa que as chaves no devem ser armazenadas sem limitao (criptografe-as com uma chave de criptografia).
3.6.2 Distribuio segura da chave criptogrfica
3.6.3 Armazenamento seguro de chaves criptogrficas
Requisito
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).
Orientao
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, mas no apenas, 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 essencial para minimizar o risco de algum obter as chaves de criptografia e conseguir decodificar os dados. Caso seja fornecido pelo revendedor do aplicativo de criptografia, siga os processos e recomendaes documentados pelo revendedor para troca peridica das chaves. O proprietrio ou responsvel pela chave tambm poder consultar as melhores prticas da indstria sobre algoritmos de criptografia e gerenciamento de chaves, por exemplo a Publicao especial NIST 800-57, para obter orientaes sobre o criptoperodo adequado de diferentes algoritmos e comprimentos de chaves. A inteo deste requerimento se aplica s chaves utilizadas para criptografar os dados do titular do carto armazenados e a qualquer chave de criptografia de chaves.
3.6.5 Inutilizao ou substituio (por exemplo, arquivamento, destruio e/ ou revogao) de chaves considerada necessria quando a integridade da chave estiver enfraquecida (por exemplo, sada de um funcionrio de uma chave de texto simples) ou houver suspeita de que a chave esteja comprometida. Observao: Caso chaves criptogrficas inutilizadas ou recolocadas precisarem ser retidas, essas chaves 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.
Chaves antigas que no so mais usadas nem necessrias devem ser aposentadas e 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 (veja o item 3.6.6 abaixo). A soluo de criptografia tambm deve levar em considerao e facilitar o processo para substituir as chaves que estejam sabidamente ou potencialmente comprometidas.
Requisito
3.6.6 Se forem usadas operaes manuais de gerenciamento de chave criptogrfica de texto simples, essas operaes devem ser gerenciadas com o uso de conhecimento separado e de controle duplo (por exemplo, exigindo duas ou trs pessoas, cada uma conhecendo somente o seu componente da chave, para reconstituir a chave completa). Observao: Exemplos de operaes manuais de gerenciamento de chave incluem, mas no so limitados a: gerao de chave, transmisso, carregamento, armazenamento e destruio. 3.6.7 Preveno contra a substituio no autorizada de chaves criptogrficas. 3.6.8 Requisito para que os responsveis pela proteo das chaves criptogrficas assinem um formulrio declarando que eles compreendem e aceitam suas responsabilidades pela proteo das chaves.
Orientao
O conhecimento compartilhado e o controle duplo das chaves so usados para eliminar a possibilidade de uma pessoa ter acesso chave inteira. Este controle pode ser aplicado em operaes de gerenciamento de chaves manual onde o gerenciamento de chaves no for implantado por um produto de criptografia.
A soluo de criptografia no deve levar em conta nem aceitar a substituio de chaves vindas de fontes no autorizadas ou de processos inesperados. Este processo assegurar que indivduos que atuem como responsveis se comprometam com a funo de responsveis pela chave e conheam as obrigaes.
Requisito 4: Criptografar a transmisso dos dados do titular do carto em redes abertas e pblicas
As informaes confidenciais devem ser criptografadas durante a transmisso nas redes que so facilmente acessadas por indivduos malintencionados. Redes wireless configuradas de forma incorreta e vulnerabilidades na criptografia legada e protocolos de autenticao continuam a ser alvos contnuos de indivduos mal-intencionados que exploram essas vulnerabilidades para obter acesso privilegiado aos ambientes de dados do titular do carto. Requisito
4.1 Uso de protocolos robustos de criptografia e de segurana (por exemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger dados confidenciais do titular do carto durante a transmisso por redes pblicas, abertas. Os exemplos de redes abertas e pblicas que esto no escopo do PCI DSS incluem mas no se limitam a: A Internet Tecnologias sem fio, Global System for Mobile communications (GSM) General Packet Radio Service (GPRS).
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. Por exemplo: o protocolo de camada de sockets segura (SSL - Secure Sockets Layer) criptografa pginas da web e os dados inseridos nelas. Ao usar sites protegidos por SSL, verifique se https faz parte do URL. Observe que algumas implantaes de protocolo (como SSL verso 2.0 e SSH verso 1.0) possuem vulnerabilidades documentadas, como superfluxos de buffer, que um transgressor 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 que seja utilizada uma conexo no segura.
Requisito
4.1.1 Certificar-se de que as redes wireless estejam transmitindo dados do titular do carto ou estejam conectadas ao ambiente de dados do titular do carto, usar as melhores prticas do setor (por exemplo, IEEE 802.11i) para implementar a criptografia robusta para a autenticao e a transmisso. Observao: O uso de WEP como controle de segurana foi proibido em 30 de junho de 2010.
Orientao
Usurios mal-intencionados usam as vrias ferramentas que esto disponveis gratuitamente para espionar as comunicaes wireless. O uso de criptografias robustas poder limitar a divulgao de informaes confidenciais atravs da rede. Muitos comprometimentos conhecidos dos dados do titular do carto armazenados somente em uma rede com fio foram originados quando um usurio mal-intencionado expandiu o acesso de uma rede wireless insegura. Exemplos de implantaes sem fio que necessitam de criptografia robusta incluem, mas no limitam-se a, GPRS, GSM, WIFI, satlites e Bluetooth. A criptografia robusta para autenticao e transmisso dos dados do titular do carto necessria para evitar que usurios mal-intencionados obtenham acesso rede wireless os dados na rede ou utilizem as redes wireless para chegar a outros dados ou redes internos. A criptografia WEP nunca dever ser utilizada como nico meio de dados de criptografia em um canal sem fio, pois no considerada uma criptografia robusta. vulnervel devido aos fracos vetores de inicializao no processo de troca de chaves WEP e no possui a rotao de chaves necessria. Um transgressor pode usar as ferramentas de cracking por fora bruta amplamente disponveis para penetrar na criptografia por WEP. Os dispositivos sem fio atuais devero ser atualizados (exemplo: atualizar o firmware de ponto de acesso para WPA2) para que sejam compatveis com criptografias robustas. Caso os dispositivos atuais no possam ser atualizados, ser possvel adquirir um novo equipamento ou outros controles de compensao implantados para fornecer criptografia robusta.
4.2Nunca enviar PANs no criptografados por tecnologias de envio de mensagens de usurio final (por exemplo, e-mail, sistemas de mensagens instantneas, bate-papo).
E-mail, sistemas de mensagens instantneas, bate-papo podem ser facilmente interceptados por sniffing de pacotes durante a entrega transversal por redes internas e pblicas. No utilize essas ferramentas de envio de mensagem para enviar o PAN se elas no tiverem recurso de criptografia.
Orientao para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: Usar e atualizar regularmente o software ou programas antivrus
Softwares mal-intencionados, normalmente chamados de "malware" incluindo vrus, worms e cavalos de Tria adentram a rede durante muitas atividades de negcios aprovadas, incluindo e-mail dos funcionrios e uso da Internet, computadores mveis e dispositivos de armazenamento, resultando na explorao das vulnerabilidades do sistema. Softwares anti-vrus devem ser usados em todos os sistemas comumente afetados por malwares para proteg-los das ameaas de softwares atuais e em evoluo. Requisito
5.1Implementar softwares antivrus em todos os sistemas normalmente afetados por softwares mal-intencionados (especialmente em computadores pessoais e servidores).
Orientao
Existe um fluxo constante de ataques usando faanhas amplamente divulgadas, muitas vezes do tipo "zero day" (publicado e divulgado por redes em at uma hora aps a descoberta) contra sistemas at ento seguros. Sem um software antivrus que seja atualizado regularmente, essas novas formas de software mal-intencionado podem atacar e desativar sua rede. Softwares mal-intencionados podem ser baixados e/ou instalados pela Internet sem voc saber, mas os computadores tambm esto vulnerveis ao usarem dispositivos removveis de armazenamento, como CDs e DVDs, USB memory sticks e discos rgidos, cmeras digitais, assistentes pessoais (PDAs) e outros perifricos. Sem a instalao de um software antivrus, esses computadores podem se tornar ponto de acesso para sua rede e/ou mirar nas informaes dentro da rede. Apesar de os sistemas comumente afetados por softwares mal-intencionados normalmente no inclurem mainframes e a maioria dos sistemas Unix (veja mais detalhes abaixo), cada entidade deve ter um processo de acordo com o Requisito de PCI DSS 6.2 para identificar e resolver novas vulnerabilidade de segurana e atualizar os padres e processos de configurao de acordo. Se outro tipo de soluo se dirigir a ameaas idnticas com uma metodologia diferente da abordagem com base em assinatura, ainda poder ser aceita para atender ao requisito. As tendncias em softwares mal-intencionados relacionadas aos sistemas operacionais que a entidade usa 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. Em geral, os sistemas operacionais a seguir no so normalmente afetados por software mal-intencionados: mainframes e alguns servidores Unix (como AIX, Solaris e HP-Unix). No entanto, as tendncias do setor para softwares malintencionados podem mudar rapidamente, e cada organizao deve obedecer ao Requisito 6.2 para identificar e resolver novas vulnerabilidades de segurana e
Requisito
5.1.1 Certificar-se de que todos os programas antivrus podem detectar, remover e proteger contra todos os tipos conhecidos de softwares mal-intencionados. 5.2 Certificar-se de que todos os mecanismos antivrus estejam atualizados, funcionem ativamente e possam gerar registros de auditoria.
Orientao atualizar os padres e processos de configurao de acordo.

importante proteger contra TODOS os tipos e formas de softwares malintencionados. O melhor software antivrus tem eficcia limitada se no tiver assinaturas antivrus atualizada ou se no estiver ativo na rede ou no computador de uma pessoa. Os logs de auditoria oferecem a capacidade de monitorar a atividades do vrus e as reaes do antivrus. Dessa forma, o software antivrus dever obrigatoriamente ser configurado de forma a gerar logs de auditoria, e esses logs devero ser gerenciados de acordo com o Requisito 10.
Requisito 6: Desenvolver e manter sistemas e aplicativos seguros

Indivduos inescrupulosos usam as vulnerabilidades da segurana para obter acesso privilegiado aos sistemas. Muitas dessas vulnerabilidades so solucionadas pelos patches de segurana disponibilizados pelos fornecedores, que devem ser instalados pelas entidades que gerenciam os sistemas. Todos os sistemas crticos devem contar com os patches de software adequados lanados mais recentes para proteger contra a explorao e o comprometimento dos dados do titular do carto por indivduos e softwares mal-intencionados. Observao: Patches de software adequados so aqueles patches que foram avaliados e testados de forma suficiente para determinar se os patches no entram em conflito com as configuraes de segurana existentes. Para aplicativos desenvolvidos internamente, diversas vulnerabilidades podem ser evitadas ao utilizar processos de desenvolvimento do sistema padro e tcnicas de codificao seguras. Requisito
6.1 Certificar-se de que todos os componentes do sistema e softwares esto protegidos de vulnerabilidades conhecidas pois tm os patches de segurana mais recentes disponibilizados pelos fornecedores instalados. Instalar patches de segurana crticos em at um ms aps o lanamento. Observao: Uma empresa talvez considere utilizar uma abordagem baseada nos riscos para priorizar suas instalaes de patches. Por exemplo, ao priorizar mais a infra-estrutura crtica (por exemplo, dispositivos e sistemas disponibilizados ao pblico, bancos de dados) em vez de dispositivos internos menos crticos, para assegurar que sistemas e dispositivos de prioridade elevada sejam resolvidos em um ms e dispositivos e sistemas menos crticos em trs meses.
Orientao
Existe uma quantidade considervel de ataques usando faanhas amplamente divulgadas, muitas vezes do tipo zero day (publicadas em at uma hora) contra sistemas at ento protegidos. Sem implementar os patches mais recentes nos sistemas crticos assim que possvel, um indivduo mal-intencionado pode us-las para atacar e desativar a rede. Pense em priorizar mudanas de forma que patches de segurana crticos em sistemas essenciais ou em risco possam ser instalados em at 30 dias, e outras mudanas menos arriscadas sejam instaladas em 2-3 meses.
Requisito
6.2 Estabelecer um processo para identificar e designar um ranking de risco para as vulnerabilidades de segurana recmdescobertas. Observaes: Os rankings de risco devem ser baseados nas melhores prticas do setor. Por exemplo, os critrios para o ranking de "Alto" risco as vulnerabilidades devem incluir uma pontuao de base CVSS de 4,0 ou mais e/ou um patch oferecido pelo fornecedor classificado por ele como "crtico" e/ou uma vulnerabilidade que afere um componente crtico do sistema. O ranking de vulnerabilidades conforme definido em 6.2.a considerado uma das melhores prticas at 30 de junho de 2012 quando passar a ser um requisito.
Orientao
A inteno deste requisito que as organizaes se mantenham atualizadas quanto a novas vulnerabilidades que podero interferir no sistema. Ao mesmo tempo que importante monitorar os annicos do revendedor em busca de notcias de vulnerabilidades e patches relacionados a seus produtos, tambm importante monitorar os grupos comuns de notcias de vulnerabilidades da indstria e as listas de correspondncias em busca de vulnerabilidades e possveis contornos que o revendedor poder ainda no conhecer. Quando uma organizao identifica uma vulnerabilidade que poder afetar seu ambiente, o risco que essa vulnerabilidade representa poder ser avaliado e classificado. Isto significa que a organizao dever possuir um mtodo para avliar as vulnerabilidades e atribuir classificaes de risco em uma base consistente. Ao mesmo tempo que cada organizao provavelmente ter mtodos diferentes de avaliar uma vulnerabilidade e atribuir uma classificao de risco com base em CDE exclusivo, ser possvel criar com base em sistemas de classificao de risco aceitos pela indstria, como o CVSS. 2.0, NIST SP 800-30, etc. Classificar os riscos (por exemplo, como "altos", "mdios" ou "baixos") permite que as organizaes identifiquem e encaminhem itens de risco de prioridade alta mais rapidamente e reduzam a probabilidade de as vulnerabilidades que representarem maior risco sejam exploradas.
6.3 Desenvolver aplicativos de software (internos e externos, inclusive acesso de administrador com base na web para aplicativos) de acordo com o PCI DSS (por exemplo, autenticao de segurana e login), e com base nas melhores prticas da indstria, e incorporar segurana de informaes durante o ciclo de vida do desenvolvimento do software. Esses processos devem incluir o seguinte: 6.3.1 Remoo de contas, IDs de usurio e senhas do aplicativo antes que ele se torne ativo ou seja lanado aos clientes
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 introduzidas inadvertida ou maliciosamente no ambiente de produo.
Contas de aplicativos personalizados, IDs de usurios e senhas devem ser removidos do cdigo da 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 titular do carto.
Requisito
6.3.2 Analisar o cdigo personalizado antes de liberar para produo ou para os clientes com o objetivo de identificar qualquer vulnerabilidade potencial de codificao. Observao: Esse requisito referente s anlises dos cdigos se aplica a todos os cdigos personalizados (internos e voltados para o pblico), como parte integrante do ciclo de vida de desenvolvimento do sistema. As anlises dos cdigos podem ser realizadas por equipes internas instrudas ou terceiros. Os aplicativos da Web tambm esto sujeitos a controles extras, caso sejam voltados ao pblico, para abranger ameaas e vulnerabilidades contnuas aps a implementao, conforme definido no Requisito 6.6 do PCI DSS. 6.4 Seguir os procedimentos de controle de alteraes para todas as alteraes nos componentes do sistema. Esses processos devem incluir o seguinte: 6.4.1 Ambientes de desenvolvimento/testes e de produo separados.
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 titular do carto. As revises do cdigo podero ser realizadas manualmente ou com o auxlio de ferramentas de reviso automatizadas. As ferramentas de reviso automatizadas possuem uma funo que rev o cdigo em busca de erros de codificao e vulnerabilidades. Ao mesmo tempo que a reviso automatizada til, em geral no dever ser creditada como o nico meio de rever cdigos. Um indivduo com conhecimento e experincia em reviso de cdigos dever estar envolvido no processo de reviso para identificar problemas de codificao difceis ou at impossveis de serem identificados por uma ferramenta. Atribuir as revises de cdigo a algum que no seja o desenvolvedor do cdigo permitir que seja realizada uma reviso independente e objetiva. Sem controles de alterao adequados, 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 malintencionado. 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 ser possvel que o ambiente de produo e os dados do titular do carto sejam comprometidos por vulnerabilidades em um ambiente de teste ou desenvolvimento. Reduzir o nmero de pessoas com acesso ao ambiente de produo e aos dados do titular do carto reduz os riscos e ajuda a garantir que o acesso seja limitado aos indivduos com necessidade comercial de saber. A inteo deste requisito garantir que as funes de desenvolvimento e teste fiquem separadas das funes de produo. Por exemplo: um desenvolvedor poder utilizar uma conta com nvel de administrador com privilgios elevados para uso no ambiente de desenvolvimento, e possuir uma conta em separado com acesso de nvel de usurio ao ambiente de produo. Em ambientes em que um indivduo executa diversas funes (por exemplo, desenvolvimento de aplicativos e implantao de atualizaes em sistemas de produo), as tarefas devero ser atribudas de forma que nenhum indivduo possua controle total de um processo sem um ponto de verificao independente. Por exemplo: atribuir responsabilidades de desenvolvimento, autorizao e monitoramento a indivduos diferentes.
6.4.2 Separao dos deveres entre os ambientes de desenvolvimento/teste e de produo
Requisito
6.4.3 Os dados de produo (PANs ativos) no so usados para testes ou desenvolvimento
Orientao
Os controles de segurana normalmente no so to rgidos no ambiente de desenvolvimento. O uso de dados de produo d aos indivduos malintencionados a oportunidade de ganhar acesso no autorizado aos dados de produo (dados do titular do carto). As bandeiras dos cartes de dbito e diversos adquirentes podem fornecer nmeros de conta adequados para teste caso voc precise de PAN realistas para testar a capacidade de funcionamento do sistema antes de liberar.
6.4.4 Remoo dos dados de teste e contas antes que os sistemas de produo tornem-se ativos
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. A posse dessas informaes pode facilitar o comprometimento do aplicativo e dos dados relacionados do titular do carto. Sem controles de alterao adequados, 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 malintencionado. Da mesma forma, uma alterao poder afetar negativamente o recurso de segurana de um sistema. Neste caso, a alterao dever ser desfeita. O impacto da alterao deve ser documentado de forma que todas as partes afetadas possam planejar adequadamente as mudanas de processamento. A aprovao por partes autorizadas indica que a alterao legtima, e que a alterao autorizada 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 que todos os controles de segurana existentes permaneam no lugar, sejam substitudos por controles igualmente rigorosos ou sejam reforados aps alguma alterao no ambiente. Para alteraes no cdigo do cliente, o teste tambm verificar se nenhuma vulnerabilidade foi introduzida atravs da alterao.
6.4.5 Alterar os procedimentos de controle para implementao de patches de segurana e modificaes de software. Os procedimentos devem incluir o seguinte:
6.4.5.1 Documentao de impacto. 6.4.5.2 Aprovao documentada de alterao pelas partes autorizadas. 6.4.5.3 Teste de funcionalidade para verificar se a alterao no tem impacto adverso sobre a segurana do sistema.
6.4.5.4 Procedimentos de reverso.
Para cada alterao, deve haver procedimentos de back-out in caso de falha na alterao, permitindo restaurar de volta para o estado anterior.
Requisito
6.5 Desenvolver aplicativos baseados nas diretrizes de cdigo seguro. Prevenir vulnerabilidades de codificao comuns nos processos de desenvolvimento do software, para incluir o seguinte: Observao: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9 estavam atualizadas de acordo com as melhores prticas do setor, quando esta verso do PCI DSS foi publicada. No entanto, conforme as melhores prticas do setor para o gerenciamento de vulnerabilidades so atualizadas (por exemplo o Guia OWASP, SANS CWE Top 25, CERT Secure Coding, etc.), as melhores prticas atuais precisam ser usadas para estes requisitos.
Orientao
A camada do aplicativo de alto risco e pode ser almejada por ameaas internas e externas. Sem uma segurana adequada, os dados do titular do carto e outras informaes confidenciais da empresa podero ser expostos, resultando em prejuzo empresa, seus clientes e sua reputao. Como ocorre com todos os requisitos PCI DSS, os requisitos de 6.5.1 a 6.5.5 e de 6.5.7 a 6.5.9 so os controles mnimos que devero estar no lugar. Esta lista composta das prticas de decodificao de segurana mais comuns e aceitas no momento em que esta verso do PCI DSS foi publicada. Todas as alteraes de prticas de decodificao aceitas pela indstria e as prticas de decodificao organizacionais devero igualmente ser atualizadas para que haja correspondncia. Os exemplos dos recursos de decodificao de segurana fornecidos (SANS, CERT e OWASP) so fontes de referncia sugeridas e devero ser includos apenas para orientao. Uma organizao dever incorporar as prticas de decodificao de segurana semelhantes da forma aplicvel tecnologia particular em seu ambiente.
Requisito
6.5.1 Falhas na injeo, particularmente na injeo SQL. Tambm considere as falhas de injeo de OS Command Injection, LDAP e XPath, assim como outras falhas.
Orientao
Valida a entrada para verificar se os dados do usurio no podem modificar o significado dos comandos e das queries. 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 query. Os dados hostis do transgressor enganam o intrprete para executar comandos no pretendidos ou para alterar os dados e permitem que o transgressor ataque os componentes dentro da rede por meio do aplicativo, a fim de iniciar ataques como buffer overflows, ou para revelar tanto informaes confidenciais quando funcionalidades no aplicativo do servidor. Essa tambm uma forma conhecida de fazer transaes fraudulentas em sites habilitados para comrcio. As informaes de solicitaes 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. Garantir que os aplicativos no fiquem vulnerveis a ataques de buffer overflows. Os overflows de buffer ocorrem quando um aplicativo no possui uma verificao de limites adequada em seu espao de buffer. Para explorar uma vulnerabilidade de overflow de buffer, um transgressor envia a um aplicativo uma quantidade de informaes superior que um de seus buffers consegue manejar. 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 transgressor consegue inserir um cdigo mal-intencionado no final do buffer e empurrar esse cdigo para o espao de memria executvel ao provocar overflow no buffer. O cdigo mal-intencionado ento executado e frequentemente permite que o transgressor acesse remotamente o aplicativo ou o sistema infectado. Evita falhas criptogrficas. Os aplicativos que no utilizam recursos de criptografia rigorosos da maneira adequada para armazenar dados correm um risco maior de ficarem comprometidos e de expor os dados do titular do carto. Caso um transgressor consiga explorar os processos criptogrficos, ele poder obter acesso de texto sem criptografia a dados criptografados. Criptografe corretamente todas as comunicaes autenticadas e confidenciais. Os aplicativos que no criptografarem adequadamente o trfego de rede utilizando criptografia rigorosa correm um risco maior de ficarem comprometidos e de expor os dados do titular do carto. Se o transgressor conseguir explorar os processos criptografados, poder obter controle de um aplicativo ou at mesmo obter acesso de texto no criptografado a dados criptografados.
6.5.2 Buffer Overflow
6.5.3 Armazenamento criptogrfico seguro
6.5.4 Comunicaes inseguras
Requisito
6.5.5 Manuseio incorreto de erros
Orientao
No vaze informaes por mensagens de erro ou outros meios. Os aplicativos podem sem querer vazar informaes sobre sua configurao, trabalhos internos ou violar a privacidade por meio de diversos problemas no aplicativo. Os transgressores usam esse ponto fraco para roubar dados confidenciais ou para aplicar ataques mais srios. Alm disso, o manuseio incorreto de erros fornece informaes que ajudam um indivduo mal-intencionado a comprometer o sistema. Se um indivduo mal-intencionado puder criar erros que o aplicativo no conseguir 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 diz que o ID de usurio fornecido est correto e que eles devem concentrar os esforos somente na senha. Use mensagens de erro mais genricas, como os dados no puderam ser verificados". Todas as vulnerabilidades altas observadas pelo Requisito 6.2 que poderiam afetar o aplicativo devero ser levadas em considerao durante a fase de desenvolvimento. Por exemplo: uma vulnerabilidade identificada em uma biblioteca compartilhada ou no sistema operacional destacado dever ser avaliada e encaminhada antes do aplicativo ser liberado para produo.
6.5.6 Todas as vulnerabilidades "Alto" identificadas no processo de identificao de vulnerabilidade (conforme definido no Requisito 6.2 do PCI DSS). Observao: Este requisito ser considerado uma das melhores praticas at 30 de junho de 2012 quando passar a ser um requisito. Nos aplicativos da web e nas interfaces dos aplicativos (externos ou internos) sero aplicados os seguintes requisitos adicionais: 6.5.7 Scripting de site cruzado (XSS)
Os aplicativos web, tanto internos quanto externos (pblicos), possuem riscos de segurana exclusivos com base em sua arquitetura e sua relativa facilidade em apresentar comprometimento. Todos os parmetros devem ser validados antes da incluso. Ocorrem falhas no XSS sempre que o aplicativo pegar os dados fornecidos pelo usurio e envi-los para um navegador sem primeiro validar ou codificar esse contedo. O XSS permite que os transgressores executem o script no navegador da vtima, que pode seqestrar sesses de usurios, desfigurar sites, possivelmente introduzir worms, etc.
Requisito
6.5.8 Controle de acesso inapropriado (como referncias diretas inseguras a objetos, falhas em restringir o acesso a URLs e diretrios transversais)
Orientao
No exponha referncias de objetos internos aos usurios. 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 URM ou form de parmetro. Os transgressores podem manipular essas referncias para acessar outros objetos sem autorizao. Fora 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 transgressores podem usar esse ponto fraco para acessar e executar operaes no autorizadas, acessando diretamente esses URLs. Proteger contra transversal de diretrio. Um transgressor poder ser capaz de enumerar e navegar pela estrutura do diretrio de um website, obtendo acesso a informaes no autorizadas e descobrindo o funcionamento do site para explorao futura.
6.5.9 Falsificao de solicitaes de site cruzado (CSRF).
No responda a credenciais de autorizao e tokens enviados automaticamente pelos navegadores. Um ataque de CSRF fora o navegador da vtima logada a enviar uma solicitao pr-autenticada a um aplicativo da Web vulnervel, que ento fora o navegador da vtima a executar uma ao hostil em benefcio do transgressor. O ataque de CSRF pode sero to poderoso quanto o aplicativo da Web atacado. Ataques em aplicativos na Web so comuns e muitas vezes bem-sucedidos, e so permitidos por prticas de codificao ruins. Este requisito para analisar aplicativos ou instalar firewalls de aplicativos da Web destina-se a reduzir enormemente o nmero de comprometimentos em aplicativos da Web que resultam em violaes nos dados do titular do carto. Ferramentas ou mtodos de avaliao da segurana de vulnerabilidade manual ou automatizada e/ou varredura de vulnerabilidades do aplicativo podem ser usados para satisfazer este requisito. Firewalls de aplicativo da Web filtram e bloqueiam trfego no essencial na camada do aplicativo. Utilizado em conjunto com um firewall baseado em rede, um firewall de aplicativo da Web configurado corretamente evita ataques na camada de aplicativos caso estes estejam codificados ou configurados incorretamente.
6.6 Para aplicativos da Web voltados ao pblico, abordar novas ameaas e vulnerabilidades continuamente e assegurar que esses aplicativos estejam protegidos contra ataques conhecidos por qualquer um dos mtodos a seguir: Analisar os aplicativos da Web voltados ao pblico por meio de ferramentas ou mtodos manuais ou automticos de avaliao de segurana das vulnerabilidades dos aplicativos, pelo menos anualmente e aps quaisquer alteraes Instalar um firewall para aplicativos da Web diante de aplicativos da Web voltados ao pblico
Orientao para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas

Requisito 7: Restringir o acesso aos dados do titular do carto de acordo com a necessidade de conhecimento para o negcio
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. Requisito
7.1 Limitar o acesso aos componentes do sistema e aos dados do titular do carto somente quelas pessoas cuja funo requer tal acesso. As limitaes de acesso devem incluir o seguinte: 7.1.1 Restrio dos direitos de acesso a IDs de usurios privilegiados ao menor nmero de privilgios necessrios para desempenhar as responsabilidades da funo 7.1.2 A concesso dos privilgios est baseada na classificao e na atribuio da funo da equipe individual 7.1.3 Requisito para aprovao por partes autorizadas documentada especificando os privilgios exigidos. 7.1.4 Implementao de um sistema de controle de acesso automtico
Orientao
Quanto mais pessoas tiverem acesso aos dados do titular do carto, mais risco haver de que a conta do usurio seja utilizada indevidamente. Limitar o acesso quelas pessoas com um forte motivo corporativo para ter esse acesso ajuda sua organizao a evitar o mau uso dos dados do titular do carto por meio de inexperincia ou ms intenes. Quando os direitos de acesso so concedidos somente para uma menor quantidade de dados e privilgios necessrios para executar um trabalho, isso se chama "privilgio mnimo" e necessidade de divulgao, e quando os privilgios so atribudos aos indivduos com base na classificao do cargo e na funo, isso se chama controle de acesso baseado na funo ou RBAC. O reforo do controle de acesso baseado na funo no limitado a uma camada de aplicativos ou qualquer soluo de autorizao especfica. Por exemplo, tecnologias incluindo mas no se limitando a servios de diretrio como Active Directory ou LDAP, Listas de Controle de Acesso (ACLs) e TACACS so solues viveis desde que estejam adequadamente configuradas para reforar os princpios de privilgio mnimo e necessidade de divulgao. As organizaes devem criar polticas e processos claros para controle de acesso de dados com base em necessidade de divulgao e usar controle de acesso baseado na funo para definir como e para quem o acesso dever ser concedido, inclusive para processos de autorizao de gerenciamento adequado.
Requisito
7.2 Estabelea um sistema de controle de acesso para os componentes do sistema com mltiplos usurios que restringe o acesso com base na necessidade de conhecimento do usurio e est configurado para "recusar todos", a menos que seja permitido de forma especfica. Esse sistema de controle de acesso deve incluir o seguinte: 7.2.1 Abrangncia de todos os componentes do sistema 7.2.2 A concesso dos privilgios s pessoas est baseada na classificao e na atribuio da funo 7.2.3 Configurao padro recusar todos Observao: Alguns sistemas de controle de acesso so definidos, como padro, como permitir todos, permitindo portanto o acesso a menos que/at que uma norma seja redigida para recus-lo de forma especfica.
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 titular do carto. O uso de um sistema ou mecanismo de controle de acesso automatizado essencial para gerenciar vrios usurios. Esse sistema deve ser criado segundo as polticas, e os processos de controle de acesso da sua organizao (incluindo necessidade de acesso e controle de acesso baseado na funo) devem gerenciar o acesso a todos os componentes do sistema e deve ter uma configurao padro recusar todos para garantir que ningum receba acesso at que se crie uma regra dando especificamente tal acesso.
Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador
Atribuir uma identificao exclusiva (ID) a cada pessoa com acesso assegura que cada indivduo seja exclusivamente responsvel pelas suas aes. Quando tal responsabilidade estiver em vigor, as aes desempenhadas nos dados e sistemas crticos sero realizadas por usurios conhecidos e autorizados, e podero levar a eles. Observao: Esses requisitos so aplicveis a todas as contas, inclusive contas de pontos de venda com capacidades administrativas e todas as contas usadas para visualizar ou acessar os dados do titular do carto ou acessar sistemas com dados do titular do carto. No entanto, os Requisitos 8.1, 8.2 e 8.5.8 a 8.5.15 no tm por objetivo serem aplicados a contas de usurio em um aplicativo de pagamento de um ponto de venda que possua acesso somente a um nmero de carto por vez para facilitar a transao nica (como contas de caixa). Requisito
8.1Atribuir a todos os usurios um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do carto.
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. Esses itens de autenticao, quando usados alm dos IDs exclusivos, ajuda a proteger os IDs exclusivos dos usurios contra o comprometimento (visto que quem estiver tentando o comprometimento precisa conhecer tanto o ID exclusivo quanto a senha ou outro item de autenticao). Certificados digitais so uma opo vlida como formulrio do tipo de autenticao "algo que voc tem" desde que seja exclusivo.
8.2Alm de atribuir um ID exclusivo, um ou mais dos seguintes mtodos foi empregado para autenticar todos os usurios: Algo que voc sabe, como uma senha ou uma passphrase Algo que voc tem, como um dispositivo de token ou um smart card Algo que voc , como a biomtrica
Requisito
8.3Incorporar a autenticao por dois fatores para o acesso remoto (acesso no nvel da rede que se origina fora dela) rede pelos funcionrios, administradores e terceiros. (Por exemplo, autenticao remota e servio de dial-in (RADIUS) com tokens; sistema de controle de acesso ao controlador de acesso ao terminal (TACACS) com tokens; ou outras tecnologias que facilitam a autenticao por dois fatores.) Observao: A autenticao de dois fatores exige que dois dos trs mtodos de autenticao (consulte o Req. 8.2 com descries de mtodos de autenticao) sejam usados para autenticao. Usar um fator duas vezes (e.g., usar duas senhas separadas) no caracteriza autenticao de dois fatores.
Orientao
A autenticao de dois fatores exige duas formas de autenticao para acessos com maior risco, como aqueles originados de fora de sua rede. Para uma segurana adicional, sua organizao tambm pode considerar o uso da autenticao de dois fatores ao acessar redes de segurana mais alta a partir de redes de segurana mais baixa; por exemplo, a partir de computadores desktop corporativos (segurana mais baixa) para servidores de produo/bancos de dados com dados do titular do carto (segurana alta). Pretende-se que esse requisito aplique-se aos usurios que possuem acesso remoto ao trabalho, onde esse acesso remoto pudesse levar ao ambiente de dados do titular do carto. Nesse contexto, o acesso remoto se refere ao acesso em nvel de rede originada de uma rede particular de uma entidade externa, tanto pela Internet como por uma rede ou sistema "no confivel", como um terceiro ou funcionrio acessando a rede da entidade usando um computador mvel. Acesso interno LAN-a-LAN (por exemplo, entre dois escritrios por VPN seguro) no considerado acesso remoto para os fins deste requisito. Se o acesso remoto for para a rede de uma entidade que possui segmentao adequada, como a impossibilidade de acesso a usurios remotos ou de impacto ao ambiente de dados do titular do carto, a autenticao de dois fatores para o acesso remoto quela rede no ser exigida pelo PCI DSS; No entanto, a autenticao de dois fatores exigida para qualquer acesso remoto a redes com acesso ao ambiente de dados do titular do carto e recomendvel para todo acesso remoto a redes de entidades.
8.4 Converta todas as senhas em ilegveis durante a transmisso e armazenamento em todos os componentes do sistema usando criptografia robusta.
Muitos dispositivos de rede e aplicativos transmitem o ID do usurio e as senhas sem criptografia por uma rede e/ou tambm armazenam as senhas sem criptografia. Um indivduo mal-intencionado pode facilmente interceptar o ID de usurio e a senha sem criptografia ou legvel durante a transmisso usando um sniffer, ou ento acessar diretamente os IDs do usurio e as senhas no criptografas em arquivos onde eles so armazenados e usar esses dados roubados para obter acesso no autorizado. Durante a transmisso, as credenciais do usurio ou o tnel podem ser criptografados 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 identificao de usurios e gesto de autenticao.
8.5Garantir um controle adequado da autenticao e da senha do usurio para usurios que no sejam clientes e administradores em todos os componentes do sistema, da forma a seguir:
Requisito
8.5.1Controle o acrscimo, a excluso e a modificao dos IDs do usurio, credenciais e outros objetos do responsvel pela identificao.
Orientao
Para garantir que os usurios adicionados no sistema estejam sejam todos vlidos e reconhecidos, a adio, excluso e modificao dos IDs do usurio deve ser gerenciada e controlada por um pequeno grupo com autoridade especfica. A capacidade de gerenciar esses IDs de usurio deve estar limitada somente a esse pequeno grupo. Muitos indivduos mal-intencionados usam a engenharia social por exemplo, ligam para o help desk e agem como um usurio legtimo para trocar a senha, de forma que possam utilizar um ID de usurio. Pense em usar uma pergunta secreta que s o usurio em si possa responder para ajudar os administradores a identificarem o usurio antes de redefinir as senhas. As perguntas devem so protegidas corretamente e no podem ser compartilhadas. Se a mesma senha for usada para todos os novos usurios configurados, um usurio interno, ex-funcionrio ou indivduo mal-intencionado pode conhecer ou descobrir facilmente essa senha e us-la para ter acesso s contas. Se um funcionrio sair da empresa e ainda tiver acesso rede por meio de sua conta de usurio, pode ocorrer um acesso desnecessrio ou mal-intencionado aos dados do titular do carto. Esse acesso pode acontecer pelo ex-funcionrio ou por um usurio mal-intencionado que explore a conta antiga e/ou no utilizada. Pense em implementar um processo com o departamento de RH para notificao imediata quando um funcionrio for desligado da empresa, de forma que a conta dele possa ser rapidamente desativada. A existncia de contas inativas permite que um usurio no autorizado explore a conta no utilizada para possivelmente acessar os dados do titular do carto. Permitir que fornecedores (como os fornecedores do POS) 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. A monitoria do acesso do fornecedor ao ambiente de dados do titular do carto se aplica do mesmo modo que para outros usurios, como funcionrios da empresa. Isso inclui monitorar e registrar as atividades conforme exigem os Requisitos 10.1 e 10.2 do PCI DSS e verificar se o uso das contas de fornecedor remoto est de acordo com a poltica conforme definido nos Requisitos 12.3.8 e 12.3.9.
8.5.2Verificar a identidade do usurio antes de realizar as redefinies de senha.
8.5.3 Definir as senhas iniciais para um valor exclusivo para cada usurio e alterar imediatamente aps a primeira utilizao. 8.5.4 Revogar imediatamente o acesso de quaisquer usurios desligados da empresa.
8.5.5 Remover/desativar as contas dos usurios inativos pelo menos a cada 90 dias. 8.5.6 Ativar as contas usadas pelos fornecedores somente para a manuteno remota durante o perodo necessrio. Monitorar as contas de acesso remoto do fornecedor quando estiver em uso.
8.5.7 Comunicar os processos e polticas de autenticao a todos os usurios que possuem acesso aos dados do titular do carto.
Comunicar os procedimentos de senha a todos os usurios os ajuda a entender e seguir as polticas e a deix-los alerta contra indivduos mal-intencionados que possam tentar explorar suas senhas para obter acesso aos dados do titular do carto (por exemplo, ligando para um funcionrio e perguntando sua senha para que ele possa resolver um problema).
Requisito
8.5.8 No use contas, senhas ou outros mtodos de autenticao de grupo, compartilhados ou genricos .
Orientao
Se vrios usurios compartilharem as mesmas credenciais de autenticao (conta e senha por exemplo), fica impossvel atribuir responsabilidade a um usurio ou fazer um registro eficaz das aes dele, pois uma determinada ao pode ter sido executada por qualquer pessoa no grupo que compartilhe da conta e da senha. Esse requisito de IDs exclusivas e senhas complexas cumprido com frequncia por funes administrativas ao usar, por exemplo, sudo ou SSH para que o administrador faa o logon inicialmente com seus ID e senha exclusivos e, em seguida, conecte-se conta do administrador por meio do sudo ou do SSH. Normalmente logins de raiz direta so desativados para evitar o uso dessa conta administrativa compartilhada. Dessa forma, a contabilidade e as trilhas de auditoria individuais so mantidas. No entanto, mesmo com o uso de ferramentas como sudo e SSH, os verdadeiros IDs e senhas do administrador tambm devem atender aos requisitos do PCI DSS (se tais contras no foram desativadas).
8.5.9 Alterar as senhas do usurio pelo menos a cada 90 dias. 8.5.10Exigir um comprimento mnimo de senha de pelo menos sete caracteres. 8.5.11 Usar senhas que contenham caracteres alfanumricos. 8.5.12 No permitir que ningum envie uma nova senha que seja a mesma de uma das quatro ltimas senhas que tenha sido usada. 8.5.13 Limitar tentativas de acesso repetidas ao bloquear o ID do usurio aps seis tentativas, no mximo.
Senhas fortes so a primeira linha de defesa para uma rede, pois um indivduo mal-intencionado muitas vezes primeiro tentar encontrar contas com senhas fracas ou inexistentes. O indivduo mal-intencionado ter mais tempo para localizar essas contas fracas e comprometer uma rede ao estilo de um DI de usurio vlido caso as senhas seja curtas, simples de serem adivinhadas ou vlidas por muito tempo sem alteraes. Senhas fortes podem ser foradas e mantidas segundo estes requisitos ao ativar os recursos de segurana de senha e de conta que vm com o sistema operacional (como o Windows, por exemplo), redes, bancos de dados e outras plataformas. Sem a implementao de mecanismos de bloqueio de conta, um transgressor pode tentar continuamente adivinhar uma senha por meio de ferramentas manuais ou automatizadas (como cracking de senha) at ter sucesso e ganhar acesso conta do usurio. 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 mal-intencionado 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 help desk podero validar que o proprietrio da conta a causa do bloqueio (por causa de erros de digitao). Quando os usurios se distanciam de uma mquina aberta com acesso a dados crticos de rede e dados do titular do carto, essa mquina poder ser usada por outras pessoas na ausncia do usurio, resultando em acesso no autorizado conta e/ou mau uso da conta.
8.5.14Definir a durao do bloqueio para um mnimo de 30 minutos ou at o administrador ativar o ID do usurio.
8.5.15 Se uma sesso estiver ociosa por mais de 15 minutos, exigir que o usurio redigite a senha para reativar o terminal.
Requisito
8.5.16 Autenticar todos os acessos para qualquer banco de dados que contenha dados do titular do carto, incluindo acesso por meio de aplicativos, administradores e todos os outros usurios. Restringir acesso direto ou as consultas aos bancos de dados aos administradores do banco de dados.
Orientao
Sem autenticao do usurio para acesso a bancos de dados e aplicativos, o potencial para acesso no autorizado ou malicioso 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 ter acesso direto ao banco de dados para as tarefas administrativas).
Requisito 9: Restringir o acesso fsico aos dados do titular do carto

Qualquer acesso fsico aos dados ou sistemas que armazenam dados do titular do carto fornecem a oportunidade para as pessoas acessarem dispositivos ou dados e removerem sistemas ou cpias impressas, e deve ser restrito de forma adequada. Para as finalidades do Requisito 9, "funcionrio" refere-se a funcionrios que trabalham em perodo integral e meio-perodo, funcionrios e equipes temporrias, e prestadores de servios e consultores que atuem com presena fsica no endereo da entidade. Um visitante refere-se a um fornecedor, convidado de um funcionrio, equipes de servio ou qualquer pessoa que precise adentrar as dependncias por um breve perodo, normalmente um dia, no mximo. "Mdia" refere-se a todas as mdias em papel ou eletrnicas que contm dados do titular do carto. Requisito
9.1Usar controles de entrada facilitados e adequados para limitar e monitorar o acesso fsico aos sistemas no ambiente de dados do titular do carto. 9.1.1 Usar cmeras de vdeo ou outros mecanismos de controle de acesso para monitorar o acesso fsico individual a reas confidenciais. Analisar os dados coletados e relacionar com outras entradas. Armazenar, por pelo menos trs meses, a menos que seja restringido de outra forma pela lei. Observao: reas confidenciais referem-se a qualquer central de dados, sala de servidores ou qualquer rea que contenha sistemas que armazenem, processem ou transmitam dados do titular do carto. Isso exclui as reas nas quais h somente terminais do ponto de venda presentes, como as reas dos caixas em uma loja de varejo. 9.1.2 Restringir o acesso fsico a pontos de rede acessveis publicamente. Por exemplo, reas acessveis a visitantes no devem ter portas de rede ativadas a no ser que o acesso rede seja autorizado explicitamente.
Orientao
Sem controles de acesso fsico, pessoas no autorizadas podem potencialmente ganhar acesso ao edifcio e s informaes confidenciais, e podem alterar as configuraes do sistema, introduzir vulnerabilidades na rede ou destruir ou roubar equipamentos. Ao investigar violaes fsicas, esses controles podem ajudar a identificar indivduos que acessam fisicamente as reas que armazenam os dados do titular do carto. Exemplos de reas confidenciais incluem salas de servidor do banco de dados corporativo, sala de servidor back-end de um local de revenda que armazene dados do titular do carto e reas de armazenamento de grandes quantidades de dados do titular do carto,
Restringir o acesso aos pontos de rede evita que indivduos mal-intencionados se conectem em tomadas de rede prontamente disponveis que pode lhes dar acesso aos recursos de rede internos. Pense em desativar as tomadas de rede enquanto elas no estiverem em uso e reativ-las somente enquanto forem necessrias. Em reas pblicas, como salas de conferncia, crie redes privadas para permitir que fornecedores e visitantes acessem somente a Internet, e no sua rede interna.
Requisito
9.1.3 Restringir o acesso fsico a pontos sem fio de acesso, gateways, dispositivos portteis, hardwares de comunicao/rede e linhas de telecomunicao.
Orientao
Sem segurana no acesso a componentes e dispositivos wireless, indivduos malintencionados podem usar os dispositivos wireless da sua empresa que no estejam sendo utilizados para acessar os recursos de rede ou at para conectar seus prprios dispositivos rede wireless para obter acesso no autorizado. Alm disso, fazer a segurana dos materiais de comunicao e rede evita que usurios mal-intencionados interceptem o trafego da rede ou conectem-se fisicamente seus prprios dispositivos em seus recursos de rede com fio. Pense em colocar pontos de acesso wireless, gateways e material de comunicao/redes em reas de armazenamento seguro, como dentro de armrios trancados ou salas de servidores. Para redes wireless, assegure-se de que a criptografia robusta est ativada. Ative o bloqueio automtico de dispositivo em dispositivos portteis wireless aps um perodo longo parado e defina um uma senha nos dispositivos quando eles forem iniciados.
9.2 Desenvolver procedimentos para diferenciar facilmente os funcionrios dos visitantes, principalmente nas reas onde os dados do titular do carto podem ser acessados.
Sem sistemas de crachs e controles de porta, usurios no autorizados e malintencionados podem facilmente obter acesso s instalaes para roubar, desativar, interromper ou destruir sistemas crticos e dados do titular do carto. Para o controle ideal, pense em implementar um sistema de acesso por crach ou carro dentro e fora das reas de trabalho que contenham dados do titular do carto. Identificar visitantes autorizados para que sejam facilmente distinguidos dos funcionrios do local evita que os visitantes no autorizados acessem reas contendo dados do titular do carto.
9.3 Certificar-se de que todos os visitantes so identificados da seguinte forma: 9.3.1 Autorizados antes de adentrar as reas onde os dados do titular do carto so processados ou mantidos. 9.3.2 Recebem um token fsico (por exemplo, um crach ou dispositivo de acesso) que expira e que identifica os visitantes como no sendo funcionrios. 9.3.3 solicitado que os visitantes apresentem o token fsico antes de sair das dependncias ou na data do vencimento
O controle de visitantes importante para reduzir a possibilidade de pessoas no autorizadas e mal-intencionadas obterem acesso a suas instalaes (e possivelmente aos dados do titular do carto). Os controles de visitantes so importantes para garantir que eles s entrem em reas onde so autorizados e que sejam identificados como visitantes, de forma que os funcionrios possam monitorar suas atividades e que o acesso esteja restrito a somente a durao da visita em si.
Requisito
9.4 Usar um registro de visitantes para manter um monitoramento fsico da auditoria da atividade do visitante. Documente no registro o nome do visitante, a empresa representada e o funcionrio que autoriza o acesso fsico. Armazene esse registro por pelo menos trs meses, a menos que seja restringido de outra forma pela lei. 9.5 Armazene back-ups de mdia em um local seguro, preferencialmente em outras instalaes, como um lugar alternativo de back-up ou uma instalao comercial de armazenamento. Analisar a segurana do local pelo menos uma vez por ano. 9.6 Proteja toda a mdia fisicamente.
Orientao
Um log de visitantes, documentando as informaes mnimas sobre eles, de manuteno fcil e barata e, durante uma possvel violao de dados, ajuda a identificar acesso fsico a um edifcio ou a uma sala e um possvel acesso aos dados do titular do carto. Pense em implementar logs na entrada s instalaes e, especialmente, em zonas onde estejam presentes os dados do titular do carto. Se armazenados em um local no protegido, os backups que contm dados do titular do carto podem ser facilmente perdidos, roubados ou copiados com ms intenes. Para armazenamento protegido, pense em contratar uma empresa de armazenamento de dados comerciais OU, para empresas menores, usar um cofre em um banco. Os dados do titular 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. Procedimentos e processos para proteger os dados do titular 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. importante que a mdia seja identificada para que seu status de classificao possa ser discernvel. A mdia no identificada como confidencial pode no ser protegida adequadamente ou ser roubada. A mdia pode ser perdida ou roubada se for enviada por um mtodo no rastrevel, como remessa postal. Use os servios de um mensageiro seguro para entregar mdias que contenham dados do titular do carto, de forma que voc possa usar os sistemas de rastreamento para manter inventrio e localizao dos envios. Os dados do titular do carto que saem de reas seguras sem um processo aprovado pela gerncia podem levar a dados perdidos ou roubados. Sem um processo firme, os locais de mdia no so rastreados e no existe um processo para onde os dados vo ou a forma como eles so protegidos. 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.7 Manter o controle rigoroso quanto distribuio interna ou externa de qualquer tipo de mdia, incluindo o seguinte: 9.7.1 Classificar a mdia para que a confidencialidade dos dados possa ser determinada. 9.7.2 Enviar a mdia via mensageiro seguro ou outro mtodo de entrega que pode ser monitorado com preciso.
9.8 Certificar-se de que a gerncia aprova quaisquer e todas as mdias contendo dados do titular do carto que so movidas de uma rea segura (principalmente quando as mdias forem distribudas s pessoas). 9.9 Manter um controle rigoroso sobre o armazenamento e a acessibilidade das mdias que contm dados do titular do carto. 9.9.1 Manter adequadamente os registros do inventrio de todas as mdias e realizar inventrios das mdias pelo menos uma vez por ano.
Requisito
9.10 Destruir as mdias que contm dados do titular do carto quando eles no forem mais necessrios por motivos de negcios ou legais, conforme se segue: 9.10.1 Triturar, incinerar ou amassar materiais impressos para que os dados do titular do carto no possam ser recuperados. 9.10.2Tornar os dados do titular do carto nas mdias eletrnicas irrecuperveis para que esses dados no possam ser reconstitudos.
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 malintencionados poder estar aptos a recuperar as informaes da mdia descartada, levando ao comprometimento dos dados. Por exemplo: indivduos malintencionados podem usar uma tcnica conhecida como dumpster diving, na qual eles pesquisam em lixeiras e usam as informaes encontradas para iniciar um ataque. Exemplos de mtodos para destruir mdias eletrnicas incluem limpeza segura, desmagnetizao ou destruio fsica (como esmagar ou triturar os discos rgidos).
Orientao para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente

Requisito 10: Acompanhar e monitorar todos os acessos com relao aos recursos da rede e aos dados do titular do carto
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. Requisito
10.1 Definir um processo para vincular todos os acessos aos componentes do sistema (principalmente o acesso realizado com privilgios administrativos como raiz) para cada usurio individual. Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos:
Orientao
essencial ter um processo ou sistema que vincule o acesso do usurio aos componentes do sistema acessados e, mais particularmente, queles usurios com privilgios administrativos. Esse sistema gera logs de auditoria e oferece a capacidade de rastrear as atividades suspeitas de um usurio especfico. Equipes forenses ps-incidente dependem muito desses logs para iniciar a investigao. 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 ps-acidente. 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 titular do carto. Um registro de todos os acessos individuais para os dados do titular do carto pode identificar quais contas podem ter sido comprometidas ou usadas inadequadamente. 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 de volta ao especfica e ao indivduo. Usurios mal-intencionados tentam frequentemente alterar os registros de auditoria para ocultar suas aes e um registro de acesso permite que uma empresa rastreia quaisquer inconsistncias ou potenciais adulteraes dos registros para uma conta individual. Indivduos mal-intencionados na rede muitas vezes executam vrias tentativas de acesso nos sistemas alvejados. Vrias tentativas invlidas de login podem ser um indicador de tentativas de um usurio no autorizado "forar" ou adivinhar uma senha.
10.2.1 Todos os acessos individuais aos dados do titular do carto
10.2.2 Todas as aes desempenhadas por qualquer pessoa com privilgios raiz ou administrativos
10.2.3 Acesso a todas as trilhas de auditoria
10.2.4 Tentativas invlidas de acesso lgico
Requisito
10.2.5 Uso de mecanismos de identificao e autenticao
Orientao
Sem saber quem estava registrado no momento de um incidente, impossvel identificar as contas que podem ter sido usadas. Alm disso, usurios malintencionados tentam manipular os controles de autenticao com o objetivo de contorn-los ou imitar uma conta vlida. Atividades incluindo, mas no limitadas a, escalao de privilgio ou alteraes nas permisses de acesso podem indicar uso no autorizado de mecanismos de autenticao. Desativar os registros de auditoria antes de realizar atividades ilcitas uma meta comum a usurios mal-intencionados que desejam evitar ser detectados. A inicializao dos registros de auditoria podem indicar que a funo de registro foi desativada. 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. Consulte a seo Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS para obter definies de "objetos no nvel do sistema".
10.2.6 Inicializao dos registros de auditoria
10.2.7 Criao e excluso de objetos do nvel do sistema
10.3 Registrar pelo menos as seguintes entradas das trilhas de auditoria para todos os componentes do sistema para cada evento: 10.3.1 Identificao do usurio 10.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
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.
Requisito
10.4 Usando tecnologia de sincronizao de tempo, sincronize todos os relgios e horrios crticos do sistema e assegure-se de que os seguintes itens sejam implementados para adquirir, distribuir e armazenar horrios. Observao: Um exemplo de tecnologia de sincronizao de tempo o Network Time Protocol (NTP). 10.4.1 Sistemas crticos tm o horrio correto e consistente 10.4.2 Os dados de horrio so protegidos 10.4.3 As definies de horrio so recebidas de fontes de horrio aceitas pelo setor
Orientao
A tecnologia para sincronizao do horrio usada para sincronizar os relgios. Quando implementada corretamente, essa tecnologia pode sincronizar relgios em um grande quantidade de sistemas com uma frao de segundo de um para outro. Alguns problemas que podem ocorrer quando os relgios no so sincronizados adequadamente incluem, mas no se limitam a tornar difcil (se no impossvel) comparar arquivos de registro de diferentes sistemas, estabelecer uma sequncia exata de eventos (cruciais para anlise forense no caso de uma violao) e evitar que protocolos criptogrficos (como SSH) dependentes de horrio absoluto funcionem adequadamente. 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. Para garantir um horrio consistente, deve haver idealmente somente alguns servidores de horrio internos (centrais) dentro de uma entidade. Esses servidores recebem o UTC (Tempo Universal Coordenado) diretamente de servidores de horrio externos, conhecidos e confiveis, por meio de rdio especial, satlites de GPS ou outra fonte de rede externa e se emparelham para garantir que mantenham o horrio preciso. Outros sistemas recebem, ento, o horrio desses servidores. Se um indivduo mal-intencionado tiver entrado na rede, ele muitas vezes tentar mudar os carimbos de data e hora de suas aes dentro dos logs de auditoria para evitar a deteco da atividade. Um indivduo mal intencionado tambm pode tentar alterar diretamente o relgio de um componente do sistema para ocultar sua presena - por exemplo, alterando o relgio do sistema para um horrio mais cedo. Por estes motivos, importante que o horrio seja preciso em todos os sistemas e que os dados de horrio sejam protegidos contra acessos e alteraes no autorizados. Dados de horrio incluem os parmetros e os mtodos usados para definir o relgio de cada sistema. Mais informaes sobre NTP podem ser encontradas em www.ntp.org, inclusive informaes sobre horrio, padres de horrio e servidores.
10.5 Proteger as trilhas de auditoria para que no possam ser alteradas.
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.
Requisito
10.5.1 Limitar a exibio de trilhas de auditoria s pessoas que tm uma necessidade relacionada funo. 10.5.2 Proteger os arquivos de trilha de auditoria de modificaes no autorizadas. 10.5.3 Fazer imediatamente o back-up dos arquivos de trilha de auditoria em um servidor de registros centralizado ou mdias que sejam difceis de alterar. 10.5.4 Documentar registros quanto s tecnologias externas em um servidor de registros na LAN interna. 10.5.5 Usar softwares de monitoramento da integridade dos arquivos ou de deteco de alteraes nos registros para assegurar que os dados de registro existentes no possam ser alterados sem gerar alertas (embora os novos dados que estejam sendo adicionados no gerem um alerta).
Orientao
Uma proteo adequada dos logs de auditoria inclui forte controle de acesso (limitar o acesso aos logs baseado somente na necessidade de divulgao) e uso da segregao interna (para deixar os logs mais difceis de serem encontrados e modificados). Ao gravar os logs de tecnologias que usam recursos externos, como wireless, 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 sistemas de monitoramento da integridade do arquivo 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. Para arquivos de registro (que no mudam com frequncia), o que deve ser monitorado , por exemplo, quando um arquivo de log excludo, cresce rapidamente ou diminui significativamente, e quaisquer outras indicaes de que um indivduo mal-intencionado mexeu indevidamente no arquivo de log. Existem ferramentas de prateleira e de cdigo aberto disponveis para monitoramento da integridade do arquivo. 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. O processo de anlise do log no precisa ser manual. Especialmente para as entidades com um grande nmero de servidores, pense em usar ferramentas de coleta, anlise e alerta de log.
10.6 Analisar os registros de todos os componentes do sistema pelo menos diariamente. As anlises dos registros incluem aqueles servidores que desempenham funes de segurana como sistema de deteco de invases (IDS) e servidores de protocolo de autenticao, autorizao e inventrio (AAA) (por exemplo, RADIUS). Observao: As ferramentas de coleta, anlise e alerta dos registros podem ser usadas para estar em conformidade com o Requisito 10.6 10.7 Manter um histrico da trilha de auditoria por pelo menos um ano, com um mnimo de trs meses imediatamente disponvel para anlise (por exemplo, on-line, arquivado ou recupervel a partir do back-up).
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 tarjas de backup fora do local pode resultar em cronogramas mais longos para restaurar dados, executar anlises e identificar sistemas ou dados afetados.
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. Requisito
11.1 Teste para a presena de pontos de acesso sem fio e detectar pontos de acesso sem fio no autorizados trimestralmente. Observao: Mtodos que podem ser usados no processo incluem mas no se limitam a varreduras de rede sem fio, inspees fsicas/lgicas de componentes e de infraestrutura do sistema, controle de acesso rede (NAC) ou IDS/IPS sem fio. Qualquer mtodo usado deve ser suficiente para detectar e identificar qualquer dispositivo no autorizado.
Orientao
A implementao e/ou explorao da tecnologia wireless dentro de uma rede um dos caminhos mais comuns para usurios mal-intencionados obterem acesso rede e aos dados do titular do carto. Se um dispositivo wireless ou uma rede forem instalados sem o conhecimento da empresa, ele pode permitir que um transgressor 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. Em funo da facilidade com que o ponto de acesso wireless pode ser conectado a uma rede, da dificuldade em detectar sua presena e do risco cada vez maior apresentado por dispositivos wireless no autorizados, esses processos devem ser executados at quando existir uma poltica proibindo o uso da tecnologia wireless. O tamanho e a complexidade de um ambiente privado determinaro as ferramentas e os processos adequados a serem usados para fornecer garantia suficiente de que um ponto de acesso sem fio intruso no tenha sido instalado no ambiente. Por exemplo: No caso de um nico quiosque de revenda autnomo em um shopping, onde todos os componentes de comunicao esto contidos em estojos anti-adulterao e indicadores de adulterao, executando inspees fsicas detalhadas no prprio quiosque pode ser suficiente para fornecer garantias de 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, um call center, sala de servidor ou centro de dados), torna-se mais difcil executar uma inspeo fsica detalhada devido ao nmero de componentes do sistema e de pontos de rede onde um dispositivo de acesso sem fio intruso poderia ser instalado ou ocultado. 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. Solues de controle de acesso de rede (NAC) podem executar o gerenciamento de autenticao e configurao do dispositivo para evitar que sistemas no autorizados conectem-se rede, ou que dispositivos no autorizados conectem-se a sistemas autorizados na rede. Uma organizao deve ter, como parte de seu plano de resposta a incidentes, procedimentos documentados a serem seguidos no caso de ser detectado um ponto de acesso wireless no autorizado. Um IDS/IPS wireless deve ser configurado para gerar automaticamente um alerta, mas o plano tambm deve documentar procedimentos de resposta caso um dispositivo no autorizado seja
Requisito
11.2 Executar varreduras quanto s vulnerabilidades das redes internas e externas pelo menos trimestralmente e aps qualquer mudana significativa na rede (como instalaes de novos componentes do sistema, mudanas na topologia da rede, modificaes das normas do firewall, upgrades de produtos). Observao: No ser necessrio que quatro varreduras trimestrais aprovadas sejam concludas quanto conformidade inicial do PCI DSS se o avaliador verificar que 1) o resultado da varredura mais recente foi uma varredura aprovada, 2) a entidade contar com polticas e procedimentos documentados que requerem a sequncia de varreduras trimestrais e 3) as vulnerabilidades observadas nos resultados da varredura tenham sido corrigidas conforme mostrado em uma nova varredura. Nos anos seguintes aps a anlise inicial do PCI DSS, quatro varreduras trimestrais aprovadas devem ter ocorrido.
Orientao detectado durante uma varredura wireless manual.

Uma varredura de vulnerabilidade uma ferramenta automatizada executada em dispositivos de rede interna e externa e servidores, feita para expor possveis vulnerabilidades e identificar portas em redes que podem ser encontradas e exploradas por indivduos mal-intencionados. Quando esses pontos fracos so identificados, a entidade os corrige e repete a verificao para chegar se as vulnerabilidades foram mesmo corrigidas. No momento da avaliao inicial do PCI DSS pela entidade, possvel que quatro varreduras trimestrais ainda no tenham sido realizadas. Se o resultado da verificao mais recente atingir os critrios para aprovao e houver polticas e procedimentos para varreduras trimestrais futuras, o objetivo desse requisito estar atingido. Caso essas condies sejam atendidas, no necessrio postergar uma avaliao no local para este requisito em funo da falta de quatro varreduras.
Requisito
11.2.1 Realizar varreduras por vulnerabilidade interna trimestralmente.
Orientao
Um processo estabelecido para identificar vulnerabilidades em sistemas internos no CDE exigem que as varreduras de vulnerabilidade sejam conduzidas trimestralmente. Identificar e abordar 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 titular do carto. As vulnerabilidades que representam o maior risco ao ambiente (por exemplo, ranqueadas como "Alto" pelo Requisito 6.2) deve ser resolvida com a maior prioridade. Como redes internas podem ser constantemente alteradas durante o ano, possvel que uma entidade possa no ter limpado consistentemente as varreduras de vulnerabilidades internas. A inteno que a entidade tenha um programa robusto de gerenciamento de vulnerabilidade instalado para resolver vulnerabilidades observadas em um perodo de tempo razovel. No mnimo as vulnerabilidades "Alto" devem ser abordadas rapidamente. Varreduras de vulnerabilidade internas podem ser realizadas por profissionais internos, qualificados que sejam razoavelmente independentes dos componentes do sistema sendo varridos (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 um Fornecedor de Varreduras Aprovado (ASV) do PCI SSC, QSA ou outra firma especializada em varreduras de vulnerabilidade.
11.2.2 As varreduras trimestrais quanto s vulnerabilidades externas devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de Segurana de Dados do Setor de Cartes de Pagamento (PCI SSC). Observao: As varreduras trimestrais quanto s vulnerabilidades externas devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de Segurana de Dados do Setor de Cartes de Pagamento (PCI SSC). As varreduras realizadas aps as alteraes na rede devem ser desempenhadas pela equipe interna da empresa. 11.2.3 Realize varreduras internas e externas aps qualquer mudana significativa. Observao: As varreduras realizadas aps as alteraes devem ser desempenhadas pela equipe interna da empresa.
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. Exige-se que os ASVs sigam um conjunto de critrios de varredura e relatrios definidos pelo PCI SSC nos Procedimentos de varredura de segurana.
Varrer um ambiente depois de qualquer alterao significativa ter sido feita assegura que todas as alteraes foram completamente adequadas para que a segurana do ambiente no tenha sido comprometida como resultado da alterao. Pode no ser necessrio varrer o ambiente completo aps uma alterao. No entanto, todos os componentes afetados pela alterao precisaram ser varridos.
Requisito
11.3 Realizar testes de penetrao externos e internos pelo menos uma vez por ano e aps qualquer upgrade ou modificao significativa na infra-estrutura ou nos aplicativos (como um upgrade no sistema operacional, uma subrede adicionada ao ambiente ou um servidor da Web adicionado ao ambiente). Esses testes de penetrao devem incluir o seguinte: 11.3.1 Testes de penetrao na camada da rede 11.3.2 Testes de penetrao na camada do aplicativo.
Orientao
A inteno de um teste de penetrao estimular uma situao de ataque real com o objetivo de identificar at onde um transgressor 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 ataques. 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. Normalmente, executar uma varredura de vulnerabilidade um dos primeiros passos que um testador de penetrao realizar para formar uma estratgia de ataque, 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 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 deve utilizar 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 um novo ataque baseado nos recursos a que o servidor tem acesso. Dessa forma, o testador capaz de simular os mtodos utilizados por um transgressor para identificar qualquer rea de fraquezas potenciais no ambiente que precisa ser abordado.
Requisito
11.4 Usar sistemas de deteco de invaso e/ou sistemas de preveno contra invaso para monitorar todo o trfego no ambiente de dados do titular do carto e alertar as equipes sobre comprometimentos suspeitos. Manter todos os mecanismos de deteco e preveno contra invases, diretrizes e assinaturas atualizados.
Orientao
A deteco de intrusos e/ou preveno de sistemas (IDS/IPS) comparam o trfego que entra na rede com assinaturas conhecidas e/ou 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 por meio dessas ferramentas, os ataques (ou mau uso) de recursos de computador podem passar despercebidos em tempo real. Os alertas de segurana gerados por essas ferramentas devem ser monitorados, de forma que as tentativas de intruso possam ser interrompidas. Dispositivos IDS/IPS devem ser implementados de maneira a monitorar o trfego de entrada e sada no permetro do CDE, alm dos pontos crticos no CDE. Os pontos crticos no CDE podem incluir servidores de bancos de dados que armazenam dados dos titulares dos cartes, locais de armazenamento de chaves de criptografia, redes de processamento ou outros componentes delicados do sistema, de acordo com o que for determinado pelo ambiente de uma entidade e documentado em sua avaliao de riscos. Enquanto vrios dispositivos IDS/IPS so capazes de monitorar diversos pontos do CDE a partir de um nico dispositivoe, importante lembrar da exposio que pode ocorrer caso esse nico dispositivo falhe. Portanto, importante incorporar a redundncia adequada na infraestrutura IDS/IPS. Existem milhares de tipos de comprometimento, e vrios outros so descobertos diariamente. Assinaturas e mecanismos de varredura antigos em dispositivos IDS/IPS no oferecem a capacidade de identificar novas vulnerabilidades que podem levar a uma violao no detectada. Os fornecedores desses produtos oferecem atualizaes frequentes, inclusive dirias, que devem ser avaliadas e aplicadas regularmente.
Requisito
11.5 Implementar softwares de monitoramento da integridade dos arquivos para alertar as equipes quanto modificao no autorizada de arquivos crticos do sistema, arquivos de configurao ou arquivos de contedo; e configurar o software para realizar comparaes de arquivos crticos pelo menos semanalmente. Observao: Para fins de monitoramento da integridade dos arquivos, os arquivos crticos normalmente so aqueles que no so alterados com frequncia, mas sua modificao poderia indicar um comprometimento do sistema ou um risco de comprometimento. Normalmente, os produtos de monitoramento da integridade dos arquivos vm pr-configurados com arquivos crticos para o sistema operacional relacionado. Outros arquivos crticos, como aqueles para os aplicativos personalizados, devem ser avaliados e definidos pela entidade (ou seja, o comerciante ou prestador de servios).
Orientao
Os sistemas de monitoramento da integridade do arquivo (FIM) verificam as alteraes nos arquivos crticos e notificam quando essas alteraes so detectadas. Existem ferramentas de prateleira e de cdigo aberto disponveis para monitoramento da integridade do arquivo. Se no implementadas corretamente e se o resultado do FIM no for monitorado, um indivduo mal-intencionado pode alterar o contedo do arquivo de configurao, os programas do sistema operacional ou os executveis do aplicativo. Essas alteraes no autorizadas, se no detectadas, podem tornar os controles de segurana ineficazes e/ou resultar no roubo dos dados do titular do carto sem impacto perceptvel no processamento normal.
Orientao para o Requisito 12: Manter uma Poltica de Segurana de Informaes

Requisito 12: Manter uma poltica que aborde a segurana das informaes para todas as equipes.
Uma poltica de segurana slida determina o tom da segurana para toda a empresa e informa aos funcionrios o que esperado deles. Todos os funcionrios devem estar cientes da confidencialidade dos dados e de suas responsabilidades para proteg-los. Para as finalidades do Requisito 12, "funcionrio" refere-se a funcionrios que trabalham em perodo integral e meio-perodo, funcionrios e equipes temporrias, e prestadores de servios e consultores que "residem" no endereo da entidade ou tm acesso ao ambiente de dados do titular do carto. Requisito
12.1 Definir, publicar, manter e disseminar uma poltica de segurana que realize o seguinte: 12.1.1 Atende a todos os requisitos do PCI DSS.
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. 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. Uma avaliao de riscos permite a uma organizao identificar ameaas e as 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 permite organizao manter-se atualizada com as mudanas organizacionais e ameaas, tendncias e tecnologias em evoluo,
12.1.2 Inclui um processo anual que identifica ameaas e vulnerabilidades, e resulta em uma avaliao de risco formal. (Exemplos de metodologias de avaliao de risco incluem mas no so limitados a OCTAVE, ISO 27005 e NIST SP 800-30.)
12.1.3 Inclui uma anlise pelo menos uma vez por ano e atualizaes quando o ambiente modificado.
As ameaas de segurana e os mtodos de proteo evoluem rapidamente ao longo do ano. Sem atualizar a poltica de segurana para refletir essas alteraes, agora so abordadas novas medidas de proteo para lutar contra essas ameaas. Procedimentos dirios de segurana operacional agem como instrues de mesa para os trabalhadores usarem nas atividades dirias de manuteno e administrao do sistema. Os procedimentos de segurana operacional no documentados levam a trabalhadores que no esto cientes do escopo total de suas tarefas, processos que no podem ser repetidos com facilidade por novos trabalhadores e possveis falhas nesses processos que podem permitir que um indivduo mal-intencionado obtenha acesso a sistemas e recursos crticos.
12.2 Desenvolver procedimentos de segurana operacional diariamente que estejam em conformidade com os requisitos nessa especificao (por exemplo, procedimentos de manuteno da conta do usurio e procedimentos de anlise de registros).
Requisito
12.3 Desenvolver polticas de utilizao para tecnologias crticas voltadas aos funcionrios (por exemplo, tecnologias de acesso remoto, tecnologias sem fio, mdia eletrnica removvel, laptops, dados pessoais/assistentes digitais (PDAs), uso de e-mail e uso da Internet) para definir o uso adequado dessas tecnologias para todos os funcionrios e prestadores de servios. Assegurar que essas polticas de utilizao exijam o seguinte:
Orientao
As polticas de uso por funcionrios podem ou 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 no estiverem em vigor polticas de uso, os funcionrios podem usar as tecnologias na violao da poltica da empresa, permitindo que indivduos malintencionados consigam acesso a sistemas crticos e dados do titular do carto. Um exemplo pode ser configurar sem saber redes wireless sem segurana. Para garantir que os padres da empresa sejam seguidos e que somente as tecnologias aprovadas sejam implementadas, pense em confinar a implementao somente s equipes operacionais e no permitir que funcionrios no especializados/gerais instalem essas tecnologias. Sem exigir aprovao adequada da gesto 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 titular do carto. Os indivduos mal-intencionados podem violar a segurana fsica e colocar seus prprios dispositivos na rede como back door, 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 rotule e registre todos os dispositivos de forma coerente 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 back door para um indivduo mal-intencionado obter acesso a sistemas crticos e a dados do titular do carto. As tecnologias de acesso remoto so frequentes "back doors" a recursos crticos e a dados do titular do carto. Ao desconectar as tecnologias de acesso remoto quando no estiverem em uso (por exemplo, aquelas usadas para dar suporte aos sistemas pelo POS ou por outros fornecedores), o acesso e os riscos rede so minimizados. Pense em usar controles para desconectar dispositivos depois de 15 minutos de inatividade. Veja tambm o Requisito 8.5.6 para saber mais sobre
12.3.1 Explicitar a aprovao por partes autorizadas
12.3.2 Autenticao para o uso da tecnologia
12.3.3 Uma lista de todos esses dispositivos e equipes com acesso 12.3.4 Identificao dos dispositivos com proprietrio, informaes de contato e finalidade
12.3.5 Usos aceitveis da tecnologia 12.3.6 Locais de rede aceitveis quanto s tecnologias 12.3.7Lista dos produtos aprovados pela empresa 12.3.8 Desconexo automtica das sesses quanto s tecnologias de acesso remoto aps um perodo especfico de inatividade 12.3.9 Ativao de tecnologias de acesso remoto para fornecedores e parceiros de negcio somente quando lhes for
Requisito necessrio, com desativao imediata aps o uso

12.3.10 Para funcionrios que acessam os dados do titular do carto por meio de tecnologias de acesso remoto, proibir a cpia, a transferncia e o armazenamento dos dados do titular do carto em discos rgidos locais e mdias eletrnicas removveis, exceto se explicitamente autorizado para uma necessidade comercial definida. 12.4 Certificar-se de que a poltica e os procedimentos de segurana definem claramente as responsabilidades quanto segurana das informaes para todos os funcionrios. 12.5 Atribuir a um indivduo ou a uma equipe as seguintes responsabilidades de gerenciamento da segurana das informaes: 12.5.1 Definir, documentar e distribuir polticas e procedimentos de segurana. 12.5.2 Monitorar e analisar os alertas e as informaes de segurana, e distribuir para as equipes apropriadas. 12.5.3 Definir, documentar e distribuir procedimentos de resposta e escalao de incidentes de segurana para assegurar que todas as situaes sejam abordadas de modo oportuno e eficiente. 12.5.4 Administrar as contas dos usurios, incluindo adies, excluses e modificaes 12.5.5 Monitorar e controlar todos os acessos aos dados. 12.6Implementar um programa formal de conscientizao da segurana para conscientizar todos os funcionrios sobre a importncia da segurana dos dados do titular do carto.
Orientao
esse tpico. Para garantir que os funcionrios estejam cientes de suas responsabilidades de no armazenar nem copiar dados do titular do carto para o computador pessoal local ou outras mdias, sua empresa deve contar com uma poltica que proba claramente essas atividades. Any such authorized personnel are responsible for ensuring that cardholder data in their possession is handled in accordance with all PCI DSS requirements, as that remote personnels environment is now considered a part of the organizations cardholder data environment. Sem papis e responsabilidades claramente definidos e atribudos, 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 das informaes 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 titular 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.
Requisito
12.6.1 Instruir os funcionrios quando da contratao e pelo menos uma vez por ano. Observao: Os mtodos podem variar dependendo da funo de cada funcionrio e do nvel de acesso aos dados do titular do carto.
Orientao
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 titular do carto. O foco e a profundidade do treinamento inicial e de atualizao podem variar de acordo com a funo dos funcionrios e devem ser personalizados conforme necessrio para o pblico especfico. Por exemplo, sesses para administradores de bancos de dados podem concentrar-se em processos e controles tcnicos especficos, enquanto o treinamento para os caixas pode ser focado procedimentos seguros de transaes Considere incluir atualizaes constantes de conscientizao para manter os funcionrios atualizados com os procedimentos e as polticas atuais. O mtodo de instruo tambm deve variar de acordo com o pblico especfico ou o treinamento sendo apresentado. Por exemplo, o treinamento inicial e anual pode ser apresentado em uma sesso formal de treinamento prtico em um computador, enquanto as atualizaes peridicas podem ser apresentadas por email, postres, boletins informativos etc.
12.6.2 Exigir que os funcionrios reconheam, pelo menos uma vez por ano, que leram e compreenderam a poltica e os procedimentos de segurana da empresa. 12.7 Analise bem os potenciais funcionrios antes de contratar para minimizar o risco de ataques a partir de fontes internas. (Exemplos de verificaes da formao incluem o histrico do emprego anterior, ficha criminal, histrico de crdito e verificaes das referncias.) Observao: Para os funcionrios como caixas de loja que tm acesso somente a um nmero do carto por vez ao viabilizar uma transao, esse requisito apenas uma recomendao.
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 esperam ter acesso aos dados do titular do carto reduz o risco do uso no autorizado de PANs e outros dados do titular do carto por pessoas com histricos questionveis ou criminais. Espera-se que uma empresa tenha uma poltica e um processo para verificaes de histrico, incluindo o prprio processo de deciso para o qual os resultados da verificao do histrico tenham impacto sobre as decises de contratao (e qual seria esse impacto). Para ser eficaz, o nvel de verificao do histrico deve ser adequado ao cargo em particular. Por exemplo: os cargos que exijam maior responsabilidade ou que possuam acesso de administrador a dados ou sistemas importantes podero garantir verificaes de background mais detalhadas do que os cargos que exigirem menos responsabilidade e possurem nvel inferior de acesso. Tambm poder no ser adequado ao processo cobrir transferncias internas, em que as pessoas que ocuparem cargos de risco mais baixo e que ainda no tiverem passado por uma verificao de background detalhada so promovidas ou transferidas para cargos de maior responsabilidade ou nvel de acesso.
Requisito
12.8 Se os dados do titular do carto forem compartilhados com prestadores de servios, manter e implementar polticas e procedimentos para gerenciar os prestadores de servios, incluindo o seguinte: 12.8.1 Manter uma lista dos prestadores de servios. 12.8.2 Manter um acordo por escrito que inclua um reconhecimento de que os prestadores de servios so responsveis pela segurana dos dados do titular do carto que eles possurem. 12.8.3 Certificar-se de que haja um processo definido para a contratao dos prestadores de servios, incluindo uma diligncia devida adequada antes da contratao. 12.8.4 Manter um programa para monitorar o status de conformidade quanto ao PCI DSS dos prestadores de servios.
Orientao
Se o comerciante ou o prestador de servio compartilhar os dados do titular do carto com um prestador de servio, devem ser aplicados certos requisitos para garantir a proteo contnua desses dados por tais prestadores de servio. Rastrear todos os provedores de servio identifica quando possveis riscos se estenderem para fora da organizao. O reconhecimento dos prestadores de servio evidencia o compromisso deles com manter uma segurana adequada dos dados do titular do carto que so obtidos dos clientes e, assim, responsabiliza-os. 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. 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 apenas os servios que estiverem dentro do escopo da avaliao de PCI DSS do cliente. Por exemplo: se um provedor oferecer servios de firewall/IDS e ISP, um cliente que utilizar o servio de firewall/IDS incluir este servio apenas no escopo da avaliao de PCI DSS.
12.9 Implementar um plano de resposta a incidentes. Preparar-se para responder imediatamente a uma falha no sistema.
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.
Requisito
12.9.1 Criar o plano de resposta a incidentes para ser implementado no caso de violaes do sistema. Certificar-se de que o plano aborda o seguinte, pelo menos: Funes, responsabilidades e estratgias de comunicao e contato no caso de um comprometimento, incluindo a notifcao s bandeiras de pagamento, pelo menos Procedimentos de resposta especficos a incidentes Procedimentos de recuperao e continuidade dos negcios Processos de back-up dos dados Anlise dos requisitos legais visando ao relato dos comprometimentos Abrangncia e resposta de todos os componentes crticos do sistema Referncia ou incluso de procedimentos de resposta a incidentes por parte das bandeiras de pagamento 12.9.2 Testar o plano pelo menos uma vez por ano.
Orientao
O plano de resposta a incidentes deve ser completo e conter todos os elementoschave para permitir que sua empresa reaja com eficincia no caso de uma violao que possa causar impacto nos dados do titular do carto.
Sem testes adequados, etapas essenciais podem ser perdidas, o que poderia aumentar a exposio durante um incidente. Se ao longo do ltimo ano o plano de resposta incidental tiver sido inteiramente ativado, bastar uma reviso detalhada do incidente real e de sua resposta para que o teste seja adequado. Caso apenas alguns componentes do plano tenham sido ativados recentemente, os componentes restantes ainda precisaro ser testados. Caso nenhum componente do plano tenha sido ativado nos ltimos 12 meses, todos os componentes do plano devero ser testados.
12.9.3 Designar equipes especficas para estarem disponveis em tempo integral para responder aos alertas. 12.9.4Fornecer o treinamento adequado equipe que responsvel pela resposta s falhas do sistema. 12.9.5 Incluir alertas de sistemas de deteco de invaso, preveno contra invases e monitoramento da integridade dos arquivos. Desenvolver um processo para modificar e aprimorar o plano de resposta a incidentes, de acordo com as lies aprendidas e para incorporar os desenvolvimentos do setor.
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. Se no estiverem disponveis recursos internos, pense em contratar um fornecedor que os fornea. 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.
Orientao para o Requisito A.1: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada
Requisito A.1: Os provedores de hospedagem compartilhada protegem o ambiente de dados do titular do carto
Conforme mencionado no Requisito 12.8, todos os prestadores de servios com acesso aos dados do titular do carto (incluindo os provedores de hospedagem compartilhada) devem seguir o PCI DSS. Alm disso, o Requisito 2,4 afirma que os provedores de hospedagem compartilhada devem proteger o ambiente hospedado e os dados de cada entidade. Portanto, os provedores de hospedagem compartilhada tambm devem estar em conformidade com os requisitos nesse Apndice. Requisito
A.1 Proteja o ambiente hospedado e os dados de cada entidade (seja comerciante, prestador de servios ou outra entidade), de acordo com os itens A.1.1 a A.1.4: Um provedor de hospedagem deve atender a esses requisitos, assim como a todas as outras sees relevantes do PCI DSS. Observao: Embora um provedor de hospedagem possa atender a esses requisitos, a conformidade da entidade de que utiliza o provedor de hospedagem no assegurada. Cada entidade deve estar em conformidade com o PCI DSS e validar a conformidade, conforme aplicvel. A.1.1 Certificar-se de que cada entidade executa somente os processos que tm acesso ao ambiente de dados do titular do carto daquela entidade.
Orientao
O Anexo 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. Essas etapas devem ser cumpridas, alm de todos os outros requisitos relevantes do PCI DSS.
Se um comerciante ou prestador de servio puder executar seus aplicativos prprios no servidor compartilhado, eles devem ser executados com o ID de usurio do comerciante ou prestador de servio, e no como um usurio privilegiado. O usurio privilegiado pode ter acesso aos ambientes de dados do titular do carto de todos os outros comerciantes e prestadores de servio, alm dos seus prprios. 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 do titular do carto, considere o seguinte: (1) privilgios do ID de usurio do servidor da Web do comerciante ou do prestador de servio; (2) permisses concedidas para ler, gravar e executar arquivos; (3) permisses concedidas para gravar em binrios do sistema; (4) permisses concedidas aos arquivos de log do comerciante e do prestador de servio; e (5) controles para garantir que um comerciante ou prestador de servio no possa monopolizar os recursos do sistema. Os logs devem estar disponveis em um ambiente de hospedagem compartilhado, de forma que os comerciantes e prestadores de servio tenham acesso e
A.1.2 Restringir o acesso e os privilgios de cada entidade somente ao prprio ambiente de dados do titular do carto.
A.1.3 Certificar-se de que os registros e as trilhas de auditoria esto ativadas e so exclusivas para o ambiente de dados do titular do carto de cada
Requisito entidade, alm de estarem em conformidade com o Requisito 10 do PCI DSS.

A.1.4 Permitir que os processos providenciem uma investigao forense oportuna no caso de um comprometimento em qualquer comerciante ou prestador de servios hospedado.
Orientao
consigam analisar os logs especficos ao ambiente dos dados do titular do carto. 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.
Anexo A: Padro de segurana de dados do PCI: documentos relacionados

Os documentos a seguir foram criados para auxiliar comerciantes e prestadores de servio a entenderem o Padro de segurana de dados do PCI e as responsabilidades e requisitos de conformidade.
Documento Requisitos dos Padres de Segurana de Dados do PCI e Procedimentos de Avaliao da Segurana Navegando pelo PCI DSS: Conhea a inteno dos requisitos Padro de segurana de dados do PCI: Diretrizes e instrues do Questionrio de auto-avaliao Padro de segurana de dados do PCI: Questionrio A de autoavaliao e atestado Padro de segurana de dados do PCI: Questionrio B de autoavaliao e atestado Padro de segurana de dados do PCI: Questionrio C-VT de autoavaliao e atestado Padro de segurana de dados do PCI: Questionrio C de autoavaliao e atestado Padro de segurana de dados do PCI: Questionrio D de autoavaliao e atestado Glossrio de termos, abreviaes e acrnimos do PCI DSS e PA-DSS
Pblico Todos os comerciantes e prestadores de servio Todos os comerciantes e prestadores de servio Todos os comerciantes e prestadores de servio Comerciantes qualificados Comerciantes qualificados Comerciantes qualificados Comerciantes qualificados
9
Comerciantes e prestadores de servio qualificados Todos os comerciantes e prestadores de servio
Para determinar o Questionrio de auto-avaliao adequado, veja Padro de segurana de dados do PCI: Diretrizes e instrues do Questionrio de auto-avaliao, Selecionando o SAQ e certificado que melhor se aplicam sua organizao.

Navigating DSS v2 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Navigating DSS v2 PDF

Caricato da

Copyright:

Formati disponibili

Indstria de cartes de dbito (PCI - Payment Card Industry) Padro de segurana dos dados

Navegando pelo PCI DSS

Conhecer a inteno dos requisitos

Outubro de 2010 Pgina 2

Elementos dos dados do titular do carto e de autenticao confidenciais .................................................................6

Orientao para os Requisitos 3 e 4: Proteger os dados do titular do carto.............................................................20

Orientao para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades ........................30

Orientao para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas .............................40

Orientao para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente.................................................51

Orientao para o Requisito 12: Manter uma Poltica de Segurana de Informaes................................................61

Outubro de 2010 Pgina 3

Outubro de 2010 Pgina 4

Outubro de 2010 Pgina 5

Elementos dos dados do titular do carto e de autenticao confidenciais

Outubro de 2010 Pgina 6

Sim Sim Sim Sim No No No

Dados de autenticao confidenciais

Outubro de 2010 Pgina 7

Localizao dos dados do titular do carto e dos dados de autenticao confidenciais

Outubro de 2010 Pgina 8

Dados do rastro 1 vs. rastro 2

Outubro de 2010 Pgina 9

Orientao relacionada para o Padro de segurana de dados do PCI

Proteger os dados do titular do carto

Manter um programa de gerenciamento de vulnerabilidades

Implementar medidas de controle de acesso rigorosas

Monitorar e Testar as Redes Regularmente

Manter uma Poltica de Segurana de Informaes

Outubro de 2010 Pgina 10

Orientao para os Requisitos 1 e 2: Construa e mantenha uma rede segura

Outubro de 2010 Pgina 11

Outubro de 2010 Pgina 12

1.2.2 Proteger e sincronizar os arquivos de configurao do roteador.

Outubro de 2010 Pgina 13

Outubro de 2010 Pgina 14

Outubro de 2010 Pgina 15

Outubro de 2010 Pgina 16

Outubro de 2010 Pgina 17

Outubro de 2010 Pgina 18

Outubro de 2010 Pgina 19

Orientao para os Requisitos 3 e 4: Proteger os dados do titular do carto

Outubro de 2010 Pgina 20

Outubro de 2010 Pgina 21

3.2.3 No armazenar o PIN (personal identification number) ou o bloco de PIN criptografado.

Outubro de 2010 Pgina 22

Outubro de 2010 Pgina 23

Criptografia robusta com processos e procedimentos de gerenciamento de chaves associados

Outubro de 2010 Pgina 24

3.6.2 Distribuio segura da chave criptogrfica

3.6.3 Armazenamento seguro de chaves criptogrficas

Outubro de 2010 Pgina 25

Outubro de 2010 Pgina 26

Outubro de 2010 Pgina 27

Outubro de 2010 Pgina 28

Outubro de 2010 Pgina 29

Orientao para os Requisitos 5 e 6: Manter um programa de gerenciamento de vulnerabilidades

Outubro de 2010 Pgina 30

Orientao atualizar os padres e processos de configurao de acordo.

Outubro de 2010 Pgina 31

Requisito 6: Desenvolver e manter sistemas e aplicativos seguros

Outubro de 2010 Pgina 32

Outubro de 2010 Pgina 33

6.4.2 Separao dos deveres entre os ambientes de desenvolvimento/teste e de produo