Indústria de cartões de débito (PCI - Payment Card ... · O ambiente de dados do titular do cartão compreende pessoas, processos e tecnologia que lidam com os dados do titular

Indústria de cartões de débito (PCI - Payment Card Industry) Padrão de segurança dos dados

Navegando pelo PCI DSS

Conhecer a intenção dos requisitos Versão 2.0

Outubro de 2010

Navegando pelo PCI DSS: Conhecer a inteção dos requisitos, v2.0 Outubro de 2010 Copyright 2010 Conselho de Padrões de Segurança LLC do PCI Página 2

Alterações no documento Data Version Description

1 de outubro de 2008

1.2 Alinhar o conteúdo com o novo PCI DSS v1.2 e implementar pequenas alterações observadas desde o original v1.1.

28 de outubro de 2010

2.0 Alinhar o conteúdo com o novo PCI DSS v2.0.


Índice

Alterações no documento ............................ ......................................................................................................................2

Prefácio ........................................... .....................................................................................................................................4 Virtualização ............................................................................................................................................................................................................ 5

Elementos dos dados do titular do cartão e de auten ticação confidenciais .............................. ...................................6 Localização dos dados do titular do cartão e dos dados de autenticação confidenciais........................................................................................ 8 Dados do rastro 1 vs. rastro 2 ................................................................................................................................................................................. 9

Orientação relacionada para o Padrão de segurança d e dados do PCI..................................... ..................................10

Orientação para os Requisitos 1 e 2: Construa e man tenha uma rede segura .............................. .............................11 Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão ........................................................... 11 Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança ......................... 17

Orientação para os Requisitos 3 e 4: Proteger os da dos do titular do cartão........................... ..................................20 Requisito 3: Proteger os dados armazenados do titular do cartão ....................................................................................................................... 20 Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas................................................................. 28

Orientação para os Requisitos 5 e 6: Manter um prog rama de gerenciamento de vulnerabilidades.......... ..............30 Requisito 5: Usar e atualizar regularmente o software ou programas antivírus ................................................................................................... 30 Requisito 6: Desenvolver e manter sistemas e aplicativos seguros ..................................................................................................................... 32

Orientação 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 cartão de acordo com a necessidade de conhecimento para o negócio .................... 40 Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador ................................................................. 42 Requisito 9: Restringir o acesso físico aos dados do titular do cartão.................................................................................................................. 47

Orientação para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente....................... ..........................51 Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão ........................ 51 Requisito 11: Testar regularmente os sistemas e processos de segurança ........................................................................................................ 55

Orientação para o Requisito 12: Manter uma Política de Segurança de Informações....................... .........................61 Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes. ............................................................... 61

Orientação para o Requisito A.1: Requisitos adicion ais do PCI DSS para provedores de hospedagem compartilhada...................................... ............. .................................................................................................................67

Anexo A: Padrão de segurança de dados do PCI: documentos rel acionados.......................................... ..............69


Prefácio

Este documento descreve os 12 requisitos do Padrão de segurança de dados do Setor de cartões de pagamento (PCI DSS), junto com uma orientação para explicar o propósito de cada um deles. A finalidade deste documento é auxiliar comerciantes, prestadores de serviço e instituições financeiras que desejem conhecer mais a respeito do padrão de segurança de dados do setor de cartões de débito, bem como o significado específico e as intenções por trás dos requisitos detalhados para proteger os componentes do sistema (servidores, rede, aplicativos, etc). compatíveis com os ambientes de dados do titular do cartão.

OBSERVAÇÃO: Navegando pelo PCI DSS: Conhecer a intenção dos req uerimentos servirá apenas como orientação. Ao preencher uma avaliação on-site do PCI DSS ou um questionário de auto-avaliação (SAQ - Self Assessment Questionnaire ), os Requisitos do PCI DSS dos Padrões de Segurança de Dados e os Questionários de auto-avaliação do PCI DSS 2.0 serão os documentos de registro.

Os requisitos de segurança do PCI DSS se aplicam a todos os componentes do sistema. No contexto do PCI DSS, os "componentes do sistema" são definidos como qualquer componente de rede, servidor ou aplicativo que esteja incluído ou vinculado ao ambiente de dados do titular do cartão. Os componentes do sistema incluem também qualquer componente de virtualização, como máquinas virtuais, roteadores e comutadores virtuais, ferramentas virtuais, aplicativos e desktops virtuais e hipervisores. O ambiente de dados do titular do cartão compreende pessoas, processos e tecnologia que lidam com os dados do titular do cartão ou dados de autenticação confidenciais.

� Os componentes de rede podem incluir, mas não de forma exclusiva, firewalls, chaves, roteadores, pontos de acesso wireless, mecanismos de rede e outros mecanismos de segurança.

� Os tipos de servidor incluem, mas não se limitam a: web, aplicativo, banco de dados, autenticação, 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 avaliação do PCI DSS é determinar precisamente o escopo da revisão. Ao menos anualmente e antes da avaliação anual, a entidade deve confirmar a precisão de seu escopo do PCI DSS ao identificar todos os locais e fluxos de dados do titular do cartão e assegurar que estejam incluídos no escopo do PCI DSS. Para confirmar a precisão e a adequação do escopo do PCI DSS, execute o seguinte:

� A entidade avaliada identifica e documenta a existência de todos os dados do titular do cartão em seu ambiente, para verificar que nenhum dado de titular do cartão existe fora do ambiente de dados do titular do cartão definido no momento (CDE).

� Assim que todos os locais dos dados do titular do cartão 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 inventário de locais de dados do titular de cartão).

� A entidade considera que qualquer dado do titular do cartão esteja no escopo da avaliação do PCI DSS e parte do CDE, a não ser que tal dado seja excluído ou migrado/consolidado no CDE definido atualmente.

� A entidade retém a documentação que mostra como o escopo do PCI DSS foi confirmado e os resultados, para a revisão da assessoria e/ou para referência durante a próxima atividade anual de confirmação do escopo do PCI SCC.


A segmentação da rede ou o isolamento (separação) do ambiente de dados do titular do cartão do restante da rede corporativa não é um requisito do PCI DSS. Entretanto, é altamente recomendável como um método que reduzirá o escopo do ambiente de dados do titular do cartão. Um Assessor de Segurança Qualificado (QSA) pode auxiliar na determinação do escopo dentro do ambiente dos dados do titular do cartão, junto com orientação sobre como estreitar o escopo de uma avaliação do PCI DSS ao implementar uma segmentação de rede adequada.

Se houver dúvidas quanto à consonância de uma determinada implantação em relação ao padrão ou a um requerimento específico, o PCI SSC recomenda às empresas que consultem o QSA para validar a implantação da tecnologia e dos processos e atender ao padrão de segurança de dados do PCI. A experiência dos QSAs em trabalhar com ambientes de rede complexos é boa para proporcionar melhores práticas e orientação ao comerciante ou prestador de serviços na tentativa de conquistar conformidade. A lista dos assessores de segurança qualificados do PCI SSC poderá ser encontrada em: https://www.pcisecuritystandards.org.

Virtualização

Se uma virtualização for implantada, todos os componentes que estiverem no ambiente virtual deverão ser identificados e considerados dentro do escopo para a revisão, incluindo os hosts individuais virtuais ou dispositivos, máquinas visitantes, aplicativos, interfaces de gerenciamento, consoles de gerenciamento centrais, hipervisores, etc. Todas as comunicações e fluxos de dados trocados entre os hosts deverão ser identificados e documentados, bem como aqueles trocados entre o componente virtual e os componentes do sistema.

A implantação de um ambiente virtualizado deverá atender às inteções de todos os requerimentos de forma que os sistemas virtualizados possam de fato ser considerados hardwares separados. Por exemplo: deverá haver uma segmentação clara das funções e segregação de redes com níveis de segurança diferentes. A segmentação deverá evitar o compartilhamento dos ambientes de produção e de teste e desenvolvimento. A configuração virtual deverá ser protegida de forma que as vulnerabilidades em uma função não interfiram na segurança de outras. E dispositivos como USB ou em série não possam ser acessados por todas as instâncias virtuais.

Além disso, todos os protocolos de interface de gerenciamento virtuais deverão ser incluídos na documentação do sistema, e deverão ser definidas funções e permissões para gerenciamento das redes virtuais e dos componentes virtuais do sistema. As plataformas de virtualização deverão ter a capacidade de aplicar a separação de tarefas e de privilégios menores, de forma a separar o gerenciamento de rede virtual do gerenciamento de servidor virtual.

Deve-se ter atenção especial ao implantar os controles de autenticação, de forma a garantir que a autenticação dos usuários seja realizada nos componentes de sistema virtual adequados e que haja distinção entre as máquinas virtuais (VMs - virtual machines) do visitante e o hipervisor.


Elementos dos dados do titular do cartão e de auten ticação 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 cartão mais Dados de autenticação confidenciais, como segue:

Os Dados do titular do cartão incluem: Os Dados de autenticação confidenciais incluem:

• O número da conta principal (PAN) • O nome do titular do cartão • Data de vencimento • Código de serviço

• Dados em tarja magnética ou equivalentes em chip

• CAV2/CVC2/CVV2/CID • PINs/Bloqueios de PIN

O número da conta principal é o fator decisivo na a plicabilidade dos requisitos do PCI DSS. Os requisitos do PCI DSS são aplicáveis se um número de conta principal (PAN) for armazenado, processado ou transmitido. Caso o PAN não seja armazenado, processado ou transmitido, não serão aplicados os requisitos do sistema.

Se o nome, código de serviço e/ou data de validade de um titular do cartão são armazenados processados ou transmitidos com o PAN ou, de outro modo, estão presentes no ambiente de dados do titular do cartão, 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 mínimo de objetivos de controle que podem ser aperfeiçoados por leis e normas locais, regionais e do setor. Além disso, os requisitos legais ou regulatórios podem exigir proteção específica de informações pessoalmente identificáveis ou outros elementos de dados (por exemplo, o nome do titular do cartão) ou definir práticas de divulgação de uma entidade ligadas a informações de clientes. Os exemplos incluem a legislação relacionada à proteção de dados de clientes, privacidade, roubo de identidade ou segurança de dados. O PCI DSS não substitui leis locais ou regionais, regulamentos do governo ou outros requisitos legais.

A tabela a seguir ilustra os elementos comumente usados do titular do cartão e dados de autenticação confidenciais; se o armazenamento de cada elemento de dados é permitido ou proibido; e se cada elemento de dados deve ser protegido. Esta tabela não tem a intenção de ser completa, mas é apresentada para ilustrar o tipo diferente de requisito que aplica-se a cada elemento de dados;


Elemento de dados

Armazenamento permitido

Converte dados de conta armazenados ilegíveis pelo

Requisito 3.4

O número da conta principal (PAN)

Sim Sim

O nome do titular do cartão Sim Não

Código de serviço Sim Não

Dados do titular do

cartão

Data de vencimento Sim Não

Dados completos da tarja magnética 2

Não Não armazenável pelo

Requisito 3.2

CAV2/CVC2/CVV2/CID Não Não armazenável pelo

Requisito 3.2

Dad

os d

a co

nta

Dados de autenticação confidenciais

1 PIN/Bloco de PIN Não

Não armazenável pelo Requisito 3.2

Os Requisitos 3.3 e 3.4 do PCI DSS aplicam-se apenas ao PAN. Se o PAN for armazenado com outros elementos dos dados do titular do cartão, somente o PAN deverá ser convertido como ilegível de acordo com o Requisito 3.4 do PCI DSS.

O PCI DSS se aplica somente se os PANs são armazenados, processados e/ ou transmitidos.

1 Dados de autenticação confidenciais não devem ser armazenados após a autorização (mesmo se forem criptografados). 2 Dados completos de rastreamento da tarja magnética, dados equivalentes no chip, ou em outro lugar.


Localização dos dados do titular do cartão e dos da dos de autenticação confidenciais Os dados confidenciais de autenticação consistem em dados de tarja magnética (ou trilha)3, código de validação do cartão ou valor4, e dados de PIN5. O armazenamento de dados de autenticação confidenci ais é proibido! Esses dados são muito valiosos para indivíduos mal-intencionados, pois permitem gerar cartões de pagamento falsos e criar transações fraudulentas. Consulte o Glossário de termos, abreviações e acrônimos utilizados no PCI DSS e no PA-DSS para obter a definição completa dos "dados confidenciais de autenticação". As imagens da frente e do verso do cartão exibidas a seguir mostram o local dos dados do titular do cartão e dos dados confidenciais de autenticação.

Observação: O chip contém dados de trilha equivalentes, bem como outros dados confidenciais, incluindo o valor de verificação de chip de circuito integrado (IC - integrated circuit), também chamado de CVC, iCVV, CAV3 ou iCSC do chip.

3 Dados codificados na tarja magnética utilizados para autorização durante a transação com o cartão. Estes dados também poderão ser encontrados em um chip ou em outra parte

do cartão. As entidades não podem reter esses dados após a autorização da transação. Os únicos elementos dos dados da tarja que podem ser retidos são o número da conta principal, o nome do titular do cartão, a data de vencimento e o código de serviço.

4 O valor de três ou quatro dígitos impresso à direita do painel de assinatura ou na frente do cartão de pagamento usado para verificar transações com cartão não presente. 5 Número de Identificação Pessoal inserido pelo titular do cartão durante uma transação com o cartão e/ou bloqueio de PIN criptografado dentro da mensagem da transação.


Dados do rastro 1 vs. rastro 2

Se os dados completos de uma tarja (seja Rastro 1 ou Rastro 2, da tarja magnética, imagem da tarja magnética no chip ou outro local) forem armazenados, indivíduos mal-intencionados que obterem esses dados poderão reproduzir e vender cartões de pagamento no mundo inteiro. O armazenamento de dados completos da tarja também viola as regras operacionais das bandeiras, podendo ocasionar multas e penalidades. A ilustração abaixo fornece informações sobre os dados das Tarjas 1 e 2, descrevendo as diferenças e mostrando o layout dos dados conforme eles são armazenados na tarja magnética.

Rastro 1 Rastro 2

� Contém todos os campos do rastro 1 e do rastro 2

� Comprimento de até 79 caracteres

� Tempo de processamento menor para transmissões discadas mais antigas

� Comprimento de até 40 caracteres

Observação : Os campos de dados opcionais são definidos pelo emissor do cartão pela marca do cartão de débito. Os campos definidos pelo emissor que contêm dados que o emissor ou a bandeira do cartão de débito não consideram como dados confidenciais de autenticação poderão ser incluídos na porção de dados opcionais da tarja, e terão permissão para armazenar estes dados específicos em situações e condições específicas da forma definida pelo emissor ou pela bandeira do cartão de débito.

Entretanto, todos os dados considerados confidenciais de autenticação, contidos ou não em um campo de dados opcionais, não deverão ser armazenados após a autorização.


Orientação relacionada para o Padrão de segurança d e dados do PCI

Construa e mantenha uma rede segura

Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão

Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmetros de segurança

Proteger os dados do titular do cartão

Requisito 3: Proteger os dados armazenados do titular do cartão

Requisito 4: Criptografar a transmissão dos dados do titular do cartão em redes abertas e públicas

Manter um programa de gerenciamento de vulnerabilid ades

Requisito 5: Usar e atualizar regularmente o software ou programas antivírus

Requisito 6: Desenvolver e manter sistemas e aplicativos seguros

Implementar medidas de controle de acesso rigorosas

Requisito 7: Restringir o acesso aos dados do titular do cartão de acordo com a necessidade de divulgação dos negócios

Requisito 8: Atribuir uma identidade exclusiva para cada pessoa que tenha acesso ao computador

Requisito 9: Restringir o acesso físico aos dados do titular do cartão

Monitorar e Testar as Redes Regularmente

Requisito 10: Acompanhar e monitorar todos os acessos com relação aos recursos da rede e aos dados do titular do cartão

Requisito 11: Testar regularmente os sistemas e processos de segurança

Manter uma Política de Segurança de Informações

Requisito 12: Manter uma política que aborde a segurança das informações para todas as equipes.


Orientação para os Requisitos 1 e 2: Construa e man tenha uma rede segura

Requisito 1: Instalar e manter uma configuração de firewall para proteger os dados do titular do cartã o

Firewalls são dispositivos do computador que controlam o tráfego do computador permitido entre a rede de uma empresa (interna) e redes não confiáveis (externa), assim como o tráfego dentro e fora de muitas áreas confidenciais na rede confiável interna de uma empresa. O ambiente de dados do titular do cartão é um exemplo de uma área mais sensível dentro da rede confiável de uma empresa.

Um firewall examina todo o tráfego da rede e bloqueia aquelas transmissões que não atendem aos critérios de segurança específicos.

Todos os sistemas devem ser protegidos do acesso não autorizado de redes não confiáveis, seja acessando o sistema por meio da Internet como e-commerce, acesso à Internet através dos navegadores na área de trabalho por parte dos funcionários, acesso via e-mail dos funcionários, conexão dedicada como conexões entre negócios, por meio de redes sem fio ou de outras fontes. Com freqüência, trajetos aparentemente insignificantes que direcionam ou partem de redes não confiáveis podem fornecer caminhos não protegidos aos sistemas principais. Os firewalls são um mecanismo de proteção essencial para qualquer rede de computador.

Outros componentes do sistema podem oferecer a funcionalidade de filirena, contanto que atendam aos requisitos mínimos para firewalls, conforme o Requisito 1. Onde outros componentes do sistema forem usados no ambiente dos dados do titular do cartão para oferecer a funcionalidade do firewall, esses dispositivos deverão ser incluídos no escopo e na avaliação do Requisito 1.

Requisito Orientação

1.1 Definir os padrões de configuração do firewall e do roteador que incluam o seguinte:

Firewalls e roteadores são os principais componentes da arquitetura que controlam a entrada e a saída da rede. Esses dispositivos são software ou hardware que bloqueiam acesso indesejado e gerenciam acesso autorizado de e para a rede. Sem políticas e procedimentos para documentar como a equipe deve configurar firewalls e roteadores, fica fácil uma empresa perder sua primeira linha de defesa na proteção de dados. As políticas e os procedimentos ajudarão a garantir que a primeira linha de defesa da organização na proteção de seus dados continue forte.

Os ambientes virtuais onde os fluxos de dados não transitarem por uma rede física deverão ser avaliados de forma a garantir que se obtenha a segmentação da rede.

1.1.1 Um processo formal para aprovar e testar todas as conexões de rede e alterações às configurações do firewall e do roteador

Uma política e um processo para aprovar e testar todas as conexões e alterações nos firewalls e roteadores ajudará a evitar problemas de segurança causados pela má configuração da rede, do roteador ou do firewall.

Os fluxos de dados entre máquinas virtuais deverão ser incluídos nas políticas e processos.



1.1.2 Diagrama da rede atual com todas as conexões com relação aos dados do titular do cartão, incluindo quaisquer redes sem fio

Os diagramas de rede permitem que a organização identifique o local de todos os dispositivos de rede. Além disso, o diagrama de rede pode ser usado para mapear o fluxo de dados dos dados do titular do cartão por toda a rede e entre cada dispositivo, a fim de entender totalmente o escopo do ambiente dos dados do titular do cartão. Sem os diagramas da rede atual e do fluxo de dados, os dispositivos com dados do titular do cartão podem ser ignorados e sem querer deixados de fora dos controles de segurança em camadas implementados para PCI DSS e, assim, vulneráveis ao comprometimento.

Os diagramas de rede e fluxo de dados deverão incluir componentes do sistema virtual e fluxos de dados trocados entre os hosts.

1.1.3 Requisitos para um firewall em cada conexão da Internet e entre qualquer zona desmilitarizada (DMZ) e a zona da rede interna

Usar um firewall e todas as conexões que entram e saem da rede permite que a organização monitore e controle a entrada e saída de acesso, e minimize as chances de um indivíduo mal-intencionado de obter acesso à rede interna.

1.1.4Descrição de grupos, funções e responsabilidades quanto ao gerenciamento lógico dos componentes da rede

Essa descrição de funções e a atribuição da responsabilidade garante que alguém seja claramente responsável pela segurança de todos os componentes e esteja ciente da responsabilidade, e também que nenhum dispositivo fique sem gerenciamento.

1.1.5 Documentação e justificativa comercial para o uso de todos os serviços, protocolos e portas permitidas, incluindo a documentação dos recursos de segurança implementados para os protocolos considerados inseguros.

Exemplos de serviços, protocolos ou portas inseguros incluem mas não são limitados a FTP, Telnet, POP3, IMAP e SNMP.

Muitas vezes ocorrem comprometimentos decorrentes de serviços e portas não utilizados ou inseguros, visto que é freqüente eles possuírem vulnerabilidades conhecidas – e muitas organizações estão vulneráveis a esses tipos de comprometimentos, pois não aplicam patches nas vulnerabilidades de segurança para serviços, protocolos e portas que não utilizam (ainda que as vulnerabilidades ainda estejam presentes). Cada organização deve decidir claramente quais serviços, protocolos e portas são necessários para seus negócios, documentá-los nos registros e garantir que todos os outros serviços, protocolos e portas sejam desabilitados ou removidos. Além disso, as organizações devem pensar em bloquear todo o tráfego e somente reabrir essas portas depois de ser determinada e documentada uma necessidade.

Além disso, existem muitos serviços, protocolos ou portas de que uma empresa pode precisar (ou estarem ativados por padrão) que normalmente sejam usados por indivíduos mal-intencionados para comprometer uma rede. Se esses serviços, protocolos e portas inseguros forem necessários para a empresa, o risco apresentado pelo uso desses protocolos deve ser claramente entendido e aceito pela organização, o uso do protocolo deve ser justificado e os recursos de segurança que permitem que esses protocolos sejam usados com segurança deverão ser documentados e implementados. Se esses serviços, protocolos ou portas inseguros não forem necessários para a empresa, eles deverão ser desativados ou removidos.



1.1.6 Requisito para analisar os conjuntos de regras do firewall e do roteador pelo menos a cada seis meses

Essa análise dá à organização a oportunidade de, pelo menos a cada seis meses, limpar todas as regras desnecessárias, obsoletas ou incorretas, e garantir que todos os conjuntos de regras só permitam que serviços e portas não autorizados correspondam às justificativas de negócios.

É aconselhável fazer essas análises com mais freqüência, como mensalmente, para garantir que os conjuntos de regras estejam atualizados e correspondam às necessidades da empresa, sem abrir furos na segurança e correr riscos desnecessários.

1.2 Elaborar uma configuração de firewall e do roteador que restrinja as conexões entre redes não confiáveis e quaisquer componentes do sistema no ambiente de dados do titular do cartão.

Observação: Uma “rede não confiável” é qualquer rede que seja externa às redes que pertencem à entidade em análise e/ou que esteja além da capacidade da entidade de controlar ou gerenciar.

É essencial instalar a proteção de rede, principalmente um componente do sistema com (pelo menos) a função de firewall de inspeção com status, entre a rede interna confiável e outra rede não confiável externa ou que esteja fora do poder de controle e administração da empresa. A não-implementação dessa medida corretamente significa que a entidade estará vulnerável ao acesso não autorizado de indivíduos ou softwares mal-intencionados.

Se o firewall estiver instalado, mas não tiver regras que controlam ou limitam determinado tráfego, indivíduos mal-intencionados ainda poderão explorar os protocolos e portas vulneráveis para atacar sua rede.

1.2.1 Restringir o tráfego de entrada e saída para aquele que é necessário para o ambiente de dados do titular do cartão.

Esse requisito destina-se a evitar que indivíduos mal-intencionados acessem a rede da empresa por meio de endereços IP não autorizados ou usem serviços, protocolos ou portas de forma não autorizada (por exemplo, enviando dados obtidos dentro da sua rede para um servidor não confiável).

Todos os firewalls devem incluir uma regra que negue todo tráfego de entrada e saída não especificamente necessário. Isso evita o surgimento de buracos inadvertidos que permitam a entrada ou saída de outros tráfegos indesejados e potencialmente prejudiciais.

1.2.2 Proteger e sincronizar os arquivos de configuração do roteador.

Apesar de os arquivos de configuração de execução normalmente serem implementados com configurações seguras, os arquivos de inicialização (os roteadores só executam esses arquivos na reinicialização) podem não ser implementados com as mesmas configurações seguras, pois eles só são executados ocasionalmente. Quando o roteador for reinicializado sem as mesmas configurações seguras que as dos arquivos de configuração de execução, o resultado pode ser regras mais fracas que permitam que indivíduos mal-intencionados entrem na rede, pois os arquivos de inicialização podem não ter sido implementados com as mesmas configurações de segurança que os arquivos de configuração de execução.



1.2.3 Instalar firewalls de perímetro entre quaisquer redes sem fio e o ambiente de dados do titular do cartão, e configurar esses firewalls para recusar ou controlar (se esse tráfego for necessário para fins comerciais) qualquer tráfego a partir do ambiente sem fio no ambiente de dados do titular do cartão.

A implementação conhecida (ou desconhecida) e a exploração da tecnologia wireless dentro de uma rede é um caminho comum para indivíduos mal-intencionados ganharem acesso à rede e aos dados do titular do cartão. Se um dispositivo wireless ou uma rede forem instalados sem o conhecimento da empresa, um indivíduo mal-intencionado pode fácil e “invisivelmente” entrar na rede. Se os firewalls não restringirem o acesso das redes wireless no ambiente do cartão de pagamento, indivíduos mal-intencionados que tiverem acesso não autorizado à rede wireless poderão se conectar facilmente ao ambiente do cartão de pagamento e comprometer as informações da conta.

Deverão 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 público direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do cartão.

O objetivo do firewall é gerenciar e controlar todas as conexões entre os sistemas públicos e os internos (especialmente aqueles que armazenam os dados do titular do cartão). Se for permitido o acesso direto entre sistemas públicos e aqueles que armazenam os dados do titular do cartão, as proteções oferecidas pelo firewall serão ignoradas e os componentes do sistema que armazenam os dados do titular do cartão poderão ser comprometidos.

1.3.1 Implemente uma DMZ para limitar o tráfego somente para componentes do sistema que oferece serviços, protocolos e portas acessíveis publicamente.

O DMZ é a parte da rede responsável pelo gerenciamento das conexões entre a Internet (ou redes não confiáveis) e os serviços internos de que a empresa precisa disponibilizar para o público (como servidor web). Essa é a primeira linha de defesa ao isolar e separar o tráfego que precisa se comunicar com a rede interna daquele que não precisa.

Este recurso será utilizado para evitar que indivíduos mal-intencionados acessem a rede da empresa através de endereços de IP não autorizados ou por meio de serviços, protocolos ou portas de forma não autorizada.

1.3.2 Limitar o tráfego de entrada da Internet a endereços IP na DMZ.

A interrupção das conexões de IP oferecem uma oportunidade para inspeção e restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis.

1.3.3Não permitir a entrada ou saída de nenhuma rota direta com relação ao tráfego entre a Internet e o ambiente de dados do titular do cartão.

A interrupção das conexões de IP oferecem uma oportunidade para inspeção e restrição de fontes/destinos, ou inspeção/bloqueio do contúdo, evitando assim o acesso não filtrado entre pessoas não confiáveis e ambientes confiáveis. Isto ajudará a evitar, por exemplo, que indivídos mal-intencionados enviem dados obtidos na rede para um servidor externo não confiável em uma rede não confiável



1.3.4 Não permitir que endereços internos sejam transmitidos via Internet na DMZ.

Normalmente um pacote contém os endereços de IP do computador que originalmente o enviou, permitindo que os outros computadores da rede saibam de onde ele vem. Em certos casos, esse endereço de IP de envio sofrerá spoofing por indivíduos mal-intencionados.

Por exemplo: indivíduos mal-intencionados enviam um pacote com um endereço spoof, para que (a menos que seu firewall proíba) o pacote consiga entrar na sua rede pela Internet, parecendo que se trata de um tráfego interno e, portanto, legítimo. Quando o indivíduo mal-intencionado estiver dentro da sua rede, ele poderá começar a comprometer seus sistemas.

A filtragem ingressa é uma técnica que você pode usar no seu firewall para filtrar pacotes que entram na sua rede, como, entre outras coisas, garantindo que os pacotes não sofram spoofing, parecendo que vêm de sua própria rede interna.

Para obter mais informações sobre a filtragem de pacotes, pense em obter informações sobre uma técnica complementar chamada “filtragem egressa”.

1.3.5Não permitir o tráfego de saída não autorizado do ambiente de dados do titular do cartão para a Internet.

Todo tráfego que sair do ambiente de dados do titular do cartão deverá ser avaliado para garantir que o tráfego de saída esteja de acordo com as regras autorizadas preestabelecidas. As conexões deverão ser inspecionadas para retringir o tráfego de forma a permitir apenas as comunicações autorizadas (por exemplo restringindo portas/endereços de origem/destino ou bloqueando o conteúdo).

Onde não forem permitidas conexões de entrada, as conexões de saída poderão ser alcançadas através de arquiteturas ou componentes de sistema que interrompam e inspecionem a conexão de IP.

1.3.6 Implementar inspeção com status, também conhecida como filtragem de pacote dinâmico. (Ou seja, somente conexões "estabelecidas" são permitidas na rede.)

Um firewall que executa inspeção de pacotes com status mantém o “status” (ou estado) de cada conexão para o firewall. Ao manter o "status”, o firewall sabe se o que parece ser uma resposta a uma conexão anterior é de fato uma resposta (visto que isso “lembra” a conexão anterior) ou se trata-se de um indivíduo ou software mal-intencionado tentando fazer spoofing ou enganar o firewall para permitir a conexão.

1.3.7 Implementar os componentes do sistema que armazenam dados do titular do cartão (como banco de dados) em uma zona da rede interna, separada da DMZ e de outras redes não confiáveis.

Os dados do titular do cartão exigem o mais alto nível de proteção de informações. Se os dados do titular do cartão estiverem localizados dentro da DMZ, o acesso a essas informações será mais fácil para um atacante externo, pois há poucas camadas a serem penetradas.

Observação: a intenção deste requisito não inclui armazenamento em memória volátil.



1.3.8 Não divulgar endereços de IP privados e informações de roteamento a partes não autorizadas.

Observação : Métodos para camuflar o endereço de IP podem incluir, mas não se limitam a:

� Network Address Translation (NAT)

� Implementação de servidores contendo dados do titular do cartão atrás dos servidores de proxy/firewalls ou caches de conteúdo,

� Remoção ou filtragem das propagandas de rota para redes privadas que empregam endereçamento registrado.

� Uso interno do espaço de endereço RFC1918 em vez de endereço registrado.

É importante restringir a transmissão de endereços IP de forma a evitar que os hackers "descubram" os endereços IP da rede interna e utilizem essas informações para acessar a rede.

Os meios eficazes de atender à inteção deste requisito podem variar de acordo com a tecnologia de rede específica utilizada em seu ambiente. Por exemplo: os controles utilizados para atender a estes requisitos em redes IPv4 poderão ser diferentes daqueles utilizados em redes IPv6.

Uma técnica para evitar que as informações de endereço IP sejam descobertas em uma rede IPv4 é implantar a tradução do endereço de rede (NAT - Network Address Translation). A NAT, que normalmente é gerada firewall, permite que a organização tenha endereços internos que só sejam visíveis dentro da rede, e um endereço externo que seja visível externamente. Se o firewall não “ocultar” (ou mascarar) os endereços de IP da rede interna, um indivíduo mal-intencionado pode descobrir os endereços de IP internos e tentar acessar a rede com um endereço de IP obtido por spoofing.

Em redes IPv4 o espaço de endereços RFC1918 é reservado para endereçamentos internos e não poderá ser roteado pela Internet. Dessa forma, é o preferido para endereçamento de IP de redes internas. Entretanto, as empresas poderão ter suas razões para utilizar em suas redes internas outros espaços de endereços que não sejam o RFC1918. Neste caso, deverá ser utilizada uma forma de prevenção de propagandas de rota para evitar que o espaço de endereços interno seja transmitido pela Internet ou divulgado a pessoas não autorizadas.

1.4Instalar o software de firewall pessoal em quaisquer computadores móveis e/ou de propriedade do funcionário com conectividade direta à Internet (por exemplo, laptops usados pelos funcionários), que são usados para acessar a rede da empresa.

Se o computador não tiver instalado em si um firewall ou programa antivírus, spyware, Trojans, vírus, worms e rootkits (malware) poderão ser baixados e/ou instalados sem conhecimento. O computador fica ainda mais vulnerável quando estiver diretamente conectado à Internet, e não estiver por trás do firewall corporativo, caso em que o malware carregado em um computador poderá buscar com más intenções nas informações dentro da rede quando o computador for reconectado à rede corporativa.

Observação: A intenção deste requisito se aplica a computadores de acesso remoto, sejam eles de propriedade do funcionário ou da empresa. Os sistemas que não podem ser gerenciados pelas políticas empresariais introduzem fraquezas ao perímetro e oferecem oportunidades a pessoas mal-intencionadas.


Requisito 2: Não usar padrões disponibilizados pelo fornecedor para senhas do sistema e outros parâmet ros de segurança

Indivíduos mal-intencionados (dentro e fora de uma empresa) com frequência usam senhas padrão do fornecedor e outras configurações padrão do fornecedor para comprometer os sistemas. Essas senhas e configurações são bastante conhecidas pelas comunidades de hackers e facilmente determinadas por meio de informações públicas.


2.1 Sempre alterar os padrões disponibilizados pelo fornecedor antes de instalar um sistema na rede—por exemplo, incluir senhas, strings de comunidade de SNMP (simple network management protocol) e a eliminação de contas desnecessárias.

Indivíduos mal-intencionados (dentro e fora de uma empresa) com freqüência usam senhas padrão do fornecedor e outras configurações padrão do fornecedor para comprometer os sistemas. Essas configurações são conhecidas nas comunidades de hackers e deixam seu sistema altamente vulnerável a ataques.

2.1.1Em ambientes sem fio conectados ao ambiente de dados do titular do cartão ou que transmitam dados do titular do cartão, alterar os padrões do fornecedor sem fio, incluindo, mas não se limitando a, chaves de criptografia sem fio padrão, senhas e strings de comunidades de SNMP.

Muitos usuários instalam esses dispositivos sem aprovação da gerência e não alteram as configurações-padrão nem fazem as configurações de segurança. Se as redes wireless não forem implementadas com configurações de segurança suficientes (incluindo a alteração das configurações-padrão), os sniffers da rede wireless conseguem espreitar o tráfego, capturar dados e senhas e entrar e atacar sua rede com facilidade. Além disso, o protocolo de troca de chaves para a versão antiga da criptografia o 802.11x (WEP) foi quebrado e pode tornar a criptografia inútil. Verifique se o firmware dos dispositivos está atualizado para suportar protocolos mais seguros (por exemplo, WPA2).

2.2 Desenvolver padrões de configuração para todos os componentes do sistema. Certificar-se de que esses padrões abrangem todas as vulnerabilidades de segurança conhecidas e estão em conformidade com os padrões de fortalecimento do sistema aceitos pelo setor.

As fontes dos padrões de proteção do sistema aceitos pelo setor podem incluir, mas não 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)

Existem pontos fracos conhecidos em vários sistemas operacionais, bancos de dados e aplicativos empresariais, e existem também formas conhecidas de configurar esses sistemas para corrigir as vulnerabilidades de segurança. Para ajudar quem não é especialista nisso, as organizações de segurança criaram recomendações para proteção do sistema que aconselham como corrigir esses pontos fracos. Se os sistemas forem deixados com esses pontos fracos, como por exemplo configurações de arquivo fracas ou serviços e protocolos com falhas (para aqueles serviços e protocolos que não são necessários com freqüência), um transgressor poderá usar várias e conhecidas explorações para atacar serviços e protocolos vulneráveis e, assim, ganhar acesso à rede da organização. Websites de origem onde você poderá aprender sobre as melhores práticas da indústria que poderão ajudá-lo a implantar padrões de configuração incluindo, mas não apenas: www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org.

Os padrões de configuração do sistema também deverão ser mantidos atualizados para garantir que as deficiências recentemente identificadas sejam corrigidas antes de o sistema ser instalado na rede.



2.2.1Implementar somente uma função principal por servidor para evitar funções que exigem diferentes níveis de segurança coexistindo no mesmo servidor. (Por exemplo, servidores da Web, servidores do banco de dados e DNS devem ser implementados em servidores separados.)

Observação: Onde tecnologias de virtualização estiverem em uso, implemente somente uma função principal por componente do sistema virtual.

Isso serve para garantir que os padrões de configuração do sistema da sua organização e os processos relacionados abordem funções do servidor que precisem ter níveis de segurança diferentes ou que possam introduzir pontos fracos de segurança em outras funções do mesmo servidor. Por exemplo:

1. Um banco de dados que precise ter medidas de segurança robustas estaria arriscado a compartilhar um servidor com um aplicativo da Web, que precisa ser aberto e interagir diretamente com a Internet.

2. A não-aplicação de um patch em uma função aparentemente pequena pode resultar em comprometimento que cause impacto em outras funções 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 cartão (geralmente com base em Unix, Linux ou Windows). Este requisito não deverá ser aplicado em sistemas que originalmente implantem níveis de segurança em um único servidor (ex.: mainframe).

Onde forem utilizadas tecnologias de virtualização, cada componente virtual (ex.: máquina virtual, comutador virtual, aplicativo de segurança virtual, etc) deverá ser considerado delimitador "de sistema". Os hipervisores individuais poderão ser compatíveis com diversas funções, mas uma única máquina virtual deveria aderir à regra "uma função primária". Nestas circunstâncias, o comprometimento do hipervisor poderá levar ao comprometimento de todas as funções do sistema. Consequentemente, o nível de risco também deverá ser considerado ao localizar diversas funções ou componentes em um único sistema físico.

2.2.2 Ativar somente serviços, protocolos, daemons, etc. necessários e seguros, conforme exigido para a função do sistema.

Implantar recursos de segurança para todos os serviços, protocolos ou daemons exigidos que forem considerados não seguros. Por exemplo: utilizar tecnologias como SSH, S-FTP, SSL ou IPSec VPN para proteger sistemas como NetBIOS, compartilhamento de arquivos, Telnet, FTP, etc.

Conforme informado no item 1.1.5, existem muitos protocolos de que uma empresa pode precisar (ou estarem ativados por padrão) que normalmente sejam usados por indivíduos mal-intencionados para comprometer uma rede. Para garantir que apenas os serviços e protocolos necessários sejam ativados e que todos os serviços e protocolos não seguros sejam protegidos adequadamente antes da implantação de novos servidores, este requisito deverá fazer parte dos padrões de configuração da empresa e dos processos relacionados.

2.2.3 Configurar os parâmetros de segurança do sistema para impedir o uso incorreto.

Isso serve para garantir que os padrões de configuração do sistema de sua organização e os processos relacionados abordem especificamente as configurações e os parâmetros de segurança que tenham implicações de segurança conhecidas.



2.2.4 Remover todas as funcionalidades desnecessárias, como scripts, drivers, recursos, subsistemas, sistemas de arquivo e servidores da Web desnecessários.

Os padrões de proteção do servidor devem incluir processos para resolver funcionalidades desnecessárias com implicações de segurança específicas (como remover/desativar FTP ou o servidor da Web, caso o servidor não execute essas funções).

2.3 Criptografar todo o acesso administrativo não console durante a criptografia robusta. Usar tecnologias como SSH, VPN ou SSL/TLS para o gerenciamento baseado na Web e outros acessos administrativos não-console.

Se a administração remota não for feita com autenticação segura e comunicações criptografadas, informações confidenciais de nível administrativo ou operacional (como as senhas do administrador) poderão ser reveladas a um espião. Um indivíduo mal-intencionado pode usar essas informações para acessar a rede, tornar-se administrador e roubar os dados.

2..4Os provedores de hospedagem compartilhada devem proteger cada ambiente hospedado da entidade e os dados do titular do cartão. Esses provedores devem atender a requisitos específicos, conforme detalhado no Apêndice A: Requisitos adicionais do PCI DSS para provedores de hospedagem compartilhada.

Isso serve para provedores de hospedagem que oferecem ambientes de hospedagem compartilhada para vários clientes no mesmo servidor. Quando todos os dados estiverem no mesmo servidor e sob controle de um único ambiente, muitas vezes essas configurações nesses servidores compartilhados não serão gerenciáveis por clientes individuais, permitindo que os clientes adicionem funções e scripts inseguros que causam impacto na segurança de todos os outros ambientes de clientes e, assim, facilitando para um indivíduo mal-intencionado comprometer os dados de um cliente, obtendo acesso a todos os dados dos outros clientes. Veja o Anexo A.


Orientação para os Requisitos 3 e 4: Proteger os da dos do titular do cartão

Requisito 3: Proteger os dados armazenados do titul ar do cartão

Métodos de proteção como criptografia, truncamento, mascaramento e referenciamento são componentes essenciais da proteção de dados do titular do cartão. Se um invasor burlar outros controles de segurança e obtiver acesso aos dados criptografados, sem as chaves criptográficas adequadas, os dados estarão ilegíveis e inutilizáveis para aquele indivíduo. Outros métodos eficientes de proteção dos dados armazenados devem ser considerados como oportunidades potenciais de minimização dos riscos. Por exemplo, os métodos para minimizar os riscos incluem não armazenar os dados do titular do cartão a menos que seja absolutamente necessário, truncar os dados do titular do cartão se um PAN completo não for necessário e não enviar o PAN em e-mails não criptografados.

Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS para obter definições de "criptografia robusta" e outros termos do PCI DSS.


3.1Manter a armazenagem dos dados do titular do cartão o mínimo possível, implementar políticas, processos e procedimentos de retenção e descarte de dados.

3.1.1 Implementar uma política de retenção e descarte de dados que inclua:

� Limite da quantia de dados armazenados e do tempo de retenção ao que é exigido pelos requisitos legais, regulatórios e comerciais

� Processos para exclusão segura de dados quando não mais necessários

� Requisitos de retenção específicos para dados de titular do cartão

� Processos trimestrais manuais ou automáticos para identificar e excluir com segurança os dados do titular do cartão que excederem os requisitos de retenção definidos

Políticas formais de retenção de dados identificam quais dados precisam ser retidos e onde ficam, de forma a serem excluídos ou destruídos com segurança assim que não forem mais necessários. Para definir os requisitos de retenção adequados, a empresa deverá primeiro conhecer suas necessidades de negócios, bem como as responsabilidades legais e regulamentares que se aplicam à indústria ou ao tipo dos dados que serão retidos.

O armazenamento prolongado dos dados do titular do cartão além das necessidades da empresa cria um risco desnecessário. Os únicos dados do titular do cartão que podem ser armazenados são o número da conta principal, ou PAN (desde que ilegível), data de vencimento, nome e código de serviço.

Implementar métodos de exclusão seguros garante que os dados não poderão ser recuperados quando não forem mais necessários.

Lembre-se: se você não precisar, não os armazene!



3.2 Não armazenar dados de autenticação confidenciais após a autorização (mesmo se estiverem criptografados).

Os dados de autenticação confidenciais incluem os dados conforme mencionados nos seguintes Requisitos 3.2.1 até 3.2.3:

Observação: É permissível para os emissores e empresas que suportam os serviços de emissão para armazenar dados de autenticação sensível se houver justificação de negócios e se os dados forem armazenados com segurança.

Os dados confidenciais de autenticação consistem em dados de tarja magnética (ou trilha)6, código de validação do cartão ou valor7, e dados de PIN8. O armazenamento de dados de autenticação confidenciais após a autorização é proibido! Esses dados são muito valiosos para indivíduos mal-intencionados, pois permitem falsificar cartões de pagamento falsos e criar transações fraudulentas. Veja Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS para obter a definição completa de “dados de autenticação confidenciais”.

Observação: As empresas que executam, facilitam ou suportam serviços de emissão têm permissão para armazenar dados de autenticação confidenciais SOMENTE SE apresentarem legítima necessidade de negócios para armazenar esses dados. Deve-se observar que todos os requisitos de PCI DSS se aplicam aos emissores, e a única exceção para emissores e processadores de emissões é que os dados de autenticação confidenciais poderão ficar retidos se houver uma razão legítima para tanto. Razão legítima é aquela necessária para o desempenho da função fornecida para o emissor e não de conveniência.

Esses dados deverão ser armazenados com segurança e de acordo com o PCI DSS e os requisitos específicos da bandeira de débito.

3.2.1 Não armazenar o conteúdo completo de qualquer rastro da tarja magnética (localizada na parte posterior do cartão, em um chio ou outro local). Esses dados são denominados alternativamente como rastro completo, rastro, rastro 1, rastro 2 e dados da tarja magnética.

Observação: No curso normal dos negócios, os seguintes elementos de dados da tarja magnética talvez precisem ser retidos:

� O nome do titular do cartão � O número da conta principal (PAN) � Data de vencimento � O código de serviço

Para minimizar o risco, armazene somente os elementos de dados conforme necessário para os negócios.

Se for armazenado o rastro inteiro, indivíduos mal-intencionados que obtiverem esses dados poderão reproduzir e vender cartões de pagamento.

6 Dados codificados na tarja magnética utilizados para autorização durante a transação com o cartão. Estes dados também poderão ser encontrados em um chip ou em outra parte

do cartão. As entidades não podem manter todos os dados da tarja magnética após a autorização da transação. Os únicos elementos dos dados da tarja que podem ser retidos são o número da conta principal, o nome do titular do cartão, a data de vencimento e o código de serviço.

7 O valor de três ou quatro dígitos impresso à direita do painel de assinatura ou na frente do cartão de pagamento usado para verificar transações com cartão não presente. 8 Número de Identificação Pessoal inserido pelo titular do cartão durante uma transação com o cartão e/ou bloqueio de PIN criptografado dentro da mensagem da transação.



3.2.2 Não armazenar o código ou valor de verificação do cartão (o número de três ou quatro dígitos impresso na frente ou atrás do cartão de pagamento) usado para verificar as transações com cartão não presente.

O objetivo do código de validação do cartão é proteger as transações do tipo "cartão não-presente", aquelas feitas por Internet, por correio ou telefone (MO/TO), nas quais o consumidor e o cartão não estão presentes. Esses tipos de transação podem ser autenticadas como originadas do proprietário do cartão somente ao solicitar esse código de validação do cartão, pois o proprietário do cartão o tem em mãos e pode ler o valor. Se esses dados proibidos forem armazenados e depois roubados, indivíduos mal-intencionados podem executar transações fraudulentas pela Internet e por MO/TO.

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

Esses valores só devem ser conhecidos pelo proprietário do cartão ou pelo banco que emitiu o cartão. Se esses dados proibidos forem armazenados e depois roubados, indivíduos mal-intencionados podem executar transações de débito protegidas por senha (por exemplo, saques em caixas eletrônicos).

3.3 Mascarar o PAN quando exibido (os primeiros seis e quatro últimos dígitos são o número máximo de dígitos a serem exibidos).

Observações: � Esse requisito não se aplica aos funcionários e outras

partes interessadas em um negócio legítimo que precisam visualizar o PAN completo.

� Este requisito não substitui os requisitos mais rigorosos em vigor quanto às exibições dos dados do titular do cartão - por exemplo, para recebimentos do ponto de venda.

A exibição do PAN completo em locais como telas de computador, recibos de cartão de pagamento, faxes ou extratos em papel pode fazer com que esses dados sejam obtidos por indivíduos não autorizados e usados de forma fraudulenta. O PAN pode ser exibido em sua integridade nos recibos do tipo “cópia do comerciante”; no entanto, os recibos em papel devem obedecer aos mesmos requisitos de segurança que as cópias eletrônicas e seguir as diretrizes do Padrão de segurança de dados do PCI, especialmente o Requisito 9, sobre segurança física. O PAN completo também pode ser exibido para as pessoas com necessidade de negócios legítima de ver o PAN completo.

Este requisito está relacionado à proteção do PAN exibida em telas, recibos, etc, e não deverá ser confundido com o Requisito 3.4 para proteção do PAN quando armazenado em arquivos, bancos de dados, etc.



3.4Tornar o PAN ilegível em qualquer local onde ele esteja armazenado (inclusive em mídia digital portátil, mídia de back-up, em registros) utilizando qualquer uma das seguintes abordagens:

� Referências únicas com base na criptografia robusta (o hash deve ser do PAN inteiro)

� Truncamento (o hashing não 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

Observação: É um esforço relativamente simples para um indivíduo mal-intencionado reconstituir os dados do PAN original caso tenha acesso às versões truncadas e hash do PAN. Quando as versões truncada e hash do mesmo PAN estiverem presentes no ambiente de uma entidade, os controles adicionais deverão estar implantados para assegurar que as versões truncada e hash não sejam correlacionadas para reconstituir o PAN original.

A falta de proteção dos PANs pode permitir que indivíduos mal-intencionados visualizem ou façam download desses dados. Os PANs armazenados no armazenamento principal (bancos de dados ou arquivos simples, como arquivos de texto e planilhas), além de armazenamento não principal (backup, logs de auditoria, logs de exceção ou de resolução de problemas) devem todos estar protegidos. Danos decorrentes de roubou ou perda de tarjas de backup durante o transporte poderão ser reduzidos ao garantir que os PANs sejam deixados ilegíveis por meio de criptografia, truncamento ou codificação hash. Como os logs de auditoria, resolução de problemas e de exceção precisam ser retidos, você pode evitar a divulgação dos dados nos logs ao deixar os PANs ilegíveis (ou removendo-os) em logs.

Ao correlacionar as versões de hash e truncada de um determinado PAN, um indivíduo mal-intencionado poderá facilmente derivar o valor do PAN original. Os controles que evitam a correlação desses dados ajudarão a garantir que o PAN original permaneça ilegível.

Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS para obter definições de "criptografia robusta" e outros termos do PCI DSS.

� Referências únicas com base na criptografia robusta (o hash deve ser do PAN inteiro)

As funções de sentido único, como o Algoritmo de has protegido (SHA - Secure Hash Algorithm) com base em criptografia robusta poderão ser utilizadas para tornar ilegíveis os dados do titular do cartão. As funções de hashing são adequadas quando não houver necessidade de recuperar o número original (o hashing de direção única é irreversível).

Para complicar a criação de tabelas de arco íris é recomendável, mas não necessário, que seja inserido um valor de sal à função de hash além do PAN.

� Truncamento (o hashing não pode ser usado para substituir o segmento truncado do PAN)

A intenção do truncamento é que somente uma parte (sem exceder os primeiro seis e os últimos quatro dígitos) 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, relatórios, recibos, etc.).

Este requisito está relacionado à proteção do PAN quando armazenado em arquivos, bancos de dados, etc, e não deverá ser confundido com o Requisito 3.3 para proteção do PAN exibido em telas, recibos, etc.



� Tokens de índice e pads (os pads devem ser armazenados de forma segura)

Os tokens de índice e pads também podem ser usados para tornar os dados do titular do cartão ilegíveis. Um token de índice é um token criptográfico que substitui o PAN, com base em determinado índice para um valor imprevisível. Um pad de uso único é um sistema no qual uma chave privada, gerada aleatoriamente, é usada só uma vez para criptografar uma mensagem que então é descodificada usando um pad e uma chave de uso único correspondentes.

� Criptografia robusta com processos e procedimentos de gerenciamento de chaves associados

O objetivo da criptografia robusta (veja a definição e os comprimentos da chave no documento Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS) é que a criptografia se baseie em um algoritmo testado e aceito pela empresa (e não um algoritmo “feito em casa”).

3.4.1 Se a criptografia de disco for utilizada (em vez da criptografia de bancos de dados no nível de arquivo ou coluna), o acesso lógico deve ser gerenciado independentemente de mecanismos de controle de acesso a sistemas operacionais nativos (por exemplo, não utilizando bancos de dados de contas de usuário locais). As chaves da descrição não devem estar ligadas às contas de usuário.

O objetivo deste requisito é abordar a aceitabilidade da criptografia de disco para deixar os dados do titular do cartão ilegíveis. A criptografia de disco codifica os dados armazenados no armazenamento em massa do computador e descodifica automaticamente as informações quando um usuário autorizado as solicita. Os sistemas de criptografia de disco interceptam as operações de leitura e gravação do sistema operacional e executam as transformações criptográficas adequadas sem nenhuma ação especial por parte do usuário, além de fornecer uma senha ou passphrase no início de uma sessão. Com base nessas características de criptografia de disco, para obedecer a esse requisito, o método de criptografia de disco não pode ter:

1) Associação direta com o sistema operacional, ou

2) Chaves de decodificação que estejam associadas a contas de usuários.

3.5 Proteja qualquer chave usada para tornar os dados do titular do cartão seguros contra divulgação e mal uso:

Observação : Esse requisito também 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 tão robustas quanto as chaves de criptografia de dados.

As chaves criptográficas devem ser muito bem protegidas, pois quem tiver acesso a elas conseguirá decodificar os dados. As chaves de criptografia de chaves, se utilizadas, deverão ser ao menos tão robustas quanto as chaves de criptografia de dados para garantir a proteção adequada da chave que criptografa os dados e dos dados criptografados por essa chave.

O requisito para proteger chaves da divulgação 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 várias chaves de criptografia de dados, as chaves de criptografia de chaves necessitam de medidas de proteção vigorosas. Os métodos de armazenamento seguro das chaves de criptografia de chaves incluem, mas não limitam-se a, módulos de segurança de hardware (HSMs) e adulteram o armazenamento evidente com controle e divisão de conhecimento.

3.5.1Restringir o acesso às chaves criptográficas ao menor número necessário de responsáveis pela proteção.

Deve haver muito poucas pessoas com acesso às chaves criptográficas, normalmente só aquelas com responsabilidades de custódia de chaves.



3.5.2 Armazenar chaves criptográficas de forma segura no menor número possível de locais e formatos.

As chaves criptográficas devem ser armazenadas em segurança, normalmente criptografas com chaves de criptografia e armazenadas em muito poucos locais. As chaves de criptografia de chaves não precisarão ser criptografadas, mas deverão ficar protegidas contra divulgação e uso indevido da forma definida no Requisito 3.5. Armazenar as chaves de criptografia de chaves em locais físicos ou logicamente separados das chaves de criptografia de dados reduz os riscos de acesso não autorizado às duas chaves.

3.6 Documentar e implementar por completo todos os processos e procedimentos de gerenciamento de chave com relação às chaves criptográficas usadas para a criptografia dos dados do titular do cartão, incluindo o seguinte:

Observação: Vários padrões do setor para o gerenciamento de chave estão disponíveis a partir de diversos recursos, incluindo NIST, que pode ser encontrado em http://csrc.nist.gov.

A forma como as chaves criptográficas são gerenciadas é parte essencial da segurança continuada da solução 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.1 Geração de chaves criptográficas robustas A solução de criptografia deve gerar chaves robustas, conforme definido em Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS, em "Criptografia robusta".

3.6.2 Distribuição segura da chave criptográfica A solução de criptografia deve distribuir as chaves de forma segura, o que significa que as chaves não deve ser distribuídas sem limitação, e sim somente para os responsáveis identificados em 3.5.1.

3.6.3 Armazenamento seguro de chaves criptográficas A solução de criptografia deve armazenar as chaves com segurança, o que significa que as chaves não devem ser armazenadas sem limitação (criptografe-as com uma chave de criptografia).



3.6.4 Troca de chave criptográfica para as chaves que chegaram ao final de seu criptoperíodo (por exemplo, após ter passado determinado período de tempo e/ ou após 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 práticas e orientações do setor (por exemplo, a Publicação Especial NIST 800-57).

Criptoperíodo é o tempo transcorrido durante o qual uma determinada chave de criptografia poderá ser utilizada para seus devidos fins. As considerações para definir o criptoperíodo incluem, mas não apenas, a força 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 periódica das chaves de criptografia é essencial para minimizar o risco de alguém obter as chaves de criptografia e conseguir decodificar os dados.

Caso seja fornecido pelo revendedor do aplicativo de criptografia, siga os processos e recomendações documentados pelo revendedor para troca periódica das chaves. O proprietário ou responsável pela chave também poderá consultar as melhores práticas da indústria sobre algoritmos de criptografia e gerenciamento de chaves, por exemplo a Publicação especial NIST 800-57, para obter orientações sobre o criptoperíodo adequado de diferentes algoritmos e comprimentos de chaves.

A inteção deste requerimento se aplica às chaves utilizadas para criptografar os dados do titular do cartão armazenados e a qualquer chave de criptografia de chaves.

3.6.5 Inutilização ou substituição (por exemplo, arquivamento, destruição e/ ou revogação) de chaves considerada necessária quando a integridade da chave estiver enfraquecida (por exemplo, saída de um funcionário de uma chave de texto simples) ou houver suspeita de que a chave esteja comprometida.

Observação : Caso chaves criptográficas inutilizadas ou recolocadas precisarem ser retidas, essas chaves deverão ser arquivadas em segurança (por exemplo, usando uma chave de criptografia de chaves). Chaves criptográficas arquivadas devem ser usadas somente para fins de decodificação/verificação.

Chaves antigas que não são mais usadas nem necessárias devem ser aposentadas e destruídas para garantir que não possam mais ser usadas. Se for necessário mantê-las (para usar com dados arquivados e criptografados, por exemplo), elas deverão ser muito bem protegidas (veja o item 3.6.6 abaixo). A solução de criptografia também deve levar em consideração e facilitar o processo para substituir as chaves que estejam sabidamente ou potencialmente comprometidas.



3.6.6 Se forem usadas operações manuais de gerenciamento de chave criptográfica de texto simples, essas operações devem ser gerenciadas com o uso de conhecimento separado e de controle duplo (por exemplo, exigindo duas ou três pessoas, cada uma conhecendo somente o seu componente da chave, para reconstituir a chave completa).

Observação: Exemplos de operações manuais de gerenciamento de chave incluem, mas não são limitados a: geração de chave, transmissão, carregamento, armazenamento e destruição.

O conhecimento compartilhado e o controle duplo das chaves são usados para eliminar a possibilidade de uma pessoa ter acesso à chave inteira. Este controle pode ser aplicado em operações de gerenciamento de chaves manual onde o gerenciamento de chaves não for implantado por um produto de criptografia.

3.6.7 Prevenção contra a substituição não autorizada de chaves criptográficas.

A solução de criptografia não deve levar em conta nem aceitar a substituição de chaves vindas de fontes não autorizadas ou de processos inesperados.

3.6.8 Requisito para que os responsáveis pela proteção das chaves criptográficas assinem um formulário declarando que eles compreendem e aceitam suas responsabilidades pela proteção das chaves.

Este processo assegurará que indivíduos que atuem como responsáveis se comprometam com a função de responsáveis pela chave e conheçam as obrigações.


Requisito 4: Criptografar a transmissão dos dados d o titular do cartão em redes abertas e públicas

As informações confidenciais devem ser criptografadas durante a transmissão nas redes que são facilmente acessadas por indivíduos mal-intencionados. Redes wireless configuradas de forma incorreta e vulnerabilidades na criptografia legada e protocolos de autenticação continuam a ser alvos contínuos de indivíduos mal-intencionados que exploram essas vulnerabilidades para obter acesso privilegiado aos ambientes de dados do titular do cartão.


4.1 Uso de protocolos robustos de criptografia e de segurança (por exemplo, SSL/TLS, IPSEC, SSH, etc.) para proteger dados confidenciais do titular do cartão durante a transmissão por redes públicas, abertas. Os exemplos de redes abertas e públicas que estão no escopo do PCI DSS incluem mas não se limitam a:

� A Internet

� Tecnologias sem fio,

� Global System for Mobile communications (GSM)

� General Packet Radio Service (GPRS).

As informações confidenciais devem ser criptografas durante a transmissão por redes públicas, pois é fácil e comum para um indivíduo mal-intencionado interceptar e/ou desviar os dados enquanto eles estiverem em trânsito.

Por exemplo: o protocolo de camada de sockets segura (SSL - Secure Sockets Layer) criptografa páginas da web e os dados inseridos nelas. Ao usar sites protegidos por SSL, verifique se “https” faz parte do URL.

Observe que algumas implantações de protocolo (como SSL versão 2.0 e SSH versão 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 segurança adotado, verifique que esteja configurado para utilizar somente configurações e versões seguras para evitar que seja utilizada uma conexão não segura.



4.1.1 Certificar-se de que as redes wireless estejam transmitindo dados do titular do cartão ou estejam conectadas ao ambiente de dados do titular do cartão, usar as melhores práticas do setor (por exemplo, IEEE 802.11i) para implementar a criptografia robusta para a autenticação e a transmissão.

Observação : O uso de WEP como controle de segurança foi proibido em 30 de junho de 2010.

Usuários mal-intencionados usam as várias ferramentas que estão disponíveis gratuitamente para espionar as comunicações wireless. O uso de criptografias robustas poderá limitar a divulgação de informações confidenciais através da rede. Muitos comprometimentos conhecidos dos dados do titular do cartão armazenados somente em uma rede com fio foram originados quando um usuário mal-intencionado expandiu o acesso de uma rede wireless insegura. Exemplos de implantações sem fio que necessitam de criptografia robusta incluem, mas não limitam-se a, GPRS, GSM, WIFI, satélites e Bluetooth.

A criptografia robusta para autenticação e transmissão dos dados do titular do cartão é necessária para evitar que usuários 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 não é considerada uma criptografia robusta. É vulnerável devido aos fracos vetores de inicialização no processo de troca de chaves WEP e não possui a rotação de chaves necessária. Um transgressor pode usar as ferramentas de cracking por força bruta amplamente disponíveis para penetrar na criptografia por WEP.

Os dispositivos sem fio atuais deverão ser atualizados (exemplo: atualizar o firmware de ponto de acesso para WPA2) para que sejam compatíveis com criptografias robustas. Caso os dispositivos atuais não possam ser atualizados, será possível adquirir um novo equipamento ou outros controles de compensação implantados para fornecer criptografia robusta.

4.2Nunca enviar PANs não criptografados por tecnologias de envio de mensagens de usuário final (por exemplo, e-mail, sistemas de mensagens instantâneas, bate-papo).

E-mail, sistemas de mensagens instantâneas, bate-papo podem ser facilmente interceptados por sniffing de pacotes durante a entrega transversal por redes internas e públicas. Não utilize essas ferramentas de envio de mensagem para enviar o PAN se elas não tiverem recurso de criptografia.


Orientação para os Requisitos 5 e 6: Manter um prog rama de gerenciamento de vulnerabilidades

Requisito 5: Usar e atualizar regularmente o softwa re ou programas antivírus

Softwares mal-intencionados, normalmente chamados de "malware" – incluindo vírus, worms e cavalos de Tróia – adentram a rede durante muitas atividades de negócios aprovadas, incluindo e-mail dos funcionários e uso da Internet, computadores móveis e dispositivos de armazenamento, resultando na exploração das vulnerabilidades do sistema. Softwares anti-vírus devem ser usados em todos os sistemas comumente afetados por malwares para protegê-los das ameaças de softwares atuais e em evolução.


5.1Implementar softwares antivírus em todos os sistemas normalmente afetados por softwares mal-intencionados (especialmente em computadores pessoais e servidores).

Existe um fluxo constante de ataques usando façanhas amplamente divulgadas, muitas vezes do tipo "zero day" (publicado e divulgado por redes em até uma hora após a descoberta) contra sistemas até então seguros. Sem um software antivírus 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 também estão vulneráveis ao usarem dispositivos removíveis de armazenamento, como CDs e DVDs, USB memory sticks e discos rígidos, câmeras digitais, assistentes pessoais (PDAs) e outros periféricos. Sem a instalação de um software antivírus, esses computadores podem se tornar ponto de acesso para sua rede e/ou mirar nas informações dentro da rede.

Apesar de os sistemas comumente afetados por softwares mal-intencionados normalmente não incluírem 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 segurança e atualizar os padrões e processos de configuração de acordo. Se outro tipo de solução se dirigir a ameaças idênticas com uma metodologia diferente da abordagem com base em assinatura, ainda poderá ser aceita para atender ao requisito.

As tendências em softwares mal-intencionados relacionadas aos sistemas operacionais que a entidade usa devem ser incluídas na identificação de novas vulnerabilidades de segurança, e os métodos para resolver novas tendências devem ser incorporados aos padrões de configuração da empresa e aos mecanismos de proteção, conforme necessário.

Em geral, os sistemas operacionais a seguir não são normalmente afetados por software mal-intencionados: mainframes e alguns servidores Unix (como AIX, Solaris e HP-Unix). No entanto, as tendências do setor para softwares mal-intencionados podem mudar rapidamente, e cada organização deve obedecer ao Requisito 6.2 para identificar e resolver novas vulnerabilidades de segurança e


Requisito Orientação atualizar os padrões e processos de configuração de acordo.

5.1.1 Certificar-se de que todos os programas antivírus podem detectar, remover e proteger contra todos os tipos conhecidos de softwares mal-intencionados.

É importante proteger contra TODOS os tipos e formas de softwares mal-intencionados.

5.2 Certificar-se de que todos os mecanismos antivírus estejam atualizados, funcionem ativamente e possam gerar registros de auditoria.

O melhor software antivírus tem eficácia limitada se não tiver assinaturas antivírus atualizada ou se não estiver ativo na rede ou no computador de uma pessoa.

Os logs de auditoria oferecem a capacidade de monitorar a atividades do vírus e as reações do antivírus. Dessa forma, o software antivírus deverá obrigatoriamente ser configurado de forma a gerar logs de auditoria, e esses logs deverão ser gerenciados de acordo com o Requisito 10.


Requisito 6: Desenvolver e manter sistemas e aplica tivos seguros

Indivíduos inescrupulosos usam as vulnerabilidades da segurança para obter acesso privilegiado aos sistemas. Muitas dessas vulnerabilidades são solucionadas pelos patches de segurança disponibilizados pelos fornecedores, que devem ser instalados pelas entidades que gerenciam os sistemas. Todos os sistemas críticos devem contar com os patches de software adequados lançados mais recentes para proteger contra a exploração e o comprometimento dos dados do titular do cartão por indivíduos e softwares mal-intencionados.

Observação: Patches de software adequados são aqueles patches que foram avaliados e testados de forma suficiente para determinar se os patches não entram em conflito com as configurações de segurança existentes. Para aplicativos desenvolvidos internamente, diversas vulnerabilidades podem ser evitadas ao utilizar processos de desenvolvimento do sistema padrão e técnicas de codificação seguras.


6.1 Certificar-se de que todos os componentes do sistema e softwares estão protegidos de vulnerabilidades conhecidas pois têm os patches de segurança mais recentes disponibilizados pelos fornecedores instalados. Instalar patches de segurança críticos em até um mês após o lançamento.

Observação: Uma empresa talvez considere utilizar uma abordagem baseada nos riscos para priorizar suas instalações de patches. Por exemplo, ao priorizar mais a infra-estrutura crítica (por exemplo, dispositivos e sistemas disponibilizados ao público, bancos de dados) em vez de dispositivos internos menos críticos, para assegurar que sistemas e dispositivos de prioridade elevada sejam resolvidos em um mês e dispositivos e sistemas menos críticos em três meses.

Existe uma quantidade considerável de ataques usando façanhas amplamente divulgadas, muitas vezes do tipo “zero day” (publicadas em até uma hora) contra sistemas até então protegidos. Sem implementar os patches mais recentes nos sistemas críticos assim que possível, um indivíduo mal-intencionado pode usá-las para atacar e desativar a rede. Pense em priorizar mudanças de forma que patches de segurança críticos em sistemas essenciais ou em risco possam ser instalados em até 30 dias, e outras mudanças menos arriscadas sejam instaladas em 2-3 meses.



6.2 Estabelecer um processo para identificar e designar um ranking de risco para as vulnerabilidades de segurança recém-descobertas.

Observações :

Os rankings de risco devem ser baseados nas melhores práticas do setor. Por exemplo, os critérios para o ranking de "Alto" risco as vulnerabilidades devem incluir uma pontuação de base CVSS de 4,0 ou mais e/ou um patch oferecido pelo fornecedor classificado por ele como "crítico" e/ou uma vulnerabilidade que afere um componente crítico do sistema.

O ranking de vulnerabilidades conforme definido em 6.2.a é considerado uma das melhores práticas até 30 de junho de 2012 quando passará a ser um requisito.

A intenção deste requisito é que as organizações se mantenham atualizadas quanto a novas vulnerabilidades que poderão interferir no sistema.

Ao mesmo tempo que é importante monitorar os anúnicos do revendedor em busca de notícias de vulnerabilidades e patches relacionados a seus produtos, também é importante monitorar os grupos comuns de notícias de vulnerabilidades da indústria e as listas de correspondências em busca de vulnerabilidades e possíveis contornos que o revendedor poderá ainda não conhecer.

Quando uma organização identifica uma vulnerabilidade que poderá afetar seu ambiente, o risco que essa vulnerabilidade representa poderá ser avaliado e classificado. Isto significa que a organização deverá possuir um método para avliar as vulnerabilidades e atribuir classificações de risco em uma base consistente. Ao mesmo tempo que cada organização provavelmente terá métodos diferentes de avaliar uma vulnerabilidade e atribuir uma classificação de risco com base em CDE exclusivo, será possível criar com base em sistemas de classificação de risco aceitos pela indústria, como o CVSS. 2.0, NIST SP 800-30, etc.

Classificar os riscos (por exemplo, como "altos", "médios" ou "baixos") permite que as organizações 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, autenticação de segurança e login), e com base nas melhores práticas da indústria, e incorporar segurança de informações durante o ciclo de vida do desenvolvimento do software. Esses processos devem incluir o seguinte:

Sem a inclusão de uma proteção durante as fases de definição de requisitos, design, análise e teste do desenvolvimento de software, as vulnerabilidades de segurança podem ser introduzidas inadvertida ou maliciosamente no ambiente de produção.

6.3.1 Remoção de contas, IDs de usuário e senhas do aplicativo antes que ele se torne ativo ou seja lançado aos clientes

Contas de aplicativos personalizados, IDs de usuários e senhas devem ser removidos do código da produção antes de o aplicativo ser ativado ou liberado para os clientes, pois esses itens podem fornecer informações sobre o funcionamento do aplicativo. A posse dessas informações pode facilitar o comprometimento do aplicativo e dos dados relacionados do titular do cartão.



6.3.2 Analisar o código personalizado antes de liberar para produção ou para os clientes com o objetivo de identificar qualquer vulnerabilidade potencial de codificação.

Observação: Esse requisito referente às análises dos códigos se aplica a todos os códigos personalizados (internos e voltados para o público), como parte integrante do ciclo de vida de desenvolvimento do sistema. As análises dos códigos podem ser realizadas por equipes internas instruídas ou terceiros. Os aplicativos da Web também estão sujeitos a controles extras, caso sejam voltados ao público, para abranger ameaças e vulnerabilidades contínuas após a implementação, conforme definido no Requisito 6.6 do PCI DSS.

As vulnerabilidades de segurança no código personalizado são comumente exploradas por indivíduos mal-intencionados para obter acesso a uma rede e comprometer os dados do titular do cartão.

As revisões do código poderão ser realizadas manualmente ou com o auxílio de ferramentas de revisão automatizadas. As ferramentas de revisão automatizadas possuem uma função que revê o código em busca de erros de codificação e vulnerabilidades. Ao mesmo tempo que a revisão automatizada é útil, em geral não deverá ser creditada como o único meio de rever códigos. Um indivíduo com conhecimento e experiência em revisão de códigos deverá estar envolvido no processo de revisão para identificar problemas de codificação difíceis ou até impossíveis de serem identificados por uma ferramenta. Atribuir as revisões de código a alguém que não seja o desenvolvedor do código permitirá que seja realizada uma revisão independente e objetiva.

6.4 Seguir os procedimentos de controle de alterações para todas as alterações nos componentes do sistema. Esses processos devem incluir o seguinte:

Sem controles de alteração adequados, os recursos de segurança podem ser omitidos sem ou com intenção ou ainda tornados inoperáveis, e podem ocorrer irregularidades no processamento ou pode ser introduzido um código mal-intencionado.

6.4.1 Ambientes de desenvolvimento/testes e de produção separados.

Devido à mutação constante dos ambientes de desenvolvimento e teste, estes tendem a ser menos seguros do que o ambiente de produção. Sem a separação adequada entre os ambientes será possível que o ambiente de produção e os dados do titular do cartão sejam comprometidos por vulnerabilidades em um ambiente de teste ou desenvolvimento.

6.4.2 Separação dos deveres entre os ambientes de desenvolvimento/teste e de produção

Reduzir o número de pessoas com acesso ao ambiente de produção e aos dados do titular do cartão reduz os riscos e ajuda a garantir que o acesso seja limitado aos indivíduos com necessidade comercial de saber.

A inteção deste requisito é garantir que as funções de desenvolvimento e teste fiquem separadas das funções de produção. Por exemplo: um desenvolvedor poderá utilizar uma conta com nível de administrador com privilégios elevados para uso no ambiente de desenvolvimento, e possuir uma conta em separado com acesso de nível de usuário ao ambiente de produção.

Em ambientes em que um indivíduo executa diversas funções (por exemplo, desenvolvimento de aplicativos e implantação de atualizações em sistemas de produção), as tarefas deverão ser atribuídas de forma que nenhum indivíduo possua controle total de um processo sem um ponto de verificação independente. Por exemplo: atribuir responsabilidades de desenvolvimento, autorização e monitoramento a indivíduos diferentes.



6.4.3 Os dados de produção (PANs ativos) não são usados para testes ou desenvolvimento

Os controles de segurança normalmente não são tão rígidos no ambiente de desenvolvimento. O uso de dados de produção dá aos indivíduos mal-intencionados a oportunidade de ganhar acesso não autorizado aos dados de produção (dados do titular do cartão).

As bandeiras dos cartões de débito e diversos adquirentes podem fornecer números 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 Remoção dos dados de teste e contas antes que os sistemas de produção tornem-se ativos

Dados e contas de teste devem ser removidos do código da produção antes de o aplicativo ser ativado, pois esses itens podem fornecer informações sobre o funcionamento do aplicativo. A posse dessas informações pode facilitar o comprometimento do aplicativo e dos dados relacionados do titular do cartão.

6.4.5 Alterar os procedimentos de controle para implementação de patches de segurança e modificações de software. Os procedimentos devem incluir o seguinte:

Sem controles de alteração adequados, os recursos de segurança podem ser omitidos sem ou com intenção ou ainda tornados inoperáveis, e podem ocorrer irregularidades no processamento ou pode ser introduzido um código mal-intencionado. Da mesma forma, uma alteração poderá afetar negativamente o recurso de segurança de um sistema. Neste caso, a alteração deverá ser desfeita.

6.4.5.1 Documentação de impacto. O impacto da alteração deve ser documentado de forma que todas as partes afetadas possam planejar adequadamente as mudanças de processamento.

6.4.5.2 Aprovação documentada de alteração pelas partes autorizadas.

A aprovação por partes autorizadas indica que a alteração é legítima, e que a alteração autorizada foi sancionada pela organização.

6.4.5.3 Teste de funcionalidade para verificar se a alteração não tem impacto adverso sobre a segurança do sistema.

Deverão ser realizados testes rigorosos para verificar se a segurança do ambiente não se reduz ao ser implantada uma alteração. O teste deverá validar que todos os controles de segurança existentes permaneçam no lugar, sejam substituídos por controles igualmente rigorosos ou sejam reforçados após alguma alteração no ambiente.

Para alterações no código do cliente, o teste também verificará se nenhuma vulnerabilidade foi introduzida através da alteração.

6.4.5.4 Procedimentos de reversão. Para cada alteração, deve haver procedimentos de back-out in caso de falha na alteração, permitindo restaurar de volta para o estado anterior.



6.5 Desenvolver aplicativos baseados nas diretrizes de código seguro. Prevenir vulnerabilidades de codificação comuns nos processos de desenvolvimento do software, para incluir o seguinte:

Observação : As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9 estavam atualizadas de acordo com as melhores práticas do setor, quando esta versão do PCI DSS foi publicada. No entanto, conforme as melhores práticas do setor para o gerenciamento de vulnerabilidades são atualizadas (por exemplo o Guia OWASP, SANS CWE Top 25, CERT Secure Coding, etc.), as melhores práticas atuais precisam ser usadas para estes requisitos.

A camada do aplicativo é de alto risco e pode ser almejada por ameaças internas e externas. Sem uma segurança adequada, os dados do titular do cartão e outras informações confidenciais da empresa poderão ser expostos, resultando em prejuízo à empresa, seus clientes e sua reputação.

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 são os controles mínimos que deverão estar no lugar. Esta lista é composta das práticas de decodificação de segurança mais comuns e aceitas no momento em que esta versão do PCI DSS foi publicada. Todas as alterações de práticas de decodificação aceitas pela indústria e as práticas de decodificação organizacionais deverão igualmente ser atualizadas para que haja correspondência.

Os exemplos dos recursos de decodificação de segurança fornecidos (SANS, CERT e OWASP) são fontes de referência sugeridas e deverão ser incluídos apenas para orientação. Uma organização deverá incorporar as práticas de decodificação de segurança semelhantes da forma aplicável à tecnologia particular em seu ambiente.



6.5.1 Falhas na injeção, particularmente na injeção SQL. Também considere as falhas de injeção de OS Command Injection, LDAP e XPath, assim como outras falhas.

Valida a entrada para verificar se os dados do usuário não podem modificar o significado dos comandos e das queries. As falhas de injeção, principalmente de injeção de SQL, são um método comumente utilizado em aplicativos comprometidos. A injeção ocorre quando dados fornecidos pelo usuário são enviados para um intérprete como parte de um comando ou query. Os dados hostis do transgressor enganam o intérprete para executar comandos não 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 informações confidenciais quando funcionalidades no aplicativo do servidor. Essa também é uma forma conhecida de fazer transações fraudulentas em sites habilitados para comércio. As informações de solicitações devem ser validadas antes de serem enviadas para o aplicativo – por exemplo, ao verificar todos os caracteres alfabéticos, mistura de caracteres alfabéticos e numéricos, etc.

6.5.2 Buffer Overflow Garantir que os aplicativos não fiquem vulneráveis a ataques de buffer overflows. Os overflows de buffer ocorrem quando um aplicativo não possui uma verificação de limites adequada em seu espaço de buffer. Para explorar uma vulnerabilidade de overflow de buffer, um transgressor envia a um aplicativo uma quantidade de informações superior à que um de seus buffers consegue manejar. Isto pode fazer com que as informações no buffer sejam empurradas para o espaço da memória do buffer e o espaço da memória executável. Quando isso ocorre, o transgressor consegue inserir um código mal-intencionado no final do buffer e empurrar esse código para o espaço de memória executável ao provocar overflow no buffer. O código mal-intencionado é então executado e frequentemente permite que o transgressor acesse remotamente o aplicativo ou o sistema infectado.

6.5.3 Armazenamento criptográfico seguro Evita falhas criptográficas. Os aplicativos que não 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 cartão. Caso um transgressor consiga explorar os processos criptográficos, ele poderá obter acesso de texto sem criptografia a dados criptografados.

6.5.4 Comunicações inseguras Criptografe corretamente todas as comunicações autenticadas e confidenciais. Os aplicativos que não criptografarem adequadamente o tráfego de rede utilizando criptografia rigorosa correm um risco maior de ficarem comprometidos e de expor os dados do titular do cartão. Se o transgressor conseguir explorar os processos criptografados, poderá obter controle de um aplicativo ou até mesmo obter acesso de texto não criptografado a dados criptografados.



6.5.5 Manuseio incorreto de erros Não vaze informações por mensagens de erro ou outros meios. Os aplicativos podem sem querer vazar informações sobre sua configuração, 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 sérios. Além disso, o manuseio incorreto de erros fornece informações que ajudam um indivíduo mal-intencionado a comprometer o sistema. Se um indivíduo mal-intencionado puder criar erros que o aplicativo não conseguir manusear corretamente, eles podem obter informações detalhadas do sistema, criar interrupções de negação de serviço, causar falhas de segurança ou criar problemas no servidor. Por exemplo: a mensagem “senha incorreta” diz que o ID de usuário fornecido está correto e que eles devem concentrar os esforços somente na senha. Use mensagens de erro mais genéricas, como “os dados não puderam ser verificados".

6.5.6 Todas as vulnerabilidades "Alto" identificadas no processo de identificação de vulnerabilidade (conforme definido no Requisito 6.2 do PCI DSS).

Observação : Este requisito será considerado uma das melhores praticas até 30 de junho de 2012 quando passará a ser um requisito.

Todas as vulnerabilidades altas observadas pelo Requisito 6.2 que poderiam afetar o aplicativo deverão ser levadas em consideração 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 produção.

Nos aplicativos da web e nas interfaces dos aplicativos (externos ou internos) serão aplicados os seguintes requisitos adicionais:

Os aplicativos web, tanto internos quanto externos (públicos), possuem riscos de segurança exclusivos com base em sua arquitetura e sua relativa facilidade em apresentar comprometimento.

6.5.7 Scripting de site cruzado (XSS) Todos os parâmetros devem ser validados antes da inclusão. Ocorrem falhas no XSS sempre que o aplicativo pegar os dados fornecidos pelo usuário e enviá-los para um navegador sem primeiro validar ou codificar esse conteúdo. O XSS permite que os transgressores executem o script no navegador da vítima, que pode seqüestrar sessões de usuários, desfigurar sites, possivelmente introduzir worms, etc.



6.5.8 Controle de acesso inapropriado (como referências diretas inseguras a objetos, falhas em restringir o acesso a URLs e diretórios transversais)

Não exponha referências de objetos internos aos usuários. Uma referência de objeto direto ocorre quando o desenvolvedor expõe uma referência a um objeto de implementação interna, como arquivo, diretório, registro de banco de dados ou chave, como um URM ou form de parâmetro. Os transgressores podem manipular essas referências para acessar outros objetos sem autorização.

Força constantemente o controle de acesso na camada de apresentação e na lógica de negócios para todos os URLs. Muitas vezes um aplicativo só protege os recursos confidenciais ao evitar a exibição de links ou URLs para usuários não autorizados. Os transgressores podem usar esse ponto fraco para acessar e executar operações não autorizadas, acessando diretamente esses URLs.

Proteger contra transversal de diretório. Um transgressor poderá ser capaz de enumerar e navegar pela estrutura do diretório de um website, obtendo acesso a informações não autorizadas e descobrindo o funcionamento do site para exploração futura.

6.5.9 Falsificação de solicitações de site cruzado (CSRF). Não responda a credenciais de autorização e tokens enviados automaticamente pelos navegadores. Um ataque de CSRF força o navegador da vítima logada a enviar uma solicitação pré-autenticada a um aplicativo da Web vulnerável, que então força o navegador da vítima a executar uma ação hostil em benefício do transgressor. O ataque de CSRF pode serão tão poderoso quanto o aplicativo da Web atacado.

6.6 Para aplicativos da Web voltados ao público, abordar novas ameaças e vulnerabilidades continuamente e assegurar que esses aplicativos estejam protegidos contra ataques conhecidos por qualquer um dos métodos a seguir:

� Analisar os aplicativos da Web voltados ao público por meio de ferramentas ou métodos manuais ou automáticos de avaliação de segurança das vulnerabilidades dos aplicativos, pelo menos anualmente e após quaisquer alterações

� Instalar um firewall para aplicativos da Web diante de aplicativos da Web voltados ao público

Ataques em aplicativos na Web são comuns e muitas vezes bem-sucedidos, e são permitidos por práticas de codificação ruins. Este requisito para analisar aplicativos ou instalar firewalls de aplicativos da Web destina-se a reduzir enormemente o número de comprometimentos em aplicativos da Web que resultam em violações nos dados do titular do cartão.

� Ferramentas ou métodos de avaliação da segurança 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 tráfego não 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.


Orientação para os Requisitos 7, 8 e 9: Implementar medidas de controle de acesso rigorosas

Requisito 7: Restringir o acesso aos dados do titul ar do cartão de acordo com a necessidade de conheci mento para o negócio

Para assegurar que os dados críticos possam ser acessados somente por uma equipe autorizada, os sistemas e processos devem estar implementados para limitar o acesso com base na necessidade de divulgação e de acordo com as responsabilidades da função. A “necessidade de divulgação” é quando os direitos de acesso são concedidos somente ao menor número possível de dados e privilégios necessários para realizar um trabalho.


7.1 Limitar o acesso aos componentes do sistema e aos dados do titular do cartão somente àquelas pessoas cuja função requer tal acesso. As limitações de acesso devem incluir o seguinte:

7.1.1 Restrição dos direitos de acesso a IDs de usuários privilegiados ao menor número de privilégios necessários para desempenhar as responsabilidades da função

7.1.2 A concessão dos privilégios está baseada na classificação e na atribuição da função da equipe individual

7.1.3 Requisito para aprovação por partes autorizadas documentada especificando os privilégios exigidos.

7.1.4 Implementação de um sistema de controle de acesso automático

Quanto mais pessoas tiverem acesso aos dados do titular do cartão, mais risco haverá de que a conta do usuário seja utilizada indevidamente. Limitar o acesso àquelas pessoas com um forte motivo corporativo para ter esse acesso ajuda sua organização a evitar o mau uso dos dados do titular do cartão por meio de inexperiência ou más intenções. Quando os direitos de acesso são concedidos somente para uma menor quantidade de dados e privilégios necessários para executar um trabalho, isso se chama "privilégio mínimo" e “necessidade de divulgação”, e quando os privilégios são atribuídos aos indivíduos com base na classificação do cargo e na função, isso se chama “controle de acesso baseado na função” ou RBAC. O reforço do controle de acesso baseado na função não é limitado a uma camada de aplicativos ou qualquer solução de autorização específica. Por exemplo, tecnologias incluindo mas não se limitando a serviços de diretório como Active Directory ou LDAP, Listas de Controle de Acesso (ACLs) e TACACS são soluções viáveis desde que estejam adequadamente configuradas para reforçar os princípios de privilégio mínimo e necessidade de divulgação.

As organizações devem criar políticas e processos claros para controle de acesso de dados com base em necessidade de divulgação e usar controle de acesso baseado na função para definir como e para quem o acesso deverá ser concedido, inclusive para processos de autorização de gerenciamento adequado.



7.2 Estabeleça um sistema de controle de acesso para os componentes do sistema com múltiplos usuários que restringe o acesso com base na necessidade de conhecimento do usuário e está configurado para "recusar todos", a menos que seja permitido de forma específica.

Esse sistema de controle de acesso deve incluir o seguinte:

7.2.1 Abrangência de todos os componentes do sistema

7.2.2 A concessão dos privilégios às pessoas está baseada na classificação e na atribuição da função

7.2.3 Configuração padrão “recusar todos”

Observação: Alguns sistemas de controle de acesso são definidos, como padrão, como “permitir todos”, permitindo portanto o acesso a menos que/até que uma norma seja redigida para recusá-lo de forma específica.

Sem um mecanismo para restringir o acesso com base na necessidade de conhecimento do usuário, este pode sem querer receber acesso aos dados do titular do cartão. O uso de um sistema ou mecanismo de controle de acesso automatizado é essencial para gerenciar vários usuários. Esse sistema deve ser criado segundo as políticas, e os processos de controle de acesso da sua organização (incluindo “necessidade de acesso” e “controle de acesso baseado na função”) devem gerenciar o acesso a todos os componentes do sistema e deve ter uma configuração padrão “recusar todos” para garantir que ninguém 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 identificação exclusiva (ID) a cada pessoa com acesso assegura que cada indivíduo seja exclusivamente responsável pelas suas ações. Quando tal responsabilidade estiver em vigor, as ações desempenhadas nos dados e sistemas críticos serão realizadas por usuários conhecidos e autorizados, e poderão levar a eles.

Observação: Esses requisitos são aplicáveis 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 cartão ou acessar sistemas com dados do titular do cartão. No entanto, os Requisitos 8.1, 8.2 e 8.5.8 a 8.5.15 não têm por objetivo serem aplicados a contas de usuário em um aplicativo de pagamento de um ponto de venda que possua acesso somente a um número de cartão por vez para facilitar a transação única (como contas de caixa).


8.1Atribuir a todos os usuários um ID exclusivo antes de permitir que eles acessem os componentes do sistema ou os dados do titular do cartão.

Ao garantir que todos os usuários sejam individualmente identificados, em vez de usar um ID para vários funcionários, uma organização consegue manter a responsabilidade individual pelas ações e uma trilha de auditoria eficaz por funcionário. Isso ajudará a apressar a resolução e a contenção de problemas quando ocorrer mau uso ou tentativa mal-intencionada.

8.2Além de atribuir um ID exclusivo, um ou mais dos seguintes métodos foi empregado para autenticar todos os usuários:

� 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 biométrica

Esses itens de autenticação, quando usados além dos IDs exclusivos, ajuda a proteger os IDs exclusivos dos usuários contra o comprometimento (visto que quem estiver tentando o comprometimento precisa conhecer tanto o ID exclusivo quanto a senha ou outro item de autenticação).

Certificados digitais são uma opção válida como formulário do tipo de autenticação "algo que você tem" desde que seja exclusivo.



8.3Incorporar a autenticação por dois fatores para o acesso remoto (acesso no nível da rede que se origina fora dela) à rede pelos funcionários, administradores e terceiros. (Por exemplo, autenticação remota e serviço 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 autenticação por dois fatores.)

Observação : A autenticação de dois fatores exige que dois dos três métodos de autenticação (consulte o Req. 8.2 com descrições de métodos de autenticação) sejam usados para autenticação. Usar um fator duas vezes (e.g., usar duas senhas separadas) não caracteriza autenticação de dois fatores.

A autenticação de dois fatores exige duas formas de autenticação para acessos com maior risco, como aqueles originados de fora de sua rede. Para uma segurança adicional, sua organização também pode considerar o uso da autenticação de dois fatores ao acessar redes de segurança mais alta a partir de redes de segurança mais baixa; por exemplo, a partir de computadores desktop corporativos (segurança mais baixa) para servidores de produção/bancos de dados com dados do titular do cartão (segurança alta).

Pretende-se que esse requisito aplique-se aos usuários que possuem acesso remoto ao trabalho, onde esse acesso remoto pudesse levar ao ambiente de dados do titular do cartão.

Nesse contexto, o acesso remoto se refere ao acesso em nível de rede originada de uma rede particular de uma entidade externa, tanto pela Internet como por uma rede ou sistema "não confiável", como um terceiro ou funcionário acessando a rede da entidade usando um computador móvel. Acesso interno LAN-a-LAN (por exemplo, entre dois escritórios por VPN seguro) não é considerado acesso remoto para os fins deste requisito.

Se o acesso remoto for para a rede de uma entidade que possui segmentação adequada, como a impossibilidade de acesso a usuários remotos ou de impacto ao ambiente de dados do titular do cartão, a autenticação de dois fatores para o acesso remoto àquela rede não será exigida pelo PCI DSS; No entanto, a autenticação de dois fatores é exigida para qualquer acesso remoto a redes com acesso ao ambiente de dados do titular do cartão e é recomendável para todo acesso remoto a redes de entidades.

8.4 Converta todas as senhas em ilegíveis durante a transmissão e armazenamento em todos os componentes do sistema usando criptografia robusta.

Muitos dispositivos de rede e aplicativos transmitem o ID do usuário e as senhas sem criptografia por uma rede e/ou também armazenam as senhas sem criptografia. Um indivíduo mal-intencionado pode facilmente interceptar o ID de usuário e a senha sem criptografia ou legível durante a transmissão usando um “sniffer”, ou então acessar diretamente os IDs do usuário e as senhas não criptografas em arquivos onde eles são armazenados e usar esses dados roubados para obter acesso não autorizado. Durante a transmissão, as credenciais do usuário ou o túnel podem ser criptografados

8.5Garantir um controle adequado da autenticação e da senha do usuário para usuários que não sejam clientes e administradores em todos os componentes do sistema, da forma a seguir:

Como uma das primeiras etapas tomadas por um indivíduo mal-intencionado para comprometer um sistema é explorar senhas fracas ou inexistentes, é importante implementar bons processos para identificação de usuários e gestão de autenticação.



8.5.1Controle o acréscimo, a exclusão e a modificação dos IDs do usuário, credenciais e outros objetos do responsável pela identificação.

Para garantir que os usuários adicionados no sistema estejam sejam todos válidos e reconhecidos, a adição, exclusão e modificação dos IDs do usuário deve ser gerenciada e controlada por um pequeno grupo com autoridade específica. A capacidade de gerenciar esses IDs de usuário deve estar limitada somente a esse pequeno grupo.

8.5.2Verificar a identidade do usuário antes de realizar as redefinições de senha.

Muitos indivíduos mal-intencionados usam a “engenharia social” – por exemplo, ligam para o help desk e agem como um usuário legítimo – para trocar a senha, de forma que possam utilizar um ID de usuário. Pense em usar uma “pergunta secreta” que só o usuário em si possa responder para ajudar os administradores a identificarem o usuário antes de redefinir as senhas. As perguntas devem são protegidas corretamente e não podem ser compartilhadas.

8.5.3 Definir as senhas iniciais para um valor exclusivo para cada usuário e alterar imediatamente após a primeira utilização.

Se a mesma senha for usada para todos os novos usuários configurados, um usuário interno, ex-funcionário ou indivíduo mal-intencionado pode conhecer ou descobrir facilmente essa senha e usá-la para ter acesso às contas.

8.5.4 Revogar imediatamente o acesso de quaisquer usuários desligados da empresa.

Se um funcionário sair da empresa e ainda tiver acesso à rede por meio de sua conta de usuário, pode ocorrer um acesso desnecessário ou mal-intencionado aos dados do titular do cartão. Esse acesso pode acontecer pelo ex-funcionário ou por um usuário mal-intencionado que explore a conta antiga e/ou não utilizada. Pense em implementar um processo com o departamento de RH para notificação imediata quando um funcionário for desligado da empresa, de forma que a conta dele possa ser rapidamente desativada.

8.5.5 Remover/desativar as contas dos usuários inativos pelo menos a cada 90 dias.

A existência de contas inativas permite que um usuário não autorizado explore a conta não utilizada para possivelmente acessar os dados do titular do cartão.

8.5.6 Ativar as contas usadas pelos fornecedores somente para a manutenção remota durante o período necessário. Monitorar as contas de acesso remoto do fornecedor quando estiver em uso.

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 não autorizado, seja de um usuário no ambiente do fornecedor ou de um indivíduo 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 cartão se aplica do mesmo modo que para outros usuários, como funcionários 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 política conforme definido nos Requisitos 12.3.8 e 12.3.9.

8.5.7 Comunicar os processos e políticas de autenticação a todos os usuários que possuem acesso aos dados do titular do cartão.

Comunicar os procedimentos de senha a todos os usuários os ajuda a entender e seguir as políticas e a deixá-los alerta contra indivíduos mal-intencionados que possam tentar explorar suas senhas para obter acesso aos dados do titular do cartão (por exemplo, ligando para um funcionário e perguntando sua senha para que ele possa “resolver um problema”).



8.5.8 Não use contas, senhas ou outros métodos de autenticação de grupo, compartilhados ou genéricos .

Se vários usuários compartilharem as mesmas credenciais de autenticação (conta e senha por exemplo), fica impossível atribuir responsabilidade a um usuário ou fazer um registro eficaz das ações dele, pois uma determinada ação 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 frequência por funções administrativas ao usar, por exemplo, sudo ou SSH para que o administrador faça 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 são desativados para evitar o uso dessa conta administrativa compartilhada. Dessa forma, a contabilidade e as trilhas de auditoria individuais são mantidas. No entanto, mesmo com o uso de ferramentas como sudo e SSH, os verdadeiros IDs e senhas do administrador também devem atender aos requisitos do PCI DSS (se tais contras não foram desativadas).

8.5.9 Alterar as senhas do usuário pelo menos a cada 90 dias.

8.5.10Exigir um comprimento mínimo de senha de pelo menos sete caracteres.

8.5.11 Usar senhas que contenham caracteres alfanuméricos.

8.5.12 Não permitir que ninguém envie uma nova senha que seja a mesma de uma das quatro últimas senhas que tenha sido usada.

Senhas fortes são a primeira linha de defesa para uma rede, pois um indivíduo mal-intencionado muitas vezes primeiro tentará encontrar contas com senhas fracas ou inexistentes. O indivíduo mal-intencionado terá mais tempo para localizar essas contas fracas e comprometer uma rede ao estilo de um DI de usuário válido caso as senhas seja curtas, simples de serem adivinhadas ou válidas por muito tempo sem alterações. Senhas fortes podem ser forçadas e mantidas segundo estes requisitos ao ativar os recursos de segurança de senha e de conta que vêm com o sistema operacional (como o Windows, por exemplo), redes, bancos de dados e outras plataformas.

8.5.13 Limitar tentativas de acesso repetidas ao bloquear o ID do usuário após seis tentativas, no máximo.

Sem a implementação 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 usuário.

8.5.14Definir a duração do bloqueio para um mínimo de 30 minutos ou até o administrador ativar o ID do usuário.

Se uma conta estiver bloqueada em função de uma pessoa tentar continuamente adivinhar a senha, os controles para atrasar a reativação dessas contas bloqueadas evitarão que o indivíduo mal-intencionado continue a tentar adivinhar a senha (ele terá de parar por pelo menos 30 minutos até a conta ser reativada). Além disso, se a reativação precisar ser solicitada, a administração ou o help desk poderão validar que o proprietário da conta é a causa do bloqueio (por causa de erros de digitação).

8.5.15 Se uma sessão estiver ociosa por mais de 15 minutos, exigir que o usuário redigite a senha para reativar o terminal.

Quando os usuários se distanciam de uma máquina aberta com acesso a dados críticos de rede e dados do titular do cartão, essa máquina poderá ser usada por outras pessoas na ausência do usuário, resultando em acesso não autorizado à conta e/ou mau uso da conta.



8.5.16 Autenticar todos os acessos para qualquer banco de dados que contenha dados do titular do cartão, incluindo acesso por meio de aplicativos, administradores e todos os outros usuários.

Restringir acesso direto ou as consultas aos bancos de dados aos administradores do banco de dados.

Sem autenticação do usuário para acesso a bancos de dados e aplicativos, o potencial para acesso não autorizado ou malicioso aumenta, e esse acesso não pode ser registrado, pois o usuário não foi autenticado e, assim, não é conhecido pelo sistema. Além disso, o acesso ao banco de dados só deve ser concedido por meio de métodos programáticos (por exemplo, por meio de procedimentos armazenados), e não por acesso direto ao banco de dados por usuários finais (exceto para DBAs, que podem ter acesso direto ao banco de dados para as tarefas administrativas).


Requisito 9: Restringir o acesso físico aos dados d o titular do cartão

Qualquer acesso físico aos dados ou sistemas que armazenam dados do titular do cartão fornecem a oportunidade para as pessoas acessarem dispositivos ou dados e removerem sistemas ou cópias impressas, e deve ser restrito de forma adequada. Para as finalidades do Requisito 9, "funcionário" refere-se a funcionários que trabalham em período integral e meio-período, funcionários e equipes temporárias, e prestadores de serviços e consultores que atuem com presença física no endereço da entidade. Um “visitante” refere-se a um fornecedor, convidado de um funcionário, equipes de serviço ou qualquer pessoa que precise adentrar as dependências por um breve período, normalmente um dia, no máximo. "Mídia" refere-se a todas as mídias em papel ou eletrônicas que contêm dados do titular do cartão.


9.1Usar controles de entrada facilitados e adequados para limitar e monitorar o acesso físico aos sistemas no ambiente de dados do titular do cartão.

Sem controles de acesso físico, pessoas não autorizadas podem potencialmente ganhar acesso ao edifício e às informações confidenciais, e podem alterar as configurações do sistema, introduzir vulnerabilidades na rede ou destruir ou roubar equipamentos.

9.1.1 Usar câmeras de vídeo ou outros mecanismos de controle de acesso para monitorar o acesso físico individual a áreas confidenciais. Analisar os dados coletados e relacionar com outras entradas. Armazenar, por pelo menos três meses, a menos que seja restringido de outra forma pela lei.

Observação: “Á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 cartão. Isso exclui as áreas nas quais há somente terminais do ponto de venda presentes, como as áreas dos caixas em uma loja de varejo.

Ao investigar violações físicas, esses controles podem ajudar a identificar indivíduos que acessam fisicamente as áreas que armazenam os dados do titular do cartão. 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 cartão e áreas de armazenamento de grandes quantidades de dados do titular do cartão,

9.1.2 Restringir o acesso físico a pontos de rede acessíveis publicamente. Por exemplo, áreas acessíveis a visitantes não devem ter portas de rede ativadas a não ser que o acesso à rede seja autorizado explicitamente.

Restringir o acesso aos pontos de rede evita que indivíduos mal-intencionados se conectem em tomadas de rede prontamente disponíveis que pode lhes dar acesso aos recursos de rede internos. Pense em desativar as tomadas de rede enquanto elas não estiverem em uso e reativá-las somente enquanto forem necessárias. Em áreas públicas, como salas de conferência, crie redes privadas para permitir que fornecedores e visitantes acessem somente a Internet, e não sua rede interna.



9.1.3 Restringir o acesso físico a pontos sem fio de acesso, gateways, dispositivos portáteis, hardwares de comunicação/rede e linhas de telecomunicação.

Sem segurança no acesso a componentes e dispositivos wireless, indivíduos mal-intencionados podem usar os dispositivos wireless da sua empresa que não estejam sendo utilizados para acessar os recursos de rede ou até para conectar seus próprios dispositivos à rede wireless para obter acesso não autorizado. Além disso, fazer a segurança dos materiais de comunicação e rede evita que usuários mal-intencionados interceptem o trafego da rede ou conectem-se fisicamente seus próprios dispositivos em seus recursos de rede com fio.

Pense em colocar pontos de acesso wireless, gateways e material de comunicação/redes em áreas de armazenamento seguro, como dentro de armários trancados ou salas de servidores. Para redes wireless, assegure-se de que a criptografia robusta está ativada. Ative o bloqueio automático de dispositivo em dispositivos portáteis wireless após um período longo parado e defina um uma senha nos dispositivos quando eles forem iniciados.

9.2 Desenvolver procedimentos para diferenciar facilmente os funcionários dos visitantes, principalmente nas áreas onde os dados do titular do cartão podem ser acessados.

Sem sistemas de crachás e controles de porta, usuários não autorizados e mal-intencionados podem facilmente obter acesso às instalações para roubar, desativar, interromper ou destruir sistemas críticos e dados do titular do cartão. Para o controle ideal, pense em implementar um sistema de acesso por crachá ou carrão dentro e fora das áreas de trabalho que contenham dados do titular do cartão.

Identificar visitantes autorizados para que sejam facilmente distinguidos dos funcionários do local evita que os visitantes não autorizados acessem áreas contendo dados do titular do cartão.

9.3 Certificar-se de que todos os visitantes são identificados da seguinte forma:

O controle de visitantes é importante para reduzir a possibilidade de pessoas não autorizadas e mal-intencionadas obterem acesso a suas instalações (e possivelmente aos dados do titular do cartão).

9.3.1 Autorizados antes de adentrar as áreas onde os dados do titular do cartão são processados ou mantidos.

9.3.2 Recebem um token físico (por exemplo, um crachá ou dispositivo de acesso) que expira e que identifica os visitantes como não sendo funcionários.

9.3.3 É solicitado que os visitantes apresentem o token físico antes de sair das dependências ou na data do vencimento

Os controles de visitantes são importantes para garantir que eles só entrem em áreas onde são autorizados e que sejam identificados como visitantes, de forma que os funcionários possam monitorar suas atividades e que o acesso esteja restrito a somente a duração da visita em si.



9.4 Usar um registro de visitantes para manter um monitoramento físico da auditoria da atividade do visitante. Documente no registro o nome do visitante, a empresa representada e o funcionário que autoriza o acesso físico. Armazene esse registro por pelo menos três meses, a menos que seja restringido de outra forma pela lei.

Um log de visitantes, documentando as informações mínimas sobre eles, é de manutenção fácil e barata e, durante uma possível violação de dados, ajuda a identificar acesso físico a um edifício ou a uma sala e um possível acesso aos dados do titular do cartão. Pense em implementar logs na entrada às instalações e, especialmente, em zonas onde estejam presentes os dados do titular do cartão.

9.5 Armazene back-ups de mídia em um local seguro, preferencialmente em outras instalações, como um lugar alternativo de back-up ou uma instalação comercial de armazenamento. Analisar a segurança do local pelo menos uma vez por ano.

Se armazenados em um local não protegido, os backups que contêm dados do titular do cartão podem ser facilmente perdidos, roubados ou copiados com más intenções. Para armazenamento protegido, pense em contratar uma empresa de armazenamento de dados comerciais OU, para empresas menores, usar um cofre em um banco.

9.6 Proteja toda a mídia fisicamente.

Os dados do titular do cartão estarão suscetíveis a visualização, cópia ou digitalização não autorizada caso estejam desprotegidos enquanto estiverem em mídia portátil, forem impressos ou deixados na mesa de alguém.

9.7 Manter o controle rigoroso quanto à distribuição interna ou externa de qualquer tipo de mídia, incluindo o seguinte:

Procedimentos e processos para proteger os dados do titular do cartão em mídias distribuídas a usuários internos e/ou externos. Sem tais procedimentos, os dados poderão ser perdidos ou roubados e usados para fins fraudulentos.

9.7.1 Classificar a mídia para que a confidencialidade dos dados possa ser determinada.

É importante que a mídia seja identificada para que seu status de classificação possa ser discernível. A mídia não identificada como confidencial pode não ser protegida adequadamente ou ser roubada.

9.7.2 Enviar a mídia via mensageiro seguro ou outro método de entrega que pode ser monitorado com precisão.

A mídia pode ser perdida ou roubada se for enviada por um método não rastreável, como remessa postal. Use os serviços de um mensageiro seguro para entregar mídias que contenham dados do titular do cartão, de forma que você possa usar os sistemas de rastreamento para manter inventário e localização dos envios.

9.8 Certificar-se de que a gerência aprova quaisquer e todas as mídias contendo dados do titular do cartão que são movidas de uma área segura (principalmente quando as mídias forem distribuídas às pessoas).

Os dados do titular do cartão que saem de áreas seguras sem um processo aprovado pela gerência podem levar a dados perdidos ou roubados. Sem um processo firme, os locais de mídia não são rastreados e não existe um processo para onde os dados vão ou a forma como eles são protegidos.

9.9 Manter um controle rigoroso sobre o armazenamento e a acessibilidade das mídias que contêm dados do titular do cartão.

Sem métodos cuidadosos de inventário e controles de armazenamento, mídias roubadas ou ausentes podem passar despercebidas por tempo indefinido.

9.9.1 Manter adequadamente os registros do inventário de todas as mídias e realizar inventários das mídias pelo menos uma vez por ano.

Se a mídia não passar por inventário, mídias roubadas ou perdidas podem passar despercebidas por bastante tempo.



9.10 Destruir as mídias que contêm dados do titular do cartão quando eles não forem mais necessários por motivos de negócios ou legais, conforme se segue:

9.10.1 Triturar, incinerar ou amassar materiais impressos para que os dados do titular do cartão não possam ser recuperados.

9.10.2Tornar os dados do titular do cartão nas mídias eletrônicas irrecuperáveis para que esses dados não possam ser reconstituídos.

Se as etapas não forem seguidas par destruir as informações contidas em discos rígidos, drives portáteis, CD/DVDs ou papéis antes do descarte, indivíduos mal-intencionados poder estar aptos a recuperar as informações da mídia descartada, levando ao comprometimento dos dados. Por exemplo: indivíduos mal-intencionados podem usar uma técnica conhecida como “dumpster diving”, na qual eles pesquisam em lixeiras e usam as informações encontradas para iniciar um ataque.

Exemplos de métodos para destruir mídias eletrônicas incluem limpeza segura, desmagnetização ou destruição física (como esmagar ou triturar os discos rígidos).


Orientação para os Requisitos 10 e 11: Monitorar e Testar as Redes Regularmente

Requisito 10: Acompanhar e monitorar todos os acess os com relação aos recursos da rede e aos dados do titular do cartão

Mecanismos de registro e a capacidade de monitorar as atividades dos usuários são fundamentais na prevenção, detecção ou minimização do impacto do comprometimento dos dados. A presença de registros em todos os ambientes permite o monitoramento, o alerta e a análise completa quando algo dá errado. Determinar a causa de um comprometimento é muito difícil, se não impossível, sem registros das atividades do sistema.


10.1 Definir um processo para vincular todos os acessos aos componentes do sistema (principalmente o acesso realizado com privilégios administrativos como raiz) para cada usuário individual.

É essencial ter um processo ou sistema que vincule o acesso do usuário aos componentes do sistema acessados e, mais particularmente, àqueles usuários com privilégios administrativos. Esse sistema gera logs de auditoria e oferece a capacidade de rastrear as atividades suspeitas de um usuário específico. Equipes forenses pós-incidente dependem muito desses logs para iniciar a investigação.

Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para recuperar os seguintes eventos:

Gerar trilhas de auditoria de atividades suspeitas alerta o administrador do sistema, envia dados a outros mecanismos de monitoramento (como sistemas de detecção de intrusão) e fornece uma trilha do histórico para acompanhamento pós-acidente. Registrar os seguintes eventos permite que uma empresa identifique e rastreie atividades potencialmente mal-intencionadas.

10.2.1 Todos os acessos individuais aos dados do titular do cartão

Indivíduos mal-intencionados poderiam tomar conhecimento de uma conta de usuário com acesso aos sistemas no CDE ou poderiam criar uma conta nova, não autorizada, para acessar os dados do titular do cartão. Um registro de todos os acessos individuais para os dados do titular do cartão pode identificar quais contas podem ter sido comprometidas ou usadas inadequadamente.

10.2.2 Todas as ações desempenhadas por qualquer pessoa com privilégios raiz ou administrativos

Contas com privilégios maiores, como "administrador" ou "raiz", têm o potencial para impactar fortemente a segurança ou a funcionalidade operacional de um sistema. Sem o registro das atividades executadas, uma empresa não é capaz de rastrear qualquer problema resultante de algum erro administrativo ou uso inadequado de privilégios de volta à ação específica e ao indivíduo.

10.2.3 Acesso a todas as trilhas de auditoria Usuários mal-intencionados tentam frequentemente alterar os registros de auditoria para ocultar suas ações e um registro de acesso permite que uma empresa rastreia quaisquer inconsistências ou potenciais adulterações dos registros para uma conta individual.

10.2.4 Tentativas inválidas de acesso lógico

Indivíduos mal-intencionados na rede muitas vezes executam várias tentativas de acesso nos sistemas alvejados. Várias tentativas inválidas de login podem ser um indicador de tentativas de um usuário não autorizado "forçar" ou adivinhar uma senha.



10.2.5 Uso de mecanismos de identificação e autenticação Sem saber quem estava registrado no momento de um incidente, é impossível identificar as contas que podem ter sido usadas. Além disso, usuários mal-intencionados tentam manipular os controles de autenticação com o objetivo de contorná-los ou imitar uma conta válida. Atividades incluindo, mas não limitadas a, escalação de privilégio ou alterações nas permissões de acesso podem indicar uso não autorizado de mecanismos de autenticação.

10.2.6 Inicialização dos registros de auditoria Desativar os registros de auditoria antes de realizar atividades ilícitas é uma meta comum a usuários mal-intencionados que desejam evitar ser detectados. A inicialização dos registros de auditoria podem indicar que a função de registro foi desativada.

10.2.7 Criação e exclusão de objetos do nível do sistema Softwares mal-intencionados, como malwares, frequentemente criam ou substituem objetos no nível do sistema no sistema de destino para controlar uma função ou operação nesse sistema.

Consulte a seção Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS para obter definições de "objetos no nível 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 Identificação do usuário

10.3.2 Tipo de evento

10.3.3 Data e horário

10.3.4 Indicação 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 auditáveis em 10.2, um possível comprometimento poderá ser rapidamente identificado, e com detalhes suficientes para saber quem, o que, onde, quando e como.



10.4 Usando tecnologia de sincronização de tempo, sincronize todos os relógios e horários críticos do sistema e assegure-se de que os seguintes itens sejam implementados para adquirir, distribuir e armazenar horários.

Observação : Um exemplo de tecnologia de sincronização de tempo é o Network Time Protocol (NTP).

10.4.1 Sistemas críticos têm o horário correto e consistente

10.4.2 Os dados de horário são protegidos

10.4.3 As definições de horário são recebidas de fontes de horário aceitas pelo setor

A tecnologia para sincronização do horário é usada para sincronizar os relógios. Quando implementada corretamente, essa tecnologia pode sincronizar relógios em um grande quantidade de sistemas com uma fração de segundo de um para outro. Alguns problemas que podem ocorrer quando os relógios não são sincronizados adequadamente incluem, mas não se limitam a tornar difícil (se não impossível) comparar arquivos de registro de diferentes sistemas, estabelecer uma sequência exata de eventos (cruciais para análise forense no caso de uma violação) e evitar que protocolos criptográficos (como SSH) dependentes de horário absoluto funcionem adequadamente. Para equipes de forenses pós-incidente, a precisão e a consistência do horário ao longo de todos os sistemas e a hora de cada atividade são essenciais para determinar a forma como os sistemas foram comprometidos.

Para garantir um horário consistente, deve haver idealmente somente alguns servidores de horário internos (centrais) dentro de uma entidade. Esses servidores recebem o UTC (Tempo Universal Coordenado) diretamente de servidores de horário externos, conhecidos e confiáveis, por meio de rádio especial, satélites de GPS ou outra fonte de rede externa e se emparelham para garantir que mantenham o horário preciso. Outros sistemas recebem, então, o horário desses servidores.

Se um indivíduo mal-intencionado tiver entrado na rede, ele muitas vezes tentará mudará os carimbos de data e hora de suas ações dentro dos logs de auditoria para evitar a detecção da atividade. Um indivíduo mal intencionado também pode tentar alterar diretamente o relógio de um componente do sistema para ocultar sua presença - por exemplo, alterando o relógio do sistema para um horário mais cedo. Por estes motivos, é importante que o horário seja preciso em todos os sistemas e que os dados de horário sejam protegidos contra acessos e alterações não autorizados. Dados de horário incluem os parâmetros e os métodos usados para definir o relógio de cada sistema.

Mais informações sobre NTP podem ser encontradas em www.ntp.org, inclusive informações sobre horário, padrões de horário e servidores.

10.5 Proteger as trilhas de auditoria para que não possam ser alteradas.

Muitas vezes um indivíduo mal-intencionado que entra em uma rede tenta editar os logs de auditoria para ocultar suas atividades. Sem proteção adequada dos logs de auditoria, sua conclusão, precisão e integridade não poderão ser garantidas, e os logs de auditoria poderão ser inutilizados como ferramenta de investigação após um comprometimento.



10.5.1 Limitar a exibição de trilhas de auditoria às pessoas que têm uma necessidade relacionada à função.

10.5.2 Proteger os arquivos de trilha de auditoria de modificações não autorizadas.

10.5.3 Fazer imediatamente o back-up dos arquivos de trilha de auditoria em um servidor de registros centralizado ou mídias que sejam difíceis de alterar.

10.5.4 Documentar registros quanto às tecnologias externas em um servidor de registros na LAN interna.

Uma proteção adequada dos logs de auditoria inclui forte controle de acesso (limitar o acesso aos logs baseado somente na “necessidade de divulgação”) e uso da segregação interna (para deixar os logs mais difíceis 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 é diminuído, pois eles estão mais seguros dentro da rede interna.

10.5.5 Usar softwares de monitoramento da integridade dos arquivos ou de detecção de alterações nos registros para assegurar que os dados de registro existentes não possam ser alterados sem gerar alertas (embora os novos dados que estejam sendo adicionados não gerem um alerta).

Os sistemas de monitoramento da integridade do arquivo verificam as alterações nos arquivos críticos e notificam quando essas alterações são observadas. Para fins de monitoramento da integridade do arquivo, uma entidade normalmente monitora os arquivos que não mudam regularmente, mas que, quando alterados, indicam um possível comprometimento. Para arquivos de registro (que não mudam com frequência), o que deve ser monitorado é, por exemplo, quando um arquivo de log é excluído, cresce rapidamente ou diminui significativamente, e quaisquer outras indicações de que um indivíduo mal-intencionado mexeu indevidamente no arquivo de log. Existem ferramentas de prateleira e de código aberto disponíveis para monitoramento da integridade do arquivo.

10.6 Analisar os registros de todos os componentes do sistema pelo menos diariamente. As análises dos registros incluem aqueles servidores que desempenham funções de segurança como sistema de detecção de invasões (IDS) e servidores de protocolo de autenticação, autorização e inventário (AAA) (por exemplo, RADIUS).

Observação: As ferramentas de coleta, análise e alerta dos registros podem ser usadas para estar em conformidade com o Requisito 10.6

Várias violações ocorrem durante dias ou meses antes de serem detectadas. A verificação diária dos logs minimiza a quantidade de tempo e exposição de uma violação em potencial. O processo de análise do log não precisa ser manual. Especialmente para as entidades com um grande número de servidores, pense em usar ferramentas de coleta, análise e alerta de log.

10.7 Manter um histórico da trilha de auditoria por pelo menos um ano, com um mínimo de três meses imediatamente disponível para análise (por exemplo, on-line, arquivado ou recuperável 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 histórico de log suficiente para determinar melhor a quantidade de tempo de uma potencial violação e os possíveis sistemas afetados. Ao ter três meses de logs imediatamente disponíveis, uma entidade pode rapidamente identificar e minimizar o impacto da violação de dados. O armazenamento de tarjas de backup fora do local pode resultar em cronogramas mais longos para restaurar dados, executar análises e identificar sistemas ou dados afetados.


Requisito 11: Testar regularmente os sistemas e pro cessos de segurança

As vulnerabilidades estão sendo continuamente descobertas por indivíduos mal-intencionados e pesquisadores, e são apresentadas por novos softwares. Os componentes do sistema, processos e softwares personalizados devem ser testados com frequência para assegurar que os controles de segurança continuem refletindo um ambiente em transformação.


11.1 Teste para a presença de pontos de acesso sem fio e detectar pontos de acesso sem fio não autorizados trimestralmente.

Observação: Métodos que podem ser usados no processo incluem mas não se limitam a varreduras de rede sem fio, inspeções físicas/lógicas de componentes e de infraestrutura do sistema, controle de acesso à rede (NAC) ou IDS/IPS sem fio.

Qualquer método usado deve ser suficiente para detectar e identificar qualquer dispositivo não autorizado.

A implementação e/ou exploração da tecnologia wireless dentro de uma rede é um dos caminhos mais comuns para usuários mal-intencionados obterem acesso à rede e aos dados do titular do cartão. 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 fácil e invisível.

Dispositivos sem fio não 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 não autorizados podem resultar em um ponto não autorizado de acesso ao ambiente.

Em função da facilidade com que o ponto de acesso wireless pode ser conectado a uma rede, da dificuldade em detectar sua presença e do risco cada vez maior apresentado por dispositivos wireless não autorizados, esses processos devem ser executados até quando existir uma política proibindo o uso da tecnologia wireless.

O tamanho e a complexidade de um ambiente privado determinarão as ferramentas e os processos adequados a serem usados para fornecer garantia suficiente de que um ponto de acesso sem fio intruso não tenha sido instalado no ambiente.

Por exemplo: No caso de um único quiosque de revenda autônomo em um shopping, onde todos os componentes de comunicação estão contidos em estojos anti-adulteração e indicadores de adulteração, executando inspeções físicas detalhadas no próprio 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 vários nós (como em uma grande loja de revenda, um call center, sala de servidor ou centro de dados), torna-se mais difícil executar uma inspeção física detalhada devido ao número de componentes do sistema e de pontos de rede onde um dispositivo de acesso sem fio intruso poderia ser instalado ou ocultado. Nesse caso, vários métodos podem ser combinados para atender ao requisito, como executar inspeções físicas no sistema em conjunto com os resultados de um analisador sem fio.

Soluções de controle de acesso de rede (NAC) podem executar o gerenciamento de autenticação e configuração do dispositivo para evitar que sistemas não autorizados conectem-se à rede, ou que dispositivos não autorizados conectem-se a sistemas autorizados na rede.

Uma organização 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 não autorizado. Um IDS/IPS wireless deve ser configurado para gerar automaticamente um alerta, mas o plano também deve documentar procedimentos de resposta caso um dispositivo não autorizado seja


Requisito Orientação detectado durante uma varredura wireless manual.

11.2 Executar varreduras quanto às vulnerabilidades das redes internas e externas pelo menos trimestralmente e após qualquer mudança significativa na rede (como instalações de novos componentes do sistema, mudanças na topologia da rede, modificações das normas do firewall, upgrades de produtos).

Observação: Não será necessário que quatro varreduras trimestrais aprovadas sejam concluídas 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 políticas e procedimentos documentados que requerem a sequência de varreduras trimestrais e 3) as vulnerabilidades observadas nos resultados da varredura tenham sido corrigidas conforme mostrado em uma nova varredura. Nos anos seguintes após a análise inicial do PCI DSS, quatro varreduras trimestrais aprovadas devem ter ocorrido.

Uma varredura de vulnerabilidade é uma ferramenta automatizada executada em dispositivos de rede interna e externa e servidores, feita para expor possíveis vulnerabilidades e identificar portas em redes que podem ser encontradas e exploradas por indivíduos mal-intencionados. Quando esses pontos fracos são identificados, a entidade os corrige e repete a verificação para chegar se as vulnerabilidades foram mesmo corrigidas.

No momento da avaliação inicial do PCI DSS pela entidade, é possível que quatro varreduras trimestrais ainda não tenham sido realizadas. Se o resultado da verificação mais recente atingir os critérios para aprovação e houver políticas e procedimentos para varreduras trimestrais futuras, o objetivo desse requisito estará atingido. Caso essas condições sejam atendidas, não é necessário postergar uma avaliação “no local” para este requisito em função da falta de quatro varreduras.



11.2.1 Realizar varreduras por vulnerabilidade interna trimestralmente.

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 hábil reduz as chances de exploração de uma vulnerabilidade e o comprometimento potencial de um componente do sistema ou de dados do titular do cartão.

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, é possível que uma entidade possa não ter limpado consistentemente as varreduras de vulnerabilidades internas. A intenção é que a entidade tenha um programa robusto de gerenciamento de vulnerabilidade instalado para resolver vulnerabilidades observadas em um período de tempo razoável. No mínimo 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 não deve ser responsável 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 Segurança de Dados do Setor de Cartões de Pagamento (PCI SSC).

Observação: As varreduras trimestrais quanto às vulnerabilidades externas devem ser realizadas por um Fornecedor de Varreduras Aprovado (ASV) qualificado pelo Conselho de Segurança de Dados do Setor de Cartões de Pagamento (PCI SSC). As varreduras realizadas após as alterações na rede devem ser desempenhadas pela equipe interna da empresa.

Como redes externas têm 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 critérios de varredura e relatórios definidos pelo PCI SSC nos Procedimentos de varredura de segurança.

11.2.3 Realize varreduras internas e externas após qualquer mudança significativa.

Observação: As varreduras realizadas após as alterações devem ser desempenhadas pela equipe interna da empresa.

Varrer um ambiente depois de qualquer alteração significativa ter sido feita assegura que todas as alterações foram completamente adequadas para que a segurança do ambiente não tenha sido comprometida como resultado da alteração. Pode não ser necessário varrer o ambiente completo após uma alteração. No entanto, todos os componentes afetados pela alteração precisaram ser varridos.



11.3 Realizar testes de penetração externos e internos pelo menos uma vez por ano e após qualquer upgrade ou modificação significativa na infra-estrutura ou nos aplicativos (como um upgrade no sistema operacional, uma sub-rede adicionada ao ambiente ou um servidor da Web adicionado ao ambiente). Esses testes de penetração devem incluir o seguinte:

11.3.1 Testes de penetração na camada da rede

11.3.2 Testes de penetração na camada do aplicativo.

A intenção de um teste de penetração é estimular uma situação de ataque real com o objetivo de identificar até onde um transgressor conseguiria penetrar em um ambiente. Isso permite que a entidade tenha mais compreensão sobre sua potencial exposição e desenvolva uma estratégia para se defender de ataques.

Um teste de penetração difere de uma varredura de vulnerabilidade, uma vez que o teste de penetração é um processo ativo que pode incluir a exploração de vulnerabilidades identificadas. Normalmente, executar uma varredura de vulnerabilidade é um dos primeiros passos que um testador de penetração realizará para formar uma estratégia de ataque, mesmo que não seja o único passo. Mesmo que uma varredura de vulnerabilidade não detecte nenhuma vulnerabilidade conhecida, o testador de penetração irá normalmente tomar conhecimento suficiente sobre o sistema para identificar possíveis lacunas de segurança.

O teste de penetração é 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 explorações 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 preparação para um novo ataque baseado nos recursos a que o servidor tem acesso. Dessa forma, o testador é capaz de simular os métodos utilizados por um transgressor para identificar qualquer área de fraquezas potenciais no ambiente que precisa ser abordado.



11.4 Usar sistemas de detecção de invasão e/ou sistemas de prevenção contra invasão para monitorar todo o tráfego no ambiente de dados do titular do cartão e alertar as equipes sobre comprometimentos suspeitos.

Manter todos os mecanismos de detecção e prevenção contra invasões, diretrizes e assinaturas atualizados.

A detecção de intrusos e/ou prevenção de sistemas (IDS/IPS) comparam o tráfego 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 detecção de atividade não autorizada por meio dessas ferramentas, os ataques (ou mau uso) de recursos de computador podem passar despercebidos em tempo real. Os alertas de segurança gerados por essas ferramentas devem ser monitorados, de forma que as tentativas de intrusão possam ser interrompidas.

Dispositivos IDS/IPS devem ser implementados de maneira a monitorar o tráfego de entrada e saída no perímetro do CDE, além dos pontos críticos no CDE. Os pontos críticos no CDE podem incluir servidores de bancos de dados que armazenam dados dos titulares dos cartões, 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 avaliação de riscos.

Enquanto vários dispositivos IDS/IPS são capazes de monitorar diversos pontos do CDE a partir de um único dispositivoe, é importante lembrar da exposição que pode ocorrer caso esse único dispositivo falhe. Portanto, é importante incorporar a redundância adequada na infraestrutura IDS/IPS.

Existem milhares de tipos de comprometimento, e vários outros são descobertos diariamente. Assinaturas e mecanismos de varredura antigos em dispositivos IDS/IPS não oferecem a capacidade de identificar novas vulnerabilidades que podem levar a uma violação não detectada. Os fornecedores desses produtos oferecem atualizações frequentes, inclusive diárias, que devem ser avaliadas e aplicadas regularmente.



11.5 Implementar softwares de monitoramento da integridade dos arquivos para alertar as equipes quanto à modificação não autorizada de arquivos críticos do sistema, arquivos de configuração ou arquivos de conteúdo; e configurar o software para realizar comparações de arquivos críticos pelo menos semanalmente.

Observação: Para fins de monitoramento da integridade dos arquivos, os arquivos críticos normalmente são aqueles que não são alterados com frequência, mas sua modificação poderia indicar um comprometimento do sistema ou um risco de comprometimento. Normalmente, os produtos de monitoramento da integridade dos arquivos vêm pré-configurados com arquivos críticos para o sistema operacional relacionado. Outros arquivos críticos, como aqueles para os aplicativos personalizados, devem ser avaliados e definidos pela entidade (ou seja, o comerciante ou prestador de serviços).

Os sistemas de monitoramento da integridade do arquivo (FIM) verificam as alterações nos arquivos críticos e notificam quando essas alterações são detectadas. Existem ferramentas de prateleira e de código aberto disponíveis para monitoramento da integridade do arquivo. Se não implementadas corretamente e se o resultado do FIM não for monitorado, um indivíduo mal-intencionado pode alterar o conteúdo do arquivo de configuração, os programas do sistema operacional ou os executáveis do aplicativo. Essas alterações não autorizadas, se não detectadas, podem tornar os controles de segurança ineficazes e/ou resultar no roubo dos dados do titular do cartão sem impacto perceptível no processamento normal.


Orientação para o Requisito 12: Manter uma Política de Segurança de Informações

Requisito 12: Manter uma política que aborde a segu rança das informações para todas as equipes.

Uma política de segurança sólida determina o tom da segurança para toda a empresa e informa aos funcionários o que é esperado deles. Todos os funcionários devem estar cientes da confidencialidade dos dados e de suas responsabilidades para protegê-los. Para as finalidades do Requisito 12, "funcionário" refere-se a funcionários que trabalham em período integral e meio-período, funcionários e equipes temporárias, e prestadores de serviços e consultores que "residem" no endereço da entidade ou têm acesso ao ambiente de dados do titular do cartão.


12.1 Definir, publicar, manter e disseminar uma política de segurança que realize o seguinte:

12.1.1 Atende a todos os requisitos do PCI DSS.

A política de segurança de informações de uma empresa cria um guia para implementar as medidas de segurança para proteger seus ativos mais valiosos. Uma política de segurança sólida determina o tom da segurança para toda a empresa e informa aos funcionários o que é esperado deles. Todos os funcionários devem estar cientes da confidencialidade dos dados e de suas responsabilidades para protegê-los.

12.1.2 Inclui um processo anual que identifica ameaças e vulnerabilidades, e resulta em uma avaliação de risco formal. (Exemplos de metodologias de avaliação de risco incluem mas não são limitados a OCTAVE, ISO 27005 e NIST SP 800-30.)

Uma avaliação de riscos permite a uma organização identificar ameaças e as vulnerabilidades relacionadas que têm o potencial de causar um impacto negativo em seus negócios. Os recursos podem então ser alocados com eficácia para implementar controles que reduzem a probabilidade e/ou o impacto potencial da ameaça em questão.

Realizar avaliações de riscos anuais permite à organização manter-se atualizada com as mudanças organizacionais e ameaças, tendências e tecnologias em evolução,

12.1.3 Inclui uma análise pelo menos uma vez por ano e atualizações quando o ambiente é modificado.

As ameaças de segurança e os métodos de proteção evoluem rapidamente ao longo do ano. Sem atualizar a política de segurança para refletir essas alterações, agora são abordadas novas medidas de proteção para lutar contra essas ameaças.

12.2 Desenvolver procedimentos de segurança operacional diariamente que estejam em conformidade com os requisitos nessa especificação (por exemplo, procedimentos de manutenção da conta do usuário e procedimentos de análise de registros).

Procedimentos diários de segurança operacional agem como “instruções de mesa” para os trabalhadores usarem nas atividades diárias de manutenção e administração do sistema. Os procedimentos de segurança operacional não documentados levam a trabalhadores que não estão cientes do escopo total de suas tarefas, processos que não podem ser repetidos com facilidade por novos trabalhadores e possíveis falhas nesses processos que podem permitir que um indivíduo mal-intencionado obtenha acesso a sistemas e recursos críticos.



12.3 Desenvolver políticas de utilização para tecnologias críticas voltadas aos funcionários (por exemplo, tecnologias de acesso remoto, tecnologias sem fio, mídia eletrônica removível, laptops, dados pessoais/assistentes digitais (PDAs), uso de e-mail e uso da Internet) para definir o uso adequado dessas tecnologias para todos os funcionários e prestadores de serviços. Assegurar que essas políticas de utilização exijam o seguinte:

As políticas de uso por funcionários podem ou proibir o uso de determinados dispositivos e outras tecnologias, se for essa a política da empresa, ou fornecer orientação para os funcionários quanto ao uso e à implementação corretos. Se não estiverem em vigor políticas de uso, os funcionários podem usar as tecnologias na violação da política da empresa, permitindo que indivíduos mal-intencionados consigam acesso a sistemas críticos e dados do titular do cartão. Um exemplo pode ser configurar sem saber redes wireless sem segurança. Para garantir que os padrões da empresa sejam seguidos e que somente as tecnologias aprovadas sejam implementadas, pense em confinar a implementação somente às equipes operacionais e não permitir que funcionários não especializados/gerais instalem essas tecnologias.

12.3.1 Explicitar a aprovação por partes autorizadas

Sem exigir aprovação adequada da gestão para implementação dessas tecnologias, um funcionário pode implementar inocentemente uma solução para uma necessidade de negócios percebida, mas também abrir um grande buraco que deixe os sistemas e dados críticos vulneráveis a indivíduos mal-intencionados.

12.3.2 Autenticação para o uso da tecnologia Se a tecnologia for implementada sem autenticação adequada (IDs de usuário e senhas, tokens, VPNs, etc.), indivíduos mal-intencionados podem facilmente usar essa tecnologia desprotegida para acessar sistemas críticos e dados do titular do cartão.

12.3.3 Uma lista de todos esses dispositivos e equipes com acesso

12.3.4 Identificação dos dispositivos com proprietário, informações de contato e finalidade

Os indivíduos mal-intencionados podem violar a segurança física e colocar seus próprios dispositivos na rede como “back door”, Um inventário preciso, com rótulos adequados nos dispositivos, permite uma rápida identificação das instalações não aprovadas. Pense em criar uma convenção de nomes oficiais para dispositivos e rotule e registre todos os dispositivos de forma coerente com os controles de inventário criados. Rótulos lógicos podem ser empregados, com informações como códigos que podem ser associados ao proprietário, a informações de contato e à sua finalidade.

12.3.5 Usos aceitáveis da tecnologia

12.3.6 Locais de rede aceitáveis quanto às tecnologias

12.3.7Lista dos produtos aprovados pela empresa

Ao definir o uso corporativo aceitável e a localização dos dispositivos e da tecnologia aprovados pela empresa, a empresa fica mais capaz de gerenciar e controlar falhas nas configurações e nos controles operacionais, a fim de garantir que não tenha sido aberta uma “back door” para um indivíduo mal-intencionado obter acesso a sistemas críticos e a dados do titular do cartão.

12.3.8 Desconexão automática das sessões quanto às tecnologias de acesso remoto após um período específico de inatividade

12.3.9 Ativação de tecnologias de acesso remoto para fornecedores e parceiros de negócio somente quando lhes for

As tecnologias de acesso remoto são frequentes "back doors" a recursos críticos e a dados do titular do cartão. Ao desconectar as tecnologias de acesso remoto quando não estiverem em uso (por exemplo, aquelas usadas para dar suporte aos sistemas pelo POS ou por outros fornecedores), o acesso e os riscos à rede são minimizados. Pense em usar controles para desconectar dispositivos depois de 15 minutos de inatividade. Veja também o Requisito 8.5.6 para saber mais sobre


Requisito Orientação necessário, com desativação imediata após o uso esse tópico.

12.3.10 Para funcionários que acessam os dados do titular do cartão por meio de tecnologias de acesso remoto, proibir a cópia, a transferência e o armazenamento dos dados do titular do cartão em discos rígidos locais e mídias eletrônicas removíveis, exceto se explicitamente autorizado para uma necessidade comercial definida.

Para garantir que os funcionários estejam cientes de suas responsabilidades de não armazenar nem copiar dados do titular do cartão para o computador pessoal local ou outras mídias, sua empresa deve contar com uma política que proíba 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 personnel’s environment is now considered a part of the organization’s cardholder data environment.

12.4 Certificar-se de que a política e os procedimentos de segurança definem claramente as responsabilidades quanto à segurança das informações para todos os funcionários.

Sem papéis e responsabilidades claramente definidos e atribuídos, pode haver uma interação inconsistente com o grupo de segurança, levando a uma implementação não protegida de tecnologias ou ao uso de tecnologias não protegidas ou desatualizadas.

12.5 Atribuir a um indivíduo ou a uma equipe as seguintes responsabilidades de gerenciamento da segurança das informações:

12.5.1 Definir, documentar e distribuir políticas e procedimentos de segurança.

12.5.2 Monitorar e analisar os alertas e as informações de segurança, e distribuir para as equipes apropriadas.

12.5.3 Definir, documentar e distribuir procedimentos de resposta e escalação de incidentes de segurança para assegurar que todas as situações sejam abordadas de modo oportuno e eficiente.

12.5.4 Administrar as contas dos usuários, incluindo adições, exclusões e modificações

12.5.5 Monitorar e controlar todos os acessos aos dados.

Cada pessoa ou equipe com responsabilidades pela gestão da segurança das informações deve estar claramente ciente das responsabilidades e das tarefas relacionadas por meio da política específica. Sem essa responsabilidade, falhas nos processos podem dar acesso a recursos críticos ou dados do titular do cartão.

12.6Implementar um programa formal de conscientização da segurança para conscientizar todos os funcionários sobre a importância da segurança dos dados do titular do cartão.

Se os usuários não forem treinados sobre as responsabilidades de segurança, as proteções e os processos que forem implementados poderão se tornar ineficazes por causa de erros do funcionário ou ações não intencionais.



12.6.1 Instruir os funcionários quando da contratação e pelo menos uma vez por ano.

Observação: Os métodos podem variar dependendo da função de cada funcionário e do nível de acesso aos dados do titular do cartão.

Se o programa de conscientização de segurança não incluir sessões de atualização anuais, os principais processos e procedimentos de segurança poderão ser esquecidos ou ignorados, resultando em exposição dos recursos críticos e dos dados do titular do cartão. O foco e a profundidade do treinamento inicial e de atualização podem variar de acordo com a função dos funcionários e devem ser personalizados conforme necessário para o público específico. Por exemplo, sessões para administradores de bancos de dados podem concentrar-se em processos e controles técnicos específicos, enquanto o treinamento para os caixas pode ser focado procedimentos seguros de transações

Considere incluir atualizações constantes de conscientização para manter os funcionários atualizados com os procedimentos e as políticas atuais. O método de instrução também deve variar de acordo com o público específico ou o treinamento sendo apresentado. Por exemplo, o treinamento inicial e anual pode ser apresentado em uma sessão formal de treinamento prático em um computador, enquanto as atualizações periódicas podem ser apresentadas por e-mail, postêres, boletins informativos etc.

12.6.2 Exigir que os funcionários reconheçam, pelo menos uma vez por ano, que leram e compreenderam a política e os procedimentos de segurança da empresa.

por escrito ou eletronicamente) ajuda a garantir que eles tenham lido e entendido as políticas e os procedimentos de segurança e que eles tenham se comprometido a obedecer a essas políticas.

12.7 Analise bem os potenciais funcionários antes de contratar para minimizar o risco de ataques a partir de fontes internas. (Exemplos de verificações da formação incluem o histórico do emprego anterior, ficha criminal, histórico de crédito e verificações das referências.)

Observação : Para os funcionários como caixas de loja que têm acesso somente a um número do cartão por vez ao viabilizar uma transação, esse requisito é apenas uma recomendação.

Executar investigações de histórico completas antes de contratar funcionários que se esperam ter acesso aos dados do titular do cartão reduz o risco do uso não autorizado de PANs e outros dados do titular do cartão por pessoas com históricos questionáveis ou criminais. Espera-se que uma empresa tenha uma política e um processo para verificações de histórico, incluindo o próprio processo de decisão para o qual os resultados da verificação do histórico tenham impacto sobre as decisões de contratação (e qual seria esse impacto).

Para ser eficaz, o nível de verificação do histórico 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 poderão garantir verificações de background mais detalhadas do que os cargos que exigirem menos responsabilidade e possuírem nível inferior de acesso. Também poderá não ser adequado ao processo cobrir transferências internas, em que as pessoas que ocuparem cargos de risco mais baixo e que ainda não tiverem passado por uma verificação de background detalhada são promovidas ou transferidas para cargos de maior responsabilidade ou nível de acesso.



12.8 Se os dados do titular do cartão forem compartilhados com prestadores de serviços, manter e implementar políticas e procedimentos para gerenciar os prestadores de serviços, incluindo o seguinte:

Se o comerciante ou o prestador de serviço compartilhar os dados do titular do cartão com um prestador de serviço, devem ser aplicados certos requisitos para garantir a proteção contínua desses dados por tais prestadores de serviço.

12.8.1 Manter uma lista dos prestadores de serviços. Rastrear todos os provedores de serviço identifica quando possíveis riscos se estenderem para fora da organização.

12.8.2 Manter um acordo por escrito que inclua um reconhecimento de que os prestadores de serviços são responsáveis pela segurança dos dados do titular do cartão que eles possuírem.

O reconhecimento dos prestadores de serviço evidencia o compromisso deles com manter uma segurança adequada dos dados do titular do cartão que são obtidos dos clientes e, assim, responsabiliza-os.

12.8.3 Certificar-se de que haja um processo definido para a contratação dos prestadores de serviços, incluindo uma diligência devida adequada antes da contratação.

O processo garante que qualquer envolvimento de um prestador de serviço seja totalmente vetado internamente pela organização, que deve incluir uma análise de risco antes de estabelecer um relacionamento formal com o prestador de serviços.

12.8.4 Manter um programa para monitorar o status de conformidade quanto ao PCI DSS dos prestadores de serviços.

Conhecer o status de conformidade do prestador de serviço com o PCI DSS fornece uma garantia a mais de que eles estão de acordo com os mesmos requisitos aos quais a organização está sujeita.

Se o provedor oferecer diversos serviços, este requisito se aplicará apenas aos serviços realmente prestados ao cliente, e apenas os serviços que estiverem dentro do escopo da avaliação de PCI DSS do cliente. Por exemplo: se um provedor oferecer serviços de firewall/IDS e ISP, um cliente que utilizar o serviço de firewall/IDS incluirá este serviço apenas no escopo da avaliação 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 segurança completo que seja adequadamente disseminado, lido e entendido pelas partes responsáveis, a confusão e a falta de uma resposta unificada podem criar mais tempo ocioso para a empresa, exposição pública desnecessária e novas responsabilidades legais.



12.9.1 Criar o plano de resposta a incidentes para ser implementado no caso de violações do sistema. Certificar-se de que o plano aborda o seguinte, pelo menos:

� Funções, responsabilidades e estratégias de comunicação e contato no caso de um comprometimento, incluindo a notifcação às bandeiras de pagamento, pelo menos

� Procedimentos de resposta específicos a incidentes

� Procedimentos de recuperação e continuidade dos negócios

� Processos de back-up dos dados

� Análise dos requisitos legais visando ao relato dos comprometimentos

� Abrangência e resposta de todos os componentes críticos do sistema

� Referência ou inclusão de procedimentos de resposta a incidentes por parte das bandeiras de pagamento

O plano de resposta a incidentes deve ser completo e conter todos os elementos-chave para permitir que sua empresa reaja com eficiência no caso de uma violação que possa causar impacto nos dados do titular do cartão.

12.9.2 Testar o plano pelo menos uma vez por ano. Sem testes adequados, etapas essenciais podem ser perdidas, o que poderia aumentar a exposição durante um incidente.

Se ao longo do último ano o plano de resposta incidental tiver sido inteiramente ativado, bastará uma revisão 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 precisarão ser testados. Caso nenhum componente do plano tenha sido ativado nos últimos 12 meses, todos os componentes do plano deverão ser testados.

12.9.3 Designar equipes específicas para estarem disponíveis em tempo integral para responder aos alertas.

12.9.4Fornecer o treinamento adequado à equipe que é responsável pela resposta às falhas do sistema.

Sem uma equipe de reação a incidentes treinada e prontamente disponível, podem ocorrer danos extensos à rede, e dados e sistemas críticos podem ficar “poluídos” pelo manuseio inadequado dos sistemas almejados. Isso pode evitar o sucesso de uma investigação pós-incidente. Se não estiverem disponíveis recursos internos, pense em contratar um fornecedor que os forneça.

12.9.5 Incluir alertas de sistemas de detecção de invasão, prevenção contra invasões e monitoramento da integridade dos arquivos.

Esses sistemas de monitoramento são feitos para se concentrar em possíveis riscos aos dados, são essenciais para se tomar uma ação rápida para evitar uma violação e devem estar incluídos nos processos de resposta a incidentes.

Desenvolver um processo para modificar e aprimorar o plano de resposta a incidentes, de acordo com as lições aprendidas e para incorporar os desenvolvimentos do setor.

Incorporar as “lições aprendidas” no plano de reação a incidentes depois de um incidente ajuda a manter o plano atualizado e capaz de reagir às ameaças que surgirem e às tendências de segurança.


Orientação para o Requisito A.1: Requisitos adicion ais do PCI DSS para provedores de hospedagem compartilhada

Requisito A.1: Os provedores de hospedagem comparti lhada protegem o ambiente de dados do titular do ca rtão

Conforme mencionado no Requisito 12.8, todos os prestadores de serviços com acesso aos dados do titular do cartão (incluindo os provedores de hospedagem compartilhada) devem seguir o PCI DSS. Além 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 também devem estar em conformidade com os requisitos nesse Apêndice.


A.1 Proteja o ambiente hospedado e os dados de cada entidade (seja comerciante, prestador de serviços 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 seções relevantes do PCI DSS.

Observação: Embora um provedor de hospedagem possa atender a esses requisitos, a conformidade da entidade de que utiliza o provedor de hospedagem não é assegurada. Cada entidade deve estar em conformidade com o PCI DSS e validar a conformidade, conforme aplicável.

O Anexo A do PCI DSS é destinado a provedores de hospedagem compartilhada que desejam fornecer aos clientes do comerciante e/ou prestador de serviço um ambiente de hospedagem em conformidade com o PCI DSS. Essas etapas devem ser cumpridas, além de todos os outros requisitos relevantes do PCI DSS.

A.1.1 Certificar-se de que cada entidade executa somente os processos que têm acesso ao ambiente de dados do titular do cartão daquela entidade.

Se um comerciante ou prestador de serviço puder executar seus aplicativos próprios no servidor compartilhado, eles devem ser executados com o ID de usuário do comerciante ou prestador de serviço, e não como um usuário privilegiado. O usuário privilegiado pode ter acesso aos ambientes de dados do titular do cartão de todos os outros comerciantes e prestadores de serviço, além dos seus próprios.

A.1.2 Restringir o acesso e os privilégios de cada entidade somente ao próprio ambiente de dados do titular do cartão.

Para garantir que os acessos e os privilégios estejam restritos, de forma que cada comerciante ou prestador de serviço só tenha acesso ao próprio ambiente dos dados do titular do cartão, considere o seguinte: (1) privilégios do ID de usuário do servidor da Web do comerciante ou do prestador de serviço; (2) permissões concedidas para ler, gravar e executar arquivos; (3) permissões concedidas para gravar em binários do sistema; (4) permissões concedidas aos arquivos de log do comerciante e do prestador de serviço; e (5) controles para garantir que um comerciante ou prestador de serviço não possa monopolizar os recursos do sistema.

A.1.3 Certificar-se de que os registros e as trilhas de auditoria estão ativadas e são exclusivas para o ambiente de dados do titular do cartão de cada

Os logs devem estar disponíveis em um ambiente de hospedagem compartilhado, de forma que os comerciantes e prestadores de serviço tenham acesso e


Requisito Orientação entidade, além de estarem em conformidade com o Requisito 10 do PCI DSS.

consigam analisar os logs específicos ao ambiente dos dados do titular do cartão.

A.1.4 Permitir que os processos providenciem uma investigação forense oportuna no caso de um comprometimento em qualquer comerciante ou prestador de serviços hospedado.

Os provedores de hospedagem compartilhada devem ter processos para fornecer uma resposta rápida e fácil no caso de uma investigação forense ser necessária para um comprometimento, até o nível adequado de detalhes, de forma que os detalhes individuais do comerciante ou do prestador de serviço estejam disponíveis.


Anexo A: Padrão de segurança de dados do PCI: docum entos relacionados Os documentos a seguir foram criados para auxiliar comerciantes e prestadores de serviço a entenderem o Padrão de segurança de dados do PCI e as responsabilidades e requisitos de conformidade.

Documento Público

Requisitos dos Padrões de Segurança de Dados do PCI e Procedimentos de Avaliação da Segurança

Todos os comerciantes e prestadores de serviço

Navegando pelo PCI DSS: Conheça a intenção dos requisitos Todos os comerciantes e prestadores de serviço

Padrão de segurança de dados do PCI: Diretrizes e instruções do Questionário de auto-avaliação

Todos os comerciantes e prestadores de serviço

Padrão de segurança de dados do PCI: Questionário A de auto-avaliação e atestado

Comerciantes qualificados9

Padrão de segurança de dados do PCI: Questionário B de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário C-VT de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário C de auto-avaliação e atestado


Padrão de segurança de dados do PCI: Questionário D de auto-avaliação e atestado

Comerciantes e prestadores de serviço qualificados9

Glossário de termos, abreviações e acrônimos do PCI DSS e PA-DSS Todos os comerciantes e prestadores de serviço

9 Para determinar o Questionário de auto-avaliação adequado, veja Padrão de segurança de dados do PCI: Diretrizes e instruções do Questionário de auto-avaliação, “Selecionando

o SAQ e certificado que melhor se aplicam à sua organização”.

Documents

Indústria de cartões de débito (PCI - Payment Card ... · O ambiente de dados do titular do cartão compreende pessoas, processos e tecnologia que lidam com os dados do titular